Microsoft has introduced seven post-quantum cryptography (PQC) pilot roots through its Trusted Root Program. Microsoft requires ML-DSA-87, the Category 5 parameter set, at the trust anchor while allowing ML-DSA-44 and ML-DSA-65 for subordinate certification authorities (CAs) and leaf certificates.
I read that asymmetry as a stress condition rather than a design recommendation for every certificate in a future TLS hierarchy. The pilot can test where maximum post-quantum signature strength adds useful assurance and where it adds size, complexity, and compatibility risk.
Start with the pilot’s actual boundary
Microsoft’s PQC TLS Pilot Program requirements are explicit about what this is not. Certificates under the program are not publicly trusted, are not intended for production or public-facing web connections, will not be added to the Common CA Database or Certificate Transparency logs, and will not be considered for public-trust inclusion by Microsoft. The intended environments are closed testing, custom applications, and enterprise testbeds.
Microsoft also describes ML-DSA support as limited and evolving. Compatibility may change, complete functionality is not expected across every Microsoft product and library, and the capability should not be relied upon for production trust.
The August 2026 deployment notice lists seven participating PQC roots from ComSign, DigiCert, HARICA, IdenTrust, Sectigo, Shanghai Electronic Certification Authority, and SSL.com. This is an interoperability experiment, not a conversion of the public Web PKI.
Why put ML-DSA-87 at the root?
FIPS 204 defines three ML-DSA parameter sets. Microsoft’s current implementation guidance records the following sizes:
| Parameter set | NIST security category | Public key | Signature |
|---|---|---|---|
| ML-DSA-44 | 2 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 3 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | 5 | 2,592 bytes | 4,627 bytes |
The instinct behind Category 5 is understandable. A root key is the hierarchy’s highest-consequence signing key. If it is compromised or its signature scheme fails, every subordinate trust path beneath it becomes suspect. A conservative architect may therefore choose the largest available security margin for the trust anchor.
ML-DSA-87 may also establish a worst-case compatibility envelope. It forces root distribution, certificate parsers, path builders, CA software, hardware security modules, revocation infrastructure, and operational processes to encounter the largest ML-DSA key and signature. Systems that support only the smaller variants would not pass that test.
Microsoft has not published a rationale choosing between those explanations. They are inferences, not statements of Microsoft’s intent. The pilot requirements do, however, require participating CAs to report breakage across tooling, HSMs, validation, encoding, parsing, root distribution, and TLS interoperability. That makes stress testing a reasonable interpretation.
One hierarchy does not require one parameter set
The most useful feature of the pilot may be the choice it preserves below the root. ML-DSA-44 and ML-DSA-65 cannot be used for a pilot root, but either may be used for subordinate CAs or leaf certificates.
The subordinate certificate has two relevant algorithms. Its subject public key can be ML-DSA-65 while its certificate signature is ML-DSA-87 because the root signed it. Microsoft’s AD CS configuration guidance illustrates that combination.
The self-signed root is normally already in the relying party’s trust store and is generally not transmitted by the TLS server. Its large self-signature does not appear in every handshake. The subordinate certificate sent in the chain does carry the root’s ML-DSA-87 signature, so the root’s algorithm choice can still increase the transmitted authentication data. It also affects root-store handling, path validation, CA operations, CRLs, tooling, and HSM support.
“Category 5 at the root” and “Category 5 everywhere” are different architecture decisions.
Highest category is not the same as best fit
A higher NIST security category provides a larger cryptanalytic security margin. It does not, by itself, provide a higher-assurance PKI.
The hierarchy still depends on implementation quality, private-key protection, issuance policy, identity proofing, revocation behavior, parser correctness, trust-store governance, and the security of every relying party. If the leaf uses ML-DSA-44, calling the entire path “Category 5” would hide those boundaries. If a verifier mishandles an unfamiliar encoding, the theoretical strength of the signature does not restore interoperability.
There is also a tension in the usual longevity argument. Production roots often live for years, which can justify giving them additional security margin. Microsoft limits these pilot roots to one year. Long-term protection may still inform the architecture being simulated, but the pilot certificate’s own lifetime does not fully explain why ML-DSA-87 is mandatory.
The strongest root exposes the upper bound. The pilot can then measure whether smaller parameter sets at the issuing and leaf layers provide a better balance for specific use cases.
MTC asks a different question
Optimizing parameter sets still leaves the conventional X.509 model intact: a CA signs each certificate, logs add further signed objects, and the server presents a certificate chain during TLS authentication.
Merkle Tree Certificates (MTC) change that structure. The current IETF PLANTS working-group draft integrates logging with issuance. The CA validates a request, appends an entry to its own issuance log, and signs checkpoints or subtrees. Cosigners verify the log’s consistency and sign the same views. A mirroring cosigner can also preserve and serve the log.
The diagram below is a separate trust model. It is not a branch beneath the ML-DSA-87 pilot root shown above, and Microsoft’s pilot does not combine the two architectures.
The two profiles serve different conditions. A standalone certificate carries an inclusion proof, the CA signature, and enough cosignatures to satisfy relying-party policy. A landmark-relative certificate carries only the inclusion proof. It works when the browser already has the applicable landmark state through its update channel. Servers are expected to retain the standalone form as a fallback.
MTC is not part of Microsoft’s announced PQC pilot. It is a useful comparison because it exposes two migration strategies:
- Parameterize the existing hierarchy: keep X.509 certificate chains and determine where ML-DSA-44, ML-DSA-65, or ML-DSA-87 belongs.
- Change the authentication structure: amortize CA and witness signatures across a Merkle tree, then prove that a leaf was included.
The first path tests the limits of the current certificate chain. The second changes the object that carries the binding from a chain of signatures to proof against logged state.
What the pilot should help us measure
The pilot will be most valuable if “works” is broken into observable results. A useful evaluation should distinguish at least:
- encoded root, subordinate, leaf, and complete chain sizes;
- what the server actually transmits, including TLS record fragmentation;
- latency and retransmission effects under realistic loss and constrained networks;
- signing and verification cost by parameter set;
- memory, parser, path-building, HSM, enrollment, CRL, and management-tool behavior;
- failure modes when one participant does not recognize an algorithm or encoding; and
- the operational cost of mixed ML-DSA parameter sets within one hierarchy.
An MTC comparison would need its own measurements: proof size, checkpoint and witness distribution, freshness assumptions, mirror availability, client state, issuance delay, monitoring, and recovery when tree state is unavailable or inconsistent. Comparing only nominal certificate byte counts would miss the change in trust and availability assumptions.
Treat Category 5 as evidence to collect
Microsoft’s pilot does not prove that ML-DSA-87 should become the default trust anchor for the public Web PKI. It creates a controlled place to identify which assumptions in certificate software, trust distribution, and CA operations break when post-quantum signatures reach their largest standardized ML-DSA profile.
My perspective is that Category 5 belongs in the pilot because it is demanding. The result should be evidence, not an inherited default. Future profiles should assign algorithm strength by threat model, security lifetime, hierarchy role, performance envelope, and operational dependency instead of copying the largest parameter set because it appeared first at the root.
The post-quantum transition requires decisions about the trust architecture as well as the signature algorithm. Microsoft’s pilot tests the existing X.509 structure. MTC tests a different structure for the public web.
Sources
- Microsoft Trusted Root Program: PQC TLS Pilot Program Requirements V1.0
- Microsoft Trusted Root Program: August 2026 deployment notice
- Microsoft Learn: Configure a certification authority to use ML-DSA
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- IETF Internet-Draft: Merkle Tree Certificates
- Unmitigated Risk: The Post-Quantum WebPKI