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 September 30, 2026, no certificate authority is generally issuing post-quantum certificates that are trusted by default in a major browser’s ordinary public root program. Current capability remains split between private PKI, experiments, and announced future public issuance.

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.

Cloudflare

Cloudflare announced on September 29, 2026 that it is establishing a public certificate authority. It has applied to major browser root programs and plans to support Merkle Tree Certificates (MTCs), with standard MTC issuance planned at no cost.

This is a roadmap, not current public issuance. Cloudflare says it is targeting early 2027 for inclusion in Chrome’s separate Quantum-resistant Root Store and for its first MTC issuance. Root-program evaluation still has to complete, the Chrome program policy is draft, and the MTC protocol remains under IETF development.

Cloudflare and Chrome did complete a large experiment: Cloudflare reports serving billions of MTCs to part of the Chrome Beta 146 population. Landmark-relative MTCs were 9% faster at the median than classical certificate chains in that experiment, largely because the intermediate certificate was omitted. The experiment used classical signatures, so the result is feasibility evidence rather than a production post-quantum performance guarantee.

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.

Merkle Tree Certificates: a separate WebPKI path

The IETF PLANTS working group is developing Merkle Tree Certificates as an alternative way to scale post-quantum Web authentication. MTCs integrate issuance and transparency: a CA adds certificate assertions to an append-only Merkle tree, obtains cosignatures over tree state, and gives the server an inclusion proof.

Landmark-relative MTCs can move the large signatures and tree metadata out of individual TLS handshakes. Cloudflare estimates that a naïve switch to post-quantum signatures in today’s Certificate Transparency architecture could increase CT log storage by about 40 times. That is a vendor estimate explaining the scaling problem, not a measured universal cost.

MTCs are not an established WebPKI standard today. The current specification is an Internet-Draft, Chrome’s Quantum-resistant Root Program policy is draft, and publicly trusted issuance is not generally available. The Cloudflare deployment guide explains how this future authentication path differs from today’s deployed hybrid ML-KEM key exchange.

Timeline for PQ certificates in the public WebPKI

There are now at least two active architectural paths: conventional or composite X.509 signatures, and Chrome’s MTC/root-program path. They do not share one guaranteed schedule.

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: ecosystem policy and interoperability

Conventional public-PKI changes require browser and CA policy alignment. The MTC path additionally requires interoperable issuance logs, independent cosigners, monitors, client update distribution and fallback behavior. Chrome has created a separate draft Quantum-resistant Root Program rather than declaring MTCs part of the ordinary WebPKI today.

Step 3: root-program inclusion

Each relying ecosystem must decide what it trusts. Cloudflare targets early 2027 for inclusion in Chrome’s Quantum-resistant Root Store, but calls this a target and says its CA must undergo evaluation. That does not establish acceptance by Chrome, other browsers, operating systems or ordinary root programs.

Step 4: production issuance and client deployment

After policy and trust decisions, CAs, servers, browsers, mirrors and monitors still need operational deployment. Classical fallback may remain necessary for clients without the relevant trust anchor or landmark data.

Realistic estimate

Cloudflare’s early-2027 MTC target is the first concrete public-CA milestone in this corpus, but it is not a broad-availability forecast. No defensible date exists yet for cross-browser, cross-platform post-quantum WebPKI availability. Track capability by root program, certificate architecture and client population instead of assigning one date to “the Web.”

What you can do now

Organizations do not need to wait for WebPKI PQ certificates to begin their migration:

1. 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.

2. 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.

3. Inventory your certificate dependencies: Know which systems depend on specific certificate algorithms and which clients would need updates for PQ certificate validation.

4. Track both standards paths: Monitor LAMPS work on X.509 signatures and PLANTS work on Merkle Tree Certificates, plus the policies of the root programs your clients use.

5. 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 negotiated	Composite certificates and MTCs both need compatible clients and policy
Rollback	Server can disable at any time	Root inclusion is permanent
Standards needed	TLS RFCs finalized	ML-DSA X.509 identifiers exist; composite and MTC work is still evolving
Production today	Yes (Chrome, Firefox, Cloudflare)	Private PKI and experiments; no generally available publicly trusted PQ issuance

FAQ

Q: Can I get a publicly-trusted PQ certificate today?

No generally available service offers a publicly trusted PQ certificate for ordinary browser use as of September 30, 2026. Cloudflare is building a CA and targets early 2027 for MTC issuance and Chrome root-program inclusion, but it is not issuing those certificates today. Private-PKI and experimental options are separate.

Q: What is a composite certificate?

A composite certificate binds classical and post-quantum signature components in one defined construction. Verification and backward-compatibility behavior depend on the specific draft and implementation. Composite certificates remain relevant to controlled PKI deployments, but Chrome’s MTC program means they should not be presented as the single settled WebPKI transition mechanism.

Q: Will my existing TLS certificates stop working when PQ certs arrive?

No immediate cutoff has been announced. Transition designs include classical fallback and parallel trust paths, but exact behavior will depend on the browser/root program and certificate architecture.

Q: Which PQ signature algorithm will WebPKI use?

ML-DSA is standardized for digital signatures and has X.509 algorithm identifiers, but public WebPKI architecture is not settled into one universal certificate format. MTCs can amortize signatures across batches and alter what is sent during the handshake, so avoid predicting one mandatory end-entity construction.

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.

Sources

• DigiCert Trust Lifecycle Manager PQC documentation
• IETF LAMPS Working Group charter
• RFC 9881: ML-DSA Algorithm Identifiers for X.509
• RFC 9909: SLH-DSA Algorithm Identifiers for X.509
• draft-ietf-lamps-pq-composite-sigs-19
• NIST FIPS 203 (ML-KEM)
• NIST FIPS 204 (ML-DSA)
• NIST FIPS 205 (SLH-DSA)
• Cloudflare: Building a public certificate authority — application status and announced issuance target
• Cloudflare: Building a post-quantum CA with MTCs — experiment, architecture, free-issuance plan and availability boundary
• IETF: Merkle Tree Certificates Internet-Draft — active standards work
• Chrome Quantum-resistant Root Program — separate program and draft-policy status