Mixed Key Storage in a Unified PKI: HSM, TPM, Secure Element, Software Keys on One Trust Chain

Enterprise keys live in HSMs and cloud KMS. Device keys live in TPMs, secure elements, or flash. A unified PKI needs policy that spans all four storage classes and an honest view of what "hardware-backed" actually means in each. The policy framework, the attestation question, and the crypto-agility path.

Key storage is where PKI policy meets physics. A certificate is worth exactly what the protection of its private key is worth. A unified PKI spanning enterprise and IoT touches at least four key storage classes — network HSM, cloud KMS, platform TPM, and discrete secure element — and must express policy across all of them without collapsing them into a single abstraction. This page is the framework for how to do that.

The central claim: "hardware-backed" is not a boolean. It is a spectrum with specific assurance properties at each point, and the unified PKI must let you express which point of the spectrum is required for which certificate profile. A platform that treats "hardware-backed" as a checkbox is a platform that will issue certificates to the weakest storage class that can tick it.

The four storage classes in practice

Class 1: Hardware Security Module (HSM)

Network-attached or PCIe HSMs — Thales Luna, Entrust nShield, Utimaco, and their peers — are the high-assurance anchor of enterprise PKI. Keys generated inside the HSM never leave in plaintext. Operations are performed inside the HSM in response to authorised requests.

Assurance properties:

• FIPS 140-2 Level 3 or FIPS 140-3 Level 3 validation typical; Level 4 for highest-assurance use cases.
• Key wrapping for controlled cross-HSM transfer.
• Role-based access with M-of-N quorum on sensitive operations.
• Tamper-evident and tamper-resistant physical construction.

Operational footprint: measured in thousands to millions of operations per second. Designed for server-class signing workloads — CA signing, code signing, document signing, TLS termination for very-high-volume services.

Cost: network HSMs range from $10K to $50K per unit plus licensing. HSM clusters for high-availability CA operations run to $100K+ in capital plus ongoing support. This is the reason cloud KMS exists.

Class 2: Cloud Key Management Service

AWS KMS, Azure Key Vault, Google Cloud KMS, and AWS CloudHSM as the managed dedicated variant. Cloud KMS services are backed by HSMs internally but exposed as managed APIs rather than as direct HSM access.

Assurance properties:

• Underlying hardware is FIPS 140-2 Level 3 validated (AWS KMS, Azure Key Vault Managed HSM) or equivalent for major cloud providers.
• Keys generated in the service never leave in plaintext.
• Access controlled via IAM policies, not HSM role management.
• Audit trail integrated with cloud platform logging.

Operational footprint: serverless, scales to the cloud provider's limits, pay-per-operation pricing. Well suited to CA signing at moderate volumes and to serverless PKI architectures — which is why Axelspire's 3AM platform uses AWS KMS as the cryptographic engine for CA operations.

Trade-offs: key material is in the cloud provider's custody. Regulatory regimes that require customer-controlled keys (some financial services jurisdictions, some sovereign cloud requirements) push toward CloudHSM or customer-managed HSMs accessed from the cloud. The operational economics shift meaningfully at scale: for very-high-volume signing, dedicated HSMs may be cheaper than per-operation KMS pricing.

For unified PKI, cloud KMS is the backing store that makes serverless CA architectures viable. It is not appropriate for every regulatory regime, and the policy framework must let the CA specify which storage class it will use on a per-profile or per-CA basis.

Class 3: Trusted Platform Module (TPM)

TPM 2.0 — the Trusted Computing Group specification — is the motherboard-integrated cryptographic chip found in most modern server and workstation platforms, and increasingly in industrial and edge compute.

Discrete TPM: dedicated chip connected via LPC or SPI bus. Physically separated from the main processor. Examples: Infineon SLB 9670, Nuvoton NPCT75x.

Firmware TPM (fTPM): TPM functionality implemented in the main processor's secure execution environment. Intel PTT (Platform Trust Technology), AMD fTPM, ARM TrustZone-based implementations. No separate chip; shares attack surface with the main processor.

Assurance properties:

• Key generation and use inside the TPM.
• Platform attestation via PCR (Platform Configuration Register) quotes — the TPM can sign a statement about the boot state of the platform.
• Endorsement Key (EK) fixed at manufacture, enabling hardware attestation.
• TCG Specifications formalise the interface; vendor implementations vary.

Operational footprint: moderate throughput (hundreds of signing operations per second for discrete TPMs; typically slower for fTPM). Designed for platform-level identity, disk encryption keys, and moderate-volume signing.

IEEE 802.1AR role: TPMs are a common choice for IDevID storage in enterprise networking and industrial gear. The IDevID private key lives in the TPM; the certificate lives in device storage. The TPM's EK chain provides attestation that the IDevID was generated in genuine TPM hardware.

SPIRE integration: SPIRE supports TPM-based workload attestation, binding SPIFFE SVIDs to platform identity via TPM quotes. This is the standard pattern for high-assurance workload identity on TPM-equipped hosts.

Class 4: Secure Element (SE)

Discrete security chips designed for embedded use: NXP SE050 / EdgeLock 2GO, Microchip ATECC608, Infineon OPTIGA Trust M, and similar parts. Used in constrained IoT, automotive ECUs, payment terminals, and high-volume consumer devices.

Assurance properties:

• Common Criteria EAL4+ or EAL6+ certification common.
• Physical tamper resistance including side-channel countermeasures.
• Small interface (I2C or SPI) suitable for microcontroller integration.
• Per-unit cost: $0.50 to $5.00, which matters at device-scale economics.

Matter DAC role: Matter specifications permit but do not mandate secure element storage for DAC private keys. In practice, consumer device manufacturers increasingly use SEs for DAC key protection because the physical tamper resistance is the only defense against device key extraction via physical attack.

PUF (Physically Unclonable Function) variants: some SE parts derive keys from silicon-level manufacturing variation rather than storing them in NVRAM. This changes the threat model — there is no key to extract — but introduces device-specific identity that cannot be pre-provisioned.

The SE class is where the IoT PKI story materially differs from enterprise PKI. Enterprise signing rarely needs per-unit secure storage. Device identity at scale does.

The fifth class: software keys

Keys stored in filesystem, kernel keyring, or application memory. Protected by OS-level access controls and, if present, disk encryption. No hardware isolation.

Used at enterprise scale for operational certificates on non-HSM hosts (most internal TLS endpoints), for workload identity SVIDs, for development and CI/CD signing. Used at IoT scale for consumer devices without SE or TPM — still the majority of shipped IoT by unit count.

Software keys are not worthless. They defeat remote attackers who don't achieve code execution on the host. They fail against adversaries who do achieve code execution or physical access. The unified PKI must express policy that distinguishes profiles where software keys are acceptable from profiles where they are not.

The policy framework: profiles bind to storage class

Unified PKI policy expresses key storage requirements at the profile level, not at the CA level. The same CA may issue certificates to keys in HSM, TPM, and software, with policy enforcement at issuance time.

A representative policy mapping:

Policy must be expressible as "this profile requires a key attested as resident in TPM, SE, or HSM — not software." Policy that cannot distinguish across storage classes forces either over-protection (SE for everything, cost explosion) or under-protection (software for everything, incident exposure).

Attestation: the difference between claimed and verified storage

A CA without attestation cannot verify where the private key is. The CSR arrives, the CA checks the signature, the CA issues the certificate. The claim "this key is in hardware" is untestable. Attestation fixes this.

TPM attestation: the TPM signs a statement about its own state — PCR values, EK chain, key attributes — using the TPM's attestation key. The CA verifies the attestation signature against the TPM's endorsement chain and extracts the claimed key attributes from the signed statement. The key's residency in the TPM is cryptographically verified, not claimed.

Secure element attestation: SE parts typically expose a challenge-response attestation. The CA sends a challenge; the SE signs it with a factory-installed attestation key; the CA verifies against the SE vendor's root. The SE proves it is a genuine part from the claimed vendor and that the key in question was generated inside it.

HSM key wrapping: HSMs don't attest in the same sense, but key wrapping provides equivalent assurance. A key wrapped by an HSM's key-wrapping key is provably known only to that HSM. For CA-to-CA key transfer, this replaces attestation.

Platform attestation via DICE / TCG DICE: the Device Identifier Composition Engine specification provides a lightweight alternative to TPM for constrained devices, attesting platform state in boot chain derived from a Unique Device Secret.

What "no attestation" means: the CA trusts the requester's claim about where the key lives. This is policy-on-trust. Usable for internal workloads where the requester is itself authenticated, unusable for device PKI where the requester is the device being verified.

Platforms that do not support attestation as an input to issuance policy cannot enforce hardware storage requirements. Platforms that support attestation for some storage classes but not others create policy gaps. The unified PKI platform must support attestation across the classes the estate actually uses.

Crypto-agility and the post-quantum transition

Key storage decisions interact with cryptographic agility. A key generated in hardware today runs an algorithm chosen today; post-quantum migration requires generating new keys in hardware that supports the new algorithms.

HSMs: major HSM vendors have added or are adding support for ML-DSA (FIPS 204), ML-KEM (FIPS 203), and Stateful Hash-Based Signatures (SP 800-208). Firmware updates in-field, sometimes requiring hardware refreshes. Largely manageable.

Cloud KMS: AWS, Azure, and GCP have announced post-quantum algorithm support roadmaps. The transition happens transparently to most customers — new algorithms become available in the API, customers rotate keys.

TPM: TPM 2.0 specification has been extended to support post-quantum algorithms, but firmware TPMs on existing processors may not receive the updates. The transition depends on platform vendor support. Discrete TPM hardware refresh cycles — 3 to 5 years for enterprise, longer for industrial — dictate the practical PQC timeline.

Secure element: current SE parts largely do not support post-quantum algorithms. New SE parts supporting PQC are emerging. Devices shipped today with current SEs will hold classical-algorithm DACs and IDevIDs for the device lifetime — potentially beyond cryptographically relevant quantum (CRQC) timelines if those arrive before 2035.

Software keys: software-key PKI has the simplest PQC transition — regenerate keys, reissue certificates. This is a rare case where software keys are operationally cheaper than hardware.

See NIST IR 8547 for the current transition guidance. The unified PKI must support a PQC transition path that accounts for the storage class constraints: short-lived software keys transition first, long-lived device keys transition last or transition via fleet replacement.

The compliance lens

Regulatory regimes increasingly specify key storage requirements:

• NIS2 Directive: critical entities must apply "state of the art" cryptographic measures. Interpretation includes HSM-protected CAs and hardware-backed identity for critical devices.
• EU Cyber Resilience Act: products with digital elements must have secure-by-design identity. Interpreted as hardware-backed device identity for applicable product categories.
• FIPS 140-3: US federal systems require FIPS-validated key storage. Level 3 is the common target for CA keys.
• PCI DSS: payment processing requires FIPS-validated HSMs for key operations touching cardholder data.
• ETSI EN 303 645: consumer IoT baseline requires unique per-device identity without mandating specific storage, but auditors increasingly expect hardware backing.

Compliance mapping depends on the specific regulation and the certificate's role. The unified PKI's policy framework must let the compliance team express requirements — "all CA keys FIPS 140-3 Level 3," "all device IDevIDs in hardware" — as policy, not as a post-hoc audit finding.

What this means for platform selection

Key-storage evaluation questions for unified PKI:

1. Does the platform support multiple backing stores — on-prem HSM, cloud KMS, cloud HSM — with per-CA or per-profile selection?
2. Can the platform consume attestation evidence (TPM quotes, SE challenge-response, DICE claims) as a policy input for issuance decisions?
3. Does the policy language express storage requirements per profile, or is storage fixed at the CA level?
4. What is the PQC transition path for the platform's current key storage integrations?
5. Are audit records sufficient to prove, for a given certificate, what storage class held the key at issuance?
6. Can the platform issue to software keys while refusing to issue to software keys for regulated profiles, within the same CA hierarchy?

A platform that answers "one backing store, one policy" is designed for a single deployment class. A platform that answers "multiple backing stores, per-profile policy, attestation as input" is designed for the unified estate. Axelspire's 3AM implements the latter with AWS KMS as the default backing store for the control plane and support for consuming external CA keys in HSM or CloudHSM for the issuing layer.

Further reading

• Unified PKI for enterprise and IoT
• Certificate lifetime policy across enterprise and IoT
• IoT hardware vs software key storage
• Device identity implementation
• SPIFFE and workload identity for device fleets
• Governance across enterprise and device PKI