Certificate Lifecycle Management Business Case

Building the investment case for certificate lifecycle management

The case for certificate lifecycle management no longer rests on post-quantum migration. By 2029, public TLS certificate lifetimes will drop to 47 days. This change will increase the renewal volume by more than eight times, against a fixed headcount. Automation becomes an operational necessity first and a post-quantum enabler second.

Why certificate lifecycle management is now a funding question

Two independent pressures have converged, and either one alone would justify the investment.

The first is certificate lifetime reduction. CA/Browser Forum ballot SC-081v3, approved in April 2025, gradually lowers the maximum validity of publicly trusted TLS certificates. The limit dropped to 200 days on 15 March 2026. It falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Domain validation reuse periods will tighten to 10 days by 2029. The requirement affects certificate authorities. Issuing beyond the limit is misissuance. This triggers mandatory revocation and risks a CA's place in browser root programmes.
‍
The second is post-quantum migration. An algorithm change propagates through an estate at the speed of certificate renewal. Automating issuance with short lifetimes means that changing the issuing authority updates the entire estate in just weeks. When renewal is manual, each endpoint needs individual attention. This process can take years.
‍
The financial argument states that the first pressure funds the platform. The second benefit is delivered as a consequence.

What drives the cost of manual certificate management

The last row is the one usually omitted, and it is where post-quantum migration enters the model. A manual estate pays the reissuance cost once per algorithm change, and there will be more than one.

How shorter certificate lifetimes change the arithmetic

The reduction schedule converts a manageable annual task into a continuous operation. The table below displays renewal events for an example estate of 5,000 public TLS certificates. These are based solely on maximum validity.

Multiply the right-hand column by your own measured handling time per renewal to produce the labour position. The 2029 figure is about eight times larger than the pre-2026 figure. The table also assumes the certificate count won't grow, which is usually not the case.

This is the arithmetic that makes the case, and it does not depend on any view about quantum computing.

How to build the certificate lifecycle management business case

Establish the denominator

Count the certificates. Discovery often uncovers certificates that no register lists. This happens because internal certificate authorities, cloud-native issuance, appliances, and self-signed certificates are often in different places. If the number is unknown, the first figure in the business case is the discovery finding.

Model the labour position across the reduction schedule

Project renewal volume across 2026, 2027 and 2029. Use the maximum validity figures provided. Then, multiply by the observed handling time. Use your own handling time instead of a benchmark. Measure it from a sample of recent renewals. Include the installation and validation steps, not just the issuance.

Quantify outage exposure

Here are some incidents from recent years where certificate expiry caused problems:
‍
- Google Bazel, 26 December 2025. Certificates on bcr.bazel.build and releases.bazel.build expired. Builds failed globally with PKIX path validation errors. Documented in the public GitHub issue and the Bazel team's postmortem.
- Cisco SD-WAN vEdge routers, 9 May 2023. Expired hardware certificate on vEdge 100, 1000 and 2000 series. Cisco warned customers not to reboot, as that caused a total loss of service. See the Cisco advisory.
- Bank of England RTGS, 21 July 2024. A 91-minute outage to CHAPS and retail settlement, caused by an expired certificate within the Bank's own infrastructure. Recorded in the RTGS and CHAPS annual report.‍

Use the organisation's current cost of downtime figure for service continuity planning. The organisation has already accepted this number internally, so you won't need to debate it again.

Add the migration avoidance

Estimate the cost of reissuing the estate when there's a change in hierarchy or algorithm. Also, remember that post-quantum migration needs at least one such change before 2035. Algorithm transitions will happen again. This converts a one-off saving into a recurring one.

Present it as avoided cost, not new capability

Finance prefers a platform that stops cost increases over one that adds new features. The reduction schedule is set, dated, and fixed. So, the work comes in regardless of funding. Without tooling, that work lands on existing staff. It either makes the team grow or takes them away from their planned work to pursue renewals. The platform is the alternative to both.

Where post-quantum migration enters the case

Post-quantum migration should be the second argument in the paper, not the first. It's less certain when it will happen, tougher to budget for, and easier to put off. Starting with it often leads to the reply that 2035 is far off.
Positioned second, it is straightforward.

The NCSC's timeline includes:
- 2028 for discovery and planning
- 2031 for the top migration activities
- 2035 for completion

Migration speed is determined by renewal speed. An estate that uses automated issuance and has short lifetimes can spread an algorithm change during regular renewal. In contrast, an estate without these features cannot do so. The platform funded on renewal volume delivers post-quantum readiness as a by-product. There is also a hard dependency worth stating. Microsoft's ML-DSA support in Active Directory Certificate Services is included in the May 2026 update for Windows Server 2025. However, it does not provide an in-place migration path. A parallel hierarchy must be set up and endpoints moved to it. Manually doing this for a large estate takes years.

What finance will ask

Three questions come up consistently.

1. What happens if we do nothing.

Doing nothing has three costs. Headcount increases as the reduction schedule progresses. This happens because renewal volume is set by external factors, so the work needs to be managed. The outage probability goes up too. Eight times the renewals means eight times the chance of missing one. Post-quantum migration is falling behind. An estate that renews manually can't meet the NCSC's 2031 milestone or finish by 2035.

2. Why not hire instead.

Because the requirement scales with certificate count and renewal frequency, and both increase. Hire once and you hire again in 2027 and 2029. Automation cost does not scale in the same way.

3. What is the return period.

In estates with thousands of certificates, the labour maths typically supports the investment within the reduction schedule. Outage avoidance and migration costs are less predictable. Thus, it is better to present them as additional factors, not the main basis. Licensing structure materially affects the answer and varies considerably between vendors, which is covered separately in how to evaluate CLM vendors and licensing models.

Common objections

We already have a register.

A spreadsheet records what someone entered. It does not discover what exists, and it does not renew anything. The gap between the register and the estate is usually the finding that starts the programme.

Our certificate authority includes management tools. 

Native tooling generally covers certificates issued by that authority. Estates usually involve multiple authorities. Public, internal, cloud, and appliance-issued certificates often cover several of them.

We will address it when we migrate to post-quantum. 

The reduction schedule comes first in 2026, 2027, and 2029. The platform is essential for efficient migration, rather than a result of it.

Our certificates rarely expire unexpectedly. 

That is a statement about the past at 398-day lifetimes. At 47 days, the same processes produce eight times the opportunities for failure.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems. We work with central government, defence, healthcare, financial services, nuclear, and transport sectors.

We produce the evidence a business case requires. Discovery through our PKI health check establishes the actual certificate population, including the certificates no register holds. We then model renewal volume against the reduction schedule, assess which platforms fit the estate, and deliver the certificate lifecycle management capability itself.

We are vendor-neutral and partner with many in the CLM landscape. This means our platform recommendation is based on the estate, not a sales quota. If you're making a business case, our CLM whitepaper sets out the evaluation criteria in more detail, and we are happy to review a draft business case.