If you renewed a public TLS certificate this summer, you already met the change: the longest certificate you could buy was good for 199 days, not the year you were used to. That cap took effect on 15 March 2026, and it is the first of three steps. On 15 March 2027 the ceiling drops to 100 days. On 15 March 2029 it lands at 47 days, and the domain validation you perform alongside it becomes reusable for only 10.
The arithmetic is what matters. A certificate you renewed once a year now needs renewing roughly twice; in seven months that becomes four times; by 2029 it is eight times, each renewal preceded by a fresh domain-control check. Multiply by the number of certificates in your estate and the manual approach stops being inefficient and starts being impossible.
This page is the consolidated reference: every reduction step with its exact date, what shrinks alongside validity, why browsers forced this, which systems are exempt, and what breaks first in a mid-market estate. We maintain it as a living document and update it whenever the CA/Browser Forum changes the schedule.
Why this is happening
The short version: certificate revocation does not work, so expiry has been promoted to do the job instead.
When a private key leaks or a certificate is misissued, the theory says relying parties check a revocation list or query an OCSP responder and refuse the bad certificate. In practice, revocation lists grew unwieldy, OCSP queries leaked browsing history to certificate authorities and added a failure point on every connection. Browsers responded by making the check soft-fail: if the responder times out, connect anyway. That means revocation checking fails precisely when an attacker is blocking it — exactly the moment it was supposed to work.
Three further arguments carried the ballot. Research presented to the CA/Browser Forum in October 2024 measured stale certificates — valid certificates for domains the holder no longer controls, left behind after a cloud provider change or a terminated vendor contract — at around 7% of the active web PKI, and showed that a 47-day ceiling removes roughly 95% of the window in which such a certificate can be abused for domain takeover. Shorter lifetimes also compress the key-compromise exposure window: an undetected leak under the old 398-day regime gave an attacker over a year of usable interception, which 47 days cuts by more than 88%. And the multi-year effort it took to purge SHA-1 signatures from the ecosystem taught root programs that long-lived certificates make cryptographic migration glacial — a problem worth solving before post-quantum algorithms need to be rolled out across the web.
The full timeline
Last verified: August 2026.
| Phase | Effective date | Max validity (nominal) | Max validity (effective) | Max SAN validation reuse | Status |
|---|---|---|---|---|---|
| Five-year era | before 1 Apr 2015 | 60 months | 60 months | 39 months | Historical |
| Three-year era | 1 Apr 2015 | 39 months | 39 months | 39 months | Historical |
| 825-day era | 1 Mar 2018 | 825 days | 825 days | 825 days | Historical |
| 398-day era | 1 Sep 2020 | 398 days | 397 days | 398 days | Historical |
| Phase 1 | 15 Mar 2026 | 200 days | 199 days | 200 days (198 effective) | In effect now |
| Phase 2 | 15 Mar 2027 | 100 days | 99 days | 100 days (98 effective) | Next |
| Phase 3 | 15 Mar 2029 | 47 days | 46 days | 10 days (8 effective) | Final floor |
Source: CA/Browser Forum Ballot SC-081v3, adopted 11 April 2025, and the current Baseline Requirements. Note that reuse of non-SAN subscriber information stays at 398 days throughout all three phases — only domain validation for the names on the certificate compresses.
Two practical footnotes on that table. The gap between nominal and effective validity is not a rounding error: a certificate that exceeds the ceiling by one second is a misissuance, which obliges the authority to revoke within 24 hours, so authorities build in a safety margin — partly to absorb the delay between logging a pre-certificate to Certificate Transparency and issuing the leaf. Plan against the effective column. Second, authorities move ahead of the deadline rather than on it: DigiCert cut its maximum term to 199 days on 24 February 2026, three weeks before the rule required it. Expect the same pattern before March 2027.
What this does to your workload
| Public certificates | 398-day era | Now (200 days) | From Mar 2027 (100 days) | From Mar 2029 (47 days) |
|---|---|---|---|---|
| 10 | ~10 renewals/year | ~20/year | ~40/year | ~80/year |
| 50 | ~50 renewals/year | ~100/year | ~200/year | ~400/year |
| 100 | ~100 renewals/year | ~200/year | ~400/year | ~800/year |
Put a time cost against those numbers and the picture sharpens. A manual renewal — generate the request, complete validation, download the chain, upload to the appliance or server, reload the service, verify — takes a competent administrator around two hours once you count the maintenance window and the verification. At 100 certificates that was 200 hours a year under the old regime, which a small team could absorb. It is 400 hours today. It becomes 1,600 hours by 2029, which is most of a full-time job spent entirely on certificate paperwork.
The more disruptive change is the one hiding in the last column of the timeline table. Today you validate control of a domain and can reuse that proof for the next 200 days across multiple issuances. From March 2029 that proof expires after 10 days — eight in practice. A 47-day certificate therefore cannot be renewed on the back of an earlier validation: every renewal triggers a fresh domain-control check, roughly 35 of them per certificate per year. Any workflow where a human approves a DNS record or drops a file on a web server is finished. Not strained — finished.
What breaks first
Modern web servers and cloud-native workloads are the easy part. Nginx, Apache and Caddy run ACME clients natively; Kubernetes ingress has cert-manager; cloud load balancers renew their own certificates. If that were the whole estate, this article would be a footnote.
The problems live at the edges:
| Where the certificate lives | Can it self-renew? | Practical approach |
|---|---|---|
| Web servers (Nginx, Apache, Caddy) | Yes, natively | Native ACME client with DNS-01 or HTTP-01 challenges |
| Cloud ingress and load balancers | Yes, natively | cert-manager or the platform’s own certificate service |
| Firewalls, VPN gateways, hardware load balancers | Rarely | Issue centrally, push via vendor API or SSH; or move public TLS termination off the appliance |
| Legacy on-premises application servers | No | DNS-01 issuance on a management host, scripted deployment plus a service reload |
Perimeter appliances are the recurring headache, because their firmware is closed and their certificate is installed by hand through a web interface. That was tolerable annually. Doing it every 30 days on every firewall and VPN gateway you own is not a maintenance plan, it is a standing risk of the kind of expiry outage described below — which is a good reason to stop terminating public TLS on hardware that also carries its own end-of-support countdown.
Three other cases catch teams out. Internal portals issued with public certificates so nobody had to distribute a private root now inherit the public rotation schedule. Wildcard deployments concentrate risk: one renewal path, and every subdomain fails together when it breaks. And pinned mobile clients turn a routine key change into a global application outage, which is why the interaction between rotation and certificate pinning deserves checking before you automate anything.
What is not affected
Plenty of teams are preparing to solve problems they do not have. The CA/Browser Forum governs publicly trusted TLS server certificates. Outside that boundary, nothing in this schedule applies:
- Internal private CAs. Certificates from Active Directory Certificate Services, HashiCorp Vault, step-ca or any other private authority that does not chain to a browser-trusted root keep whatever lifetime your policy sets.
- mTLS client certificates. Device and service identity certificates are not server certificates. The rotation discipline of mutual TLS is yours to set.
- Code signing and S/MIME. Governed by separate baseline requirements with their own, longer lifetimes.
- SSH keys and other non-TLS credentials. Entirely outside the forum’s remit.
What is in scope: every publicly trusted TLS server certificate, including single-domain, multi-domain and wildcard certificates, and — since Ballot SC102 passed in July 2026 — extended validation certificates, whose validity and data reuse now align with the same baseline schedule.
Automation, without buying anything yet
The protocol layer here is open and well specified. ACME (RFC 8555) automates domain validation, signing requests and retrieval. Its Renewal Information extension (RFC 9773) lets an authority tell your client when to renew, which is how a CA can orchestrate an emergency mass-reissuance without every subscriber noticing. A subdomain validation extension (RFC 9444) lets separate teams validate independently. And since 15 September 2025, authorities must confirm domain validation from multiple network vantage points before issuing, which closes the BGP-hijack path to a fraudulently obtained certificate.
Free automated issuance is not a niche: Let’s Encrypt and Google Trust Services together account for the majority of active public web certificates, which settles the question of whether short lifetimes force you into a commercial contract.
Three things are worth doing in the next quarter, none of which require a purchase. Inventory what you actually have: scan your public address space and internal ranges, and record every public certificate with its expiry, issuer, host and owner. Teams routinely find certificates nobody remembers deploying. Separate public web PKI endpoints from internal services, so you stop applying public rules to private infrastructure. And standardise on DNS-01 challenges, because that method proves domain control through your DNS provider’s API rather than requiring inbound HTTP access to each host — which is the only way appliances and internal servers get automated at all. Building the discipline around those steps is its own subject, and a dedicated guide follows later this week.
The objections, answered
“This is a revenue grab by the certificate authorities.” The voting record says otherwise. When lifetimes were first cut, commercial authorities voted overwhelmingly against — frequent reissuance raises their infrastructure, storage and transparency-logging costs without raising per-certificate revenue. The reductions were driven by browser root programs, which hold the actual leverage: their trust stores decide which authorities exist commercially. And with free automated issuance covering most of the public web, the “forced subscription” theory does not survive contact with the market share data.
“Our appliances cannot run ACME, so automation is impossible.” Half true, and the half that is true does not lead where the objection assumes. The appliance does not need to run the client. Issue centrally on a management host using DNS-01, then deploy to the device through its REST API or an SSH script with a configuration reload — or stop terminating public TLS on the appliance altogether and move that job to a platform built to rotate certificates automatically. What is genuinely unworkable is keeping a human in the loop for every renewal.
“Renewing eight times a year will cause more outages than it prevents.” This is the strongest objection and it deserves the strongest answer, which is that the evidence runs the other way. The worst certificate outages on record came from annual, manual processes. An expired internal certificate in Ericsson’s core network software took mobile service away from 32 million O2 subscribers for close to a day in December 2018, with the operator later pursuing a nine-figure damages claim. An expired authentication certificate locked around 20 million users out of Microsoft Teams for three hours in February 2020. Both were single certificates that nobody was watching, because nobody had looked at them in a year. A pipeline that runs every 30 days is exercised constantly: when it breaks, you find out with weeks of validity left, not with a dead service and a scramble to find who has the private key.
Start with the inventory, not the tooling
You are already living under the 200-day cap. March 2027 halves it again, and that is close enough to plan for now: know every public certificate you own, get the automatable ones onto ACME with DNS-01, and make a deliberate decision about each one that cannot self-renew, because those are the outages waiting to happen.
Where those stubborn cases are perimeter appliances, the durable answer is architectural rather than procedural. Jimber delivers secure web gateway, ZTNA network isolation, firewall-as-a-service and SD-WAN from a single EU-sovereign platform, which takes public TLS termination off hardware you would otherwise be updating by hand every few weeks — and takes the hardware refresh cycle with it. Book a demo to see how that changes your certificate footprint, or start with how the platform fits together.
Frequently asked questions
When do 47-day TLS certificates become mandatory?
The 47-day maximum applies to publicly trusted TLS certificates issued from 15 March 2029. Two earlier steps come first: the 200-day cap has applied since 15 March 2026, and 100 days follows on 15 March 2027. Authorities apply the limits based on issuance date, so certificates issued before a deadline keep their original term.
Does the 47-day rule affect internal private CAs?
No. The CA/Browser Forum schedule applies only to publicly trusted TLS server certificates that chain to a root in a browser trust store. Certificates from an internal Active Directory CA, HashiCorp Vault or step-ca keep whatever lifetime your own policy defines, as do mTLS client certificates and SSH keys.
Why is the CA/Browser Forum reducing certificate lifespans?
Because revocation is unreliable. Revocation lists are unwieldy and OCSP checks soft-fail when blocked, so a compromised certificate can stay usable. Shorter validity makes expiry the enforcement mechanism, shrinks the window for stale-certificate domain takeover, and gives the ecosystem the agility to migrate cryptographic algorithms.
What is the difference between nominal and effective validity?
A certificate exceeding the maximum by even one second counts as a misissuance requiring revocation within 24 hours, so authorities issue below the ceiling as a safety margin. In practice the 200-day cap yields a 199-day maximum term, and the 47-day cap will yield 46 days. Plan renewal schedules against the effective figure.
How does the validation reuse period change?
Domain validation reuse for names on the certificate drops alongside validity: 200 days now, 100 days from March 2027, and 10 days from March 2029. At that point every renewal needs a fresh domain-control check — roughly 35 per certificate per year — which rules out any workflow requiring manual approval.
Can firewalls and appliances be automated for certificate renewal?
Usually not with an on-device client, because appliance firmware rarely supports ACME. The workable pattern is to issue centrally on a management host using DNS-01 challenges and push the result to the device via its REST API or an SSH script with a configuration reload, or to move public TLS termination off the appliance entirely.
Does Let’s Encrypt already meet the 47-day requirement?
Not yet in the sense of issuing 47-day certificates by default: its standard certificates run to 90 days with renewal recommended at 60. Because issuance is fully automated, conforming to the shorter maximum before March 2029 is a configuration change for the authority, not a workflow change for subscribers already using ACME.
How many renewals per year will 47-day certificates require?
About eight per certificate, assuming renewal at roughly two-thirds of the term to leave a safety margin. An estate of 50 public certificates moves from about 50 renewals a year under the old regime to roughly 400, each preceded by its own domain validation check.
