Starting March 15, 2026, the CA/Browser Forum voted to reduce maximum SSL/TLS certificate validity from 398 days to 200 days – and the reduction doesn’t stop there. Under the approved ballot SC-081, the limit drops further to 100 days in 2027, then to 47 days in 2029. For anyone managing web certificates today, the 200-day threshold is the first concrete deadline to plan around. Certificates issued on or after March 15, 2026, must not exceed 200 days. Any cert issued before that date under the old 398-day maximum remains valid until its natural expiry, but no new 398-day certificates can be issued after the cutoff.
SSL certificate validity refers to the period during which a certificate is considered trusted by browsers and operating systems. Once that window closes, the certificate expires and browsers display security warnings to visitors – regardless of whether the underlying domain or key pair has changed.
Why Did the Industry Reduce the Validity Period?
The reduction exists to limit the exposure window when a certificate’s private key is compromised. Shorter lifespans mean stale or potentially unsafe credentials cycle out of the ecosystem faster. According to Google’s Chrome Root Program policy documentation (updated 2025), longer-lived certificates create persistent attack surfaces because revocation mechanisms – OCSP and CRL – are inconsistently enforced across clients. A certificate that lives for 398 days but whose key was exposed at month six remains technically valid for another ten months under the old rules.
The push has been building for years. Google first proposed 90-day certificate lifespans within the Chrome Root Program as far back as 2023, and the industry’s move to 200 days by March 2026 reflects a negotiated consensus between browser vendors and certificate authorities. The trajectory is clearly toward much shorter lifespans – 200 days is not the destination.
What Exactly Changes on March 15, 2026?
As of March 15, 2026, any publicly trusted SSL/TLS certificate issued by a certificate authority that participates in the CA/Browser Forum must cap its validity at 200 days. The change applies to all certificate types: DV, OV, and EV. Domain Control Validation (DCV) re-use periods also shrink – under the new ballot, domain validation may only be reused for up to 200 days before a fresh validation check is required.
The timeline across all three stages looks like this:
|
Effective Date |
Max Certificate Validity |
Max DCV Re-use |
|
March 15, 2026 |
200 days |
200 days |
|
March 15, 2027 |
100 days |
100 days |
|
March 15, 2029 |
47 days |
10 days |
Each row represents a hard cap – not a recommendation. CAs that issue certificates exceeding these limits would be in violation of baseline requirements and could face distrust from browser root programs.
How Does This Affect Certificate Renewal Workflows?
Organizations that renew certificates manually once a year will need to adjust immediately. A 200-day limit means certificates must be renewed roughly every six months. By 2029, with a 47-day maximum, manual renewal processes become functionally unworkable at any meaningful scale.
The practical shift this creates:
- Automated certificate management becomes mandatory at scale. Tools like ACME-based clients (Certbot, cert-manager for Kubernetes) and platform-native automation on AWS, Azure, and GCP handle issuance and renewal without human intervention.
- Internal PKI must align with public CA changes. Many organizations running private certificate authorities have mirrored public CA validity periods by convention. Internal certificates should be brought into alignment with organizational renewal automation, even if private CAs are not formally bound by CA/Browser Forum rules.
- Certificate inventory visibility becomes urgent. Teams without a clear view of their certificate estate – what they have, when each expires, and who owns each – will face outages as shorter lifespans compress the window between issuance and expiry.
You can verify your existing certificates’ validity windows using OpenSSL commands to check certificate details before planning any renewal schedule changes.
Does the 200-Day Change Affect Existing Certificates?
No. Certificates already issued before March 15, 2026, retain their original validity period and will not be truncated by the new rule. A certificate issued February 1, 2026, with a 398-day validity will remain valid through February 2027 without any action required.
The rule applies prospectively – only to new issuances on or after the effective date. So if a certificate is up for renewal in April 2026, the new one must carry a maximum 200-day term. The one being replaced, assuming it was issued under the old rules, simply expires on its original date.
Will Free SSL Certificates from Let’s Encrypt Be Affected?
Let’s Encrypt already issues certificates with a 90-day validity period and is not directly affected by the 200-day cap – their certificates already fall well under the new limit. Users relying on Let’s Encrypt through automated ACME clients are already operating in a short-lifespan model and will continue to do so.
The organizations most impacted are those purchasing one-year or multi-year certificates from commercial CAs. Multi-year plans have always worked by issuing sequential shorter-validity certificates over the plan period, but now the individual certificate in each cycle must not exceed 200 days.
What Should Organizations Do Right Now?
The March 2026 deadline is here, which means next renewal cycle is the first one subject to the new limit. Three actions matter immediately:
- Audit your certificate inventory. Identify every publicly trusted certificate in your environment, its expiry date, and whether renewal will fall after March 15, 2026. Any renewal after that date gets a 200-day certificate – plan for it.
- Evaluate your renewal automation maturity. If certificates are renewed through a ticketing process or calendar reminder, map out whether that approach is sustainable at 200-day cycles. If not, begin piloting ACME-based automation or a certificate lifecycle management platform before the next major renewal wave.
- Update internal documentation and runbooks. Teams that document renewal schedules based on annual cycles need to revise those assumptions. Any runbook that says “renew 30 days before expiry on an annual basis” is already outdated.
For teams thinking ahead to the 47-day era, the guide to transitioning to 47-day SSL/TLS certificates covers the infrastructure and automation steps needed well before 2029.
Does Shorter Validity Actually Improve Security?
Shorter certificate lifespans improve security in two meaningful ways. First, they reduce the blast radius of a compromised private key – an attacker who obtains a private key has less time to exploit it before the certificate naturally cycles out. Second, they enforce more frequent domain validation, which means any unauthorized certificates issued for a domain get discovered and replaced sooner.
The limitation is that shortened validity doesn’t address all threat vectors. A certificate that is actively being misused can still cause harm within its validity window, regardless of whether that window is 200 days or 47. Certificate transparency logs already provide the primary mechanism for detecting unauthorized issuance – validity reduction complements but does not replace that system.
According to CSC’s SSL Landscape report analyzing over 802,000 certificates across 2.4 million domains (November 2025), around 40% of enterprises already risk SSL outages under current renewal practices – a figure that grows substantially as renewal frequency increases. The same research found that nearly 60% of companies manage certificates across three or more providers, creating fragmented inventory that becomes harder to track as validity windows shrink.
For teams preparing for the eventual transition to 47-day certificates, preparing for shorter SSL certificate lifespans covers the foundational automation steps that apply equally to each successive reduction.
What This Means Going Forward
The 200-day transition is the beginning of a structured, decade-long move toward certificates that expire in weeks rather than months. Organizations that treat this as an isolated deadline will find themselves repeating the same scramble in 2027 and again in 2029. The companies that come through this smoothly are those investing now in automation infrastructure – ACME clients, certificate lifecycle platforms, and consistent inventory visibility – rather than patching manual processes at each new deadline.
Renew whatever is coming due under the new 200-day rules, then use the time between now and the 2027 reduction to establish automated renewal pipelines. That investment pays off regardless of how quickly the industry moves.
Frequently Asked Questions
Can I still buy a 1-year or 2-year SSL certificate plan after March 15, 2026?
Commercial CAs will still sell multi-year coverage plans, but the individual certificate issued within that plan cannot exceed 200 days. Buyers purchasing a two-year plan will receive sequential certificates, each valid for up to 200 days, automatically re-issued throughout the coverage period. The billing and plan duration remain multi-year; only the per-certificate validity changes.
What happens if a CA issues a certificate exceeding 200 days after the deadline?
The certificate would violate CA/Browser Forum baseline requirements. Browser vendors – particularly those with root programs like Chrome, Firefox, Safari, and Edge – could treat such certificates as untrustworthy, meaning users would see browser security warnings. CAs that repeatedly violate baseline requirements risk distrust of their root certificates entirely.
Do internal/private SSL certificates need to follow the 200-day rule?
No. The CA/Browser Forum rules govern publicly trusted certificates issued by CAs that participate in browser root programs. Certificates issued by a private, internal CA that is not included in public trust stores are not subject to these limits. That said, aligning internal certificate lifespans with renewal automation practices designed for public CAs is generally advisable.
How does the 200-day limit interact with the Domain Control Validation re-use period?
Under the March 2026 update, domain validation results can also only be reused for up to 200 days. This means the validation check itself must be repeated at least every 200 days, not just the certificate issuance. By 2029 when the 47-day certificate limit takes effect, DCV re-use drops to just 10 days – essentially requiring near-continuous domain validation.
Will Let’s Encrypt change their 90-day certificate issuance in response to these rules?
Let’s Encrypt’s existing 90-day certificates already comply with the new 200-day maximum, so no immediate change is required. Let’s Encrypt has publicly noted interest in potentially moving to shorter durations in the future, but as of early 2026, the 90-day cycle remains standard.
If I renew my certificate before March 15, 2026, can I still get a 398-day certificate?
Yes – if the certificate is issued before the March 15, 2026, effective date, the old 398-day maximum still applies. Certificates issued on or after that date must comply with the 200-day cap regardless of when the purchase or renewal process begins.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
