A trusted platform module is a small computer attached to your computer. It has its own processor, its own memory, and its own non-volatile storage. It runs a defined command set, accepts inputs from the host, and returns cryptographic results. It can refuse to do work if the host is in an unexpected state. The TPM is the hardware root of trust for billions of laptops, servers, and embedded devices.
TPM 2.0 is the current specification, published by the Trusted Computing Group, an industry consortium that includes Microsoft, Intel, AMD, IBM, and dozens of other major vendors. The specification has been stable since 2014, with revisions adding features and clarifying behavior. As of 2024 and 2025, TPM 2.0 chips ship in essentially every Windows 11 capable machine, and Linux makes wide use of them too (Apple machines use Apple's own Secure Enclave instead of a TCG TPM).
The next big transition for TPM 2.0 is the addition of post-quantum cryptography. The TPM is full of classical algorithms today: RSA, ECC over various curves, AES, SHA-2, and SHA-3. NIST FIPS 203, 204, and 205 add a new family of algorithms with different sizes, different operation costs, and different security properties. Fitting them into the TPM specification is a multi-year project that is well underway.
This article walks through the TPM architecture, the algorithm registry, the changes needed for post-quantum, and the practical timeline.
TPM architecture in plain terms
The TPM is a slave device on a low-bandwidth bus. On laptops, it usually sits on the LPC or SPI bus at a few megahertz. The host CPU sends commands and the TPM responds. The communication is slow by modern standards, hundreds of kilobytes per second at best.
The TPM has a few standard structures. Platform Configuration Registers, PCRs, hold hashes that represent the boot state. Each PCR is a hash chain that the host extends with measurements during boot. NV indices store small amounts of non-volatile data that survives power cycles. Persistent objects are key handles that the TPM creates and stores in its own protected memory.
Cryptographic operations happen inside the TPM. The host never sees the private key. To sign a document, the host sends the hash of the document to the TPM, the TPM signs it with the loaded key, and the host receives the signature. To unwrap an encrypted key, the host sends the wrapped key to the TPM, the TPM uses its private key to decrypt, and returns the unwrapped key to the host.
The bandwidth and command set are designed for classical cryptography. RSA-2048 signatures fit in 256 bytes. ECDSA signatures fit in 64 bytes. ML-DSA-65 signatures are around 3300 bytes. Sending a signature out of the TPM requires moving more data than RSA does, but the bus can handle it. Sending in a public key is similar. The bigger question is whether the TPM has enough internal memory and compute to do the operation.
TCG specification process
The Trusted Computing Group defines TPM behavior through formal specifications. The core specification, TPM 2.0 Library, defines the architecture, structures, and command set. Vendor profiles, including PC Client and Mobile, restrict the choices for specific platforms. Errata and revisions update the specifications as issues are found and as new algorithms are added.
Adding post-quantum algorithms to the TPM requires changes in several specification documents. The TCG Algorithm Registry assigns identifiers to cryptographic algorithms. New algorithms get new identifiers. The TPM Library Specification defines the formats for keys and signatures. The PC Client Specification defines what algorithms a PC Client TPM must support.
The TCG has been working on post-quantum extensions through several working groups. The Algorithm Registry has been extended with provisional identifiers for ML-KEM, ML-DSA, and SLH-DSA. The Library Specification is being updated to define how these algorithms map onto TPM commands. As of 2025, the work is partially public, with full specifications expected in coming years.
Algorithm registry and identifier space
The TCG Algorithm Registry assigns 16-bit identifiers to algorithms. Classical algorithms occupy a wide range of identifiers, with separate entries for each variant. RSA, ECC over various curves, AES with various key sizes, and the SHA family all have identifiers.
For post-quantum, the TCG has been provisional about identifier assignments. ML-KEM-512, 768, and 1024 are expected to have separate identifiers. ML-DSA-44, 65, and 87 are expected to have separate identifiers. SLH-DSA, with its many parameter sets, will have multiple identifiers as well.
The reason this matters is that TPM commands reference algorithms by identifier. A signing command specifies which algorithm to use. A key creation command specifies which algorithm the key is for. Without registry entries, the algorithms cannot be used through the standard TPM interface.
Vendor experimental implementations have used vendor-specific identifiers in the meantime. Microsoft, IBM, and others have published experimental TPM firmware with post-quantum support. These implementations are not interoperable, but they prove the concept and inform the standardization.
Memory and bandwidth challenges
A typical TPM 2.0 chip has hundreds of kilobytes of internal RAM and a few megabytes of internal flash. ML-KEM-768 needs a few kilobytes of working memory. ML-DSA-65 needs more, with the secret key alone occupying around 4000 bytes. SLH-DSA does not need a large secret key but does need significant working memory during signing because of the hash tree structure.
The bus bandwidth is the bigger constraint. SPI at 33 megahertz can move around 4 megabytes per second in theory, but TPM protocol overhead reduces this significantly. LPC is slower. Sending in a 1,184-byte ML-KEM-768 public key takes milliseconds. Sending out a 3300-byte ML-DSA signature takes similar time. For interactive use, this is acceptable. For high-throughput signing, it would be too slow.
Some vendors are designing TPM chips with higher-bandwidth buses for post-quantum use. Others are accepting the slower throughput on the assumption that signing operations remain rare. Boot-time measurements, attestation, and key wrapping are infrequent enough that the slower bandwidth does not matter for most use cases.
Endorsement keys and platform certificates
The TPM ships with an endorsement key, EK, that is used to authenticate the device. The EK is signed by the TPM manufacturer in a certificate chain that ultimately leads to a manufacturer root certificate. When a server wants to verify that a client has a genuine TPM, it requests the EK certificate and validates the chain.
Today, EK certificates are signed with RSA or ECDSA. Migrating to post-quantum signatures means manufacturers must issue new certificates signed with ML-DSA or SLH-DSA. This is a significant operational change because manufacturer signing keys, infrastructure, and certificate chains all need updates.
The TCG has guidance on EK certificate formats and is working on extensions for post-quantum chains. Manufacturer participation is essential because the signing infrastructure lives at the manufacturer's secure facility. Microsoft, Intel, AMD, and Infineon have all published statements indicating they are working on this.
For deployed TPMs that already have RSA or ECDSA EKs, retrofit is harder. The EK is provisioned at manufacture and cannot be replaced. New post-quantum endorsement keys can be added through TCG-defined commands, and platforms with both old and new EKs can authenticate to either old or new servers. This dual-EK approach is the realistic path for migration.
Attestation and integrity reporting
TPM attestation is the process of proving that a platform is in a known state. The TPM produces a quote, a signed report of PCR values, and the verifier checks the signature against an attestation key. The attestation key is itself bound to the EK through a chain of TPM-internal operations.
Migration to post-quantum attestation requires updating both the attestation keys and the protocols that use them. Microsoft's Device Health Attestation service, Intel SGX attestation, and similar systems all need to update. The challenge is operational rather than cryptographic: rolling out new attestation infrastructure across millions of devices takes time.
The hybrid approach helps here too. A platform can include both a classical attestation key and a post-quantum attestation key, producing both signatures on each quote. Verifiers that support post-quantum can validate both. Verifiers that only support classical can validate the classical signature. This dual-mode operation enables a gradual transition without flag days.
Hybrid encryption covers the cryptographic construction. The same logic applies to attestation signatures.
Key wrapping and storage
The TPM is often used to wrap keys that the host application does not want to expose. The application generates a working key, hands it to the TPM with a request to wrap, and stores the wrapped key. Later, the application asks the TPM to unwrap, and uses the unwrapped key. The wrapping key never leaves the TPM.
For post-quantum, the wrapping algorithm changes. ML-KEM provides a key encapsulation mechanism that can wrap a symmetric key in a similar pattern to RSA-OAEP. The host generates a fresh symmetric key, encapsulates it with the TPM's ML-KEM public key, and stores the ciphertext. Later, the TPM decapsulates the ciphertext to recover the symmetric key.
The pattern requires bus bandwidth for the larger ciphertexts but otherwise fits the existing TPM use case. Hybrid wrapping, where the symmetric key is encapsulated under both an RSA public key and an ML-KEM public key, gives defense-in-depth.
QNSQY's hybrid file encryption uses similar logic. The file's data encryption key is wrapped under both X25519 and ML-KEM-768. Decryption requires both private keys. The same approach can be used with TPM-stored keys when TPM 2.0 supports ML-KEM.
DICE and silicon root of trust
Device Identifier Composition Engine, DICE, is a related TCG specification for embedded devices that need a root of trust without a full TPM. DICE devices use one-way derivation to chain identities from a permanent secret in silicon. Post-quantum DICE is being discussed in TCG working groups.
DICE typically signs attestations using the derived identity. Migration to post-quantum signing means using ML-DSA or SLH-DSA in the DICE chain. The smaller form factor and tighter resource budget of DICE devices favor compact algorithms. SLH-DSA's large signatures are awkward, while ML-DSA fits better.
OpenTitan, an open-source silicon root of trust project, implements DICE concepts in an open-source design.
Practical timeline
The realistic timeline for full TPM 2.0 post-quantum support runs from now through the late 2020s. TCG specifications are partially in place. Vendor experimental firmware exists. Production silicon with post-quantum support is starting to appear in 2025 and 2026, with broader availability through 2027 and 2028.
For organizations planning hardware refreshes, the question is whether to wait for post-quantum capable TPMs or to deploy current chips and add post-quantum software defense. The hybrid software approach in QNSQY does not require TPM-level support, so file-level encryption can move ahead immediately. TPM-protected keys for signing and authentication will need to wait for production hardware.
Microsoft, in particular, has published roadmaps that indicate Windows will support post-quantum TPM operations as the chips become available. The interface stability of TPM 2.0 means that adding new algorithms does not break existing software. Applications that use the TPM through Microsoft's CNG layer or through TSS will inherit post-quantum support without code changes.
Frequently asked questions
Does TPM 2.0 currently support post-quantum algorithms? Not in the production specification, but provisional support is in development. The TCG Algorithm Registry has reserved identifiers for ML-KEM, ML-DSA, and SLH-DSA, with full specifications expected in coming years.
Can existing TPM chips be updated to support post-quantum? Some can if the firmware is updateable and there is enough headroom for the new algorithms. Many cannot because the silicon does not have the required compute or memory. New chips will be needed for full post-quantum support.
What is the EK and why does it matter for the migration? The endorsement key is the manufacturer-provisioned identity of the TPM. Migrating to post-quantum requires new EKs signed with post-quantum signatures, which requires manufacturer infrastructure changes.
How long will the migration take? Several years. Specifications are partially in place. Production silicon is starting to ship in 2025 and 2026. Broad deployment will follow over several years as hardware is refreshed.
What can organizations do today? Use software-level post-quantum tools like QNSQY for file encryption. Plan TPM hardware refreshes for upcoming purchase cycles. Track TCG specification progress and Microsoft, Intel, AMD roadmaps.
Sources
- TCG TPM 2.0 Library Specification, https://trustedcomputinggroup.org/resource/tpm-library-specification/
- TCG Algorithm Registry, https://trustedcomputinggroup.org/resource/tcg-algorithm-registry/
- TCG PC Client Platform Specification, https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/
- NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, https://csrc.nist.gov/pubs/fips/204/final
- NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, https://csrc.nist.gov/pubs/fips/205/final
- TCG DICE Architectures, https://trustedcomputinggroup.org/resource/dice-architectures/
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.