What Is a Hardware Root of Trust?

Every cryptographic key an organization relies on has to be generated and stored somewhere. If a software keystore runs on the same server as the application it protects, the key is only as safe as the operating system around it. A single breach of that server is enough to expose it.

A hardware root of trust moves that key generation and storage into a dedicated physical boundary, commonly a hardware security module (HSM) or a trusted platform module (TPM), built specifically to resist extraction, even from someone with direct physical access to the device.

Generally, a root of trust is simply the source a cryptographic system trusts by default. With hardware, that trust can be checked rather than just assumed. Encryption, digital signatures, secure boot, and certificate issuance all depend on that hardware boundary staying secure.

Hardware protection comes in more than one form and choosing the wrong one might mean compliance gaps and unexpected exposure.

Key Takeaways

• Software-based key storage, protected only by operating system access controls, remains exposed to privileged attackers and malware with direct memory access.
• Private keys generated and held inside dedicated, tamper-resistant hardware, such as an HSM or TPM, stay protected even if the server around them is fully compromised.
• Regulators and auditors evaluate hardware root of trust implementations against FIPS 140-3 and Common Criteria, with physical tamper resistance as the practical enterprise baseline.
• Public key infrastructure (PKI) root certificate authorities, code signing, payment processing, and cloud key management all depend on a hardware root of trust, which is also the infrastructure the post-quantum transition runs on.
• Entrust nShield HSMs cover the full range of hardware root of trust use cases (from PKI and code signing to post-quantum-ready key management) with FIPS 140-3 validation and more than 150 documented integrations.

Hardware Root of Trust vs. Software Root of Trust

Software-based keystores are a practical choice for many environments, but for regulated workloads and sensitive key operations, they often fall short.

An attacker who gains elevated access to such a host can read the key directly. That same attacker facing a hardware-based root of trust cannot extract the key, because it never enters host memory.

Software-based key storage still has a place in development environments and low-sensitivity workloads, along with systems where hardware deployment isn't feasible. Organizations should scope those exceptions deliberately and keep regulated and high-value data on hardware.

Types of Hardware Root of Trust

Hardware roots of trust come in three main forms: HSMs, TPMs, and secure enclaves all anchor trust in hardware, but they differ in scope and assurance level.

Hardware Security Modules (HSMs)

Hardware security modules (HSMs) are tamper-resistant devices designed for enterprise-scale cryptographic operations. Validation against the Federal Information Processing Standard (FIPS) 140-3 and Common Criteria means they meet the assurance standards regulated industries rely on.

HSMs protect the keys that carry the most risk if compromised:

• PKI root certificate authority keys
• Transport Layer Security (TLS) session keys
• Code signing keys
• The encryption keys behind payment card data and cloud storage
• Organizations deploy them wherever the workloads run, as on-premises appliances, cloud HSM-as-a-service, or network-attached hardware.

Trusted Platform Modules (TPMs)

Trusted platform modules (TPMs) are standardized by the Trusted Computing Group and embedded directly into laptops and servers. A TPM attests to the boot process and stores the keys behind disk encryption. That makes it a device-level trust anchor, built for endpoint and platform security, while HSMs handle enterprise-wide key management.

Secure Enclaves

Secure enclaves, like Intel Software Guard Extensions (SGX) and ARM TrustZone, carve out an isolated execution environment inside the processor for sensitive operations. They fit mobile and cloud-native use cases in which deploying dedicated HSM hardware isn't practical. Enclaves carry a lower assurance level than a FIPS-validated HSM, which makes them a fit for app-level protections while enterprise key management stays with dedicated hardware.

How HSMs Serve as a Hardware Root of Trust

An HSM establishes trust through a set of hardware-enforced controls that operate independently of the host system:

• Key generation: A hardware-based true random number generator (TRNG) creates key material inside the module using its own certified entropy source, independent of the host.
• Key storage: Private keys stay in tamper-protected memory inside the HSM. Every access request goes through the HSM's own authentication layer, so OS-level compromise alone cannot expose the key.
• Cryptographic operations: Signing, encryption, and key derivation all run inside the HSM. The host sends a request and receives the finished result while the key stays inside the module.
• Tamper evidence and response: FIPS 140-3 Level 3 modules detect physical tampering and zero the key material in response. Level 4 extends that protection to environmental attacks like voltage or temperature manipulation.
• Role-based access control: Sensitive operations, like loading a root CA private key, require a quorum of authorized administrators to act together before the operation proceeds.
• Audit logging: Every operation on a managed key is timestamped, attributed to a user, and recorded in a tamper-evident log that a dedicated audit role can review.
• Secure boot anchor: The same hardware boundary can hold the signing keys that validate firmware and software at each stage of the boot process, before anything is allowed to execute.

Hardware Root of Trust Use Cases

A hardware root of trust is required or strongly recommended when a compromised key could invalidate an entire trust hierarchy, authorize malicious code, expose payment systems, or weaken control over cloud encryption. That risk is especially high in government, healthcare, financial services, and enterprise environments.

PKI and Certificate Authority Protection

The root CA private key is the most sensitive key in any government or enterprise PKI. If it's compromised, the certificate hierarchy it anchors becomes untrustworthy, along with everything that hierarchy has signed. As certificate lifespans shrink and regulatory scrutiny increases, hardware protection for this one key is the baseline requirement for any credible PKI deployment.

Code Signing

Code signing keys confirm that software came from the source it claims to. If an attacker gets hold of one, they can distribute malicious software under a legitimate signature, with no further access required. Protecting those keys in dedicated hardware has become a standard expectation in software supply chain security programs.

Secure Boot

Secure boot uses a hardware root of trust to check firmware and software integrity before anything executes. An HSM or TPM holds the signing keys that validate each stage of the boot process, from firmware through the operating system loader. If that hardware anchor is compromised, every validation step above it still reports success, so the failure goes undetected.

Payment and Financial Systems

Payment HSMs protect the keys behind PIN encryption, card transaction processing, and payment network communication. The Payment Card Industry (PCI) HSM standard sets the requirements, and a May 2026 update extended them to cloud and multi-tenant HSM deployments and added post-quantum readiness criteria. For financial services, PCI HSM compliance is a mandate, verified during every assessment.

Cloud Key Management (BYOK and HYOK)

Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK) models let organizations and institutions generate and hold their own cloud encryption keys instead of delegating that to the provider. Both depend on a hardware root of trust, typically an on-premises or customer-controlled HSM, so the root encryption key never resides solely inside the provider's infrastructure.

Compliance and Standards for Hardware Root of Trust

FIPS 140-3 is the primary U.S. and Canadian standard for validating cryptographic modules, with validation run jointly by the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security. It defines four assurance levels, with the right level depending on the sensitivity of the key material and the applicable regulatory framework:

• Level 1: Permits software-only implementations with no dedicated hardware
• Level 2: Requires tamper evidence and role-based authentication
• Level 3: Adds identity-based authentication and physical tamper resistance, and is where most enterprise HSM deployments are validated
• Level 4: Adds protection against environmental attacks like voltage and temperature manipulation

NIST SP 800-57 sets the general baseline for key management practice, recommending hardware-based storage for high-value keys within its broader guidance.

In two sectors this recommendation is mandatory: Payment environments must meet the PCI HSM standard under PCI Data Security Standard (DSS), and government and defense procurement typically requires Common Criteria evaluation, built on ISO/IEC 15408, with evaluation assurance levels (EAL) like EAL4+ as a contractual condition.

National security systems face the strictest requirements of all. The National Security Agency's (NSA) Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets a higher bar than NIST's general guidance, requiring hardware-backed operations and exclusive use of quantum-resistant signing algorithms by 2030.

Hardware-backed key management also supports regulations that never mention hardware directly. The General Data Protection Regulation (GDPR) doesn't specify HSMs, but this is one established way to meet its accountability and data residency requirements.

In Europe, hardware key management falls under two regulatory frameworks: NIS2 and eIDAS.

The NIS2 Directive (Directive 2022/2555), enforceable across EU Member States since October 2024, mandates cryptography and encryption as a baseline security measure under Article 21, with ENISA guidance explicitly framing hardware-based key storage as an expected control.

The eIDAS Regulation requires that qualified electronic signatures be stored on a qualified signature creation device (QSCD), a category that includes cloud-based HSMs, making hardware protection a hard legal requirement for any trust service provider operating in the EU.

Hardware Root of Trust and Post-Quantum Cryptography

Some of the algorithms a hardware root of trust protects today won't survive quantum computing. NIST and the NSA have set 2030 for deprecating RSA and ECC and 2035 for disallowing them.

Meeting that deadline depends less on the algorithms themselves, which are already finalized, than on whether the hardware protecting them can be upgraded to run them.

Organizations running field-upgradable, crypto-agile HSM infrastructure can add new algorithm support through firmware and software updates as standards evolve, but those running fixed-function hardware face a full reprocurement cycle with no firmware shortcut. This means procurement planning needs to start now.

Support for these algorithms is arriving inside the same hardware boundary that protects today's keys, though full FIPS 140-3 validation for PQC-specific implementations is still rolling out across HSM vendors.

Choosing a Hardware Root of Trust for Your Organization

Choosing a hardware root of trust comes down to security assurance and operational fit. The following criteria determine whether the platform can protect critical key operations across the environment and over time:

• Assurance level: FIPS 140-3 Level 2 is the practical minimum for enterprise, though most deployments target Level 3; Level 4 is reserved for high-sensitivity and government use cases.
• Deployment model: On-premises appliances, cloud HSM-as-a-service, and network-attached hardware trade off differently on control and operational overhead.
• Upgrade path: Field-upgradable, crypto-agile HSMs hold up better against the post-quantum migration timeline than fixed-function hardware.
• Integration: A hardware root of trust that can't connect to existing infrastructure leaves key operations outside the hardware protection the rest of the environment depends on.

Entrust's nShield HSMs are built to meet all four criteria at once. They are FIPS 140-3 Level 3 validated; deploy on premises, in the cloud, or hybrid; use a programmable FPGA architecture for in-field algorithm updates; and connect to more than 150 partner integrations.

FAQs

What is a hardware root of trust?

A hardware root of trust is a dedicated physical component, such as an HSM or TPM, that generates and protects cryptographic keys inside hardware designed so those keys cannot be read out, even by someone with direct physical access. Every downstream cryptographic operation inherits its trustworthiness from that hardware.

How does a hardware root of trust work?

Keys are generated inside the hardware using a certified random number source and never leave in plaintext. Cryptographic operations happen inside the module, so the connected system receives the finished result while the key stays inside. Physical tamper detection protects the hardware from extraction attempts.

What is the difference between a hardware and software root of trust?

Software-based keys rely on operating system access controls alone, which a privileged attacker or malware with system access can potentially bypass. Hardware-protected keys are held inside a physical boundary that requires compromising specialized tamper-resistant hardware.

What are common hardware root of trust use cases?

PKI root certificate authority protection, code signing, secure boot, payment processing under the PCI HSM standard, and cloud key management through BYOK and HYOK models are the most common, each relying on hardware to hold the private key while the rest of the system uses it without direct access.

Can a hardware root of trust support cloud environments?

Yes, cloud HSM services, or HSM-as-a-service, deliver the same hardware-backed protection as an on-premises appliance. BYOK and HYOK models let organizations keep control of their root encryption keys even in a public cloud, which helps satisfy data residency requirements.

How does a hardware root of trust help with regulatory compliance?

FIPS 140-3, Common Criteria, PCI DSS, and NIST SP 800-57 either require or strongly recommend hardware-based key protection, depending on the industry and data sensitivity. Government and defense procurement typically requires Common Criteria evaluation; payment environments require PCI HSM validation.