Post-Quantum Cryptography on Windows: The Thirty-Year Migration That Just Arrived

1. The 1184-Byte Field#

A Windows endpoint opens a connection to cloudflare.com. In its ClientHello, alongside the 32-byte X25519 public value every TLS 1.3 handshake has carried since 2018, sits a new 1184-byte field whose contents look like uniform noise -- an ML-KEM-768 encapsulation key, the bytes by which Microsoft, Cloudflare, Google, Apple, and OpenSSH have chosen to close a future they cannot yet see ^{[4, 7]}.

Two adversaries are watching the handshake. The first has 2026 compute and cannot break either share. The second has a hypothetical 2040 fault-tolerant quantum computer, breaks the X25519 share trivially via Shor's algorithm, and walks away unable to recover the ML-KEM-768 session key. Why does the handshake hold against the second adversary, and what did it take to make that field 1184 bytes long?

The wire format is concrete and currently shipping. The IETF draft draft-ietf-tls-ecdhe-mlkem-04 (published 8 February 2026) defines three hybrid Supported Groups codepoints in TLS 1.3: X25519MLKEM768 at 0x11EC, SecP256r1MLKEM768 at 0x11EB, and SecP384r1MLKEM1024 at 0x11ED ^{[4, 10]}. The ClientHello key_share extension carries 32 bytes of X25519 public value followed by 1184 bytes of ML-KEM-768 encapsulation key. The ServerHello reply carries 32 bytes of X25519 public value followed by 1088 bytes of ML-KEM-768 ciphertext. Both endpoints derive an X25519 shared secret and an ML-KEM-768 shared secret, concatenate them, and feed both into TLS 1.3's HKDF-Extract per draft-ietf-tls-hybrid-design-16 ^[11]. An adversary who can break either component but not both still learns nothing.

The first internet-scale deployment of the construction landed on October 3, 2022, when Cloudflare turned on hybrid post-quantum key agreement by default for every website and API on its edge ^[13]. Cloudflare's blog post measured the bytes-on-the-wire cost of the deployment as roughly 1.1 KB per handshake added; by March 2024 nearly two percent of all TLS 1.3 connections to Cloudflare's edge negotiated post-quantum key agreement, with double-digit adoption forecast by year-end ^[7]. The Cloudflare default-on date predated FIPS 203's August 2024 finalisation by almost two years, which is why early deployments speak of "Kyber" and "X25519Kyber768Draft00" rather than ML-KEM.

Apple's iMessage PQ3 followed in February 2024, framed as "Level 3" -- post-quantum key establishment plus post-quantum ratcheting ^[14]. By May 2026, Microsoft, Google, OpenSSH, and Signal have all shipped or announced hybrid post-quantum key agreement; Section 7 catalogues the per-vendor deployments verbatim, anchored to each vendor's own release artifact ^{[7, 15, 16]}.

This article delivers two promises. The first is algorithm-level: by the end of Section 5 you will know ML-KEM, ML-DSA, and SLH-DSA well enough to reason about parameter-set choices, side-channel posture, and FIPS-mandated byte counts. The second is platform-level: by the end of Section 6 you will know which CNG identifier ships in which SymCrypt release, which Schannel toggle gates X25519MLKEM768 on 24H2, and which Windows surfaces (Schannel, AD CS, .NET 10, Azure Key Vault) carry PQC in May 2026 and which (IKEv2, SMB, RDP, BitLocker network unlock, Kerberos PKINIT, Windows Hello attestation) do not.

Every line of code, every parameter set, every byte of that 1184-byte field has a thirty-year story behind it. To understand what shipped, we start where it began -- with a 1994 paper that put a clock on every public-key cryptosystem then in production.

2. Historical Origins#

Why is replacing public-key cryptography hard? Because in 1976, Whitfield Diffie and Martin Hellman defined the primitive that everything since has imitated. Their "New Directions in Cryptography" paper, in IEEE Transactions on Information Theory 22(6), introduced the asymmetric key-agreement model ^[17]: two parties exchange public values, derive a shared secret, and never share the underlying private state. The shared secret was the discrete logarithm of a public element in a finite group. Every public-key construction that followed -- RSA (1977), the Diffie-Hellman variants, DSA (1991), ECDSA and the elliptic-curve variants (mid-1980s into the 1990s, with X25519 standardised in RFC 7748 in 2016) -- inherited one of two hard problems: integer factoring, or the discrete logarithm in some abelian group ^[18].

Eighteen years later, Peter Shor at Bell Labs found a polynomial-time quantum algorithm for both ^[19]. The arXiv preprint quant-ph/9508027 dates to August 1995; the journal version appeared as "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer" in SIAM Journal on Scientific and Statistical Computing 26 (1997) 1484. Shor's algorithm requires a fault-tolerant quantum computer with thousands of logical qubits -- the kind of machine that does not yet exist, and may never exist in some accounts. But if it does exist, RSA, DH, DSA, ECDSA, and ECDH all collapse simultaneously. Not weakened; broken. Doubling key sizes does not help; the algorithm's runtime is polynomial in the key length.

Two years later, Lov Grover (also at Bell Labs) published the symmetric-key counterpart. Grover's algorithm searches an unstructured database of N items in O(sqrt(N)) quantum steps ^[20]. Applied to AES-128, Grover reduces the effective key strength to roughly $2^{64}$ quantum-search steps -- comparable to a 64-bit symmetric key. Applied to AES-256, it leaves 128 bits of security. The asymmetric lane is fatal; the symmetric lane is a parameter bump. This is why the entire post-quantum programme is a public-key replacement programme, not a symmetric one. The standard policy response to Grover is to double the symmetric key size. AES-256 retains 128 bits of post-quantum security; SHA-384 retains 192 bits of preimage resistance; SHA-512 retains 256 bits. CNSA 2.0 mandates AES-256 and SHA-384 specifically for this reason ^[21]. Grover-style speedups do not generalise to AEAD constructions in the same way the asymmetric collapse does; the cost of doubling is structural and easy to absorb, which is why no one tries to invent a "post-quantum AES."

If Shor and Grover are 1994-1996 results, why is replacing public-key cryptography not a 2040 problem? Michele Mosca's 2015 ePrint 2015/1075 named the deadline. Mosca's inequality is one line:

$X + Y > Z$

where X is the security shelf-life of the data (how long today's traffic must remain confidential), Y is the migration time (how long it takes to deploy quantum-safe systems), and Z is the time until a cryptographically relevant quantum computer arrives. If X + Y exceeds Z, the adversary harvesting traffic today wins regardless of when the quantum computer arrives ^[12].

"If the security shelf-life of your data plus the migration time to deploy quantum-safe systems exceeds the time-to-quantum-computer, the adversary harvesting traffic today wins." -- the X + Y > Z framing, Mosca (eprint 2015/1075).

On September 7, 2022, the U.S. National Security Agency turned Mosca's inequality into national-security policy. The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the algorithm list the NSA requires for protecting U.S. National Security Systems ^{[22, 21]}. The current revision (May 30, 2025) names ML-KEM-1024 for key establishment, ML-DSA-87 for general digital signatures, LMS and XMSS for firmware signing, AES-256 for symmetric encryption, and SHA-384 for hashing. The policy carries four dates that drive every U.S. vendor roadmap including Microsoft's: acquisition preference for PQC in new National Security Systems by January 1, 2027; legacy-algorithm phase-out beginning December 31, 2030; mandatory PQC adoption by December 31, 2031; and disallowance of RSA / ECDSA after 2035.

Shor's algorithm requires a fault-tolerant quantum computer that does not yet exist. So why isn't the migration easy? Because cryptographers tried to replace the asymmetric primitive for thirty years before this paper -- and every early attempt failed in a different way.

3. Early Approaches and Their Failures#

Three rejected family trees and one almost-survivor explain why ML-KEM looks the way it does in 2026. Each was tried; each failed in a specific way; the failure shaped what survived.

McEliece (1978) is the oldest post-quantum proposal still under active study. Robert McEliece's construction uses the hardness of decoding a general linear code -- specifically, a binary Goppa code disguised by random permutations and a scrambling matrix ^[23]. The cryptosystem has survived forty-eight years of cryptanalysis with no structural break; its security argument is one of the most conservative in cryptography. The cost is the public key. Classic McEliece at NIST security category 1 has public keys of roughly 261 kilobytes; at category 5, about 1 megabyte ^[24]. That size makes it unusable in TLS, where the entire ClientHello must fit in one or two IP packets. Classic McEliece survives as a Round-4 NIST candidate; it was not selected for FIPS standardisation because of the key-size constraint, but is widely cited as the conservative fallback for long-term archival key wrapping.

HFE and multivariate cryptography (1996) form the most thoroughly broken family. Jacques Patarin's Hidden Field Equations (HFE) hide the structure of a univariate polynomial over a small extension field by composing with random linear transformations on each side. Kipnis and Shamir broke the original HFE construction in 1999 ^[25]. The descendant scheme Rainbow advanced through three NIST rounds before Ward Beullens published "Breaking Rainbow Takes a Weekend on a Laptop" in eprint 2022/214 on 25 February 2022, recovering Rainbow's secret key in 53 hours on a commodity laptop ^[26]. 53 hours on a commodity laptop is the visceral data point. Rainbow had been a NIST third-round signature finalist; one paper, one weekend of CPU time, retired it. Beullens' result is now the canonical example in PQC pedagogy of how a cryptographic finalist can be retired by an algorithmic insight that nobody noticed during seven years of NIST evaluation. The multivariate signature lane is effectively closed in 2026, with the partial exception of small specialised constructions (UOV-style schemes) that NIST is considering in the additional-signatures onramp ^[27].

NTRU (1996) is the founding lattice cryptosystem. Jeffrey Hoffstein, Jill Pipher, and Joseph Silverman presented "NTRU: A ring-based public key cryptosystem" at ANTS-III in 1998 ^[28]. The construction works in a polynomial ring $R = \mathbb{Z}[X]/(X^n - 1)$ and offers public keys of roughly 1-2 kilobytes -- the first lattice cryptosystem with sizes competitive with RSA. NTRU was patent-encumbered for two decades (US Patents 6,081,597 and 6,144,740 expired in the late 2010s) ^[29], which kept it out of standards work for the formative years. Falcon, the NIST-selected lattice signature scheme that became FIPS 206 draft, inherits the NTRU lattice structure directly.

SIDH and SIKE (2011-2022) were the most efficient post-quantum proposal by public-key size. Supersingular Isogeny Diffie-Hellman, introduced by Jao and De Feo in 2011 ^[30], achieved public keys of roughly 330 bytes at category 1 ^[31] -- smaller than ML-KEM-512's 800 bytes. NIST advanced SIKE to the fourth round of evaluation on 5 July 2022 ^[32]. On 30 July 2022, twenty-five days later, Wouter Castryck and Thomas Decru published "An efficient key recovery attack on SIDH," recovering SIKEp434's secret key in about ten minutes on a single CPU core via a torsion-point exploitation of Kani's reducibility criterion ^[33]. The higher-security parameter set SIKEp751 (NIST category 5) fell in roughly three hours on the same hardware. A concurrent paper by Maino and Martindale extended the attack to arbitrary starting curves ^[34]. One paper, one month, the entire isogeny lane retired. SIKE is the canonical example of why NIST's portfolio rests on multiple unrelated hardness assumptions.

flowchart TD
PQ["Post-Quantum Cryptography"]
PQ --> Lat["Lattice
(LWE, Module-LWE, NTRU)"]
PQ --> Code["Code-based
(Goppa, Quasi-Cyclic)"]
PQ --> Multi["Multivariate
(HFE, Rainbow)"]
PQ --> Hash["Hash-based
(XMSS, LMS, SPHINCS+)"]
PQ --> Iso["Isogeny
(SIDH, SIKE)"]
Lat --> LatV["ACTIVE: ML-KEM, ML-DSA, Falcon"]
Code --> CodeV["NICHE: HQC, Classic McEliece"]
Multi --> MultiV["DEAD: Rainbow broken 2022"]
Hash --> HashV["ACTIVE: SLH-DSA, LMS, XMSS"]
Iso --> IsoV["DEAD: SIDH/SIKE broken 2022"]

The portfolio lesson lands here, and it is the article's first aha moment. Post-quantum cryptography is not a single family; it is a portfolio across multiple hardness assumptions, because each one has been broken at least once during the modern standardisation effort. The Rainbow break and the SIKE break both happened during the NIST competition, in 2022, on candidates that NIST had advanced for further study. This is why the eventual slate -- ML-KEM (lattice) plus SLH-DSA (hash) -- sits on two structurally unrelated foundations. A single mathematical break cannot retire the whole programme.

Lattices survived. But the lattices of 2005 had megabyte-scale public keys, unusable in TLS. How those keys were compressed to kilobytes is the story of the next section.

4. The Evolution -- Lattices in Five Generations#

In 2005, Oded Regev published a paper that gave lattice cryptography the mathematical foundation RSA never had. By 2010, the same idea had been compressed by a factor of n via the Number Theoretic Transform; by 2015 it had been generalised with a parameter knob that let one base ring serve every security category; by 2024 it was a Federal Information Processing Standard. This section walks the generation-by-generation story of how lattices got from impossible to inevitable.

Generation 0 (1976-1994): the classical baseline#

Diffie-Hellman, RSA, DSA, ECDH, ECDSA. Five primitives over four decades, all on discrete-log-style hardness in one group or another, all retired in one stroke by Shor's algorithm. The classical baseline is what PQC replaces. Nothing about post-quantum cryptography innovates on the symmetric side; AES and SHA-2 survive with parameter increases.

Generation 1 (1996-2009): plural hard problems, mostly impractical#

Miklos Ajtai's 1996 STOC paper "Generating Hard Instances of Lattice Problems" introduced the first worst-case-to-average-case reduction for a lattice problem (the Short Integer Solution problem) ^[37]. The reduction was a foundational theoretical result; the cryptographic constructions built from it had public keys in the megabytes.

Nine years later, Oded Regev published "On Lattices, Learning with Errors, Random Linear Codes, and Cryptography" at STOC 2005 ^[35]. The Learning With Errors problem is simple to state.

LWE was the cryptographic breakthrough. The construction was clean, the reduction tied average-case security to worst-case lattice hardness, and the resulting cryptosystem was simple enough that any cryptographer could implement it. But the public key was a full $n \times n$ matrix over $\mathbb{Z}_q$ -- $O(n^2 \log q)$ bits. At the parameter sizes needed for 128-bit security, that meant several megabytes of public key. Unusable in TLS, unusable in X.509, unusable in any deployment that touches the wire.

Generation 2 (2010-2017): the ring-LWE and module-LWE compression#

The compression that made lattices deployable was a single algebraic move. Lift LWE from $\mathbb{Z}_q$ to a polynomial ring. Lyubashevsky, Peikert, and Regev's 2010 paper "On Ideal Lattices and Learning with Errors over Rings" (eprint 2012/230) introduced Ring-LWE ^[38]. The underlying ring is $R_q = \mathbb{Z}_q[X]/(X^n + 1)$ for $n$ a power of two; the secret and noise are now polynomials in $R_q$ rather than vectors over $\mathbb{Z}_q$. Multiplying two ring elements becomes a polynomial multiplication, which the Number Theoretic Transform reduces from $O(n^2)$ scalar multiplications to $O(n \log n)$.

Public keys dropped from megabytes to kilobytes. The 2010 lift is the load-bearing intellectual move; everything subsequent is engineering.

Adeline Langlois and Damien Stehle's 2012/2015 Module-LWE paper added a parameter knob ^[40]. Module-LWE works over $R_q$ rings of fixed degree $n$ (typically 256 in ML-KEM), but lifts the secret and matrix into module rank $k$: $A$ is a $k \times k$ matrix of ring elements, $s$ is a $k$-vector of ring elements. Now one base ring of degree 256 can serve every NIST security category by varying $k \in \{2, 3, 4\}$. ML-KEM-512 uses $k = 2$; ML-KEM-768 uses $k = 3$; ML-KEM-1024 uses $k = 4$. The compiler-style metaphor is exact: Ring-LWE was an over-fitted special case, Module-LWE generalises it.

The first TLS deployment of a Ring-LWE key exchange landed in 2014, and Microsoft Research was at the centre of it.

Google's Chrome team deployed the construction in production first. CECPQ1 ("Combined Elliptic-Curve and Post-Quantum 1") shipped in Chrome Canary in July 2016, combining X25519 with NewHope ^[45]. NewHope was a Ring-LWE construction by Alkim, Ducas, Poppelmann, and Schwabe; CECPQ1 ran for several months as an experiment, measured the cost of an extra ~2 KB on each handshake, and was retired. CECPQ2 replaced it with NTRU-HRSS -- the announcement post by Adam Langley names the lineage explicitly ("CECPQ1 was the experiment ... It's about time for CECPQ2") and the NTRU-HRSS basis -- and was wound down in 2022 as Chrome migrated to the X25519+Kyber-768 hybrid following NIST's July 2022 selection ^{[46, 7]}. The parallel CECPQ2b experiment paired X25519 with SIKE; the Castryck-Decru break that same month retired CECPQ2b along with the entire isogeny lane. The Cloudflare-Microsoft-Google triad has been iterating in production since.

Generation 3 (2017-2022): the NIST competition#

NIST issued the formal call for post-quantum public-key submissions in December 2016. Eighty-two submissions arrived by the November 2017 deadline; sixty-nine were judged complete and proper, advancing into Round 1 (announced December 2017; narrowed to 26 in Round 2, January 2019) ^[47]. The 82-vs-69 discrepancy is a frequent source of confusion in PQC pedagogy. Eighty-two total submissions, sixty-nine deemed "complete and proper" by NIST's intake review, advanced to Round 1. The remaining thirteen had documentation defects or were withdrawn. Wikipedia's "NIST Post-Quantum Cryptography Standardization" article spells out both numbers verbatim ^[47]. The field narrowed to 26 algorithms in Round 2 (January 2019), then to 7 finalists plus 8 alternates in Round 3 (July 2020). NIST IR 8413 (July 2022) is the canonical status report on Round 3 ^[48].

On 5 July 2022, NIST announced the first four standardisation selections: CRYSTALS-Kyber for key encapsulation, plus CRYSTALS-Dilithium, FALCON, and SPHINCS+ for signatures ^[32]. Three were lattice schemes; one (SPHINCS+) was hash-based. The same announcement moved Classic McEliece, BIKE, HQC, and SIKE to a fourth round for further evaluation. Twenty-five days later, the Castryck-Decru attack retired SIKE. NIST IR 8545 documents the eventual fourth-round selection of HQC (announced 7 March 2025) over BIKE, with Classic McEliece left as a candidate for niche-use standardisation due to its key size ^[49].

gantt
dateFormat YYYY
axisFormat %Y
section Algorithm research
Diffie-Hellman           :milestone, dh, 1976, 0
Shor's algorithm         :milestone, shor, 1994, 0
NTRU                     :milestone, ntru, 1996, 0
Regev LWE                :milestone, lwe, 2005, 0
Ring-LWE (LPR)           :milestone, rlwe, 2010, 0
Module-LWE               :milestone, mlwe, 2012, 0
BCNS / Frodo / NewHope   :milestone, bcns, 2014, 0
section NIST process
PQC call announced       :milestone, call, 2016, 0
Round 1 (69 candidates)  :milestone, r1, 2017, 0
Round 2 (26 candidates)  :milestone, r2, 2019, 0
Round 3 finalists        :milestone, r3, 2020, 0
Selections + Round 4     :milestone, sel, 2022, 0
Rainbow + SIKE broken    :milestone, brk, 2022, 0
FIPS 203 / 204 / 205     :milestone, fips, 2024, 0
HQC selected             :milestone, hqc, 2025, 0
section Windows shipping
SymCrypt v103.5.0 ML-KEM :milestone, sc1, 2024, 0
Insider Canary CNG PQ    :milestone, can, 2025, 0
.NET 10 GA               :milestone, dn, 2025, 0
Schannel X25519MLKEM768  :milestone, sch, 2026, 0
TPM 2.0 v1.85 PQC        :milestone, tpm, 2026, 0

Generation 4 (2023-2024): standardisation#

The draft FIPS standards published in August 2023; the final versions landed on 13 August 2024, when the Secretary of Commerce approved FIPS 203, FIPS 204, and FIPS 205 ^{[1, 50]}. Names changed in the transition: CRYSTALS-Kyber ^[51] became Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM); CRYSTALS-Dilithium became Module-Lattice-Based Digital Signature Algorithm (ML-DSA); SPHINCS+ ^[52] became Stateless Hash-Based Digital Signature Algorithm (SLH-DSA). The renaming was deliberate; NIST wanted standard names that described the construction rather than the project. Falcon's standardisation slipped to FIPS 206 in draft, principally because the floating-point Gaussian sampler required for Falcon's compact signatures is unusually hard to make both fast and constant-time ^{[27, 53]}.

Generation 5 (2024-2026): shipping on Windows#

SymCrypt v103.5.0 added ML-KEM "per final FIPS 203" along with XMSS and XMSS^MT ^[2]. Subsequent versions added LMS (v103.6.0), ML-DSA (v103.7.0), FIPS-approved-services indicator (v103.8.0), ML-DSA External-Mu sign/verify (v103.9.0), FIPS CAST plus ML-KEM/ML-DSA keygen pairwise consistency tests (v103.9.1), and Composite ML-KEM (v103.11.0). The Windows Insider Canary channel exposed the CNG identifiers in May 2025 ^[54]. .NET 10 (GA November 2025) shipped managed types System.Security.Cryptography.MLKem, MLKemCng, MLDsa, MLDsaCng ^{[55, 56, 57]}. Schannel hybrid TLS 1.3 X25519MLKEM768 reached Server 2025 and 24H2 in preview behind Group Policy in early 2026.

The competition is over. The standards are published. The SymCrypt versions are shipping. We have arrived at the moment where the algorithm internals matter -- because every Windows engineer now writes code against BCRYPT_MLKEM_ALG_HANDLE, and code that uses an algorithm should know how it works.

5. The Breakthrough -- ML-KEM, ML-DSA, SLH-DSA at Engineer Depth#

Three FIPS standards. Three algorithms. Three Windows API surfaces. Each rests on a different hardness assumption. Each has its own parameter zoo, key sizes, and side-channel surface. This section walks all three at the level a Windows engineer needs to make procurement, audit, and migration decisions.

5.1 ML-KEM (FIPS 203) -- the default KEM#

ML-KEM is the only NIST-finalised key-encapsulation mechanism. It is the encryption primitive of the post-quantum era on Windows. The algebra is Module-LWE / Module-LWR over $R_q = \mathbb{Z}_q[X]/(X^{256} + 1)$ with $q = 3329$ -- a 12-bit prime chosen to make NTT arithmetic fast on 16-bit and 32-bit lanes ^[39]. The base ring has degree 256; the module rank $k$ selects the parameter set.

The byte counts in the table are verbatim from the FIPS 203 standard ^{[58, 39, 59]}. Cloudflare's October 2022 deployment and Schannel's X25519MLKEM768 both target ML-KEM-768 specifically -- the category-3 sweet spot that survives even an aggressive cryptanalytic improvement against Module-LWE ^{[13, 4]}. Apple's PQ3 splits its parameter selection: ML-KEM-1024 for the initial key exchange and Kyber-768 for the ongoing asymmetric ratchet ^[14]. OpenSSH 9.0+ deployed a different post-quantum primitive entirely -- Streamlined NTRU Prime in sntrup761x25519-sha512 ^[60] -- and OpenSSH 9.9 (released 19 September 2024) added the ML-KEM-768-based group mlkem768x25519-sha256 available by default alongside it ^[16].

ML-KEM has three operations: KeyGen produces $(ek, dk)$; Encaps(ek) produces $(K, c)$ where $K$ is the 32-byte shared secret and $c$ is the ciphertext; Decaps(dk, c) recomputes $K$. The CNG surface mirrors this exactly. The canonical Microsoft idiom (from Microsoft Learn's CNG ML-KEM examples, currently marked prerelease) is BCryptGenerateKeyPair with the pseudo-handle BCRYPT_MLKEM_ALG_HANDLE, followed by BCryptSetProperty setting BCRYPT_PARAMETER_SET_NAME to BCRYPT_MLKEM_PARAMETER_SET_768, followed by BCryptFinalizeKeyPair, followed by BCryptExportKey to extract the encapsulation key as a BCRYPT_MLKEM_ENCAPSULATION_BLOB ^[3]. The new verbs BCryptEncapsulate and BCryptDecapsulate complete the picture; neither existed in CNG before the ML-KEM surface was added.

sequenceDiagram
participant C as Client (Windows / Schannel)
participant S as Server (Cloudflare / IIS)
C->>S: ClientHello key_share = X25519 (32B) || ML-KEM-768 ek (1184B)
Note over S: Generates X25519 keypair
Note over S: Computes ML-KEM Encaps(ek)
Note over S: Yields ct and K_pq
S->>C: ServerHello key_share = X25519 (32B) || ML-KEM-768 ct (1088B)
Note over C: Derives ECDH shared secret K_ecdh
Note over C: Computes ML-KEM Decaps for K_pq
Note over C,S: HKDF-Extract IKM = K_ecdh concat K_pq
Note over C,S: Yields TLS 1.3 traffic secrets

The internal construction of ML-KEM combines an IND-CPA-secure public-key encryption scheme called K-PKE with the Fujisaki-Okamoto-Hofheinz transform to produce an IND-CCA2 KEM. K-PKE is a Regev-style encryption with module structure; the encryption is illustrative-grade simple.

// Illustrative ML-KEM K-PKE encryption.
// The FIPS 203 standard is the normative source for byte-exact operations.
// q = 3329, n = 256, ring R_q = Z_q[X] / (X^n + 1), module rank k in {2, 3, 4}.
function kpkeEncrypt(ek: PublicKey, message: number[], seed: Uint8Array) {
const { A, t, k } = ek;           // A is k x k matrix in R_q, t is k-vector in R_q
const r  = sampleSmallCBD(seed, k);     // r:  k-vector, centred binomial noise
const e1 = sampleSmallCBD(seed, k);     // e1: k-vector, fresh noise
const e2 = sampleSmallSingle(seed);     // e2: scalar polynomial, fresh noise
const u = ringMatVecMul(transpose(A), r);
addInPlace(u, e1);                       // u = A^T r + e1
const v = ringDot(t, r);                 // v = t . r
addInPlace(v, e2);                       // v = t.r + e2
const mEncoded = encodeMessage(message); // 256-bit message -> R_q element
addInPlace(v, mEncoded);                 // v += Encode(message)
return { u, v };                          // ciphertext (u in R_q^k, v in R_q)
}

The IND-CCA2 wrapper that becomes ML-KEM proper is the FO transform: hash the message and randomness into the encapsulation, then re-encrypt during decapsulation and reject if the ciphertext does not match. Decapsulation on a tampered ciphertext returns a pseudorandom shared secret derived from the secret key -- implicit rejection -- rather than an error code that an attacker could observe. This is what gives ML-KEM CCA2 security suitable for static keys in TLS, X.509, and CNG.

5.2 ML-DSA (FIPS 204) -- the default lattice signature#

ML-DSA is the general-purpose lattice signature scheme. Same base ring of degree 256 as ML-KEM, but with a different prime: $q = 8380417$, a 23-bit prime ^[5]. The disparity is intentional; ML-KEM and ML-DSA do not share keys, so their NTT parameter choices are independently optimised. The construction is Fiat-Shamir-with-aborts over Module-LWE and Module-SIS.

Numbers verbatim from FIPS 204 ^{[61, 5]}. CNSA 2.0 selects ML-DSA-87 specifically as the general-signature algorithm for U.S. National Security Systems ^[21].

flowchart TD
Start["Begin sign(message, sk)"] --> Sample["Sample masking vector y (small ball)"]
Sample --> Commit["Compute w = Ay in R_q"]
Commit --> Hash["c = H(message || HighBits(w))"]
Hash --> Resp["Compute response z = y + c<em>s_1"]
Resp --> Check{"||z||_inf < bound?
||LowBits(w - c</em>s_2)||_inf < bound?"}
Check -->|no| Sample
Check -->|yes| Out["Return signature (z, c, h)"]

ML-DSA-87's 4595-byte signature is the bottom-of-stack constraint that drives every TPM and Pluton roadmap ^[5]. The default TPM 2.0 command and response buffers, fixed by historical compatibility decisions, are 4096 bytes. ML-DSA-65's 3293-byte signature fits; ML-DSA-87's 4595-byte signature does not. The TCG TPM 2.0 Library Specification v1.85 (March 2026) introduces a streaming Sign/Verify family and ML-KEM Encapsulate/Decapsulate opcodes that resolve the overflow; the full opcode inventory and the new TPM2B_KEM_CIPHERTEXT / TPM2B_SHARED_SECRET / TPM_ST_MESSAGE_VERIFIED structures are catalogued in Section 9.1 ^[6]. Until v1.85 chips ship in retail volume, ML-DSA-87 cannot live on a commodity TPM. Cross-reference the TPM and Pluton sibling articles for the silicon-side mechanics. Pluton's firmware-update agility -- the firmware ships through the existing Microsoft Update channel -- is the reason Pluton can move on PQ adoption faster than discrete TPM 2.0 chips, whose firmware updates depend on each TPM vendor's release cadence. The cross-reference to the Pluton sibling article in this series spells out the firmware-update mechanism in detail ^[44].

The CNG surface mirrors ML-KEM's idiom with the signature primitives. BCryptOpenAlgorithmProvider with BCRYPT_MLDSA_ALGORITHM = L"ML-DSA" and MS_PRIMITIVE_PROVIDER returns a handle; BCryptSetProperty selects BCRYPT_MLDSA_PARAMETER_SET_44, _65, or _87; BCryptGenerateKeyPair plus BCryptFinalizeKeyPair produces the keypair; key blobs are BCRYPT_PQDSA_PUBLIC_KEY_BLOB and BCRYPT_PQDSA_PRIVATE_KEY_BLOB; signing and verification go through BCryptSignHash and BCryptVerifySignature with a BCRYPT_PQDSA_PADDING_INFO struct that selects pure-mode or pre-hash-mode (External-Mu, per FIPS 204's HashML-DSA variants) and carries an optional context string ^[63].

// Illustrative ML-DSA signing.
// Constants gamma1, gamma2, beta are parameter-set dependent.
function mlDsaSign(message: Uint8Array, sk: SecretKey): Signature {
const { A, s1, s2, t0 } = sk;
let attempt = 0;
while (attempt < 1000) {
  attempt++;
  const y  = sampleMaskingVector(gamma1);     // y in R_q^l, ||y||_inf < gamma1
  const w  = ringMatVecMul(A, y);              // w = A*y in R_q^k
  const w1 = highBits(w, 2 * gamma2);
  const c  = hashToChallenge(message, w1);     // c in B_tau
  const z  = addVec(y, scalarMul(c, s1));      // z = y + c*s1
  if (infNorm(z) >= gamma1 - beta) continue;   // reject if response too large
  const r0 = lowBits(subVec(w, scalarMul(c, s2)), 2 * gamma2);
  if (infNorm(r0) >= gamma2 - beta) continue;  // reject if low bits leak
  return { z, c, h: makeHint(t0, c, w) };
}
throw new Error("ML-DSA signing exceeded attempt budget (statistically improbable)");
}

ML-DSA sign time on x86-64 is in the low single-digit milliseconds; verify time is in the hundreds of microseconds. The rejection-sampling loop creates a measurable variance in sign-time -- a side channel that secret-key recovery exploits if the loop count, branch, or memory-access pattern leak.

5.3 SLH-DSA (FIPS 205) -- the conservative hash-based signature#

SLH-DSA's security rests on hash-function security alone. No lattice. No code. No multivariate. No isogeny. Just preimage resistance and collision resistance of an underlying hash function (SHA-2 or SHAKE). If every algebraic post-quantum assumption breaks tomorrow, hash-based signatures still hold. The cost is signature size and signing time ^{[64, 65]}.

The construction is a hypertree -- a tree of XMSS subtrees, with WOTS+ (Winternitz One-Time Signature Plus) leaves at each subtree level, and FORS (Forest of Random Subsets) few-time signatures at the bottom layer signing the actual message. The hypertree is sampled fresh per signature via a pseudorandom function of the message, which is what makes SPHINCS+ -> SLH-DSA stateless. Unlike LMS or XMSS, which require the signer to track a counter (because re-using a one-time key reveals the secret), SLH-DSA derives the leaf address from the message hash and a per-signature randomness; no signer state survives between signatures.

flowchart TD
Root["SLH-DSA public key = root of top XMSS tree (32-64 bytes)"]
Root --> T1["Top XMSS subtree (WOTS+ leaves)"]
T1 --> T2["Middle XMSS subtrees (WOTS+ leaves)"]
T2 --> T3["More XMSS layers (parameter d controls depth)"]
T3 --> Bot["Bottom XMSS subtree"]
Bot --> FORS["FORS forest (k trees of depth t)"]
FORS --> Msg["Message digest derived from per-signature randomness"]

Twelve parameter sets ship in FIPS 205: every combination of {SHA2, SHAKE} × {128s, 128f, 192s, 192f, 256s, 256f} where s is "small signature, slow signing" and f is "fast signing, larger signature" ^{[66, 64]}. Public keys are 32-64 bytes; signatures range from 7,856 bytes (SLH-DSA-SHA2-128s) to 49,856 bytes (SLH-DSA-SHA2-256f). Signing time ranges from ~10 ms (SLH-DSA-SHA2-128f) to several hundred milliseconds at the high end. The use case is code signing: sign once, verify a billion times. CNG plans BCRYPT_SLHDSA_ALGORITHM with the same BCRYPT_PQDSA_KEY_BLOB and BCRYPT_PQDSA_PADDING_INFO plumbing as ML-DSA ^[67].

ML-KEM is the only NIST-finalised KEM. ML-DSA is the general-purpose lattice signature. SLH-DSA is the conservative hash-based fallback. They are not interchangeable; an engineer picks one (or all three) per use case. Hybrid TLS key agreement uses ML-KEM-768; X.509 end-entity signatures use ML-DSA-65 or ML-DSA-87; long-lived code signing where signature size is tolerable uses SLH-DSA; firmware signing with build-counter discipline uses LMS or XMSS.

All three algorithms are FIPS-standardised. All three have CNG identifiers in Insider Canary builds. But until SymCrypt ships them, until Schannel negotiates them, until AD CS issues certificates that carry them, none of this exists for the Windows engineer in production. So what does Microsoft actually ship in May 2026?

6. State of the Art -- What Windows Ships in May 2026#

Algorithms are not products. Microsoft ships SymCrypt, CNG, NCrypt, Schannel, .NET, AD CS, CertEnroll, and Authenticode -- and post-quantum cryptography arrives in each surface on its own clock.

SymCrypt -- the FIPS-validated foundation#

SymCrypt is Microsoft's primary cryptographic library. The repository description states it directly: "SymCrypt is the core cryptographic function library currently used by Windows ... started in late 2006 with the first sources committed in Feb 2007 ... Since the 1703 release of Windows 10, SymCrypt has been the primary crypto library for all algorithms in Windows" ^[68]. Microsoft open-sourced SymCrypt in March 2019 ^[68]. It is the FIPS 140-validated module that backs CNG; if CNG ships a post-quantum algorithm on Windows, SymCrypt is the implementation underneath.

The SymCrypt release history through May 2026 is verbatim from the public CHANGELOG ^[2].

The SymCrypt releases page lists the binary artefacts at each version for Windows AMD64/ARM64, generic Linux AMD64/ARM64, and OpenEnclave AMD64 ^[70]. Microsoft has also begun rewriting SymCrypt in Rust; the Microsoft Research blog post describes the rationale (memory safety in a TCB-grade library) and confirms the algorithm coverage includes "AES-GCM, SHA, ECDSA, and the more recent post-quantum algorithms ML-KEM and ML-DSA" ^[69].

CNG, NCrypt, and .NET 10#

The Windows Insider Canary channel introduced post-quantum CNG identifiers in May 2025 ^[54]. The new pseudo-handle BCRYPT_MLKEM_ALG_HANDLE, the algorithm-name strings BCRYPT_MLKEM_ALGORITHM = L"ML-KEM" and BCRYPT_MLDSA_ALGORITHM = L"ML-DSA", the planned BCRYPT_SLHDSA_ALGORITHM, and the existing BCRYPT_LMS_ALGORITHM are documented on the CNG Algorithm Identifiers page ^[67]. NCrypt KSPs expose the same algorithm names; an application that previously called NCryptCreatePersistedKey against an RSA KSP can do the equivalent against an ML-KEM KSP with no plumbing changes beyond the algorithm identifier and parameter set.

.NET 10 (GA November 2025) exposes the managed surface ^[55]. System.Security.Cryptography.MLKem is an abstract base class with KeyGen, Encapsulate, Decapsulate, ExportEncapsulationKey, and ImportEncapsulationKey instance methods ^[56]. MLKemCng is the CNG-backed concrete subclass that forwards to SymCrypt via CNG ^[57]. Equivalent MLDsa / MLDsaCng and SlhDsa / SlhDsaCng pairs cover the signature primitives. The *Cng subclasses are sealed; the abstract base classes are subclassable for non-CNG implementations.

Schannel hybrid TLS 1.3#

Schannel is the Windows TLS stack. The hybrid TLS 1.3 Supported Groups are defined by IETF draft-ietf-tls-ecdhe-mlkem-04 (8 February 2026) ^[4]:

The IANA TLS Parameters registry lists all three (registry last updated 2026-04-29) ^[10]. Schannel preview on 24H2 and Server 2025 gates these behind Group Policy in early 2026; default-on is the May 2026 -> November 2026 milestone per Microsoft's Quantum-Safe Security blog ^[44]. The actual TLS key schedule combines the two shared secrets with a concatenation combiner: $\text{HKDF-Extract}(\text{salt} = 0, \text{IKM} = K_{\text{ecdh}} \| K_{\text{pq}})$, per draft-ietf-tls-hybrid-design-16 ^[11]. The combiner is correct as long as either component is unbroken; an adversary breaking only ECDH cannot recover the session key, nor can one who breaks only ML-KEM.

AD CS, CertEnroll, and Azure Key Vault#

The X.509 side of the migration lags TLS by a year. Active Directory Certificate Services supports ML-DSA certificate templates via the CertEnroll API, conditional on a CSP or KSP exposing BCRYPT_MLDSA_ALGORITHM. The practical migration mechanism is composite signatures per draft-ietf-lamps-pq-composite-sigs-19 (21 April 2026), which combines ML-DSA with RSA-PKCS#1-v1.5, RSA-PSS, ECDSA, Ed25519, or Ed448 in a single SubjectPublicKeyInfo and requires both components to verify ^[71]. Downlevel verifiers that do not recognise the composite OID can still validate the inner classical chain; uplevel verifiers validate both. Pure post-quantum X.509 chains are in preview for closed pilots, not in general use. Azure Key Vault's managed-HSM exposes post-quantum keys in preview for Q1 2026.

flowchart TD
ISV["ISV applications (browsers, services, SDKs)"]
Schannel["Schannel (TLS 1.3 with X25519MLKEM768)"]
ADCS["AD CS / CertEnroll (ML-DSA, composite signatures)"]
DotNet[".NET 10 (MLKem, MLDsa, SlhDsa managed types)"]
KSP["NCrypt KSPs (Microsoft Software KSP, Pluton KSP, vendor KSPs)"]
CNG["CNG Win32 API (BCryptEncapsulate, BCryptSignHash, ...)"]
SymCrypt["SymCrypt (FIPS-validated, primary crypto library since Win10 1703)"]
HW["Hardware (CPU AES-NI, Pluton, TPM 2.0, IOMMU)"]
ISV --> Schannel
ISV --> ADCS
ISV --> DotNet
Schannel --> CNG
ADCS --> CNG
DotNet --> CNG
Schannel --> KSP
KSP --> CNG
CNG --> SymCrypt
SymCrypt --> HW

What is NOT shipping in May 2026#

The honest accounting matters. Several load-bearing Windows surfaces have no post-quantum path as of May 2026.

CNSA 2.0 -- the policy clock#

CNSA 2.0 turns the technical timeline into an acquisition mandate. The four authoritative dates from the May 30, 2025 revision of the Cybersecurity Advisory ^[21]:

ML-KEM is the only NIST-finalised KEM. ML-DSA and SLH-DSA are the only NIST-finalised signature schemes. But the NIST portfolio still has Falcon in FIPS 206 draft, HQC for code-based diversification, LMS / XMSS for firmware -- and the IETF still has composite signatures and hybrid TLS layered on top. What else is shipping, and why?

7. Competing Approaches -- Inside the Lattice Lane and Outside It#

ML-KEM is the only KEM in FIPS 203, but it is not the only KEM in the portfolio. Several other algorithms compete for adjacent niches, and the engineer who treats "PQ" as one thing misses the architectural choices that CNSA 2.0 and NIST actually make.

Falcon (FN-DSA, FIPS 206 draft). NTRU-lattice signatures with fast Fourier sampling. Signature sizes range from 666 bytes (Falcon-512, category 1) to 1280 bytes (Falcon-1024, category 5) -- three to five times smaller than ML-DSA-65 at comparable security; the byte counts are verbatim from the Falcon Round-3 specification's recommended-parameters table ^{[72, 53]}. The cost is Falcon's Gaussian sampler, which requires floating-point arithmetic and is notoriously hard to make constant-time. Microsoft has signalled support; SymCrypt has not shipped Falcon as of May 2026. FIPS 206 finalisation is the precondition; NIST's pqc-dig-sig project page lists Falcon (renamed FN-DSA) as the standard whose finalisation has been pushed past initial timelines pending the constant-time sampler question ^[27].

HQC (Hamming Quasi-Cyclic). NIST selected HQC as the fourth-round standardisation choice on 7 March 2025 ^[49]. HQC is code-based -- its security rests on the hardness of decoding random quasi-cyclic codes -- which is structurally unrelated to lattice cryptography. NIST IR 8545 documents the rationale: HQC offers diversification away from lattices in case future cryptanalysis makes Module-LWE less conservative than it now appears. HQC was chosen over BIKE; Classic McEliece remains a candidate but was not selected because of key size. NIST is expected to publish the HQC standard around 2027.

Classic McEliece. ~1 MB public keys at NIST category 5; ~261 KB at category 1 ^[24]. Forty-eight years of cryptanalysis without a structural break. Not selected by NIST for general standardisation. Survives as a niche choice for long-term archival key wrapping, where the key transfer happens once and the ciphertext is small.

LMS, XMSS, XMSS^MT (stateful hash-based, NIST SP 800-208). Already in SymCrypt. The NIST SP 800-208 specification names "two algorithms ... stateful hash-based signature schemes: the Leighton-Micali Signature (LMS) system and the eXtended Merkle Signature Scheme (XMSS), along with their multi-tree variants (HSS and XMSS_MT)" ^[73]. CNSA 2.0 specifies LMS and XMSS for firmware signing: UEFI capsule signing, OEM driver signing, secure-boot dbx revocation entries ^[21]. The stateful-counter requirement -- the signer must track a build counter and never reuse a leaf index -- is acceptable in build pipelines that already track build numbers monotonically. SymCrypt v103.5.0 added XMSS and XMSS^MT; v103.6.0 added LMS ^[2].

Composite signatures. draft-ietf-lamps-pq-composite-sigs-19 (21 April 2026) defines combinations of ML-DSA with each of RSA-PKCS#1-v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 ^[71]. The X.509 SubjectPublicKeyInfo contains both component public keys; verification requires both component signatures to succeed; an attacker must break both algorithms. Composite is the load-bearing migration mechanism for 2026-2030, because it is deployable against today's PKI. Downlevel verifiers ignore the composite OID and trust the inner classical chain; uplevel verifiers validate both.

Hybrid TLS X25519MLKEM768. Already in production at internet scale. Cloudflare since October 2022; Apple iMessage PQ3 since February 2024; Signal PQXDH since September 2023 ^[15]; OpenSSH since version 9.0 (April 2022) via sntrup761x25519-sha512 (Streamlined NTRU Prime + X25519) ^[60], with the ML-KEM-768-based group mlkem768x25519-sha256 added in OpenSSH 9.9 (September 2024) ^[16]; Google Chrome; Microsoft Edge. Schannel preview on 24H2 and Server 2025 in early 2026 ^{[13, 7, 14]}. Apple's framing of PQ3 as "Level 3" is the policy-marketing achievement of the post-quantum era. Level 1 is no post-quantum; Level 2 is post-quantum key establishment for the initial handshake; Level 3 is post-quantum key establishment for both the initial handshake and ongoing message-key ratcheting. iMessage PQ3 reached Level 3 in February 2024 -- six months before ML-KEM was even FIPS-finalised. The companion symbolic-analysis PDF Apple commissioned confirms the parameter split: ML-KEM-1024 for the initial key exchange, Kyber-768 for the ongoing ratchet ^[14].

Compact portfolio comparison for the KEM side (HQC sizes are current Round-4 parameters from the HQC project specification ^[74]):

Signature side:

The portfolio works as long as one of its families holds. But what if it doesn't? What does cryptography not tell us about the future, and what are the structural limits of even the strongest post-quantum primitive?

8. Theoretical Limits -- What PQC Does and Does Not Solve#

Post-quantum cryptography is not magic. It closes one specific channel of one specific threat model, and engineers who treat it as "now we're quantum-safe" miss the four limits the cryptographers themselves keep flagging.

1. The cryptanalysis margin is narrower than for RSA or ECDH. The best classical algorithm for solving Module-LWE at NIST parameter sizes (BKZ with sieving) runs in roughly $2^{0.292 n}$ operations, where $n$ is the lattice dimension; the best quantum variant runs in roughly $2^{0.257 n}$. That is a 12% exponent reduction -- not a Shor-style polynomial-time collapse. NIST parameter sizes carry a small but measurable margin to absorb future BKZ-with-sieving improvements. The hardness conjecture is stronger than RSA's (worst-case-to-average-case reduction), but the cryptanalytic frontier is thinner. Lattice cryptanalysis has improved continuously since Ajtai 1996; whether the asymptotic exponent further drops in the next decade is an open problem ^{[35, 40]}.

2. The side-channel surface is larger. ML-DSA's rejection-sampling loop is secret-correlated; Falcon's Gaussian sampler requires floating-point arithmetic; ML-KEM's polynomial operations can leak through cache-timing channels. The most visceral example is KyberSlash (eprint 2024/1049, advisory GHSA-x5j2-g63m-f8g4), in which Bernstein and collaborators demonstrated that the official Kyber reference implementation contained a secret-dependent division-timing leak that survived multiple rounds of NIST review and recovered secret keys in minutes on a Raspberry Pi 2 ^{[75, 76]}. KyberSlash is the most important data point in PQC implementation security. The leak was a one-line / operator that compiled to a variable-time integer division on ARM and on older x86-64. The vulnerability survived years of formal NIST review, multiple academic implementations, and several vendor ports. Constant-time discipline is more fragile in PQ primitives than in classical primitives -- both because the algorithms are newer and because the ring arithmetic offers many more variable-time corners than the simpler scalar arithmetic of ECDH or RSA. The KyberSlash site, authored by Bernstein, documents specific implementations affected ^[75].

3. The signed-binary harvest is not closed by PQ. This is the article's third aha moment, and the one most readers miss. A 2026 Authenticode signature on a 2026 Windows driver uses RSA-2048 + SHA-256. In 2035, the verifier may no longer trust RSA-2048 -- but the binary has already been loaded by every machine that downloaded it. Authenticode is not a transport channel. There is no migration-window analogue of harvest-now-decrypt-later because the signature was already validated at load time. The threat model is "an adversary in 2035 forges a new signature on a new binary," not "an adversary in 2035 decrypts a 2026 conversation." The two threat models call for different migration disciplines.

Post-quantum cryptography closes the harvest-now-decrypt-later channel for transport-protected traffic (TLS, IPsec, SSH, iMessage). It does not close the signed-binary persistence channel; a 2035 quantum-forged signature on a 2035 driver is a new attack, not a retroactive decryption of a 2026 signature. It does not close the algorithm-agility gap; CNG ships per-algorithm identifiers, not per-algorithm-class. Plan migration accordingly. Hybrid TLS first; composite X.509 chain second; firmware signing pilot third. Authenticode and PKINIT can wait for Microsoft's published specifications -- and premature migration in those surfaces is worse than no migration.

4. The algorithm-agility problem persists. Microsoft has shipped CNG identifiers per algorithm (BCRYPT_MLKEM_ALGORITHM, BCRYPT_MLDSA_ALGORITHM) rather than per algorithm-class (a hypothetical BCRYPT_PQ_KEM_ALGORITHM that selected the underlying primitive at runtime). The IETF treats algorithm agility as a load-bearing concern in draft-ietf-pquip-pqc-engineers-14 (26 August 2025), the IETF informational document on engineering PQC into existing protocol surfaces ^[77]. CNG does not yet treat it as load-bearing; the engineering consequences for the next migration are discussed in Section 9.4.

These four limits are not bugs; they are structural. But they are not the only open problems. What is the cryptographer's current research frontier, and where will the next migration begin?

9. Open Problems -- Where the Active Research Is#

What does Microsoft, NIST, and the IETF still not know? Five open problems whose resolution will define the next decade of Windows cryptography.

9.1 TPM 2.0 and Pluton blob-size constraints#

Default MAX_COMMAND_SIZE and MAX_RESPONSE_SIZE on TPM 2.0 are 4096 bytes. ML-DSA-87 signatures (4595 bytes) overflow the response buffer; ML-DSA-65 (3293 bytes) fits. NV memory budgets on commodity TPMs are tightly constrained, which means storing a single ML-DSA-87 keypair (2592-byte public key plus a multi-kilobyte private state) consumes a meaningful fraction of the available NV slot space ^{[6, 5]}. The TCG TPM 2.0 Library Specification v1.85 (March 2026) introduces the streaming command family that resolves the buffer overflow; the cited wolfSSL secondary source enumerates the new commands verbatim as TPM2_SignSequenceStart / TPM2_VerifySequenceStart, TPM2_SignSequenceComplete / TPM2_VerifySequenceComplete, and TPM2_SignDigest / TPM2_VerifyDigestSignature for digest-mode operations, plus TPM2_Encapsulate and TPM2_Decapsulate for ML-KEM, with the new structures TPM2B_KEM_CIPHERTEXT, TPM2B_SHARED_SECRET, and TPM_ST_MESSAGE_VERIFIED (the matching *SequenceUpdate opcode is implied by analogy with the existing TPM 2.0 hash-sequence command family but is not enumerated in the available secondary source pending TCG primary access) ^[6]. Commodity v1.85-capable chips are entering early sampling in 2026; Pluton's Rust firmware can move faster but is locked to specific SoC generations. Pluton's SoC-generation locking is the structural cost of its update-channel advantage. The Microsoft Learn Pluton page enumerates the currently supported families (AMD Ryzen 6000, 7000, 8000, 9000, and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3, and (non-Ultra) Series 3 processors; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series) ^[78]; OEMs without those silicon options cannot ship Pluton-backed PQC even when the firmware-update mechanism is ready. The cross-reference to the Pluton sibling article spells out the silicon-side mechanics.

9.2 Kerberos PKINIT#

RFC 4556's certificate-of-the-KDC bootstrap currently uses RSA-OAEP or pre-shared-secret-via-ECDH for AS-REP key establishment. The KDC certificate could be composite-ML-DSA-signed, but the AS-REP encryption key derivation has no IETF post-quantum migration draft as of May 2026. Every Windows domain join, every smart-card logon, every Kerberos-authenticated SMB or RDP or IIS session depends on PKINIT -- and PKINIT has no PQ path. The NTLM-to-PKINIT migration (the subject of a sibling article on NTLM deprecation) was hard enough; the PKINIT-to-PQ-PKINIT migration has not started.

9.3 Authenticode and the EFI signature database#

A Windows machine that boots in 2035 must verify boot loaders signed between 2010 and 2035. The EFI signature-database revocation list (dbx) is roughly 32 KB on commodity platforms ^[79]. Replacing each entry's RSA-2048 signature with ML-DSA-65 multiplies the per-entry signature size by ~1.6×; with SLH-DSA-SHA2-128f, by ~50×. No public Microsoft Secure Boot post-quantum roadmap exists as of May 2026. LMS is the obvious candidate -- CNSA 2.0 mandates LMS or XMSS for firmware signing -- but the dbx-size question remains open. Cross-reference the Secure Boot sibling article in this series.

9.4 Algorithm agility as a separately engineered property#

Section 8 limit-4 introduced algorithm agility as a structural property the IETF treats as load-bearing ^[77]. The open engineering problem is the CNG provider-interface design. Today every consumer -- Schannel, AD CS, IKEv2, SMB, RDP, Authenticode -- is wired to a specific algorithm identifier (BCRYPT_MLKEM_ALGORITHM, BCRYPT_MLDSA_ALGORITHM). A future migration to a NIST Round-5 KEM has to re-do every one of those wiring points, the same shape of problem CNG had with the RSA-to-ECDSA transition. Solving algorithm agility means redesigning the CNG provider interface around algorithm families rather than algorithm names -- a multi-year engineering programme that nobody has publicly committed to, and that the post-2030 migration window depends on.

9.5 The PKI rebuild before 2035#

Every TLS server certificate, every code-signing certificate, every smart-card user certificate has to be re-issued in a post-quantum algorithm before the legacy algorithm is disallowed. The throughput of the global public-CA system is the limiting factor. Commercial CAs are pilot-issuing composite-signed roots in 2026; volume issuance lags by years. NIST IR 8547 (12 November 2024) proposes deprecating quantum-vulnerable algorithms in NIST standards by 2035 ^[80].

flowchart TD
OP1["TPM / Pluton blob-size limits (v1.85)"]
OP2["Kerberos PKINIT bootstrap"]
OP3["Authenticode and EFI dbx"]
OP4["CNG algorithm agility"]
OP5["Global PKI rebuild by 2035"]
OP1 --> S1["Hello attestation"]
OP1 --> S2["BitLocker network unlock"]
OP1 --> S3["Trustlet attestation"]
OP2 --> S4["Domain join"]
OP2 --> S5["Smart-card logon"]
OP2 --> S6["Kerberos-mediated SMB / RDP / IIS"]
OP3 --> S7["Driver loading"]
OP3 --> S8["Secure Boot revocation"]
OP4 --> S9["Schannel / AD CS / IKEv2 / SMB / RDP"]
OP5 --> S10["Every X.509 certificate in the estate"]

Five open problems, five decade-scale research programmes, five places where a Windows engineer's procurement decision in 2026 will be visible in 2035. So what does that engineer do on Monday morning?

10. Practical Guide -- What an Engineer Does Monday Morning#

Six actions, in priority order. Each is doable in May 2026. Each closes a real gap. None requires a procurement cycle -- those start at Action 4.

// Pseudo-code for a Schannel cipher-suite inventory.
// In real PowerShell: Get-TlsCipherSuite | Select-Object Name, Hash, Cipher, Exchange
// This logic flags quantum-vulnerable Exchange groups (RSA, ECDH-*-without-PQ-companion).
type CipherSuite = {
name: string;
exchange: string;   // "ECDHE", "DHE", "RSA", "X25519MLKEM768", ...
cipher: string;     // "AES-256-GCM", "ChaCha20-Poly1305", ...
hash: string;       // "SHA-384", "SHA-256", ...
};

const QUANTUM_VULNERABLE_EXCHANGE = new Set([
"RSA", "DHE", "ECDHE", "ECDH",                // classical key agreement
"X25519", "SecP256r1", "SecP384r1",            // unwrapped classical EC groups
]);

const QUANTUM_SAFE_EXCHANGE = new Set([
"X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024",
"MLKEM768", "MLKEM1024",
]);

function audit(suites: CipherSuite[]) {
for (const s of suites) {
  if (QUANTUM_SAFE_EXCHANGE.has(s.exchange)) {
    console.log("OK    " + s.name + "  (" + s.exchange + ")");
  } else if (QUANTUM_VULNERABLE_EXCHANGE.has(s.exchange)) {
    console.log("FLAG  " + s.name + "  (" + s.exchange + " is harvest-now-decrypt-later exposed)");
  } else {
    console.log("?     " + s.name + "  (unknown exchange " + s.exchange + ")");
  }
}
}

One quarter to inventory, two quarters to pilot, two years to volume. Now for the questions every engineer asks after reading.

11. Frequently Asked Questions and Closing#

Closing#

A Windows endpoint opens a connection to cloudflare.com. The 1184-byte field on the wire is no longer a curiosity. It is a thirty-year migration in a single TLS extension. The bytes have a history: Diffie and Hellman in 1976; Shor in 1994; McEliece's megabyte keys; HFE and its descendants broken by Beullens; NTRU patented for two decades; Regev's quantum-reduction LWE in 2005; the Ring-LWE compression of 2010; the Module-LWE knob of 2012; BCNS 2014 from Microsoft Research Redmond; Cloudflare-by-default on October 3, 2022; the Castryck-Decru break twenty-five days after NIST's July 2022 selection; SymCrypt 103.5.0; the FIPS publications of August 13, 2024; the CNG BCRYPT_MLKEM_ALG_HANDLE exposed in Insider Canary in May 2025; Schannel preview behind Group Policy in early 2026.

The work is not done. Kerberos PKINIT has no PQ path. Authenticode has no PQ specification. BitLocker network unlock is still RSA-2048. The EFI signature database is still RSA-2048. Every signed binary already on every Windows disk in the world is signed with an algorithm whose 2035 status is uncertain. The TPM 4096-byte buffer cannot fit an ML-DSA-87 signature. CNG ships per-algorithm identifiers, not per-algorithm-class, which guarantees that the next migration will hit the same surfaces from the same angle. CNSA 2.0 picks 2035; NIST IR 8547 picks 2035 ^{[21, 80]}; the global public-CA infrastructure has nine years to rebuild every certificate it has ever issued.

"Migration to post quantum cryptography (PQC) is not a flip-the-switch moment, it's a multiyear transformation that requires immediate planning and coordinated execution to avoid a last-minute scramble." -- Microsoft Quantum-Safe Security blog, 20 August 2025 ^[44].

Above all, the bytes are real. The CNG handle exists. The SymCrypt release is shipping. The migration has started. The next decade is the engineering. Every line of code, every parameter set, every byte of that 1184-byte field has thirty years of work behind it, and the Windows engineer of 2026 is the one who carries it the next mile.