Since March 15, 2026, a publicly trusted SSL/TLS certificate can be valid for a maximum of 200 days, down from 398. The limit falls to 100 days on March 15, 2027 and to 47 days on March 15, 2029, under CA/Browser Forum ballot SC-081. Any certificate issued after each date must respect the new ceiling. Certificates issued before a change keep their original validity until they expire.
That is the whole rule. The interesting part is what it does to the way teams work, because a renewal cadence that was comfortably annual is now roughly twice a year, becomes quarterly in 2027, and lands at about every six weeks in 2029. Manual processes that felt fine at one renewal a year stop being viable somewhere around the third step.
How long is an SSL certificate valid in 2026?
A maximum of 200 days, if it was issued on or after March 15, 2026. In practice most certificate authorities issue slightly under the ceiling to leave themselves room, so expect something in the 190 to 200 day range from a commercial CA. Let's Encrypt and other ACME issuers were already well below the limit at 90 days, so nothing changed for teams using them.
| Effective date | Maximum certificate lifetime | Maximum DCV reuse | Renewals per year, per hostname |
|---|---|---|---|
| Until March 14, 2026 | 398 days | 398 days | About 1 |
| March 15, 2026 (in effect now) | 200 days | 200 days | About 2 |
| March 15, 2027 | 100 days | 100 days | About 4 |
| March 15, 2029 | 47 days | 10 days | About 8 |
The change applies to every validation level. Domain Validated, Organization Validated and Extended Validation certificates all sit under the same ceiling, so paying more for OV or EV does not buy a longer life. It also applies to every public CA that participates in the CA/Browser Forum, which is effectively all of them, because a CA that issued longer certificates would be violating the baseline requirements and risking removal from browser root programs.
Why is my SSL certificate only 200 days?
Because the ceiling moved, not because your CA shortchanged you. The reasoning behind SC-081, which Apple proposed and the CA/Browser Forum passed in April 2025, comes down to two things: shortening the window in which a compromised private key stays useful to an attacker, and forcing the industry onto automated issuance.
Certificate revocation has never worked reliably. Browsers do not consistently check revocation lists, and OCSP has been progressively deprecated, so in practice a stolen key stays usable until the certificate expires on its own. Cutting the lifetime cuts that exposure window directly. It is a blunt fix, and it works.
The second motive is less often stated but more consequential. Shorter lifetimes make manual renewal painful enough that teams automate, and automated issuance is more reliable than a human with a calendar reminder. The industry is being pushed toward ACME by making the alternative exhausting.
Do I need to renew my SSL certificate more often now?
Yes, and the multiplier is what catches people out. Going from 398 days to 200 does not add one renewal, it doubles them. By 2029 the same hostname needs roughly eight renewals a year instead of one. If you run 40 hostnames, you go from about 40 renewal events a year to about 320.
Each renewal is an opportunity for the same handful of failures that have always caused certificate outages. The certificate renews but the web server never reloads. The leaf installs without its intermediate chain, which desktop Chrome forgives using a cached intermediate while mobile clients and API consumers fail outright. The origin updates but the CDN edge keeps serving the old one. The main domain gets renewed and the API subdomain does not.
None of those failure modes are new. What is new is that you now get eight chances a year to hit them instead of one, per hostname, forever. That is the real cost of the change, and it is why "we renewed it" and "it is serving correctly" have to become two separate checks.
Does the 200-day limit apply to existing certificates?
No. Certificates issued before March 15, 2026 keep the validity period they were issued with, up to the old 398-day maximum, and stay trusted until their own expiry date. The limit applies at issuance. This is why some teams still have a certificate running with 300-plus days left on it and have not felt the change at all yet. They will at the next renewal.
The same logic applies to the 2027 and 2029 steps. Each one binds certificates issued on or after its date, so the transition is gradual rather than a cliff where everything reissues at once.
What is DCV reuse, and why does it matter?
Domain Control Validation is the step where the CA proves you control the domain, usually by asking you to serve a file or publish a DNS record. Historically that proof could be reused for a long time, so renewals were cheap: the CA already knew you owned the domain and just issued a new certificate.
SC-081 shrinks the reuse window on the same schedule as the lifetime, and then shrinks it much harder at the end. In 2029 a domain validation is good for 10 days while the certificate itself is good for 47. In practice that means revalidation becomes a routine automated event rather than something you do at setup and forget. If your DNS is managed somewhere your automation cannot write to, this is the constraint that will hurt, not the certificate lifetime.
What to do about it now
The work splits into three things, in this order.
1. Automate issuance wherever you can. ACME clients like certbot, acme.sh, Caddy's built-in issuance, or whatever your platform provides handle the 90-day Let's Encrypt cadence without anyone thinking about it, and they will handle 47 days the same way. Managed platforms and load balancers that terminate TLS for you (AWS ACM, Cloudflare, most PaaS providers) already renew automatically. If a hostname is behind one of those, it is largely solved. Teams running their own fleet should fold certificate renewal into the same tooling that handles provisioning and deploys, because a renewal that does not trigger a service reload is not finished.
2. Inventory every hostname that terminates TLS. This is the step people skip and the reason outages happen. The list is almost always longer than the one in your head: the apex and www, api and staging subdomains, the host that receives webhooks, the mail server, the internal admin panel, the vanity domain marketing bought for a campaign three years ago, and anything behind a load balancer that holds its own certificate. Anything not on that list is not being renewed by anybody.
3. Monitor what is actually being served. Automation reports success far more often than it delivers it, because the renewal and the deployment of the renewed certificate are separate steps. The only reliable check is an outside connection that opens a real TLS handshake against each public hostname and reads what comes back. That catches the reload that never happened, the chain that lost its intermediate, and the CDN edge still serving last cycle's certificate. Our guide to what happens when an SSL certificate expires walks through those failure modes in order.
Expiry tracking as an operational discipline is not unique to TLS, incidentally. Any team that has chased a supplier over insurance certificates that quietly lapsed recognizes the pattern exactly: a document with a date on it, an owner who moved on, and nobody watching until something depends on it.
When does SSL certificate validity drop to 47 days?
March 15, 2029. The intermediate step, 100 days, arrives on March 15, 2027, which is the one worth planning for now because it is close. At 100 days a hostname needs renewing roughly every three months, which is the point where quarterly manual renewal across a real fleet stops being realistic and starts producing missed dates.
If you want a single planning rule: whatever you are doing manually today, assume you will be doing it four times as often by 2027 and eight times as often by 2029. Anything that does not survive that multiplication needs replacing before the deadline rather than after the first outage.
The part nobody automates away
Automation solves issuance. It does not solve coverage or verification. A certificate can renew perfectly and still leave you with a broken site, and an ACME client cannot tell you about a hostname it was never pointed at.
That is why the shrinking lifetime story ends at monitoring rather than at automation. Set warnings at 30, 14, 7 and 1 day before expiry, check the served certificate rather than the file on disk, include every subdomain, and send the late warnings somewhere a human will actually see on a Saturday. When lifetimes reach 47 days, a 30-day warning covers most of the certificate's life, and the difference between catching a failed renewal on day one and finding out from a customer on day four is the entire value of the check.