The Four Pillars of CLM - Applicability, Visibility, Availability, and Automation:

Applicability, visibility, availability and automation: the four pillars of CLM

Most certificate outages are not caused by a missed email. They are caused by an organisation not knowing the certificate existed.

The renewal reminder went to a mailbox nobody monitors. The owner left eighteen months ago. The certificate was issued for a short-term project that quietly became production. None of these are exotic failures. They are the normal condition of a large certificate estate that has grown faster than the process managing it.

That gap is about to get more expensive. Public TLS certificate lifetimes are falling to 47 days. A renewal cycle that was annual becomes roughly eight times a year, on every certificate you own. An estate of 2,000 certificates moves from 2,000 renewal events a year to around 16,000. Manual processes that just about held together will not survive that.

Certificate Lifecycle Management is how organisations close the gap. It is not a scheduling tool for expiry dates. It is the operating model for cryptographic trust across the estate.

It rests on four pillars: visibility, applicability, availability and automation. The order matters. Each one depends on the one before it.

1. Visibility

You cannot manage what you cannot see. This is the pillar organisations most often assume they have and most often do not.

In nearly every health check we run, the certificate count in the client's spreadsheet is lower than the count we find. Sometimes significantly. The gap is made up of certificates issued outside the central process: self-signed certificates on internal services, certificates bought on a team credit card, certificates embedded in appliances and devices by the supplier, certificates created during a migration and never decommissioned.

What good looks like

• A single inventory covering every certificate, across servers, applications, devices, load balancers, cloud services and third-party platforms.
• Discovery that runs continuously, not as a one-off exercise. An inventory built by hand is out of date within weeks.
• Named owners against every certificate, with an escalation path when the owner moves on.
• Visibility of the issuing CA, key algorithm, key length and expiry — not just the hostname.
• Coverage of internal and private PKI as well as public certificates. Internal estates are usually larger and less well governed.

What failure looks like

• Renewal becomes guesswork. You renew what you know about and hope the rest holds.
• Orphaned certificates stay valid for years, presenting an avoidable attack surface.
• Your first warning of a problem is a service falling over, not an alert.
• Post-quantum planning cannot start, because you have no baseline to plan against.

Visibility is the foundation. Every other pillar operates on the inventory this one produces.

2. Applicability

A CLM platform is only useful if it fits the estate you actually have, rather than the estate a vendor demo assumes you have.

This is where procurement decisions go wrong. A platform is selected on the strength of its cloud-native integrations, deployed against the modern 40% of the environment, and the legacy 60% stays exactly as manual as it was before. The business case was written on the whole estate. The benefit lands on part of it.

What good looks like

• Genuine hybrid support. On-premises and cloud, not one with the other bolted on.
• Multiple Certificate Authorities supported natively, so you are not locked to one vendor's roadmap, pricing or outage.
• Support for the protocols your systems actually speak — ACME, EST, SCEP and CMP — because different parts of the estate will need different ones.
• Coverage for legacy systems and appliances that cannot be modernised on your timescale.
• Role-based access and delegation, so application teams can self-serve within policy rather than raising tickets.

What failure looks like

• Shelfware. The platform works, but only for the systems that were easy.
• Shadow processes reappear, because the sanctioned route does not cover a team's technology.
• A second tool is bought to cover the gap, and you now have two partial inventories instead of one complete one.

Before committing, test against your hardest systems, not your easiest. Our guide to evaluating CLM vendors and licensing models covers the questions worth asking, and what to look for inside an enterprise deployment sets out the features that matter in practice.

3. Availability

Certificates need to be valid and working, continuously. Availability is the pillar the business actually cares about, because it is the one that maps directly to service uptime.

What good looks like

• Monitoring that flags problems before they reach production, including chain and trust store issues, not only expiry.
• Renewal workflows that run well ahead of expiry, with enough lead time for a failed renewal to be retried.
• Tested revocation and reissuance, so a compromise can be contained in hours rather than days.
• Redundancy in the issuing infrastructure. If your CA is unavailable, renewals stop.
• Clear ownership of the escalation path when automated renewal fails, because sometimes it will.

What failure looks like

• Outages that are entirely preventable and highly visible. A public-facing certificate expiry is a front-page failure, not an internal one.
• Emergency change windows, out-of-hours work and the associated cost. The real cost of an expired certificate is rarely the certificate.
• Regulatory and contractual exposure where availability is committed in an SLA.

At 47 days the margin for recovery disappears. Under an annual cycle, a renewal that failed silently could sit for weeks before anyone noticed and still be fixed. Under a 47-day cycle, there is no longer time to raise a ticket, chase an owner and wait for a change window. The process has to work first time, repeatedly.

4. Automation

Automation is what makes the other three sustainable at scale. Without it, the first three pillars describe a manual burden that grows with every new service you deploy.

What good looks like

• Certificates issued on request, integrated with provisioning, configuration management and DevOps pipelines.
• Renewal and deployment handled end to end, including the restart or reload the application needs to pick up the new certificate.
• Immediate revocation and replacement when a key is compromised.
• Policy enforced at issuance. Key length, algorithm, validity period and naming standards applied consistently regardless of who requested the certificate.
• A complete audit trail of every issuance, renewal and revocation, available without a manual evidence-gathering exercise.

What failure looks like

• Partial automation. Renewal is automated but installation is not, so a human is still in the loop on the step most likely to break.
• Automation built per team, in scripts, with no shared visibility. This is the silo problem, and it is common.
• Engineering time consumed by routine renewals that deliver no value.

The benefit is not only fewer outages. Automation removes a recurring, low-value task from skilled teams, enforces policy that would otherwise drift, and produces the audit evidence compliance functions ask for anyway.

Resistance is normal, and it is usually practical rather than technical. Teams have been burned by automation that broke something. We cover how to work through that in overcoming resistance to automation in certificate management.

How the pillars compound

These are not four parallel workstreams. They are a sequence, and taking them out of order is the most common reason CLM programmes stall.

• Automating an estate you cannot see automates the part you already had under control. The unknown certificates stay unknown.
• Choosing a platform before you understand the estate means choosing against assumptions. Applicability is a question you can only answer with an inventory in hand.
• Availability depends on both. You cannot guarantee continuity for certificates outside the system.

The practical sequence is: discover, then assess fit, then establish reliable renewal, then automate. Each step makes the next one cheaper.

What to measure

If you need to build a case internally, these are the numbers that tend to carry it:

• Total certificates discovered, against the number previously known.
• Certificates with no identified owner.
• Renewal events per year, now and at 47-day lifetimes.
• Engineering hours per renewal, multiplied out.
• Cost of certificate-related incidents over the last 24 months, including out-of-hours response.
• Certificates using algorithms or key lengths that will need replacing for post-quantum.

That last figure is the bridge to the next programme.

Where this leads

The same four pillars underpin post-quantum readiness.

You cannot migrate cryptography you have not inventoried. You cannot re-issue at scale without automation. You cannot swap algorithms across a hybrid estate unless your tooling reaches all of it. Every capability the quantum transition demands is a capability CLM builds first.

Organisations that get CLM right now are not solving a 47-day problem in isolation. They are building the crypto-agility that makes the next cryptographic change a managed process rather than a crisis. And there will be a next one.

How Unsung helps

We are vendor-neutral. We do not lead with a product.

We assess the estate first and establish what is genuinely there, including the certificates nobody has on record. From that baseline we advise on the architecture and tooling that fit your environment, your constraints and your timescales — then support the delivery.

A PKI Health Check is usually the starting point.