Expiry is the only revocation that works

On March 15 this year, the maximum lifetime of a publicly trusted TLS certificate dropped from 398 days to 200. If that passed you by, there’s a reason: estates with automated renewal absorbed it without a ticket, and estates without it mostly haven’t met their first 200-day expiry yet. The earliest ones land in October. October is going to be educational.

That was step one of a schedule the CA/Browser Forum adopted in April 2025 as ballot SC-081v3, by a vote of 25 certificate issuers in favor, none against, five abstaining. Here is the schedule as it now stands in the Baseline Requirements themselves (v2.2.9, sections 6.3.2 and 4.2.1):

Certificates issued	Maximum validity	Domain validation reuse
before 2026-03-15	398 days	398 days
on or after 2026-03-15	200 days	200 days
on or after 2027-03-15	100 days	100 days
on or after 2029-03-15	47 days	10 days

The last 398-day certificates, issued the day before the first cut, expire by April 16, 2027. From March 15, 2029, nothing newly issued outlives 47 days, and the final 100-day stragglers age out by that June.

One scope note before the interesting part. This binds certificates that chain to publicly trusted roots. Your private PKI can keep issuing five-year certificates to its heart’s content, and whether it should is a separate article.

The number is honest

The ballot text never explains why 47. The arithmetic falls out anyway, if you know one operational convention: automated clients renew at roughly two-thirds of a certificate’s lifetime. Two-thirds of 47 is about 31. So a 47-day certificate renews monthly, and a renewal that fails on day 31 leaves you 16 days to notice and fix it before anything goes dark.

The requirement text is written with the same practicality. Certificates issued from March 2029 “SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.” Target 46, and the extra day absorbs clock skew at issuance instead of becoming a compliance incident.

So 47 is not a security constant derived from some threat model. It’s a monthly renewal cycle with margin, dressed as a number of days. That reading matters, because it tells you what the policy is actually for.

What the schedule admits

The vendor coverage frames all this as a certificate-management workload problem, which is understandable, because the people writing it sell certificate management. The primary sources are more candid about the motive.

The ballot’s rationale says certificates are “representations of a point in time state of reality,” and that as time passes, “the more likely it becomes that data represented in the certificate diverge from reality.” The traditional answer to divergence was revocation: when a key is compromised or a domain changes hands, the CA marks the certificate bad, and clients check. The ballot’s verdict on that machinery is one clause long. Shorter lifetimes provide “firm protection to users, independent of certificate status services.”

Independent of. Not “complementing.” The protection that counts is the one that doesn’t depend on a status check happening.

The Baseline Requirements now encode the same judgment structurally. There is a defined class of Short-lived Subscriber Certificates, seven days or less for anything issued after March 2026, and for that class revocation is optional: “The CA MAY support revocation of Short-lived Subscriber Certificates.” The revocation obligations that fill section 4.9 open with “With the exception of Short-lived Subscriber Certificates.” Let’s Encrypt’s six-day certificates, first issued in February 2025, carry no OCSP or CRL URLs by design, and their announcement says the quiet part plainly: revocation “has historically been unreliable.”

Follow the gradient. At 398 days, revocation is mandatory and load-bearing. At 47, it’s a backstop. At 7, the Web PKI’s own rulebook says you can skip it, because the certificate will be dead before the revocation would have propagated anyway. A quarter century of revocation engineering, and the mechanism that finally reaches every client is a kitchen timer. The schedule is the industry writing that down as policy.

Renewal stops being a separate operation

The less-quoted half of the schedule is the third column. Today a CA may reuse a domain-control validation for 200 days, so several certificates can ride one validation. From March 2029 the reuse window is 10 days, against a 47-day lifetime. A cached validation can no longer span even a single renewal.

That deletes a distinction PKI people have relied on forever: renewal as the cheap operation, re-validation as the expensive one. From 2029 there is no renewal in any meaningful sense. There is only issuance, and every issuance re-proves domain control from scratch. If your process treats “renewal” as a lighter-weight path, that path stops existing. The CA’s memory of you lasts ten days. After that you’re a stranger with paperwork.

The arithmetic of operating it

Some numbers, all of them arithmetic you can redo on a napkin, none of them measurements.

Take an estate of 1,000 public TLS certificates, which is small for an enterprise. On annual renewal that’s 1,000 issuance events a year, about three a day. On a 47-day lifetime with two-thirds renewal it’s roughly 12 per certificate per year, call it 12,000 events, 33 a day, every day, including the ones between Christmas and New Year.

If a human touches each event for 20 minutes (open the ticket, run the request, install, verify, close), that’s 4,000 hours a year: two full-time salaries spent proving, monthly, that you still own your own domains. The same estate automated is a monitoring dashboard.

The sharper collision is with change control. The failure budget on a 47-day certificate is those 16 days between scheduled renewal and expiry. If a failed renewal at your organization means a change request with a two-week lead time, your process fits inside the budget with two days to spare. A three-week lead time doesn’t fit at all: the certificate expires while the fix is waiting for approval. A process that today merely makes renewals annoying will, in 2029, be arithmetically incapable of keeping a site up.

That’s the real deadline in the table. From March 2029, a manual certificate process is one missed renewal away from an outage that its own approval workflow is too slow to prevent. The change process stops being the safety net and starts being the root cause.

The dividend nobody is selling

There’s a second rationale in the ballot that got less coverage, and it’s the one that earns this article its place on this site. Deprecating a cryptographic algorithm, the ballot notes, is complex and slow, and weaknesses can arrive “with or without forewarning,” so the Web PKI must be structured so “a response can be made rapidly and effectively.” A reduced maximum validity, the rationale says, provides “substantial support” for swapping deployed cryptography in a hurry.

That transition has a name and a schedule. NIST’s transition guidance, IR 8547, proposes deprecating RSA and ECDSA at 112-bit security strength (RSA-2048 territory, which is most of the deployed web) after 2030, and disallowing them at every strength after 2035. (It is still an initial public draft as of this week; I checked, because a search summary confidently told me a final version shipped in 2025, and no such document exists.) Set the two timelines side by side: the 47-day floor arrives in March 2029, before the deprecation window opens. Whatever else the lifetime schedule does, it forces every publicly trusted estate to build monthly certificate rotation as reflex before the post-quantum migration needs exactly that muscle.

An estate that rotates every certificate monthly can swap signature algorithms across its whole footprint inside seven weeks, using nothing but the machinery it already runs. An estate that renews annually by hand faces the same swap as a multi-year program. I’ve measured what that swap does to the handshake and what the hybrid certificate shapes cost; the bytes are manageable. The operational readiness is the hard part, and the CA/Browser Forum just made practicing it mandatory.

What to do with the seven months

The 100-day step lands March 15, 2027. Three things are worth doing before it, none of which involve buying anything.

Count your issuance paths, not your certificates. The certificate inventory is the easy list. The list that predicts 2029 pain is how certificates get onto things: ACME to a web server is solved, but the load balancer that takes a PKCS#12 upload through a web console, the appliance with a vendor-specific renewal ritual, the SaaS that wants a CSR emailed to support, each of those is a path that has to become automatic or become monthly toil.

Find the certificates that can’t do this. Every estate has a few: a certificate someone pinned, a partner who breaks on rotation. The worst is the device whose firmware update cycle is longer than 47 days. They’ll limp through the 100-day phase. They will not survive 2029 unchanged, and the lead time to replace them is measured in budget cycles, which is why the list needs to exist now.

Measure your failure window. Break a renewal in staging and time how long your organization takes to land the fix in production, approvals included. If the answer is more than 16 days, you now know precisely which process has to change before March 2029, and you can show the approvals board the arithmetic instead of an opinion.

The schedule reads as aggressive until you notice what it’s built on. Expiry is the only revocation that works, and for the next three years the Web PKI is rebuilding itself around that fact, 200 days at a time.

Provenance

Read, not summarized. The validity and reuse schedules were taken from the Baseline Requirements text itself, v2.2.9 (dated 2026-08-06), downloaded from the cabforum/servercert repository and grepped, requirement by requirement. This wasn’t ceremony: an AI page summary of the same document returned the schedule shifted by one row, placing the 47-day floor in 2027 instead of 2029. The table above quotes the document, not a summary of it.

Reported. Ballot SC-081v3’s passage date, vote counts, and every quoted rationale sentence were verified verbatim against the ballot page. The Let’s Encrypt quotes were verified verbatim against their announcement. NIST IR 8547’s proposed dates are cited to the initial public draft, which remains the current version: a search summary asserted a 2025 final exists, and checking NIST’s publication pages shows it does not. Two fabricated “facts” from summarizers in one afternoon is a fair sample of why this section exists.

Computed. The renewal cadence, the estate workload figures, and the failure-window math are arithmetic on stated inputs (two-thirds renewal convention, 1,000 certificates, 20 minutes per manual event), stated inline so you can redo them with different inputs. I measured nothing for this article. The two-thirds renewal convention itself is an ecosystem norm, not a requirement; if your tooling renews at a different fraction, the cadence shifts and the failure window shifts with it.

Not claimed. The ballot text does not explain the number 47, and I haven’t repeated the folk derivation that circulates for it. The monthly-cycle reading above is my own arithmetic from the two-thirds convention, and it stands or falls on that convention alone.

If something here is wrong, email the studio and I will correct it in place with a note saying what changed.