up:: In the Protocols MOC
PQC in the Web PKI (CA-Browser Forum)
The web PKI is the global system of certificate authorities, root programs, and browser trust stores that lets a browser trust the identity behind an HTTPS address, and it is governed for the public internet by the CA/Browser Forum’s Baseline Requirements. Migrating it to post-quantum cryptography means replacing the classical RSA and ECDSA signatures that sign every certificate with post-quantum signatures a quantum computer cannot forge, across an ecosystem of thousands of CAs and billions of certificates. Two adjacent developments make that migration tractable: the ongoing shortening of certificate lifetimes toward 47 days, which is the crypto-agility groundwork for swapping algorithms cleanly, and Merkle Tree Certificates, which address the bandwidth that much larger post-quantum signatures would otherwise impose.
Source: CA/Browser Forum, “Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods,” April 2025, cabforum.org.
The short version:
- The web PKI is the certificate-authority and browser-trust ecosystem that authenticates HTTPS, governed for the public internet by the CA/Browser Forum Baseline Requirements. Its certificates are signed with classical RSA and ECDSA, which a quantum computer forges.
- Certificate authentication is a signature problem, so it is Non-HNDL: nothing is harvested for later decryption, and the pressure is forgery once a quantum computer is live, which puts it on a slower clock than harvestable key exchange.
- The move to shorter certificate lifetimes is agility infrastructure. Ballot SC-081v3 steps the maximum lifetime down from 398 days to 200 (March 2026), 100 (March 2027), and 47 days (March 2029), forcing the automated renewal that makes an algorithm swap survivable.
- An estate that renews certificates automatically every few weeks can adopt a new post-quantum signature algorithm as a routine reissue, while one that renews manually once a year cannot roll the whole ecosystem in any reasonable window.
- Post-quantum certificate signatures are much larger than classical ones, so the size lands on every handshake. Merkle Tree Certificates are the IETF proposal to make that bandwidth practical at internet scale.
Think of the web PKI as a nation’s ID-card system where every card is stamped with a signature that proves it is genuine. Switching the whole country to a new, forgery-proof stamp is only feasible if cards expire and get reissued often, because then the new stamp rolls out on the normal reissue cycle instead of requiring a one-time recall of every card at once. Shortening the card’s validity period is the boring prerequisite that makes the stamp change routine. The web PKI is doing exactly that: cutting certificate lifetimes first, so the algorithm change can ride the renewal machinery already in motion.
What is the web PKI, and who governs its move to PQC?
The web PKI is the trust system that answers “is this really the site it claims to be?” for HTTPS. A certificate authority issues an X.509 certificate that binds a domain name to a public key and signs it, browsers ship a set of trusted root CAs, and a chain of signatures links the site’s certificate back to one of those roots. The rules that CAs must follow to stay in the browser root programs are the CA/Browser Forum’s Baseline Requirements, so for the public internet the Forum is the body whose ballots decide how and when the ecosystem changes.
That governance structure is why post-quantum migration of the web PKI is a coordination problem rather than a single vendor’s decision. A post-quantum certificate has to be issued by CAs, accepted by browser trust stores, validated by the TLS libraries in between, and logged in Certificate Transparency the way classical certificates are, and all of those parties move on the Baseline Requirements and the root programs. The Forum does not write the cryptographic standards, which come from NIST as ML-DSA and SLH-DSA, but it sets the profile and timeline for how the public web adopts them.
Source: CA/Browser Forum, Baseline Requirements, cabforum.org.
Why is certificate authentication on a slower clock than key exchange?
Because certificate signatures are a Non-HNDL exposure and TLS key exchange is a harvestable one, so the two halves of TLS migrate on different schedules. A recorded TLS session encrypted with classical key exchange can be decrypted years later once a capable quantum computer exists, which means the harvest-now-decrypt-later window on key exchange is already open and every day of delay adds exposed traffic. That urgency is why hybrid key exchange shipped first and is already the default in major browsers.
A forged certificate signature is different, because it only helps an attacker in real time, at the moment of authentication, so there is nothing to record and no deferred payoff. An attacker cannot usefully “harvest” the ability to forge a certificate; they need the quantum computer live and pointed at a connection happening right then. That makes certificate authentication genuinely less time-critical on the clock, even though it is harder to roll out because it touches the entire CA and trust-store ecosystem. The consequence for planning is that a TLS endpoint can and does run a post-quantum key exchange while still presenting a fully classical certificate, and that split is the normal state of a 2026 deployment.
How do shorter certificate lifetimes create crypto-agility?
Shorter lifetimes force automated renewal, and automated renewal is precisely the machinery that lets an algorithm change roll through the whole ecosystem without a manual recall. The CA/Browser Forum passed Ballot SC-081v3 in April 2025, stepping the maximum certificate validity period down on a fixed schedule. The dated schedule:
| Effective date | Maximum certificate lifetime | Domain-validation reuse |
|---|---|---|
| Until March 15, 2026 | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
Source: CA/Browser Forum, “Ballot SC-081v3,” April 2025, cabforum.org; DigiCert, “TLS Certificate Lifetimes Will Officially Reduce to 47 Days,” digicert.com.
A 47-day maximum lifetime, paired with a 10-day domain-validation reuse window, makes manual certificate management impractical and effectively mandates automation such as ACME. That automation is the agility payoff. An estate that reissues every certificate automatically every few weeks can adopt a new post-quantum signature algorithm as an ordinary reissue, so the whole population turns over to the new algorithm within one or two renewal cycles. An estate that renews by hand once a year has no realistic path to swap the algorithm across every certificate in a bounded window. Short lifetimes are best read as the prerequisite for a post-quantum change even though the ballot is framed around agility and revocation generally, because the same automated-reissue capability is what a post-quantum swap depends on.
Why do post-quantum certificates strain bandwidth, and what fixes it?
Because post-quantum signatures are much larger than classical ones, and a TLS handshake carries several of them in the certificate chain, so the size lands on every new connection. A classical ECDSA signature is tens of bytes, while a ML-DSA signature is a few kilobytes, and a full chain includes the leaf certificate’s signature plus the intermediate and sometimes an SCT, so a post-quantum chain can add several kilobytes to the start of every handshake. At the volume of connections the web handles, that added handshake weight is a real latency and bandwidth cost, and it can interact with the same protocol-ossification limits that make oversized TLS handshakes fragile in the first place.
Merkle Tree Certificates are the IETF proposal aimed squarely at this. Instead of each certificate carrying a full per-connection post-quantum signature chain, MTC replaces the chain with a compact Merkle-tree inclusion proof checked against a periodically published tree head that is distributed out of band, which cuts the bytes on the wire dramatically for the common case. It is an optimization for the web-scale bandwidth problem, meant to coexist with classical certificates rather than replace X.509 wholesale, and its own note carries the mechanics. The broader point is that making the web PKI post-quantum is as much a bandwidth-engineering problem as a cryptographic one, which is why shorter lifetimes and MTC are being built alongside the algorithm change rather than after it.
Source: CA/Browser Forum and IETF work referenced in Merkle Tree Certificates (MTC).
What should an operator do about the web PKI transition now?
Treat certificate agility as the deliverable, because the post-quantum signature swap is not something an individual operator triggers, it is something the ecosystem rolls out and an agile estate absorbs. The concrete moves:
- Automate certificate issuance and renewal now. The lifetime schedule is already stepping down, so ACME-style automation across every certificate is required regardless of quantum, and it is the exact capability a post-quantum algorithm swap will need. Doing it now pays off twice.
- Inventory your certificates and their signature algorithms. Knowing which certificates exist, which CAs issue them, and which are pinned or hard-wired to a specific algorithm is what a CBOM captures, and it is the map for the eventual change.
- Find the agility-blockers. Systems that hard-code a certificate, pin a specific public key, or cannot accept a new signature algorithm are the ones that break a post-quantum swap, and surfacing them early is the difference between a smooth reissue and a scramble.
- Track the CA/Browser Forum and root-program timelines. The profile and dates for post-quantum certificates come from the Forum and the browser root programs, so those are the sources to watch rather than a single vendor’s roadmap.
Source: CA/Browser Forum, Baseline Requirements, cabforum.org.
Common misconceptions
- “Post-quantum certificates are the urgent part of TLS migration.” The reverse. Certificate signatures are Non-HNDL, needing a live quantum computer to forge, so they are on a slower clock than harvestable key exchange, which is why hybrid key exchange shipped first.
- “Shorter certificate lifetimes are just about revocation.” They also build the automated-reissue capability an algorithm swap depends on, so short lifetimes double as the agility groundwork for going post-quantum.
- “An individual site can just switch its certificate to a post-quantum algorithm.” The change has to be issued by CAs, accepted by every browser trust store, and validated by the libraries in between, so it moves through the CA/Browser Forum and the root programs, not through one operator’s choice.
- “Post-quantum web PKI is purely a cryptography problem.” It is also a bandwidth problem, because larger signatures land on every handshake, which is why Merkle Tree Certificates and shorter lifetimes are being engineered alongside the algorithm change.
Questions people ask
Who decides how the web moves to post-quantum certificates? The CA/Browser Forum, through its Baseline Requirements, together with the browser root programs. The Forum sets the profile and timeline the public web PKI follows, while the cryptographic standards themselves come from NIST as ML-DSA and SLH-DSA.
Why are certificate lifetimes dropping to 47 days? Ballot SC-081v3 steps the maximum lifetime from 398 days down to 200 in March 2026, 100 in March 2027, and 47 by March 2029, alongside a 10-day domain-validation reuse window. It forces automated renewal, which is the agility infrastructure a post-quantum algorithm swap needs.
Is switching to post-quantum certificates urgent? Less urgent than key exchange. Certificate authentication is Non-HNDL, so a forged signature needs a live quantum computer and there is nothing to harvest, which puts it on a slower clock than harvestable TLS key exchange.
Why do post-quantum certificates cause a bandwidth problem? Post-quantum signatures are kilobytes where classical ones are tens of bytes, and a TLS handshake carries several of them in the chain, so the added weight lands on every connection. Merkle Tree Certificates are the proposal to make that practical at internet scale.
What can I do about it today? Automate certificate issuance and renewal, inventory your certificates and their algorithms in a CBOM, find the systems that pin or hard-code a certificate, and track the CA/Browser Forum timelines. Certificate agility is the deliverable you control.
Everything here is the map, given freely. When your team needs its certificate estate inventoried, its agility-blockers found, and its issuance automated ahead of the post-quantum signature swap, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.