Certificate expiry is one of the most preventable causes of production outages in existence, and yet it keeps happening at scale. CyberArk’s 2025 State of Machine Identity Security Report found that 72% of organisations experienced at least one certificate-related outage in the past year, with 34% suffering multiple. Keyfactor’s 2024 PKI and Digital Trust Report puts the figure even higher: 88% of companies continue to hit unplanned outages from expired certificates. These are not edge cases. They are the predictable outcome of treating certificate management as an afterthought.
The consequences range from embarrassing to catastrophic. An expired certificate cost Microsoft Teams a roughly three-hour global outage in February 2020. In December 2018, an expired certificate in an Ericsson SMF node knocked O2 UK and SoftBank offline for most of a day, affecting approximately 32 million users. After Equifax’s 2017 breach, investigators found a monitoring device whose SSL certificate had been expired for 19 months, during which 265 instances of unauthorised data access went undetected, along with 324 other expired certificates across the infrastructure. The pattern is consistent: the certificate is known, the expiry date is known, and the outage happens anyway.
For infrastructure teams operating under NIS2 or DORA, the stakes are now explicit in regulation. NIS2 (Directive (EU) 2022/2555) mandates the effective use of cryptography and encryption, and sets hard incident thresholds: complete unavailability of more than 30 minutes triggers reporting obligations for cloud, CDN, and managed service providers. DORA (Regulation (EU) 2022/2554), which went live on 17 January 2025, defines an ICT-related incident broadly enough to capture certificate expiry outages directly. A certificate that takes a payment platform offline is a reportable major incident under DORA’s Article 3(8), with a 4-hour classification window and a 72-hour notification requirement to supervisors. The operational cost of getting this wrong now includes regulatory exposure.
The pressure is about to intensify further. In April 2025, the CA/Browser Forum approved Ballot SC-081v3, originally proposed by Apple, with 29 votes in favour and none opposed. The ballot mandates a phased reduction in TLS certificate validity: 200 days maximum from March 2026, 100 days from 2027, and 47 days by March 15, 2029. At the current 398-day maximum, a team managing 100 public certificates performs roughly 100 renewals per year. At 47-day validity, that same estate requires approximately 800 renewals annually. Any team still renewing certificates manually will find the workload untenable well before 2029 arrives.
Why automation alone is not enough
The instinctive response is to automate. Let’s Encrypt and the ACME protocol have made automated renewal genuinely accessible, and for public-facing web services they are a reasonable baseline. But automation introduces its own failure modes, and regulated environments require more than a renewal script that runs until it silently stops.
Let’s Encrypt renewal failures are a real and recurring pattern. Rate limits, DNS propagation delays, firewall rules blocking the HTTP-01 or DNS-01 challenge, and misconfigured renewal hooks all cause silent failures. The certificate does not renew; the alert does not fire; the expiry arrives on schedule. A single CA dependency is also a concentration risk: Let’s Encrypt has experienced availability incidents, and any CA can be compromised, distrusted, or temporarily unreachable. Relying on one CA for your entire estate is an operational single point of failure.
Automation removes the human forgetting problem. It does not remove the need for humans to verify that the automation is working.
The gap that kills teams is the absence of independent monitoring. Renewal automation and expiry monitoring are separate concerns and should be treated as separate systems. If your only signal that a certificate is about to expire is the renewal tool itself, you have no independent verification layer. By the time a browser or load balancer rejects the certificate, the outage has already started.
A systematic approach to certificate lifecycle management
A robust certificate lifecycle management programme has four distinct layers, and all four need to be in place before the 47-day mandate makes partial approaches unworkable.
1. Full inventory and continuous discovery
You cannot manage what you have not found. Start with a complete inventory of every certificate in your estate: public-facing, internal, load balancers, API gateways, service meshes, database connections, and anything that terminates TLS. Automated discovery tools that scan your network ranges and parse certificate transparency logs give you coverage that manual spreadsheets cannot sustain. Internal PKI certificates are frequently overlooked because they are not publicly visible; they are just as capable of causing outages.
2. Multi-CA strategy with ACME-compatible tooling
Do not concentrate your entire certificate estate on a single CA. Maintain at least two CA relationships for critical services, and test failover between them before you need it. ACME-compatible certificate management platforms (cert-manager on Kubernetes is the most widely deployed example) support multiple issuers and can be configured to fail over or alert when a renewal attempt fails against the primary issuer. For internal services, operate your own intermediate CA under a trusted root so that internal certificate issuance is not dependent on external CA availability at all.
3. Independent expiry monitoring with hard alerting thresholds
Monitor certificate expiry independently of your renewal tooling. External monitoring services, Prometheus exporters such as the ssl-exporter, or purpose-built PKI management platforms all provide this. Set alert thresholds at 30 days, 14 days, and 7 days, with escalating severity. At 47-day validity, a 30-day alert fires within 17 days of issuance: that is your signal that something in the renewal chain has already failed and needs human attention immediately. Wire these alerts into your incident management workflow, not just a dashboard that someone checks occasionally.
4. Auditable renewal records for compliance
NIS2 and DORA both require organisations to demonstrate effective risk management practices, not merely assert them. Certificate renewal events, failures, and manual interventions should be logged with timestamps and retained in a way that supports audit. This is especially relevant for financial entities under DORA, where the EBA’s regime applies to over 22,000 financial entities across the EU and auditors will look for evidence that ICT risk controls are operating as documented.
How we handle this at DIVERSITY
Across our infrastructure at MAD1, MUC1, HEL1, and AMS1, we manage TLS termination at multiple layers: edge, load balancers, internal service-to-service communication, and the management plane itself. We run cert-manager across our Kubernetes clusters with multiple issuer configurations, backed by independent monitoring that alerts independently of the renewal path. For our internal services, we operate our own PKI rather than routing internal certificate issuance through public CAs, which removes external availability dependencies from the critical path.
Customers running workloads in our managed environments inherit the monitoring and alerting layer as part of the platform. For customers managing their own certificate estates on our infrastructure, particularly those in finance and healthcare where NIS2 and DORA exposure is direct, we recommend and can help implement the full four-layer approach described above. The contractual 99.9% uptime SLA we offer is only meaningful if the services running on top of our infrastructure are not taking themselves offline with expired certificates.
What to do before March 2026
The CA/Browser Forum’s phased reduction starts in March 2026, which gives infrastructure teams roughly a year to reach a state where certificate renewal is fully automated, independently monitored, and auditable. That timeline sounds comfortable until you account for the organisational work: getting inventory complete, migrating legacy services that cannot support automated renewal, and building the monitoring layer from scratch if it does not already exist.
Start with inventory. Find every certificate in your estate, including the ones that are not on any list. Then automate renewal for everything that can be automated, build independent monitoring for everything that cannot, and treat any manual renewal process as technical debt with a hard deadline attached to it. The 47-day mandate is not a future problem. It is the forcing function that makes the work that should already be done impossible to defer.
