The short version
Publicly trusted TLS certificates are getting much shorter lives. In April 2025 the CA/Browser Forum passed ballot SC-081, and every public certificate authority is bound by it. The maximum lifetime steps down in three stages, and the window in which a CA may reuse a domain validation shrinks with it.
| Takes effect | 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 |
The first step is already in effect. If you renewed a public certificate after March 2026, you got at most 200 days.
A 47-day certificate renewed at two-thirds of its life means a renewal roughly every 30 days. An organization with a thousand public certificates that renews once a year today will be doing about twelve thousand renewals a year, or thirty-three every day, including weekends. Validation reuse of ten days means almost every one of those renewals also re-proves control of the domain.
Nobody does that by hand. The change is, in practice, a mandate to automate.
Why this is happening
Three reasons, all of them reasonable.
Revocation does not work. Browsers largely ignore certificate revocation lists and online status checks because they are slow and unreliable. If a private key leaks, the only dependable fix is for the certificate to expire. A 47-day certificate caps the damage at 47 days. A 398-day certificate caps it at more than a year.
Validation data goes stale. A domain validated a year ago may have changed hands. Shorter reuse windows mean the CA re-checks control close to issuance.
Agility. When an algorithm, a CA, or a root is distrusted, an ecosystem on short certificates rolls over in weeks instead of years. The industry learned this the hard way through the SHA-1 deprecation, the Symantec distrust in 2018, and the Entrust distrust in 2024. Post-quantum migration will need the same agility.
What is and is not affected
Affected: any certificate issued by a publicly trusted CA for TLS. Websites, APIs, load balancers, reverse proxies, mail servers with public certificates, VPN gateways, SaaS integrations that present a public certificate, and devices in the field that fetch certificates from a public CA.
Not affected: certificates from your own private CA, such as Microsoft AD CS or EJBCA, which follow your policy and not the Forum’s. Code-signing certificates. S/MIME certificates. Document-signing certificates. Client certificates for mutual TLS from a private CA.
That second list matters. Many organizations have public certificates on internal-only systems because it was convenient. Those are the first candidates to move to a private CA, where you control the lifetime.
Where it breaks
Automated renewal is a solved problem for a modern web server. The work is in everything else.
Appliances and middleboxes. Load balancers, firewalls, VPN concentrators, and storage arrays often have no ACME client and a certificate upload screen designed for a yearly ritual. Each needs either a vendor-supported automation path, a lifecycle platform that can push to it through its API, or a decision to terminate TLS somewhere else.
HSM-backed TLS keys. If the private key lives in a hardware security module, the renewal tooling has to generate the CSR there and never see the key. Many ACME clients cannot. This is a design task, not a configuration task.
Certificates baked into images. Container images, virtual machine templates, and firmware that ship with a certificate inside will ship with an expired one within weeks. The certificate has to be injected at deploy time or fetched at start.
Mobile and desktop applications that pin certificates. Pinning to a leaf certificate that changes every month is a guaranteed outage. Pin to the CA or to the key, or stop pinning.
Shared wildcards. One wildcard certificate copied across twenty systems by five teams is twenty renewals nobody owns. Shorter lifetimes turn this from untidy into dangerous.
Extended Validation. EV certificates have never fit automation well. Decide whether you still need them. For most organizations the honest answer is no.
Change control. If every certificate change needs a ticket and a change window, 33 changes a day will not survive contact with your process. Renewal has to be a pre-approved standard change or it will not happen.
The readiness plan
Six phases. Most organizations can do the first three in a quarter and should.
1. Discover
You cannot automate what you cannot see. Build a complete inventory of public certificates: scan your external IP space and DNS names, pull issuance history from Certificate Transparency logs for every domain you own, and query every CA account you have. Certificate Transparency is the step people skip, and it is the one that finds the certificates a contractor ordered four years ago.
Record for each certificate: where it is installed, what issued it, when it expires, how it is renewed today, and whether the private key is exportable.
2. Assign ownership
Every certificate gets a named owning team and an escalation contact that survives staff turnover. Put this in the inventory system, not a spreadsheet. If a certificate has no owner after a reasonable search, it is a candidate for retirement.
3. Automate the easy majority
For web servers, reverse proxies, Kubernetes ingress, and cloud load balancers, ACME is the answer. Use the client native to the platform where one exists. For everything with an API, a certificate lifecycle management platform such as Keyfactor Command, Venafi, DigiCert Trust Lifecycle Manager, or Sectigo Certificate Manager can drive renewal and installation centrally and gives you the inventory and reporting from phase one as a side effect.
Choose one validation method and standardize on it. DNS-based validation through an API-managed DNS provider works for everything, including systems that are not reachable from the Internet, and it works for wildcards.
4. Handle the exceptions deliberately
What remains after phase three is the hard list from the previous section. For each item, pick one of four outcomes and write it down:
- Automate it through a vendor integration or lifecycle platform connector.
- Move TLS termination to something that can automate, and put the appliance behind it.
- Move it to a private CA because it never needed a public certificate.
- Accept manual renewal, with an owner, a calendar, and a documented procedure, because the system is going away within a year.
The fourth option is legitimate only with an end date.
5. Monitor and alert
Expiry monitoring should come from two independent sources: the lifecycle platform that thinks it renewed the certificate, and an external scanner that checks what is actually being served. They disagree more often than you would expect. Alert at 14 days and 7 days for 47-day certificates, and page a human at 3.
6. Rehearse
Before March 2027, shorten your own certificates voluntarily. Let’s Encrypt already issues 90-day certificates and offers 6-day ones. Running a quarter on 90-day certificates exposes every weak point in your automation while the stakes are still low. Treat each failure as a gift.
Timeline for a typical enterprise
| When | What should be true |
|---|---|
| Now | Inventory complete. Owners assigned. ACME live for web tier. |
| By March 2027 | Lifecycle platform or ACME covering 90% of public certificates. Exception list written, each with an outcome. Internal-only systems moved to private PKI. |
| By March 2028 | Exceptions resolved. Voluntarily running on 90-day or shorter certificates everywhere. Two independent monitors. Renewal is a standard change. |
| By March 2029 | Nothing left to do. |
Questions we get
Will my private PKI be forced to 47 days too? No. The ballot binds public CAs. Your AD CS or EJBCA policy is your own. That said, the same operational discipline applies, and shorter internal certificates are good practice once renewal is automated.
Can I just buy a long certificate before each deadline? Only until the deadline. A certificate issued on March 14, 2027 can still be 200 days. After that, no CA can issue one. Stockpiling buys months, not a strategy.
What about Let’s Encrypt versus a paid CA? Both are bound by the same rules. The difference is support, features such as organization validation, and integrations. Lifetime is no longer a differentiator.
Does this affect my code-signing or S/MIME certificates? Not this ballot. Code signing has its own rules, including the 2023 requirement that keys live in hardware. S/MIME has a separate baseline. Both are trending shorter too.
Where we can help
A 47-day readiness assessment covers the inventory, the ownership gaps, the exception list, and a sequenced plan with the automation path for each system. It usually takes two to three weeks and leaves you with a plan your own team can execute. If you want help executing it, that is the rest of what we do.