The First 200-Day Certificates Expire Around 1 October and Nobody Has Exercised the Renewal Path Since March
TL;DR The maximum lifetime for public TLS certificates dropped from 398 days to 200 days on 15 March 2026. This means the first cohort of certificates issued under the new limit will expire around 1 October 2026, forcing many engineering teams to exercise their renewal paths for the first time since the rules changed.
On 15 March 2026, the ceiling for public TLS certificate validity was slashed in half. While the industry has discussed the move toward shorter lifespans for years, the operational reality is now arriving. If you issued a certificate on the first day of the new regime, its expiration date is approaching rapidly. This is not a prediction; it is simple arithmetic based on the CA/Browser Forum’s mandated schedule.
The date nobody has done the arithmetic on
Maximum public TLS certificate lifetime dropped from 398 to 200 days on 15 March 2026, following the adoption of CA/B Forum ballot SC-081v3. Two hundred days after 15 March 2026 falls on or about 1 October 2026.
For many organizations, the certificates issued in that late-March window represent the "first-movers" of the 200-day era. Because the previous cycle was 398 days, any renewal path you have in place has likely only been exercised once—if at all—since the new rules took effect. The exact expiration for your specific services will depend on their precise issuance date, but the "October Wall" is the first major test of organizational certificate expiration monitoring.
What actually changed on 15 March 2026, precisely
The transition isn't just about the expiration date on the certificate. According to the CA/B Forum, ballot SC-081v3 introduced three critical reductions simultaneously:
- Certificate Lifetime: 398 days reduced to 200 days.
- Domain/IP Validation Data Reuse: 398 days reduced to 200 days.
- Subject Identity Information (SII) Reuse: 825 days reduced to 398 days (for OV and EV certificates).
This is part of a multi-year aggressive ramp-down. On 15 March 2027, lifetimes drop to 100 days. By 15 March 2029, we hit the 47 day certificate era, where validation data reuse is capped at just 10 days. According to DigiCert, this 2029 milestone creates a structural "trap": since validation data expires in 10 days but the certificate lasts 47, manual revalidation becomes essentially impossible to manage at scale.
Why the renewal that worked is not evidence
The most dangerous assumption an SRE can make is that a successful automated renewal for one service means the entire estate is safe. An automated ACME pipeline succeeding for your primary web front-end proves that one path works. It says nothing about the certificates that exist outside that automation.
Key Takeaway: The primary risk of shorter certificate lifecycles is not the failure of known automation, but the discovery gap of the uninventoried estate.
In many outages, the failure mode is not the certificate that renewed, but the four legacy certificates in the estate that were never added to the monitoring tool. As the frequency of renewals increases, the "hope-based" strategy for manual certificates becomes a statistical certainty for downtime.
The estate nobody inventoried
To survive the transition to a 200 day certificate ceiling, you must move from renewal management to inventory reconciliation. Here is where the "hidden" certificates usually reside:
- Public Edge & CDN: Often managed via provider-specific APIs; ensure your certificate expiration monitoring integrates with Cloudflare, CloudFront, or Akamai directly.
- Internal mTLS: Service-to-service mesh certificates. Check your Istio or Linkerd expiration settings.
- Baked Certificates: Certificates living inside container images or static K8s ConfigMaps. These do not update when the CA issues a new cert; they require a redeploy.
- Mobile Pinning: If your mobile app pins to a specific leaf or intermediate, your release cadence is now tethered to a 200-day (and soon 100-day) window.
- Hardware Appliances: Load balancers (F5, Citrix) or VPN gateways often require manual PKCS#12 uploads by a specific admin.
The step that has a human in it
The reduction in validation reuse is the underrated "poison pill" in SC-081v3. Previously, you could renew a certificate for years without re-proving you owned the domain or that your company existed.
Now, if you are using Organization Validation (OV) or Extended Validation (EV), the Subject Identity Information (SII) reuse cap of 398 days means that every second renewal will likely require a human to interact with a CA auditor. This creates a lead-time bottleneck that a cron job cannot fix. If your legal entity name changed or a contact person left the company, your renewal will block.
Detection that does not depend on remembering
Effective certificate expiration monitoring must be external. Checking a file on a disk is insufficient; you must check the certificate being served over the wire.
| Phase Date | Max Lifetime | Validation Reuse | Suggested Alert Horizon |
|---|---|---|---|
| Current | 200 Days | 200 Days | 30 Days |
| Mar 2027 | 100 Days | 100 Days | 15 Days |
| Mar 2029 | 47 Days | 10 Days | 5 Days |
Alerts must be routed to a team rotation (e.g., PagerDuty) rather than an individual's email. When lifetimes drop to 47 days, a 30-day alert is useless; you need a tiered horizon that scales with the certificate's lifespan.
The compounding load nobody has budgeted
Moving from a 398-day cycle to a 47-day cycle represents an eightfold increase in operational load per certificate. For an organization with 1,000 certificates, you are moving from ~900 renewals per year to over 7,000. This is not a one-time migration; it is a permanent increase in the "tax" of running secure infrastructure. The work is no longer the renewal itself—which should be automated—but the constant discovery of new services and the reconciliation of the estate.
Eight-Week Checklist for 1 October Readiness
- Week 8 (Today): Run an external scan (using tools like
nmaporzgrab2) against all internal and external IP ranges to find every listening TLS port. - Week 7: Identify any OV/EV certificates and verify that the Subject Identity Information (SII) was validated within the last 300 days.
- Week 6: Audit mobile app teams for hardcoded certificate pins.
- Week 5: Check "manual" endpoints (VPNs, old ALBs) and schedule the manual renewal now.
- Week 4: Verify that your certificate expiration monitoring alerts are actually reaching an on-call engineer and not a "noreply" inbox.
- Week 2: For any certificate not yet renewed, force a manual trigger of the automation to ensure the path is clear.
Sources & Further Reading
- According to the CA/Browser Forum, ballot SC-081v3 was passed with near-unanimous support from browsers including Google and Apple.
- As stated by DigiCert, the transition to shorter lifetimes is designed to increase security by reducing the window of opportunity for compromised keys.
- According to The SSL Store, the move to 47-day certificates by 2029 will mandate total automation for any organization that wishes to remain online.
Certificate expiry is a proactive operational challenge: it is entirely knowable in advance, yet it remains a leading cause of major outages because it spans code, infrastructure, and third-party vendors. Operate approaches these problems by opening the investigation before the failure occurs, scanning your configuration and infrastructure to find the certificates your inventory missed. When it finds a looming expiration or a broken renewal path, it doesn't just alert—it drafts the fix.