SEALSQ's QVault TPM Puts ML-DSA and ML-KEM in Silicon and wolfSSL's wolfTPM Now Drives It: What the September 3, 2026 Integration Means for Long-Life Defense Platforms
Quentir Defense Monitor
Evidence-based insights for quantum defense and security. Published by Quentir Systems LLC · September 6, 2026.
A trusted platform module is the small chip a computer uses to protect keys and record measurements of its boot software for attestation, and it is soldered to the board with the expectation that it will do that job for the life of the machine. The TPMs riding in today's military aircraft, ground vehicles and command-post servers use RSA and elliptic-curve mathematics for public-key operations, exactly the algorithms a cryptographically relevant quantum computer is expected to break. On September 3, 2026, SEALSQ Corp of Geneva and wolfSSL Inc. of Edmonds, Washington announced that the wolfTPM embedded software stack now drives the SEALSQ QVault TPM, a chip SEALSQ states is on track to be the first shipping TPM 2.0 device to implement in silicon the post-quantum algorithms introduced in the Trusted Computing Group's TPM 2.0 v1.85 specification. The pairing matters because a security chip without a software stack is a paperweight. An embedded developer needed a way to reach the new algorithms from application code, and since a merge in mid-August that path exists and has run against real silicon.
The job list of a TPM is short and load-bearing. Record boot measurements in platform configuration registers for attestation, while firmware commonly enforces Secure Boot by verifying signatures. Generate and hold private keys inside a hardware boundary designed to prevent application software from extracting them. Attest to a remote party to the machine's measured software state. The public-key operations supporting these functions inherit the quantum expiry problem, but a platform's ability to accept quantum-resistant updates depends on its complete boot and update verification chain, not just the algorithms in its TPM.
What shipped: the wolfTPM merge of August 14, the pqc_ctrl tool and testing on physical QVault silicon
The hardware half of the announcement is the QVault TPM, which implements ML-DSA for digital signatures and ML-KEM for key establishment directly in the chip. Both algorithms come out of the United States standards process. ML-DSA is the lattice-based signature scheme of FIPS 204, finalized by NIST in August 2024, and ML-KEM is its key-establishment counterpart from FIPS 203. The Trusted Computing Group folded both into revision 1.85 of the TPM 2.0 library specification, which defines how a TPM exposes them to the outside world: staged signing and verification commands for the large lattice signatures, plus TPM2_Encapsulate and TPM2_Decapsulate for key exchange. wolfSSL added those commands to wolfTPM in a January 2026 engineering release, months before hardware existed to answer them.
The software half arrived on August 14, 2026, when wolfSSL merged pull request 570 into the wolfTPM main branch. The merge adds recognition of SEALSQ as a TPM manufacturer, serial-interface configuration defaults for the part, and a command-line tool the developers call pqc_ctrl. From one interface the tool lists the algorithms a connected TPM supports, runs the chip's self-tests, draws random numbers, reads and extends the platform configuration registers that anchor measured boot, and exercises the full parameter matrix of ML-DSA, Hash-ML-DSA and ML-KEM. According to the joint announcement, the integration was tested two ways, on physical QVault TPM hardware and inside wolfSSL's firmware TPM environment, with ML-DSA signing and verification plus ML-KEM encapsulation and decapsulation exercised at every key strength the standards define.
The two chief technology officers put the design's point plainly. Todd Ouska of wolfSSL noted that running ML-DSA and ML-KEM inside the QVault TPM means the private keys are generated and used in hardware and never leave the TPM boundary. Jean Pierre Enguent of SEALSQ described the pairing as bringing hardware-based post-quantum security closer to deployment and scale. In capability terms the announcement sits squarely on the hardware root of trust branch of the post-quantum migration: the keys that sign firmware, attest platform state and unwrap stored secrets move out of software libraries and into a part designed to resist physical extraction.
Quantum pillar: post-quantum cryptography (roots of trust in hardware). Use posture: defensive. Technology readiness: the QVault TPM and wolfTPM software integration is editorially assessed at TRL 4 of 9. The chip and its software stack ran ML-DSA and ML-KEM together on physical silicon in laboratory integration testing; availability commitments and applicable certification status are not established by the cited evidence, and actual availability and certification remain unverified.
Why the root of trust moves last: soldered chips, provisioned keys and platform lives that outrun the quantum timeline
The defense reading starts with a distinction the migration debate often flattens. Harvest-now-decrypt-later, the pattern in which an adversary collects encrypted traffic today in order to read it once a quantum computer matures, threatens confidentiality immediately, which is why key exchange draws the early attention in every migration plan. Signatures fail on a different clock. A forged firmware signature becomes possible only on the day an adversary actually operates the quantum machine, so stored traffic creates no pressure. The pressure comes from hardware lifecycles instead. A TPM is provisioned at manufacture with the key hierarchy it will defend, soldered to a board, and shipped inside a platform whose service life in a defense fleet commonly runs past thirty years. A transport aircraft accepted in 2028 with an RSA-only root of trust could still depend on RSA firmware verification in the 2050s if its boot and update chain cannot migrate; whether that requires a board-level retrofit depends on the platform architecture.
That arithmetic defines the capability this integration serves. It could let a program office specify a post-quantum TPM as an enabling component for lattice-based firmware-signature verification when the program decides to switch algorithms. Avoiding board rework and a depot visit would require the complete boot and update chain, including firmware, trust anchors and update verification, to support that transition. What a force could gain is defensive and structural: support for quantum-resistant secure boot, device identity and update verification, subject to implementation security and platform integration. The posture field above says defensive for exactly this reason. Everything the part does protects one's own systems, and nothing in a TPM helps anyone break an adversary's cryptography.
The silicon turn is also part of a wider movement this lane has followed. In August, two unrelated chip announcements from a Chinese university team and a Canadian-Taiwanese partnership marked the point where the post-quantum migration reached the silicon layer. A TPM under the Trusted Computing Group specification is a further step of the same kind with a longer lever, because the TPM is a standardized socket sitting in millions of existing designs, from laptops to flight computers. When the socket learns new algorithms, designs that consult it gain an enabling component, but using those algorithms still requires support in the relevant platform software and trust chain.
What stays open after September 3: an availability date, FIPS 140-3 and Common Criteria evaluation, and the side-channel question
The distance between this integration and a program office relying on it is concrete, and it can be listed. First, availability. The announcement's own wording is that QVault is on track to be the first shipping TPM 2.0 device with the v1.85 post-quantum algorithms in silicon, which is a statement about a near future. No sampling or general-availability week appears in the release, so availability commitments are not established by the cited evidence; actual availability and delivery terms remain unverified.
Second, validation. Government procurement of security chips leans on independent evaluation regimes, Common Criteria for the TPM itself and FIPS 140-3 for the cryptographic module inside it, and the September announcement mentions neither. The applicable certification status of the QVault part and its post-quantum functions is not established by the cited evidence and remains unverified.
Third, implementation security. An algorithm that is mathematically sound can still leak its key through the power draw or timing of one specific chip, and the lattice schemes have already taught this lesson in public: when ML-KEM moved into the hardware test lab, published side-channel results showed how wide the gap can be between a standardized algorithm and a hardened part. A TPM invites that scrutiny by design, since resisting physical and electrical probing is the product's entire reason to exist, and passing such scrutiny in public is how a security chip earns a place in defended systems.
A reader watching this capability should look for four signals in order. A shipping date with volume behind it. Evaluation results from an accredited laboratory under either regime above. A second TPM vendor implementing revision 1.85 in silicon, because a specification with one implementation is a product rather than an ecosystem. And the first platform vendor, whether in defense, aerospace or automotive, to write post-quantum TPM silicon into a design specification. Until those arrive, the established facts are narrower and still genuinely useful: the algorithms of FIPS 203 and FIPS 204 now run inside a TPM's hardware boundary, a maintained open-source stack drives them from application code, and both halves have been exercised together on real silicon at every key strength. For the buyers of thirty-year platforms, the last chip on the board to change has started moving.
Sources
Primary source: SEALSQ Corp and wolfSSL Inc., "SEALSQ Announces wolfTPM Support for Its Post-Quantum TPM Technology," joint announcement of September 3, 2026, with statements from Jean Pierre Enguent (SEALSQ) and Todd Ouska (wolfSSL). Engineering detail from wolfTPM pull request 570 (merged August 14, 2026) and wolfSSL's January 2026 TPM 2.0 v1.85 release note; algorithm standard NIST FIPS 204.