Parag Mali - tag: fips

CNG Architecture: BCrypt, NCrypt, KSPs, and How Windows Picks Its Algorithms

noreply@paragmali.com (Parag Mali) — Sat, 16 May 2026 00:00:00 GMT

Since Windows Vista, every piece of cryptography in Windows -- TLS, BitLocker, Authenticode, Windows Hello, DPAPI -- flows through the **Cryptography API: Next Generation (CNG)**. CNG splits the world into two layers. **BCrypt** does primitives: AES, SHA, HMAC, RNG, key derivation. **NCrypt** routes calls to a **Key Storage Provider (KSP)** that owns the long-lived private keys: software, TPM, smart card, or a third-party HSM. Algorithm selection is governed by a registered provider-priority list, the Schannel cipher-suite order, and a single FIPS-mode toggle that flips Windows into its validated subset. Windows 11 24H2 added the first post-quantum primitives (ML-KEM, ML-DSA) to the same surface, with no API break. This article walks through how that machine works, why Microsoft designed it that way, and where it leaks.

1. From CAPI to CNG: why Microsoft started over

In the late 1990s, Microsoft shipped its first general cryptographic API. The original Cryptographic Service Providers (CAPI) model [@learn-microsoft-com-service-providers] arrived in Windows NT 4.0 Service Pack 4 in 1998 and defined a plug-in unit called a Cryptographic Service Provider, or CSP. A CSP was a monolithic DLL: it owned the algorithm implementations, the key storage, and the export-control posture all at once. If you wanted to add hardware-backed RSA on Windows NT, you wrote a CSP. If you wanted to add a new hash function, you also wrote a CSP. The model worked for the algorithms Microsoft had in mind when it designed it.

Then the algorithms changed.

AES was standardized in 2001, after CAPI's design was already frozen. Microsoft retrofitted AES into the original architecture by shipping the Microsoft Enhanced RSA and AES Cryptographic Provider [@learn-microsoft-com-cryptographic-provider] as a separate CSP, sitting alongside the original Microsoft Base Cryptographic Provider. Elliptic-curve cryptography was even more awkward: CAPI's algorithm identifiers and key-blob formats had no place for ECC curves. Every new algorithm required a new CSP or a new release of an existing one. The plug-in surface was rigid, the FIPS validation story was painful, and the API was relentlessly C-shaped in ways that made auditing hard.Microsoft was not alone. The same era produced Intel's Common Data Security Architecture (CDSA) [@en-wikipedia-org-os-2] and several short-lived crypto frameworks for OS/2 and other platforms. Most of them disappeared. CAPI's longevity owed more to Windows market share than to its design.

By 2005, Microsoft started over. The result was the Cryptography API: Next Generation, or CNG, which shipped with Windows Vista and Windows Server 2008 in January 2007 [@learn-microsoft-com-cng-portal]. CNG was not a refactor. It was a clean second system, designed from a different set of assumptions: algorithms would keep arriving, key storage needed to be a separate concern, FIPS validation had to be a first-class output, and the same API had to work in user mode and kernel mode.

The Windows cryptographic API introduced in Vista (2007) as the long-term replacement for CAPI. CNG splits cryptography into a primitives layer (`bcrypt.h`, `bcryptprimitives.dll`) and a key-storage layer (`ncrypt.h`, `ncrypt.dll`), each pluggable through registered providers. Used by every modern Windows component that touches cryptography. The plug-in unit of the legacy CAPI architecture (1998-onward). A CSP bundled algorithms, key storage, and FIPS posture into a single DLL. Largely superseded by CNG providers, but still present on the system for backwards compatibility.

The three design pillars Microsoft committed to in the CNG portal documentation were modularity, cryptographic agility, and FIPS-compliance readiness [@learn-microsoft-com-cng-features]. All three would matter twenty years later when post-quantum cryptography arrived without warning the protocol authors. We will get to that.

Throughout this article, "BCrypt" refers to Microsoft's CNG primitives header `bcrypt.h` and its companion DLL `bcryptprimitives.dll`. It is not the Provos-Mazieres password-hashing function of the same name, which is unrelated and uses a different spelling in most academic literature ("bcrypt"). The naming collision is unfortunate but firmly entrenched in Windows.

2. BCrypt: the symmetric stack and the ephemeral key

Open a Visual Studio project, include <bcrypt.h>, link bcrypt.lib, and you have access to almost every cryptographic primitive Windows ships. AES in CBC, CFB, ECB, GCM, and CCM modes. SHA-1, SHA-256, SHA-384, SHA-512, the SHA-3 family, and the cSHAKE128 and cSHAKE256 extendable-output functions added in Windows 11 24H2 [@learn-microsoft-com-algorithm-identifiers]. HMAC over any of those hashes. PBKDF2. The NIST SP 800-108 key-derivation construction. The DRBG-based random number generator drawn from NIST SP 800-90 [@csrc-nist-gov-1-final]. Ephemeral asymmetric operations -- RSA encrypt, ECDSA sign, ECDH key agreement -- on key handles that vanish when the process exits.

The canonical BCrypt opening dance is four calls.

{` // Pseudocode mirroring the BCryptOpenAlgorithmProvider flow. // In real C: NTSTATUS values, BCRYPT_ALG_HANDLE, etc.

const algId = "AES"; // wide string const impl = null; // null -> walk the priority list const flags = 0;

const hAlg = BCryptOpenAlgorithmProvider(algId, impl, flags); BCryptSetProperty(hAlg, "ChainingMode", "ChainingModeGCM");

const hKey = BCryptGenerateSymmetricKey(hAlg, keyBytes); const ciphertext = BCryptEncrypt(hKey, plaintext, authInfo);

BCryptDestroyKey(hKey); BCryptCloseAlgorithmProvider(hAlg, 0); `}

The interesting parameter is impl. When it is NULL, BCryptOpenAlgorithmProvider "attempts to open each registered provider, in order of priority, for the algorithm specified by the pszAlgId parameter and returns the handle of the first provider that is successfully opened" [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider]. That sentence is the whole story of CNG provider priority in nineteen words.

Algorithm identifiers are wide strings. L"AES", L"SHA256", L"RSA", L"ML-KEM", L"ML-DSA", L"CHACHA20_POLY1305", L"CSHAKE128". Each string is registered in CNG's configuration store under HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\, with a per-algorithm ordered list of providers that claim to implement it. Add a new algorithm and you add a new string. Add a new provider and you append to its priority list. The API surface does not change.

Note: The algorithm-identifier string is the seam where cryptographic agility lives. As long as your protocol can encode "use whatever the spec calls AES-256-GCM," and as long as a CNG provider answers to that name, you can swap implementations without touching the calling code. Protocols whose wire format hard-codes the algorithm (the old SSL 3.0 cipher list, for example) do not get this benefit no matter what crypto API they call.

Underneath the API is a single implementation library. Microsoft's SymCrypt [@github-com-microsoft-symcrypt] has been the actual workhorse since Windows 10 version 1703: "SymCrypt is the core cryptographic function library currently used by Windows... Since the 1703 release of Windows 10, SymCrypt has been the primary crypto library for all algorithms in Windows." SymCrypt is open source. It carries hand-tuned assembly for AES-NI, VAES, SHA-NI, and PCLMULQDQ on x64, plus ARM64 SHA and AES intrinsics. On a modern Xeon, AES-GCM throughput from BCrypt routinely sits in the 4 to 8 GB/s range per core.

SymCrypt's open-source release in 2019 was a quiet event for a Microsoft library: the algorithms that protect Windows are reviewable by anyone willing to read C and ARM/x64 assembly.

BCrypt keys are ephemeral by construction. A BCRYPT_KEY_HANDLE lives in your process and dies with it. If you want to keep a private key around between processes, between reboots, or between machines, you do not use BCrypt. You use NCrypt.

That distinction is the first thing developers get wrong when they meet CNG. The second thing they get wrong is forgetting that BCrypt's GCM API does not allocate nonces for you. The NIST SP 800-38D specification of Galois/Counter Mode [@nvlpubs-nist-gov-nistspecialpublication800-38dpdf] is famously brittle under nonce reuse: a single repeated nonce under the same key destroys both confidentiality (XOR of plaintexts leaks) and authenticity (the GHASH authentication key becomes recoverable). With 96-bit random nonces the birthday bound limits safe usage to roughly $2^{32}$ invocations per key before collision probability becomes meaningful. Counter-based nonces sidestep the birthday bound entirely but require persistent state. CNG does neither for you. That part is your problem.

Note: First, GCM nonce reuse: BCryptEncrypt with BCRYPT_CHAIN_MODE_GCM accepts whatever 12 bytes you hand it. Counter or random, but never twice. Second, algorithm string drift: BCRYPT_SHA256_ALGORITHM is the macro for L"SHA256". L"SHA-256" returns STATUS_NOT_FOUND. Third, kernel-mode pseudo-handles: the convenient BCRYPT_AES_ALG_HANDLE shortcut is user-mode only per the BCryptOpenAlgorithmProvider remarks [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider]; kernel drivers must use real handles.

Windows 10 added pseudo-handles -- pre-baked handle constants like BCRYPT_AES_ALG_HANDLE and BCRYPT_SHA256_ALG_HANDLE -- that skip the provider lookup for the built-in algorithms. The 24H2 release extended that list to include BCRYPT_MLKEM_ALG_HANDLE and the cSHAKE handles. Microsoft now recommends pseudo-handles over BCryptOpenAlgorithmProvider for new code [@learn-microsoft-com-bcrypt-bcryptopenalgorithmprovider] when the algorithm is built in. The motivation is performance: pseudo-handles bypass the per-call provider walk and the configuration-store lookup.

That covers the primitives. Now we need a place to keep the keys.

3. NCrypt: where the long-lived secrets live

The ncrypt.h header opens a different door. Every function in the NCrypt API surface [@learn-microsoft-com-api-ncrypt] -- NCryptOpenStorageProvider, NCryptCreatePersistedKey, NCryptOpenKey, NCryptSignHash, NCryptDecrypt, NCryptKeyDerivation, NCryptExportKey, NCryptProtectSecret -- begins by routing the call through ncrypt.dll, which acts as a router rather than an implementation. The router decides which Key Storage Provider handles the operation and forwards the call.

That routing layer is the architectural distinction Microsoft has insisted on for two decades. Microsoft's Key Storage and Retrieval documentation [@learn-microsoft-com-and-retrieval] describes it like this: the NCrypt router "conceals details, such as key isolation, from both the application and the storage provider itself." Translation: the application calls NCryptSignHash and gets back a signature. It does not know -- and should not need to know -- whether the key lives in %APPDATA%, inside a TPM chip on the motherboard, on a smart card halfway across the room, or in a network-attached hardware security module in a data center on a different continent.

A registered plug-in DLL that owns persistent private-key material and exposes it through the NCrypt API. Microsoft ships four built-in KSPs (Software, Platform/TPM, Smart Card, and the CNG-DPAPI provider); third parties ship KSPs for HSM appliances, USB security keys, and cloud key services. Selecting a KSP is a matter of passing the right name string to `NCryptOpenStorageProvider`.

The mechanical flow for creating a persisted key looks like this.

sequenceDiagram participant App as Application participant Router as ncrypt.dll (NCrypt router) participant KSP as Microsoft Software KSP participant LSA as LSA key-isolation process participant Disk as %APPDATA%\Microsoft\Crypto\Keys\

App->>Router: NCryptOpenStorageProvider("Microsoft Software Key Storage Provider")
Router-->>App: hProvider
App->>Router: NCryptCreatePersistedKey(hProvider, "RSA", "MyKey", 2048, ...)
Router->>KSP: dispatch via registered KSP entry points
KSP->>LSA: LRPC: generate key, return handle
LSA->>Disk: write DPAPI-wrapped private blob
LSA-->>KSP: ok
KSP-->>Router: hKey
Router-->>App: hKey
App->>Router: NCryptSignHash(hKey, digest)
Router->>KSP: forward
KSP->>LSA: LRPC: sign with isolated key
LSA-->>KSP: signature
KSP-->>Router: signature
Router-->>App: signature

Two facts about that diagram matter. First, the private key bits never enter the calling process. They are generated inside the LSA process and the calling application only ever receives a handle and the eventual signature. Second, the LRPC hop is real: it costs roughly 30 to 100 microseconds per call on modern hardware. For bulk symmetric encryption you would not want this overhead, which is why CNG's design pushes you toward BCrypt for symmetric work and reserves NCrypt for the rarer, smaller, and more sensitive operations on long-lived asymmetric keys.The LSA key-isolation process is lsaiso.exe on systems with Credential Guard enabled, hosted inside the Virtualization-Based Security (VBS) trustlet boundary. On systems without VBS, the role is played by lsass.exe itself. Either way, key material does not enter the application's address space.

NCrypt is also where the asymmetric algorithms live in their persistent form. The Microsoft Software Key Storage Provider claims RSA keys from 512 to 16384 bits in 64-bit increments, DSA, DH, and ECDSA/ECDH on the NIST P-256, P-384, and P-521 curves [@learn-microsoft-com-and-retrieval]. Windows 11 24H2 added ML-KEM at the 512, 768, and 1024 parameter sets and ML-DSA at the 44, 65, and 87 parameter sets to the Software KSP's repertoire.

The split between BCrypt and NCrypt is sometimes confusing because there is overlap. You can sign with BCrypt's BCryptSignHash if you generated an ephemeral key pair. You can also sign with NCrypt's NCryptSignHash if the key is persisted in a KSP. The rule of thumb is: if the key needs to survive the process, use NCrypt; if it does not, use BCrypt. Real-world Windows code skews heavily toward NCrypt for asymmetric operations because almost every interesting asymmetric key has an associated certificate, and certificates outlive processes.

Note: The four Microsoft KSP name strings are MS_KEY_STORAGE_PROVIDER (Software), MS_PLATFORM_KEY_STORAGE_PROVIDER (TPM/Pluton), MS_SMART_CARD_KEY_STORAGE_PROVIDER, and MS_NGC_KEY_STORAGE_PROVIDER (Next Generation Credentials, used by Windows Hello). Typo any of these and you silently fall through to the Software KSP, which is a recurring source of "why is my key on disk instead of in the TPM" incident reports.

The router lets the application speak one language and have the storage backend vary. That makes the KSP plug-in model the most interesting piece of the architecture, and it deserves its own section.

4. The KSP model: one API, many places to keep keys

A KSP is a DLL on disk and an entry in the registry. The DLL exports a fixed set of function pointers that mirror NCrypt's API. The registry entry under HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Microsoft Software Key Storage Provider (and its siblings) tells ncrypt.dll which DLL to load when an application asks for a provider by name. That is the whole interface contract. If you can produce a DLL that implements the entry points and you can install a registry entry, you have a CNG KSP.

The platform comes with four. They sit on a spectrum from "your operating system is the entire trust boundary" to "the keys live on a separate piece of silicon and only signatures come back."

flowchart LR A["Microsoft Software KSP -- private keys on disk -- (DPAPI-wrapped)"] --> B["Microsoft Platform Crypto Provider -- TPM 2.0 or Pluton -- on-CPU silicon"] B --> C["Microsoft Smart Card KSP -- removable hardware token -- (PIV, CAC, Yubikey)"] C --> D["Third-party HSM KSP -- Thales Luna, Entrust nShield, -- YubiHSM 2, AWS CloudHSM"] A -.-> A1["~10^4 RSA-2048 sign/sec -- FIPS 140-2 L1"] B -.-> B1["~1-10 sign/sec -- TPM vendor cert"] C -.-> C1["~1-5 sign/sec -- card vendor cert"] D -.-> D1["~10^2-10^4 sign/sec -- FIPS 140-2/-3 L3 typical"]

4.1 The Microsoft Software KSP

The default. If you pass NULL for the provider name in NCryptOpenStorageProvider, you get this one. It stores per-user private keys at %APPDATA%\Microsoft\Crypto\Keys\ and per-machine keys at %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys\, with each file-level blob further protected by DPAPI under either the user master key or the LocalSystem (S-1-5-18) master key. The private-key operations dispatch through LRPC into the LSA key-isolation process so that even with administrator privileges on the machine, naive code-injection into the application's address space does not yield key bits.

The Microsoft Software KSP is also the only KSP that runs inside the LSA key-isolation process. Third-party KSPs run in the calling application's process. That difference matters enormously for the threat model. Microsoft notes this explicitly: third-party KSPs "do not run inside the LSA process" [@learn-microsoft-com-and-retrieval]. If you are a third-party KSP that talks to remote HSM hardware, the isolation comes from the HSM itself, not from any Windows process boundary.

4.2 The Microsoft Platform Crypto Provider (TPM and Pluton)

The KSP that answers to MS_PLATFORM_KEY_STORAGE_PROVIDER is the TPM's face to CNG. When you call NCryptCreatePersistedKey against it, the TPM 2.0 chip itself [@learn-microsoft-com-tpm-fundamentals] generates the key under the protection of its Storage Root Key. The private bits never leave the chip. The application gets back a handle whose only operations are sign, decrypt, and key derivation -- the private key cannot be exported, and that property is enforced by physics, not by software policy.

Key idea: The Platform Crypto Provider is the place where CNG stops trusting the operating system and starts trusting a separate piece of silicon. Every TPM-backed key in Windows -- BitLocker's Volume Master Key wrapping, Windows Hello credentials, AD CS attestation-enrolled machine identities -- enters and exits through this single KSP name.

Microsoft Pluton, the security processor that shipped in 2022 on AMD Ryzen 6000, Snapdragon 8cx Gen 3, and Intel Core Ultra Series 2 silicon, is exposed to Windows as a TPM 2.0 device behind the same Platform Crypto Provider name [@learn-microsoft-com-security-processor]. Application code that worked against a discrete TPM works against Pluton with no changes. Pluton's wins are at the supply-chain layer (no SPI bus to physically tap between the chip and the CPU) and the firmware-update layer (Pluton firmware ships via Windows Update). The Windows-facing API is intentionally identical.

4.3 The Microsoft Smart Card KSP

MS_SMART_CARD_KEY_STORAGE_PROVIDER is a single KSP that routes to whichever vendor minidriver claims the inserted card. The minidriver model is Microsoft's plug-in layer below the KSP layer: smart-card vendors do not write CNG KSPs, they write minidrivers, and Microsoft's single KSP fans the calls out to them via the APDU protocol. Cards that follow Microsoft's Generic Identity Device Specification (GIDS) [@learn-microsoft-com-device-specification] work without a vendor minidriver. Cards that do not, including most US federal PIV cards before about 2015, ship vendor-specific minidrivers.

This is the layer that powers Windows Hello for Business "virtual smart card" credentials, which present a TPM-backed key through the smart-card path because so much enterprise software already knew how to talk to PIV-style cards.

4.4 Third-party HSM and security-key KSPs

YubiHSM 2, Thales Luna, Entrust nShield, AWS CloudHSM Client for Windows, and various cloud-KMS bridges all ship CNG KSPs. The KSP DLL pretends to be a local provider and proxies operations across whatever transport the device uses -- USB for a YubiHSM, PCIe or TCP for a Luna, HTTPS for a cloud HSM. Latency varies from microseconds for a USB device to a few milliseconds for a network HSM. The application code that calls NCryptSignHash does not change.

For an internal Active Directory Certificate Services CA, the KSP choice is the entire trust story. A CA whose root key lives in the Software KSP can have that key extracted by any administrator. A CA whose root lives in a FIPS 140-2 Level 3 HSM KSP requires physical access to the HSM (often with multi-person key ceremonies) to recover the key. The application code in `certutil` is identical in both cases. The audit story is not.

5. The TPM KSP, attestation, and the hardware boundary

A TPM-bound key is a useful key, but a TPM-bound key with an attestation statement is a different kind of asset entirely. The Trusted Platform Module supports a primitive called key attestation: the TPM can sign a statement that says, "this key was generated inside me, I will never let it out, and here is a chain of trust back to my Endorsement Key that proves I am a real TPM made by a real vendor." A certificate authority that requires this attestation can refuse to issue a certificate for any key that did not come from inside a TPM.

Active Directory Certificate Services supports exactly this flow as "TPM key attestation" [@learn-microsoft-com-key-attestation]. The flow involves three keys: an Endorsement Key (EK) burned into the TPM at manufacture, an Attestation Identity Key (AIK) derived from the EK and certified by Microsoft or by the enterprise PKI, and the application key being attested. The AIK signs a statement covering the application key's properties; the CA verifies the AIK certificate chain and the statement, and only then issues a certificate.

flowchart TD EK["Endorsement Key (EK) -- burned into TPM at manufacture -- vendor cert from Intel/AMD/etc."] AIK["Attestation Identity Key (AIK) -- generated in TPM, certified by -- Microsoft EK CA or enterprise PKI"] APPK["Application key -- generated in TPM via -- NCryptCreatePersistedKey"] STMT["Attestation statement -- signed by AIK"] CA["Enterprise CA (AD CS) -- verifies AIK chain -- and attestation"] CERT["X.509 certificate -- issued to application key"]

EK --> AIK
AIK --> STMT
APPK --> STMT
STMT --> CA
CA --> CERT

The CNG-facing API for this is the property bag on a NCRYPT_KEY_HANDLE. After creating the key, the application calls NCryptGetProperty with NCRYPT_KEY_ATTESTATION_PROPERTY (and friends) to retrieve the attestation blob. The CA receives the blob in the certificate request and validates it against Microsoft's published EK CA roots. The whole protocol fits inside the standard certificate-enrollment flow.

Key idea: A software KSP can promise that a key is non-exportable. A TPM KSP can prove it.

Throughput is the price. A typical TPM 2.0 chip performs single-digit RSA-2048 signatures per second. Pluton-based platforms are in the same neighborhood. Any architecture that wants to do a TPM signature on every HTTP request will fall over almost immediately. The TPM is the right home for one signature per session, per boot, or per logon -- not one per packet.Key migration between TPMs is essentially impossible by design. Replace a motherboard, and any keys that were sealed to the old TPM's Storage Root Key are gone. This is the same property that makes BitLocker safe against motherboard theft (the recovery key, escrowed elsewhere, is the only way back) and the same property that makes TPM-bound device identities a key-management headache during hardware refresh cycles.

There is a deeper, more philosophical reason to use the TPM that the API does not advertise. Software keys are bounded by the kernel's process-isolation guarantees. Any kernel-level attacker, any user with SeDebugPrivilege, or any code injected into lsass.exe can in principle reach key material. The provably stronger bound -- keys that no OS-level code can ever read -- requires an off-CPU hardware boundary. CNG's own design notes acknowledge this when they say CNG "is designed to be usable as a component in a FIPS level 2 validated system" [@learn-microsoft-com-cng-features]: software-only isolation maps to FIPS 140-2 Levels 1 and 2; hardware boundaries are required for Level 3 and above.

6. FIPS 140 mode, compliance, and the one-bit toggle

There is a registry value at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. When it is set to 1 (or when the equivalent Group Policy "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" is enabled), Schannel and CNG callers refuse to use algorithms that fall outside the FIPS-approved set. RC4 disappears. MD5 disappears. SHA-1 disappears for new signatures (though not for legacy verification). TLS suites that rely on any of those are removed from the negotiation list.

The toggle is a runtime gate, not a code path. The underlying modules -- bcryptprimitives.dll and cng.sys [@learn-microsoft-com-140-windows11] -- are the same modules either way. They have been submitted to the Cryptographic Module Validation Program [@csrc-nist-gov-modules-search] and validated against the FIPS 140-2 standard [@csrc-nist-gov-2-final]. The toggle simply tells those modules that the calling environment expects FIPS-mode behavior, and the modules then refuse the non-approved algorithms.

A US federal certification program (Federal Information Processing Standard 140) that subjects a cryptographic module to laboratory testing and NIST review. Validated modules receive a public CMVP certificate. Federal agencies, FedRAMP/CMMC contractors, and most regulated industries can only use validated modules in approved configurations. FIPS 140-2 and the newer FIPS 140-3 differ mainly in test methodology and the standard's own ISO/IEC alignment.

Two current Windows 11 certificate numbers are worth memorizing. CMVP certificate #4825 covers bcryptprimitives.dll [@csrc-nist-gov-certificate-4825]. CMVP certificate #4766 covers cng.sys [@csrc-nist-gov-certificate-4766], the kernel-mode primitives. Both are FIPS 140-2 Level 1 modules with a sunset date of September 21, 2026 under the CMVP's transition rules. Microsoft maintains the per-version FIPS validation portal for Windows 11 [@learn-microsoft-com-140-windows11], which lists the active certificates per build and the algorithms each one covers.

The cadence mismatch is the open story here. Windows ships H1 and H2 feature updates roughly every six months. CMVP validation of a new build's primitives DLL and kernel module typically takes 12 to 24 months. Federal customers, FedRAMP-bound cloud tenants, and CMMC contractors cannot run a Windows build that does not have an active FIPS certificate covering its cryptographic modules. Microsoft submits 140-3 evidence for newer modules, but as of mid-2026 no public 140-3 certificate is visible on CMVP for the bcryptprimitives.dll shipping in Windows 11 24H2.

Note: Setting FIPSAlgorithmPolicy\Enabled = 1 is necessary for FIPS compliance, but not sufficient. The validated configuration also requires that Windows be a covered build (with an active certificate), that you avoid third-party crypto libraries that have not been validated, and that algorithm choices stay inside the per-certificate Approved Mode list. A Windows version without an active certificate is not in compliance even with the toggle on.

The toggle also does not change the SymCrypt implementations. AES-GCM is still AES-GCM. What changes is which APIs the caller is allowed to reach. From the application's point of view, the symptom of FIPS mode is STATUS_NOT_SUPPORTED on BCryptOpenAlgorithmProvider(L"RC4", ...). From an auditor's point of view, the symptom is the absence of any disallowed primitive call in the binary.

7. The post-quantum slide: ML-KEM, ML-DSA, and the agility test

The piece of CNG that earns its "agility" billing is the post-quantum transition.

NIST opened the Post-Quantum Cryptography standardization process in 2016 and ran four rounds of public evaluation [@csrc-nist-gov-quantum-cryptography] before issuing the first final standards in August 2024. FIPS 203 standardizes ML-KEM (formerly CRYSTALS-Kyber), a module-lattice key encapsulation mechanism [@nvlpubs-nist-gov-fips-nistfips203pdf]. FIPS 204 standardizes ML-DSA (formerly CRYSTALS-Dilithium), a module-lattice digital signature algorithm [@csrc-nist-gov-204-final]. Microsoft Research had been working on lattice cryptography for years [@microsoft-com-quantum-cryptography], and the public CNG implementations followed quickly: Windows 11 24H2 ships ML-KEM and ML-DSA as first-class CNG algorithms.

Here is the surprising part: the CNG API surface did not change. Adding ML-KEM was a matter of registering new algorithm identifier strings -- BCRYPT_MLKEM_ALGORITHM, the parameter sets BCRYPT_MLKEM_PARAMETER_SET_512, BCRYPT_MLKEM_PARAMETER_SET_768, BCRYPT_MLKEM_PARAMETER_SET_1024 -- in the CNG algorithm-identifier registry [@learn-microsoft-com-algorithm-identifiers]. The opening dance for an ML-KEM key encapsulation looks exactly like the opening dance for an ECDH key agreement, except for the string.

{` // Mirrors the BCrypt pattern shown in the Microsoft sample // "Using ML-KEM with CNG for Key Exchange"

const hAlg = BCryptOpenAlgorithmProvider("ML-KEM", null, 0);

const hKeyPair = BCryptGenerateKeyPair(hAlg, 0, 0); BCryptSetProperty(hKeyPair, "ParameterSetName", "ML-KEM-768"); BCryptFinalizeKeyPair(hKeyPair, 0);

const pubBlob = BCryptExportKey(hKeyPair, "MLKEMPUBLICBLOB");

// Sender side: encapsulate to recipient's public key const recipPub = BCryptImportKeyPair(hAlg, "MLKEMPUBLICBLOB", pubBlob); const { ciphertext, sharedSecret: ssA } = BCryptEncapsulate(recipPub);

// Recipient side: decapsulate with the matching private key const ssB = BCryptDecapsulate(hKeyPair, ciphertext);

// ssA === ssB `}

That code is structurally identical to a 2007-era ECDH session. The string changes, the blob format changes, and the wire-format sizes change considerably. ML-KEM ciphertexts at the 512, 768, and 1024 parameter sets are 768, 1088, and 1568 bytes respectively, with public keys of 800, 1184, and 1568 bytes per FIPS 203 [@csrc-nist-gov-203-final]. ML-DSA signatures at parameter sets 44, 65, and 87 are 2420, 3309, and 4627 bytes per FIPS 204 [@csrc-nist-gov-204-final]. For comparison, an ECDSA P-256 signature is 64 bytes and an X25519 public key is 32 bytes. The PQC blowup is roughly an order of magnitude, and that has knock-on consequences for every protocol that carries certificates or handshakes on the wire.

The reason ML-KEM matters before any large quantum computer exists is the harvest-now, decrypt-later attack: an adversary recording today's TLS sessions can decrypt them years from now if the long-lived key-exchange material was only protected by RSA or ECDH. Long-lived secrets transmitted over the wire today -- medical records, source code, government cables -- have a confidentiality lifetime measured in decades. The motivation for hybrid PQ key exchange is that you cannot un-record traffic.

The wire-format problem is why most TLS-PQ deployments use hybrid groups: classical X25519 combined with ML-KEM-768, with the shared secret derived from both. If either component breaks, the other one still holds. The IETF draft draft-kwiatkowski-tls-ecdhe-mlkem [@learn-microsoft-com-mlkem-examples] defines the X25519MLKEM768 group with IANA codepoint 0x11EC, and Chrome, Cloudflare, and AWS shipped support in production in 2024. OpenJDK JEP 527 [@openjdk-org-jeps-527] tracks the equivalent work for Java's TLS stack. Schannel in Windows 11 24H2 can negotiate ML-KEM through CNG, but Microsoft has not publicly committed to a default-on hybrid group at the Schannel layer as of mid-2026.

On a Windows 11 24H2 machine, the following PowerShell snippet asks CNG for its registered algorithms:

[System.Security.Cryptography.CngAlgorithm]::new("ML-KEM")
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\Default\0010'

The first line forces a CngAlgorithm lookup. The second walks the configuration store. If the keys ML-KEM and ML-DSA appear, your kernel-mode and user-mode primitives are 24H2-current.

The bigger structural lesson is that two decades of "cryptographic agility" claims actually paid off. The PQC transition required a 24H2 update, not a CNG redesign.

8. Where CNG actually shows up: TLS, BitLocker, and friends

The argument for an OS-level cryptographic API stands or falls on what runs on top of it. Every modern Windows component that touches cryptography is a CNG consumer.

The Windows implementation of TLS and DTLS, exposed through the SSPI (Security Support Provider Interface). Schannel handles the TLS protocol state machine, certificate validation, and cipher-suite negotiation, then delegates the actual cryptography to BCrypt and NCrypt. The cipher-suite priority list and protocol-version controls are configured per Windows version, often via Group Policy.

Schannel, the Windows TLS stack, sits directly above CNG. The Schannel cipher-suite list is its own per-version object, documented at the Schannel cipher-suites portal [@learn-microsoft-com-in-schannel]. For TLS 1.2 and earlier, the order is administered via the registry key HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 (the "Functions" value) or the Group Policy "SSL Cipher Suite Order." For TLS 1.3, the three suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256) are not user-orderable; Schannel hard-codes the priority. TLS 1.0 and TLS 1.1 are off by default in Windows 11 23H2 and later, per Microsoft's August 2023 deprecation announcement [@techcommunity-microsoft-com-windows-3887947].

flowchart TD App["Application -- (WinHTTP, HttpClient, browser, ...)"] SSPI["SSPI / CredSSP layer"] Schannel["Schannel -- protocol state machine -- cipher-suite negotiation"] BCrypt["BCrypt -- AES-GCM, SHA-2/3, HKDF, RNG"] NCrypt["NCrypt -- server cert private key sign -- client cert auth"] KSP["KSP (Software / TPM / -- Smart Card / HSM)"]

App --> SSPI
SSPI --> Schannel
Schannel --> BCrypt
Schannel --> NCrypt
NCrypt --> KSP

BitLocker is the canonical NCrypt-and-TPM consumer. The Full Volume Encryption Key (FVEK) is generated and stored encrypted on disk. The Volume Master Key (VMK) wraps the FVEK and is itself wrapped by one or more "protectors": the TPM, a recovery password, a startup PIN, a USB startup key. The TPM protector is an NCrypt-style operation against the Platform Crypto Provider, sealed to a set of Platform Configuration Register (PCR) measurements that capture the boot state. If anything in the early boot chain changes, the PCRs do not match, the TPM refuses to unwrap the VMK, and BitLocker falls back to recovery.

Authenticode, the signature format on Windows binaries, is a NCrypt-driven workflow at signing time and a BCrypt-driven workflow at verification time. The Windows kernel verifies driver signatures, the Windows loader verifies binary signatures, and WinVerifyTrust exposes the same machinery to applications. The hash algorithm in modern Authenticode is SHA-256, which means every signed executable on the system has a SHA-256 digest computed by BCrypt at some point during validation.

Credential Guard runs the LSA isolated process (lsaiso.exe) inside the Virtualization-Based Security trustlet boundary on systems with VBS enabled. Credential Guard does not replace CNG; it relocates the Microsoft Software KSP into a stronger isolation boundary. NTLM password hashes and Kerberos TGT session keys live inside that boundary, accessible only through the standard CNG calls dispatched into the trustlet.

Windows Hello for Business uses the Platform Crypto Provider as the home for the user's gesture-protected authentication key. The biometric (or PIN) unlocks a key in the TPM; that key signs an attestation that is consumed by Azure AD or AD FS. The biometric never leaves the device.

DPAPI and DPAPI-NG are themselves built on CNG, and they deserve their own section because they are the easiest place to see how the layering pays off.

Schannel, BitLocker, EFS, Authenticode, Credential Guard, Windows Hello, DPAPI-NG, IPsec, SMB encryption, Kerberos PKINIT -- every modern Windows component is a CNG consumer.

9. DPAPI-NG: a worked example of the NCrypt model

The original Data Protection API (DPAPI), shipped with Windows 2000, was a per-user secret-protection mechanism. An application called CryptProtectData, passed a blob of secret data, and got back an encrypted blob that only the same user on the same machine could later unwrap. The mechanism was anchored in the user's logon credentials, with a master key per user and a complex backup mechanism for password resets. It worked. It also locked the secret to a single machine, which became a problem the moment users started living on more than one device.

DPAPI-NG, introduced in Windows 8 and Windows Server 2012, is the cloud-era rebuild. The CNG DPAPI documentation [@learn-microsoft-com-cng-dpapi] describes the three calls: NCryptCreateProtectionDescriptor, NCryptProtectSecret, and NCryptUnprotectSecret. The protection descriptor is a small string that names who can unwrap the data. Examples include SID=S-1-5-21-... for an Active Directory user or group, LOCAL=user for the legacy single-user behavior, WEBCREDENTIALS=... for a credential vault entry, and combinations connected by AND or OR operators.

flowchart LR Plain["plaintext secret"] --> Protect["NCryptProtectSecret(descriptor, plain)"] Desc["descriptor: -- SID=group GUID -- OR -- LOCAL=user"] --> Protect Protect --> Blob["opaque blob"] Blob --> Unprotect["NCryptUnprotectSecret(blob)"] Unprotect -.->|"resolves descriptor -- via AD DC backup keys"| AD["Active Directory DC -- (DPAPI backup keys)"] Unprotect --> Out["plaintext secret -- on any authorized machine"]

The architectural win is that DPAPI-NG is just NCrypt with a particular protection-descriptor schema. Any KSP that can serve the key referenced by the descriptor can satisfy the unwrap. In an Active-Directory-joined environment, the AD domain controller's DPAPI backup keys allow any machine where the user (or any member of the named group) authenticates to recover the secret. The application that called NCryptProtectSecret does not need to know about backup keys, replication topology, or recovery flows. It calls NCrypt; the router and the relevant KSP do the rest.

This is the design payoff of the two-tier model. A new key-management capability (cross-machine recovery via AD-stored backup keys) becomes a new descriptor type, not a new API. The Windows team has used the same descriptor extensibility to add web-credential descriptors, container-bound descriptors, and the descriptors that protect Group Managed Service Account passwords. Each one is a private key-management concern; none of them broke the public API.The DPAPI-NG descriptor language is small enough to read in one sitting and powerful enough to express "any member of this AD group, on any machine where that member can authenticate." That is the cloud-era access-control story that the original DPAPI never had.

10. Engineering takeaways: choosing the right tool

The decision tree for CNG usage in production code is short.

flowchart TD Q1{"Need persistent -- private key?"} Q1 -- No --> B["BCrypt -- (ephemeral key, pseudo-handle)"] Q1 -- Yes --> Q2{"Threat model?"} Q2 -- "Machine identity, -- hardware-rooted" --> P["Microsoft Platform -- Crypto Provider -- (TPM / Pluton)"] Q2 -- "User-bound PKI, -- removable hardware" --> S["Microsoft Smart Card KSP -- (PIV / virtual smart card)"] Q2 -- "High signing rate, -- regulated custody" --> H["Third-party HSM KSP -- (YubiHSM / Luna / nShield)"] Q2 -- "Default, -- portable, fast" --> SW["Microsoft Software KSP"]

For algorithm choice in mid-2026, the defensible defaults look like this. Symmetric encryption: ChaCha20-Poly1305 or AES-256-GCM. Hashing: SHA-256 or SHA-3 family. Signatures: ECDSA P-256 or P-384 today, with ML-DSA-65 in the back pocket for the inevitable hybrid transition. Key encapsulation: X25519 today, with X25519+ML-KEM-768 hybrid as soon as your peers support it. RSA-2048 only for legacy interoperability. RC4, 3DES, and SHA-1 only behind explicit deprecation policy, and only for verification of historical artifacts.

Key idea: The hardest thing about CNG is not learning the API. It is choosing the right KSP. That single decision -- where the private key actually lives -- determines almost everything about your threat model, your throughput, your compliance posture, and your operational complexity.

A few engineering rules survive in any setting.

Do not put persistent keys in BCrypt. Every BCrypt key handle dies with the process. The architectural separation exists for a reason. If the key needs to survive a reboot, it belongs in NCrypt under a named KSP.

Do not assume the Software KSP. Code that calls NCryptOpenStorageProvider(NULL) ends up with whatever the default is. On a server with an HSM KSP configured as the default, this might be what you want; on a developer workstation, it might be the Microsoft Software KSP. Be explicit. Pass the name string. Test the negative case where the KSP you named is not registered.

Audit which KSP your certificates actually use. A certificate enrolled with the Platform Crypto Provider behaves identically to a certificate enrolled with the Software KSP from certutil's point of view. The difference is invisible until you ask. Use certutil -store -v My to dump certificate properties, and look for the provider field.

Treat FIPS mode as a deployment fact, not a development toggle. Code that works fine on a developer workstation can break in surprising ways on a FIPS-enabled production server. Run your CI on a FIPS-toggled image periodically. Catch the STATUS_NOT_SUPPORTED returns before customers do.

Watch the PQC roadmap. The ML-KEM and ML-DSA primitives are in 24H2. Hybrid TLS in Schannel is not on by default at the OS level as of mid-2026 (the most recent Microsoft public posture in the cipher-suite documentation does not yet list a default-on hybrid group), but downstream protocol updates will come. Code that uses the BCrypt and NCrypt patterns shown here picks up the new algorithms with a string change.

Note: The single most useful CNG diagnostic command on a modern Windows system is certutil -csptest, which enumerates registered providers and the algorithms each one claims to support. Run it before you suspect a configuration drift, not after.

The story of CNG is the story of two architectural bets that paid off. The first bet was that algorithms would keep arriving, so the API should be a registry of strings rather than a hard-coded set of functions. The second bet was that key storage was a separate concern from algorithm implementation, so the same primitives could run against software, TPM, smart cards, and HSMs without changing the application. In 2007 those bets looked over-engineered. In 2026, with ML-KEM shipping behind the same BCryptEncapsulate call that an ECDH consumer would have used, they look like exactly the right design.

Frequently asked questions

No. Microsoft's BCrypt is the `bcrypt.h` primitives header in CNG, providing AES, SHA, HMAC, RNG, and related primitives. The Provos-Mazieres bcrypt is a password-hashing function based on the Blowfish cipher, with no connection to Windows. The naming collision is unfortunate but firmly entrenched. When in doubt, BCrypt with a capital "B" usually means Microsoft's CNG header; lowercase bcrypt usually means the password-hashing function. On Windows, yes. .NET's `System.Security.Cryptography` namespace wraps CNG directly: `RSACng`, `ECDsaCng`, `AesGcm`, `SHA256.HashData()`, `CngKey`. Go, Rust, and Python bindings exist as third-party crates and packages (the Rust `windows` crate exposes both BCrypt and NCrypt, for example). OpenSSL on Windows does not transparently use CNG; you need the `openssl-cng` provider or direct CNG calls if you want the OS-validated primitives to do the work. Both can do RSA, ECDSA, and (in 24H2) ML-DSA signatures. The difference is lifetime. BCrypt key handles are ephemeral: they live in your process and disappear when it exits. NCrypt keys are persisted in a KSP and survive process exit, reboots, and (for AD-replicated descriptors via DPAPI-NG) the loss of a single machine. Use BCrypt for one-shot ephemeral operations (signing a single message, deriving a session key); use NCrypt for anything with a certificate attached or anything that has to be around tomorrow. Possibly, depending on what algorithms it calls. Setting `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled = 1` causes CNG to refuse RC4, MD5, SHA-1 for new signatures, and a handful of other non-approved algorithms. Anything that relied on those returns `STATUS_NOT_SUPPORTED`. The fix is to switch to approved algorithms (AES, SHA-2 family, RSA, ECDSA, ML-KEM, ML-DSA), not to disable the toggle. The toggle is also necessary but not sufficient for FIPS compliance: you also need a Windows build with an active CMVP certificate covering the cryptographic modules. As of mid-2026, the public Schannel documentation does not list a default-on hybrid group like `X25519MLKEM768`. The ML-KEM primitive is in CNG in 24H2, and Schannel can use it through the standard cipher-suite negotiation, but Microsoft has not publicly committed to enabling a hybrid group out of the box at the OS level. Chrome, Cloudflare, and AWS have already shipped hybrid PQ TLS in production at the application layer. Expect Schannel to follow once IETF standardization stabilizes and CMVP validation of the new modules catches up. For a certificate in the user or machine store, run `certutil -store -v My` (or `My` replaced with the store name) and look at the "Provider" field of each certificate. `Microsoft Software Key Storage Provider` means the key is on disk under `%APPDATA%` or `%ALLUSERSPROFILE%`. `Microsoft Platform Crypto Provider` means the key lives inside the TPM (or Pluton). `Microsoft Smart Card Key Storage Provider` means the key is on a card. Third-party HSM KSPs will show the vendor's provider name. For a freshly-created key via `NCryptCreatePersistedKey`, the provider name you passed to `NCryptOpenStorageProvider` is the source of truth. Because private keys do not live in the calling process. For the Microsoft Software KSP, key material lives in the LSA key-isolation process (`lsaiso.exe` under VBS, `lsass.exe` otherwise), and every operation that touches private bits has to cross that process boundary. The cost is around 30 to 100 microseconds per call. That is acceptable for signing or key derivation (operations that happen a handful of times per session); it would be punishing for bulk symmetric encryption. The architectural answer is to keep bulk crypto in BCrypt and let only the persistent-key operations pay the LRPC cost.

<StudyGuide slug="cng-architecture-bcrypt-ncrypt-ksps-and-windows-crypto" keyTerms={[ { term: "CAPI (Cryptographic Application Programming Interface)", definition: "The original Windows cryptographic API (1998-onward). Plug-in unit was the CSP. Superseded by CNG starting in 2007 but still present for backwards compatibility." }, { term: "CNG (Cryptography API: Next Generation)", definition: "The Windows cryptographic API since Vista (2007). Two-tier split: BCrypt for primitives, NCrypt for key storage. The basis for all modern Windows cryptography." }, { term: "CSP (Cryptographic Service Provider)", definition: "The CAPI-era plug-in unit. Monolithic DLL bundling algorithms, key storage, and FIPS posture." }, { term: "KSP (Key Storage Provider)", definition: "The CNG-era plug-in unit for persistent key storage. Microsoft ships four; third parties ship many more. Selected by name string passed to NCryptOpenStorageProvider." }, { term: "Microsoft Software Key Storage Provider", definition: "The default KSP. Stores DPAPI-wrapped keys on disk and dispatches operations through the LSA key-isolation process via LRPC." }, { term: "Microsoft Platform Crypto Provider", definition: "The TPM-and-Pluton-backed KSP. Keys are generated and used inside the TPM chip; private bits never leave the silicon." }, { term: "TPM key attestation", definition: "A three-key chain (EK -> AIK -> application key) that lets a CA verify a key was generated inside a real TPM. Supported by Active Directory Certificate Services since Windows Server 2012 R2." }, { term: "FIPS 140", definition: "US federal certification program for cryptographic modules. Validated modules receive a public CMVP certificate. Windows 11's bcryptprimitives.dll holds CMVP certificate #4825, cng.sys holds #4766." }, { term: "ML-KEM (FIPS 203)", definition: "Module-Lattice Key Encapsulation Mechanism. The NIST-standardized post-quantum KEM, formerly known as CRYSTALS-Kyber. Shipped in Windows 11 24H2." }, { term: "ML-DSA (FIPS 204)", definition: "Module-Lattice Digital Signature Algorithm. The NIST-standardized post-quantum signature scheme, formerly known as CRYSTALS-Dilithium. Shipped in Windows 11 24H2." }, { term: "DPAPI-NG", definition: "The CNG-era rebuild of the original Data Protection API. Uses NCrypt protection descriptors to bind protected data to AD principals (users, groups, web credentials) rather than to a single machine." }, { term: "SymCrypt", definition: "Microsoft's open-source cryptographic implementation library. The actual workhorse behind BCrypt and NCrypt since Windows 10 version 1703 (2017)." } ]} />

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

noreply@paragmali.com (Parag Mali) — Mon, 11 May 2026 00:00:00 GMT

**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.

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].

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 [@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 Computing 26(5) (1997) 1484-1509; DOI 10.1137/S0097539795293172. 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 August and November 2017) [@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 27 July 2022, twenty-two 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]. 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.

The BCNS 2014 paper "Post-quantum key exchange for the TLS protocol from the ring learning with errors problem" by Joppe Bos, Craig Costello, Michael Naehrig, and Douglas Stebila (eprint 2014/599) was the first end-to-end TLS implementation of a Ring-LWE key exchange [@bcns-2014]. Two of the four authors -- Costello and Naehrig -- were Microsoft Research Redmond. Two years later, the same Microsoft Research group plus collaborators published Frodo (CCS 2016, eprint 2016/659), the unstructured-LWE conservative fallback design with no ring algebra [@frodo-2016]. Frodo became FrodoKEM in the NIST process; FrodoKEM was selected as a Round-3 alternate but not advanced to standardisation [@frodokem-project]. Microsoft Research's own retrospective spans this work: "Our PQC effort began in 2014 when we published research on post-quantum algorithms and later quantum cryptanalysis ... we participated in four submissions to the original 2017 NIST PQC call and one submission to the current call. Since 2018 we have been experimenting with verified versions of PQC algorithms and in 2019 Microsoft Research completed testing of an experimental PQC-protected VPN tunnel between Redmond, Washington, and Scotland" [@ms-quantum-safe-blog]. The 2024 FIPS publication did not surprise Microsoft.

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 [@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]. 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].

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-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-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]. 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 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 [@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].

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]. 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-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 -- 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 prerelease 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. A FIPS 140-3 validation is a Cryptographic Module Validation Program certificate that asserts a cryptographic module (a binary, with a specific version, a specific build, and a specific tested configuration) implements specific algorithms correctly and has been tested by an accredited lab. SymCrypt's FIPS validation is what makes CNG-backed cryptography acceptable for U.S. federal procurement; without validation, the same algorithm implemented in the same byte-exact code is not FIPS-validated. The cadence matters because algorithm-implementation cadence (new ML-DSA External-Mu support in v103.9.0) and module-validation cadence (a new CMVP certificate per validated build) are different clocks. SymCrypt v103.8.0 explicitly added a FIPS approved-services indicator [@symcrypt-changelog] -- the runtime hook by which an application can ask "am I operating in FIPS-validated mode?" and reject non-FIPS algorithms accordingly. CMVP queue times in 2026 are running 9-18 months, which means the published SymCrypt version is typically two or three versions ahead of the FIPS-validated version at any given moment.

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]. 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].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]. A common confusion is the simultaneous truth that lattice cryptography has a *stronger* hardness argument than RSA (the worst-case-to-average-case reduction) and a *narrower* cryptanalytic margin (the 12% exponent gap). Both are true. The strength claim is structural: every average-case Module-LWE instance is hard if any worst-case lattice instance is hard. The narrowness claim is empirical: the best known algorithm is closer to a feasibility threshold than the best known algorithm for factoring or for elliptic-curve discrete log. The conservative McEliece line trades the strength claim (no analogous reduction) for an even wider empirical margin (no progress on Goppa-code decoding in 48 years). Engineers who treat "stronger hardness" and "wider margin" as synonyms get the post-quantum picture backwards. The honest framing: lattice is the deployable post-quantum, McEliece is the conservative fallback, and the portfolio exists because no one assumption carries everything.

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) 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 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].

NIST IR 8547 proposes the timeline; CNSA 2.0 imposes it on U.S. National Security Systems; CA/Browser Forum will eventually impose it on public web PKI. The unfunded part is the operational work. Every organisation operating an internal Windows AD CS hierarchy has to re-issue its root, its issuing CAs, and every end-entity certificate. The Microsoft tooling for this rebuild is the AD CS composite-signature support and the CertEnroll ML-DSA template path. The CA throughput question is real -- a typical commercial CA issues at peak in the low hundreds of thousands of certificates per day, and the global web PKI runs at orders of magnitude more -- which is why composite signatures are the deployment story for 2026-2030 and pure-PQ X.509 is the post-2030 story [@nist-ir-8547, @draft-lamps-composite]. 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 (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", ]);

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.

The priority ordering follows the threat model. Hybrid TLS is first because it closes harvest-now-decrypt-later on transport traffic with no compatibility cost (the classical share remains in the handshake; an uplevel server downgrades to classical-only cleanly). Composite X.509 is second because it lets you build a post-quantum-ready PKI hierarchy now and surfaces operational rough edges before pure-PQ deployments. Firmware signing is third because the stateful-counter discipline requires HSM-mediated key custody and a long lead time for the signing pipeline. Authenticode is last because there is no specification and no urgency.

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]. The cryptographic transition described here runs in parallel to the architectural transition documented across this blog's sibling articles. The hypervisor article explains the substrate on which the Secure Kernel and trustlets sit. The VBS trustlets article explains where Credential Guard lives. The NTLM-to-Kerberos article documents the protocol migration that PQ Kerberos PKINIT will eventually re-do. The Adminless article addresses the local-administrator surface; the Pluton and TPM articles cover the silicon-side roots of trust; the Secure Boot article covers the static measured boot chain that meets the dynamic measured boot chain at hypervisor load. Read them in any order. They share the same migration calendar, the same engineering discipline, and the same honesty about the gaps.

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.

<StudyGuide slug="post-quantum-cryptography-on-windows" keyTerms={[ { term: "ML-KEM (FIPS 203)", definition: "Module-Lattice-Based Key-Encapsulation Mechanism. The only NIST-finalised post-quantum KEM. Parameter sets ML-KEM-512/768/1024 over R_q = Z_q[X]/(X^256 + 1) with q = 3329. ML-KEM-768 public key is 1184 bytes, ciphertext 1088 bytes, shared secret 32 bytes." }, { term: "ML-DSA (FIPS 204)", definition: "Module-Lattice-Based Digital Signature Algorithm. Fiat-Shamir-with-aborts over Module-LWE / Module-SIS, q = 8380417. Parameter sets ML-DSA-44/65/87; signatures 2420 / 3293 / 4595 bytes." }, { term: "SLH-DSA (FIPS 205)", definition: "Stateless Hash-Based Digital Signature Algorithm. SPHINCS+ lineage; security rests on hash-function security alone. Twelve parameter sets across SHA-2 and SHAKE; signatures 7,856 to 49,856 bytes." }, { term: "LWE / Ring-LWE / Module-LWE", definition: "Learning With Errors: distinguish (A, As + e) from uniform when e is small. Ring-LWE lifts to a polynomial ring; Module-LWE generalises to module-rank-k. The 2010-2012 algebraic lift compressed lattice key sizes from megabytes to kilobytes." }, { term: "NTT", definition: "Number Theoretic Transform. The finite-field analogue of the FFT; reduces polynomial multiplication in R_q from O(n^2) to O(n log n). The reason ML-KEM is fast enough for TLS." }, { term: "Fujisaki-Okamoto-Hofheinz transform", definition: "Generic IND-CPA-to-IND-CCA2 transform for KEMs. Re-encrypts the plaintext during decapsulation and returns implicit-rejection pseudorandom output on mismatch. ML-KEM wraps K-PKE with FO to become IND-CCA2." }, { term: "Mosca's inequality", definition: "X + Y > 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." } ]} />