The SSL certificate lifetime changes are already here: as of October 2026, the longest public SSL/TLS certificate you can buy caps out at 200 days, and in practice you'll be issued 199. In March 2027 that drops to 100 days, and in March 2029 to 47. If someone at your company renews certificates by hand once a year, that job is about to happen four times a year, then eight.
The 200-day cap took effect March 15, 2026, so the change isn't coming: you're living in the first phase of it.
Here's the schedule, what it breaks, and what it doesn't touch.
What are the certificate lifetime changes, and when do they take effect?
The CA/Browser Forum, the body where certificate authorities and browser makers set the rules browsers enforce, passed ballot SC-081v3 in April 2025. It phases certificate lifetimes down in three steps.
| Effective | Max certificate validity | Domain validation reuse |
|---|---|---|
| Until March 14, 2026 | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
Those dates and figures come from the CA/Browser Forum Baseline Requirements and are mirrored in DigiCert's summary: "As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days," dropping to 100 in 2027 and 47 in 2029.
One practical wrinkle. Certificate authorities issue a day under the cap to avoid breaching it, so DigiCert moved to 199-day certificates on February 24, 2026. Buy a certificate today and you get roughly 199 days, not 200.
The 2029 column is the one to look at
Everyone fixates on 47 days. The harder number is the 10-day domain validation reuse period arriving the same day.
Today you prove you control a domain, and that proof stays good for 200 days across reissues. From March 2029 that proof expires in 10 days. You won't just be reissuing certificates constantly. You'll be re-proving domain control constantly. No human process survives that.
Why did the CA/Browser Forum do this?
Mostly because certificate revocation has never worked. When a certificate needs to be pulled early, browsers are supposed to check revocation lists, and in practice that check is unreliable. A short lifetime means a bad certificate stops working on its own.
The ballot itself makes that argument directly, describing shorter validity as giving "firm protection to users, independent of certificate status services." It also argues that certificate data goes stale: "The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality."
The vote is worth knowing about if you're hoping this gets rolled back. It passed with zero votes against: 25 certificate authorities in favor with 5 abstentions, and all four browser makers in favor. Apple wrote it. Google, Mozilla and Sectigo endorsed it.
Nobody is coming to save your annual renewal process.
What actually breaks
Websites are mostly fine. Any modern hosting platform, CDN or web server running ACME renews automatically and has for years.
The problem is everywhere a person pastes a certificate into a web admin panel once a year and writes the date on a calendar. In a typical small business that's:
- Firewalls and VPN appliances, including the SSL VPN portal your remote staff hits
- Load balancers and reverse proxies
- Mail gateways and on-premises mail servers
- Remote Desktop gateways
- Network-attached storage, cameras, door controllers and printers with HTTPS admin pages
- Line-of-business applications running on a server in your closet
Each of those is now on a roughly 199-day clock, dropping to about 99 in March 2027. Miss one and the failure is loud: users get a browser warning, the VPN stops connecting, or mail stops flowing.
That list is our own assessment of where the work lands, not a published finding. The dates and caps above are the sourced part.
What this does not affect
Two exemptions save a lot of unnecessary work, and plenty of businesses miss both.
Internal certificates from your own CA. The ballot governs publicly trusted certificates. If an internal application uses a certificate issued by your own Active Directory Certificate Services or another private CA, none of this applies to it. You set that policy.
Code signing certificates. Those live under a separate CA/Browser Forum working group and a separate document. SC-081v3 amends the TLS requirements only.
How to get ahead of it
The work is mostly inventory, and it's better done now than during an outage.
- Find every public certificate you own. Not just websites, but every appliance, gateway and admin panel with HTTPS on a name that resolves publicly. This belongs in the same place as your hardware and software inventory, and it's common to turn up one or two nobody remembered. Our managed network services keep that kind of equipment record for firewalls, switches and access points, and certificates belong on it.
- Write down who renews each one and how. If the answer is a person and a calendar reminder, flag it.
- Turn on ACME wherever the device supports it. ACME is the protocol that renews certificates automatically, with no human involved. Firewall, load balancer and mail platform vendors have been shipping support for it precisely because of this schedule, so check your version before assuming it isn't there.
- Use DNS-01 validation where you can. This is the answer to the 10-day problem: ACME re-proves domain control on its own, and a DNS-01 challenge delegated with a CNAME keeps working for systems that can't expose an HTTP endpoint to the internet.
- Move what can't automate to a private CA, where you control the lifetime, or put it behind a reverse proxy that does automate.
- Monitor expiry dates with alerting that reaches someone who's still employed. A certificate monitor is cheap insurance against a Monday morning outage.
If you're already using ACME, you're nearly done. Let's Encrypt's default certificate has been 90 days for years, stricter than today's 200-day cap, and it is getting shorter on its own schedule: 64 days by default from February 10, 2027, then 45 days in February 2028. Let's Encrypt's advice is to renew at about two-thirds of a certificate's lifetime, or let the ACME client follow the CA's renewal hints, so check that nothing renews on a hard-coded 60-day timer. It also now offers a six-day option: certificates "valid for 160 hours, just over six days," which reached general availability in January 2026.
That's the real lesson in this schedule. Automated renewal makes the number irrelevant. Manual renewal makes it worse every two years.
NIST reached the same conclusion before the ballot existed. SP 1800-16 is a whole practice guide on automating TLS certificate management to prevent and recover from certificate-related incidents.
Frequently asked questions
How long are SSL certificates valid in 2026?
The maximum is 200 days for certificates issued on or after March 15, 2026. In practice most certificate authorities issue at 199 days to stay safely under the cap. The limit drops to 100 days on March 15, 2027, and to 47 days on March 15, 2029, under CA/Browser Forum ballot SC-081v3.
Why are SSL certificate lifetimes getting shorter?
Certificate revocation is unreliable in browsers, so a compromised or misissued certificate can stay usable longer than it should. Short lifetimes make expiry do the job revocation can't. The CA/Browser Forum ballot also cites keeping certificate data accurate and enabling faster transitions between cryptographic algorithms.
Does the 47-day rule apply to internal certificates?
No. The Baseline Requirements govern publicly trusted certificates from public certificate authorities. Certificates issued by your own internal or private CA, such as Active Directory Certificate Services, are not covered, and you set their lifetime. Code signing certificates are also governed separately and are unaffected.
What is ACME and do I need it?
ACME is the protocol that lets a server request and renew certificates automatically, with no human involved. If you have systems where someone manually installs a certificate each year, you need it, or you need to move that system behind something that has it. At a 47-day lifetime with 10-day validation reuse, manual renewal stops being workable.
How often will we renew certificates after these changes?
Roughly twice a year per certificate today, about four times a year once the 100-day cap arrives on March 15, 2027, and about eight times a year after March 15, 2029. In practice it is more often, because renewals happen before the cap, not on the last day. That is why the answer is automation rather than a bigger calendar.
Will shorter certificate lifetimes cost more?
The certificates themselves don't have to: ACME certificates from Let's Encrypt are free, and the shorter cap applies to every public certificate authority. The cost is labor and equipment. Each manual renewal takes someone's time, the count doubles in 2027 and again in 2029, and a device that can't automate needs a reverse proxy, a private certificate or a replacement at its next refresh. Under a NetSys managed agreement, ongoing upkeep is part of the flat monthly fee per user, and hardware replacement is scoped as its own project, so you know which is which before work starts.
Is anything else changing with public certificates?
Yes. Public TLS certificates are losing their client authentication use. Let's Encrypt stopped offering it on July 8, 2026, and the Chrome Root Program requires certificates issued on or after March 15, 2027 to be for server authentication only. If a firewall, mail relay or VPN uses a public certificate to prove its own identity to another system, move that job to a private CA before its next renewal.
What happens if a certificate expires?
Visitors get a full-page browser security warning, and most will leave. Anything that depends on the certificate breaks outright: VPN clients fail to connect, mail servers refuse to relay, and integrations return TLS errors. Expired certificates have taken down services at national scale: an expired certificate on Ericsson equipment knocked out mobile data for millions of O2 and SoftBank customers in 2018. It isn't only a small-business problem.
Sources and further reading
- CA/Browser Forum: Ballot SC-081v3. The schedule, the rationale, and the vote record. Accessed October 2026.
- CA/Browser Forum: Baseline Requirements. The relevant dates table for validity and data reuse periods. Accessed September 2026.
- DigiCert: TLS certificate lifetimes will officially reduce to 47 days. The step-down dates in plain language. Accessed September 2026.
- Let's Encrypt: Six-day and IP address certificates generally available. The 160-hour certificate profile. Published January 2026.
- Let's Encrypt: 64-day certificate lifetimes coming February 2027. The default lifetime schedule and renewal advice. Published October 7, 2026.
- Chrome Root Program Policy, version 1.8. The server-authentication-only rule for certificates issued from March 15, 2027. Accessed October 2026.
- NIST SP 1800-16: Securing Web Transactions, TLS Server Certificate Management. Automation practice guide. Published 2020.
If you don't have a certificate inventory, that's the first deliverable, and it usually takes an afternoon. Book a call with an engineer and we'll build the list with you and flag which devices can automate today. It pairs well with the rest of our managed IT work.
By Joe Laboy, a systems engineer at The NetSys Group, which has delivered managed IT, cybersecurity and cloud services from Brooklyn since 1998. Our engineers hold degrees in electrical and computer engineering. We work on-site across New York City, Long Island, Westchester, the Hudson Valley, North Jersey and Fairfield County, CT, with remote managed IT nationwide.
Discuss managed it services for your business.
Tell us about your current systems, the result you need and your timeline. We will discuss the work, responsibilities and pricing before you decide on an engagement.