D3-IOPR IO Port Restriction: Deploy and Verify

Every USB, Thunderbolt and other external port is an unauthenticated entry point unless something decides which devices may use it. MITRE D3FEND names that decision IO Port Restriction (D3-IOPR) and defines it as "Limiting access to computer input/output (IO) ports to restrict unauthorized devices." It sits under the Isolate tactic as a child of Access Mediation (D3-AMED). This card covers what D3-IOPR restricts, which ATT&CK techniques D3FEND relates to it, the operating system and product features that implement it, how to prove a block actually holds, and where the control can be bypassed. It is for endpoint engineers and security architects who already know the policy side from the Removable Media and USB Control Guide and want the technique-level view.

Key takeaways

It is device admission control. D3-IOPR filters Input Devices and Removable Media Devices and isolates the I/O Module, so the question it answers is "may this device talk to this host at all, and with which operations".
D3FEND describes three restriction types. Device connection, device command filtering, and device file system read or write restrictions, delivered by host agent software or by hardware filters between the port and the device.
Allow lists beat block lists. Blocking named device classes leaves every new class open; a default-deny with approved device IDs closes the port to anything not explicitly approved.
Descriptors can be faked. The Linux kernel documentation warns that device class, type and protocol checks are the weakest form of verification because gadget hardware can spoof them, so a keyboard allow rule can admit a malicious device that claims to be a keyboard.
DMA ports need a separate control. Thunderbolt, USB4 and other PCIe hot-plug ports can reach memory directly; that needs IOMMU-based protection such as Windows Kernel DMA Protection, not only a USB storage policy.

D3-IOPR at a glance

Attribute	Value
D3FEND ID	D3-IOPR (d3f:IOPortRestriction)
Tactic	Isolate
Parent technique	Access Mediation (D3-AMED)
Digital artefacts and relations	filters Input Device; filters Removable Media Device; isolates I/O Module
Restriction types named by D3FEND	Device connection; device command filtering; device file system read or write restrictions
Delivery models	Host agent software that monitors IO port traffic; hardware filters such as a USB filter hub between host and devices; secured motherboard port circuitry (one of D3FEND's patent references)
D3FEND considerations	Agent software must be installed on hosts; allow and deny configurations for devices and files must be maintained
ATT&CK mitigation D3FEND relates to it	M1034 Limit Hardware Installation (see M1034 Limit Hardware Installation)

How it works

D3FEND's knowledge base article describes the control as a decision made when a device is connected. Agent software, or a hardware filter, identifies the device and checks it against an approved list, in some implementations by device type. If the device presents itself as storage, its files and executables can be examined to identify it more accurately. The decision then applies at one of three levels.

Connection: the device is never enumerated or never gets a driver. This is the strongest level and the one that stops human interface device (HID) injection tools.
Command filtering: the device connects, but only some operations or interfaces are allowed, for example a composite device whose storage interface is allowed while an unexpected network interface is denied.
File system access: storage mounts, but read, write or execute is restricted, which is the usual setting for data loss prevention on removable drives.

The I/O Module isolation relation matters beyond USB. Ports that expose a bus with direct memory access (DMA), such as Thunderbolt or USB4, let a device read and write memory without the CPU's involvement, so restricting them depends on IOMMU remapping rather than a storage policy.

ATT&CK techniques D3FEND relates to D3-IOPR

Relationship type: inferred only. D3FEND derives these relations through shared digital artefacts and labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). The first group comes from ATT&CK techniques that act directly on a Removable Media Device or I/O Module in the D3FEND ontology; the second from techniques that use input devices, which the D3FEND site also lists. Each ID was checked against ATT&CK v20.

ATT&CK ID	Technique	Artefact link	What IO port restriction does to it
T1091	Replication Through Removable Media	Removable Media Device	A default-deny storage policy stops the drive mounting or executing content
T1025	Data from Removable Media	Removable Media Device	Read restriction limits what can be collected from attached media
T1052.001	Exfiltration over USB	Removable Media Device	Write restriction or device denial removes the exfiltration path
T1092	Communication Through Removable Media	Removable Media Device	Blocks media used as a command channel into air-gapped hosts
T0847 (ICS)	Replication Through Removable Media	Removable Media Device	The same control at engineering workstations and HMIs; see MITRE ATT&CK for ICS T0847 Replication Through Removable Media
T0860 (ICS)	Wireless Compromise	I/O Module	Restricting unused I/O modules removes wireless interfaces an attacker could use
T1056.001	Keylogging	Input Device	Admission control limits hardware keyloggers and unknown input devices
T1123, T1125	Audio Capture, Video Capture	Input Device	Denying unapproved microphones and cameras at the port

The two ICS rows come from the D3FEND ontology file rather than the D3FEND technique page, which lists only Enterprise techniques. Hardware Additions (T1200) is not in D3FEND's list for this technique, but it describes the attacker behaviour IO port restriction most directly addresses; see MITRE ATT&CK T1200 Hardware Additions. The removable media techniques are covered in depth in MITRE ATT&CK T1091 Replication Through Removable Media and MITRE ATT&CK T1052 Exfiltration Over Physical Medium.

Where it is implemented

Platforms are listed alphabetically. Each row names the platform's own controls as described in its documentation (checked November 2026).

Platform or class	Control	Restriction level
Apple macOS (Apple silicon laptops)	System Settings, Privacy & Security, "Allow accessories to connect": Always ask, Ask for new accessories (default), Automatically allow when unlocked, Always allow. On supervised Macs administrators can control the setting	Connection
Linux kernel	sysfs `authorized` per device and `authorized_default` per host controller (0 deauthorises new devices, 1 authorises, 2 authorises only internal ports); `interface_authorized_default` and per-interface `authorized` for partial devices	Connection and interface
Linux USBGuard	Rule language with targets allow, block (left connected but unauthorised) and reject (removed from the system); matching on vendor:product ID, per-device hash, serial, via-port and with-interface. Devices that match no rule are blocked	Connection and interface
Microsoft Windows device installation	Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions: allow or prevent by device instance ID, device ID or setup class, "Prevent installation of removable devices", "Prevent installation of devices not described by other policy settings", and the layered evaluation order setting	Connection
Microsoft Windows Kernel DMA Protection	IOMMU-based DMA remapping for Thunderbolt, USB4 and CFexpress; Group Policy "Enumeration policy for external devices incompatible with Kernel DMA Protection" (Blocked, Allowed, or Allowed only after user sign-in, the default), MDM DmaGuard	Connection for DMA-capable devices
Microsoft Defender for Endpoint device control	Removable storage, Windows Portable Devices, printers and Bluetooth; read, write and execute control by device, user group, network location or file type; audit entries that log without blocking	File system and connection
Endpoint DLP and device control agents (product class)	Third-party agents that implement the agent model D3FEND describes, usually with central policy and reporting	All three
Hardware port filters (product class)	USB filter hubs, port blockers and secure KVMs that decide outside the host OS	Connection

The file system level overlaps with data loss prevention; see the Endpoint DLP Guide.

Implementation steps

Inventory what is plugged in. Collect device recognition events for a few weeks before blocking anything. On Windows, enable the Audit PNP Activity subcategory so event 6416 records Device ID, Class ID and Vendor IDs. On Linux, usbguard generate-policy produces allow rules for currently connected devices that you can review.
Classify devices. Group them into always needed (keyboards, mice, docks, smart card readers, hubs and host controllers), approved by exception (encrypted corporate drives by device or instance ID) and never needed. Microsoft's guidance notes that an allow list must include parent controllers and hubs, or users lose input devices.
Start in audit. Use audit entries (Defender device control) or log-only rules so you see what would be blocked. Run a pilot ring of IT staff for two to four weeks (an example period, not a standard).
Move to default-deny. Allow by device ID or instance ID; deny everything else. Keep HID and storage decisions separate so a storage block does not lock out keyboards.
Close DMA ports. Confirm Kernel DMA Protection reads ON in msinfo32 (or the equivalent IOMMU setting on other platforms) and set the enumeration policy for incompatible devices to match your risk.
Write the exception process. A time-bound exception with an owner and a device ID, never a group-wide allow. Record each one.
Plan rollback. Keep a tested policy that restores the previous state. Microsoft warns that applying prevent policies retroactively to critical classes such as disk drives or network adapters can make a machine unusable, so test retroactive options in a lab first.

How to verify it works

Test device kit: keep an unapproved storage drive, an approved encrypted drive, a composite device and a USB network adapter. After each policy change, connect each on a test host and confirm the expected result.
Reinstall check: without the retroactive option, Windows blocks only new installations. Uninstall the device, reconnect it and confirm it does not reinstall, as Microsoft's own test steps describe.
Event check: confirm blocked attempts produce telemetry: PnPDeviceBlocked and RemovableStoragePolicyTriggered in Defender's DeviceEvents, 6416 events in the Windows Security log, USBGuard decisions in its audit log.
DMA check: confirm the Kernel DMA Protection status and that the DMA Remapping Policy property of key drivers reads 2 (supported).

Metric	Example target (NHI Mgmt Group suggestion, not a standard)	Why it matters
Endpoints with a default-deny device policy enforced	Above 95% of in-scope endpoints	Coverage of the control
Endpoints with DMA protection on, where hardware supports it	100%	Closes the PCIe hot-plug path
Open device exceptions older than their expiry	Zero	Shows exceptions are not becoming permanent allows
Blocked device events reviewed per week	All high-risk classes (storage, network, HID on servers)	Blocked attempts are early warning
Test kit pass rate after each policy change	100%	Proves the policy does what it says

Limits, bypasses and failure patterns

Trusting descriptors: an allow rule for "keyboard class" admits any device that claims to be a keyboard. The Linux kernel documentation states class checks are the weakest form of verification and recommends cryptographic verification for real security. Prefer device instance IDs, serials or USBGuard hashes, and pair HID rules with detection of unexpected input devices on servers.
Blocking only storage: a policy limited to removable storage leaves HID injection, network adapters and DMA devices untouched. See the USB Drop Attacks Guide for the device types attackers use.
Admin override left on: the Windows setting "Allow administrators to override Device Installation Restriction policies" exempts local Administrators, so wide local admin rights undo the control.
Boot-time gap: Microsoft states Kernel DMA Protection does not protect during boot and does not cover FireWire, PCMCIA, CardBus or ExpressCard; firmware settings and BIOS passwords cover that window.
Servers and virtual hosts forgotten: check which operating systems each device control product supports; where servers are outside a product's documented scope, use OS-level policy or physical port control.
Policy drift: an approved list that grows with every helpdesk ticket ends as an allow-all. Review exceptions quarterly.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	SC-41 Port and I/O Device Access	Physically or logically disable or remove connection ports and I/O devices
NIST SP 800-53 Rev 5	MP-7 Media Use	Restrict or prohibit the use of types of system media
NIST CSF 2.0	PR.PS-01, PR.DS-01	Configuration management; protection of data at rest
MITRE ATT&CK	M1034 Limit Hardware Installation	The mitigation D3FEND relates to D3-IOPR
MITRE D3FEND	D3-AMED, D3-IOPR	Parent and technique

The parent technique is covered in the MITRE D3FEND Access Mediation Implementation Guide; the wider framework in the MITRE D3FEND Guide.

Practitioner checklist

Audit device connections (event 6416 or equivalent) before enforcing anything.
Allow by device ID, instance ID, serial or hash; avoid class-only allow rules.
Include hubs, host controllers and input devices in the allow list before default-deny.
Pilot in audit mode with a defined ring, then enforce.
Turn on IOMMU DMA protection and set the external enumeration policy.
Turn off administrator override where local admin rights are broad.
Keep a test device kit and run it after every policy change.
Time-bound every device exception and review the list quarterly.
Cover servers and OT workstations with OS-level or physical port controls.

D3-IOPR IO Port Restriction: Blocking Unapproved Devices and Proving the Block Holds