Ask any senior engineer whether expired certificates still cause outages in 2026 and the answer is a tired yes. Ask them how often, and the answer collapses into shrugs. The data closes that gap. Keyfactor's 2024 PKI & Digital Trust Report — a survey of roughly 1,200 IT and security leaders across enterprises with 500+ employees — puts the certificate-related outage rate at 86% in the past twelve months ( Keyfactor, 2024, retrieved 2026-09-03).
That is not the percentage of organisations that have ever had a cert outage. That is the percentage that had one in the last year. And the CA/Browser Forum has just voted to compress the renewal cadence 8× by 2029. If the outage rate is 86% at today's cadence, the interesting question is what happens at eight times the cadence in three years.
The headline: 86% had an outage
Keyfactor's 2024 report is the largest recurring PKI-operations survey in the industry, run annually since 2019. The 2024 cut published four numbers that matter:
- 86% of organisations reported at least one certificate-related outage in the past 12 months.
- 57% reported outages that caused material customer or business impact — not just internal service degradation.
- 77% agreed that shrinking certificate lifetimes will make their outage risk worse, not better, without new tooling.
- Only 32% reported having a formal certificate lifecycle management (CLM) tool in production.
The gap between the first and last numbers is the whole story. 86% outage rate. 32% CLM coverage. Nearly two-thirds of enterprises are running certificate operations on tickets, calendar reminders, and one engineer's memory — and the outage data shows exactly what that looks like at scale.
The cadence data: quarterly, monthly, weekly
The single-year-outage-rate number hides the more revealing distribution. Inside the 86%:
- Roughly 31% reported at least quarterly certificate-related outages.
- Roughly 10% reported weekly or more frequent outages.
- The remaining share reported one or two isolated incidents over the year.
Weekly cert outages sound absurd until you look at what they measure. A large enterprise with 50,000+ machine identities across cloud, on-prem, and vendor SaaS surfaces will have several near-misses a week — a wrong intermediate served briefly, a service mesh sidecar rejecting a rotated cert, a Kubernetes ingress controller failing to reload after a cert-manager renewal. Every one of those counts under Keyfactor's definition. Every one of those is invisible to a monitor pointed at the public apex.
Why the outage rate is that high
Four causes show up consistently across Keyfactor's five most recent annual reports:
- Ownership is diffuse. A single enterprise has certificates owned by web team, mail team, DevOps, platform, identity, and a long tail of vendor SaaS. There is rarely one person responsible for the full inventory.
- Inventory is incomplete. Certificate Transparency covers publicly-trusted certs only. Internal PKI, self-signed, vendor firmware, and appliance management planes are invisible to CT. Most organisations discover them only when they fail.
- Renewal automation is partial. ACME (Let's Encrypt, ACM) covers the well-instrumented portion. The rest is a mix of hand-rolled scripts, vendor consoles, and manual renewal windows. Any partial automation increases the odds of the automated half breaking silently while the manual half is watched.
- Monitoring is at the wrong granularity. Watching the apex certificate is table stakes. Watching every subdomain, every mTLS client cert, every management-plane cert, every code-signing cert is a different problem — and the one where the outages come from.
See the SSL certificate primer and the SSL/TLS glossary entry for the underlying protocol mechanics.
The CLM adoption gap — 32%
Certificate lifecycle management (CLM) tools automate discovery, issuance, renewal, and revocation across the estate. Products in this category — DigiCert Trust Lifecycle Manager, Venafi TLS Protect, AppViewX, Keyfactor Command, Sectigo Certificate Manager — are the enterprise standard for solving the problem the 86% number describes.
Only 32% of Keyfactor's 2024 respondents reported running one in production ( Keyfactor 2024, retrieved 2026-09-03). The remaining 68% split roughly into:
- Evaluating a tool but not yet in production (about a third of the non-adopters).
- Running homegrown automation stitched from cert-manager, custom scripts, and one Jira dashboard (the majority).
- Running fully manual renewal cycles on calendar reminders (a smaller but non-trivial share, mostly at mid-market and below).
The homegrown-automation cohort is the interesting one. Their outage rate in Keyfactor's data is not meaningfully lower than the fully-manual cohort's, because the homegrown solutions usually cover only web-facing TLS on the apex. Everything else — mTLS, code-signing, management planes, vendor-fronted subdomains — falls into the same gap.
The 47-day collision course
On April 11, 2025 the CA/Browser Forum passed Ballot SC-081v3 (retrieved 2026-09-03). The ballot phases the maximum validity of publicly-trusted TLS certificates down over four years:
- 2025 — status quo, 398 days (13 months)
- March 15, 2026 — 200 days maximum
- March 15, 2027 — 100 days maximum
- March 15, 2028 — 47 days maximum (proposal iteration)
- March 15, 2029 — 47 days maximum, in force
DigiCert, Sectigo, GlobalSign and every other public CA has publicly aligned with the ballot (retrieved 2026-09-03 from vendor announcements). The exact intermediate dates vary slightly by ballot iteration but the endpoint is set: 47 days by March 2029.
The operational math: 8× renewal cadence
Today's 398-day cert renews once a year. A 47-day cert renews roughly 7.8× per year. Every certificate in the estate hits its renewal path eight times more often. Every hand- rolled script, every manual approval step, every calendar reminder, every vendor console that requires a login — eight times the touch points, eight times the failure surface.
Extrapolating Keyfactor's 2024 outage rate is not straightforward, but the direction is unambiguous. In their own 2024 report, 77% of respondents said shrinking lifetimes will increase their outage risk unless they adopt CLM. The math:
- Manual estate at 86% outage rate today. Cadence multiplied by 8. Failure surface multiplied by 8. Outage rate cannot climb above 100%, but incident volume can — and does.
- Homegrown-automation estate at similar outage rate today. Same multiplier applies to every surface the homegrown tool doesn't cover, which is most of them.
- Full-CLM estate. Outage rate materially lower in Keyfactor's data even at today's cadence. Under 47-day certs, the delta widens.
In three years the difference between running a CLM and not running one shifts from "table stakes for large enterprises" to "the difference between running a business and not." That is what the DigiCert, Venafi, and Keyfactor sales cycles look like right now.
What to do before March 2029
Three years is a long roadmap. It is not a long procurement, deployment, and organisational-change roadmap. The teams that survive comfortably are the ones that start the inventory pass in Q4 2026 and the automation pass in Q1 2027.
- Build the inventory. Certificate Transparency + subdomain enumeration + management-plane audit + vendor-SaaS survey. Every cert your organisation depends on, in one place, with an owner, an expiry, and an issuer. Two weeks of engineering time for a mid-sized org.
- Instrument the alerts. Per-host, not per-apex. 30 days out for anything human-touched, 7 days out for anything under automation (because automation fails silently). Alerts route to the owning team's channel, not a generic security inbox.
- Automate the highest-volume renewal paths. Web-facing TLS is the easy win — ACME + cert-manager + Cloudflare. Get to zero-manual on this surface first.
- Address mTLS and internal PKI. This is where homegrown automation dies. If you have SPIFFE, HashiCorp Vault PKI, or Istio ambient mesh, the tooling exists — use it. If not, this is the segment a CLM tool actually pays for itself on.
- Address vendor-managed certs. Every SaaS that serves your subdomain manages a cert on your behalf. Ask each vendor for their renewal SLA in writing. The number of vendors who cannot produce one is instructive.
- Practise the 47-day cycle now. Pick one non-critical surface and run 45-day renewals on it starting Q1 2027. Everything you learn (broken scripts, missing intermediates, downstream services that cache old chains) is a lesson you don't want during the March 2029 deadline weekend.
FAQ
Where does Keyfactor's 86% number come from?
Keyfactor's annual PKI & Digital Trust Report surveys IT and security leaders at enterprises with 500+ employees; the 2024 iteration polled roughly 1,200 respondents across North America, EMEA, and APAC. Methodology and sample size are published in the report itself. The 86% figure is the share who reported at least one certificate-related outage in the past 12 months.
How does the 47-day rule affect internal PKI?
The CA/Browser Forum ballot governs publicly-trusted certificates — those chained to CAs in browser and OS trust stores. Internal private CAs (like the one that failed at Ericsson in 2018) are not bound by the ballot. But most enterprises operating internal PKI take the ballot as an industry signal and shorten internal lifetimes in parallel, both because the tooling gets built once and because the operational discipline transfers.
Does using AWS ACM or Cloudflare eliminate cert-outage risk?
For the surfaces those platforms cover, largely yes. The cert-outage risk shifts to the surfaces they don't cover — API gateways with per-tenant certs, EC2 instances with origin-terminated TLS, appliances with their own management-plane certs, and every vendor SaaS your subdomains are delegated to. The 86% outage rate in Keyfactor's data is not a measure of ACM's reliability; it is a measure of everything ACM doesn't touch.
Is 47 days final, or will it move again?
The ballot passed with wide CA and browser vendor support. The endpoint (47 days) is fixed; the intermediate dates may drift by a quarter or two based on operational feedback. No vendor has publicly signalled intent to push back on the endpoint itself.
What is the cheapest way to get to a working certificate inventory?
Free CT enumeration + subdomain brute-force + a spreadsheet gets a mid-sized organisation 80% of the way in a week. The remaining 20% (internal PKI, vendor SaaS, appliances) requires touching every management console — no shortcut. DomainScan's Free tier automates the CT + subdomain + external-facing chain audit for two domains continuously; the Pro tier scales it to twenty and adds per-host alert routing.
What is the difference between a CLM and a certificate monitor?
A monitor tells you a certificate is expiring. A CLM issues, rotates, and revokes the certificate for you. Most enterprises need both: a monitor for external validation (does the cert actually work when a real client connects?) and a CLM for internal operations (issue, install, rotate). Running only a CLM leaves you blind to the "cert deployed but chain broken downstream" failure mode. Running only a monitor leaves you doing renewals by hand.