When Equifax was breached in 2017, one of the reasons attackers moved data out undetected for 76 days was an expired certificate. Not on a website — on the network inspection appliance that was supposed to decrypt and examine outbound traffic. The appliance kept running. It simply stopped seeing anything. Nobody noticed, because nobody was tracking that certificate.
That is the version of certificate failure worth planning for. The obvious one — a public website throwing browser warnings — is embarrassing and gets fixed within the hour. The expensive one is a certificate on a piece of infrastructure whose failure mode is silence.
Most mid-market organisations have no certificate lifecycle owner. Responsibility is spread across whoever built each system, tracked in a spreadsheet if at all, and remembered through calendar entries owned by people who may have left. That arrangement worked while certificates lasted a year. It does not survive the schedule now in force: the public maximum dropped to 200 days in March 2026 and halves again in March 2027, as set out in our TLS certificate lifespan timeline. This guide is about building something that does survive it, without buying software you do not need.
The five stages, and how each one fails
| Stage | How it usually fails | What fixes it |
|---|---|---|
| Discovery and inventory | Shadow certificates deployed by developers or cloud services; a spreadsheet that was accurate two years ago | Active scanning across internal ranges plus Certificate Transparency log monitoring for your public domains |
| Issuance and validation | Manual signing requests, human error, validation proof that has expired before reissuance | Centralised issuance policy and automated DNS-01 or HTTP-01 challenges |
| Deployment | Certificate renewed at the authority but never installed on the target device — records say renewed, service still expires | API or scripted deployment with an automatic service reload and post-deployment verification |
| Renewal and monitoring | Alerts routed to an individual who changed roles; warning fatigue from generic reminder mail | Escalation to a team queue at fixed thresholds, and unattended renewal where the platform allows it |
| Revocation | No practical way to withdraw trust quickly; revocation checks soft-fail in browsers anyway | Short-lived certificates as the primary mechanism, with automated revocation as a secondary control |
Two of those deserve expanding, because they cause most real incidents.
Discovery is the foundation and it is usually broken. Survey data puts the share of organisations that cannot state how many keys and certificates they hold at over 60%. Certificates accumulate organically: a developer spins one up for a test environment that becomes production, a cloud service provisions its own, a department buys one directly. Each is invisible to central IT until it expires. You cannot renew what you have never counted.
Deployment failure is the quiet killer. The certificate was reissued on time and the ticket was closed, but the payload never reached the load balancer because an API credential had rotated or a reload signal was never sent. Central records show green. The service expires anyway. Any automation you build needs to verify what is actually being served, not merely that issuance succeeded.
The outage evidence
The pattern across documented incidents is consistent: one certificate, no owner, no monitoring.
- Ericsson, December 2018. An expired certificate inside core network software crashed mobile services for 32 million O2 subscribers in the UK and tens of millions in Japan for up to 23 hours, and drew a regulatory investigation.
- Microsoft Teams, February 2020. An internal authentication certificate expired and locked millions of users out of the platform globally for roughly three hours in the middle of the working day.
- Equifax, 2017. The expired inspection certificate described above left intrusion detection blind for 76 days while data was being exfiltrated.
Industry research puts numbers on how common this is: 77% of surveyed organisations reported at least two significant certificate-related outages in a 24-month period, and 55% said those outages disrupted customer-facing services. Ponemon Institute research places the average annual cost of certificate mismanagement to a large enterprise at around €6.6 million ($7.2 million), covering emergency remediation, audit failures and lost productivity.
Converted from USD at ≈€0.92 per US dollar (August 2026); local figures will differ.
Those are enterprise numbers, and your organisation is not Equifax. The mechanism is what transfers: a certificate nobody owns, on a system whose failure is not immediately visible, in an estate where nobody can produce a full list.
Why this is getting harder, faster
Two forces compound. Machine identities — servers, containers, services, devices — now outnumber human identities in a typical enterprise network by roughly 45 to 1, and each one that speaks TLS needs a certificate. Meanwhile the renewal frequency per certificate is doubling on a published schedule.
Run the arithmetic on a 100-certificate estate. Under the old 398-day regime that was about 100 renewal events a year, roughly two a week, absorbable by a small team. Today, under the 200-day cap, it is about 200. From March 2027 it becomes 400. By March 2029, at 47 days, it is around 800 — and by then each renewal also requires a fresh domain-control check, because validation proof will only be reusable for 10 days.
The thing to notice is that the crossover is not in 2029. It is roughly now. Whatever process you have today is already running at twice its historical load, and will be at four times within seven months.
Automation, honestly assessed
ACME is the open standard underneath almost everything here, and for standard web servers and cloud workloads it genuinely solves the problem: a client on the host requests, validates, retrieves and installs, and you stop thinking about it. Certbot covers standalone Linux servers, cert-manager covers Kubernetes, and cloud platforms renew their own load balancer certificates natively.
Three boundaries are where mid-market estates get stuck:
- Appliance firmware. Firewalls, VPN gateways and hardware load balancers rarely run an on-device ACME client. Automation has to be done to them, not by them: issue centrally, then push via the device’s REST API or an SSH script with a configuration reload.
- Internal names. Public authorities cannot issue for non-routable internal domains, so anything on .local or .internal needs a private CA — step-ca, Vault’s PKI engine or AD CS — with its own automation.
- Governance. ACME has no concept of approval workflows, ticket references or departmental separation. If you need those, they sit above the protocol.
One planning note that catches teams out: most ACME clients generate a new key pair at every renewal unless told otherwise. That is fine everywhere except in front of pinned clients, where a changed public key is an instant outage — the interaction we set out in our guide to certificate pinning.
What it actually costs
The build-versus-buy debate is usually argued on licence price, which is the wrong number. Here is the three-year picture with labour included, based on a mid-market estate and a fully loaded engineer cost of about €75,000 per year.
| Approach | Licence/year | Infrastructure/year | Labour | 3-year total |
|---|---|---|---|---|
| Certbot plus shell scripts | €0 | €0 | 0.5 FTE (≈€37,500/yr) | ≈€112,500 |
| cert-manager plus private CA (Vault) | €0 | ≈€10,000 | 0.5 FTE (≈€37,500/yr) | ≈€142,500 |
| Mid-tier commercial CLM platform | ≈€25,000 | Included | 0.1 FTE (≈€7,500/yr) | ≈€97,500 |
| Top-tier enterprise CLM platform | ≈€80,000 | Included | 0.1 FTE (≈€7,500/yr) | ≈€262,500 |
The uncomfortable line is the third one. At mid-market scale, a mid-tier commercial platform can come out cheaper over three years than the free tooling, because the free tooling is not free — it consumes half an engineer indefinitely. That is not an argument for buying software; it is an argument for costing your own labour honestly before deciding. Two caveats keep it honest in the other direction: the labour estimate assumes a hybrid estate with appliances in it, and top-tier enterprise platforms priced for the Fortune 500 remain terrible value at this scale.
The decision framework
A spreadsheet is genuinely fine when you have fewer than roughly 25 public certificates, all on systems that could run ACME, and one named owner who is not the only person who knows the process. Below that threshold, tooling is overhead.
Scripting is the right answer for perhaps 25 to 150 endpoints that are mostly Linux, cloud-native or otherwise ACME-capable. Certbot or cert-manager with DNS-01 challenges, deployment hooks and alerting into a team channel will carry you a long way. The cost is maintenance: those scripts are production infrastructure, and they need an owner and a test path.
A platform starts paying for itself when the estate passes roughly 100 endpoints, or — more often the real trigger — when a meaningful share of them are appliances, load balancers and internal services that cannot self-renew. That is where discovery, connectors and approval workflows stop being luxuries.
Whichever tier you land in, sequence the work by exposure rather than by convenience:
- Public-facing services first. Customer portals, e-commerce, public APIs. Highest visibility, highest business impact, and the easiest to automate with ACME.
- Perimeter hardware second. Firewalls, VPN gateways, reverse proxies. Hardest to automate, most damaging to lose, and the place where a manual process is least sustainable at 200-day intervals.
- Internal cloud workloads third. Containers, service meshes, internal APIs — usually solvable with cert-manager and a private CA.
- Internal servers last. Intranets, domain controllers, print services. Automate via scripted deployment or group policy once the exposed layers are handled.
Three things a two-person team can do this month
Scan for what you do not know about. Sweep your internal ranges on 443, 8443, 636 and 8080, and monitor Certificate Transparency logs for your public domains. A first inventory takes a couple of days and routinely surfaces certificates nobody remembers deploying.
Move to DNS-01 challenges. Validating through your DNS provider’s API rather than by placing files on each host is what makes automation possible for servers behind firewalls and for devices with no web root. It is the single change that unlocks the most endpoints.
Route alerts to a queue, not a person. Set thresholds at 90, 60, 30, 14 and 7 days into a shared channel or service desk, with the last two escalating. Personal mailboxes are where certificate warnings go to be ignored, and they leave with the person.
Where the sceptics are right
“Certbot and a calendar reminder are enough.” For a homogeneous Linux estate with a handful of certificates, this is true today and will still be true in 2029 — Certbot renews unattended, and the calendar is only a backstop. It stops being true the moment two things enter the picture: endpoints that cannot run a client, and the assumption that one person will remember the procedure. The failure mode is never the tool; it is the institutional memory around it.
“Commercial CLM platforms are enterprise-priced shelfware.” Often, yes. Platforms built for organisations with dedicated PKI teams carry six-figure contracts and implementation projects that a 300-person company will never amortise. But the cost table above shows the honest counterpoint: measured against half an engineer’s time indefinitely, a mid-tier platform can be the cheaper option. Evaluate on total cost including your own labour, not on the licence line.
“Our firewalls cannot automate, so why bother?” The appliance not running a client does not mean the renewal cannot be automated — issuance happens centrally and deployment happens over the API. Where that genuinely is not possible, the answer is to stop terminating public TLS on that device, which usually means moving the function rather than the certificate.
Start by counting
Every certificate outage in the record above began the same way: nobody knew that certificate existed, or nobody owned it. Before you evaluate a single product, produce the list — every public certificate, its expiry, its issuer, the host it lives on and the person responsible. That document tells you which tier of the framework you belong in, and it is the deliverable an auditor asks for anyway.
The other lever is reducing how many certificates you have to manage at all. Every appliance terminating public TLS is a manual renewal every few weeks and, eventually, a hardware refresh. Jimber consolidates secure web gateway, ZTNA network isolation, firewall-as-a-service and SD-WAN onto one EU-sovereign platform, which takes those terminations — and their rotation schedule — off your own hardware. Book a demo and we will look at your certificate footprint alongside your perimeter, or read more about how the platform works.
Frequently asked questions
What is certificate lifecycle management?
Certificate lifecycle management is the operational process of discovering, issuing, deploying, monitoring, renewing and revoking digital certificates across an organisation. Done properly it prevents expiry outages, keeps an accurate inventory of machine identities, and replaces manual tracking with automated renewal workflows tied to owners rather than individuals.
How do I find all the certificates on our network?
Combine two methods. Scan internal address ranges on common TLS ports — 443, 8443, 636 and 8080 among others — to find what is actually listening, and monitor Certificate Transparency logs for your public domains to catch certificates issued outside your process. Add exports from your internal CA and load balancer configurations.
What is the difference between ACME automation and a CLM platform?
ACME automates issuance and installation on endpoints that can run a client, which covers most web servers and cloud workloads. A CLM platform adds what the protocol does not provide: network-wide discovery, central visibility, approval workflows, reporting, and connectors that deploy certificates to appliances with no native client.
Are wildcard certificates a good idea?
They reduce administrative effort but concentrate risk, because one private key is shared across every subdomain and one compromised host exposes all of them. With automated issuance the administrative argument largely disappears, so per-host certificates are the safer default unless a specific deployment makes wildcards necessary.
What happens if our internal CA certificate expires?
Everything trusting that root fails at once: internal services, VPN connections, mTLS links and encrypted database sessions. Recovery means distributing a new trust anchor to every endpoint and server, which is slow and manual. Internal root and intermediate expiry dates belong in the same inventory as public certificates.
Can certificate renewal be automated on firewalls and load balancers?
Yes, but not with a client on the device. Issue the certificate centrally using a DNS-01 challenge, then deploy it through the appliance’s REST API or an SSH script that installs the key pair and triggers a configuration reload. Enrolment protocols such as SCEP and EST serve the same purpose where supported.
What alert thresholds should we set for expiring certificates?
For anything not fully automated, alert at 90, 60, 30, 14 and 7 days before expiry. Send the early warnings to a team queue and escalate the last two to a named owner or IT leadership. Alerts routed to individual mailboxes are the most common reason a known expiry still causes an outage.
Does replacing a certificate require restarting the service?
On modern web servers, no. Nginx, Apache and HAProxy apply a new certificate on a configuration reload, which affects new connections without dropping active sessions. Automation should always issue that reload explicitly — a renewed certificate that was never loaded is one of the most common causes of expiry outages.
