Certificate Lifecycle Management: 9 Proven Wins for Uptime

Certificate lifecycle management used to be an annual chore. Someone set a calendar reminder, renewed the wildcard, ticked a box, and forgot about it for another twelve months. That era is over. Public TLS certificate lifetimes are now on a fixed shrinking schedule, and the manual habits that just about survived a 398-day certificate will not survive a 47-day one. For MSPs and internal IT teams running dozens of tenants, certificate lifecycle management has quietly become continuous operational work — and most teams have not staffed it.

This article sets out what changed, what an expiry outage really costs, and nine proven wins that turn certificate lifecycle management from a recurring emergency into a boring, evidenced routine.

Why Certificate Lifecycle Management Just Got Harder

In April 2025 the CA/Browser Forum passed ballot SC-081v3, which introduced a phased reduction in how long a publicly trusted TLS certificate may be valid. The schedule is public and dated: a maximum lifetime of 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. The period for which domain validation data may be reused shrinks alongside it — 200 days, then 100 days, then just 10 days. You can read the ballot text in full on the CA/Browser Forum’s own site.

The arithmetic is what matters for certificate lifecycle management. A certificate you renewed once a year will need renewing roughly twice a year from 2026, three to four times a year from 2027, and around eight times a year from 2029. Multiply that by every public-facing service across every client tenant you support, and a task that felt like housekeeping becomes a standing workload with a hard deadline attached to each item.

The reuse change is the part teams tend to miss. Even where renewal itself is automated, domain control validation has to be repeated far more often, which means the DNS records, HTTP challenge paths and delegation arrangements that validation depends on must keep working unattended. Certificate lifecycle management is no longer only about the certificate; it is about the whole validation path staying healthy between renewals.

What an Expired Certificate Actually Costs

An expired certificate rarely degrades gracefully. It fails closed, loudly, and usually at the least convenient moment. A public website throws a full-page browser interstitial that no non-technical user will click past. API clients simply stop connecting, often without a useful error surfacing to the people who notice first. Mail flow stalls. VPN clients refuse to establish. Wi-Fi authentication against RADIUS breaks for an entire site at once, which reads to users as “the internet is down”.

The secondary cost is the scramble. Because expiry outages are unplanned, they pull senior engineers off whatever they were doing, and the fix is frequently blocked on something mundane: nobody knows which account holds the CA login, the DNS is managed by a third party who is not answering, or the private key lives on a server that was rebuilt last quarter. Weak certificate lifecycle management does not just cause the outage — it lengthens it.

There is a reputational cost too. A browser warning that says a client’s site is not secure is the single most visible failure an IT provider can hand a customer, and it is the one failure the customer’s own customers will see first.

9 Proven Wins for Certificate Lifecycle Management

None of these require a platform purchase to start. They require someone to own them.

1. Build one expiry register that spans every tenant

The foundation of certificate lifecycle management is a single list: every certificate, its common name and SANs, issuer, expiry date, where it is installed, how it renews, and who owns it. Per-client spreadsheets scattered across documentation tools are how estates drift. One register, one source of truth, reviewed weekly.

2. Discover what you do not already know about

Your register starts wrong, because certificates get issued by people who never told you. Scan public IP ranges and hostnames, query certificate transparency logs for client domains, and inventory internal issuing CAs. Most teams doing this properly for the first time find appliance management interfaces, forgotten dev environments and a load balancer nobody documented.

3. Automate with ACME wherever the platform allows it

Automated renewal is the only approach that scales as lifetimes compress. The ACME protocol, standardised as RFC 8555, lets a client request, validate and install certificates without a human in the loop. Prioritise the high-churn public estate first. Good certificate lifecycle management means every manual renewal is a deliberate exception, not a default.

4. Give every certificate a named owner

“The infrastructure team” is not an owner. A person is. Ownership decides who gets the alert, who is accountable when a renewal is missed, and who signs off a change. Certificates attached to a departed employee’s account are one of the most common causes of a renewal that silently stops working.

5. Fix the renewal path before you shorten the lifetime

Before trusting automation, walk the whole path once by hand: can the validation challenge be served, does the DNS provider API token still work, does the deployment step actually restart the service that holds the certificate? Automation that issues a new certificate but never installs it is worse than a manual process, because it looks green.

6. Treat internal PKI as a first-class citizen

The shortening schedule applies to publicly trusted certificates, but internal certificate authorities cause just as many outages — domain controllers, RADIUS, internal APIs, code signing. These often have long lifetimes and no monitoring at all, which means the failure lands years later with nobody left who remembers the design. Certificate lifecycle management has to cover both estates.

7. Monitor from the outside in

Check expiry the way a user experiences it: connect to the live endpoint and read the certificate being served. Internal inventory tells you what should be installed; an external probe tells you what actually is. Alert at 30, 14 and 7 days, and route those alerts somewhere a human reads, not into the same queue as the noise.

8. Bring secrets and API keys into the same register

Certificates are not the only thing with an expiry date. Application registration secrets, signing keys, integration tokens and cloud credentials all expire, and they fail in the same abrupt way. The same register, the same owner and the same alerting works for all of them, which is why mature certificate lifecycle management usually grows into expiry management generally.

9. Rehearse the emergency reissue

Mass revocation events happen, and CAs occasionally have to revoke at short notice. Knowing in advance how quickly you could reissue and redeploy across a client base — and having tested it once — converts a potential multi-day incident into a scheduled afternoon. The UK’s National Cyber Security Centre makes the same general point about deployed estates: the controls you have never exercised are the ones that fail under pressure.

Where It Breaks Across a Multi-Tenant Estate

Everything above is achievable for one organisation with one domain. The difficulty is multiplication. An MSP supporting forty clients is dealing with forty sets of DNS providers, forty registrar logins, forty change-approval cultures and forty different opinions about who pays for what. Certificate lifecycle management across that estate is not a harder version of the single-tenant problem; it is a different problem, and it is mostly coordination.

The work is also unevenly urgent. Nothing is on fire until something expires, at which point it is extremely on fire. That profile is exactly what gets deprioritised in a service desk optimising for ticket throughput, which is why certificate lifecycle management tends to be genuinely good on the two clients someone cared about and undocumented everywhere else.

Certificate Lifecycle Management Is a Staffing Problem

Most teams do not have a tooling gap here. They have a capacity gap. The register needs maintaining weekly, discovery scans need running and triaging, exceptions need chasing, and the long tail of appliances that cannot speak ACME needs handling by hand, per tenant, forever. That is steady, documentable, evidence-generating work — and it is precisely the kind of work that never wins against a P1 ticket.

Handing it to your senior engineers means it gets done in the gaps, badly. Hiring a dedicated UK engineer for it is hard to justify on cost. The realistic answer for most MSPs is dedicated capacity that is affordable enough to assign permanently to unglamorous, high-value operational work, which is where outstaffing changes the maths on certificate lifecycle management.

How OutsourceZA Staffs the Work

OutsourceZA places skilled South African tech talent with UK and EU businesses, and this is a textbook fit. South Africa sits in the SAST time zone, one to two hours ahead of the UK depending on the season, so an outstaffed engineer covers the full UK working day in real time — not a handover note written overnight. Renewal windows, change approvals and client calls all happen while your team is at their desks.

The cost difference is the other half of it. Engaging engineers through OutsourceZA typically saves 40–60% against equivalent UK hiring costs, which is what makes it viable to assign someone to certificate lifecycle management as a permanent responsibility rather than a project that gets shelved. Our engineers are MSP-ready: they already know RMM and PSA tooling, multi-tenant administration and the discipline of working inside someone else’s documentation standards.

Because the model is outstaffing rather than a fixed managed service, you can scale the commitment to the work. Start with part of an engineer’s week to build the register and run discovery, then expand as the automation programme grows. You can read more about our IT outsourcing services, see the kind of engineers we place on our IT jobs page, or learn about us and how we vet talent.

A 30-Day Certificate Lifecycle Management Starting Plan

Week 1 — Inventory. Build the register. Pull what exists from documentation, scan the public estate, query certificate transparency logs per client domain, and list every internal issuing CA. Accept that it will be incomplete and record it anyway.

Week 2 — Triage. Sort by expiry date, then by blast radius. Anything expiring inside 60 days gets a named owner and a confirmed renewal path this week. Flag every certificate whose renewal depends on a person rather than a process.

Week 3 — Automate the easy majority. Move the standard web estate onto ACME-based renewal and prove it end to end on one low-risk service before rolling it out. Certificate lifecycle management improves fastest when the routine cases stop needing attention at all.

Week 4 — Monitor and hand over. Put external expiry probes on everything in the register, set the 30/14/7-day alerts, write the runbook, and agree who owns the weekly review. If nobody owns the weekly review, the register is stale within a quarter.

Done properly, certificate lifecycle management stops being something you think about. That is the entire goal: no interstitials, no 4pm scrambles, no client asking why their site says it is not secure.

Certificate Lifecycle Management FAQs

How short will TLS certificate lifetimes actually get?

Under CA/Browser Forum ballot SC-081v3, the maximum lifetime for a publicly trusted TLS certificate dropped to 200 days on 15 March 2026, falls to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Domain validation reuse periods shorten on the same dates, ending at 10 days.

Does automation remove the need for certificate lifecycle management?

No. Automation removes the repetitive renewal step, which is the easy part. You still need discovery, ownership, an accurate register, monitoring that checks what is actually being served, and a plan for the appliances and legacy systems that cannot be automated. Certificate lifecycle management is the programme; ACME is one tool inside it.

What about certificates on appliances that do not support ACME?

They need to be identified explicitly and managed as a known exception list, with named owners and calendar-driven renewal windows. The exception list should shrink over time as kit is replaced, and its size is a useful metric to report to clients.

Should internal certificates be on the same schedule?

They do not have to follow the public schedule, but they should be in the same register with the same monitoring. Internal PKI expiries tend to be rarer and far more damaging, because they hit authentication infrastructure and often surprise a team that has changed completely since the CA was built.

How much capacity does this take to run properly?

For a mid-sized MSP estate, the build phase is typically several focused weeks, after which ongoing certificate lifecycle management settles into a few hours a week of register maintenance, exception chasing and alert triage — provided somebody genuinely owns those hours.

Can OutsourceZA provide an engineer to own this?

Yes. We place dedicated South African engineers who work your hours and integrate into your existing tooling and processes. Contact us to talk through the scope and what the right level of commitment looks like for your estate.