HSM vs TPM vs Secure Enclave: Hardware Key Protection

Hardware security modules, Trusted Platform Modules and secure enclaves all keep private keys away from ordinary software, yet they protect different things against different attackers, and picking the wrong one leaves a gap that no amount of policy closes. An HSM is a shared, network-attached or cloud service that guards high-value organisational keys such as CA roots and signing keys. A TPM is a chip, or firmware function, bound to one computer that anchors that machine's identity and boot integrity. A secure enclave is an isolated subsystem inside a phone or laptop system-on-chip that protects keys belonging to one user on one device. This guide compares them by threat model, key ownership, certification, use case and cost, with a worked scenario each. It is for security architects, PKI owners and endpoint and mobile engineers.

Key takeaways

Scope decides the choice. An HSM protects keys the organisation shares across many systems; a TPM protects keys that belong to one machine; a secure enclave protects keys that belong to one user on one device.
All three stop key copying, none stops key misuse. Malware on the host can usually ask the hardware to sign, so authorisation, user presence and logging still matter.
Certification differs by class. HSMs are bought on their FIPS 140-3 certificate and security policy; TPMs and mobile enclaves are judged mostly through attestation and platform documentation, so check which evidence a regulation or contract actually accepts.
Attestation is what makes device keys trustworthy to others. A TPM or enclave key is only useful to a CA or relying party if it can prove, through key attestation, that the key was generated in hardware and cannot be exported.
Recovery drives cost. HSM keys can be backed up under ceremony; TPM and enclave keys die with the device, so design for re-enrolment.

The short answer

Use an HSM (dedicated appliance, single-tenant cloud HSM, or a cloud KMS backed by validated HSMs) when a key is an organisational asset used by services: root and issuing CA keys, code signing keys, payment keys, token signing keys and master keys for envelope encryption. Use a TPM when a key must be tied to a specific computer: device certificates, machine credentials for Wi-Fi, VPN and mutual TLS, disk encryption keys sealed to boot state, and Windows Hello for Business keys. Use a secure enclave (Apple Secure Enclave, Android StrongBox or TEE-backed Keystore) when a key belongs to a person on a mobile device or laptop: passkeys, app-level signing keys, payment tokens and biometric-gated secrets. Many architectures use all three: the HSM holds the CA key that certifies TPM-protected machine keys and enclave-protected user keys. For the layers above the HSM, see Secrets Manager vs KMS vs HSM.

Side-by-side comparison

Property	HSM	TPM	Secure enclave
Where it lives	Network appliance, PCIe card, USB token or cloud service	Discrete chip on the motherboard, or a function integrated into the processor or firmware	Dedicated subsystem inside the phone or laptop system-on-chip
Whose keys	Organisation's shared keys	The machine's keys (and user keys bound to that machine)	One user's keys on one device
Key ownership and admin	Security officers and crypto officers with HSM-local roles, often quorum-controlled	Platform owner (Windows initialises and takes ownership of the TPM automatically); applications create keys under its hierarchy	Device and app; the platform vendor controls the enclave firmware, the app controls key policy at creation
Key export and backup	Non-exportable keys stay inside; wrapped backup to another HSM of the same family under ceremony	Non-exportable by design; keys bound to that TPM	Apple: keys cannot be imported or exported. Android: keys stay in secure hardware when bound to it
Algorithms	Broad: RSA, ECC, AES, HMAC and more, per the security policy	Defined by the TCG TPM 2.0 library and the chip; typically RSA and ECC, limited throughput	Apple: NIST P-256 only. Android StrongBox: RSA 2048, AES 128 and 256, ECDSA and ECDH P-256, HMAC-SHA256, Triple DES
Throughput	High, built for server workloads	Low, built for occasional operations	Low to moderate, built for interactive use
Main assurance evidence	FIPS 140-3 certificate and security policy; Common Criteria where required	Endorsement key certificate, key attestation, measured boot	Platform key attestation and vendor platform security documentation
Typical attacker it resists	Insider or intruder on application servers who wants to copy a master key	Malware or thief who wants to clone the machine's identity to another device	Compromised OS kernel or app that wants to extract the user's key
What it does not stop	Authorised callers misusing the key	Malware on the same booted machine using the key	A compromised app using its own key while the device is unlocked

HSM: threat model, architecture and failure modes

Architecture in words: applications reach the HSM over a network or bus through PKCS#11, JCA/JCE, Microsoft CNG and KSP, or a cloud KMS API. Keys are generated inside the module boundary and used there; the caller sends data and receives a signature, ciphertext or plaintext. Administration is separated into roles (security officer, crypto officer, crypto user) with authentication at the module, often requiring a quorum of smart cards for sensitive changes. Operational detail is in the HSM Deployment and Operations Guide.

Threat model: the HSM assumes the servers around it may be compromised. It protects against an attacker reading key material from disk, memory or backups, and against physical tampering at the higher FIPS 140-3 levels. ATT&CK describes the theft it prevents as T1552.004 Private Keys and, for PKI, T1649 Steal or Forge Authentication Certificates.

Failure modes: an over-privileged application credential lets an intruder sign anything (the key is safe, the signatures are not); the HSM client credential or partition PIN sits in a configuration file; a single HSM with no tested backup becomes a single point of loss; and key ceremonies drift into one person holding every card.

Controls: one partition per application, least-privilege crypto user credentials held in a secrets manager, quorum for export and role changes, and a tested restore to a second module.

Worked scenario: a software vendor must keep its code signing key in hardware. The CA/Browser Forum Code Signing Baseline Requirements (section 6.2.7.4.1) require that, for certificates issued on or after 1 June 2023, subscriber keys are generated and protected in a hardware crypto module certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, a cloud key protection service that keeps the key in such a module with access logging, or a qualifying signing service. A TPM in one build server would tie signing to a single machine with no recovery path. The right answer is a cloud HSM-backed key or a network HSM, with the build pipeline authenticating through a federated workload identity and every signing call logged. See the Code Signing Security Guide.

TPM: threat model, architecture and failure modes

Architecture in words: the TPM is defined by the Trusted Computing Group TPM 2.0 Library specification, also published as ISO/IEC 11889. Microsoft describes it as a secure crypto-processor with physical mechanisms that make it tamper-resistant, able to generate, store and limit the use of keys. Each TPM holds an endorsement key whose private half never leaves it, and a storage hierarchy that wraps application keys so they can only be loaded back into the same TPM. Keys can be sealed to platform measurements recorded during measured boot, so they unwrap only when the machine booted the expected firmware and operating system. Implementations range from a discrete chip to firmware TPMs and processor-integrated designs such as Microsoft Pluton, which Microsoft documents as able to provide TPM functionality when configured as the system TPM.

Threat model: the TPM resists credential cloning. A device certificate whose key lives in the TPM cannot be copied to an attacker's laptop, which defeats stolen-certificate replay. Sealing protects disk encryption keys against offline attacks on a removed drive. Windows also applies dictionary attack protection: on TPM 2.0 systems Windows configures the TPM to lock after 32 authorisation failures and to forget one failure every 10 minutes.

Failure modes: malware running on the booted machine can still use the TPM key, so a TPM-backed VPN certificate does not stop an attacker who already controls the endpoint; certificate templates that allow key export quietly fall back to software keys; CAs issue "TPM" certificates without checking attestation; and firmware updates or motherboard replacement break sealed keys without a re-enrolment plan.

Controls: require key attestation at enrolment, combine the machine certificate with user authentication and device health signals, record which issuance policy each certificate carries, and keep a recovery key for sealed disk encryption in escrow. For Windows estates, Active Directory Certificate Services supports TPM key attestation with three trust models: an administrator-managed list of endorsement public keys (high assurance, issuance policy OID 1.3.6.1.4.1.311.21.30), validation of the endorsement key certificate chain (medium, .31), and trust on the user's credentials (low, .32). Microsoft documents that this attestation works only for RSA keys, is not supported on a standalone CA, and requires the template to disallow private key export.

Worked scenario: a company wants to stop attackers using stolen VPN certificates. It moves machine certificates to the Microsoft Platform Crypto Provider, sets key attestation to Required on the template, starts with the endorsement certificate model for scale, and adds the endorsement key list for privileged administration workstations. The gateway accepts only certificates carrying the attestation OID. See the Hardware key attestation guide and, for constrained devices, the IoT Device Identity with TPM and DICE Guide.

Secure enclave: threat model, architecture and failure modes

"Secure enclave" here means a dedicated security subsystem inside a mobile or laptop system-on-chip. Platforms are listed alphabetically; order is not a ranking.

Apple Secure Enclave: Apple's platform security documentation describes a dedicated subsystem in the system-on-chip designed to keep sensitive data secure even when the application processor kernel is compromised. It has its own processor, runs from protected memory with an encrypting and authenticating memory engine, and holds a per-device UID key generated by its own random number generator during manufacturing. Hardware keys stay in its AES engine and public key accelerator, and software can request operations but cannot extract them. Developers create keys with kSecAttrTokenIDSecureEnclave; Apple's developer documentation states the enclave works only with NIST P-256 keys, cannot import pre-existing keys, and only the enclave that created a key can use it.
Google Android Keystore and StrongBox: Android documentation states key material never enters the app process and can be bound to secure hardware, a Trusted Execution Environment (TEE) or a secure element. StrongBox, available from Android 9 (API level 28), denotes implementations in an embedded secure element or integrated secure enclave, with its own CPU, secure storage, a true random number generator and a secure timer. Developers request it with setIsStrongBoxBacked(true) and can confirm placement through KeyInfo.getSecurityLevel(), which reports TRUSTED_ENVIRONMENT or STRONGBOX. Google notes StrongBox is slower and supports fewer concurrent operations, and that most apps do not need it.

Threat model: the enclave assumes the main operating system may be compromised and keeps user keys out of reach of malware, debuggers and forensic extraction. Both platforms let the app bind key use to user authentication: Apple through access control flags such as biometryAny, Android through setUserAuthenticationParameters() with time-based or per-operation authorisation. Android documents that key authorisations cannot be changed after creation and that secure hardware usually does not enforce time-window limits because it lacks a secure real-time clock.

Failure modes: keys without user authentication let a compromised app sign silently; servers that skip attestation let an emulator pass as a phone; and an app requests StrongBox for an unsupported algorithm and falls back to software without logging it (Android throws StrongBoxUnavailableException, which must be handled deliberately).

Worked scenario: a bank's mobile app signs payment approvals. It generates a P-256 key in the enclave on both platforms, requires biometric or device credential authentication per operation, sends the attestation chain at registration, and the server stores the public key against the customer and device. A new phone means a new key and a fresh registration, not a restore. For user authentication with platform keys see Device-Bound Passkeys.

Certification: what each class can show

FIPS 140-3, published by NIST on 22 March 2019, defines four increasing security levels for cryptographic modules and covers physical security, non-invasive attacks, sensitive security parameter management and self-tests. The Cryptographic Module Validation Program, run by NIST and the Canadian Centre for Cyber Security, states that FIPS 140-2 validated modules can be accepted through 21 September 2026, after which they move to the Historical list and may be used only in existing systems. As of November 2026, new procurement should therefore ask for a FIPS 140-3 certificate. Read the certificate's security policy, not just the level. See the FIPS 140-3 and Cryptographic Module Validation Guide.

Evidence	HSM	TPM	Secure enclave
FIPS 140-3 certificate	Standard procurement evidence; check level and approved mode	Some TPM products hold certificates; check the exact part and firmware on the CMVP list	Check the CMVP list for the specific platform module and version before claiming it
Common Criteria	Often required for qualified signature and payment use	Check the specific product certificate	Check the platform vendor's published certifications
Key attestation	Vendor-specific key attestation statements on many products	Endorsement key certificate and TPM key attestation	Apple and Android platform key attestation chains
Accepted for CA/B Forum code signing keys	Yes, at FIPS 140-2 Level 2 or EAL 4+ or above	Only if the specific module carries a qualifying certification	Only if the specific module carries a qualifying certification

Key ownership and lifecycle

Who can use: HSM keys are used by any authorised caller across the network, so caller identity is the control. TPM and enclave keys are used only on that device, so device and user authentication is the control.
Backup and recovery: HSM keys can be cloned or wrapped to another module of the same family under a documented ceremony. TPM and enclave keys are designed to be unrecoverable outside the device. Design for re-issue: short certificate lifetimes, automated enrolment and a revocation path. NIST SP 800-57 Part 1 Rev. 5 covers key states and lifecycle in detail.
Destruction: TPM keys disappear when the TPM is cleared, enclave keys when the app or device is wiped. Revoke the certificate at the same time.

For machine identities, a TPM-bound key suits per-host identity; a service identity running on many hosts needs an HSM or KMS-held key, or better, short-lived federated credentials. See the Cryptographic Key Management Guide.

Use cases mapped

Use case	Best fit	Why
Offline root CA and online issuing CA keys	HSM	High-value shared key, ceremonies, backup, quorum control. See the Enterprise PKI Design and CA Hierarchy Guide
Code signing and release signing	HSM or cloud HSM-backed key	CA/B Forum hardware requirement; many pipelines need one key
Payment PIN and card keys	Payment HSM	Scheme rules; see Payment HSMs
Laptop and server machine certificates	TPM	Bind identity to hardware, attest at enrolment
Full-disk encryption keys	TPM	Seal to boot state; see BitLocker
Windows Hello for Business keys	TPM	User key bound to the machine
IoT and edge device identity	TPM or DICE	Per-device identity at low cost
Passkeys and mobile app signing keys	Secure enclave	User presence and biometric gating on the device

Cost and operating model

Compare on cost drivers rather than list prices. HSMs carry hardware or service fees, clustering for availability, support, ceremony staff time and integration work; cloud KMS keys backed by validated HSMs remove most of that unless a rule requires sole custody. TPMs are already in most business PCs and servers, so the cost is enrolment engineering and help desk handling of motherboard swaps. Secure enclaves cost app development, server-side attestation checks and re-registration flows. In all three, the hidden cost is recovery.

Decision checklist

Does more than one system or person need to use the key? If yes, HSM or HSM-backed KMS.
Must the key prove which physical device is calling? If yes, TPM for computers, secure enclave for phones.
Does a rule name a certification (FIPS 140-3 level, Common Criteria, scheme approval)? If yes, confirm the exact module certificate before choosing.
Must the key survive hardware failure? If yes, HSM with backup.
Does the operation need user presence? If yes, secure enclave or TPM with user authentication bound to the key.
How many operations per second? Server-scale signing or decryption points to an HSM; occasional operations suit a TPM or enclave.
Can the relying party verify attestation? If not, a device-bound key gives you less than it seems.

How to implement

Inventory and classify: list every private key by owner and storage, tagged organisational, machine or user.
Set a standard: hardware class and minimum evidence for each tag.
Start with the highest-value keys: move CA and signing keys into HSMs first, with a witnessed ceremony and a tested restore.
Pilot device keys in audit mode: issue TPM-backed certificates with attestation set to "Required, if client is capable" to a pilot ring, record which devices fail, then move to "Required".
Enforce at the relying party: VPN, Wi-Fi and mutual TLS endpoints accept only certificates with the attestation issuance policy; mobile back ends reject registrations without a valid attestation chain.
Roll back safely: keep the previous template published until the pilot passes, and old HSM keys active for verification until dependants move.

Detection and measurement

HSM: alert on role changes, export or cloning attempts, failed logins and unusual signing volume per client.
TPM: monitor TPM lockout events, TPM clears, certificate requests without attestation, and device health attestation failures from the management platform.
Secure enclave: log attestation results, low security-level registrations and re-registration spikes.

Metrics that show the programme is working:

Percentage of high-value keys (CA, signing, master keys) held in validated HSMs.
Percentage of machine certificates issued with verified TPM key attestation.
Percentage of mobile registrations with a valid hardware attestation at StrongBox, TEE or Secure Enclave level.
Number of software-held private keys found by discovery scans per quarter, trending down.
Time to re-issue device credentials after hardware replacement.
Date of the last successful HSM restore test.

Common failure patterns

Buying hardware, not authorisation: an HSM signing key behind one shared, unrotated client password still lets an intruder sign malware.
Unverified "hardware" keys: the CA or app server never checks attestation, so software keys pass as TPM or enclave keys.
Exportable templates: a certificate template that allows private key export defeats the TPM entirely.
No re-enrolment path: a motherboard swap or new phone strands users because the team planned for backup that the hardware never allowed.
Certificate expiry ignored: FIPS 140-2 modules move to the Historical list after 21 September 2026, which can fail new procurement or audits if nobody tracked it.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-12, SC-12(1)	Key establishment and management, key availability
NIST SP 800-53 Rev. 5	SC-13, IA-7	Cryptographic protection, cryptographic module authentication
NIST SP 800-53 Rev. 5	IA-5(2), SI-7	Public key-based authentication; firmware and software integrity (measured boot)
NIST CSF 2.0	PR.DS-01, PR.AA-01, PR.AA-03	Data at rest; credentials for users, services and hardware; authentication of hardware
MITRE ATT&CK	T1552.004, T1649	Private key theft and certificate theft or forgery that hardware protection counters

Practitioner checklist

Classify every private key as organisational, machine or user scope.
Hold CA, code signing and master keys in FIPS 140-3 validated HSMs or HSM-backed KMS.
Track the FIPS 140-2 to 140-3 transition for every module you rely on.
Require TPM key attestation for machine certificates and disallow key export on templates.
Bind mobile keys to the enclave with user authentication and verify attestation server-side.
Protect HSM client credentials as privileged non-human identities.
Design re-enrolment for device keys and test HSM restores at least yearly.
Forward HSM, TPM and attestation events to the SIEM and track the metrics above.

HSM vs TPM vs Secure Enclave: Choosing the Right Hardware Root of Trust