Certificate Authorities Preparing for Post-Quantum
The transition to post-quantum cryptography (PQC) in the Web Public Key Infrastructure (WebPKI) is one of the most complex coordination challenges in the history of internet security. Unlike key exchange, where browsers and servers can negotiate quantum-safe algorithms bilaterally, certificate issuance requires alignment across certificate authorities, browser root programs, and standards bodies. This article tracks which CAs are issuing post-quantum certificates today, what the IETF LAMPS Working Group has delivered, and when we can realistically expect PQ certificates in production WebPKI chains.
Current state: who is issuing post-quantum certificates
As of August 2026, no certificate authority issues post-quantum certificates that are trusted by default in any major browser root program. All current PQ certificate issuance falls into two categories: private PKI (enterprise-internal) and experimental test certificates.
DigiCert
DigiCert is the most advanced CA in PQC certificate issuance. Through Trust Lifecycle Manager (TLM), DigiCert offers:
- ML-DSA certificates (FIPS 204): Available for private PKI use with ML-DSA-44, ML-DSA-65, and ML-DSA-87 key sizes. Certificates can be issued and managed through the same certificate profile workflow as classical certificates.
- SLH-DSA certificates (FIPS 205): Available for private PKI use across all SLH-DSA parameter sets.
- Composite certificates: Combining ML-DSA with RSA or ECDSA for hybrid authentication. DigiCert explicitly notes that Falcon and Composite PQC certificates remain experimental and are only available through DigiCert LABS.
Enrollment methods include admin web requests, CSR-based enrollment, EST (Enrollment over Secure Transport), and REST API. This is production-grade infrastructure, but it is limited to private trust hierarchies. DigiCert cannot issue publicly-trusted PQ certificates because browser root programs do not yet include PQ root certificates.
DigiCert LABS also provides free quantum-safe test certificates for organizations that want to simulate real-world PQC deployment scenarios without committing to a paid private PKI.
Entrust
Entrust has taken a more cautious public stance. Their nShield HSMs support NIST-approved PQC algorithms (ML-KEM, ML-DSA, SLH-DSA), enabling key generation and signing operations within hardware security modules. However, Entrust has not publicly launched a production PQ certificate issuance service equivalent to DigiCert TLM.
Entrust’s 2026 Global Cryptographic Report highlights that organizations report little progress on cryptographic visibility and PQC implementation, even as certificate lifetimes are being reduced to 47 days. Their current focus appears to be on crypto-agility infrastructure rather than immediate PQ certificate deployment.
Let’s Encrypt
Let’s Encrypt has not announced any timeline for PQ certificate issuance. Given their mission of universal HTTPS adoption through automation, they are likely waiting for the browser root program changes and CA/Browser Forum ballot requirements that would make PQ certificates meaningful for publicly-trusted use.
Other CAs
Sectigo, GlobalSign, and other major CAs have published PQC readiness whitepapers but have not announced production PQ certificate issuance services. Most are in a “wait for standards” posture, which is understandable given the dependency on the IETF and CA/Browser Forum processes described below.
IETF LAMPS Working Group: standards progress
The IETF LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is responsible for specifying how post-quantum algorithms are used in X.509 certificates and CMS (Cryptographic Message Syntax). Their charter explicitly includes PQC algorithm integration with PKIX certificates.
Published RFCs
- RFC 9881 (published early 2026): Specifies algorithm identifiers for ML-DSA in X.509 certificates. This is the foundational standard that tells CAs exactly how to encode ML-DSA-44, ML-DSA-65, and ML-DSA-87 public keys and signatures in certificate structures.
- RFC 9909 (published mid-2025): Specifies algorithm identifiers for SLH-DSA in X.509 certificates, covering all 12 SLH-DSA parameter sets.
Active drafts nearing completion
- draft-ietf-lamps-pq-composite-sigs (revision 19 as of early 2026): Defines Composite ML-DSA, which pairs ML-DSA with RSA, ECDSA, or EdDSA in a single certificate. This is the critical document for transition-period WebPKI because it allows a single certificate to be valid under both classical and post-quantum verification. The draft has reached late-stage review, with working group consensus on no further changes.
- draft-ietf-lamps-pq-composite-kem (revision 11): Defines composite ML-KEM for X.509 use, combining ML-KEM with classical key agreement in certificate structures.
- draft-ietf-lamps-cms-composite-sigs (revision 5): Extends composite signatures to CMS contexts, relevant for S/MIME and code signing.
Emerging work
- Root CA certificate rekeying (draft-wang-lamps-root-ca-cert-rekeying, revision 4): Addresses how root CAs transition their long-lived root certificates to PQC keys without breaking existing trust chains. This is a critical operational challenge because root certificates have lifetimes measured in decades.
- PQ Hybrid Commitment extension (draft-vicente-lamps-pqchc): A proposed X.509 extension that lets a certificate issued with a classical key carry a cryptographically bound commitment to a future post-quantum key. This would allow servers to signal their PQC readiness before the full transition.
Timeline for PQ certificates in the public WebPKI
The path from standards to production WebPKI certificates requires several sequential steps:
Step 1: IETF standards finalization (2026 to 2027)
RFC 9881 and RFC 9909 provide the pure PQ algorithm identifiers. The composite signatures draft needs to reach RFC status, which is likely in late 2026 or early 2027 given its current maturity.
Step 2: CA/Browser Forum ballot (2027 to 2028)
The CA/Browser Forum must pass a ballot allowing PQ or composite algorithms in publicly-trusted certificates. This requires agreement from browser vendors (Apple, Google, Microsoft, Mozilla) and CAs. Historically, ballot processes take 6 to 18 months from proposal to final adoption.
Step 3: Root program inclusion (2028 to 2029)
Browser root programs (Apple Root Certificate Program, Microsoft Trusted Root Program, Mozilla CA Certificate Program, Chrome Root Store) must accept root certificates signed with PQ algorithms. CAs need to generate new PQ root certificates and submit them for inclusion. Root program reviews typically take 12 to 24 months.
Step 4: Intermediate and end-entity issuance (2029 and beyond)
Once root certificates are in trust stores, CAs can issue intermediate certificates and then end-entity certificates using PQ algorithms. The full chain needs to verify under PQ algorithms for the transition to be meaningful.
Realistic estimate
Based on current progress, the most optimistic timeline for the first publicly-trusted post-quantum certificate is 2028. A more realistic estimate for broad availability is 2029 to 2030. Composite certificates (hybrid classical + PQ) are likely to appear first, as they provide backward compatibility with clients that do not yet support PQ verification.
What you can do now
Organizations do not need to wait for WebPKI PQ certificates to begin their migration:
-
Deploy PQ key exchange today: ML-KEM-based hybrid key exchange (X25519MLKEM768) is already available in Chrome, Firefox, and Cloudflare. This protects session data against harvest-now-decrypt-later attacks without any certificate changes.
-
Pilot private PKI PQ certificates: Use DigiCert TLM or OpenSSL with oqs-provider to issue PQ certificates within your internal infrastructure. This builds operational experience.
-
Inventory your certificate dependencies: Know which systems depend on specific certificate algorithms and which clients would need updates for PQ certificate validation.
-
Track the LAMPS WG: Subscribe to the IETF LAMPS mailing list to monitor composite signature RFC progress, which gates the CA/Browser Forum process.
-
Build crypto-agile infrastructure: Design systems that can swap signature algorithms without architectural changes, so when PQ WebPKI certificates become available, adoption is a configuration change rather than a rebuild.
Comparison: PQ key exchange versus PQ certificates
It is worth understanding why PQ key exchange has moved so much faster than PQ certificates:
| Aspect | PQ Key Exchange | PQ Certificates |
|---|---|---|
| Negotiation | Bilateral (client + server) | Multilateral (CA + server + client + root programs) |
| Backward compatibility | Hybrid mode is transparent | Composite certs need client support |
| Rollback | Server can disable at any time | Root inclusion is permanent |
| Standards needed | TLS RFC (done) | X.509 RFC + CA/B ballot + root program |
| Production today | Yes (Chrome, Firefox, Cloudflare) | No (private PKI only) |
FAQ
Q: Can I get a publicly-trusted PQ certificate today?
No. As of August 2026, no publicly-trusted root program includes PQ root certificates. You can obtain PQ certificates for private PKI use from DigiCert TLM or generate them yourself using OpenSSL 3.5 with the OQS provider.
Q: What is a composite certificate?
A composite certificate contains two key pairs and two signatures: one classical (RSA or ECDSA) and one post-quantum (ML-DSA). A verifier that supports PQ checks both; a verifier that does not can fall back to the classical signature. This is the expected transition mechanism for WebPKI.
Q: Will my existing TLS certificates stop working when PQ certs arrive?
No. PQ certificates will coexist with classical certificates during the transition. Servers will likely serve composite certificates that validate under both classical and PQ algorithms.
Q: Which PQ signature algorithm will WebPKI use?
ML-DSA (FIPS 204) is the primary candidate, likely in composite form with ECDSA for the initial transition period. SLH-DSA is unlikely for WebPKI end-entity certificates due to its large signature sizes (7,856 to 49,856 bytes), which would significantly increase TLS handshake sizes.
Q: Does PQ key exchange protect me even without PQ certificates?
Yes. PQ key exchange (ML-KEM hybrid) protects the confidentiality of your session data against future quantum attacks. Certificate authentication protects against active impersonation attacks. The quantum threat to authentication is less immediate because the attacker must have a quantum computer at the time of the connection, not years later.
Q: How does the 47-day certificate lifetime trend affect PQC migration?
Shorter certificate lifetimes actually help PQC migration because they reduce the window of exposure and make certificate infrastructure more agile. Organizations accustomed to frequent certificate rotation will find it easier to switch algorithms when PQ certificates become available.
Q: What is the IETF LAMPS WG?
LAMPS stands for Limited Additional Mechanisms for PKIX and SMIME. It is the IETF working group responsible for maintaining and extending the X.509 and CMS standards, including the addition of post-quantum algorithm support.