USB 1.0 to USB4 v2 and Thunderbolt 1 to 5: Specs, Dates, DMA Attacks

USB went from 12 Mbps in USB 1.0 (January 1996) to 480 Mbps in USB 2.0 (2000), 5 Gbps in USB 3.0 (2008), 10 and 20 Gbps in USB 3.1 and 3.2, 40 Gbps in USB4 (2019) and 80 Gbps in USB4 Version 2.0 (October 2022). Thunderbolt went from 10 Gbps channels on a Mini DisplayPort connector in 2011 to 80 Gbps, with bursts to 120 Gbps, in Thunderbolt 5 (announced September 2023), all on USB-C since Thunderbolt 3.

The security story follows one thread. Thunderbolt and USB4 carry PCI Express through the port, and PCIe devices can read and write memory on their own through direct memory access (DMA). FireWire showed the problem in the 2000s, Thunderclap (2019) showed the IOMMU defences had gaps, and Thunderspy (2020) showed that Thunderbolt's own access controls could be bypassed with brief physical access. The fixes that matter today are an IOMMU switched on early, Windows Kernel DMA Protection, the Linux Thunderbolt security levels and Apple's per device IOMMUs.

Key takeaways

• USB speeds: 12 Mbps (1.0, 1996), 480 Mbps (2.0, 2000), 5 Gbps (3.0, 2008), 10 Gbps (3.1, 2013), 20 Gbps (3.2, 2017), 40 Gbps (USB4, 2019), 80 Gbps symmetric or 120 Gbps one way (USB4 Version 2.0, 2022).
• Read the Gbps, not the version. USB-IF now asks vendors to label products "USB 5Gbps" through "USB 80Gbps"; names like "USB 3.2" are not meant for packaging.
• USB-C is the connector (August 2014). USB Power Delivery negotiates power over it, up to 240 W since PD 3.1 (May 2021). Neither tells you the data speed.
• Thunderbolt went from Mini DisplayPort (2011, 2013) to USB-C at 40 Gbps (Thunderbolt 3 and 4) and 80 Gbps (Thunderbolt 5, 2023). USB4 is built on the Thunderbolt 3 protocol.
• A PCIe tunnel means DMA. Plain USB peripherals do not perform DMA; a Thunderbolt or USB4 device with a PCIe tunnel can.
• Thunderclap (NDSS 2019) found IOMMU protection often off and leaky when on. Thunderspy (May 2020) found seven weaknesses in Thunderbolt 1 to 3 access control.
• Check it: Windows Security, Device security, Core isolation details, Memory access protection. On Linux, iommu_dma_protection should read 1.
• Kernel DMA Protection does not cover boot, FireWire or ExpressCard. Firmware owns the pre boot window.
• Controller firmware and drivers are software with versions and updates, so they belong in your inventory.

A dated timeline of USB, Thunderbolt and DMA attacks

The USB-IF site lists its current specifications but not historic release dates, and Intel's newsroom blocked most automated requests. Dates marked with an asterisk come from Wikipedia's summaries of the original releases. Unmarked dates come from the USB-IF, Intel, Microsoft or the researchers' own pages.

What were the speeds and dates for USB 1.0 through USB4 v2?

Spec comparison table

USB 1.x and 2.0: one port for everything

USB was designed to replace serial, parallel, game and PS/2 ports with one hot pluggable bus. USB 1.0 defined Low Speed (1.5 Mbps) for keyboards and mice and Full Speed (12 Mbps) for everything else; USB 1.1 in August 1998 fixed early problems and is what most late 1990s hardware shipped. USB 2.0 in April 2000 added High Speed at 480 Mbps on the same four wires, and every later port still carries a USB 2.0 pair for compatibility.

The design choice that matters for security came early: USB is host scheduled. The host controller polls devices and does the DMA under its driver's control; a USB keyboard, stick or webcam cannot write into memory on its own. Microsoft's Kernel DMA Protection FAQ says non PCI peripherals such as USB devices do not perform DMA, so their drivers need no DMA remapping. USB's own problems are about what a device claims to be, covered in our post on BadUSB, lost drives and air gapped transfer.

USB 3.0, 3.1 and 3.2: SuperSpeed and two renames

USB 3.0 (November 2008) added a separate full duplex "SuperSpeed" path at 5 Gbps using five extra wires and 8b/10b coding, so about 20 percent of the raw rate is coding overhead. USB 3.1 (July 2013) added 10 Gbps with 128b/132b coding, about 3 percent overhead, and renamed 5 Gbps "Gen 1" and 10 Gbps "Gen 2". USB 3.2 (September 2017) used the second set of high speed pairs in a USB-C cable for two lanes; the USB-IF's USB 3.2 page says the specification "absorbed all prior 3.x specifications" and defines 5, 10 and 20 Gbps. Gen 2x2 (20 Gbps) only exists on USB-C.

USB4: Thunderbolt 3 becomes USB

USB4 was announced in March 2019 and Version 1.0 released on 29 August 2019. The USB-IF describes it as "based on the Thunderbolt protocol specification contributed by the Intel Corporation." A USB4 link is a tunnelling fabric: it carries USB 3.x, DisplayPort and PCIe traffic at the same time over a shared 20 or 40 Gbps link, on USB-C only, and stays compatible with USB 3.2, USB 2.0 and Thunderbolt 3.

That is the key to the security discussion. PCIe tunnelling is optional for USB4 devices, but Wikipedia's summary of Microsoft's hardware certification says Windows requires every USB4 port to support PCIe tunnelling and Thunderbolt 3 compatibility. On a Windows USB4 laptop, the port that charges your phone can also carry PCIe.

USB4 Version 2.0: 80 Gbps

USB4 Version 2.0 was announced on 1 September 2022 and released on 18 October 2022. A new physical layer runs 80 Gbps symmetric, or 120 Gbps one way and 40 Gbps the other for display heavy use, and the USB-IF says the 80 Gbps rate needs cables certified for it. Version 2.0 also removed a Version 1.0 limit that capped PCIe packets in a tunnel at 128 bytes, which had hurt external storage and graphics throughput.

Why are USB 3.x names so confusing, and what do the current logos say?

The confusion has three causes. The USB-IF renamed existing modes twice (2013 and 2017), so the same 5 Gbps port is "USB 3.0", "USB 3.1 Gen 1" and "USB 3.2 Gen 1" depending on the year of the box. Specification version numbers describe the newest document a product complies with, not its speed, so a "USB 3.2" device can be a 5 Gbps device. And connector shape says nothing about speed: a USB-C port can be USB 2.0 only.

The USB-IF responded by telling vendors to stop using version numbers with consumers. Its current USB Data Performance Language Usage Guidelines (January 2024 edition) list five marketing names, each tied only to the signalling rate: USB 80Gbps, USB 40Gbps, USB 20Gbps, USB 10Gbps and USB 5Gbps. The same document says that USB4 Version 2.0, USB4 Version 1.0, USB 3.2, SuperSpeed Plus, Enhanced SuperSpeed and SuperSpeed+ "are not intended to be used in product names." Certified products can carry logos that state the speed, and for charging products the wattage.

The practical rule: read the Gbps figure, and for power the wattage. If a product or cable lists neither, assume the lowest.

What does USB Type-C define, and what does USB PD add?

Type-C: connector, cable and configuration

The USB Type-C Cable and Connector Specification, first published on 11 August 2014, defines the 24 pin reversible connector and its cables. It also defines the configuration channel (CC) pins, which detect attachment, orientation and which side supplies power, and Alternate Modes, where some high speed wires carry DisplayPort or Thunderbolt after negotiation. Later releases enabled USB4 (2.0, August 2019), 240 W cables (2.1, May 2021) and USB4 Version 2.0 (2.2, October 2022).* Full featured and higher current cables carry an electronic marker chip that tells the host what the cable can do.

Type-C does not define a port's data speed. A USB-C port can be USB 2.0 only, USB 3.2, USB4 or Thunderbolt.

USB Power Delivery: negotiation for power

USB Power Delivery is a separate protocol for negotiating voltage, current and power direction over the CC line. The USB-IF describes it as "more flexible power delivery along with data over a single cable." Before PD 3.1 the ceiling was 100 W (20 V at 5 A). The USB Promoter Group announced PD 3.1 on 26 May 2021, adding 28, 36 and 48 V fixed voltages for 140, 180 and 240 W, an adjustable voltage mode, and a stricter negotiation protocol for the higher power range. Power can flow either way, so a monitor can charge a laptop.

Two security notes follow. The charger and the data device share a port: the Thunderclap team warned that a malicious charger or projector could do its visible job while attacking the host over a PCIe tunnel. And PD and Type-C negotiation run in small controller chips with their own firmware that few inventories record. For public charging kiosks, see juice jacking: what is actually documented.

How did Thunderbolt evolve from Mini DisplayPort to USB-C?

Thunderbolt 1 and 2. Intel developed Thunderbolt from its "Light Peak" project, and Apple shipped it first in February 2011 MacBook Pros on a Mini DisplayPort connector. The controller multiplexes PCIe lanes and DisplayPort streams onto the cable and splits them out at the far end, so one cable could drive a display and an external PCIe device such as a storage array or capture card. Thunderbolt 2 (2013) merged the two 10 Gbps channels into one 20 Gbps channel.

Thunderbolt 3. In 2015 Thunderbolt moved to USB-C as an Alternate Mode at 40 Gbps, carrying up to four PCIe 3.0 lanes plus DisplayPort and falling back to USB 3.1 Gen 2 for plain USB devices. The Thunderspy authors describe how the port switches its physical mode depending on what is plugged in. From then on a Thunderbolt port looked like any USB-C port. On 4 March 2019 Intel gave the Thunderbolt 3 specification to the USB Promoter Group royalty free, and it became USB4.*

Thunderbolt 4. Announced at CES 2020 with the final specification in July 2020, it kept 40 Gbps but raised the floor: 32 Gbps PCIe, two 4K displays, hubs as well as daisy chains, and Intel VT-d based DMA protection as a host certification requirement.* Intel's own page blocked our automated requests, so this list comes from Wikipedia's summary.

Thunderbolt 5. Intel introduced it on 12 September 2023 with 80 Gbps bi directional bandwidth, Bandwidth Boost up to 120 Gbps for video, double Thunderbolt 4's PCIe throughput, DisplayPort 2.1 and passive cables up to 1 metre, built on industry standards "including USB4 V2." The release does not mention DMA protection.

Why does Thunderbolt expose PCIe, and therefore DMA?

Because that is its purpose: putting PCIe devices such as external GPUs, NVMe enclosures, fast network adapters and docks outside the case. PCIe devices are bus masters that read and write memory themselves, which is why they are fast and why the processor's MMU, which only governs software, does not restrict them.

Microsoft's Kernel DMA Protection page says PCIe hot plug devices such as Thunderbolt, USB4 and CFexpress are DMA capable, and describes drive by DMA attacks that take a few minutes with off the shelf hardware while the owner is away, without opening the case. The bus evolution post in this series explains bus mastering and IOMMUs in depth.

Three conditions decide whether an external device can actually do this:

1. Is a PCIe tunnel created? Never for plain USB. For Thunderbolt or USB4, only if the host's connection manager builds one under its security level or policy.
2. Is an IOMMU confining the device? If so, it reaches only memory its driver mapped.
3. Is the pre boot window covered? Operating system protections start with the operating system; before that, firmware decides. See CWE-1190, DMA enabled too early.

Some systems also run Option ROMs from attached Thunderbolt devices at boot, a separate firmware risk that UEFI Secure Boot's signature checks address.* MITRE ATT&CK lists kernel memory reading via DMA among hardware addition capabilities in T1200; see our T1200 explainer.

What did the FireWire DMA attacks show?

FireWire (IEEE 1394), standardised in 1995, was the first consumer external bus where DMA attacks became a mainstream concern. Its OHCI host controller design let attached devices request reads and writes to physical memory without the operating system's involvement. In 2004 Maximillian Dornseif demonstrated FireWire memory access at the PacSec conference in Japan using a modified iPod.* Later public tools extended the technique to ExpressCard, PC Card and Thunderbolt.*

The lessons every later bus relearned:

• Port access can equal RAM access. Disk encryption does not help a running or sleeping machine, because the keys are in memory.
• Ports can be added. A laptop without FireWire was still exposed through a PC Card or ExpressCard FireWire adapter.*
• Driver blocking is blunt. Microsoft's BitLocker guidance was to block the SBP-2 driver and FireWire controllers (KB2516445), and Linux added an option to disable FireWire physical DMA.* Microsoft states Kernel DMA Protection does not cover 1394/FireWire, PCMCIA, CardBus or ExpressCard, so on old hardware the old mitigations still apply.

What did Thunderclap (2019) find?

Thunderclap is research from the University of Cambridge and SRI International (A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore and Robert N. M. Watson), presented at NDSS in San Diego on 24 to 27 February 2019 after disclosure to vendors from 2016. Their platform was an FPGA that posed as a common, genuine Ethernet controller, so the operating system loaded its normal driver and gave it legitimate DMA work. That let them study what a malicious device could reach.

Key findings:

• IOMMUs were often off. The site says IOMMU protection "is turned off by default in many systems," partly for performance.
• On is not enough. Operating systems placed sensitive data in the same memory regions mapped for device communication, so a correctly confined device could still see network traffic and, on some systems, keystrokes and framebuffer data.
• Chargers and projectors are attack surfaces because USB-C mixes power, video and PCIe on one port.
• Supply chain matters. Compromised firmware in an internal PCIe device, such as a NIC or server BMC, could use the same weaknesses.
• macOS approved by allowlist rather than prompting, so an attacker could buy an approved dock.

Vendor responses listed by the researchers: Apple fixed the specific issue used for a root shell in macOS 10.12.4; Microsoft enabled IOMMU protection for Thunderbolt in Windows 10 version 1803 (2018), with older hardware needing a firmware update; Intel contributed Linux 5.0 patches enabling the IOMMU for Thunderbolt and blocking a bypass through PCIe Address Translation Services (ATS). The researchers advise disabling Thunderbolt in firmware where unneeded, using non Thunderbolt docks so a USB-C port cannot switch into Thunderbolt mode, avoiding public USB-C charging stations and declining unexpected approval prompts.

What did Thunderspy (2020) find?

Thunderspy is research by Björn Ruytenberg of Eindhoven University of Technology, made public on 10 May 2020. It targeted Thunderbolt's own access control: the security levels that let users authorise trusted devices, and the "cryptographic authentication of connections" meant to stop spoofing. The site lists seven vulnerabilities:

1. Inadequate firmware verification schemes.
2. Weak device authentication scheme.
3. Use of unauthenticated device metadata.
4. Downgrade attack using backwards compatibility.
5. Use of unauthenticated controller configurations.
6. SPI flash interface deficiencies.
7. No Thunderbolt security on Boot Camp.

In an "evil maid" model, someone with a few minutes and a screwdriver alone with a sleeping or locked laptop could reprogram the Thunderbolt controller's firmware chip, clone an already authorised device, change or disable the security level without firmware settings showing it, and gain the PCIe access needed for DMA. Some variants made the change permanent and blocked later firmware updates. We describe the classes of weakness, not the procedure.

According to the researchers, all Thunderbolt systems shipped from 2011 to 2020 were vulnerable; systems with Kernel DMA Protection (shipping from 2019) were partially vulnerable, because the IOMMU still blocks the final DMA step; the issues cannot be fixed in software; and because variants 5 and 6 can override the security level, a USB and DisplayPort only setting was not enough. Intel was told of vulnerabilities 1 to 5 on 10 February 2020, and Apple of vulnerability 7 on 17 April 2020. The researchers released Spycheck, an open source checker for Windows and Linux, and MITRE added "CAPEC-665: Exploitation of Thunderbolt." Their advice: connect only your own peripherals, do not leave the system unattended while on or asleep, prefer hibernation or power off, and disable Thunderbolt in firmware if you do not use it.

What is Windows Kernel DMA Protection, and how do you check it?

Kernel DMA Protection uses the IOMMU to block external PCIe peripherals from DMA unless their drivers support DMA remapping (memory isolation). Microsoft's OEM documentation dates it to Windows 10 versions 1803 and 1809 on Intel and AMD platforms.

• Peripherals with remapping capable drivers start normally and are confined to their assigned memory.
• Peripherals without it are blocked if plugged in before an authorised user signs in or while the screen is locked, then run normally after unlock until reboot or unplug.
• Administrators can change that with the group policy Enumeration policy for external devices incompatible with Kernel DMA Protection (under Administrative Templates, System, Kernel DMA Protection) or the DmaGuard MDM policy: block, allow, or allow after sign in (the default).

Limits Microsoft lists:

• It needs UEFI firmware support but not Virtualization based Security, and it turns on automatically only if the firmware opts in through ACPI flags (DMA_CTRL_PLATFORM_OPT_IN_FLAG in the DMAR table on Intel, a DMA remap bit in IVRS on AMD) with all DMA capable devices behind an IOMMU that is on by default.
• It does not protect during boot. Firmware must isolate DMA before ExitBootServices and clear Bus Master Enable on root ports that do not need it.
• It does not cover FireWire, PCMCIA, CardBus or ExpressCard.
• It replaces BitLocker's older DMA countermeasures, which Microsoft recommends disabling where it is supported.
• DMA remapping for graphics drivers arrived in Windows 11 with WDDM 3.0. Microsoft's inbox xHCI, AHCI and NVMe drivers support remapping.

How to check

1. Open Windows Security, Device security, Core isolation details, and look at Memory access protection; or run msinfo32 and read Kernel DMA Protection.
2. If it is Off and the Hyper-V line for virtualization enabled in firmware reads No, turn on Intel Virtualization Technology and VT-d (or the AMD equivalent) in firmware and reboot.
3. If it is still Off, the system does not support it.
4. For one device, Device Manager's Details tab shows DMA Remapping Policy: 2 means the driver supports remapping; 0, 1 or no value means it does not.

What do macOS and Linux do about external DMA?

macOS

Apple's Platform Security guide says Macs have had DMA protections since 2012. On Apple silicon, each DMA agent, including PCIe and Thunderbolt ports, has its own IOMMU and translation tables, so a peripheral reaches only memory mapped for it, and any other access triggers a kernel panic. Apple's IOMMUs start with a default deny policy at power on. Intel Macs with VT-d enable DMA and interrupt remapping very early in boot, and Macs with the T2 chip run boot time UEFI drivers for external devices in a restricted ring 3 environment. Two caveats from the research: Thunderclap found macOS used an allowlist of approved Thunderbolt devices, and Thunderspy found Thunderbolt security disabled when Intel Macs ran Windows or Linux through Boot Camp.

Linux

The kernel's USB4 and Thunderbolt guide describes two layers. First, security levels, read from /sys/bus/thunderbolt/devices/domainX/security:

With user or secure, a device's authorized attribute reads 0 and no PCIe tunnel exists until it is approved. The kernel's software connection manager, used on Apple systems and newer USB4 designs, defaults to user, so PCIe tunnelling starts off. The guide says a userspace tool should keep the approval database; on most desktop distributions that is the bolt daemon and boltctl. It also warns that a catch all udev rule authorising every device bypasses the levels.

Second, IOMMU DMA protection. Systems from 2018 onward may support it natively, Linux enables the IOMMU automatically on them, and they report 1 in iommu_dma_protection. Some such systems ship with the level set to none, since the IOMMU confines devices. Given that Thunderspy bypassed authorisation and Thunderclap found IOMMU gaps, the safer posture is both. The guide recommends fwupd for Thunderbolt host, device and retimer firmware (NVM) updates.

Decision table: which defence against which threat

Step by step: audit a laptop's external ports

These commands only read state. Run them on machines you administer. The one step that changes state is marked.

1. Windows: check Kernel DMA Protection and list devices

# Shows the "Kernel DMA Protection" line in System Summary
msinfo32

# List present PCI devices (Thunderbolt and USB4 tunnelled devices appear here)
Get-PnpDevice -PresentOnly |
  Where-Object { $_.InstanceId -like 'PCI\*' } |
  Select-Object Status, Class, FriendlyName, InstanceId

# Record USB and Thunderbolt controller drivers for inventory
Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DeviceName -match 'USB|Thunderbolt|USB4' } |
  Select-Object DeviceName, DriverProviderName, DriverVersion, DriverDate |
  Export-Csv -NoTypeInformation usb-tb-drivers.csv

Then confirm Memory access protection in Windows Security as described above, and check the DMA Remapping Policy for any external adapter you rely on.

2. Linux: list the USB tree and speeds

lsusb -t        # tree with negotiated speed: 480M, 5000M, 10000M, 20000M
lsusb           # vendor:product IDs

A device you expected at 10000M that shows 480M is on a USB 2.0 only cable or port.

3. Linux: read Thunderbolt and USB4 security state

for d in /sys/bus/thunderbolt/devices/domain*; do
  echo "$d security=$(cat $d/security) iommu_dma_protection=$(cat $d/iommu_dma_protection)"
done
boltctl domains     # same information through the bolt daemon
boltctl list        # each device, its authorisation status and policy

What you want to see: iommu_dma_protection=1. If it reads 0 and the security level is none, any Thunderbolt or USB4 device gets a PCIe tunnel without approval and is not confined by an IOMMU. Check firmware settings for VT-d or AMD-Vi (sometimes "IOMMU") and for a Thunderbolt security option.

4. Linux: confirm the IOMMU is on

sudo dmesg | grep -i -E "DMAR|IOMMU|AMD-Vi"
ls /sys/kernel/iommu_groups/ | wc -l     # 0 means no active IOMMU
cat /proc/cmdline                         # look for iommu=off, intel_iommu=off or iommu=pt

5. Linux: record Thunderbolt firmware (NVM) versions

for d in /sys/bus/thunderbolt/devices/*; do
  [ -f "$d/nvm_version" ] && echo "$(basename $d) $(cat $d/device_name 2>/dev/null) nvm=$(cat $d/nvm_version)"
done
fwupdmgr get-devices      # firmware the update service can see
fwupdmgr get-updates      # available updates; review before applying

6. Linux: review a device before authorising it (changes state)

Warning: de-authorising a device tears down its PCIe tunnel, and the kernel guide warns of data loss if storage on it is not unmounted first. Check the device path and name before you write anything.

cat /sys/bus/thunderbolt/devices/0-1/device_name /sys/bus/thunderbolt/devices/0-1/vendor_name
cat /sys/bus/thunderbolt/devices/0-1/authorized     # 0 means no PCIe tunnel yet
# Only if this is a device you own and expect:
boltctl authorize <uuid-from-boltctl-list>

7. macOS: list Thunderbolt and USB devices

system_profiler SPThunderboltDataType   # ports, link status, connected devices, firmware
system_profiler SPUSBDataType           # USB devices and speeds (newer macOS may use SPUSBHostDataType)

8. Put the results in your inventory

Record per machine: Kernel DMA Protection or iommu_dma_protection state, Thunderbolt security level, controller and retimer firmware versions, USB and Thunderbolt driver versions, and whether Thunderbolt is disabled in firmware. CycloneDX has component types for device-driver and firmware, so those versions can live in the same SBOM format as your application dependencies. The hardware supply chain trust boundaries post covers why those layers belong in scope.

What should a laptop buyer or fleet owner check?

Before approving a model:

1. Kernel DMA Protection is supported and on by default, or iommu_dma_protection reads 1 on Linux. Check a sample unit.
2. Prefer Thunderbolt 4, Thunderbolt 5 or certified USB4 hosts over Thunderbolt 3, since Thunderbolt 4 host certification requires VT-d based DMA protection.* A USB4 badge alone does not guarantee the same.
3. Firmware can disable Thunderbolt or PCIe tunnelling while keeping USB, power and video.
4. Firmware protects the pre boot window, which Microsoft assigns to the firmware.
5. Controller, retimer and driver updates ship through a channel you can automate, such as Windows Update or fwupd.
6. Ports are labelled with speed and wattage in USB-IF terms.

For a deployed fleet: collect Kernel DMA Protection and Thunderbolt security state from every machine and track exceptions; keep the Windows external device enumeration policy at its default or stricter; prefer hibernate or shut down for laptops that travel; disable Thunderbolt in firmware on kiosks and shared machines; retire or block FireWire and ExpressCard; issue known good docks and chargers; tell staff not to accept unexpected Thunderbolt prompts; and patch controller firmware and drivers on a schedule, recording versions.

Where Safeguard fits, honestly

Most of this topic sits below where Safeguard works. Safeguard does not configure IOMMUs, set Thunderbolt security levels, manage devices, scan firmware binaries or generate a hardware bill of materials. Those controls come from your operating system, your device management tooling and your hardware vendor.

The honest link is software inventory. Thunderbolt controller firmware, USB and Thunderbolt drivers, bolt, fwupd and the management agents on your laptops are software with versions, release notes and security updates of their own. If you assemble those versions into CycloneDX files, or vendors supply SBOMs, Safeguard can ingest them with safeguard scan --sbom <file>, match components against vulnerability databases and show which products contain a given component and version. It also scans the repositories and container images behind any drivers, agents or tools your team builds. The local runner and offline mode keep those checks on your own machines. Fixes for controller firmware still come from the device vendor.

Common mistakes

• Reading the version, not the speed. "USB 3.2" can mean 5 Gbps. Look for the Gbps figure.
• Assuming USB-C means fast or means Thunderbolt. A USB-C port or cable can be USB 2.0 only.
• Thinking every USB device can do DMA. Plain USB peripherals do not; the risk comes with a PCIe tunnel.
• Thinking Kernel DMA Protection covers boot. Microsoft says it does not.
• Treating sleep as safe. DMA attacks target running, locked or sleeping machines with keys in memory. Hibernate or shut down in untrusted places.
• Relying on security levels alone, or the IOMMU alone. Thunderspy beat the first on 2011 to 2020 hardware; Thunderclap found leaks in the second.
• Auto authorising everything with a catch all udev rule.
• Ignoring old FireWire and ExpressCard ports, which Kernel DMA Protection does not cover.
• Not recording controller firmware and driver versions, so you cannot tell which machines need a vendor update.

FAQ

What is the difference between USB 3.0, 3.1 and 3.2?

They are successive specifications that renamed each other's modes. 5 Gbps was "USB 3.0", then "USB 3.1 Gen 1", then "USB 3.2 Gen 1". 10 Gbps is "Gen 2", and 20 Gbps over two lanes is "Gen 2x2", USB-C only. The USB-IF now asks vendors to say USB 5Gbps, USB 10Gbps or USB 20Gbps.

Is USB4 the same as Thunderbolt 4?

No. USB4 is the USB-IF specification built on the Thunderbolt 3 protocol. Thunderbolt 4 is Intel's certification with stricter minimums, including 40 Gbps, 32 Gbps PCIe, two 4K displays and VT-d based DMA protection on hosts.

How fast is USB4 Version 2.0?

80 Gbps both ways, or 120 Gbps one way and 40 Gbps the other. Its consumer name is USB 80Gbps, and Thunderbolt 5 is built on it.

What is the difference between USB-C and USB PD?

USB-C is the reversible connector and cable specification. USB Power Delivery negotiates voltage, current and direction over its configuration channel, up to 240 W since PD 3.1. Neither defines data speed.

Can a USB flash drive perform a DMA attack?

No. Plain USB devices do not perform DMA; the host controller does it for them. They can still pose as a keyboard or network card, which is a different problem with different controls.

How do I check if Kernel DMA Protection is enabled?

Open Windows Security, Device security, Core isolation details, Memory access protection, or read the Kernel DMA Protection line in msinfo32. If it is off, enable VT-d or the AMD equivalent in firmware and recheck.

Is Thunderspy still a risk?

For Thunderbolt systems shipped from 2011 to 2020, yes; the researchers said it cannot be fully fixed in software. Systems with Kernel DMA Protection are only partially affected. Disable Thunderbolt if unused and prefer hibernation over sleep.

Does macOS protect against Thunderbolt DMA attacks?

Apple says Macs have had DMA protections since 2012, with a separate default deny IOMMU per DMA agent on Apple silicon and early VT-d remapping on Intel Macs. Boot Camp installs of Windows or Linux on Intel Macs lacked Thunderbolt security, per the Thunderspy research.

Fix it without waiting for upstream

External ports are a hardware problem, but the code that runs them is not: Thunderbolt connection managers, USB stacks, fwupd, bolt and the agents that manage your laptops are software built from open source components, and the tools your team writes to collect port and firmware inventory have dependencies of their own. The fit with what follows is indirect for controller firmware, which only its vendor can fix, and direct for the software you build and ship.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows how to set up Safeguard's runner on your own machine, approve it with a device code and run scans from the terminal. That is the flow you would use on an IT admin workstation or an isolated build host to scan the driver and firmware SBOM you assembled in step 8, or the repositories holding your fleet inventory scripts, without sending the work elsewhere.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: the Safeguard CLI reads a lodash finding and its advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval and pushes nothing. The same approve each step pattern applies when a vulnerable library turns up in a device management agent or an internal tool that reads Thunderbolt and USB state across your fleet.

Click through it at your own pace, or open it full screen.

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude may use. Once connected, you can ask which of your projects contain a given driver or library version from your inventory and get the answer from your own Safeguard data.

Click through it at your own pace, or open it full screen.

To try it on your own machines, download Safeguard and follow the CLI documentation.

Quick check

Sources

• USB-IF: USB4 specification page
• USB-IF: USB 3.2 specification page
• USB-IF: USB Type-C Cable and Connector Specification page
• USB-IF: USB Charger (USB Power Delivery)
• USB-IF: Document library
• USB-IF: USB Data Performance Language Usage Guidelines (January 2024)
• USB Promoter Group: USB Power Delivery Revision 3.1 announcement (26 May 2021)
• Intel: Intel Introduces Thunderbolt 5 Connectivity Standard (12 September 2023)
• Microsoft Learn: Kernel DMA Protection
• Microsoft Learn: Kernel DMA Protection (Memory Access Protection) for OEMs
• Apple Platform Security: Direct memory access protections for Mac computers
• Linux kernel: USB4 and Thunderbolt administration guide
• Thunderclap: IOMMU protection and DMA from untrustworthy peripherals
• Thunderspy: When Lightning Strikes Thrice
• MITRE ATT&CK: T1200 Hardware Additions
• Wikipedia: USB
• Wikipedia: USB 3.0
• Wikipedia: USB4
• Wikipedia: USB-C
• Wikipedia: Thunderbolt (interface)
• Wikipedia: DMA attack
• Wikipedia: IEEE 1394

Last reviewed: 23 October 2026.