Compliance
IT Infrastructure

Preventing Downtime From Expired Certificates in 2026

Preventing Downtime from Expired Certificates

It’s 2026. TLS is decades old, certificate authorities are free, and every major platform has automated renewal tooling. And yet a certificate quietly expiring at 2 a.m. is still one of the most common ways mature engineering teams take themselves offline. Preventing downtime from expired certificates isn’t a solved problem — it’s a moving target, and the target just got harder to hit: the CA/Browser Forum’s phased rollout of shorter certificate lifespans means the renewal clock that used to give teams a year of slack now gives them weeks, and soon days.

This isn’t a hypothetical risk for small shops with no ops maturity. Microsoft Teams, Spotify, Ericsson’s telecom core, and Epic Games have all had public, multi-hour outages traced back to one expired certificate. This guide covers why the failure mode persists even at well-resourced companies, what changes with 2026’s shorter certificate lifetimes, and the concrete playbook for preventing downtime from expired certificates before it becomes an incident review.

What Actually Happens When a Certificate Expires

A TLS certificate isn’t a soft warning label — it’s a hard boundary condition. The moment the clock passes its “not valid after” timestamp, every client that checks it (browsers, mobile apps, internal services, IoT devices, API clients) is supposed to refuse the connection outright. There’s no grace period built into the protocol. A site that was serving traffic perfectly one second can be fully unreachable the next, with no code deploy, no infrastructure change, and no alert from any system that wasn’t specifically watching the certificate’s expiry date.

The failure also isn’t confined to the public-facing website most people picture. Expired certificates break service-to-service calls inside a mesh, API gateways, database connections that enforce TLS, internal admin tools, mobile app backends, and IoT device check-ins — often simultaneously, because organizations frequently reuse one wildcard or SAN certificate across dozens of internal services. That’s exactly what happened at Epic Games, where a single expired wildcard certificate took down authentication across hundreds of backend services at once, turning a routine renewal miss into a company-wide, multi-hour incident.

Why Certificate Outages Still Happen in 2026

If this were purely a tooling gap, it would have been solved years ago — free automated issuance via ACME has existed since 2015. The real cause is organizational: certificates sprawl across teams, vendors, and legacy systems faster than any single owner can track, and the systems most likely to be forgotten (internal tools, network appliances, IoT fleets, third-party integrations) are exactly the ones without an obvious “someone will notice” safety net. Well-run SRE practices close that gap, but plenty of otherwise mature organizations still don’t have expiry alerting wired into every certificate they own. Recent, well-documented incidents make the pattern hard to dismiss as bad luck:

CompanyWhat BrokeImpact
Microsoft Teams (Feb 2020)An internal authentication certificate expired and wasn’t renewed in time~3 hours of global downtime; Microsoft’s own post-incident review cited monitoring gaps on internal certificate infrastructure
Ericsson / O2 UK (Dec 2018)An expired software certificate inside core telecom network equipmentO2’s 4G network in the UK was down for nearly 24 hours, affecting roughly 32 million customers; Ericsson paid O2 an estimated $132.8M in compensation
SpotifyAn expired SSL certificate on backend API infrastructureDesktop and mobile players stopped working and some web API calls failed for a period of time
Equifax (2017)An expired certificate on a network monitoring appliance went unnoticed for 19 monthsThe blind monitoring tool let attackers exfiltrate data from 48 databases undetected — a contributing factor in the breach of ~147 million people’s records
Epic GamesAn expired wildcard certificate shared across hundreds of backend servicesMulti-hour outage across Fortnite and related services; recovery took roughly 5.5 hours
Why Certificate Outages Still Happen in 2026

Notice what these have in common: none of them are small or under-resourced organizations. Every one had a security or SRE function. The failure wasn’t a lack of capability — it was a certificate that existed outside whatever inventory or monitoring process the team assumed covered “everything.”

The Real Cost of an Expired-Certificate Outage

Certificate outages aren’t rare edge cases — they’re a routine, recurring line item in enterprise incident logs. Keyfactor’s 2026 State of Machine Identity research found that over 70% of organizations experienced at least one certificate-related outage in the past year, that it typically takes more than four hours to identify, remediate, and recover from one, and that a single incident commonly pulls in 11 to 20 people across security, infrastructure, and application teams before it’s resolved. Nearly two-thirds of respondents expect these outages to keep happening over the next two years — not because the fix is unknown, but because certificate inventories keep growing faster than governance does; the average enterprise now manages over 250,000 machine identities, up from roughly 150,000 just two years ago.

The numbers that matter to leadership: more than 70% of organizations had a certificate-related outage in the past 12 months, the average incident takes 4+ hours and a double-digit headcount to resolve, and nearly two-thirds of security leaders expect the problem to persist without a change in process — not tooling.

The knock-on effects compound quickly. A public-facing outage means lost transactions and support volume; an internal outage on something like a certificate feeding a monitoring pipeline (as at Equifax) can quietly disable the very system meant to catch a breach in progress. Either way, the incident review almost always ends with the same finding: the certificate wasn’t unknown, it just wasn’t anyone’s clearly assigned job to renew.

The 47-Day Certificate Era: Why Manual Renewal Just Broke

In April 2025, the CA/Browser Forum — the industry body that sets the baseline requirements every public certificate authority must follow — voted to phase out today’s roughly 398-day maximum certificate lifetime in favor of a much shorter one. DigiCert’s rollout summary lays out the schedule plainly: the ceiling drops to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029. The goal is legitimate — shorter-lived certificates shrink the damage window if a private key is ever compromised, and reduce reliance on slow, unreliable revocation checking. But the side effect is that any process built around “someone checks the spreadsheet a couple of times a year” stops working long before 2029 arrives.

Effective DateMax Certificate LifetimeWhat It Means Operationally
Today~398 daysAnnual renewal cadence; manual tracking is slow but survivable
March 15, 2026200 daysRoughly twice-yearly renewal; manual processes start missing certificates that used to fall on a predictable annual calendar entry
March 15, 2027100 daysQuarterly renewal cadence across every certificate in inventory; spreadsheet tracking becomes a full-time job at any real scale
March 15, 202947 daysMonthly-plus renewal cycles; domain validation must also be repeated roughly every 10 days — automation stops being optional
The 47-Day Certificate Era: Why Manual Renewal Just Broke

None of this is optional or vendor-specific — it applies to every publicly trusted certificate, regardless of which CA issues it. Teams still relying on a manual renewal checklist for their externally facing certificates have a hard deadline to fix that, not an abstract best-practice recommendation to eventually get around to.

A Practical Playbook for Preventing Downtime From Expired Certificates

Preventing downtime from expired certificates doesn’t require a large team or an expensive platform on day one — it requires closing the two gaps that cause every incident in the table above: an incomplete inventory, and alerting that isn’t tied to an owner who’s actually accountable for acting on it.

  1. Build a complete certificate inventory first. Scan every network range, load balancer, API gateway, and internal service for TLS endpoints — don’t rely on a list of “known” certificates, since the ones that cause outages are almost always the ones nobody remembered existed. Include internal-only and appliance certificates, not just public-facing ones; Equifax’s breach traces back to exactly this blind spot.
  2. Assign a named owner to every certificate, not just a team. “DevOps owns it” is how a certificate sits unrenewed for months — a specific person or on-call rotation needs to be accountable, the same way application monitoring alerts route to a specific responder rather than a general channel.
  3. Wire expiry alerts to more than one threshold. A single 30-day warning is easy to miss during a busy sprint. Layer alerts at 60, 30, 14, and 7 days, escalating severity and audience each time, so a missed first alert isn’t the only thing standing between the team and an outage.
  4. Automate renewal wherever the certificate authority supports it. ACME-based automation (via tools like Certbot, cert-manager for Kubernetes, or a commercial CLM platform) removes the human step entirely for the majority of certificates — this is the single highest-leverage fix available, and it’s the only approach that scales cleanly as lifetimes shrink toward 47 days.
  5. Treat certificate renewal like a deploy, not a background task. Verify the renewed certificate actually loads correctly, that dependent services reconnect cleanly, and that no client-side pinning or caching breaks the rollout — a certificate that renews on schedule but doesn’t deploy correctly causes the same outage as one that expired outright.
  6. Build a documented emergency-reissue path. Even with automation, something will occasionally still expire. A tested runbook for emergency reissuance and deployment turns a multi-hour, all-hands incident into a 15-minute fix — this is the same operational discipline behind a solid disaster recovery plan applied specifically to certificate failures.
A Practical Playbook for Preventing Downtime From Expired Certificates

Manual Tracking vs. Automated Renewal: Choosing Your Approach

Most organizations don’t move straight from a spreadsheet to full automation — they land somewhere on a spectrum, and where a given certificate sits usually depends on how disruptive an outage on that specific service would be. It’s worth being deliberate about which tier each certificate belongs in rather than defaulting to whatever the last engineer who touched it happened to set up.

  • Spreadsheet or calendar reminders — the lowest-effort option and the one most outages in the table above trace back to; viable only for a handful of low-risk, rarely-touched certificates, and increasingly unviable as 2026’s 200-day ceiling compresses the renewal calendar.
  • Centralized monitoring with expiry alerts — a real step up: every certificate is inventoried and alerts fire before expiry, but a human still has to act on each one, which means the failure mode shifts from “nobody knew” to “the ticket sat in a backlog.”
  • ACME-based automated renewal — the default for anything that can support it (most public web and API certificates); renewal happens without human action, which is the only approach that scales cleanly as certificate lifetimes shrink toward 47 days by 2029.
  • Full certificate lifecycle management (CLM) platform — adds centralized policy, audit trails, and cross-team visibility on top of automation; worth the investment once an organization is managing certificates across multiple clouds, business units, or compliance regimes.

Common Mistakes That Cause Certificate Outages

A small set of recurring mistakes shows up across nearly every certificate-related outage postmortem, including the well-documented incidents above:

  • Treating internal certificates as lower priority than public ones. Equifax’s breach and countless smaller internal outages trace back to an appliance or monitoring-tool certificate nobody was watching because it wasn’t customer-facing.
  • Relying on a single alert with no escalation. One 30-day email that lands in an inbox during a busy week is not a monitoring strategy — it’s a single point of failure with a human in the loop.
  • Sharing one wildcard certificate across too many services. It reduces renewal overhead, but it also means one missed renewal takes down everything that certificate touches at once, as happened at Epic Games.
  • Renewing the certificate but not verifying the deploy. A certificate that renews correctly on the CA side but fails to load on the actual service produces the same outage as one that expired — verification has to be part of the renewal step, not assumed.
  • Not accounting for certificates outside the standard inventory. IoT devices, third-party vendor integrations, and legacy network appliances routinely fall outside the systems that scan for “our” certificates, exactly where GitLab’s own public incident tracker documents a Gitter SSL certificate renewal that required manual, out-of-band intervention.

Still tracking certificate renewals in a spreadsheet?

Gart Solutions builds the monitoring and automation layer that catches expiring certificates weeks before they become an outage — cert inventory, expiry alerting, ACME-based renewal automation, and the SRE processes to keep it that way as certificate lifetimes keep shrinking.

10+ Years in DevOps & Cloud
50+ Enterprise clients secured
4.9★ Clutch rating
IT Monitoring Services SRE & Reliability Engineering DevSecOps Disaster Recovery (DRaaS) Infrastructure Audit
Talk to an Infrastructure Expert →
Fedir Kompaniiets

Fedir Kompaniiets

Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant

Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the “tech madness” through expert DevOps and Cloud managed services. Connect on LinkedIn.

FAQ

What happens when an SSL/TLS certificate expires?

Clients — browsers, mobile apps, internal services, and APIs — are designed to refuse connections to a server presenting an expired certificate. There's no grace period: a service that was working normally becomes unreachable the moment the certificate's validity window ends, often breaking backend service-to-service calls and API integrations in addition to any public-facing site.

Who is responsible for preventing downtime from expired certificates?

In most organizations, accountability should sit with a named owner or on-call rotation within SRE, platform engineering, or security — not a general "DevOps team" label. Keyfactor's 2026 research found certificate outages typically pull in 11 to 20 people to resolve once they happen, which is a strong sign that ownership wasn't clearly assigned before the incident.

Where do certificate outages most commonly originate?

Outside the "obvious" public-facing website, most often: internal service-to-service certificates, network monitoring or security appliances, third-party vendor integrations, IoT device fleets, and shared wildcard certificates covering many backend services at once. These are the certificates least likely to be included in a standard inventory or dashboard.

When do TLS certificate lifetimes get shorter under the new CA/Browser Forum rules?

The maximum lifetime drops to 200 days on March 15, 2026, to 100 days on March 15, 2027, and to 47 days on March 15, 2029. Each reduction applies to every publicly trusted certificate industry-wide, regardless of which certificate authority issues it.

Why do certificate outages still happen at well-resourced companies?

Because the failure is organizational, not technical — certificates sprawl across teams, vendors, and legacy systems faster than any manual process can track. Microsoft, Ericsson/O2, Spotify, and Equifax all had mature security or ops functions when their outages happened; in each case, the certificate that expired existed outside whatever inventory or alerting process the team assumed covered everything.

How do you prevent downtime from expired certificates?

Build a complete certificate inventory (including internal and appliance certificates), assign a named owner to each one, layer expiry alerts at multiple thresholds (60/30/14/7 days), automate renewal via ACME wherever the CA supports it, verify that renewed certificates actually deploy correctly, and maintain a tested emergency-reissue runbook for the exceptions that slip through.

How much does a certificate-related outage typically cost?

Keyfactor's 2026 research found that certificate outages take an average of 4+ hours to detect and resolve and typically involve 11 to 20 staff across teams. Combined with general enterprise downtime costs, the total business impact — lost revenue, support load, and incident-response hours — routinely runs into six figures for a single incident, even before counting reputational damage.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy