TLS Certificate Lifetimes Just Dropped to 200 Days: Why Every Business Needs to Automate Renewals Now

Every website your company operates, every web application your employees use, every customer portal and payment page, all depend on TLS certificates to work. TLS is the technology behind the padlock icon in your browser. It encrypts traffic between your users and your servers, and it tells browsers that your site is legitimate. When a TLS certificate expires, browsers throw up a full-screen warning that tells visitors your site isn’t safe. Most people leave immediately.

As of March 15, 2026, the maximum lifetime for a new TLS certificate dropped from 398 days to 200 days. That means certificates your IT team used to renew once a year now need to be renewed every six and a half months. And this is just the first step in a deliberate, accelerating timeline set by the CA/Browser Forum (the industry body that governs certificate standards). By March 2027, the maximum drops to 100 days. By March 2029, it falls to just 47 days.

If your business handles certificate renewals manually, this timeline will break your process. Probably sooner than you think.

What Changed and Why

The CA/Browser Forum voted unanimously for SC-081, a ballot that progressively shortens TLS certificate lifetimes over the next three years. The reasoning is straightforward: shorter certificate lifetimes reduce the window of exposure if a certificate’s private key is compromised. They also force organizations to keep their certificate infrastructure current rather than letting it decay between annual renewals.

Here is the timeline:

• March 15, 2026 (now in effect): Maximum TLS certificate validity is 200 days
• March 15, 2027: Maximum drops to 100 days
• March 15, 2029: Maximum drops to 47 days

Any certificate issued before March 15, 2026, at the old 398-day maximum is still valid until its original expiration date. But every new certificate your organization purchases or renews from this point forward is capped at 200 days.

This affects every business with a web presence. If you run a company website, a customer portal, an e-commerce platform, a client-facing application, or even internal tools that use HTTPS, you have certificates that now expire faster.

The Real Cost of an Expired Certificate

Certificate expirations are not minor inconveniences. They are outages that directly affect revenue, customer trust, and operations.

When a TLS certificate expires, here is what happens. Browsers display a warning page that says “Your connection is not private” or “This site can’t provide a secure connection.” Most visitors won’t click through the warning. They’ll close the tab and go to a competitor. If the expired certificate is on an internal application, your employees can’t do their work until someone fixes it. If it’s on an API endpoint, integrations with vendors and partners break silently.

The numbers are bad. According to research from Venafi and the Ponemon Institute, 72% of organizations experienced at least one certificate-related outage in the past year. The average cost of application downtime runs roughly $9,000 per minute, and these outages lasted an average of four hours each. For a small business, even a fraction of that figure represents a painful hit.

The examples you’ve probably heard about are the big ones. Equifax’s failure to renew an SSL certificate contributed to a delayed discovery of their 2017 breach. Microsoft Teams went down for hours in 2020 because of a forgotten certificate. Spotify, LinkedIn, and the UK Conservative Party have all had public certificate expirations. These are organizations with massive IT teams and dedicated security operations. If they can miss a renewal, a 50-person company running certificates on spreadsheets certainly can.

Why Manual Certificate Tracking Is Already Broken

Most small and mid-sized businesses manage certificates the same way: someone in IT buys a certificate, installs it, sets a calendar reminder for 30 days before expiration, and hopes they’re still around when that reminder fires. This process has always been fragile. The new timeline makes it unsustainable.

The math tells the story. Under the old 398-day maximum, a company with 10 certificates renewed them roughly 10 times per year. Under the new 200-day maximum, that same company renews 20 times per year. When the lifetime drops to 100 days in 2027, it becomes 40 renewals per year. At 47 days in 2029, it jumps to approximately 80 renewals per year. That is an 8x increase in renewal workload compared to last year.

Now consider that most businesses don’t have 10 certificates. They have 10 that they know about. The actual number, once you count subdomains, internal tools, staging environments, API endpoints, and third-party services, is usually much higher. An honest audit often uncovers 30 to 50 or more certificates scattered across different servers, cloud platforms, and CDN providers.

Calendar reminders don’t scale. A renewal that someone forgets, a certificate on a server that nobody remembers exists, an employee who leaves and takes the institutional knowledge about where certificates live with them: any of these will cause an outage. And with renewals happening every six months (soon every three months, then every six weeks), each certificate is another ticking clock.

Multi-cloud environments make it worse. If your business uses Azure for some workloads, AWS for others, and a traditional hosting provider for your main website, certificates live in three different management consoles with three different renewal processes. Each one is a separate opportunity for something to slip through the cracks.

How to Get Your Certificate House in Order

This is a solvable problem, but it requires action now, before the 100-day deadline hits in March 2027 and the workload doubles again.

Step 1: Inventory Every Certificate You Own

You cannot manage what you cannot see. Start by building a complete list of every TLS certificate in your environment. Include:

• Public websites and subdomains (www, blog, shop, portal, support, etc.)
• Web applications your employees or customers access
• API endpoints that connect to vendors, partners, or internal systems
• Internal tools that use HTTPS (intranet, documentation, dashboards)
• Email infrastructure (certificates on mail servers, if applicable)
• Cloud services (Azure App Services, AWS Certificate Manager, load balancers, CDNs)

For each certificate, record the domain name, the issuing Certificate Authority, the expiration date, and the server or service where it’s installed.

If your IT team doesn’t know where all your certificates are, that alone is a finding worth addressing. Unknown certificates are the ones that expire without warning.

Step 2: Identify Which Certificates Expire First

Sort your inventory by expiration date. Any certificate expiring in the next 90 days is your immediate priority. Any certificate that was issued at the old 398-day maximum will expire before October 2026 and will need to be renewed at the new 200-day maximum.

This step often reveals surprises: certificates on forgotten staging servers, wildcard certificates that cover dozens of subdomains, or certificates tied to services that a former employee set up.

Step 3: Implement Automated Certificate Management

This is the critical step. Manual renewal might carry you through the 200-day era if you’re diligent. It will not survive the transition to 100-day certificates in 2027, and it absolutely will not work at 47 days in 2029. Automation is not optional; it’s a requirement the industry is forcing on every organization.

The good news is that the tools exist and they work well. Certificate Authorities like Let’s Encrypt, DigiCert, and Sectigo support the ACME protocol, which allows certificates to be renewed automatically without human intervention. Your IT provider should be able to configure automated renewal for every certificate in your environment so that renewals happen in the background, well before expiration, without anyone needing to click a button or remember a date.

For businesses running on Azure, Azure Key Vault can automate certificate lifecycle management for cloud workloads. AWS Certificate Manager provides similar functionality for AWS-hosted resources.

The specific tools matter less than the outcome: every certificate in your environment should renew itself automatically, and your IT team should receive alerts if any renewal fails. If a renewal works, nobody needs to know. If one fails, your team needs to know immediately.

Step 4: Set Up Monitoring and Alerting

Automation handles the renewals. Monitoring catches the exceptions. Even with automated renewal in place, things can go wrong: a DNS change breaks validation, a server migration orphans a certificate, a provider changes their API.

Your network monitoring system should track certificate expiration dates across your environment and alert your IT team when any certificate is within 30 days of expiration. This acts as a safety net behind the automation. If the automated renewal worked, the alert never fires. If something went wrong, your team gets advance warning instead of a 2 AM outage.

Questions to Ask Your IT Provider

If you work with a managed IT provider, these are the questions you should be asking this week:

1. Do you have a complete inventory of all our TLS certificates? If the answer is “we think so” or “most of them,” that’s not good enough. You need a definitive list.
2. Are our certificate renewals automated? If renewals depend on someone remembering to do them, you’re exposed.
3. What happens when a renewal fails? There should be an automated alert and a documented process for manual intervention.
4. Are we ready for 100-day certificates in March 2027? The 200-day change is manageable with some effort. The 100-day change is where unprepared organizations will start breaking.
5. Who is responsible for certificates across all our environments? Cloud platforms, web hosts, CDN providers, and internal servers all need certificate management. If responsibility is scattered, gaps are inevitable.

If your IT provider can answer all five confidently and back it up with documentation, you’re in good shape. If they can’t, this is a conversation to have before your next certificate expires.

The 2027 Cliff Is the Real Deadline

The 200-day maximum that took effect in March is manageable. It doubles your renewal workload, but it’s still a cadence most organizations can handle with some process improvements.

The 100-day maximum arriving in March 2027 is where businesses without automation will start having outages. Renewing certificates every three months across a multi-server, multi-cloud environment is genuinely difficult to do manually. And the 47-day maximum in 2029 makes it impossible.

The organizations that will sail through these transitions are the ones that invested in automation early. The ones that waited will be scrambling to fix certificate outages while simultaneously trying to implement the automation they should have set up a year earlier.

You have roughly 11 months before the 100-day deadline. That is enough time to audit your certificates, implement automation, test it, and build confidence that it works. It is not enough time to procrastinate and still avoid problems.

If your IT team is already stretched thin, a managed IT partner can handle certificate lifecycle management as part of broader infrastructure monitoring. Certificate management is exactly the kind of recurring, detail-oriented operational work that benefits from dedicated tooling and process, rather than relying on individual memory and calendar reminders.

For a deeper look at how automated management keeps your infrastructure current and reduces the operational burden on your team, see our guide on automated patch management with ConnectWise.