Quantum-Safe on Microsoft Platforms — Quantum-Safe: Migration and Governance

Quantum-safe migration becomes real when it reaches the tools people already use. On Microsoft platforms, that means the cryptographic engine underneath Windows, the developer APIs in .NET, the certificate systems many enterprises depend on, and the Transport Layer Security layer that protects network connections. Some of this is ready for careful testing now, some is deliberately marked experimental, and some should be enabled only where both ends of a connection are known to support it.

Start with the stack, not the slogan

Post-quantum cryptography, often shortened to PQC, is not one feature. It is a set of algorithms, application programming interfaces, certificate formats, protocol choices, and operational controls that have to line up. The useful question is not whether a platform is quantum-safe in the abstract. The useful question is where the new algorithms appear, which parts are stable, and what an application can safely depend on.

On Microsoft platforms, the foundation is SymCrypt, Microsoft’s core cryptographic library. SymCrypt implements the National Institute of Standards and Technology, or NIST, post-quantum algorithms including Module-Lattice Key-Encapsulation Mechanism, or ML-KEM, for key establishment and Module-Lattice Digital Signature Algorithm, or ML-DSA, for digital signatures. Windows exposes cryptography through Cryptography Next Generation, or CNG, which sits above SymCrypt. Higher-level features such as .NET cryptography APIs, Active Directory Certificate Services, and Schannel then draw from that base.

This layering matters. When a post-quantum algorithm is implemented in the platform crypto engine and surfaced through familiar operating system interfaces, developers do not have to invent their own cryptographic plumbing. They still have to test, pin versions, and understand compatibility, but they can begin from supported platform boundaries rather than ad hoc libraries scattered through the estate.

SymCrypt and Windows CNG provide the foundation

SymCrypt is the low-level engine in this story. It is where the standardized post-quantum primitives are implemented for Microsoft’s platform stack. ML-KEM is used for establishing shared secrets, which is the job traditionally handled by key exchange schemes. ML-DSA is used for digital signatures, which prove that a message, certificate, package, or other object was signed by the holder of a private key.

Windows applications usually do not call SymCrypt directly. They use CNG, the Windows cryptography API layer. Because CNG is built on top of SymCrypt, post-quantum capabilities can be surfaced through the same general Windows cryptography model developers have used for classical algorithms such as Rivest-Shamir-Adleman, or RSA, and elliptic-curve cryptography.

The architectural point is simple but important: post-quantum support is not merely a sample project or a lab build. It is appearing in the operating system cryptography path. That gives enterprises a cleaner route to inventory, policy, testing, and eventual migration than if every team selected its own standalone implementation.

📌

One engine, many surfaces. When post-quantum algorithms are implemented in the platform engine, they can reach developers, certificates, and protocols through established interfaces.

Post-quantum support surfaces from SymCrypt up through CNG to apps.

.NET gives developers named post-quantum types

Modern .NET adds cryptography types whose names map directly to the standards: MLKem for key encapsulation, MLDsa for lattice-based signatures, and SlhDsa for stateless hash-based signatures. Stateless Hash-Based Digital Signature Algorithm, or SLH-DSA, is the NIST-standardized hash-based signature option and is often treated as a conservative backup because it relies on different mathematical assumptions from lattice schemes.

Some of these .NET APIs are marked experimental. In .NET, that can appear as an opt-in diagnostic such as SYSLIB5006. This label is easy to misread. It does not mean the NIST algorithms are untrusted or that the cryptography is known to be weak. It means the software interface may still change, so developers must explicitly acknowledge the risk of API movement.

Under the covers, the .NET types use the platform’s cryptographic provider. On Windows, that path is CNG and SymCrypt. On Linux, applications need a recent OpenSSL implementation, specifically OpenSSL 3.5 or newer, that includes the required algorithms. For older .NET Framework applications that cannot move immediately to a modern runtime, Microsoft.Bcl.Cryptography provides a bridge for some of these capabilities.

The practical design pattern is to isolate post-quantum calls behind your own small cryptography boundary. If an experimental API changes, the repair is then local. Pin the software development kit, runtime, and package versions used in your tests, and record them in the same way you would record a database driver or a protocol library dependency.

⚠️

Experimental is about the API. For these .NET types, an experimental marker means the interface may change, not that the standardized algorithm should be treated as broken.

Modern .NET names map directly to the NIST post-quantum standards.

Certificates move in phases

Certificates are where cryptography meets identity and trust. Many Microsoft-centered enterprises use Active Directory Certificate Services, or AD CS, to issue internal certificates for users, devices, services, and infrastructure. Post-quantum support in AD CS is arriving in phases rather than as a single switch.

The first phase adds the ability to issue certificates signed with ML-DSA. That matters because signatures are what let relying parties verify that a certificate was issued by a trusted authority and has not been altered. A later phase adds ML-KEM support and Composite ML-DSA.

Composite ML-DSA means a certificate carries both a classical signature and a post-quantum signature. This is a hybrid design. The aim is not elegance; it is risk reduction during transition. If one scheme is later weakened, the other can still help preserve trust, provided the validation software and policy understand the composite form.

AD CS adds post-quantum certificates in phases, ending in composite.

Schannel brings hybrid post-quantum TLS

Schannel is the Windows implementation of Secure Channel, the platform component that provides Transport Layer Security, or TLS, for many Windows applications and services. TLS is the protocol family used to protect network connections such as HTTPS. In the post-quantum transition, the immediate focus is usually the key exchange inside the TLS handshake, because recorded traffic may be exposed later if today’s key exchange can be broken by a future quantum computer.

Schannel is gaining hybrid post-quantum key exchange that combines a classical elliptic-curve exchange with ML-KEM. Hybrid means both mechanisms contribute to the negotiated secret. The connection is not betting everything on only the old method or only the new method.

In early releases, this support is typically disabled by default and must be enabled deliberately. That caution is operational, not philosophical. Servers, clients, load balancers, proxies, inspection tools, and other middleboxes may not all handle larger or newer handshake patterns correctly. Enable hybrid TLS first between hosts you control, then expand only after you have evidence from your own network.

⚠️

Do not start at the internet edge. Turn on hybrid TLS first in controlled paths where you own both endpoints and can observe the handshake.

Schannel combines a classical exchange with ML-KEM for the secret.

What to try first in a test environment

The best first step is not a production cutover. It is a short, instrumented test that teaches your team what changes when post-quantum cryptography is used. Measure sizes, timings, dependencies, logging, and failure modes. Treat the exercise as engineering reconnaissance.

Start with key establishment. Generate an ML-KEM key pair, encapsulate a shared secret, and decapsulate it on the other side. Then test signatures: sign and verify with MLDsa, and compare signature and key sizes with a familiar classical scheme such as Elliptic Curve Digital Signature Algorithm, or ECDSA. Larger artifacts are normal and may affect message formats, certificate chains, logs, caches, and protocol limits.

If you test on Linux, confirm that OpenSSL 3.5 or newer is installed and is the version actually used by the application. If you test on Windows, confirm the required operating system and runtime builds. For TLS, enable Schannel hybrid key exchange only between two machines you control and capture enough telemetry to see whether the handshake negotiated the expected groups.

Create a small .NET test project that calls MLKem for encapsulation and decapsulation.
Add MLDsa signing and verification, then record key and signature sizes.
Check provider dependencies: CNG and SymCrypt on Windows, OpenSSL 3.5 or newer on Linux.
Pin the .NET software development kit, runtime, and package versions used in the test.
Enable Schannel hybrid TLS only on a controlled path and inspect the negotiated handshake.

The real decisions are operational

For leaders and practitioners, the Microsoft platform question is not simply whether post-quantum features exist. They do. The decision is where they reduce real risk today, where they create compatibility risk, and where waiting for a more stable interface is the safer engineering choice.

A chief information security officer may care most about systems exposed to harvest-now, decrypt-later risk: long-lived confidential data crossing networks that an adversary could record now and decrypt in the future. An application owner may care more about whether an experimental .NET API could change before a release. A public key infrastructure owner may need to plan certificate templates, relying-party validation, and lifecycle rules before issuing ML-DSA or composite certificates. A network engineer may need to test whether TLS middleboxes tolerate hybrid handshakes.

The governance answer is to make these choices explicit. Record which systems are testing PQC, which are blocked by dependency versions, which require vendor or protocol compatibility, and which should not change yet. Post-quantum migration is a staged program, not a weekend patch.

Prioritize data with a long confidentiality lifetime before data that expires quickly.
Separate algorithm readiness from API stability; they are related but not the same risk.
Keep PQC code behind an internal abstraction so provider or API changes do not spread.
Plan certificate migration with relying-party validation in mind, not only issuance.
Treat hybrid TLS as a controlled rollout because network intermediaries can be the limiting factor.

✅

Good migration looks boring. The strongest PQC programs make small tested changes, record dependencies, and expand only when compatibility is proven.

Key takeaways

SymCrypt implements NIST post-quantum algorithms such as ML-KEM and ML-DSA, and Windows surfaces them through CNG.
Modern .NET includes MLKem, MLDsa, and SlhDsa types, with some APIs marked experimental because the interface may change.
On Linux, .NET post-quantum support depends on a recent OpenSSL implementation, specifically OpenSSL 3.5 or newer.
AD CS support arrives in phases: ML-DSA certificates first, then ML-KEM and Composite ML-DSA patterns.
Schannel hybrid TLS combines classical elliptic-curve key exchange with ML-KEM, but it should usually be enabled first in controlled environments.
The practical next step is testing: measure sizes, performance, provider dependencies, certificate behavior, and network compatibility before production rollout.

Glossary

Post-quantum cryptography: Cryptography designed to resist known attacks from both classical computers and future cryptographically relevant quantum computers.
SymCrypt: Microsoft’s core cryptographic library that implements algorithms used by higher platform layers.
Cryptography Next Generation: The Windows cryptography API layer, often called CNG, that exposes cryptographic services to applications.
ML-KEM: Module-Lattice Key-Encapsulation Mechanism, the NIST-standardized post-quantum algorithm used to establish shared secrets.
ML-DSA: Module-Lattice Digital Signature Algorithm, the NIST-standardized post-quantum algorithm used for digital signatures.
SLH-DSA: Stateless Hash-Based Digital Signature Algorithm, a NIST-standardized post-quantum signature scheme based on hash functions.
Active Directory Certificate Services: Microsoft’s certificate authority service, often called AD CS, used by many organizations to issue and manage internal certificates.
Schannel: The Windows Secure Channel component that implements protocols such as Transport Layer Security for many Windows applications.
Composite ML-DSA: A hybrid certificate-signature approach that carries both a classical signature and a post-quantum ML-DSA signature.