Certificate lifecycle management explained: CLM stages, machine identity management, certificate discovery, preventing expiry outages and a CLM tool checklist.
Certificate lifecycle management (CLM) is the practice of discovering, owning, issuing, deploying, monitoring, renewing, revoking and retiring every digital certificate an organisation uses, with as much of that cycle automated as possible. It is the operational core of machine identity management: keeping track of the certificates, keys and other credentials that servers, devices, workloads and software agents use to prove who they are.
Certificates rarely fail because the cryptography breaks. They fail because nobody knew a certificate existed, nobody owned it, or nobody renewed it in time.
Two changes make this more pressing in 2026. Publicly trusted TLS certificates are now capped at 200 days and will drop to 100 days in March 2027 and 47 days in March 2029, so manual renewal stops scaling. And the move to post-quantum cryptography means every certificate and key will eventually be reissued with new algorithms, which is only practical if you already know where they all are. This guide covers the lifecycle stages, expiry outages, automation protocols, discovery, a tool checklist and a 90-day rollout plan.
An X.509 certificate binds a public key to an identity (a domain name, a host, a service, a person or an organisation) and is signed by a certificate authority (CA). The certificate has a fixed validity period, and the matching private key must stay protected for that whole period. Certificate management covers who requested it, where it is installed, who owns it, and how it is replaced or revoked.
Certificate lifecycle management turns that into a repeatable process with three properties:
NIST's practice guide on TLS server certificate management (NIST SP 1800-16) frames the goal in the same terms: a formal certificate management programme that can prevent, detect and recover from certificate-related incidents at enterprise scale.
CLM is often confused with PKI. A PKI is the infrastructure that issues certificates: the CAs, their keys, policies, CRLs and OCSP responders. CLM is the process that governs certificates from every CA you use, public and private. You need both; the PKI as a Service guide covers the issuing side.
A machine identity is any credential a non-human actor uses to authenticate, sign or encrypt. Machine identity management is the broader discipline; CLM is its largest part. The inventory includes:
| Machine identity | Typical examples | Lifecycle concern |
|---|---|---|
| TLS server certificates | Websites, APIs, load balancers, ingress controllers, mail servers | Expiry, wrong chain, weak algorithm, public lifetime limits |
| Private / internal certificates | Service mesh (mTLS), internal APIs, databases, VPN, Wi-Fi (802.1X) | Unknown issuers, long lifetimes, no owner |
| Client and device certificates | Laptops, mobile devices, IoT, network equipment | Enrollment at scale, revocation when devices are lost |
| Cryptographic keys | Keys in HSMs, cloud KMS, keystores (JKS, PKCS#12) | Location, custody, algorithm, rotation |
| SSH keys and SSH certificates | Admin access, automation accounts, host keys | Unmanaged authorized_keys, no expiry on plain keys |
| Code and document signing certificates | Release pipelines, signed PDFs, firmware | Key theft, timestamping, long-term validation |
| Workload and agent identities | Containers, serverless functions, AI agents calling tools and APIs | Short-lived, high volume, created and destroyed dynamically |
Each identity has a key, a lifetime and an owner; if any of the three is unknown, it can cause an outage or a breach.
The certificate lifecycle has nine stages. Most incidents can be traced to a gap at one of them, usually long before the certificate expires.
| Stage | What happens | What can go wrong | Control to put in place |
|---|---|---|---|
| 1. Discover | Find certificates on hosts, keystores, cloud services, network endpoints and CA logs | Shadow certificates bought on a credit card or issued by an unknown internal CA | Scheduled scans across all sources, not one-off audits |
| 2. Inventory / own | Record each certificate with owner, application, location and renewal method | Owner left the company; nobody gets the expiry alert | Mandatory owner and team field; ownerless certificates escalated |
| 3. Request / approve | A CSR is submitted and checked against policy | Wrong key size, wildcard where not allowed, unapproved CA | Policy enforced at request time; approval workflow for exceptions |
| 4. Issue | The CA signs the certificate | Wrong profile, missing SANs, broken chain | Certificate profiles per use case; automated chain checks |
| 5. Deploy | Certificate and key installed on every endpoint that needs it | Installed on one node of a cluster but not the others; private key copied by email | Deployment automation with validation and rollback; keys generated where they are used or held in a vault |
| 6. Monitor | Track expiry, chain validity, algorithm and usage | Alerts go to a shared mailbox nobody reads | Alerts routed to the owner and the on-call rota, with escalation |
| 7. Renew | Replace before expiry, ideally with a new key | Renewed certificate issued but never deployed | Renew at a fixed fraction of lifetime; verify the served certificate after deployment |
| 8. Revoke | Invalidate a certificate early (key compromise, superseded, decommissioned) | Revocation not published; relying parties do not check | CRL and OCSP per CA; revocation playbook with reason codes |
| 9. Retire | Remove the certificate and destroy or archive the key | Old certificate still served by a forgotten host | Decommissioning step tied to asset lifecycle; rescan to confirm |
Revocation reasons are defined in RFC 5280, including keyCompromise, cACompromise, affiliationChanged, superseded and cessationOfOperation. Online status checking is defined in RFC 6960 (OCSP).
Certificate expiry outages tend to follow the same pattern. The certificate did exactly what it was designed to do: it stopped being valid on the date written in it. The failure is organisational.
The most common causes are:
How to prevent certificate expiry outages: discover continuously, give every certificate an owner, automate renewal and deployment through a protocol such as ACME, verify the certificate actually served after each deployment, and alert on expiry well before the renewal window closes, not on the day.
CA/Browser Forum Ballot SC-081v3, passed in April 2025, amended the TLS Baseline Requirements to phase down the maximum validity of publicly trusted TLS certificates and the reuse period for domain validation:
| Certificate issued | Maximum validity (BR 6.3.2) | Domain / IP validation reuse (BR 4.2.1) |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| From 15 March 2026 | 200 days | 200 days |
| From 15 March 2027 | 100 days | 100 days |
| From 15 March 2029 | 47 days | 10 days |
At 47 days, each public certificate is replaced roughly once a month. A process that needs a person for each renewal will not keep up. The rule applies to publicly trusted TLS certificates; private CAs set their own policy. The 47-day TLS certificate timeline guide has the renewal maths and a preparation plan.
Four standard protocols cover most automated enrollment. A CLM programme usually needs more than one, because servers, network devices and mobile fleets support different protocols.
| Protocol | Standard | Typical use | Notes |
|---|---|---|---|
| ACME | RFC 8555 (Standards Track, 2019) | Web servers, Kubernetes, reverse proxies | Defines http-01 and dns-01 challenges; clients include certbot, acme.sh, Caddy, cert-manager |
| EST | RFC 7030 (Standards Track, 2013) | Devices, IoT, enterprise clients | Operations under /.well-known/est: cacerts, simpleenroll, simplereenroll, and optional serverkeygen, csrattrs, fullcmc |
| SCEP | RFC 8894 (Informational, 2020) | Network equipment, MDM-managed mobile devices | Widely deployed in network and mobile device management |
| CMP | RFC 9810 (2025, obsoletes RFC 4210) and the lightweight profile RFC 9483 | Industrial, telecom and manufacturing PKI | Rich message set for enrollment, key update and revocation |
For internal certificates, running ACME against your own private CA gives you the same automation that public web servers already use. The ACME private CA automation guide walks through it step by step, including Kubernetes cert-manager. For example, a cert-manager ClusterIssuer only needs the private CA's ACME directory URL:
# ClusterIssuer pointing cert-manager at a DuoKey CA over ACME
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory
cert-manager renews by default at two-thirds of the certificate lifetime, configurable with renewBefore.
A certificate discovery tool answers which certificates exist, where, and who issued them. No single source gives the full answer:
| Discovery source | What it finds | Blind spots |
|---|---|---|
| Network scanning (TLS handshakes on IP ranges and ports) | Certificates served by reachable endpoints | Certificates not served on the network (keystores, files, client certs) |
| Filesystem and keystore scanning on hosts | PEM, DER, PKCS#12/PFX, JKS files, Windows certificate store, TPM | Hosts without an agent or credentials |
| Cloud provider APIs | Keys and certificates in cloud KMS and key vaults | Certificates installed directly on VMs or containers |
| CA databases and Certificate Transparency logs | Everything a given CA has issued for your domains | Internal CAs you do not know about; where the certificate is deployed |
| Load balancer, ingress and appliance APIs | Certificates bound to virtual servers and routes | Vendor coverage varies |
For each certificate, record at least subject and SANs, issuer, serial number, validity dates, key algorithm and size, signature algorithm, location, owner and renewal method. It also feeds your cryptographic inventory and your post-quantum migration plan.
Discovery is a loop, not a project: new services create certificates every week, so scan on a schedule and alert on differences.
Use this checklist to compare certificate lifecycle management tools, and ask vendors to demonstrate each item.
| Capability | What to check | Why it matters |
|---|---|---|
| Discovery sources | Network, filesystem and keystores, cloud KMS and key vaults, CA imports, CT logs | Coverage determines how many unknown certificates remain |
| CA-agnostic | Manages certificates from public CAs, private CAs and imported/external CAs | Most estates use several CAs; switching CA should not mean switching tools |
| Ownership and approval workflow | Owner field, team mapping, CSR approval, policy on key types and lifetimes | Prevents ownerless certificates and policy drift |
| Enrollment protocols | ACME, EST, SCEP, CMP, REST API | Different device classes need different protocols |
| Deployment automation and rollback | Connectors to servers, load balancers, Kubernetes; validation after deploy; rollback on failure | Renewal without deployment is the most common hidden failure |
| Alerting | Expiry thresholds, routing to owners, escalation, integration with ticketing and chat | Alerts that reach the wrong person do not prevent outages |
| Revocation | Revocation with RFC 5280 reasons; CRL and OCSP publication | Fast, correct response to key compromise |
| PQC readiness | ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) certificates, hybrid composite chains, algorithm reporting | Post-quantum migration will reissue most certificates |
| Audit | Tamper-evident log of requests, approvals, issuance and revocations | Evidence for DORA, NIS2, FINMA and internal audit |
| API and integration | Documented REST API, CI/CD integration, ITSM integration | CLM has to fit how teams already ship software |
Machine identity management also covers credentials whose failures are quieter than a TLS outage.
Code signing. A stolen code signing key lets an attacker ship software your customers will trust. Keep the keys in a vault or HSM and log every signature.
Document signing. Signed PDFs, contracts and reports depend on a signing certificate whose private key must not sit on a laptop. Server-side signing through an API keeps the key in a managed keystore instead of on individual machines.
SSH. Plain SSH keys have no expiry and accumulate in authorized_keys files. An SSH certificate authority changes the model: as the OpenSSH ssh-keygen manual describes, ssh-keygen can sign user and host certificates, and the -V option sets a validity interval. Servers then trust the CA, and short-lived certificates replace long-lived keys.
Workloads and AI agents. Containers, functions and AI agents that call tools and APIs on behalf of users are machine identities too, often created and destroyed within minutes. The same questions apply: who owns it, what may it sign or decrypt, and how is its credential revoked? The Know Your Agent article discusses this problem, and DuoKey's approach is described on the agentic crypto agility page.
This plan assumes partial visibility and mostly manual renewals.
DuoKey's certificate management runs in DuoKey Cockpit, one console and API for private PKI, keys and discovery. According to the DuoKey PKI documentation:
Discovery. The DuoKey PQC Scanner, which is the discovery engine of cryptographic posture management, finds filesystem certificates and keys (PEM, DER, PKCS#12/PFX, JKS/JCEKS), inspects X.509 certificates, and scans keystores including the Windows certificate store, JKS, PKCS#12 and TPM. It also inventories AWS KMS, Azure Key Vault and GCP Cloud KMS and produces a CBOM.
Beyond TLS. Cockpit includes an SSH certificate authority, and the PDF Sign API provides server-side PDF signing in which the certificate never leaves the tenant keystore.
DuoKey is a private PKI and certificate management platform; publicly trusted WebPKI certificates still come from a public CA. For questions about specific integrations or deployment models, contact DuoKey.
Q: What is certificate lifecycle management?
Certificate lifecycle management (CLM) is the process of discovering, owning, issuing, deploying, monitoring, renewing, revoking and retiring every digital certificate in an organisation. Its goal is to prevent outages and security incidents caused by unknown, expired or misconfigured certificates, mainly through inventory, policy and automation.
Q: What is machine identity management?
Machine identity management is the governance of the credentials that non-human actors use to authenticate: TLS and client certificates, cryptographic keys, SSH keys and certificates, signing certificates, and workload or AI agent identities. CLM is its largest part.
Q: How do I find all certificates in my organisation?
Combine several discovery sources: network scans of TLS endpoints, filesystem and keystore scans on hosts, cloud KMS and key vault APIs, exports from every CA you use, and Certificate Transparency logs for your public domains. Merge the results into one inventory with an owner for each certificate, and repeat the scans on a schedule.
Q: How do I prevent certificate expiry outages?
Keep a continuously updated inventory, give every certificate a named owner, automate renewal and deployment with ACME or another enrollment protocol, verify the certificate actually served after each change, and send expiry alerts to owners and on-call well before the renewal window closes. Check intermediate CA expiry as well as leaf certificates.
Q: What is a certificate discovery tool?
A certificate discovery tool scans networks, hosts, keystores and cloud services to find certificates and record their issuer, expiry, algorithm and location. Certificates you have not found cannot be renewed or migrated.
Q: Does the 47-day limit apply to internal certificates?
No. SC-081 applies to publicly trusted TLS server certificates. Private CAs set their own lifetimes.
Q: How does certificate lifecycle management relate to post-quantum migration?
Most certificates today use RSA or ECDSA, which are vulnerable to a future quantum computer. A CLM inventory shows which certificates use which algorithms, and automated issuance lets you reissue them with ML-DSA, SLH-DSA or hybrid certificates.
Certificates expire on a known date, so expiry outages are preventable: know every certificate, know who owns it, and let machines renew and deploy it.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.