Security teams detect disabling crypto hardware by monitoring changes that turn off TPM, HSM or other hardware-backed protections, and by alerting on firmware, boot and policy changes that reduce cryptographic assurance. Investigate sudden loss of hardware-backed key usage, attestation failures and unexpected fallback to software-only encryption or signing paths.
What disabling crypto hardware looks like in telemetry
Detection starts with watching for the state changes that matter most: TPM disablement, HSM policy changes, firmware updates that weaken trust anchors, and boot or platform configuration changes that remove hardware-backed assurance. Teams should treat these as security-relevant events because they often change the trust path, not just the implementation detail.
A useful detection pattern is to compare normal hardware-backed usage against current behaviour. When devices or services suddenly stop producing attestations, stop using hardware-backed keys, or begin falling back to software-only crypto, that is often the first observable sign that the protection has been reduced or bypassed.
For defenders who need a threat-detection baseline, the MITRE ATT&CK Guide for Defenders is useful for mapping those telemetry shifts to detection logic and response coverage, especially where firmware, boot, and configuration changes precede loss of assurance.
Signals that separate normal change from weakening assurance
Not every crypto-related change is suspicious. The practical question is whether the change preserves the same trust properties. A legitimate firmware upgrade may be acceptable, but a change that disables measured boot, changes attestation settings, or removes access to a hardware root of trust should be treated as a control-impacting event.
Teams should correlate several signals rather than relying on a single alert. Sudden attestation failure, unexpected key migration out of protected hardware, altered device inventory, and an increase in software-based signing or encryption calls are stronger indicators together than any one of them alone.
For hardware-backed key custody and recovery pathways, the Crypto Wallet Security Guide is a useful analogue for understanding why hardware dependency matters, even when the exact platform is not a wallet.
How to investigate and confirm the cause
Once a weakening pattern appears, confirm whether the change was deliberate, accidental, or malicious. Check firmware update records, boot logs, configuration management history, remote administration actions, and any policy changes that could disable TPM, HSM, or related protections. The key question is whether the system is still proving the same cryptographic trust boundary it had before.
If the system is supposed to rely on hardware-backed keys, verify that attestation still succeeds, that expected modules are present and enabled, and that no unapproved fallback path has been introduced. If the hardware is missing, disabled, or no longer trusted, you should assume the cryptographic posture has changed until proven otherwise.
For incident handling and response workflow around security-control tampering, the EDR Evasion and Defence Guide is a useful reference point because the same operational problem appears when an attacker tries to blind a control rather than break it directly.
Risk and Threat Considerations
Disabling crypto hardware is dangerous because it can quietly reduce the assurance of keys, signatures, and device identity without breaking the application outright. That makes the change attractive for persistence, tampering, and stealth, especially where defenders assume the hardware trust anchor is still active.
Failure mechanism: The protection fails when firmware, boot settings, policy enforcement, or administrative access remove the hardware-backed path and the system silently accepts software-only crypto or unauthenticated trust decisions instead.
Impact: Attackers can gain a weaker signing or encryption environment, increase the chance of key theft or replay, and undermine attestation-based detection, which can expose higher-value systems to undetected compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1552 — Unsecured Credentials | Hardware crypto disablement can expose or bypass protected credential material. |
| T1547 — Boot or Logon Autostart Execution | Boot and firmware changes can weaken trust anchors before the system fully loads. | |
| Recommendation — Map fallback paths and tamper events to credential-access detections and hunt for exposed key material. Monitor boot-chain changes and alert when startup trust settings diverge from baseline. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on logging firmware, boot, policy, and attestation failures. |
| Recommendation — Centralise and review logs for hardware, boot, and policy changes that reduce cryptographic assurance. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Audit analysis is needed to spot control tampering and unexpected crypto fallback. |
| CM-6 — Configuration Settings | Disabled TPM, HSM, or boot protections are configuration changes that weaken assurance. | |
| Recommendation — Correlate audit records for attestations, firmware events, and configuration changes. Baseline hardware-backed crypto settings and alert on any unauthorized deviation. | ||
Practitioner Guidance
What to verify: Make hardware-backed state part of your detection content, not just your asset inventory. The alert should answer whether the device or service still uses the expected trust anchor, not only whether a configuration item changed.
Decision rule: If a system that should use TPM or HSM suddenly falls back to software crypto, treat that as a security incident until the cause is explained and the original assurance level is restored.
What practitioners underestimate: Loss of crypto hardware assurance is often operationally quiet. Systems may continue to function normally while the trust model has already weakened, so alerting must focus on assurance loss, not service outage.
Practitioner takeaway: The best detection strategy is to watch for trust degradation, not just failures, because attackers and misconfigurations alike often succeed by making strong cryptography behave like ordinary software crypto without triggering obvious breakage.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org