Thunderbolt, DMA and Peripheral Attack Protection Guide: Protecting Lost and Unattended Laptops

A locked laptop is not necessarily a protected laptop: PCIe-capable ports such as Thunderbolt, USB4 and CFexpress let a plugged-in device read and write system memory directly, without the processor, unless the operating system and firmware stop it. Microsoft describes the threat plainly: an attacker with a few minutes and off-the-shelf tools could extract data or inject malware while the owner is away. Lost, stolen and briefly unattended devices are the scenario that matters, and full disk encryption alone does not cover a running machine whose keys are already in memory. This guide is for endpoint, platform and security architecture teams. It explains how direct memory access (DMA) attacks work at a defensive level, how IOMMU-based protection works on Windows, macOS and Linux, which settings to deploy, how to roll them out and test them, and how to handle the wider peripheral threat from USB devices. It goes deeper on DMA than the Firmware and Boot Security Guide, which covers the boot chain.

Key takeaways

• The IOMMU is the control that matters. It restricts each device to the memory mapped for it; with it enforced, a malicious peripheral cannot reach kernel memory or encryption keys.
• Confirm protection is actually on. On Windows, msinfo32 must show Kernel DMA Protection "ON", which needs UEFI support and Intel VT-d (or the platform equivalent) enabled in firmware.
• Decide what happens before sign-in. Windows blocks devices with non-remapping drivers until a user signs in or unlocks, by default; the DmaGuard DeviceEnumerationPolicy lets you block them entirely.
• Boot time and legacy ports are separate problems. Kernel DMA Protection does not cover boot or FireWire, PCMCIA, CardBus and ExpressCard; firmware settings and pre-boot authentication fill that gap.
• Peripherals are more than DMA. Keystroke-injecting USB devices, rogue network adapters and storage exfiltration need device control policies as well (ATT&CK T1200 Hardware Additions).

How DMA and peripheral attacks work

Direct memory access lets fast devices such as storage controllers, network cards and graphics adapters move data to and from memory without involving the CPU. External PCIe tunnelling over Thunderbolt and USB4 extends that ability to anything plugged into the port. Without an IOMMU enforcing per-device memory maps, a device can read arbitrary memory (credentials, BitLocker or FileVault keys, session tokens) or write to it (patching the kernel to bypass the lock screen). Public research over the past decade has repeatedly shown that firmware, driver and protocol weaknesses can undermine port security where IOMMU protection is absent or incompletely enforced.

Windows: Kernel DMA Protection and DmaGuard

Kernel DMA Protection on Windows 10 and 11 uses the system IOMMU to block external peripherals from starting DMA unless their drivers support DMA remapping.

• Remapping-compatible drivers: enumerated, started and allowed DMA only to their assigned memory. Microsoft's inbox USB XHCI 3.x, AHCI/SATA and NVMe drivers support it.
• Incompatible drivers: blocked by default until an authorised user signs in or unlocks. Once started, an incompatible device keeps working through later screen locks and sign-outs until it is unplugged or the system restarts.
• Requirements: UEFI firmware support and Intel VT-d enabled in firmware; virtualisation-based security is not required. Supported on Pro, Enterprise, Pro Education/SE and Education editions. DMA remapping for graphics devices needs Windows 11 with the WDDM 3.0 driver model.
• Verification: Windows Security, Device security, Core isolation details, Memory access protection; or msinfo32.exe showing Kernel DMA Protection as ON. If it is OFF and Hyper-V firmware virtualisation shows No, enable VT-d in UEFI and reboot. If it is still off, the hardware does not support it. Per device, Device Manager's Details tab shows "DMA Remapping Policy": 2 means supported; 0, 1 or a missing property means not.
• Limitations: no protection for 1394/FireWire, PCMCIA, CardBus or ExpressCard, and no protection during boot, where firmware must protect the ports.

Policy settings

The DmaGuard policy needs a reboot and applies only where firmware supports and enables Kernel DMA Protection. Microsoft's BitLocker countermeasures guidance says pre-boot authentication helps mitigate DMA and memory remanence attacks, covers the window after BitLocker unlocks but before Windows applies port policies, and recommends hibernate over sleep. For the encryption side, see the Disk Encryption Guide: BitLocker and FileVault.

macOS and Linux

macOS

• Apple silicon: Apple's Platform Security Guide says each DMA agent has its own IOMMU with separate address translation tables, so PCIe and Thunderbolt peripherals reach only memory mapped for their use; an out-of-bounds attempt triggers a kernel panic.
• Intel Macs: Intel VT-d is set up early in boot and the IOMMU starts in a default-deny state, so peripheral DMA is blocked from power-on until software maps allowed regions.
• Boot: since macOS 11, Macs with the T2 chip run UEFI drivers that handle external device DMA in a restricted ring 3 environment.
• Operational point: because protection is built in, the work on macOS is keeping devices on supported hardware and current macOS, enforcing FileVault and managing accessory access through MDM where your fleet supports it.

Linux

The kernel exposes Thunderbolt and USB4 security through sysfs. The domain's security attribute reports the level set by firmware or the connection manager.

• IOMMU check: if iommu_dma_protection reads 1, the IOMMU restricts device memory access and the kernel documentation says the security levels are then largely redundant.
• Auto-authorisation: the kernel documentation warns that a rule authorising every device bypasses the security levels and makes the system vulnerable to DMA attacks; if you must, limit it to systems where iommu_dma_protection is 1.
• Software connection managers: on later USB4 hardware and Apple systems they support only the user level and expect IOMMU protection.

Firmware settings and hardware selection

• Enable IOMMU in firmware: Intel VT-d or the AMD equivalent, and the vendor's pre-boot or boot-time DMA protection option where offered.
• Thunderbolt firmware security level: on older systems without OS-level protection, set user or secure authorisation or disable PCIe tunnelling.
• Protect the firmware settings: a firmware administrator password stops a thief from simply turning protection off. See the Firmware and Boot Security Guide.
• Disable unused legacy ports: FireWire, ExpressCard and similar have no Kernel DMA Protection coverage.
• Procurement: require Kernel DMA Protection support (Windows), current IOMMU-protected platforms and vendor firmware update support in hardware standards; Microsoft's Secured-core PC programme bundles these expectations.

Peripheral and USB device control

DMA protection does not stop a device that behaves like a keyboard or a storage drive. Device control fills that gap. Microsoft Defender for Endpoint documents three layers: Windows device installation restrictions (allow or deny drivers by device ID, instance ID or setup class), Defender device control policies (by device, type, operation, user group, network location or file type, including allowing only BitLocker-encrypted removable drives) and Endpoint DLP for content. Device control requires anti-malware client 4.18.2103.3 or later and does not support servers. Setting the default enforcement to Deny also blocks printers, so add an allow policy for printers if you only mean to manage storage. See the Removable Media and USB Control Guide and the USB Drop Attacks Guide.

Where identity fits

A DMA attack on a running laptop is an identity attack in practice: the prize is often the primary refresh token, browser session cookies, cached Kerberos tickets and developer credentials such as cloud CLI tokens and SSH keys sitting in memory or unlocked on disk. Privileged and developer laptops hold machine and workload credentials that outlive the device's loss. Pair DMA controls with short token lifetimes, device-bound credentials where your identity provider supports them, and a lost-device runbook that revokes sessions and rotates credentials. See the Privileged Access Workstations Guide.

Choosing the right level for each device group

Small organisations can get most of the benefit by buying hardware that supports Kernel DMA Protection, confirming VT-d is enabled, leaving the default enumeration policy in place and enforcing encryption with hibernate. Large organisations should add per-group policies, a driver compatibility list for approved docks, inventory reporting and lost-device credential revocation, because at scale some devices will always be lost while unlocked or asleep.

Implementation roadmap

1. Inventory: report Kernel DMA Protection state across the Windows fleet (msinfo32 data or your endpoint management inventory), Linux iommu_dma_protection and Thunderbolt security levels, and Mac hardware models.
2. Fix firmware: enable VT-d and pre-boot DMA protection, set firmware passwords and update firmware on the models that report protection off.
3. Pilot the policy: apply DeviceEnumerationPolicy 1 (or 0 for a high-risk pilot) to an IT ring with common docks, capture cards and eGPUs, and note devices with non-remapping drivers.
4. Audit device control: deploy Defender device control or equivalent in audit mode and review RemovableStoragePolicyTriggered events before enforcing.
5. Enforce by ring: widen to general users, then apply 0 and TPM plus PIN to privileged and high-risk travel devices.
6. Roll back: revert the policy value through MDM (a reboot is required); keep an exception group for hardware awaiting driver updates rather than relaxing the baseline.
7. Retire legacy: replace hardware that cannot support IOMMU-based protection.

Detection and measurement

• Configuration drift: alert when a device reports Kernel DMA Protection off, or when firmware virtualisation settings change.
• Device events: PnPDeviceBlocked, PnPDeviceAllowed and RemovableStoragePolicyTriggered in Defender advanced hunting; new Thunderbolt authorisations in Linux logs.
• Lost device signals: sign-ins or token use from a device reported lost.

Metrics:

• Protection coverage: percentage of laptops with IOMMU-based DMA protection enabled (target near 100% of supported hardware).
• Strict policy coverage: percentage of privileged devices with enumeration policy set to block all and TPM plus PIN.
• Legacy exposure: number of devices that cannot support protection, with a replacement date.
• Exception count: devices in the DMA exception group, trending down.
• Lost-device response: median time from loss report to session revocation.

Framework mapping

Common failure patterns

• Assuming the feature is on: hardware that supports Kernel DMA Protection ships with VT-d disabled, so msinfo32 shows OFF.
• Allow all to fix a dock: setting the enumeration policy to 2 to make one incompatible peripheral work removes protection fleet-wide.
• Sleep instead of hibernate: unattended laptops in sleep keep keys in memory and resume without pre-boot authentication.
• Linux auto-authorise rules: udev rules that authorise every Thunderbolt device on systems without IOMMU protection.
• Firmware unprotected: no firmware password, so a thief can disable IOMMU or Thunderbolt security in setup.
• No credential response: the laptop is wiped remotely but its sessions and developer tokens remain valid.

Practitioner checklist

• Report Kernel DMA Protection, Linux IOMMU protection and Thunderbolt security levels across the fleet.
• Enable VT-d or equivalent and pre-boot DMA protection in firmware, and set firmware passwords.
• Set DmaGuard DeviceEnumerationPolicy to 1 as baseline and 0 for privileged and high-risk devices.
• Use TPM plus PIN and hibernate rather than sleep on high-risk devices.
• Disable or block legacy DMA ports that Kernel DMA Protection does not cover.
• On Linux, use user or secure Thunderbolt levels and avoid blanket auto-authorisation.
• Deploy USB device control in audit mode, then enforce.
• Include session revocation and credential rotation in the lost-device runbook.
• Add IOMMU-based DMA protection to hardware procurement standards.

Standards and references

• Microsoft: Kernel DMA Protection
• Microsoft: DmaGuard Policy CSP
• Microsoft: BitLocker countermeasures
• Apple: Direct memory access protections for Mac computers
• Linux kernel: USB4 and Thunderbolt
• Microsoft: Device control in Microsoft Defender for Endpoint
• MITRE ATT&CK: Hardware Additions
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Disk Encryption Guide: BitLocker and FileVault · Removable Media and USB Control Guide · Privileged Access Workstations Guide