What Changed
The CA/Browser Forum is the industry body of certificate authorities and browser vendors that sets the shared rules for publicly trusted certificates. In April 2025 it ratified Ballot SC-081v3, which established a phased schedule for shortening TLS certificate lifetimes.
What makes this significant is that it isn't a commercial decision by any single certificate authority — it's a requirement every publicly trusted CA must follow. In other words, the timeline applies regardless of who you currently buy certificates from, including free services such as Let's Encrypt.
| Effective date | Max lifetime | What it means |
|---|---|---|
| Before March 15, 2026 | 398 days | Old rule — roughly one renewal a year |
| March 15, 2026 | 200 days | Current rule — about twice a year |
| March 15, 2027 | 100 days | Roughly four renewals a year |
| March 15, 2029 | 47 days | Roughly eight renewals a year |
Worth noting: alongside certificate lifetimes, the reuse period for domain control validation (DCV) is shrinking too. That means it isn't only certificates that need reissuing more often — domain ownership itself must be revalidated more frequently, dropping to 10 days by 2029.
Why Shorten Certificate Lifetimes?
Shorter lifetimes clearly mean more work for operations teams, but there are several concrete security arguments behind the change:
- Shrinking the window for key compromise When a private key leaks or a certificate is misused, how long an attacker can exploit it depends directly on the certificate's remaining lifetime. Going from 398 days to 47 compresses the worst-case exposure window to roughly one-eighth of what it was.
- Reducing reliance on revocation In theory a compromised certificate can be revoked via CRL or OCSP, but in practice these mechanisms are not fully reliable — some browsers soft-fail when the check doesn't complete, and network conditions can cause timeouts. Short-lived certificates simply expire, with no dependency on revocation working correctly.
- Forcing automation and crypto-agility Frequent renewal pushes the whole industry toward automated workflows. This isn't only about the current rules — it's preparation for the eventual migration to post-quantum cryptography, when the industry will need to be able to rotate certificates and algorithms quickly.
What This Actually Costs You
The impact on operational workload multiplies at each phase. Under the old rules a certificate was renewed roughly once a year. In the 200-day phase that becomes about twice a year; the 100-day phase in 2027 makes it four times; and the 47-day phase in 2029 pushes it to roughly eight times a year.
Then multiply that by how many domains you manage. For an organization handling 20 domains and subdomains, the old rules meant about 20 certificate operations a year. In the 47-day phase, that becomes roughly 160 a year — which, done manually, is a certificate task every couple of days.
The bigger risk is human error. Certificate management is a classic low-frequency, high-consequence task: it needs no attention at all, right up until a renewal is missed — at which point the site throws browser security warnings, API calls start failing, and payment integrations can break. Multiplying the frequency by eight multiplies the opportunities to get it wrong.
Why Manual Processes Won't Hold
A full manual renewal usually involves: logging into the CA portal to submit the request, adding a TXT or CNAME record in DNS for validation, waiting for validation to pass, downloading the certificate files, uploading them to every server or CDN node one at a time, reloading the service configuration, and finally confirming the new certificate is actually being served. When everything goes smoothly, that's roughly 20 to 40 minutes.
Multiply that by domain count and renewal frequency and the cost adds up quickly. Worse, this work resists any fixed rhythm — every certificate has its own expiry date scattered across the year, so someone has to keep tracking them. Once a team manages a few dozen domains, simply knowing which certificate expires when becomes a list that needs maintaining in its own right.
How to Respond: Three Layers of Automation
The direction is clear — take the human out of the loop. But automation isn't a single step; it's three layers you can adopt progressively:
Layer one: automated issuance and renewal
The ACME protocol (Automatic Certificate Management Environment) lets a server talk directly to a certificate authority to request, validate, and renew automatically. Let's Encrypt with Certbot is the most common pairing, and most hosting control panels now ship something equivalent. This layer solves where the certificate comes from.
Layer two: automated domain validation
Among ACME's validation methods, HTTP validation requires exposing a specific path publicly, which isn't always convenient; DNS validation requires adding TXT records dynamically. Creating those records automatically through your DNS provider's API removes the manual login step entirely and makes wildcard certificate automation possible. Given that the DCV reuse period is shrinking too, this layer only grows in importance.
Layer three: automated deployment
Obtaining the certificate is only half the job. The genuinely time-consuming part is deployment — pushing the same certificate to multiple servers, multiple CDN nodes, sometimes across different CDN vendors. Without automation here, the time saved in the first two layers gets eaten at the deployment stage. Ideally, a newly issued certificate propagates to every node that needs it and its status is verified automatically.
Three Things to Do Now
If your team hasn't audited its exposure to this change yet, start with these three steps:
- Inventory your certificates List every certificate in use, including the domain, issuing CA, expiry date, where it's deployed (which servers, which CDNs), and who currently owns renewal. Building this list alone tends to surface a few forgotten certificates.
- Separate what can be automated from what can't Most modern environments can adopt ACME, but some legacy systems, air-gapped networks, or specialized hardware may not support it directly. Flagging these exceptions early is what lets you estimate the extra handling cost — or decide whether the architecture itself should change.
- Set up expiry monitoring and alerts Even with automation in place, you still need independent monitoring to confirm renewals actually succeeded. Alerting ahead of expiry is the last line of defense against an automated pipeline failing silently.
In Summary
The direction of travel is settled and the dates are known. The 200-day phase might still be survivable with manual effort, but the 100-day phase in 2027 and the 47-day phase in 2029 effectively rule manual management out. Rather than waiting until the workload has already doubled, it's worth using the remaining runway to get automation in place.
If you're evaluating certificate automation, or want to understand how to automate deployment as well as issuance, our technical team is happy to talk through your specific setup.