A TPM Counts as PQC-Ready Only If It Meets TCG's PTP 1.07: What the 23 March 2026 Profile Requires, and What the Chips Announced on 3 September Claim
On many business machines a discrete chip roughly the size of a shirt button sits on the board carrying a Trusted Platform Module, and inside it is an endorsement key whose private half is generated in the part and never leaves it. The certificate issued over the public half functions as a statement of origin: this key lives in a genuine TPM from this manufacturer. Other things in a platform hang off that starting point at one remove. Storage keys wrap disk-encryption secrets under the TPM's own hierarchy. Boot components are measured into platform configuration registers. Attestation keys, separate from the endorsement key, sign quotes over those measurements, and a verifier decides whether to trust such a quote partly on the basis that the attestation key was certified back to a credible endorsement credential. Several distinct mechanisms, one common anchor.
Which is why the phrase “quantum-safe TPM” on a datasheet has been doing more work than it could carry. The conformance document had existed since spring — the PC Client Platform TPM Profile version 1.07, published 23 March 2026 — without guidance addressed to purchasers or an agreed vocabulary for a part that falls short. Both arrived with the Trusted Computing Group's guidance of 24 August 2026. TCG president Joe Pennisi put the problem plainly: buyers “will need to look beyond individual algorithm support.” Ten days later, two announcements showed why he said it.
Practical takeaway. Ask a TPM vendor which version of the PC Client Platform TPM Profile the part conforms to, and whether the endorsement key certificates are provisioned in the factory or delivered later by field upgrade. SEALSQ reports ML-KEM and ML-DSA testing on QVault hardware; its release does not establish PTP 1.07 conformance.
What PTP 1.07 Requires: ML-KEM-768 or ML-KEM-1024, ML-DSA-65 or ML-DSA-87, and SHA-1 Removed Outright
The profile is 195 pages and unglamorous, and its operative sentences are short. In the algorithm table it states that a TPM shall support either ML-KEM-768 or ML-KEM-1024, and that it shall support either ML-DSA-65 or ML-DSA-87. Both lines carry the same annotation: mandatory as of PTP version 1.07. Those are the NIST lattice standards, FIPS 203 for key encapsulation and FIPS 204 for signatures, now landed in the profile that governs the PC and server root of trust.
The same table does housekeeping that will be felt sooner than the lattice work. SHA-1 becomes Not Allowed as of 1.07, meaning a conformant part shall not support it at all. SHA-512 becomes mandatory. RSAES drops to optional on the ground that NIST deprecated it. Triple DES had already been ruled out in 1.06. A vendor can add optional post-quantum algorithms beyond the floor, and several will, but the floor is now written down and a purchasing officer can quote it.
The Storage Requirement: 68 NV Indexes, 11,026 Bytes of Index Data and 6,896 Bytes of Persistent Objects
The engineering that matters most in PTP 1.07 is arithmetic about non-volatile memory. Post-quantum objects are large. The profile's own size tables put an ML-KEM-768 public key at 1,184 bytes and an ML-KEM-1024 public key at 1,568, with an ML-DSA-87 signature at 4,627 bytes and an ML-DSA-87 expanded private key at 4,896. For scale, the same specification's persistent-object example budgets an ECC P-384 endorsement key at 144 bytes.
Two normative floors follow. A conformant TPM shall support allocation of at least 68 NV indexes with a total minimum data size of 11,026 bytes, and shall support a minimum of 6,896 bytes to hold persistent objects. The profile notes that the index figure excludes any space used for pre-provisioned endorsement key certificates, which vendors must budget separately, and that the stated sizes are data areas only, before overhead.
The tables illustrating those numbers are marked non-normative, and they are where the design thinking shows. The persistent-object example reaches 6,896 bytes on the assumption that for ML-KEM and ML-DSA the chip stores the seed rather than the expanded key: an ML-KEM-1024 endorsement key budgeted at 64 bytes and an ML-DSA-87 attestation key at 32, against 3,072 for the RSA 3072-bit endorsement key beside them. Nothing binds a vendor to that partitioning, but it shows what the working group expected the budget to be spent on, and a seed-based design implies work at use time that a stored expanded key would not need.
Where Certificates Are Pre-Provisioned, They Come in Classical and Post-Quantum Pairs
The provision most likely to surprise a migration plan is conditional, and the condition matters. Pre-provisioning endorsement key certificates in the factory is optional under PTP 1.07. Where a vendor does pre-provision them, the profile requires at least one of two combinations: RSA 3072 together with ML-KEM-768 or ML-KEM-1024, or NIST P-384 together with ML-KEM-768 or ML-KEM-1024. So a factory-provisioned part meeting this profile carries a classical credential next to its post-quantum one. Migration planning has to account for both credential families; which of them any given verifier actually consumes depends on its protocol and its policy. A part shipped without pre-provisioned certificates sits outside the table, and where its credentials come from becomes a question for the vendor.
The profile also allows post-quantum endorsement certificates to arrive later by field upgrade, and adds a small piece of plumbing for that case: an attribute called TCGPQCVersion inside the credential, stating which firmware version the chip requires before those certificates are available. It is a statement of prerequisite, not a receipt — it tells a verifier what is needed, and says nothing about whether the upgrade has happened on the device in front of it. Quentir has made a related argument about what a green check mark in a client actually asserts: the same padlock renders whether the trust decision underneath it was post-quantum or classical. Reading TCGPQCVersion is where a fleet's post-quantum status starts to become a per-device question instead of a model-number one, and somebody still has to go and ask it of each device.
What SEALSQ, wolfSSL and WiSECURE Announced on 3 September 2026
On 3 September, SEALSQ and wolfSSL announced wolfTPM support for the SEALSQ QVault TPM, describing it as “on track to be the first shipping TPM 2.0 device on the market to implement in silicon the post-quantum algorithms introduced in the Trusted Computing Group's latest TPM 2.0 v1.85 specification.” The testing they report is substantial and specific: ML-DSA signing and verification and ML-KEM encapsulation and decapsulation at all key strengths, on physical hardware and in wolfSSL's firmware TPM environment.
Read next to the profile, two things stand out. The claim is anchored to the TPM 2.0 Library Specification v1.85, the document that defines what the algorithms are and how commands invoke them. PTP 1.07 — the document that says what a PC client part must do to be conformant — appears nowhere in the release, and neither does the PQC-ready designation. “On track to be the first shipping” is also a schedule statement, and the release gives no shipping or sampling date. None of that says the part falls short. It leaves a question open that the profile was written to answer, and the company is well placed to answer it: the acknowledgements page of PTP 1.07 lists four SEALSQ engineers among its contributors, one of them credited a second time under WISeKey Semiconductors. The people who helped write the profile are in a position to say where the part stands against it.
The same day at SEMICON Taiwan 2026, WiSECURE Technologies and ITRI showed a new generation of the WAP cryptographic application chip, which the company says supports FIPS 203, 204 and 205 together and has reached mass-producible commercial grade. WiSECURE's account is that its previous generation carried FIPS 203 and 204 in an ASIC and has already shipped to customers, and that this generation adds FIPS 205 in work with ITRI's SecPaaS platform; those are company statements, not independently verified. The part is aimed at enterprise hardware security modules and embedded work: a different socket, and PTP 1.07 does not reach it at all. Worth saying, because a procurement conversation about “post-quantum silicon” can otherwise slide between three unrelated categories of chip inside a single meeting.
PQC-Upgradable and PQC-Ready Are Two Different Purchases
TCG's August guidance defines two designations off the same profile. A part that implements PTP 1.07 is a TCG PQC-ready TPM. A part that falls short but can be brought to conformance is a TCG PQC-upgradable TPM, with the condition that the upgrade path itself must be quantum-safe, since an adversary who owns the firmware pipeline owns everything that pipeline installs. TCG says it will extend its certification programs to cover PTP 1.07. Until that work finishes, the designations are vocabulary, not a certificate a buyer can demand.
TCG is also explicit that this settles one layer and no more: a PQC-ready TPM assures the TPM meets the profile's requirements, and any other post-quantum requirement on the platform may be independent of what the TPM can do. Within that layer, the designations sort an installed base into three piles with rising cost. Ready parts can anchor a post-quantum identity now. Upgradable parts carry a firmware campaign, the integration and validation work that goes with any firmware change on a security component, and the per-device checking to confirm it landed. Parts that are neither need physical replacement, on whatever refresh cycle the finance function will bear — the layer underneath the server-refresh numbers Quentir looked at last month, when Dell put 1.2 million aging servers at the center of its own migration argument. The figure TCG quoted alongside the August guidance is that 90 percent of businesses still lack a formal post-quantum roadmap, so most organizations have not yet sorted their fleet into any pile at all.
How Quentir Reads It
Standards bodies publish two kinds of document, and the distance between them is where this week's confusion lives. A library specification is a menu: here are the algorithms, here is how a command invokes them. A platform profile is a bar: here is what a part in this class must do to be called conformant. Vendors reach for the menu because it lands first and because implementing a lattice algorithm in a secure element is a real achievement. Buyers need the bar, because a purchase order cannot cite an achievement. A citation to the library version tells a purchaser which specification the work was aimed at, and leaves conformance to the platform profile an open question.
PTP 1.07 has been public since March. What changed on 24 August is that TCG told purchasers to use it and gave them two words to use it with. The mechanism is unremarkable, and that is what makes it consequential: post-quantum migration will reach most organizations through a line in a hardware specification that somebody has to check before signing. Contributors from around thirty organizations wrote that line — AMD, Arm, Cisco, Dell, Google, IBM, Infineon, Intel, Microsoft, NXP, STMicroelectronics and the United States Government among them — with Dell's Amy C Nelson as editor.
The obligation outlives the purchase. Platform identities, attestation keys and firmware measurements, as TCG's guidance puts it, may need to remain secure for decades. A machine bought in 2027 will still be proving what it is in 2035, to auditors and insurers reading proofs that trace back to a decision made at the point of sale. Quentir's Signature Report on the post-quantum migration goes further than a public post can: a fixed-scope walk through the hardware, certificate and inventory layers, with refresh triggers and an internal-use license, at quentir.ai/products.
One question is worth carrying into the next vendor call. Which profile version does the part conform to, and are its endorsement key certificates in the factory image or in a firmware release that has yet to ship?
Published intelligence, built to inform your own decisions. Published: 6 September 2026.
Sources: Trusted Computing Group, TCG PC Client Platform TPM Profile Specification for TPM 2.0, Version 1.07 (published 23 March 2026; algorithm table, EK certificate combinations and object-size tables read directly). Trusted Computing Group, “Is Your TPM Truly PQC-Ready?” guidance, 24 August 2026, reported by Help Net Security, “New TCG guidance gives buyers a way to test PQC-ready TPM claims”, 25 August 2026 (source of the Joe Pennisi quotation, the two designations and the 90 percent figure). SEALSQ and wolfSSL, “SEALSQ Announces wolfTPM Support for Its Post-Quantum TPM Technology”, 3 September 2026. iThome, on the WiSECURE and ITRI WAP cryptographic application chip shown at SEMICON Taiwan 2026, 3 September 2026 (the page's own visible date; production-grade and revenue statements are the company's). NIST, FIPS 203 and FIPS 204. All links checked 6 September 2026.
Published intelligence, built to inform your own decisions. Published: September 6, 2026.