Every week companies ask our team how to prepare for the PQC TPM migration, in part because TPM vendors are moving painfully slow with public guidance. This post shares everything we can about the transition without violating NDAs.
Key takeaways
- Most current TPM 2.0 chips will not be upgradable to PQC capabilities. You will need to procure new discrete TPMs that implement v1.85 of the TCG TPM specification. This means new hardware or, in the best case, a TPM header plus a UEFI/bootloader update.
- Firmware TPM 2.0 is also impacted, due to FIPS certification and the available cryptographic primitives, and in some cases also memory constraints.
- PQC EK provisioning: it is not yet clear how this will be solved for existing systems.
- TPM applications also need migration to use the new v1.85 API and the new TPM commands for PQC. Work in the TCG-referenced tpm2-tss is ongoing but not complete.
Replacing TPM headers in server racks is a likely scenario, but not a guaranteed PQC upgrade path. Read below to understand the technical details.
Contents
- Upgrading systems with discrete TPMs
- Upgrading systems with firmware TPMs
- PQC provisioning using a TPM 2.0 and PQC EK
- Migrating TPM applications to PQC TPM API
Upgrading systems with discrete TPMs
Based on public information, no one has claimed that discrete TPM 2.0 chips can be upgraded to a PQC TPM 2.0 compliant with v1.85. Why? Current hardware platforms used for most discrete TPMs cannot meet the memory requirements for PQC algorithms and PQC operations.
However, we can share that there will be at least one attempt to provide a TPM firmware update to some existing TPM 2.0 chips. The caveat with this is latency and performance.
TPM 2.0 is known for high security guarantees, not for the speed of its cryptographic operations. Therefore, even if PQC capabilities fit into an existing TPM 2.0 chip, PQC operations will be slower than what we have with RSA today.
This means any server, hyperscaler or datacenter use case will suffer from increased latency on verification, secure communication and signing operations, making it less practically viable.
Automotive and industrial systems may be able to use a current TPM 2.0 with a firmware update to PQC TPM, because a car or an industrial control system performs far fewer of these operations, far less often, than a cloud server does.
In summary: using a discrete TPM 2.0 chip? Prepare to change your systems’ hardware.
Upgrading systems with firmware TPMs
The challenge with Firmware TPM 2.0 is where the cryptographic primitives come from. Sometimes it is an old OpenSSL version that was FIPS certified. Other times it is rooted in the hardware: a cryptographic hardware accelerator that supports only RSA and ECC.
This means the PQC problem remains difficult to solve by a pure firmware update, even for firmware TPMs. What to ask your system OEM?
- Are you going to provide a new FIPS-certified cryptographic library for our TPM 2.0?
- Are you going to provide a new firmware update that implements v1.85 of the TCG TPM 2.0 specification?
- Can you confirm that the shared/secure memory available to the TEE/fTPM will be sufficient to perform PQC operations?
Even once we solve the cryptographic primitives for PQC and deploy a v1.85 fTPM over the air, the question of PQC memory requirements remains:
- RSA 4096 maximum signature size: 512 bytes
- ML-DSA-44 (NIST Level 2): 2,420 bytes
- ML-DSA-65 (NIST Level 3): 3,309 bytes
- ML-DSA-87 (NIST Level 5): 4,627 bytes
That is a 4x to 9x increase in memory on the signature size alone. More memory is required for performing the signing operation that generates the signature, and key generation is not an inexpensive process either.
A firmware TPM usually has a memory-isolated piece of the system’s shared memory. In better architectures, it has its own dedicated secure enclave or core with secure memory.
When your systems were built with an fTPM, the requirements for PQC did not exist. If the memory isolation mapping can be updated, then maybe the fTPM can achieve the full functionality of v1.85 after a firmware update.
PQC provisioning using a TPM 2.0 and PQC EK
Traditionally, a TPM 2.0 has a special Endorsement Key (EK), provisioned at manufacturing time by the TPM vendor, that can be verified using the TPM EK certificate.
These EKs can only perform decryption. Therefore, they are used in a complex challenge-response mechanism using MakeCredential/ActivateCredential to provision a system securely.
How to acquire a PQC EK on a current generation TPM 2.0?
We cannot. We would have to ship the TPMs from all our systems to the TPM vendor’s factory, where they would be reprovisioned and new EK certificates issued.
What is technically possible?
We can generate any sort of Endorsement Key using our own key template, so we can specify the algorithm and key properties.
A current generation TPM upgraded with v1.85 PQC capabilities should be able to generate a PQC EK for the purposes of internal provisioning, but that EK will not have a TPM EK certificate to be verified against. Verification would have to be done using a Certificate Authority that is either yours or from a third-party provider.
New PQC TPM 2.0 chips produced with v1.85 out of the factory will be provisioned by the TPM vendors with PQC EKs and PQC EK certificates.
Migrating TPM applications to PQC TPM API
Can we at least start porting our TPM applications for PQC?
TPM integration has two sides: we have the actual TPM, and then we have the TPM application that makes use of it. The TPM application can be rich software running on a Linux server, or something very lean as part of the system bootloader.
Good news, bad news
- The Trusted Computing Group has done its job publishing the v1.85 TPM 2.0 specification (link below), where we can find all the new APIs and clarifications on PQC operations.
- The TPM industry is working hard on implementing the v1.85 specification in public for the TPM Software Stack, specifically the open-source tpm2-tss.
- There is no TCG reference TPM 2.0 implementation with v1.85 yet that you can use with tpm2-tss.
There are alternatives like wolfTPM from wolfSSL, which implements both a TPM server and a TPM stack with v1.85. It is also open source, but many teams specifically use the TCG-referenced TPM software.
A good starting point is the TCG specification for the new TPM commands for PQC:
TPM2_SignSequenceStartandTPM2_SignSequenceCompleteTPM2_VerifySequenceStartandTPM2_VerifySequenceCompleteTPM2_SignDigestTPM2_VerifyDigestSignatureTPM2_EncapsulateTPM2_Decapsulate
Keep in mind that the existing TPM2_Sign and TPM2_Verify will be deprecated, but still available on new v1.85 PQC TPM 2.0 solutions. tpm2-tss with v1.85 support is expected to be finished before the end of the year, and the TPM reference implementation early next year.
Where to start
Today, the recommended PQC TPM strategy is to start learning the new v1.85 TPM API and plan your PQC TPM application migration. EnactTrust will support PQC TPM 2.0 like the upcomming Infineon Technologies OPTIGA TPM with PQC
Update, Oct 2026: Infineon SLB 9678 with PQC was unveiled at OCP Summit).
Do not delay the work. Start preparing, and reach out if you need help.