ML-DSA Certificates and Post-Quantum PKI: Building a Quantum-Safe CA (2026 Guide)

ML-DSA certificates are X.509 certificates whose public key and signature use ML-DSA, the Module-Lattice-Based Digital Signature Algorithm that NIST standardized in FIPS 204 in August 2024. They replace RSA and ECDSA signatures, which a large enough quantum computer could forge, with a signature scheme designed to resist quantum attacks. The IETF has defined how to encode ML-DSA in X.509 certificates in RFC 9881 (October 2025).

The decision for a security team is no longer whether to move a PKI to post-quantum signatures, but where to start and in what order. Public TLS isn't ready: as of October 2026 the CA/Browser Forum has not adopted a ballot that allows ML-DSA in publicly trusted TLS certificates. Private PKI is a different story. When you run the CA and control both the issuer and the relying parties, you can start building and testing a post-quantum certificate authority now.

This guide covers what ML-DSA and SLH-DSA are, the real size impact on certificate chains, where the IETF standards stand, when to choose hybrid (composite) certificates over pure post-quantum ones, and a step-by-step migration path for a private CA hierarchy.

---

Table of Contents

1. Why Post-Quantum PKI Matters Now
2. ML-DSA and SLH-DSA: The Two NIST Signature Standards
3. What Changes in Certificates and Chains
4. Standards Status: IETF LAMPS and the CA/Browser Forum
5. Why Start with Private PKI
6. Hybrid Certificates vs Pure PQC: Decision Table
7. Migration Path for a Private CA Hierarchy
8. Running a Post-Quantum Certificate Authority with DuoKey
9. FAQ

---

Why Post-Quantum PKI Matters Now

Encryption and signatures face different quantum risks. Encrypted traffic can be recorded today and decrypted later (store now, decrypt later), which is why key exchange moved first. Signatures are checked at the moment of use, so a forged signature only matters once someone can actually forge one. That sounds like more time, but PKI has the longest lead times in cryptography:

• Root CAs live for years. A root created today is often still trusted a decade later. A root you create with RSA or ECDSA now has to be replaced before quantum forgery becomes practical.
• Trust stores move slowly. Getting a new root into every server, laptop, container image, appliance and embedded device takes longer than issuing it.
• Long-lived signatures exist. Firmware, code signing and signed documents may need to verify for many years.

A PKI migration therefore starts with the top of the hierarchy and with distributing trust, long before the last leaf certificate changes. Regulators expect a plan; for Swiss banks, see the FINMA 05/2026 post-quantum migration.

---

ML-DSA and SLH-DSA: The Two NIST Signature Standards

NIST published both standards on 13 August 2024:

• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Standard), derived from CRYSTALS-Dilithium.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Standard), derived from SPHINCS+.

ML-DSA parameter sets (FIPS 204)

FIPS 204 defines three parameter sets. Sizes are in bytes, from FIPS 204 Table 2; security categories from Section 4.

FIPS 204 does not express strength as "128 bits of security". Each category means breaking the parameter set needs at least the resources required to break a reference block cipher or hash function. In practice, ML-DSA-65 is a common default for CA and server certificates, ML-DSA-87 for roots and high-assurance use, and ML-DSA-44 where size matters most.

SLH-DSA: small vs fast

SLH-DSA relies only on the security of hash functions, a conservative assumption that is independent of the lattice mathematics behind ML-DSA. FIPS 205 approves 12 parameter sets, each instantiated with SHA-2 or SHAKE. The suffix tells you the trade-off: "s" sets are designed for relatively small signatures, "f" sets for relatively fast signature generation.

Public keys are tiny, signatures are large, and signing is slow compared with ML-DSA. That makes SLH-DSA a fit for roots and other keys that sign rarely and must last a long time, and a poor fit for TLS leaf certificates that sign on every handshake.

ML-DSA vs SLH-DSA at a glance

---

What Changes in Certificates and Chains

An X.509 certificate carries the subject's public key and the issuer's signature. With ECDSA P-256 both are measured in tens of bytes. With ML-DSA they are measured in kilobytes.

Using the FIPS 204 sizes, an ML-DSA-65 certificate signed by an ML-DSA-65 issuer carries 1,952 + 3,309 = 5,261 bytes of key and signature material before any names or extensions. In a TLS 1.3 handshake the server typically sends its leaf and intermediate certificates plus a CertificateVerify signature, so an all-ML-DSA-65 chain adds roughly:

What this means in practice:

• Handshake size. A chain of more than 13 KB no longer fits in a few packets. Expect extra round trips on lossy networks and check middleboxes, load balancers and proxies with fixed buffer limits.
• Constrained devices. IoT and OT devices with small memory, slow links or fixed certificate storage slots may not be able to hold or parse ML-DSA chains. Inventory them early.
• Storage and logging. Certificate databases, CRLs signed with ML-DSA, OCSP responses and Certificate Transparency logs all grow. CT log capacity is one of the concerns raised in the CA/Browser Forum discussions.
• Short chains help. Every intermediate you remove saves about 5 KB with ML-DSA-65. Post-quantum is a good moment to flatten hierarchies that grew for historical reasons.

Use the ACME automation guide for private CAs and the 47-day TLS certificate lifetime timeline to plan the renewal side: shorter lifetimes and larger certificates both push towards fully automated issuance.

---

Standards Status: IETF LAMPS and the CA/Browser Forum

The composite draft defines 18 combinations of ML-DSA with a traditional algorithm, for example id-MLDSA65-ECDSA-P256-SHA512 and id-MLDSA87-ECDSA-P384-SHA512. A composite signature is valid only if every component signature verifies, so an attacker would have to break both algorithms. Until the RFC is published, OIDs and encodings can still change; keep composite certificates in test or private use and track the final RFC.

Public TLS. The CA/Browser Forum's Server Certificate Working Group has been working on an "Allow ML-DSA" ballot since at least spring 2026. The May 2026 minutes record open questions on Certificate Transparency log capacity and whether traditional X.509 certificates will be part of the post-quantum transition at all; Merkle Tree Certificates were also mentioned. The August 2026 minutes say work continues towards a combined ballot. No ML-DSA ballot appears on the Forum's ballot list. The same May minutes record that ML-DSA trust anchor support for private PKI in TLS 1.3 will ship in Chrome 150.

---

Why Start with Private PKI

A private (internal) CA is where post-quantum certificates are usable today, for three reasons:

1. You control both ends. You decide which trust anchors your clients install and which libraries your servers run. No root program has to approve your root.
2. The blast radius is bounded. You can pilot ML-DSA on one service mesh, one VPN, one device fleet, and roll back without affecting customers.
3. It produces the evidence you need. Real measurements of handshake size, latency and device compatibility in your environment are what turn a roadmap into a funded project.

Typical first candidates: service-to-service mTLS inside Kubernetes, internal APIs, VPN and device identity where you ship the client, and code or firmware signing with your own verifier. Keep public-facing websites on classical certificates from public CAs until the WebPKI rules change. If your internal PKI runs on Active Directory Certificate Services, review its known limitations (see Related Resources) before planning a PQC hierarchy on it.

---

Hybrid Certificates vs Pure PQC: Decision Table

Hybrid certificates combine a post-quantum and a classical algorithm so the result stays secure as long as either one holds. The approach standardized in IETF LAMPS is the composite certificate: one certificate with one composite public key and one composite signature (for example ML-DSA-65 + ECDSA P-256). The alternative is parallel chains: a classical chain and a pure PQC chain side by side, with each client using the one it understands.

Two points that often get missed. A composite certificate is not readable by a classical-only client: it uses a new algorithm identifier, so an old verifier still fails. And composite certificates are slightly larger than pure ML-DSA ones, since they also carry the classical key and signature.

---

Migration Path for a Private CA Hierarchy

A practical sequence for moving an internal PKI to post-quantum signatures:

Step 1: Inventory what you have

List every CA, its algorithm, key size, validity and where its key lives, plus every certificate consumer that will need a new trust anchor. A cryptographic bill of materials (CBOM) and a discovery scan give you the starting point; cryptographic posture management keeps it current.

Step 2: Choose algorithms per tier

The issuing CA's algorithm must be one its parent can sign and its children's verifiers understand. Do not mix a PQC intermediate under a classical root and call the chain quantum-safe: an attacker who can forge the root's signature can forge the whole chain.

Step 3: Create a new PQC root in parallel

Generate the new root key in an HSM or vault, never on a workstation. Keep the existing classical root running. The two hierarchies operate side by side during the transition.

Step 4: Distribute the new trust anchor early

This is the longest step. Push the PQC root into OS trust stores, container base images, Java truststores, mobile device management profiles and device firmware. Distributing the anchor costs nothing at runtime until it is used, so start now even if issuance comes later.

Step 5: Issue PQC intermediates, then leaves

Create ML-DSA intermediates under the new root. Move one service group at a time to leaves from the PQC chain, using automated enrollment (ACME, EST, SCEP or CMP) so renewal does not depend on people.

Step 6: Run parallel chains, measure, then cut over

Serve classical and PQC chains to the clients that support each. Measure handshake size, latency and failures. When a group of relying parties is fully PQC-capable, stop issuing classical certificates to it.

Step 7: Retire the classical hierarchy

Let classical leaves expire, revoke what remains, publish final CRLs, then remove the classical root from trust stores.

---

Running a Post-Quantum Certificate Authority with DuoKey

DuoKey's certificate management in DuoKey Cockpit is built for the migration path above. According to DuoKey's PKI documentation:

• Algorithms. RSA-2048/4096, EC-P256/P384, ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) and a hybrid composite ML-DSA-65 + ECDSA-P256, a pairing that also appears in the IETF composite draft's list.
• CA hierarchy. Root, intermediate/issuing and external (imported) CAs. Cockpit enforces parent-algorithm compatibility, so PQC and hybrid chains verify end to end. CA lifecycle covers suspend and reactivate, simple and cascade revoke, and archive.
• Vault-signed PQC CAs. PQC and hybrid CA signing keys live in the vault or HSM and are not generated locally; for issued PQC certificates, the leaf key is also vault-resident. Vault-backed CAs can use external HSM-backed vaults, for example Securosys (FIPS 140-2 Level 3 HSM).
• Lifecycle. CSR approval workflow (request, approve or reject, issue), renew, revoke with RFC 5280 reasons, and a per-CA CRL and OCSP responder.
• Enrollment. ACME (RFC 8555) with http-01 and dns-01 challenges, EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager via ACME, and a KMIP 2.1 server endpoint, plus deployment connectors with per-job validation and rollback.

Pointing Kubernetes cert-manager at a DuoKey CA over ACME uses the CA's directory URL:

# ClusterIssuer pointing cert-manager at a DuoKey CA over ACME
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory

DuoKey's documentation gives the same recommendation as this guide: use PQC where you control both ends, and use the hybrid composite where you must interoperate with classical relying parties, because "not every browser, server or device understands ML-DSA / SLH-DSA yet."

To find which certificates and keys need to move first, start with the free Quantum Readiness Score.

---

FAQ

Q: What is an ML-DSA certificate?

An ML-DSA certificate is an X.509 certificate that uses ML-DSA (FIPS 204) for its public key and signature instead of RSA or ECDSA. The encoding is defined in RFC 9881. It is designed to remain secure against attacks by quantum computers.

Q: Do browsers support ML-DSA certificates?

Not for the public web yet. The CA/Browser Forum has not adopted a ballot allowing ML-DSA in publicly trusted TLS certificates, so public CAs cannot issue them for websites. For private PKI, CA/B Forum minutes from May 2026 record that ML-DSA trust anchor support for private PKI in TLS 1.3 will ship in Chrome 150.

Q: What is the difference between ML-DSA and SLH-DSA?

ML-DSA (FIPS 204) is lattice-based, with keys and signatures of a few kilobytes and fast signing. SLH-DSA (FIPS 205) relies only on hash functions, with 32-64 byte public keys but signatures from about 7.9 KB to 49.9 KB and slower signing. ML-DSA suits most certificates; SLH-DSA suits long-lived roots and firmware signing.

Q: What is a composite (hybrid) certificate?

A composite certificate holds one combined public key, for example ML-DSA-65 + ECDSA P-256, and one combined signature that is valid only if both component signatures verify. It is defined in the IETF LAMPS draft draft-ietf-lamps-pq-composite-sigs, which is in the RFC Editor queue but not yet published as an RFC.

Q: Which ML-DSA parameter set should I use?

ML-DSA-65 (category 3) is a reasonable default for intermediates and servers. Use ML-DSA-87 (category 5) for roots or high-assurance requirements, and ML-DSA-44 (category 2) where certificate size is the main constraint.

Q: How much bigger are ML-DSA certificates?

An ML-DSA-65 certificate signed by an ML-DSA-65 CA carries 5,261 bytes of public key and signature, against tens of bytes for ECDSA P-256. A two-certificate chain plus the handshake signature adds about 13.8 KB to a TLS 1.3 handshake.

Q: Is ML-DSA standardized for X.509?

Yes. RFC 9881 (October 2025) defines ML-DSA algorithm identifiers for X.509, and RFC 9909 (December 2025) does the same for SLH-DSA. Both are IETF Proposed Standards.

Q: Should I use hybrid or pure post-quantum certificates?

Use pure ML-DSA where you control the issuer and every relying party. Use composite certificates where policy requires a classical component or you want a hedge against PQC implementation bugs, and parallel classical and PQC chains where some clients remain classical-only.

Q: Can I build a post-quantum certificate authority today?

Yes, for private PKI. Create a PQC root in an HSM or vault, distribute it to your trust stores, then issue ML-DSA intermediates and leaves through automated enrollment, running parallel chains until your clients are ready.

---

Conclusion: A Post-Quantum PKI Checklist

Post-quantum PKI starts at the top of the hierarchy and with trust distribution, not with the last leaf certificate. Private PKI is where you can build and measure it today, while the public WebPKI rules are still being written.

• Inventory every CA, its algorithm, validity and key location
• List relying parties that will need a new trust anchor, including constrained devices
• Choose algorithms per tier (for example ML-DSA-87 or SLH-DSA root, ML-DSA-65 intermediates)
• Generate the PQC root in an HSM or vault, in parallel with the classical root
• Start distributing the PQC trust anchor now
• Automate enrollment (ACME, EST, SCEP or CMP) before issuing PQC leaves
• Pilot on one internal service group and measure handshake size and failures
• Decide pure PQC, composite or parallel chains per relying-party group
• Track the composite RFC and the CA/B Forum ML-DSA ballot

---

Further reading

• PKI as a service: managed private CA
• Certificate lifecycle management (CLM)

---

References

• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 204 (PDF), Tables 1 and 2
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST FIPS 205 (PDF), Table 2
• RFC 9881: Internet X.509 PKI: Algorithm Identifiers for ML-DSA
• RFC 9909: Internet X.509 PKI: Algorithm Identifiers for SLH-DSA
• IETF draft-ietf-lamps-pq-composite-sigs: Composite ML-DSA for X.509
• CA/Browser Forum Ballot SMC013: Enable PQC Algorithms for S/MIME
• CA/Browser Forum: Server Certificate WG minutes, 21 May 2026
• CA/Browser Forum: Server Certificate WG minutes, 13 August 2026
• CA/Browser Forum: All ballots
• DuoKey Docs: PKI and SSL overview
• DuoKey Docs: Post-quantum certificates
• DuoKey Docs: Enrollment protocols