The short version
In April 2025, the CA/Browser Forum — the industry body that sets SSL/TLS certificate standards — voted unanimously to reduce maximum certificate lifespans from 398 days to just 47 days by 2029. The change rolls out in phases, and the first one takes effect this month.
If you manage SSL certificates for your organization, this affects you. Here's what's changing, why it matters, and how to prepare.
The timeline
The reduction is phased to give organizations time to adapt:
March 15, 2026 — 200 days. Maximum certificate lifespan drops from 398 to 200 days. Domain Control Validation (DCV) reuse also drops to 200 days. This is the first real operational change. If you were renewing once a year, you're now renewing twice.
March 15, 2027 — 100 days. Certificates max out at 100 days. DCV reuse drops to 100 days. You're now renewing roughly every three months. Quarterly renewal is manageable manually, but it's tight.
March 15, 2029 — 47 days. The final target. Certificates last a maximum of 47 days. DCV reuse drops to just 10 days. You're renewing every month, and validating your domain ownership almost continuously.
The vote passed 25-0 among certificate authorities, with all four major browser vendors — Apple, Google, Mozilla, and Microsoft — voting in favor. This isn't a proposal. It's happening.
Why 47 days?
The number sounds arbitrary, but the logic is straightforward.
Shorter exposure windows. When a certificate is compromised — through a leaked private key, a misconfigured server, or a CA mistake — the damage window is limited to the certificate's remaining validity. A 398-day cert gives an attacker up to 13 months. A 47-day cert gives them weeks at most.
Revocation doesn't work well. The existing systems for revoking compromised certificates — Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) — are unreliable in practice. Many browsers have stopped checking them altogether. Shorter lifespans are a pragmatic workaround: if you can't reliably revoke a certificate, make it expire quickly instead.
Forcing automation. The CA/Browser Forum has been signaling for years that manual certificate management is unsustainable. Shorter lifespans make that explicit. The intent is to push the entire ecosystem toward automated renewal using protocols like ACME (the same protocol behind Let's Encrypt).
Crypto agility. As quantum computing advances, the ability to rotate certificates quickly becomes a security requirement, not just an operational convenience. Short-lived certificates make it easier to transition to new cryptographic algorithms when the time comes.
The math gets uncomfortable fast
Here's where it gets real for most IT teams.
At 398-day lifespans, managing 50 certificates means roughly 50 renewal events per year. That's just under one per week — manageable with a calendar and some discipline.
At 47-day lifespans, those same 50 certificates require approximately 400 renewal events per year. That's more than one per day, every day, including weekends and holidays. And that's before you factor in the 10-day DCV reuse window, which means you're also re-validating domain ownership almost constantly.
For a single certificate on a single site with Let's Encrypt and a working ACME client, this is a non-issue — the automation handles it. But most organizations aren't in that situation. They have certificates spread across web servers, load balancers, CDNs, firewalls, mail servers, VPN appliances, API gateways, and legacy systems that don't support ACME. Some of those systems require manual certificate installation. Some require change board approval. Some run in air-gapped environments.
The teams that will feel this the most aren't the ones with fully automated cloud-native infrastructure. It's the ones in the middle — managing a mix of modern and legacy, cloud and on-prem, automated and manual. Which, frankly, describes most organizations.
What this means for different teams
If you're already fully automated with ACME: You're in good shape. Make sure your renewal processes are monitored (silent failures in auto-renewal are a leading cause of outages — I wrote about that here). Test that your pipeline handles the shorter renewal cycles without hitting rate limits.
If you're partially automated: Identify which certificates are covered by automation and which aren't. The ones that aren't are your risk. Prioritize getting those into an automated pipeline, or at minimum into a tracking system with alerts.
If you're managing certificates manually: You have until March 2026 to start changing that — which is now. Manual renewal at 200-day intervals is feasible but tight. At 100 days (March 2027), it becomes a part-time job. At 47 days, it's untenable for anything more than a handful of certificates.
If you're in a regulated or change-controlled environment: This is where it gets complex. Many organizations require change requests and CAB approval for certificate installations. That process needs to be streamlined or exempted for routine renewals, because the current cadence won't survive monthly certificate rotations.
This only applies to public certificates
One important clarification: the 47-day mandate only applies to public SSL/TLS certificates issued by publicly trusted Certificate Authorities. Internal PKI certificates — the ones you issue yourself for internal applications, dev environments, and non-public systems — aren't subject to these rules.
That said, the principles behind the change — shorter lifespans, automated renewal, better monitoring — are worth adopting internally too. If your internal certificates expire and take down an internal service, the CA/Browser Forum's rules don't matter much. The outage is the same.
What you should do now
Regardless of your current setup, here are concrete steps to take before the first reduction hits:
Inventory everything. You can't manage what you can't see. Build a complete list of every public certificate your organization uses — not just the ones on your main website, but wildcard certs, SAN certs, certs on mail servers, API endpoints, and third-party integrations. If you don't have this list today, that's the first problem to solve.
Identify what can't auto-renew. Some systems support ACME or API-driven renewal. Others don't. Know which is which. The ones that can't auto-renew are the ones that will cause you the most pain as lifespans shorten.
Set up monitoring on your automation. If you're using auto-renewal (Let's Encrypt, cloud provider managed certs, etc.), verify that it's actually working — not just that it was working last time you checked. Silent auto-renewal failures are one of the most common causes of certificate outages. Set up alerts for renewal failures, not just for upcoming expirations.
Talk to your change management team. If certificate installations currently require change board approval, start the conversation now about how to handle monthly renewals. Automation-friendly policies (like pre-approved change templates for routine renewals) will save everyone significant pain.
Pick a tracking system. Whether it's a spreadsheet, a monitoring tool, or something purpose-built like CertWatcher — make sure you have a single source of truth for what's expiring and when. The 47-day cycle doesn't leave room for "I thought someone else was tracking that."
The bigger picture
The shift to 47-day certificates is part of a broader trend: the things that secure our infrastructure are getting faster, shorter-lived, and more automated. That's a good thing for security. But it raises the operational bar for every team that manages certificates.
The organizations that will handle this transition smoothly are the ones that treat certificate management as an ongoing operational concern — not a set-it-and-forget-it task. The ones that will struggle are the ones that don't realize they need to change until the first renewal deadline slips by. The good news is that for teams that start now, this is a solvable problem.
March 2026 is the starting line. The time to prepare is now.
CertWatcher helps individuals and IT teams track credential expiry dates with automated alerts at 30, 14, 7, and 1 day before expiration. Free tier available at certwatcher.dev.
Top comments (0)