The CA/Browser Forum's decision to progressively reduce maximum TLS certificate lifetimes down to 47 days is not just a technical adjustment — it is a defining operational shift that will expose weaknesses in how most organizations manage certificates. The organizations that come out ahead will be those that treated 2026 as a preparation window, not a deadline.
The reductions are coming in three waves, each one closing off the option to delay:
| Period | Max validity | Renewals/year (for a single cert) |
|---|---|---|
| Today (pre-2026) | 398 days | ~1× |
| March 2026 – March 2027 | 200 days | ~2× |
| March 2027 – March 2029 | 100 days | ~4× |
| After March 2029 | 47 days | ~8× |
The 200-day limit is already in effect for new certificates issued after March 2026. Teams that haven't started thinking about automation are already behind.
The rationale is sound, even if the operational implications are steep. Longer-lived certificates create two systemic risks.
First, certificate revocation has largely failed as a mechanism. OCSP responders time out, CRL downloads are slow, browsers implement soft-fail revocation checks, and mobile clients often skip them entirely. The practical reality is that once a certificate is issued, revoking it has limited effect — relying parties may continue to trust it. A shorter validity period bounds the blast radius of a compromised private key or a misissuance event. If the worst happens, the cert expires in six weeks on its own.
Second, longer lifetimes accumulate organizational debt. A certificate issued 18 months ago may have been issued to a service that no longer exists, a team that has changed, a domain you're in the process of decommissioning. Frequent renewal forces periodic re-confirmation that the certificate is still needed and still appropriate.
The security reasoning is correct. But it shifts an assumption that has been baked into how most teams work: that certificate management is an annual or semi-annual task, handled manually or through loosely coupled tooling.
By the final phase, every certificate needs renewing roughly every six weeks. An organization with 50 public-facing certificates — not unusual for a mid-sized SaaS company — goes from managing roughly 50 renewals per year to roughly 400. What used to be a manageable quarterly task will become a near-weekly operational burden.
And that count of 50 public certs almost certainly understates the real picture. Most mid-market organizations also have internal certificates: service mesh mTLS, internal APIs, database connections, monitoring agents, VPN infrastructure. Add those, and the number often reaches into the hundreds — with less visibility, less tooling, and less automation than the public-facing surface.
The failure mode is predictable: automation handles 95% of renewals correctly, and the remaining 5% cause production incidents. At 8× the renewal frequency, that 5% failure rate creates far more outages.
Most teams have already automated public cert renewal with something like Certbot or Let's Encrypt's ACME client. That handles the simple case. The problems show up at the edges:
You cannot automate renewal for certificates you don't know about. Most organizations have a combination of Let's Encrypt certs, certificates from a commercial CA, internal certificates issued from a private CA, and certificates that were manually generated by developers for specific services. The Let's Encrypt certs have automation. The rest often don't, and they don't all live in the same place.
Automation without policy is just fast chaos. If a developer can request a wildcard cert covering your entire internal domain by deploying a Kubernetes Certificate manifest, you've automated the attack surface. Governance requires that certificate requests go through a layer that enforces: which domains are permitted, which CA to use, what validity period is acceptable, and whether a human needs to approve it.
SOC 2, PCI-DSS, ISO 27001, and HIPAA all touch certificate management in one form or another. Auditors want evidence that certificate issuance was controlled and authorized. "We use Certbot" doesn't satisfy that. You need a record of who requested each certificate, who approved it, what policy it was issued under, and where it was deployed.
When your certificate inventory is split across Let's Encrypt, DigiCert, an internal CA, and whatever your cert-manager cluster is doing, you don't have a full picture of your expiry risk. Expiry alerts from multiple disconnected systems are easy to miss.
Calendar-based manual renewal was already fragile at annual renewal. At 47-day lifetimes, it will fail routinely. Human attention doesn't scale linearly with renewal frequency.
Application-level automation (scripts embedded in each application's deployment that handle their own cert renewal) solves the mechanical problem but creates a new one: your certificate management logic is now distributed across dozens of services, each with its own failure modes, logging, and alerting. There's no central place to answer "what certs do we have and when do they expire?"
Per-CA tooling (a Certbot script here, a cert-manager issuer there, a DigiCert API integration somewhere else) works until you need a unified compliance report. Then you're assembling evidence from six different systems.
The organizations that handle the 47-day era without outages and without compliance gaps are the ones that centralize certificate governance without centralizing certificate delivery.
The architecture looks like this: every certificate request — regardless of whether it comes from a developer in the Platform UI, a Kubernetes cert-manager manifest, an automated renewal job, or an AI agent using the MCP protocol — routes through a central governance proxy. That proxy:
The CAs themselves remain where they are — Let's Encrypt for public certs, your internal CA for private ones. The governance layer doesn't replace them; it sits in front of them.
Renewal automation fits cleanly into this model. The renewal job submits a request to the governance layer. If it matches an auto-approve policy (same domains, same CA, same team), it's issued immediately. If it falls outside policy — an unexpected domain added, a validity period that's too long — it goes to a human. The audit trail is complete either way.
There's a separate, non-operational reason to move on this before the 47-day deadline: the compliance picture is getting harder.
The same browsers enforcing shorter lifetimes are the ones auditors trust as evidence of "industry standard practices." Saying you were aware of the CA/Browser Forum timeline but didn't adapt your certificate management practices is a harder position to defend in an audit than saying you have a governance layer that enforces certificate policy across all issuance channels.
The teams that implement governance now get a second benefit: the audit evidence is already being generated by the time the auditor asks for it. You're not reconstructing a paper trail from Git history and Slack messages — you have a complete, per-certificate record of every request, approval, and deployment.
The 200-day limit is live. The 100-day limit arrives in March 2027. The teams that start building the governance layer in 2026 will have it fully operational and with some production experience behind it before the 100-day window closes. The teams that wait until 2028 will be building it under fire.
The operational investment is lower than it looks. A governance proxy doesn't replace your existing CAs or your cert-manager setup — it integrates with them. For most teams, the heavy lift is inventory: discovering what certificates you actually have, where they live, and which ones have renewal automation that routes through a governed channel and which ones don't.
That inventory exercise is worth doing regardless. The 47-day era just made it urgent.
CertForge was built for this moment.
A governance layer that sits in front of your existing CAs — bringing policy enforcement, human approvals, immutable audit trails, and SIEM integration without the complexity and cost of traditional enterprise CLM platforms. Connect your first CA in under an hour.
Start free — no credit card