T1195.003: Compromise Hardware Supply Chain
Adversaries may manipulate hardware components in products prior to receipt by a final consumer for the purpose of data or system compromise. By modifying hardware or firmware in the supply chain, adversaries can insert a backdoor into consumer networks that may be difficult to detect and give the adversary a high degree of control over the system. Hardware backdoors may be inserted into various devices, such as servers, workstations, network infrastructure, or peripherals.
Analyst context for executives and security teams
Hardware supply chain compromise matters because the initial access may be built into a device before the organization ever receives it. For leaders, the practical risk is that servers, workstations, network infrastructure, or peripherals could arrive with modified hardware or firmware that is hard for normal endpoint or network monitoring to see. This makes procurement assurance, asset intake, firmware/boot integrity, and incident response readiness part of the security control surface—not just IT operations.
Executive priority
Treat this as a high-consequence, lower-visibility initial access risk. The key business question is whether critical hardware entering the environment can be trusted, verified, and monitored over its lifecycle. Prioritize controls and evidence around supplier assurance, secure intake processes, boot integrity, firmware integrity, and documented response procedures for suspected tampering. This is especially relevant for resilience planning and audit evidence where critical systems depend on trusted hardware foundations.
Technical view
ATT&CK lists this as an initial-access sub-technique under Supply Chain Compromise for Linux, macOS, and Windows environments. MITRE provides no native detection text for this technique, but the relationship context identifies DET0368: Hardware Supply Chain Compromise Detection via Host Status & Boot Integrity Checks, and mitigation M1046: Boot Integrity. SOC, detection engineering, and IR teams should validate whether host status, secure boot state, firmware/boot integrity signals, and hardware inventory baselines are actually collected and reviewed for critical systems. Because the suspected manipulation may occur before receipt, detection should emphasize deviations from known-good baselines and boot/integrity failures rather than only post-compromise behavior.
Likely telemetry
- Hardware and asset inventory records for servers, workstations, network infrastructure, and peripherals
- Procurement, receipt, chain-of-custody, and asset intake records
- Firmware version, configuration, and update history where available
- Secure boot or boot integrity status
- Host health/status and runtime integrity check results
Detection direction
- Validate whether DET0368-style host status and boot integrity checks are deployed on systems where hardware trust is material.
- Tune for unexpected secure boot changes, boot integrity failures, firmware drift, or unexplained hardware/firmware configuration differences from approved baselines.
- Correlate technical anomalies with procurement and asset intake records; a device that is anomalous at first boot is different from one that drifted after deployment.
- Expect blind spots where firmware, peripheral state, or hardware provenance is not inventoried or where endpoint tools cannot inspect below the operating system.
- Avoid over-reliance on conventional malware alerts; this technique may not initially present as ordinary file, process, or network activity.
Mitigation priorities
- Start with supplier and asset intake assurance for critical hardware, including documented provenance and acceptance checks.
- Implement Boot Integrity controls where supported, including secure boot mechanisms, hardware-rooted trust, and runtime integrity checks as described by M1046.
- Maintain known-good baselines for firmware, boot configuration, and hardware inventory on critical Linux, macOS, and Windows systems.
- Require controlled firmware and boot configuration change management with evidence retained for audit and incident response.
- Prepare IR playbooks for suspected hardware or firmware tampering, including isolation, preservation of evidence, and replacement decisions.
Analyst notes and limits
This technique is materially different from many initial-access behaviors because compromise can precede enterprise deployment. Glexia would use this object to drive conversations between security, procurement, infrastructure, compliance, and incident response teams: which hardware is business-critical, what trust evidence is required before use, and what telemetry would reveal integrity failure after deployment.
MITRE does not provide official detection guidance for this object. The supplied relationship context only identifies one detection strategy name and Boot Integrity mitigation; it does not provide implementation details, vendor coverage, prevalence, attribution, or active exploitation evidence. Local architecture, supplier processes, firmware visibility, and platform capabilities determine practical coverage.
Compromise Hardware Supply Chain
Adversaries may manipulate hardware components in products prior to receipt by a final consumer for the purpose of data or system compromise. By modifying hardware or firmware in the supply chain, adversaries can insert a backdoor into consumer networks that may be difficult to detect and give the adversary a high degree of control over the system. Hardware backdoors may be inserted into various devices, such as servers, workstations, network infrastructure, or peripherals.
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.
Related techniques
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 |
|---|---|---|---|
| Enterprise | T1195 | Supply Chain Compromise | This object subtechnique of Supply Chain Compromise. |
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | 4ee46c09cee0… |
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 T1195.003Open 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.