The technical groundwork for a quantum-resistant internet is further along than the policy needed to build it. The IETF finalized the standard for encoding ML-DSA signatures within X.509 certificates in RFC 9881 in October 2025, yet as of this year the CA/Browser Forum has not approved their use in publicly trusted TLS certificates. This creates a clear timeline; organizations can begin building post-quantum certificate authorities now, but widespread adoption for secure browsing remains a future goal. Encryption, facing the immediate threat of “store now, decrypt later” attacks, prioritized key exchange solutions before signature updates.
NIST FIPS 204/205: ML-DSA and SLH-DSA Signature Standards
This discrepancy highlights a growing gap between the readiness of post-quantum cryptographic algorithms and the policy frameworks needed for their widespread deployment, a situation that could delay the transition to a quantum-resistant internet. NIST’s finalized standards, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA, published on August 13, 2024, define distinct approaches to quantum-resistant cryptography, each with its own performance characteristics and ideal use cases. ML-DSA, based on module lattices, offers relatively small public keys and signatures alongside fast signing speeds, making it suitable for a wide range of applications including intermediate and leaf certificates.
Conversely, SLH-DSA relies solely on the security of hash functions, resulting in minimal public key sizes but significantly larger signatures and slower signing processes. This profile positions it as a strong candidate for long-lived root certificates and firmware, where infrequent signing and longevity are paramount.
The trade-offs between these two algorithms are clearly delineated in the FIPS documents, with ML-DSA signatures ranging from 2.4 to 4.6 KB compared to SLH-DSA’s 7.9 to 49.9 KB. The choice between ML-DSA and SLH-DSA also impacts certificate chain design, with each removed intermediate certificate potentially saving approximately 5 KB in chain size when using ML-DSA-65.
The differing characteristics of these algorithms also influence the decision of whether to adopt hybrid certificates, which combine post-quantum and classical signatures, or to transition directly to pure post-quantum cryptography. While hybrid approaches offer backward compatibility, the performance benefits of ML-DSA may incentivize a faster transition to fully post-quantum solutions in certain scenarios.
“not every browser, server or device understands ML-DSA / SLH-DSA yet,” indicating that interoperability remains a key challenge. The CA/Browser Forum minutes from May 2026 record that ML-DSA trust anchor support for private PKI in TLS 1.3 will ship in Chrome 150, a development focused on internal, controlled environments rather than the broader public web.
This fundamental difference in approach allows organizations to diversify their cryptographic defenses and mitigate the risk of a single vulnerability compromising their entire infrastructure. “Internet X.509 PKI: Algorithm Identifiers for ML-DSA” and “Internet X.509 PKI: Algorithm Identifiers for SLH-DSA” are the respective RFCs defining the encoding of these algorithms within X.509 certificates.
ML-DSA Certificate Size Impact on X.509 Chains
An ML-DSA-65 certificate, signed by a similarly configured certificate authority, carries 5,261 bytes of public key and signature data, a substantial increase compared to the tens of bytes typical of ECDSA P-256 certificates, impacting network performance and device compatibility.
This size difference necessitates careful consideration of network conditions, as extra round trips may be required on lossy networks, and thorough testing of middleboxes, load balancers and proxies to ensure they can handle the larger payloads without truncation. IoT and OT devices, often constrained by limited memory, slow network links, or fixed certificate storage, may prove unable to accommodate or parse ML-DSA certificate chains, creating a significant challenge for widespread deployment.
The increased certificate size extends beyond the initial handshake; certificate databases, Certificate Revocation Lists signed with ML-DSA, Online Certificate Status Protocol responses, and Certificate Transparency logs all experience growth, demanding increased storage capacity and bandwidth. Capacity within Certificate Transparency logs is already a subject of discussion within the CA/Browser Forum, highlighting a potential bottleneck for scaling post-quantum PKI. The source details that ML-DSA-65 is a reasonable default for intermediate and server certificates, while ML-DSA-87, offering higher assurance, is suitable for root certificates, and ML-DSA-44 is best when certificate size is paramount.
This approach allows organizations to gain experience with the new technology and identify potential issues before transitioning to a fully post-quantum environment. “Post-quantum PKI starts at the top of the hierarchy and with trust distribution, not with the last leaf certificate,” the source emphasizes, emphasising the importance of a phased and strategic implementation.
IETF Standards: RFC 9881 Encoding for ML-DSA
The technical specification for integrating ML-DSA signatures into standard X.509 certificates finalized in October 2025 with the publication of RFC 9881, detailing how to encode the Module-Lattice-Based Digital Signature Algorithm within the widely used certificate format. This standardization precedes broad public trust, as the CA/Browser Forum has yet to approve a ballot permitting ML-DSA in publicly trusted Transport Layer Security certificates as of mid-October 2026. The delay highlights a critical gap between technical readiness and the policy changes needed for widespread deployment of quantum-resistant cryptography.
This efficiency gain encourages a re-evaluation of existing certificate hierarchies, potentially streamlining them for improved speed and reduced bandwidth consumption. The ACME automation guide for private certificate authorities, coupled with a 47-day TLS certificate lifetime timeline, offers a pathway for organizations to plan and implement fully automated issuance processes. This explains why efforts to secure key exchange mechanisms preceded the widespread adoption of post-quantum signatures.
The source addresses a common question: “What is an ML-DSA certificate?” defining it as an X.509 certificate using ML-DSA for its public key and signature, designed to withstand attacks from quantum computers. “Use pure ML-DSA where you control the issuer and every relying party,” the source advises, “Use composite certificates where policy requires a classical component or you want a hedge against PQC implementation bugs.” ML-DSA is generally well-suited for most certificate applications, while SLH-DSA is recommended for long-lived root certificates and firmware signing. The source also provides guidance on selecting appropriate ML-DSA parameter sets, defined in FIPS 204, based on security requirements and certificate size considerations.
Private PKI Adoption Prior to Public TLS Support
The absence of a formal ballot allowing ML-DSA in publicly trusted TLS certificates, as of October 2026, distinguishes the timeline for private versus public key infrastructure adoption, according to minutes from the CA/Browser Forum. While broad public deployment remains pending, organizations controlling both certificate issuance and relying parties can immediately begin building and testing post-quantum certificate authorities internally. This divergence stems from the control private PKI offers over trust anchors and client libraries, circumventing the need for wider industry consensus.
The source notes that ML-DSA-65 often is a practical default for certificate and server authentication, while ML-DSA-87 is better suited for root certificates and high-assurance applications, and ML-DSA-44 prioritizes minimal certificate size. These differing characteristics allow organizations to tailor their PKI to specific risk profiles and performance requirements. This initial step, coupled with identifying every certificate consumer requiring a new trust anchor, is critical for a smooth transition. Running parallel classical and post-quantum chains allows for gradual adoption as clients become ready.
The differing quantum risks facing encryption and signatures also influence the order of implementation. Chrome 150 is slated to include support for ML-DSA trust anchors within private PKI deployments using TLS 1.3, as recorded in the May 2026 CA/Browser Forum minutes. This browser-level support is a key enabler for organizations seeking to deploy post-quantum certificates within their internal networks, CA/Browser Forum says. The ability to build and measure a post-quantum PKI in a private setting provides valuable experience and insights as the public WebPKI rules continue to evolve.
Hybrid vs Pure PQC Certificates: Decision Factors
The transition to post-quantum cryptography isn’t a wholesale replacement, but a subtle decision between hybrid and pure ML-DSA certificates, with private PKI deployments leading the way. Organizations with internal certificate authorities, however, can begin implementation now, controlling both the issuer and all relying parties within their ecosystem. Hybrid certificates combine a post-quantum algorithm, such as ML-DSA-65, with a classical algorithm like ECDSA P-256, ensuring continued security even if one algorithm is compromised.
This size difference, though often minor, can be a consideration for bandwidth-constrained environments or devices. The IETF has defined how to encode ML-DSA in X.509 certificates in RFC 9881 (October 2025).
The source emphasizes that a practical migration path for internal PKIs begins with a thorough inventory of existing certificates, CAs and consumers, mapping out key sizes, validity periods and key storage locations. Vault-backed CAs, using hardware security modules like those from Securosys, are recommended for generating and protecting both post-quantum and classical signing keys, with leaf keys also residing within the vault. The selection of signature algorithms also varies by use case.
The source poses the question, “Which ML-DSA parameter set should I use?” and directs readers to relevant documentation for guidance. RFC 9881, published in October 2025, defines the algorithm identifiers for ML-DSA within X.509 certificates, while RFC 9909, from December 2025, does the same for SLH-DSA, both as IETF Proposed Standards.
The source advises using pure ML-DSA certificates when full control over the issuer and all relying parties is maintained. Composite certificates are more appropriate when policy dictates a classical component or as a hedge against potential implementation bugs in post-quantum algorithms. Parallel classical and PQC chains can also be deployed to support clients that remain classical-only.
See today’s quantum computing news on Quantum Zeitgeist for the latest breakthroughs in qubits, hardware, algorithms, and industry deals.
