How Long Can an SSL Certificate Last Now? The 200, 100, 47 Schedule
A publicly trusted TLS certificate can be issued with a maximum validity of 200 days. That limit took effect on 15 March 2026 and replaced the 398 day maximum that had stood since 2020. It drops again to 100 days on 15 March 2027, and to 47 days on 15 March 2029, under CA/Browser Forum ballot SC-081v3.
This article lays out the schedule and what governs it, the practical detail that most certificates are actually issued at 199 days rather than 200, the parallel reduction in how long domain validation can be reused, what it means for renewal automation, and the exception that catches people out, which is that none of this applies to private certificate authorities.
The schedule, and what it applies to
The change comes from CA/Browser Forum ballot SC-081v3, proposed by Apple and sponsored by Sectigo, which passed on 11 April 2025 with twenty-five certificate authorities voting yes, none against, and all four browser vendors in favour. It sets three step-downs rather than one cliff.
Call it the 200, 100, 47 ladder. Until 15 March 2026 the maximum was 398 days. From 15 March 2026 it is 200 days. From 15 March 2027 it becomes 100 days. From 15 March 2029 it becomes 47 days. The cutoffs are keyed to issuance date, so a certificate issued the day before a deadline keeps its longer validity through to its natural expiry. Nothing gets shortened retroactively.
The scope matters as much as the numbers. These are the Baseline Requirements for publicly trusted TLS server certificates, meaning certificates from CAs whose roots ship in the trust stores of Chrome, Safari, Firefox, and Edge. Certificates from a private or internal CA are outside this entirely, so an enterprise PKI issuing certificates for internal services can keep whatever lifetime it likes. Teams running both often assume the rule is universal and then spend an afternoon wondering why their internal certificates were not affected.
The detail nobody mentions: nobody issues 200 days
The ceiling is 200 days. Almost no certificate is issued for 200 days. Certificate authorities issue at 199, because a certificate has to remain valid for its whole stated period and issuing exactly at the limit leaves no room for clock skew or processing time. GlobalSign states plainly that while 200 days is the maximum permitted, the maximum recommended validity is 199 days. DigiCert made the same choice and went further by moving early, applying a 199 day maximum from 24 February 2026, several weeks ahead of the deadline.
That gap is small but it is the kind of thing that breaks automation written against the headline number. If your renewal logic assumes 200 days and your CA issues 199, every calculation drifts by a day, and drift compounds when you chain it across renewals.
There is a second commercial wrinkle worth knowing. Multi-year certificate products still exist and are still sold, but they were already subscriptions rather than single long certificates, since no public CA has issued beyond 398 days since September 2020. Under the new limits, a one-year order simply becomes two 199 day certificates with a free reissue in the middle. You are not buying more certificate. You are buying more reissues, and the operational burden is yours.
Validation reuse is shrinking too, and that is the harder half
The lifetime numbers get the attention, but the parallel change to validation data reuse is the one that affects manual processes more. Domain control validation, the proof that you actually control the name in the certificate, could previously be reused for up to 398 days. From 15 March 2026 that reuse window is 200 days, and by 2029 it drops to 10 days.
The practical consequence is that you cannot simply reissue a certificate against old validation evidence any more. Every renewal increasingly requires fresh proof of domain control, and at a ten day reuse window that proof has to be automated, because no human process runs on that cadence across a real estate of certificates.
Identity validation moved as well. Subject Identity Information, the organisation details that appear in OV and EV certificates, dropped from 825 days of reuse to 398 days on the same date. That does not affect DV certificates, which carry no organisation data, but it does end the set-and-forget pattern for high-assurance certificates in enterprises that had grown used to revalidating roughly every two years.
Some CAs are moving ahead of the schedule voluntarily. Let's Encrypt, which has issued 90 day certificates since it started, published a roadmap to 45 days: an opt-in profile from May 2026, a default of 64 days with a 10 day authorisation reuse window from February 2027, and 45 days with a 7 hour reuse window from February 2028. It also offers a short-lived profile at 160 hours, just over six days, for cases that want it.
What this changes in practice
Three things, in rough order of how quickly they bite.
Manual renewal stops being viable, and the timing of that is worth being precise about. At 200 days it is merely annoying, roughly two renewals a year per certificate. At 100 days it is four. At 47 days it is around eight, which for a modest estate of one hundred certificates is eight hundred renewals a year. There is no version of that which a calendar reminder survives.
Hardcoded renewal intervals become a liability. Automation that renews on a fixed schedule rather than reading the certificate's actual expiry will silently fall out of step as lifetimes shrink. Renewal logic should derive its timing from the certificate itself, and clients supporting ACME Renewal Information can take that timing from the CA directly.
Monitoring changes shape. When certificates lasted a year, a single expiry alert weeks in advance was reasonable, because there was time. Under short lifetimes the buffer between expiring soon and expired collapses, and what you actually need is verification that renewal happened, checked on a routine cycle, rather than a warning that expiry is approaching. For checking what a given host is currently presenting, our guide to SSL checkers covers what the handshake reveals.
Common mistakes in planning for shorter certificate lifetimes
Assuming the rule covers internal certificates. The Baseline Requirements govern publicly trusted CAs only. A private CA can issue whatever lifetime it wants, so an internal estate will not change on its own.
Writing automation against 200 days. Certificate authorities issue at 199 to leave headroom. Logic built on the headline ceiling drifts by a day per cycle, and the drift compounds.
Focusing on lifetime and ignoring validation reuse. The reuse window shrinks in parallel and reaches ten days by 2029, which is what actually ends manual domain validation. It arrives before the 47 day lifetime does.
Hardcoding renewal intervals. A rule that renews every sixty days regardless of the certificate's real expiry breaks quietly as lifetimes shrink. Derive renewal timing from the certificate.
Keeping expiry alerts as the only certificate monitoring. Under short lifetimes, the useful question changes from whether a certificate is about to expire to whether the renewal you expected actually reached the server.
FAQ
How long can an SSL certificate last now?
A publicly trusted TLS certificate can be issued for a maximum of 200 days as of 15 March 2026, though most certificate authorities issue at 199 days to leave headroom. Certificates issued before that date keep their original validity until they expire.
When do 47 day certificates start?
15 March 2029. The intermediate steps are 200 days from 15 March 2026 and 100 days from 15 March 2027, all under CA/Browser Forum ballot SC-081v3.
Does this apply to internal or self-signed certificates?
No. The rules bind publicly trusted certificate authorities in browser root programs. A private or internal CA can issue certificates with any lifetime, although shortening them voluntarily still reduces risk.
What happens to certificates already issued for longer periods?
Nothing. The limits apply at issuance, so a certificate issued under an earlier rule stays valid until its original expiry date. The new maximum applies the next time it is renewed or reissued.
Closing thought
The direction of this is settled and the dates are published, which makes it one of the few infrastructure changes you can plan against precisely. The trap is treating it as a 2029 problem. The 200 day limit is already in force, the validation reuse window is already halved, and the operational habits that survive 47 day certificates are the ones built now, while the cost of getting them wrong is two renewals a year instead of eight.
If you want visibility into what your certificates are actually doing rather than what your automation believes, Odown checks certificates on a daily cycle across unlimited SSL monitors on every plan, and sends expiry alerts at 30, 10, and 7 days ahead by default with custom thresholds available on every tier. As lifetimes fall, that customisation stops being optional, because a 30 day warning on a 47 day certificate fires when the certificate is barely two weeks old.
