# Post-Quantum Cryptography on Windows: The Thirty-Year Migration That Just Arrived
> How NIST FIPS 203/204/205 reaches the Windows platform via SymCrypt, CNG, Schannel, and .NET 10 -- the algorithm internals, the wire format, the migration timeline, and the honest accounting.
*Published: 2026-05-11*
*Canonical: https://paragmali.com/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**Post-quantum cryptography arrived on Windows in 2024-2026.** NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024 [@nist-fips-approved-news]. SymCrypt has shipped ML-KEM, ML-DSA, LMS, and composite-ML-KEM implementations across versions 103.5.0 through 103.11.0; CNG exposes them as `BCRYPT_MLKEM_ALG_HANDLE` and `BCRYPT_MLDSA_ALGORITHM`; Schannel can negotiate hybrid TLS 1.3 `X25519MLKEM768` (codepoint 0x11EC) on 24H2 behind Group Policy [@symcrypt-changelog, @cng-mlkem-examples, @draft-tls-ecdhe-mlkem]. The migration closes the harvest-now-decrypt-later channel for TLS-protected traffic, leaves the signed-binary persistence channel open, and is structurally constrained by the 4096-byte TPM 2.0 command buffer against which ML-DSA-87's 4595-byte signatures overflow [@fips-204-pdf, @wolfssl-wolftpm-v185].
## 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 [@draft-tls-ecdhe-mlkem, @cloudflare-pq-2024].
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?
A family of cryptographic algorithms whose security rests on mathematical problems for which no efficient quantum algorithm is known. PQC is a public-key replacement programme: it replaces RSA, Diffie-Hellman, and elliptic-curve discrete-log primitives that Shor's algorithm collapses in polynomial time on a fault-tolerant quantum computer. Symmetric primitives (AES, SHA-2/3) survive with parameter increases and are not the target of PQC standardisation [@wp-pqc, @nist-pqc-project].
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 [@draft-tls-ecdhe-mlkem, @iana-tls-parameters]. 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` [@draft-tls-hybrid]. An adversary who can break either component but not both still learns nothing.
A threat model in which an adversary records today's network traffic and stores it for years, decrypting it once a sufficiently capable quantum computer is available. The threat applies to any traffic whose secrecy must survive past the time-to-cryptographically-relevant-quantum-computer; it does not apply to signed-binary integrity, which is validated at load time. Hybrid TLS shifts the boundary from "must trust X25519 forever" to "must trust either X25519 or ML-KEM-768 forever" [@cloudflare-pq-2024, @mosca-2015].
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 [@cloudflare-pq-for-all].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 [@cloudflare-pq-2024]. 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 [@apple-imessage-pq3]. 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 [@cloudflare-pq-2024, @signal-pqxdh, @openssh-9-9].
> **Note:** This article covers what the NIST PQC standardisation effort produced (FIPS 203/204/205), what Microsoft ships on Windows (SymCrypt 103.5.0 through 103.11.0, CNG identifiers, .NET 10 managed types, Schannel hybrid TLS), and the honest accounting of what PQC does and does not solve. Sibling articles in this series cover the architectural transitions running in parallel: NTLM deprecation, Administrator Protection, the Windows hypervisor, VBS trustlets, the TPM, Pluton, Secure Boot, and Authenticode. Cross-references appear in the closing.
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](/blog/bitlocker-on-windows-architecture-attacks-and-the-limits-of-/), Kerberos PKINIT, [Windows Hello attestation](/blog/your-face-is-not-your-password-inside-windows-hellos-hardwar/)) 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 [@dh-1976]: 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 [@rfc-7748].
Eighteen years later, Peter Shor at Bell Labs found a polynomial-time quantum algorithm for both [@shor-1996]. 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.
A polynomial-time quantum algorithm, due to Peter Shor (1994-1996), that solves integer factoring and the discrete logarithm in arbitrary abelian groups [@shor-1996]. The algorithm reduces both problems to finding the period of a function via the Quantum Fourier Transform, which a fault-tolerant quantum computer can compute in time polynomial in the input size. RSA, finite-field Diffie-Hellman, DSA, and the elliptic-curve variants ECDH/ECDSA/X25519 are all structurally retired by Shor's algorithm; no parameter increase rescues them.
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 [@grover-1996]. 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 [@cnsa20-csa]. 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 [@mosca-2015].
The deadline relation $X + Y > Z$: if data-secrecy lifetime (X) plus migration time (Y) exceeds time-to-quantum-computer (Z), harvest-now-decrypt-later succeeds. Mosca's framing turned an open quantum-engineering timeline into an actionable IT-policy lever; if you cannot predict Z, you must minimise Y, which means starting migration now [@mosca-2015].
"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 [@nsa-cnsa-news, @cnsa20-csa]. 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 [@mceliece-1978]. 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 [@mceliece-project]. 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 [@kipnis-shamir-1999]. 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 [@beullens-rainbow-2022].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 [@nist-pqc-dig-sig].
**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 [@ntru-1996]. 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) [@ntru-patents], 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 [@jao-defeo-2011], achieved public keys of roughly 330 bytes at category 1 [@wp-sidh] -- smaller than ML-KEM-512's 800 bytes. NIST advanced SIKE to the fourth round of evaluation on 5 July 2022 [@nist-pqc-selection-2022]. 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 [@castryck-decru-sidh]. 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 [@maino-martindale-sidh]. 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"]
A proof technique, introduced for lattices by Miklos Ajtai in 1996 and refined for LWE by Oded Regev in 2005, that ties the average-case security of a cryptosystem to the worst-case hardness of an underlying lattice problem [@regev-2005, @wp-lattice]. The reduction says: solving random instances of the cryptosystem at any non-negligible advantage gives an algorithm for the *worst-case* hard problem. RSA has no analogous reduction; the average factoring instance is conjectured hard, but no theorem ties it to worst-case factoring. The lattice reduction is the structural argument for why post-quantum lattice cryptography may be more conservative, in a formal sense, than RSA.
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) [@ajtai-1996]. 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 [@regev-2005]. The Learning With Errors problem is simple to state.
Given a uniformly random matrix $A \in \mathbb{Z}_q^{m \times n}$, a secret vector $s \in \mathbb{Z}_q^n$, and a small noise vector $e$ sampled from a Gaussian-like distribution, distinguish the pair $(A, As + e)$ from a uniformly random pair $(A, b)$ where $b$ is uniform in $\mathbb{Z}_q^m$. LWE is conjectured hard for any polynomial-time algorithm classical or quantum; Regev's theorem ties LWE to the worst-case hardness of approximating shortest-vector problems on $n$-dimensional lattices, via a quantum reduction [@regev-2005].
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 [@lpr-2010-ringlwe]. 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)$.
A discrete Fourier transform over a finite field rather than the complex numbers. For a prime $q$ such that $2n$ divides $q - 1$, NTT converts a polynomial $a(X) \in \mathbb{Z}_q[X]/(X^n + 1)$ into its evaluations at the $2n$-th roots of unity in $\mathbb{Z}_q$. Polynomial multiplication then becomes pointwise multiplication of the NTT vectors. NTT is the speedup that compresses Ring-LWE arithmetic from $O(n^2)$ to $O(n \log n)$ and is the reason ML-KEM-768 encapsulates in tens of microseconds on commodity x86-64 [@fips-203-pdf].
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 [@langlois-stehle-modulelwe]. 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.
A generalisation of Learning With Errors over polynomial rings of fixed degree, in which the secret is a $k$-vector of ring elements and the matrix is $k \times k$. Module-LWE inherits the worst-case-to-average-case reduction from Ring-LWE [@langlois-stehle-modulelwe], offers a finer-grained security knob than either LWE or Ring-LWE, and is the underlying hardness assumption of ML-KEM (FIPS 203) and ML-DSA (FIPS 204) [@fips-203-pdf, @fips-204-pdf].
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 [@google-cecpq1]. 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 [@imperialviolet-cecpq2, @cloudflare-pq-2024]. 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) [@wp-nist-pqc].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 [@wp-nist-pqc]. 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 [@nist-ir-8413].
On 5 July 2022, NIST announced the first four standardisation selections: CRYSTALS-Kyber for key encapsulation, plus CRYSTALS-Dilithium, FALCON, and SPHINCS+ for signatures [@nist-pqc-selection-2022]. 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 [@nist-hqc-news].
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 [@nist-fips-approved-news, @nist-press-2024-fips]. Names changed in the transition: CRYSTALS-Kyber [@crystals-kyber-paper] became Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM); CRYSTALS-Dilithium became Module-Lattice-Based Digital Signature Algorithm (ML-DSA); SPHINCS+ [@sphincsplus-framework] 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 [@nist-pqc-dig-sig, @falcon-project].
### Generation 5 (2024-2026): shipping on Windows
SymCrypt v103.5.0 added ML-KEM "per final FIPS 203" along with XMSS and XMSS^MT [@symcrypt-changelog]. 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 [@ms-pqc-windows-insider]. .NET 10 (GA November 2025) shipped managed types `System.Security.Cryptography.MLKem`, `MLKemCng`, `MLDsa`, `MLDsaCng` [@dotnet-10-launch, @dotnet-mlkem, @dotnet-mlkemcng]. 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 [@fips-203-pdf]. The base ring has degree 256; the module rank $k$ selects the parameter set.
| Parameter set | $k$ | NIST category | Encapsulation key (bytes) | Ciphertext (bytes) | Shared secret (bytes) |
| --- | --- | --- | --- | --- | --- |
| ML-KEM-512 | 2 | 1 (AES-128 equivalent) | 800 | 768 | 32 |
| ML-KEM-768 | 3 | 3 (AES-192 equivalent) | 1184 | 1088 | 32 |
| ML-KEM-1024 | 4 | 5 (AES-256 equivalent) | 1568 | 1568 | 32 |
The byte counts in the table are verbatim from the FIPS 203 standard [@fips-203, @fips-203-pdf, @wp-kyber]. 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 [@cloudflare-pq-for-all, @draft-tls-ecdhe-mlkem]. Apple's PQ3 splits its parameter selection: ML-KEM-1024 for the initial key exchange and Kyber-768 for the ongoing asymmetric ratchet [@apple-imessage-pq3]. OpenSSH 9.0+ deployed a different post-quantum primitive entirely -- Streamlined NTRU Prime in `sntrup761x25519-sha512` [@openssh-9-0] -- and OpenSSH 9.9 (released 19 September 2024) added the ML-KEM-768-based group `mlkem768x25519-sha256` available by default alongside it [@openssh-9-9].
A generic construction that converts an IND-CPA-secure public-key encryption scheme into an IND-CCA2-secure key-encapsulation mechanism. The transform re-encrypts the plaintext during decapsulation and verifies the resulting ciphertext bit-for-bit; any mismatch causes decapsulation to return an implicit-rejection pseudorandom value rather than the real shared secret. ML-KEM wraps an IND-CPA-secure scheme called K-PKE with the FO transform; the FO wrapper is what makes ML-KEM safe to use with long-term keys [@fips-203-pdf].
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` [@cng-mlkem-examples]. 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 [@fips-204-pdf]. 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.
| Parameter set | NIST category | Public key (bytes) | Signature (bytes) |
| --- | --- | --- | --- |
| ML-DSA-44 | 2 | 1312 | 2420 |
| ML-DSA-65 | 3 | 1952 | 3293 |
| ML-DSA-87 | 5 | 2592 | 4595 |
Numbers verbatim from FIPS 204 [@fips-204, @fips-204-pdf]. CNSA 2.0 selects ML-DSA-87 specifically as the general-signature algorithm for U.S. National Security Systems [@cnsa20-csa].
A signature construction in which the prover commits to a masking value, hashes the message and commitment to derive a challenge, computes a response that depends on the secret and the challenge, and *aborts and retries* if the response would leak the secret. The "abort" probability is bounded so signing completes in a small constant expected number of restarts. The technique, due to Lyubashevsky, is the foundation of ML-DSA's security argument; the rejection-sampling loop is also the source of a measurable timing variance that constant-time implementations must handle carefully [@fips-204-pdf, @crystals-dilithium-paper].
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*s_1"]
Resp --> Check{"||z||_inf < bound? ||LowBits(w - c*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 [@fips-204-pdf]. 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 [@wolfssl-wolftpm-v185]. Until v1.85 chips ship in retail volume, ML-DSA-87 cannot live on a commodity TPM. Cross-reference the [TPM](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) and [Pluton](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/) 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 [@ms-quantum-safe-blog].
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 [@cng-mldsa-examples].
{`
// 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 [@fips-205-pdf, @wp-sphincsplus].
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.
A one-time signature scheme. The signer publishes a public key consisting of hash-chain endpoints; the private key is the chain starts. Signing reveals intermediate chain values that depend on the message digest. A WOTS+ key signs exactly one message; signing a second message with the same key reveals enough chain values to forge any signature. WOTS+ is the leaf primitive of XMSS and SLH-DSA [@fips-205-pdf, @wp-sphincsplus].
A few-time signature scheme built from $k$ independent hash trees of depth $t$. To sign a message, the signer hashes the message to obtain $k$ leaf indices and reveals the leaf preimage plus authentication path in each tree. Signing many messages with the same FORS key eventually reveals enough leaves to forge, but the few-times threshold is high enough to be tolerable when FORS is the bottom layer of an SLH-DSA hypertree whose root is signed by the layer above [@fips-205-pdf].
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" [@fips-205, @fips-205-pdf]. 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 [@cng-algorithm-ids].
> **Key idea:** 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](/blog/who-is-this-code----the-quiet-33-year-reinvention-of-app-ide/) -- 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" [@symcrypt-repo]. Microsoft open-sourced SymCrypt in March 2019 [@symcrypt-repo]. It is the FIPS 140-validated module that backs CNG; if CNG ships a post-quantum algorithm on Windows, SymCrypt is the implementation underneath.
Microsoft's open-source cryptographic library, used by Windows, Azure Linux, Xbox, and other Microsoft platforms. SymCrypt has been Windows's primary cryptographic library since Windows 10 1703 (April 2017); its FIPS 140-validated module is the implementation backing CNG (the Win32 API surface) and the NCrypt KSP infrastructure (the key-storage-provider surface). SymCrypt is currently written predominantly in cross-platform C, with an in-progress Rust rewrite for memory-safety reasons [@symcrypt-repo, @ms-research-symcrypt-rust].
The SymCrypt release history through May 2026 is verbatim from the public CHANGELOG [@symcrypt-changelog].
| Version | Post-quantum change |
| --- | --- |
| 103.5.0 | Add ML-KEM per final FIPS 203; add XMSS / XMSS^MT |
| 103.6.0 | Add LMS implementation |
| 103.7.0 | Add ML-DSA implementation |
| 103.8.0 | Add FIPS approved-services indicator |
| 103.9.0 | Add ML-DSA Sign / Verify with External Mu |
| 103.9.1 | Add FIPS CAST for ML-DSA, plus ML-KEM and ML-DSA keygen pairwise-consistency tests |
| 103.11.0 | Add Composite ML-KEM implementation |
The SymCrypt releases page lists the binary artefacts at each version for Windows AMD64/ARM64, generic Linux AMD64/ARM64, and OpenEnclave AMD64 [@symcrypt-releases]. 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" [@ms-research-symcrypt-rust].
### CNG, NCrypt, and .NET 10
The Windows Insider Canary channel introduced post-quantum CNG identifiers in May 2025 [@ms-pqc-windows-insider]. 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 [@cng-algorithm-ids]. 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 [@dotnet-10-launch]. `System.Security.Cryptography.MLKem` is an abstract base class with `KeyGen`, `Encapsulate`, `Decapsulate`, `ExportEncapsulationKey`, and `ImportEncapsulationKey` instance methods [@dotnet-mlkem]. `MLKemCng` is the CNG-backed concrete subclass that forwards to SymCrypt via CNG [@dotnet-mlkemcng]. 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) [@draft-tls-ecdhe-mlkem]:
| Group | Codepoint | Construction |
| --- | --- | --- |
| `X25519MLKEM768` | 0x11EC | RFC 7748 X25519 plus ML-KEM-768 |
| `SecP256r1MLKEM768` | 0x11EB | NIST P-256 plus ML-KEM-768 |
| `SecP384r1MLKEM1024` | 0x11ED | NIST P-384 plus ML-KEM-1024 |
The IANA TLS Parameters registry lists all three (registry last updated 2026-04-29) [@iana-tls-parameters]. 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 [@ms-quantum-safe-blog]. 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` [@draft-tls-hybrid]. 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 [@draft-lamps-composite]. 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.
> **Note:** The post-quantum migration is partial. As of May 2026, none of the following has a published Microsoft post-quantum specification or shipping implementation: IKEv2 PQ key exchange; SMB hybrid (`X25519MLKEM768` over SMB 3.1.1); RDP hybrid; BitLocker network unlock (still RSA-2048 + AES-256); Kerberos PKINIT (no PQ certificate path for the KDC bootstrap); Windows Hello attestation (TPM-bound RSA-2048 / ECDSA-P256). Authenticode signatures on drivers and binaries remain RSA-2048 + SHA-256 with no published PQ Authenticode specification. Premature migration of these surfaces is *worse* than no migration, because there is no downlevel-compatible composite story for them. The discipline is: hybrid TLS first, composite X.509 chain second, firmware signing pilot third. Leave the rest alone until Microsoft publishes specifications [@ms-quantum-safe-blog].
### 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 [@cnsa20-csa]:
| Milestone | Date |
| --- | --- |
| Acquisition preference for PQ in new National Security Systems | January 1, 2027 |
| Legacy algorithm phase-out begins | December 31, 2030 |
| Mandatory PQ adoption in National Security Systems | December 31, 2031 |
| RSA / ECDSA disallowed in National Security Systems | After 2035 |
The U.S. National Security Agency's Commercial National Security Algorithm Suite 2.0, announced September 7, 2022 [@nsa-cnsa-news]. CNSA 2.0 mandates post-quantum algorithms for U.S. National Security Systems by 2031 and disallows RSA / ECDSA after 2035. Specific algorithm selections (May 30, 2025 revision): ML-KEM-1024 for key establishment, ML-DSA-87 for general signing, LMS and XMSS for firmware signing, AES-256 for symmetric encryption, SHA-384 for hashing [@cnsa20-csa]. The CNSA 2.0 dates drive every U.S. vendor's PQC roadmap including Microsoft's.
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 [@falcon-spec, @falcon-project]. 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 [@nist-pqc-dig-sig].
**HQC (Hamming Quasi-Cyclic).** NIST selected HQC as the fourth-round standardisation choice on 7 March 2025 [@nist-hqc-news]. 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 [@mceliece-project]. 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)" [@nist-sp-800-208]. CNSA 2.0 specifies LMS and XMSS for firmware signing: UEFI capsule signing, OEM driver signing, secure-boot dbx revocation entries [@cnsa20-csa]. 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 [@symcrypt-changelog].
> **Note:** CNSA 2.0 names stateful hash-based signatures for firmware signing and only firmware signing. The reason is operational. LMS and XMSS are state-leaking: signing twice with the same leaf index reveals the secret. A general-purpose signing surface (X.509 end-entity certificates, code signing for arbitrary developers, document signing) cannot guarantee state discipline. A firmware-build pipeline that issues build numbers monotonically and operates under hardware-security-module discipline can. The narrow scope is what makes LMS / XMSS safe to deploy now -- the stateless SLH-DSA story is the general-purpose alternative for everything that cannot guarantee counter discipline [@cnsa20-csa, @nist-sp-800-208].
**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 [@draft-lamps-composite]. 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.
A signature construction that combines two component signature algorithms -- one classical, one post-quantum -- such that both signatures must verify for the composite signature to validate. The composite public key is the concatenation of the two component public keys plus a composite-OID wrapper; the composite signature is the concatenation of the two component signatures. The construction provides "either-component" security: an adversary must break both algorithms to forge. Composite is the practical migration on-ramp for X.509 PKI during 2026-2030 [@draft-lamps-composite].
**Hybrid TLS X25519MLKEM768.** Already in production at internet scale. Cloudflare since October 2022; Apple iMessage PQ3 since February 2024; Signal PQXDH since September 2023 [@signal-pqxdh]; OpenSSH since version 9.0 (April 2022) via `sntrup761x25519-sha512` (Streamlined NTRU Prime + X25519) [@openssh-9-0], with the ML-KEM-768-based group `mlkem768x25519-sha256` added in OpenSSH 9.9 (September 2024) [@openssh-9-9]; Google Chrome; Microsoft Edge. Schannel preview on 24H2 and Server 2025 in early 2026 [@cloudflare-pq-for-all, @cloudflare-pq-2024, @apple-imessage-pq3].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 [@apple-imessage-pq3].
A key-exchange construction that combines a classical key-agreement algorithm (X25519, ECDH-P256, RSA) with a post-quantum KEM (ML-KEM-768) in such a way that the final shared secret depends on both components. An adversary who breaks either component but not both learns nothing. The most common combiner is HKDF-Extract over the concatenation of the two shared secrets, per `draft-ietf-tls-hybrid-design-16` [@draft-tls-hybrid]. Hybrid is the migration choice during the period when neither classical nor post-quantum primitives can be trusted standalone -- classical because of harvest-now-decrypt-later, post-quantum because of the narrower cryptanalytic margin (see Section 8).
Compact portfolio comparison for the KEM side (HQC sizes are current Round-4 parameters from the HQC project specification [@hqc-project]):
| Algorithm | Public key | Ciphertext | Hardness | NIST status | Microsoft adoption |
| --- | --- | --- | --- | --- | --- |
| ML-KEM-768 | 1184 B | 1088 B | Module-LWE | FIPS 203 | SymCrypt 103.5.0; CNG; Schannel hybrid |
| HQC-1 | 2241 B (cat 1) | 4433 B (cat 1) | Quasi-cyclic codes | Round-4 selected (March 2025) | Not yet in SymCrypt |
| Classic McEliece | ~261 KB to ~1 MB | ~128 B to ~240 B | Goppa codes | Round-4 niche | Not in SymCrypt |
| Hybrid X25519+MLKEM768 | 1216 B | 1120 B | X25519 OR Module-LWE | TLS 1.3 IETF draft | Schannel preview, default-on roadmap |
Signature side:
| Algorithm | Public key | Signature | Hardness | NIST status | Microsoft adoption |
| --- | --- | --- | --- | --- | --- |
| ML-DSA-65 | 1952 B | 3293 B | Module-LWE / Module-SIS | FIPS 204 | SymCrypt 103.7.0; CNG |
| Falcon-512 | 897 B | 666 B [@falcon-spec] | NTRU lattices | FIPS 206 draft | Not in SymCrypt |
| SLH-DSA-SHA2-128f | 32 B | 17088 B | SHA-2 collision resistance | FIPS 205 | Planned `BCRYPT_SLHDSA_ALGORITHM` |
| LMS / HSS | 60 B | 4-50 KB | Hash preimage | NIST SP 800-208 | SymCrypt 103.6.0 |
| Composite ML-DSA-65 + ECDSA-P256 | ~2 KB | ~3.4 KB | ML-DSA AND ECDSA | LAMPS draft-19 | AD CS pilot path |
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 [@regev-2005, @langlois-stehle-modulelwe].
**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 [@kyberslash-2024, @ghsa-kyberslash].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 [@kyberslash-2024].
**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.
> **Key idea:** 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 [@draft-pquip-engineers]. CNG does not yet treat it as load-bearing; the engineering consequences for the next migration are discussed in Section 9.4.
The property of a cryptographic protocol or library that lets the underlying algorithm change without changing the protocol or API surface. A protocol that names "AES-256-GCM" instead of "an AEAD with at least 128-bit security" has poor algorithm agility; replacing AES-256-GCM with ChaCha20-Poly1305 requires the entire protocol to be re-negotiated. CNG's `BCRYPT_MLKEM_ALGORITHM` is per-algorithm rather than per-algorithm-class; a future Round-5 KEM will require new CNG plumbing rather than a parameter change. The IETF `pqc-engineers` document treats algorithm agility as the load-bearing engineering concern for the post-2030 migration window [@draft-pquip-engineers].
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 [@wolfssl-wolftpm-v185, @fips-204-pdf]. 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) [@wolfssl-wolftpm-v185]. 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) [@pluton-microsoft-learn]; 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](/blog/ntlmless-the-death-of-ntlm-in-windows/)) 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 [@uefi-dbx]. 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](/blog/secure-boot-in-windows-the-chain-from-sector-zero-to-userini/) 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 [@draft-pquip-engineers]. 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 [@nist-ir-8547].
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"]
> **Note:** ML-DSA-87 keys cannot live on a TPM 2.0 chip whose firmware predates Library Specification v1.85. Three Windows surfaces are stuck on RSA-2048 / ECDSA-P256 until v1.85-capable chips reach retail volume: Windows Hello attestation (TPM-bound), BitLocker network unlock (depends on TPM key sealing), and [Trustlet attestation](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/) (LSAISO / Credential Guard). Pluton can move faster than discrete TPMs because its firmware ships through Windows Update; the cross-reference to the Pluton sibling article explains the firmware-update agility mechanism [@wolfssl-wolftpm-v185, @ms-quantum-safe-blog].
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.
> **Note:** Run a CNG inventory against `HKLM\SYSTEM\CurrentControlSet\Control\Cryptography` and the registered providers. Catalogue certificate templates with `certutil -template`. Enumerate Schannel cipher suites with `Get-TlsCipherSuite` on every Schannel-using service. Identify every place RSA-2048, ECDSA-P256, ECDH/X25519, RSA-PSS, and DSA appear in your estate. Output is a CSV. The CSV is the input to every subsequent action. Without inventory, the migration is a guessing game [@cng-algorithm-ids].
{`
// 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 + ")");
}
}
}
`}
> **Note:** Cloudflare-fronted endpoints already negotiate `X25519MLKEM768` by default [@cloudflare-pq-for-all, @cloudflare-pq-2024]. For Windows servers using OpenSSL 3.5+, enable hybrid. For Schannel-only servers, monitor the Group Policy toggle on 24H2 and the documented Schannel curve preference order. Hybrid is the immediate harvest-now-decrypt-later defence -- the one place where a single configuration change measurably reduces today's exposure to a future quantum break.
> **Note:** Issue one composite root, one composite issuing CA, one composite end-entity certificate in a non-production lab. Validate consumption by an updated Schannel client and Microsoft Edge. The point is to surface the operational rough edges -- template definition, key-archival behaviour with PQ keys, certificate-validation timing on uplevel and downlevel clients -- before they hit production. This is the load-bearing 2026-2030 PKI migration on-ramp; the composite OID is downlevel-compatible, so the failure mode of an uplevel client validating an unaltered classical chain is the baseline, not a regression [@draft-lamps-composite].
> **Note:** Current TPM 2.0 v1.84 chips on most Windows 11 endpoints will not accept ML-DSA-87 keys without a firmware update. Use `Get-Tpm` and the TBS API to enumerate supported algorithms; if `BCryptOpenAlgorithmProvider` for ML-DSA returns `NTE_NOT_SUPPORTED` against the platform crypto provider, the underlying TPM does not yet expose the PQ surface. If your hardware lifetime extends past 2030, wait for v1.85-capable chips (early sampling 2026) or Pluton (already shipping with on-die firmware updates). Inventory your fleet's TPM firmware versions today; the migration plan needs to know the floor [@wolfssl-wolftpm-v185].
> **Note:** UEFI capsule signing, OEM driver signing, and secure-boot dbx revocation entries are all candidates for LMS or XMSS [@cnsa20-csa]. The stateful-counter requirement is acceptable because build pipelines already track build numbers monotonically. The CNG identifier `BCRYPT_LMS_ALGORITHM` is prerelease; SymCrypt v103.6.0 ships LMS [@symcrypt-changelog]. Start the pilot in a non-production signing service that has secure HSM custody of the counter state. The firmware-signing migration is the only place where CNSA 2.0 explicitly *prefers* stateful hash-based signatures over ML-DSA, because firmware signing is the use case where state discipline is realistic.
> **Note:** Post-quantum Authenticode is not specified by Microsoft as of May 2026. Premature migration breaks downlevel verification. The discipline is: hybrid TLS first, composite X.509 chain second, AD CS pilot third, firmware-signing pilot fourth, and **leave Authenticode alone** until Microsoft publishes the post-quantum Authenticode specification. Authenticode signatures are validated at binary load time; harvest-now-decrypt-later does not apply, and there is no urgency that justifies risking downlevel-verifier breakage. This is the action that takes restraint rather than effort.
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
Yes, when the server supports `X25519MLKEM768` and your Edge build negotiates it. Check via the Edge devtools' Security panel, or test against a Cloudflare-fronted endpoint with the Edge URL bar's connection information popup. Cloudflare reported nearly two percent of all TLS 1.3 connections to its edge were post-quantum-protected in March 2024, with a forecast of double-digit adoption by year-end [@cloudflare-pq-2024]. Endpoints that have not enabled hybrid TLS still negotiate X25519 alone, which leaves you exposed to harvest-now-decrypt-later.
Not as of May 2026. Schannel's hybrid TLS 1.3 preview is gated behind Group Policy on 24H2 and Server 2025. Microsoft's Quantum-Safe Security blog frames May 2026 to November 2026 as the milestone window for default-on negotiation [@ms-quantum-safe-blog]. Until then, the Schannel side has to be explicitly opted in via the cipher-preference order and the Group Policy toggle.
No, not on the public record. Post-quantum Authenticode is not yet specified. The CNG `BCRYPT_MLDSA_ALGORITHM` exists, and SymCrypt 103.7.0 implements ML-DSA, but the Authenticode signature format and the verifier policy have not been updated to accept post-quantum algorithms. Premature migration breaks downlevel verification on every Windows machine that has not received the PQ Authenticode update -- which today is *every* Windows machine. Do not migrate Authenticode prematurely.
Only against harvest-now-decrypt-later. Today's TLS is not under quantum attack -- quantum computers capable of breaking RSA-2048 or ECDH-X25519 do not exist in 2026. But today's TLS *traffic can be recorded* today, and if a sufficient quantum computer exists in 2040 the recorded traffic can be decrypted then. Enabling hybrid TLS now closes that window; enabling it in 2035 does not retroactively protect the traffic recorded in 2026 [@mosca-2015].
Nobody knows. CNSA 2.0 picks 2035 as the policy deadline, not a technical forecast [@cnsa20-csa]. Mosca's 2015 estimate, widely reproduced in PQC literature, was a 1/2 chance of breaking RSA-2048 by 2031. Quantum-engineering progress between 2015 and 2026 has been substantial on the qubit-count axis and modest on the error-correction axis; the underlying question -- when a thousand-logical-qubit fault-tolerant device becomes available -- has no consensus answer in 2026. CNSA 2.0's job is to make the answer not matter.
Hybrid `X25519MLKEM768` protects you against a break of either component. The HKDF combiner in `draft-ietf-tls-hybrid-design-16` requires both component shared secrets to be uniform-looking from the adversary's perspective; an attacker who breaks only ML-KEM still cannot recover the session key without also breaking X25519 [@draft-tls-hybrid]. Pure ML-KEM (no hybrid) does not have this property. The central design choice of the IETF hybrid construction is that it pays the byte cost (~1.2 KB extra per handshake) to buy the safety margin.
The kilobyte scale is structural to lattice mathematics; it is not a parameter-tuning issue. The minimum key size for a Module-LWE-based KEM at NIST category 3 is set by the dimension required for security under the best known lattice-sieving attacks. ML-KEM-768 at 1184 bytes is already aggressively tuned [@wp-kyber]. The alternatives that offer smaller keys (Falcon at 897 bytes, SIKE-when-it-was-alive at ~330 bytes) buy that size with either constant-time difficulty (Falcon's Gaussian sampler) or fragility (SIKE collapsed in July 2022). Classical comparisons: X25519's 32-byte public value is the floor; Classic McEliece's ~1 MB is the ceiling.
Only if your procurement timeline extends past 2030. As of May 2026, TPM 2.0 v1.85-PQ-spec-compliant chips are in announcement and early-sampling stages, not in retail volume [@wolfssl-wolftpm-v185]. Pluton is shipping, but is locked to specific SoC generations (current Intel Core Ultra series, AMD Ryzen 8000-series, Qualcomm Snapdragon X) [@pluton-microsoft-learn]. If you replace endpoints every three years, your 2026 procurement decision will be visible in 2029, before any post-quantum TPM mandate bites. If your refresh cycle is five-to-seven years, the calculus changes -- but the answer is still "wait for v1.85 silicon to ship at volume" unless you can write a specific business case for the early-adopter risk.
### 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 [@cnsa20-csa, @nist-ir-8547]; 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 [@ms-quantum-safe-blog].
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.
Z. If data-secrecy lifetime plus migration time exceeds time-to-quantum-computer, harvest-now-decrypt-later succeeds. The framing that made post-quantum migration an actionable IT-policy lever." },
{ term: "CNSA 2.0", definition: "U.S. NSA Commercial National Security Algorithm Suite 2.0. Mandates ML-KEM-1024, ML-DSA-87, LMS/XMSS for firmware, AES-256, and SHA-384 in National Security Systems. Acquisition preference 2027; mandatory adoption 2031; RSA / ECDSA disallowed after 2035." },
{ term: "Hybrid key agreement", definition: "Combines a classical key-agreement primitive (X25519) with a post-quantum KEM (ML-KEM-768) so the session key depends on both. An adversary must break both components to forge or recover. Used by Cloudflare since October 2022, Apple iMessage PQ3 since February 2024, Schannel preview in 2026." },
{ term: "Composite signature", definition: "X.509 signature that combines a classical and a post-quantum component such that both must verify. The deployment story for 2026-2030 X.509 PKI migration, per draft-ietf-lamps-pq-composite-sigs-19. Downlevel verifiers ignore the composite OID; uplevel verifiers validate both." },
{ term: "Algorithm agility", definition: "The property that protocols and APIs can change the underlying algorithm without re-engineering the consumer. CNG ships per-algorithm identifiers (BCRYPT_MLKEM_ALGORITHM) rather than per-algorithm-class identifiers; a future Round-5 KEM will require new CNG plumbing." },
{ term: "X25519MLKEM768", definition: "Hybrid TLS 1.3 Supported Group, codepoint 0x11EC, defined in draft-ietf-tls-ecdhe-mlkem-04. Concatenates X25519 (32-byte) and ML-KEM-768 (1184-byte ek / 1088-byte ct) shares. ClientHello key_share is 1216 bytes; ServerHello key_share is 1120 bytes." }
]} questions={[
{ q: "Why is the post-quantum programme a public-key replacement programme and not a symmetric one?", a: "Shor's algorithm breaks RSA / DH / ECDSA / ECDH in polynomial time on a fault-tolerant quantum computer, with no parameter increase rescuing them. Grover's algorithm gives only a quadratic speedup on symmetric primitives, which is absorbed by doubling key sizes (AES-256, SHA-384). The asymmetric lane is fatal; the symmetric lane is a parameter bump." },
{ q: "What single algebraic move compressed lattice public keys from megabytes to kilobytes?", a: "Lifting Learning With Errors from Z_q to a polynomial ring R_q = Z_q[X]/(X^n + 1), per Lyubashevsky-Peikert-Regev 2010. Polynomial multiplication via NTT becomes O(n log n) instead of O(n^2). Module-LWE (Langlois-Stehle 2012/2015) added a module-rank parameter knob that lets one base ring serve every NIST security category." },
{ q: "Why does the NIST FIPS slate combine a lattice scheme and a hash scheme rather than two lattice schemes?", a: "Diversification. Both the Rainbow break (Beullens, February 2022) and the SIKE break (Castryck-Decru, July 2022) happened during the NIST competition. The portfolio rests on two structurally unrelated foundations (lattice + hash) so that a single mathematical break cannot retire the whole programme. SLH-DSA's security rests on hash-function security alone." },
{ q: "Which SymCrypt version first added ML-KEM?", a: "Version 103.5.0, which 'Add ML-KEM per final FIPS 203' along with XMSS and XMSS^MT. Subsequent versions added LMS (103.6.0), ML-DSA (103.7.0), the FIPS approved-services indicator (103.8.0), ML-DSA External-Mu (103.9.0), FIPS CAST for ML-DSA (103.9.1), and Composite ML-KEM (103.11.0)." },
{ q: "What TLS Supported Group does Schannel preview-negotiate on 24H2, and what is its codepoint?", a: "X25519MLKEM768, codepoint 0x11EC, per draft-ietf-tls-ecdhe-mlkem-04 (8 February 2026). The ClientHello carries 32 bytes X25519 + 1184 bytes ML-KEM-768 encapsulation key (1216 bytes total); the ServerHello carries 32 bytes X25519 + 1088 bytes ML-KEM-768 ciphertext (1120 bytes total)." },
{ q: "Why does ML-DSA-87 not fit on a commodity TPM 2.0 chip?", a: "ML-DSA-87 signatures are 4595 bytes. Default TPM 2.0 MAX_COMMAND_SIZE and MAX_RESPONSE_SIZE are 4096 bytes. TCG TPM 2.0 Library Specification v1.85 (March 2026) introduces a streaming TPM2_SignSequence Start / Complete family (with TPM2_SignDigest / TPM2_VerifyDigestSignature for digest-mode operations) and ML-KEM TPM2_Encapsulate / Decapsulate, but v1.85-capable chips are in early sampling in 2026, not retail volume." },
{ q: "What is the difference between LMS / XMSS and SLH-DSA, and when does CNSA 2.0 prefer each?", a: "LMS and XMSS are stateful: the signer must track a counter and never reuse a leaf index. SLH-DSA derives the leaf address from the message hash and per-signature randomness, making it stateless. CNSA 2.0 specifies LMS or XMSS for firmware signing (where build pipelines already track counters under HSM custody) and ML-DSA-87 for general signing." },
{ q: "Why does PQC not close the signed-binary persistence channel?", a: "Authenticode signatures are validated at binary load time. A 2026 RSA-2048 signature has already been verified by every machine that downloaded the binary; a 2035 quantum break does not retroactively decrypt anything because Authenticode is not an encryption channel. The threat model is forgery of new signatures on new binaries, not retroactive decryption. Harvest-now-decrypt-later does not apply." }
]} />
{/*
---WRITER METRICS---
Word count: 15908
Citations: 64 distinct frontmatter refs, 156 inline citation tokens
Mermaid diagrams: 7
Definitions: 17
Sidenotes: 8
FAQ questions: 8
---END WRITER METRICS---
*/}