Post-Quantum Cryptography on Windows Server: What Changed, and What to Do About It

June 17, 2026

The short version

Microsoft shipped the NIST-standardised post-quantum algorithms into Windows 11 and Windows Server 2025 in the November 2025 update. As of the May 2026 update, Active Directory Certificate Services can issue and manage ML-DSA certificates, which brings quantum-resistant signing into enterprise PKI. Hybrid post-quantum TLS key exchange is landing on the same platform.

None of this requires you to rip anything out today. All of it changes what a sensible cryptographic roadmap looks like for the next three years. This paper walks through what is in the box, where the real work sits, and the sequence we run when a customer asks us to get the controls in place ahead of a quantum-safe transition.

S5 is in the engineering lane here. We are not selling you a quantum computer and we are not writing your cryptographic policy. What we do is inventory where you use public-key cryptography, design the migration, deploy the parallel PKI, and operate it so the transition does not break production along the way.

Why this matters before quantum computers exist

The threat that justifies acting now is not a quantum computer breaking your TLS session in real time. That hardware is not here. The threat is harvest now, decrypt later.

An adversary captures encrypted traffic or exfiltrated ciphertext today and stores it. They do not need to read it now. They need to read it in eight or ten years, once a cryptographically relevant quantum computer can run Shor’s algorithm against the RSA or elliptic-curve keys that protected it. Anything with a long confidentiality life is already exposed: legal records, health data, intellectual property, biometric templates, contracts, source code, and anything covered by a regulator’s multi-decade retention requirement.

If your data has to stay secret past roughly 2035, the classical encryption protecting it in transit today is already on borrowed time. That is the whole argument for starting now. The migration is a multi-year program, and the clock on the data you are protecting started some time ago.

What is actually in Windows Server 2025

Two NIST algorithms do the heavy lifting, and it is worth being precise about what each one is for, because they are not interchangeable.

ML-KEM (Module-Lattice Key Encapsulation Mechanism, formerly Kyber) handles key exchange. This is the one that defends against harvest-now-decrypt-later, because it protects the session key that encrypts your data in transit.
ML-DSA (Module-Lattice Digital Signature Algorithm, formerly Dilithium) handles signatures. This is for code signing, certificate signing, and authentication. ML-DSA is signature-only. It does not encrypt and it does not do key exchange, so it is not a drop-in replacement for RSA everywhere RSA is used.

Both are built into SymCrypt, the cryptographic engine behind Windows, Azure, and Microsoft 365, and both are exposed through the Cryptography API: Next Generation (CNG). .NET 10 carries the same algorithms for application developers.

The capabilities that matter for an enterprise estate:

Hybrid TLS key exchange

Windows Server 2025 supports hybrid key exchange that combines a classical algorithm such as X25519 with ML-KEM in the same TLS handshake. Hybrid is the right call during the transition. You get the post-quantum protection of ML-KEM without betting the whole connection on a young algorithm, because the classical half still has to be broken too. Defence in depth, applied to the handshake itself.

ML-DSA in AD CS

This is the headline for anyone running a Microsoft PKI. AD CS on Windows Server 2025 can stand up an ML-DSA certificate authority hierarchy and issue ML-DSA certificates for code signing, TLS, Web Server, User and Computer templates, and OCSP response signing.

There are real constraints here, and they shape the whole project:

You cannot upgrade an existing CA in place. PQC support requires newly deployed certification authorities. You stand up a parallel hierarchy alongside production, validate it, then migrate. There is no flag that flips your current root to post-quantum.
CNG only. All PQC algorithms in AD CS require CNG key storage providers. Legacy Cryptographic Service Providers are not supported, so any template or HSM integration still tied to a CSP needs to move first.
Three parameter sets. ML-DSA-44, ML-DSA-65, and ML-DSA-87 trade security strength against key and signature size. Bigger signatures have real consequences for certificate chains, OCSP responses, and anything bandwidth- or latency-sensitive, so the parameter choice is an engineering decision, not a default.
Platform baseline. PQC support in AD CS rides on the 2026-05 security update. The CAs you deploy for this need to be at that level or later.

Code signing and authentication

ML-DSA code signing and certificate-based authentication for web server, user, and computer scenarios are in scope. That covers a large share of the certificate use cases most enterprises actually run on AD CS.

Where the real work is, and it is not the algorithms

The algorithms are the easy part. Microsoft has done that work. The hard part is the same hard part as every other large security transition: you cannot migrate what you cannot see, and most organisations have no accurate map of where they use public-key cryptography.

This is the engineering sequence we run.

1. Cryptographic discovery and inventory

Find every place public-key cryptography is in use across applications, infrastructure, devices, and services. Not just the obvious TLS endpoints. Code-signing pipelines, VPN tunnels, S/MIME, database connections, embedded device certificates, service-to-service authentication, and the certificate stores nobody has looked at since the last admin left. For each one, capture the algorithm, key length, certificate validity period, and protocol version.

You cannot protect or migrate what you cannot see. This inventory is the single most valuable artefact the whole program produces, and it is the thing most often skipped.

2. Risk-rank by data lifetime, not by system

Prioritise on how long the data must stay confidential, how exposed the system is, and how much it would cost to migrate. Long-lived sensitive data behind external-facing systems, plus your trust anchors, go first. A public web server protecting session data that is worthless in a week is a lower priority than an internal system holding records that must stay secret for twenty years. Harvest-now-decrypt-later inverts the usual “patch the internet-facing thing first” instinct, because here the value is in the data’s confidentiality life, not just its exposure.

3. Build for crypto-agility

Crypto-agility is the ability to swap algorithms, keys, certificates, and protocols without re-architecting the application around them. It is the real deliverable of this program, because ML-KEM and ML-DSA will not be the last algorithms you migrate to. The components that make it real: centralised key and certificate management, abstraction so applications call a crypto service rather than hard-coding an algorithm, automated certificate lifecycles so a swap is a configuration change rather than a project, and support for hybrid models during every transition.

If you come out of this program able to change algorithms quickly and quietly, you have built the thing that matters. The specific algorithms are almost incidental.

4. Stand up the parallel PKI

Because AD CS cannot upgrade a CA in place, the PQC hierarchy is a new build running beside production. That is an opportunity, not just a constraint. You test ML-DSA issuance, parameter-set choices, chain-building behaviour, and OCSP sizing against real workloads without touching the CAs your business currently depends on. Move CSP-bound templates to CNG as part of the groundwork.

5. Deploy hybrid, then migrate, then verify

Roll out hybrid TLS key exchange where the platform supports it, so the session-key protection is in place while the rest of the estate catches up. Migrate certificate templates and signing workflows onto the new hierarchy in priority order. Test restoration and rollback at each step. Treat this as continuous: parameter sets, standards, and platform support will keep moving, and crypto-agility is what lets you keep pace without another forklift.

The timeline you are actually working against

Microsoft has said it aims to deliver quantum-safe capabilities across its products by 2029 and complete its own transition by 2033, which it positions as roughly two years ahead of most government deadlines. That is a useful anchor, because it tells you the platform support you will need is arriving on a known cadence, not all at once.

Your own timeline is set by your data, not by Microsoft’s roadmap. Work backwards from the longest confidentiality requirement you hold. If you have data that must stay secret until 2040, and a realistic migration program runs three to five years, the comfortable start date was already in the past. The honest answer for most enterprises is that the discovery and inventory work should be underway now, while the high-value migrations are sequenced over the next few years as platform support matures.

What S5 does on a post-quantum engagement

We get the technical controls in place. Concretely:

Cryptographic discovery across your estate, producing the inventory of where and how you use public-key cryptography.
Risk-ranked migration roadmap built on data lifetime and exposure, not a generic checklist.
Parallel AD CS PKI design and deployment for ML-DSA issuance, including parameter-set selection, CNG migration, and OCSP sizing.
Hybrid TLS rollout across the systems where the platform supports it.
Crypto-agility architecture so the next algorithm change is a configuration, not a program.
Managed operation of the new PKI under our Managed Infrastructure Services, or a clean handover to your team.

The policy, the risk acceptance, and the cryptographic standards your organisation adopts stay with you and your security leadership. The engineering to make the platform do what the policy requires is the part we take off your plate.

The one decision to make this quarter

You do not need to migrate anything this quarter. You do need to decide to look. The cryptographic inventory is the gating artefact for everything else, it takes the longest, and it ages the moment your estate changes, so it is the work that benefits most from starting early.

If you run a Microsoft estate and you have data with a long confidentiality life, the post-quantum transition has already begun whether or not you have a project for it. The only question is whether you are running it deliberately or discovering it later.

If you want a view of where your estate stands, talk to us. We will start with the inventory.