Certificate lifecycle management (CLM) is the practice of finding, tracking, renewing and retiring every digital certificate an organization uses, from the day it is issued to the day it expires or is revoked. Done well, it stops outages caused by expired certificates and gives security teams one accurate list of every certificate, its owner and where it runs.
What is certificate lifecycle management?
A digital certificate is an X.509 file that links a public key to a name, such as a website, a user or a device. Certificates are what make HTTPS, VPN logins, signed documents and device identity work.
CLM covers every step of a certificate’s life, not only issuing it. In practice, it brings discovery, inventory, issuance, renewal, replacement, revocation, policy, ownership, reporting and automation together in one place.
CLM does not replace a certificate authority (CA). The CA checks requests and signs certificates. CLM keeps track of those certificates, wherever they came from, and automates the work around them.
The five stages of the certificate lifecycle
1. Discovery and inventory
You cannot renew a certificate you do not know about. Discovery scans networks, cloud accounts, servers, load balancers and Kubernetes clusters for certificates.
A useful inventory records, for each certificate, the owner, the issuer, the expiry date, the key type and size, and where it is deployed.
2. Request and issuance
A system or a person creates a key pair and a certificate signing request (CSR) and sends it to a public or private CA. The CA checks the request against its policy and issues the certificate.
Your own certificate policy should decide which CAs, key sizes, algorithms and lifetimes are allowed.
3. Deployment
The certificate and its private key are installed on the server, device or application. Many outages start here: the new certificate is issued but never installed, or it is installed on only some of the servers behind a load balancer.
4. Monitoring and renewal
Monitoring sends alerts well before a certificate expires. Renewal then requests a new certificate and deploys it, ideally with no manual step.
Renewal is also the right moment to rotate keys and move to stronger algorithms.
5. Revocation and retirement
When a private key is exposed or a system is retired, the certificate should be revoked. The CA then publishes its status through certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP).
Finally, remove old certificates and keys from your systems so they cannot be misused.
Why CLM matters more in 2026
Public TLS certificates are getting shorter. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime of a publicly trusted TLS certificate fell to 200 days on 15 March 2026. It drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029.
More renewals mean more chances to miss one. Our guide to 47-day TLS certificates explains the full timeline and what it means for your team.
The number of certificates is growing too. Organizations now use certificates for machines, containers, APIs and IoT devices, not only for websites, and those numbers grow faster than any spreadsheet can track.
Spreadsheets vs a CLM platform
A spreadsheet and a few calendar reminders can work for a handful of certificates. They break down when you have thousands of certificates spread across teams, clouds and CAs.
| Task | Spreadsheet and reminders | CLM platform |
|---|---|---|
| Discovery | Manual; only what people remember to add | Scans networks, cloud and devices for certificates |
| Accuracy | Goes stale when someone forgets to update it | Updated from scans and issuance events |
| Alerts | Calendar reminders sent to one person | Policy-based alerts and escalation |
| Renewal | Done by hand | Automated through ACME, SCEP, EST or APIs |
| Deployment | Done by hand, server by server | Pushed through integrations and automation tools |
| Audit trail | Edits in a shared file | Logged lifecycle events and reports |
| Scale | Tens of certificates | Thousands of certificates across many CAs |
The point is not that spreadsheets are wrong. It is that they depend on people remembering, and shorter lifetimes leave less room for that.
What to look for in a CLM tool
- CA-agnostic: it works with the public, private and cloud CAs you already run, without forcing you to replace them.
- Standard automation protocols: ACME, SCEP, EST and REST APIs, so servers, network devices and managed endpoints can renew without a person.
- DevOps and IT integrations: Kubernetes, infrastructure-as-code, CI/CD pipelines and IT service management tools.
- Governance: policy enforcement, role-based approvals, separation of duties, audit logs and reports.
- Key protection: support for hardware security modules (HSMs) where the risk is high.
As an example, Certinium CLM, our certificate lifecycle management platform, is designed as a CA-agnostic platform for mixed PKI environments, including Microsoft ADCS, EJBCA, DictaLabs CA and other enterprise or private CAs. It automates with ACME, SCEP, EST and REST APIs.
Its integration framework is designed to support Kubernetes and cert-manager, Terraform, Ansible, Jenkins, GitHub Actions, GitLab CI and REST API integration, subject to connector availability and implementation scope.
How to start: a five-step plan
- Discover every certificate, including those from public CAs, internal CAs and cloud services. If you want outside help, a PKI risk assessment looks for certificate visibility gaps, expiry risks and automation opportunities.
- Give every certificate a named owner, so someone is responsible when an alert fires.
- Write a short certificate policy that lists allowed CAs, key sizes, algorithms and maximum lifetimes.
- Automate renewal first for the certificates whose failure would hurt most.
- Report monthly on expiring, unknown and weak certificates.
Frequently asked questions
Is CLM the same as PKI?
No. Public key infrastructure (PKI) is the whole system of CAs, keys, policies and certificates. CLM is the management layer that keeps the certificates in that system healthy.
Does CLM replace my certificate authority?
No. A CA-agnostic CLM platform works with your existing CAs. If you also want to run your own CA, that is a separate product, such as DictaLabs CA, our enterprise certificate authority, which integrates with Certinium CLM.
When do I need CLM?
A simple test: if you cannot list every certificate, its owner and its expiry date in a few minutes, you need it.
Next step
If you want to know where you stand first, start with a PKI risk assessment of your certificates. If you are ready to see automation in your own environment, ask for a Certinium CLM demo or talk to a PKI expert.
