Microsoft Tests Post-Quantum Certificates Before Enterprise Rollout

Microsoft is asking certificate authorities and enterprise PKI teams to test post-quantum TLS certificates now, while the trust chain can still be kept inside a lab. Its October 8 research post describes a pilot that issues certificates using ML-DSA-87, with seven pilot roots added in August. Those certificates are for closed test environments; they carry no public trust. The immediate risk for operators is a future authentication migration that fails at an application, appliance, or certificate-management step even when the cryptography itself works.

Microsoft’s October 8 account of the August pilot gives PKI owners an end-to-end test path and the Windows starting builds. They can find brittle dependencies before a production authentication change causes an outage.

A certificate crosses many systems

A TLS certificate is useful only when the software at the other end can build and validate its chain to a trusted root. Before that handshake, an issuer created the certificate, key material was stored, and someone distributed the relevant trust anchors. Renewal and inspection systems then have their own assumptions about algorithms and sizes. Microsoft writes that changes can reach beyond “cryptographic correctness into operational processes, interoperability, and infrastructure readiness.” Microsoft is evaluating its own pilot; measure compatibility in your environment.

Larger post-quantum certificates and chains can put pressure on handshake size, storage, transmission and inspection limits, according to Microsoft. An application that accepts a certificate in isolation might still fail when its TLS stack, proxy, HSM or management process encounters the complete chain. Long-lived devices, security appliances and operational technology deserve particular attention because their upgrade cycles and embedded assumptions are harder to change. The operational question is which component actually issues, stores, distributes or validates each chain, and which team owns it.

Pilot roots belong in closed labs

Microsoft launched its PQC TLS Pilot Program on August 27 for approved certificate authorities in good standing with its Trusted Root Program. The August release added seven pilot roots operated by ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority and SSL.com. Their ML-DSA-87 certificates are intended for interoperability tests in closed environments, custom applications and enterprise testbeds. Microsoft says they must stay out of production trust scenarios and public-facing websites; support for these certificates remains limited and evolving.

For a Windows lab, Microsoft identifies the July 28 updates as the starting point for supported, appropriately configured Windows 11 tests: KB5101681 (28000.2608) for 26H1 and KB5101684 (26200.8973 or 26100.8973) for 25H2. Microsoft’s 26H1 update record and 25H2/24H2 update record identify those as preview builds and confirm their OS-build mapping; the pilot post supplies the ML-DSA test context. Check the applicable Windows and Schannel requirements on each machine before running a test. A newer build number alone is a poor substitute for an actual application-level validation run.

Map the chain before testing

Start with the certificate-dependent applications, services, devices and appliances you operate. Record the issuing CA, public or private hierarchy, trust anchors, key storage, renewal workflow and the endpoints or intermediaries that validate the chain. Include certificate-management systems and network inspection in the map, alongside the HSM and vendors that support long-lived hardware. This gives the test a real route through your estate rather than an artificial pair of endpoints.

Then ask the certificate provider whether it participates in the pilot and offers an appropriate closed test path. Put pilot roots only in that testbed’s trust store, keep its traffic and services separate from production, and exercise issuance, distribution, renewal and validation through the actual application and, where supported, Schannel. Record rejected chains or handshakes, parsing errors, certificate and handshake sizes, latency and the workflow step that fails. These are proposed test observables drawn from the compatibility questions Microsoft lists, not published measurements of an enterprise deployment.

Keep trust limited to testbeds

Have the PKI owner choose one representative application and one long-lived device or appliance from the dependency map. With an eligible certificate provider, run their normal certificate-validation path in an isolated environment.

1. Check the Windows test system’s installed build against the supported pilot starting points: 28000.2608 for 26H1, or 26200.8973 or 26100.8973 for 25H2. Confirm the pilot root exists only in the lab trust store and that the applicable Schannel and application requirements are met. Save the installed build and a lab/production trust-store inventory with the test results; the production inventory should contain no pilot root.
2. Check whether the application completes a TLS handshake with the pilot chain, whether the inspection path handles its size, and whether the team can renew it through its normal workflow. Capture the test application’s TLS handshake log with its certificate-validation status or chain-rejection error, then save the handshake size, latency and renewal result alongside the existing-chain baseline.

A successful test produces a completed application-level handshake and documented renewal path while the pilot root stays in the lab trust store. Use failures to prioritize vendor changes and the next round of testing.