Certificate Lifecycle Management (CLM)

What Certificate Lifecycle Management is

Certificate Lifecycle Management (CLM) is the practice of treating every X.509 certificate in an environment as a managed asset with a birth, an operational life, and a controlled retirement. Software tools in the category — like TigerTrust — do the same job for certificates that IT service management platforms do for tickets, or that mobile device management platforms do for phones: they know what exists, they own the process for changing it, and they alert humans when something needs attention.

A modern CLM platform covers six stages:

The point is not any single stage — it is that they all happen automatically and consistently across teams that would otherwise each build a fragile version of the same thing.

Why it matters

Certificates are the silent load-bearing infrastructure of the internet. Every TLS handshake, every mTLS mesh, every code signing operation, every SSH connection, every device-to-cloud message that is authenticated at all depends on one. And they all expire.

The failure mode is uniquely bad: certificates work perfectly right up until the minute they do not, and then everything downstream breaks at once. Post-mortems on major outages regularly cite "expired certificate" as the root cause — Ericsson (2018), Cisco Umbrella (2020), Microsoft Teams (2020, 2022), Spotify (2020), Fastly, Slack, and hundreds of smaller incidents. The cost per incident is typically measured in millions of dollars per hour of unavailability plus long-tail reputational damage.

The problem is getting worse for two reasons:

1. Certificate lifetimes keep shrinking. Public TLS is on a trajectory toward 47-day maximum validity by 2029, with Let's Encrypt already at 45 days. What used to be a yearly problem is becoming a monthly one and will soon be a weekly one.
2. Certificate volumes keep growing. A single Kubernetes cluster can hold thousands of workload certs. A large enterprise has tens of thousands of TLS certs, plus SSH keys, plus device certs, plus code-signing certs. Manual processes that worked at hundreds do not work at hundreds of thousands.

CLM exists because the combination of shorter lifetimes and larger fleets makes manual management impossible.

What a CLM platform does

Concretely, a CLM platform provides:

• Continuous discovery across cloud accounts (AWS ACM, Azure Key Vault, Google CCM), Kubernetes clusters, load balancers, HSMs, filesystems, and network scans. Certs the CMDB does not know about are found and inventoried.
• A unified inventory with every cert's expiry, SANs, key algorithm, issuing CA, deployed locations, and owning team.
• Automated issuance through standard protocols — ACME (RFC 8555), EST (RFC 7030), SCEP, CMPv2, plus vendor APIs — so certs are issued programmatically without humans copying and pasting.
• Deployment automation that pushes issued certs to load balancers (F5, NGINX, HAProxy), Kubernetes ingress, cloud services, HSMs, and directly onto hosts.
• Renewal orchestration that triggers on a policy schedule (e.g. 30 days before expiry), issues the new cert, deploys it, and rolls back on health-check failure.
• Revocation and CRL/OCSP publishing for certs that must be withdrawn early — key compromise, employee departure, hardware retirement.
• Policy enforcement — cert must be from an approved CA, key algorithm must be on the allow-list, wildcards prohibited in production, etc.
• Audit trails and compliance reporting — who issued what, when, and why. PCI DSS, HIPAA, SOX, and CNSA 2.0 all require this.

Where CLM fits with other categories

CLM overlaps with but is not identical to:

• PKI (Public Key Infrastructure) — the underlying CA hierarchy and cryptographic services. CLM manages what PKI issues.
• Secrets management (HashiCorp Vault, AWS Secrets Manager) — CLM handles the certificate itself; secrets managers handle the private keys and other credentials. Modern CLM platforms integrate with vaults rather than replace them.
• HSM (Hardware Security Module) — CLM can drive HSM-backed CAs and can enrol HSM-generated keys, but HSMs are the storage tier, not the lifecycle tier.
• Machine identity management — a superset of CLM that also covers non-X.509 identities: SPIFFE SVIDs, SSH keys, API tokens, cloud instance identities. CLM is the certificate slice of that broader category.

Common misconceptions

"We have a spreadsheet — we do CLM." Spreadsheets go out of date the moment they are created. Every team that issues a cert without updating the sheet creates an unknown asset, and there is always a team that will forget.

"Auto-renewal is enough." Auto-renewal on the certs you know about is enough. The certs you do not know about are exactly the ones that cause the outage. Discovery is at least as important as renewal.

"Our cloud provider handles it." AWS ACM, Azure Key Vault, and Google CCM handle certs they issue. They do not know about your on-prem HSM, your legacy load balancer, your CI-signed dev certs, or the vendor SaaS you SSO'd into that provisions its own certs. Real environments are always a mix.

"CLM is an operations concern, not security." Every expired public cert is a browser warning that trains users to click through security warnings. Every self-signed cert that stays in production is a MITM invitation. Every long-lived cert with a compromised key is unrevoked risk. Lifecycle is security posture.

"Migrating to a CLM platform is a big-bang project." The successful adoptions start with discovery only — plug it in, find out what you have, share the report. Renewal, issuance, and policy come later once the inventory is a shared source of truth.

When to adopt CLM

You need a CLM platform when:

• Your fleet is large enough that spreadsheets are unreliable — typically low hundreds of certificates and up.
• You have suffered (or narrowly avoided) a certificate-expiry outage.
• Public TLS lifetimes are shrinking faster than your renewal process can keep up.
• You are subject to compliance frameworks that require inventory and audit trails.
• You are running multiple CAs (internal + public + cloud + Kubernetes) and no single team has the whole picture.

How TigerTrust does CLM

TigerTrust provides discovery across cloud, Kubernetes, and network scans; a unified inventory with owner attribution; automated issuance via ACME, EST, and vendor APIs; renewal workflows with health-checked rollback; and revocation with CRL/OCSP publishing. Where the risk profile demands it, certificates can be issued only to devices that pass a TPM-attested integrity check first — bringing hardware-rooted assurance into the same platform that manages the more routine TLS fleet. See TigerTrust's Certificate Lifecycle Automation product page for feature detail.

Related reading

• IETF RFC 8555 (ACME) — the dominant automated issuance protocol.
• IETF RFC 7030 (EST) — the enterprise counterpart for internal PKI.
• NIST SP 800-57 — general key management guidance that CLM programmes implement.