M1034 Limit Hardware Installation: Blocking Rogue USB, Peripheral and Network Devices

Any device an attacker or careless insider can plug in is a path around network controls, email filtering and application allowlisting. MITRE ATT&CK mitigation M1034 Limit Hardware Installation covers the policies and technical controls that stop unapproved USB storage, keystroke injection devices, rogue network hardware and IP-based KVMs from being used. This guide reads M1034 from the ATT&CK point of view: which techniques it addresses in ATT&CK v20, how to prioritise and implement it, where it stops short and what covers the gap, and how to measure coverage. It is written for detection engineers, endpoint teams and security architects. Configuration depth for Windows removable storage lives in the Removable Media and USB Control Guide, which this page links rather than repeats.

Key takeaways

• Seven techniques, three attack paths. In ATT&CK v20, M1034 mitigates seven techniques and sub-techniques: removable media spread and exfiltration, input injection, hardware additions and remote access hardware.
• Storage blocking is only half of it. Keystroke injection devices and IP-KVMs are not storage, so a policy that only denies mass storage leaves T1674 and T1219.003 open.
• Default deny by device class, allow by ID. Block unknown device classes and allow approved devices by hardware ID or serial number; prevent rules should win over allow rules.
• Network hardware needs network controls. A rogue device on a switch port never touches the endpoint's device policy, so T1200 also needs M1035 Limit Access to Resource Over Network and asset inventory.
• Measure exceptions, not just blocks. The count and age of device exceptions, and the share of endpoints reporting device events, tell you more than the raw number of blocked devices.

What M1034 is

ATT&CK describes M1034 as preventing unauthorised users or groups from installing or using hardware such as external drives, peripheral devices or unapproved internal components, by enforcing hardware usage policies and technical controls. The ATT&CK text names five groups of measures: disabling USB mass storage and allowlisting approved devices by serial number through Windows device installation policies; endpoint device control that allows specific classes (keyboards, mice) and blocks others; BIOS/UEFI passwords and Secure Boot; restricting driver installation and Bluetooth or wireless pairing; and logging hardware installation events (ATT&CK cites Windows Event ID 20001 from Device Setup Manager) into a SIEM.

In practice M1034 is a device control programme with three layers:

• Port and bus layer: which device classes may enumerate at all (storage, HID, network adapters, Bluetooth, Thunderbolt or PCIe peripherals).
• Device identity layer: which specific devices are approved, identified by vendor and product ID, hardware ID, instance ID or serial number.
• Firmware layer: who can change boot order, enable ports in firmware or boot from external media.

MITRE D3FEND describes the same idea as IO Port Restriction (D3-IOPR), "limiting access to computer input/output (IO) ports to restrict unauthorized devices", supported by Hardware Component Inventory (D3-HCI).

Techniques M1034 mitigates in ATT&CK v20

The table lists every non-revoked technique linked to M1034 in the ATT&CK v20 Enterprise dataset, grouped by tactic, with ATT&CK's own usage text paraphrased and an NHI Mgmt Group priority based on how commonly the path is reachable in a typical enterprise.

Seven entries is a short list, but they matter more than the count suggests. T1200 and T1091 are initial access paths that bypass the perimeter entirely, T1674 gives code execution with the logged-on user's rights, and T1052.001 is the classic insider exfiltration path that network DLP never sees.

Implementation priorities

The order below puts the highest-coverage, lowest-disruption steps first. Platform detail for Windows policies, Defender device control and BitLocker To Go is in the Removable Media and USB Control Guide.

1. Inventory what is plugged in today. Collect device connection events for 2-4 weeks before enforcing anything. On Windows endpoints with Microsoft Defender for Endpoint, advanced hunting records PnPDeviceAllowed, PnPDeviceBlocked and RemovableStoragePolicyTriggered events; on Linux, USBGuard can generate an initial policy from currently attached devices. The output is your approved device list and your exception backlog.
2. Block removable storage write, then read. Deny write to USB mass storage for most users first (addresses T1052.001), then read and execute (addresses T1091). Keep a small allowlist of encrypted, organisation-issued drives by serial number.
3. Restrict device installation by class and ID. On Windows, the Device Installation Restrictions policies under Computer Configuration > Administrative Templates > System > Device Installation let you prevent installation by device setup class, hardware ID or instance ID. Microsoft documents that Prevent policies take precedence over Allow policies unless the "Apply layered order of evaluation" setting is enabled, in which case instance IDs override device IDs, which override setup classes, which override the removable device rule.
4. Treat new keyboards and network adapters as suspicious. Keystroke injection devices enumerate as human interface devices. On high-value systems (admin workstations, kiosks, build servers) restrict new HID and USB network adapter installations to approved IDs, and alert on any new HID that appears alongside another HID on the same host. USBGuard on Linux supports rules on device attributes, including interface class, for this purpose.
5. Lock the firmware. Set firmware administrator passwords, disable boot from external media, disable unused ports (Thunderbolt, ExpressCard, unused USB headers on servers) in firmware where the hardware allows it, and turn on Secure Boot. Firmware and boot integrity is covered more fully by M1046 Boot Integrity and the Linux Secure Boot and Shim Guide.
6. Restrict Bluetooth and wireless pairing. Disable Bluetooth on servers and fixed workstations that do not need it; on laptops restrict allowed Bluetooth services through device control or MDM.
7. Close the network side of T1200 and T1219.003. Enforce port authentication (802.1X) and DHCP registration so unregistered devices cannot talk to trusted systems, and sweep for IP-KVM devices on management networks. This is the M1035 half of the control; see the Network Access Control (NAC) Guide.

Testing and rollback

• Audit first: Defender device control supports audit entries that log without enforcing; USBGuard can run with a generated allow policy before switching the implicit target to block.
• Beware retroactive blocks: Microsoft warns that the "Also apply to matching devices that are already installed" option on Prevent policies can disable critical devices, for example blocking a whole Disk Drive or Net class can block the boot disk or network access. Pilot on a small ring with console access, and never apply a class-wide retroactive block fleet-wide in one step.
• Printers and docks: Microsoft notes that a device control Deny policy can block printers by default; add explicit allow entries for printers and approved docking stations before enforcing.
• Rollback: keep the enforcement setting as a single policy object or profile per ring so it can be reverted to audit in one change, and keep a documented break-glass procedure for locked-out kiosks and servers.

Choosing the right enforcement point

Small organisations: start with the built-in OS policy to deny removable storage write and unknown device classes through the MDM you already use, and keep the exception list in a ticketing system. Large organisations: use agent-based device control for reporting and per-group exceptions, ring-based rollout, and pair it with NAC so the network side of T1200 is covered.

What M1034 does not stop

• Devices that impersonate approved IDs. Vendor and product IDs, and in many cases serial numbers, are reported by the device itself. A purpose-built device can claim an approved identity, which is why HID controls on sensitive hosts should also watch for unexpected additional keyboards. Pair M1034 with M1038 Execution Prevention so injected keystrokes cannot launch unapproved code.
• Rogue hardware inside the network. A single-board computer or wireless access point plugged into a switch port does not touch any endpoint policy. Network access control and inventory are the controls; see M1035 Limit Access to Resource Over Network and M1030 Network Segmentation.
• Approved devices used for the wrong purpose. An authorised encrypted drive can still carry data out. Content-aware DLP and logging of file copies to removable media cover this.
• Implanted or supply chain hardware. Modified components inside a device are outside M1034's reach; procurement controls and firmware integrity checking address them.
• Software remote access. M1034 covers remote access hardware only; software remote access tools under T1219 need M1033 Limit Software Installation and network filtering.

Where identity fits

Device control is usually discussed for human users, but the highest-value targets are often hosts that run non-human identities. Build servers, CI runners, jump hosts and hypervisor management stations hold service account credentials, signing keys and cloud tokens; a keystroke injection device or a rogue network implant on one of these hosts reaches those credentials directly. Apply the strictest device policy (no removable storage, approved HID only, ports disabled in firmware) to hosts that store or use machine credentials. Hardware security keys and PKI tokens are themselves USB devices, so allowlist them explicitly by ID instead of opening the HID or smart card class; see the USB PKI tokens and eTokens guide.

A real example: an unauthorised device at NASA JPL

NASA's Office of Inspector General report IG-19-022 (June 2019) describes how, in April 2018, an attacker accessed the Jet Propulsion Laboratory network by targeting a Raspberry Pi that was not authorised to be attached to it, and took about 500 MB of data from 23 files. The report found JPL's IT security database incomplete and inaccurate and not consistently updated within the required 30 days, so devices could join the network without being identified and vetted; the intrusion went undetected for nearly a year. The lesson for M1034 is that hardware control is an inventory and approval process as much as a port setting: unknown devices need to be blocked or at least detected on first connection.

Detection and measurement

Metrics that show the control is working:

• Enforcement coverage: percentage of endpoints, by tier, with removable storage write blocked and device events reaching the SIEM.
• Exception count and age: active device exceptions, and the share older than their review date.
• Unknown device rate: blocked or audited unknown devices per 1,000 endpoints per month, trending down after the inventory phase.
• Time to detect a rogue network device: from first DHCP lease to alert, measured in planned tests.
• High-value host compliance: share of build servers, jump hosts and admin workstations on the strict device profile.

Test the control the way ATT&CK describes the techniques: in an authorised exercise, plug in an unapproved storage device, an extra keyboard and an unregistered network device, and confirm each is blocked or alerted within the expected time.

Framework mapping

Common failure patterns

• Storage-only policies. Blocking mass storage while leaving HID and USB network adapter classes open leaves T1674 untouched.
• Exceptions that never expire. A "temporary" allow for a whole user group or device class becomes permanent and quietly re-opens T1052.001.
• Servers left out. Device control agents that cover only client operating systems leave servers and build hosts, which hold the most valuable credentials, on default settings.
• No inventory behind the policy. As the NASA JPL case shows, unapproved devices persist when the asset record is incomplete and not reconciled.
• Retroactive class blocks pushed fleet-wide. A Prevent policy applied to already installed devices in a broad class can take down storage or networking on production hosts.

Practitioner checklist

• Collect 2-4 weeks of device connection telemetry before enforcing.
• Deny removable storage write for all users without an approved exception; then deny read and execute.
• Allowlist organisation-issued encrypted drives and hardware security keys by ID or serial number.
• Restrict new HID and USB network adapters on admin workstations, jump hosts, build servers and kiosks.
• Set firmware passwords, disable external boot and unused ports, and enable Secure Boot.
• Enforce 802.1X or equivalent so unregistered devices cannot reach trusted networks, and sweep management networks for IP-KVMs.
• Forward device installation and device control events to the SIEM and alert on unknown devices on high-value hosts.
• Review device exceptions quarterly with an owner and an expiry date.
• Test with an authorised unapproved device each quarter and record time to block or alert.

Standards and references

• MITRE ATT&CK: M1034 Limit Hardware Installation
• MITRE ATT&CK: T1200 Hardware Additions
• MITRE D3FEND: IO Port Restriction
• NIST: SP 800-53 Rev. 5
• Microsoft Learn: Manage Device Installation with Group Policy
• Microsoft Learn: Device control in Microsoft Defender for Endpoint
• USBGuard project: USBGuard
• NASA Office of Inspector General: Cybersecurity Management and Oversight at the Jet Propulsion Laboratory (IG-19-022)

Related NHI Mgmt Group resources: Removable Media and USB Control Guide · USB Drop Attacks Guide · Network Access Control (NAC) Guide · MITRE ATT&CK T1674 Input Injection · M1035 Limit Access to Resource Over Network