For most of the last decade, the maximum validity period for a publicly trusted TLS certificate sat at 398 days — just over thirteen months. Long enough that a sysadmin could handle renewals with a calendar reminder and a few manual steps. That window is closing.
In April 2025, the CA/Browser Forum passed a ballot with unanimous support from all four major browser vendors — Apple, Google, Microsoft, and Mozilla — to reduce maximum TLS certificate lifetimes in stages, ending at 47 days by March 2029. The first reduction hits in March 2026. If your organization still relies on manual certificate management, this affects your planning timeline now.
The Full Reduction Schedule
The changes arrive in three phases, each affecting both the maximum certificate validity period and the Domain Control Validation (DCV) reuse window:
March 15, 2026
- Maximum certificate validity: 200 days (down from 398)
- DCV reuse period: 200 days
March 15, 2027
- Maximum certificate validity: 100 days
- DCV reuse period: 100 days
March 15, 2029
- Maximum certificate validity: 47 days
- DCV reuse period: 10 days
These rules apply to newly issued publicly trusted TLS/SSL certificates. A certificate issued before a cutoff date remains valid through its original lifetime — but once it expires and you renew, the replacement certificate is subject to the limits in effect at that time. Code signing certificates, document signing certificates, and certificates issued by private or internal CAs are not covered by this ballot.
The DCV reuse change deserves separate attention. Domain Control Validation is the process by which a CA confirms you actually control a domain before issuing a certificate for it. Currently that proof can be reused across issuances for up to 398 days. By 2029, that reuse window drops to 10 days — which means every 47-day renewal cycle requires a fresh domain validation, not a cached one.
Why This Is Happening
The security case
When a certificate’s private key is compromised, the attacker can use it until the certificate expires or is successfully revoked. Certificate revocation has historically been unreliable at scale. Browsers don’t strictly enforce OCSP checks, CRL files are large and often cached, and a determined attacker can often prevent revocation information from reaching clients. Shorter certificate lifetimes reduce the window of exposure by design rather than depending on revocation to work.
The same logic applies to stale identity information. Organization Validated and Extended Validation certificates embed details about the certificate holder that were accurate at issuance but can drift over time — a company changes its legal name, moves offices, or is acquired. More frequent reissuance keeps that data current.
Crypto-agility
The industry is also looking ahead to post-quantum cryptography. Current algorithms like RSA and ECDSA will eventually need to be replaced, and the transition will require re-issuing certificates fleet-wide. Organizations with fully automated certificate pipelines can make that switch quickly. Organizations with manual processes cannot. Shortening certificate lifetimes is partly about building that operational muscle before it becomes urgent.
The forcing function argument
Shorter lifetimes are, in part, deliberate pressure to accelerate automation adoption. At 47-day validity with a 10-day DCV reuse window, the manual approach — generating a CSR, submitting it to a CA portal, completing domain validation, downloading the certificate, and deploying it — is not viable at any meaningful scale. The CA/Browser Forum is betting that operational necessity will drive adoption of ACME and similar automated provisioning systems.
Let’s Encrypt has operated this way since its launch. Certificates are valid for 90 days and the expected workflow is automated renewal, typically every 60 days. That pattern is now becoming the industry standard.
What Changes in Practice
For organizations with existing ACME automation
If you’re already using certbot, acme.sh, or a similar tool with a major CA, your renewal automation likely handles both certificate issuance and domain validation in a single flow. The main thing to verify is that your renewal timing is aggressive enough. A renewal that runs 30 days before expiry is fine for 90-day certificates; for a 47-day certificate, that leaves you 17 days — not much runway if something goes wrong. Adjust renewal to trigger at roughly half the certificate lifetime, not 30 days before expiry.
For organizations with manual or semi-automated workflows
The 2026 reduction to 200 days is the inflection point. A 200-day certificate renewed manually is inconvenient but survivable. A 100-day certificate is stressful. A 47-day certificate renewed manually at any meaningful scale is an incident waiting to happen. If your current process involves humans touching a CA portal and manually deploying certificates, that process needs to change well before 2027.
For embedded systems and appliances
This is the hardest category. Network appliances, IoT devices, industrial controllers, and older load balancers often don’t support ACME, have limited scripting capabilities, and may require manual firmware procedures to update certificates. Vendors will need to add automation support; organizations running hardware that can’t be updated have a harder problem to solve. If this describes part of your infrastructure, identify those devices now and start conversations with vendors about roadmaps.
Operational Challenges to Plan For
Certificate inventory gaps
Many organizations discover their certificate inventory is incomplete when they start working on automation. Certificates are issued across teams and projects without centralized tracking, sometimes by employees who have since left. You can’t automate renewal of certificates you don’t know exist. An accurate inventory — issuing CA, expiry date, domains covered, deployment locations — is the prerequisite for everything else. Setting up proper expiry monitoring across your infrastructure is also what catches anything that slips through automation.
Change management overhead
Organizations in regulated industries often require change approvals before any certificate is deployed to production. If your change process takes two weeks, that window consumes a large fraction of a 47-day certificate’s lifetime. Change management procedures designed around annual renewals will need to be revisited. The goal isn’t to bypass controls but to make the process work for much shorter cycles — pre-approved automation workflows, exception handling for common renewal scenarios, or tiered approval paths for routine renewals versus emergency replacements.
DCV automation
When the DCV reuse window shrinks to 10 days, domain validation must happen as part of every renewal, not once during initial setup. ACME protocols handle this by performing domain validation inline during each certificate request. If you use a non-ACME workflow with manual or batched DCV steps, that process will need to be rebuilt as part of the renewal automation.
DNS-based validation (DNS-01 challenge) works well here because it doesn’t require an accessible HTTP server, handles wildcard certificates, and can be automated through DNS provider APIs. The downside is DNS propagation delay — if your DNS TTL is set high, challenges can fail or time out. Lower TTLs (300 seconds or less) on the DNS records used for validation reduce that risk significantly.
Monitoring and alert thresholds
Alert thresholds configured for annual renewals don’t translate to short-lived certificates. A “30 days until expiry” alert gives you a month of lead time on a 398-day certificate; on a 47-day certificate, it means the cert is already 65% expired and you need to act immediately. For any automated renewal system, monitoring the automation itself — alerting on renewal failures, not just expiry proximity — is a better signal. A failed renewal 35 days before expiry is a much cleaner alert than a looming expiry date with unclear root cause.
Getting Ready: A Practical Checklist
Now through early 2026:
- Complete your certificate inventory. Map every publicly trusted certificate to its deployment location, issuing CA, and current expiry.
- For each certificate, document the current renewal process. Where is the human in the loop? What are the dependencies?
- Confirm whether your CAs support ACME. Most major commercial CAs now offer ACME endpoints. If yours doesn’t, start the conversation.
- Test automated renewal end-to-end in a non-production environment before relying on it in production. Specifically test failure scenarios: ACME server unreachable, DNS challenge failing, deployment step partially completing.
Before March 2026:
- Migrate manual renewal workflows to ACME or equivalent automation wherever possible.
- For Let’s Encrypt deployments, certbot provides a well-documented path to automated renewal including support for DNS challenges and deployment hooks.
- Update monitoring to alert on renewal failures and push expiry warnings earlier relative to the new certificate lifetimes.
- Identify any certificates that can’t be automated and build a plan for those specifically — whether that’s hardware replacement, custom scripting, or an exception process.
Ongoing:
- Review renewal automation after each phase transition to confirm timing and failure handling are appropriate for the new lifetime.
- For the 2027 (100-day) and 2029 (47-day) transitions, re-examine anything that was borderline acceptable at the previous validity period.
The Broader Shift
The move to shorter certificate lifetimes is part of a longer arc toward treating certificate management as a continuous operational process rather than a periodic administrative task. Let’s Encrypt normalized this for the public web years ago. The CA/Browser Forum ballot extends the same expectation to the commercial certificate space.
Organizations that invest in automation before the 2026 deadline will find the subsequent transitions manageable. The phased schedule is generous — three years of lead time before the final 47-day limit. Organizations that wait and try to absorb the 2029 change at once will have a harder time.
The 47-day limit isn’t the end state; it’s where the current ballot lands. The direction of travel — toward shorter lifetimes, stricter DCV reuse windows, and mandatory automation — is the part to internalize.