All terms
Hardware Root of Trust
A tamper-resistant hardware element (TPM, secure element, or fused boot ROM) that provides the foundational, unforgeable trust anchor for secure boot, attestation, and key storage.
Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed June 20, 2026
Definition
A hardware root of trust is a tamper-resistant hardware component, typically a Trusted Platform Module (TPM 2.0), a vendor secure element, an ARM TrustZone protected region, or one-time-programmable fuses holding immutable boot code and public keys, that serves as the anchor for all higher-level security guarantees. Because the hardware can't be replaced or reprogrammed by software running on the device, any chain of trust it certifies (secure boot, signature verification, attestation reports, key release) is rooted in a property an attacker can't change without physical access and specialized equipment. What the regulation says
FDA's 2023 Cybersecurity in Medical Devices guidance expects manufacturers to describe 'cryptographic key generation, storage, and lifecycle management.' IEC 81001-5-1 and AAMI SW96 expect tamper-resistant storage for security-critical keys. The HSCC Joint Security Plan lists hardware roots of trust as an expected architecture pattern.What this means in practice
On modern connected medical devices, every meaningful security claim, secure boot, signed-update verification, certificate-based device identity, remote attestation, full-disk encryption, terminates in a hardware root of trust. FDA premarket cybersecurity submissions are expected to describe the device's roots of trust and how cryptographic keys are protected at rest. Devices that store keys in flash or in software-only key stores cannot credibly claim the security capabilities FDA expects. Common pitfalls
- •Calling a software-only secure key store a 'root of trust', without hardware tamper resistance, it isn't.
- •Provisioning the same root keys across many devices in manufacturing, per-device unique keys are required for credible device identity.
- •Ignoring supply-chain attestation of the secure element itself, a compromised secure element undermines every claim above it.
Primary references
3 sourcesLink health: 1 verified 2 bot-blocked· last checked 2026-06-20
NIST·1Trusted Computing Group·1FDA·1
- 1NIST SP 800-193: Platform Firmware ResiliencyVerifiedNISTcsrc.nist.gov
- 2TPM 2.0 Library SpecificationBot-blockedTrusted Computing Grouptrustedcomputinggroup.org
- 3FDA - Cybersecurity for Medical DevicesBot-blockedFDAfda.gov
Inline markers like [1] jump to the matching reference above.