Revocation never worked, so short lived certificates are arriving instead.
The fix is operational rather than cryptographic, and most teams have not started.
The CA/Browser Forum adopted Ballot SC-081v3 on 11 April 2025, with Apple proposing it and Google, Microsoft and Mozilla voting yes.
Twenty five certificate issuers voted in favour, none voted against, and five abstained, which is an unusual margin for a change this disruptive.
The ballot sets a three step reduction in the maximum lifetime of publicly trusted TLS certificates: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029.
Reuse of validation data falls on the same schedule, from 398 days to 10 days for domain validation data used in a certificate, and from 825 days to 398 days for everything else.
The 200 day limit took effect in March 2026, so the first cut is already live and the remaining two are fixed dates rather than proposals.
Image: VulcanSphere, Apache License 2.0, via Wikimedia Commons.
Why the lifetimes keep being cut
The TLS Baseline Requirements have always assumed that a certificate can be replaced inside 24 hours, because a CA must revoke within that window in defined cases.
Ballot SC-081v3 states that certificate status services, meaning CRLs and OCSP, "do not adequately protect relying parties at the current scale of the internet".
Its listed problems are scalability, reliability and user impact, including the retries and timeouts that status checks add to ordinary page loads.
Shorter validity sidesteps all of it, because an expired certificate needs no responder, no cache and no browser willing to check it.
The ballot also notes that a certificate only describes a point in time, so the longer one lives the more likely it is to be wrong.
Stated benefits include fewer misissued certificates surviving, a smaller blast radius when validation was done badly, and easier movement between algorithms.
It also admits the underlying problems remain, describing the change as a mitigation rather than a cure.
Reducing lifetimes is cheaper than fixing revocation, and the ballot says so without much diplomacy.
Earlier cuts through Ballot 185 in 2017 and Ballot SC-22 in 2019 followed the same reasoning.
ACME made unattended issuance routine years ago, so the machinery exists in most stacks already.
A short lived certificate profile with a 10 day maximum already exists, which shows how far tolerance has moved.
What short lived certificates change
1. Automate issuance. Renew through an ACME client that runs unattended in your deployment pipeline, and target the first third of the lifetime so a failed attempt leaves room for another.
2. Inventory what the ballot does not cover. It governs only certificates that authenticate internet accessible servers, so internal CAs, service mesh identities, appliances, VPNs and code signing chains keep their own clocks.
Image: Stokito, CC BY-SA 4.0, via Wikimedia Commons.
3. Watch expiry as an availability signal. Keep days remaining and renewal failures in your monitoring stack, then rehearse a forced replacement while nothing is broken.
The estate you have not counted
Public websites are the visible part, because scanners and transparency logs keep them countable.
Any certificate you cannot enumerate is a certificate you cannot renew.
The hidden part is the internal certificate authority nobody documents, plus the appliances, hypervisors, backup systems and printers holding certificates of their own.
Where renewal fails quietly
A renewed certificate on disk is not a renewed service, and the reload step is where a surprising number of outages begin.
Pinned clients add another trap, because a mobile build or a hard coded trust anchor can outlive whatever renewal window you choose.
If replacing a certificate means an upgrade rather than a renewal, it will be missed.
Volume matters too, since moving from 200 days to 47 days means roughly four times as many issuance events for the same estate.
Spread those events rather than bunching them, or a tidy renewal schedule turns into a small traffic spike.
Validation is moving with it
Validation is shifting at the same speed, because the forum is sunsetting the email and phone based methods teams rely on for manual approval.
Reuse of validation data drops from 398 days to 10 days, so a process that depends on someone clicking approve becomes a weekly obstacle.
The forum is adding DNS based replacements, but the direction of travel is one way.
If your renewal path is an email to whoever owns DNS, that path now has an expiry date of its own.
What teams get wrong
Treating 2029 as the deadline is the first mistake, since the 200 day limit is what breaks hand rolled processes.
Assuming the ballot covers the whole estate is the second, and its scope is narrower than most inventories assume.
Reusing one private key across many renewals is the third, and shorter lifetimes make that habit far more expensive to audit.
Counting a calendar reminder as a control is the fourth, because the same reminder now fires several times more often.
Automation is not a synonym for safety either, since a renewer that fails quietly is worse than a person who notices.
The old assumption
The old assumption treated a certificate as an annual chore with a reminder attached.
The new reality is that replacement is a background service, and every manual step now runs several times more often with the same risk attached to each pass.
A certificate has become a credential with a short life, closer to a session token than a yearly fixture.
Nobody earns credit for a renewal that works, and everybody remembers the one that did not.
If every certificate in your estate had to be replaced inside 24 hours, which system would fail first?
Featured image: Chris, CC BY-SA 3.0, via Wikimedia Commons.