Microsoft Windows, Post-Quantum Crypto, and the Reality Gap as of 2026

Windows Server 2025 and Windows 11 (24H2 and newer) are the first Windows releases that include native post-quantum cryptographic primitives in the operating system. These changes are intended to reduce long-term exposure to data captured today and decrypted in the future.

Windows does not yet provide a complete quantum safe security stack. It only includes the base cryptographic primitives and hybrid mechanisms needed to begin transitioning away from classical algorithms.

What follows is what is actually present in the platform today, where it can be used, and what it cannot yet do.

Terminology

Base cryptographic primitives

This means Windows now has low-level implementations of PQC algorithms such as:

• ML-KEM for key exchange

• ML-DSA for digital signatures

  
  

These live in SymCrypt and can be called by higher-level components. They are the equivalent of having AES or RSA functions available, not a full encryption product.

They do not by themselves:

• Replace RSA or ECC

• Automatically secure traffic

• Enforce policy

• Integrate into existing enterprise controls

  
  

They are just the math engines.

Hybrid mechanisms

Hybrid means Windows does not use PQC on its own.

Instead it:

• Combines classical crypto (ECC like X25519)

• With PQC (ML-KEM)

• Mixes both secrets into one session key

  
  

This protects you if either algorithm is later broken, but it also means:

• PQC is not yet trusted enough to stand alone

• Classical crypto is still required everywhere

  
  

So Windows is not “post-quantum only.” It is post-quantum assisted.

Core PQC Algorithms in Windows

Microsoft has implemented the NIST standardised post-quantum algorithms directly into SymCrypt, the core cryptographic library used throughout Windows.

The following primitives are now present in modern Windows builds:

• ML-KEM (formerly CRYSTALS-Kyber)Used for post-quantum key exchange and encapsulation. Windows includes support for ML-KEM-512, 768, and 1024.

• ML-DSA (formerly CRYSTALS-Dilithium)Used for digital signatures, certificate validation, and identity verification.

These algorithms are integrated into the same core crypto engine that backs BitLocker, TLS, Kerberos, and CNG functions. This integration is necessary if the platform is ever to support PQC beyond academic demonstrations.

Where PQC Exists in the Windows Stack

SymCrypt and CNG

PQC algorithms are exposed through the same cryptographic pipeline used by existing Windows security features, via CNG-backed providers.

This means the operating system is capable of performing post-quantum operations natively, without third-party crypto libraries.

However, these API surfaces are still considered early access or preview grade. Public, documented stable APIs for third-party developers are not yet available. The capability is present, but not fully supported for production use outside of Microsoft’s own components.

Certificates and PKI

Windows certificate stores can parse and retain PQC algorithm identifiers and hybrid certificate chains.

Microsoft has demonstrated internal ADCS builds capable of issuing PQC and hybrid certificates, but as of early 2026 this is not a general availability feature. There is no supported workflow for running a full quantum-safe enterprise PKI yet.

Windows can store and process PQC formats, but does not yet provide a complete operational lifecycle for PQC certificates.

Hybrid TLS, The Only Practical Model

All practical PQC deployments in Windows today use hybrid key exchange.

Windows combines a classical key exchange algorithm such as X25519 with ML-KEM during TLS 1.3 handshakes, and both secrets are mixed into the session key.

If the post-quantum algorithm were later found to be weak, the classical layer would still protect the session. If a quantum computer someday breaks the classical layer, the PQC portion remains intact.

Hybrid key exchange is currently the only deployment model that provides backward compatibility and forward security.

This support exists only in TLS 1.3. TLS 1.2 and earlier cannot negotiate hybrid key exchange with PQC algorithms.

Operational Side Effects

Post-quantum cryptography increases the sizes of the following:

• Signature sizes

• key blobs

• certificate chains

Handshake payloads are larger than their classical counterparts. A classical ECDSA signature is roughly 64 bytes. An ML-DSA (Post-Quantum) signature can be over 2,400 bytes.

In practice, this means:

• Firewalls and load balancers may drop or fragment PQC handshakes.

• MTU and fragmentation settings may need adjustment.

• HTTP header limits and reverse proxy configurations might need raising to accommodate larger certificate headers.

  
  

These impacts are concrete and should be tested early in any deployment.

What “Enabled” Actually Means

PQC is not globally enabled across Windows as a system-wide security mode.

It is selectively used by Microsoft-controlled stacks such as Edge and specific TLS paths, and in internal services where hybrid negotiation is already implemented.

For developers, PQC types are beginning to appear in upcoming .NET releases, but they remain in preview and subject to change.

For administrators, there is no single switch, no Group Policy, and no supported way to enforce PQC system-wide yet.

PQC adoption in Windows is an incremental platform change and cannot be enabled through a single configuration setting.

Final Reality Check

The operating system now includes native support for post-quantum algorithms at the cryptographic provider layer. That is the actual milestone.

It is not yet quantum safe end-to-end. It is not yet enterprise ready. It is not a complete solution.

Broader deployment depends on standards maturity, application support, and enterprise tooling.