M0934: Limit Hardware Installation
Block users or groups from installing or using unapproved hardware on systems, including USB devices.
Analyst context for executives and security teams
Limit Hardware Installation is an ICS mitigation focused on preventing unapproved hardware, including USB devices, from being installed or used on systems. Its practical value is strongest in environments where control systems may be physically reachable or isolated from enterprise networks: removable media can become the bridge into systems that are otherwise not exposed online.
Executive priority
This control matters for operational resilience and audit readiness because it reduces a common pathway for malware or unauthorized tools to enter control environments through trusted users, suppliers, contractors, or routine maintenance activity. Leaders should ask whether hardware-use restrictions are policy-only or technically enforced, whether exceptions are governed, and whether evidence exists for standards-aligned controls referenced by ATT&CK, including IEC 62443 SR/EDR 3.2 and NIST SP 800-53 MP-7.
Technical view
For SOC, IR, and control-system defenders, validate whether systems can block or restrict unapproved USB and other peripheral hardware use, especially where removable media could enable Replication Through Removable Media (T0847). Because ATT&CK provides no official detection text for this mitigation and no platforms are specified, local architecture must drive validation: identify where removable media is allowed, where it is technically blocked, where exceptions exist, and whether security teams can reconstruct device insertion and use during an investigation.
Likely telemetry
- Endpoint or host logs showing removable device insertion, mounting, driver loading, or device installation events
- Asset and configuration records identifying systems where removable hardware is permitted or blocked
- Change, maintenance, supplier, or contractor access records tied to removable media use
- Policy enforcement logs from device-control or operating-system hardware restriction mechanisms, where present
- Incident response evidence such as file creation or execution from removable media paths, if collected
Detection direction
- Confirm whether telemetry exists for hardware insertion and use; do not assume visibility because ATT&CK provides no detection guidance for M0934.
- Tune monitoring around exceptions: engineering workstations, maintenance laptops, shared operator stations, and supplier/contractor workflows may generate legitimate removable-media activity.
- Correlate removable media events with file creation, execution, user identity, physical access, and maintenance windows to reduce false positives and support incident reconstruction.
- Validate coverage specifically for the related technique T0847, where removable media can move malware into systems separated from enterprise networks.
- Document blind spots where systems cannot log device activity or where logs are not forwarded to the SOC.
Mitigation priorities
- Start with an approved-hardware and removable-media policy that defines ownership, exception criteria, and operational break-glass handling.
- Technically block users or groups from installing or using unapproved hardware, including USB devices, where operationally feasible.
- Apply stricter controls to control-system assets and physically accessible systems that are isolated from untrusted networks but reachable by personnel or third parties.
- Govern supplier, contractor, and maintenance use of removable media with approval, scanning, chain-of-custody, and post-use review processes as locally appropriate.
- Maintain audit evidence showing enforcement status, approved exceptions, and periodic review to support IEC 62443 and NIST SP 800-53 MP-7-aligned compliance discussions.
Analyst notes and limits
The key decision point is whether removable hardware control is enforceable and observable, not merely documented. This mitigation is directly related to reducing Replication Through Removable Media in ICS environments, where physical access and trusted third-party workflows can undermine network isolation assumptions.
ATT&CK provides a concise mitigation description, no official detection guidance, no specified platforms, and limited relationship context. Environment-specific architecture, device-control capabilities, logging support, and operational constraints are required to determine actual coverage.
Limit Hardware Installation
Block users or groups from installing or using unapproved hardware on systems, including USB devices.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0847 | Replication Through Removable Media | Enforce system policies or physical restrictions to limit hardware such as USB devices on critical assets. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 02905b52f355… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0934Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.