Microsoft PQC TLS Pilot: Windows 11 and Server 2025 ML-DSA Certificate Testing

What Microsoft actually announced​

The core event is Microsoft's Post-Quantum Cryptography (PQC) TLS Pilot Program. It is run by the Trusted Root Program to test and evaluate PQC-enabled certificate hierarchies within the Microsoft Root Program. The Microsoft post says the pilot launched on August 27, 2026.

The pilot is strictly scoped to closed testing environments, custom applications and enterprise testbeds. Its purpose is to evaluate PQC's impact there, not to set a standard for public web connections.

Participation is not open to ordinary organizations. The requirements say participating certificate authorities must be in good standing with the Microsoft Trusted Root Program. They also need Microsoft's approval, and Microsoft can deny, suspend or remove participation at any time. The pilot is aimed at CAs. If you run an enterprise PKI, your practical route is through your certificate provider.

Who is in so far​

Microsoft's August 2026 deployment notice, dated August 27, adds pilot roots from seven CAs:

• ComSign
• DigiCert
• HARICA
• IdenTrust Services
• Sectigo
• Shanghai Electronic Certification Authority
• SSL.com

The same notice lists a Visa root. It is not described as a PQC pilot root, so it shouldn't be counted among the seven. Microsoft's post says admissions are rolling through the end of 2026.

The guardrails​

The warning label matters more than the announcement. Pilot certificates:

• are not publicly trusted, are not meant for production trust scenarios, and are not meant to secure public-facing web connections
• will not be added to the Common CA Database, will not be considered for public trust inclusion by Microsoft, and will not be added to Certificate Transparency logs

The requirements add that ML-DSA support is limited and evolving, with no expectation of complete functionality across Microsoft products and libraries. Behavior may be unstable and compatibility may change without notice. In plain terms, treat these roots as lab equipment.

The pilot's technical rules, per the published requirements, are:

• Root algorithm: ML-DSA-87 is required for roots. ML-DSA-44 and ML-DSA-65 are barred for roots but allowed for subordinate CA or leaf certificates.
• Allowed uses: server authentication, client authentication, or both. The EKU extension must be marked critical. Code signing, document signing, S/MIME and other non-TLS uses are excluded.
• Maximum validity: one year for roots, one year for subordinate CAs and 90 days for leaf certificates.
• Scope limit: unless Microsoft approves otherwise, a CA is limited to one pilot root, and Windows is the intended test platform.

Reporting breakage is part of the job​

Participating CAs must document and report incompatibilities and give Microsoft enough detail to evaluate policy or process updates. The listed examples include CA software or HSM limitations, validation or linting failures, TLS interoperability problems, root-store ingestion issues, and encoding or parsing failures in dependent systems. So the pilot is a bug-hunting exercise as much as a certificate-issuing one. It is meant to find where the ecosystem breaks.

Why authentication is the harder half​

Microsoft's argument is that confidentiality and authentication carry different risks. Certificates and private keys have to be issued, distributed, stored, validated, renewed and managed across many vendors and environments. A new algorithm therefore touches operations as well as math.

Microsoft's AD CS documentation explains why this matters for the long term. Long-lived root CA and code-signing certificates must stay trustworthy for their whole validity period, because a forged signature in a quantum-vulnerable algorithm becomes possible once capable machines exist. Hence the focus on long-lived infrastructure: embedded devices, appliances, operational technology and custom applications.

The questions Microsoft says testing should answer:

• Can existing applications parse and validate post-quantum certificates?
• How do larger certificates and chains affect handshake size, performance, storage, transmission and inspection limits?
• Do PKI workflows need to change?
• Are monitoring, inspection and certificate-management tools ready?
• Can HSMs and other cryptographic components cope?
• What hidden dependencies sit in vendors and third-party services?

Microsoft doesn't claim every organization will hit each problem. It says many teams don't yet know which of these questions matter to them, and testing is how they find out.

Why size matters​

Microsoft Learn's ML-DSA guidance for AD CS lists the fixed sizes of each parameter set:

These are per-key and per-signature figures. They are not measurements of a full certificate chain or TLS handshake. Still, a single ML-DSA-87 signature of 4,627 bytes is a reminder that middleboxes, logs and fixed-size buffers may see much bigger payloads than they do today.

Windows 11 and Windows Server specifics​

Microsoft says supported and appropriately configured Windows 11 systems can evaluate ML-DSA certificates in the pilot's non-production scenarios. Support begins with the July 28, 2026 updates:

• KB5101681 (OS Build 28000.2608) for 26H1
• KB5101684 (OS Builds 26200.8973 and 26100.8973) for 25H2

Those build numbers come from Microsoft's post. Check the update documentation for your own devices before relying on them. Microsoft also says ML-DSA certificates can be used with Secure Channel (Schannel) in supported scenarios, and that you should confirm the platform requirements first.

Separately, you can build your own ML-DSA lab hierarchy with AD CS on Windows Server 2025. Microsoft Learn says this needs:

• Two servers running Windows Server 2025 with the May 2026 security update (KB5087539) or later, one for the root CA and one for the subordinate CA
• A domain-joined subordinate CA
• A root that is either domain-joined or standalone. Microsoft recommends a standalone root taken offline for production, and says an enterprise root suits lab and test setups.

The overview page lists further platform requirements. All PQC algorithms need CNG key storage providers, and AD CS doesn't support legacy CSPs. Clients need Windows 11 24H2 or 25H2 with the October 2025 non-security update (KB5067036) or later. ML-DSA is Phase 1 for AD CS. ML-KEM and composite ML-DSA are planned for Phase 2.

One practical detail: when you pick an ML-DSA provider, the hash algorithm defaults to NoHash. ML-DSA hashes messages internally and needs no external hash. If you script CA setup with the usual RSA-and-SHA-256 habits, expect to change them.

Don't read the AD CS documentation as proof that every Windows feature accepts ML-DSA. Independent analysts note gaps. Encryption Consulting reports that smart card logon and PKINIT don't yet support ML-DSA in this release. It also says AD CS can't upgrade an existing CA in place, so you must stand up a new parallel hierarchy. Both are third-party observations, not Microsoft statements in the material I reviewed, so verify them against current Microsoft documentation.

A practical readiness plan​

Microsoft's six steps, with some of my own commentary:

1. Inventory certificate-dependent systems. Include applications, services, devices, appliances and infrastructure. Be ruthless. The forgotten load balancer is usually the one that bites.
2. Map trust relationships. Document public and private PKI, internal hierarchies, trust anchors, device authentication and externally managed certificates.
3. Assess vendor readiness. Ask CA, PKI, HSM, software and platform vendors for their PQC roadmaps and test capabilities.
4. Find long-lived infrastructure. Embedded devices, OT and security appliances top the list.
5. Build a safe test strategy. Use isolated non-production environments. Never put pilot certificates in front of production or public-facing services.
6. Create a multi-year roadmap. Assign owners, sequence dependencies and let test results set priorities.

Also ask your CA whether it is in the pilot. If it is in the Trusted Root Program but not the pilot, Microsoft suggests nudging it to apply.

Analysis: sensible urgency, no deadline​

This is Microsoft's own security blog encouraging readiness, so read it as guidance and not as a mandate. Microsoft hasn't announced a production migration deadline in this material, and the pilot is explicitly experimental. The company also has an interest in having its platforms look ready. Even so, the advice holds up on its own merits. The pilot's reporting rules and the "not for production" warnings back the central point, which is that the unknowns sit in operational plumbing. An inventory costs little, and finding an HSM or inspection appliance that chokes on large certificates is far cheaper in a lab than during an outage.

The industry context supports a measured pace. A DigiCert summary of a CA/Browser Forum meeting said Microsoft announced the pilot as test-only, and that DigiCert was drafting a ballot to allow ML-DSA in the TLS Baseline Requirements once production capabilities exist. One vendor blog claims no public root has yet issued an ML-DSA chain into the major trust stores. That is a vendor claim, but it fits the pilot's design: everything here is preparation.

Bottom line​

• The Microsoft PQC TLS pilot is for approved CAs, not for general enterprise enrollment.
• Pilot certificates are not publicly trusted and must stay out of production.
• Windows 11 and Windows Server 2025 have specific update prerequisites for ML-DSA testing.
• The best first move is unglamorous: inventory your certificates, ask your vendors hard questions, and build a lab.