Guide
What is certificate lifecycle management?
Certificate lifecycle management (CLM) is the practice of tracking and controlling every digital certificate an organization uses, from the moment it is requested until it is renewed, replaced, or revoked. It covers discovery, approval, issuance, deployment, monitoring, renewal, and revocation, so certificates never expire unnoticed and never get issued without anyone knowing.
Updated
Why certificate lifecycle management matters
Every TLS connection, internal API call, VPN tunnel, and voice or video session that uses encryption depends on a certificate that is valid, trusted, and not about to expire. A typical organization has hundreds or thousands of them, spread across web servers, load balancers, Kubernetes clusters, network devices, and cloud services, and issued by more than one certificate authority (CA).
When that estate isn't managed, the failures are predictable: certificates expire and take services down, certificates get issued for names nobody approved, private CAs appear without anyone documenting them, and auditors ask questions nobody can answer.
The pressure is increasing. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of publicly trusted TLS certificates drops to 200 days in 2026, 100 days in 2027, and 47 days in 2029. A certificate that was renewed once a year before 2026 will need at least eight renewals a year by then. Read more in The 47-Day Certificate Era Is Coming.
The stages of the certificate lifecycle
1. Discovery and inventory
You can't manage certificates you don't know about. Discovery builds a complete inventory by searching Certificate Transparency logs for every public certificate issued for your domains, probing your networks for certificates that are actually deployed, and importing records from the CAs you buy from. Each certificate should be tied to an owner and a service.
2. Request and approval
Before a certificate is issued, someone should decide whether it should exist. Policy defines which domains may receive certificates, which CAs may issue them, maximum validity, key requirements, and whether wildcards are allowed. Requests that match low-risk policy can be approved automatically; production, wildcard, or sensitive requests go to a human approver.
3. Issuance
The approved request goes to a CA: a public CA such as Let's Encrypt or DigiCert for internet-facing services, or a private CA for internal ones. Issuance is usually automated through the ACME protocol or a CA's API. The private key should be generated where the certificate will be used and never sent anywhere else.
4. Deployment
A certificate sitting in a portal protects nothing. Deployment installs it on every endpoint that needs it: web servers, load balancers, Kubernetes Secrets, Windows and Linux servers, and network appliances. This is the stage most often left manual, and the one where renewals silently fail.
5. Monitoring
Monitoring tracks expiry dates, configuration, and changes across the inventory. It alerts the right owner well before a certificate expires, flags certificates that don't comply with policy, and spots certificates issued outside the approved process.
6. Renewal
Renewal replaces a certificate before it expires, ideally automatically and with enough margin to recover from a failure. With shorter lifetimes, renewal stops being an occasional task and becomes a continuous process that has to work without anyone watching.
7. Revocation and retirement
When a private key is exposed, a service is decommissioned, or a certificate was issued in error, it has to be revoked so it is no longer trusted, and removed from the inventory. Retirement closes the loop so old certificates don't linger in configurations or backups.
CLM vs. PKI vs. cert-manager
These terms are often used interchangeably, but they cover different layers:
- PKI (public key infrastructure) is the trust system itself: the CAs, keys, and policies that make certificates mean something.
- An ACME client or cert-manager automates issuance and renewal for the systems it runs on. It doesn't decide who may request what, or see certificates elsewhere.
- Certificate lifecycle management is the layer across all of it: inventory, policy, approvals, delivery, and audit for every certificate, whichever CA issued it and whichever tool requested it.
What to look for in a CLM tool
- Discovery beyond what you issued: Certificate Transparency monitoring and network scanning, not just a list of certificates the tool created.
- Policy enforced before issuance, not just reported after the fact.
- Human approvals for the requests that need them, without blocking routine renewals.
- Multi-CA support, public and private, so you aren't locked into one CA.
- Delivery to every endpoint type you run, including network devices and Kubernetes.
- A tamper-evident audit trail and reports your auditors will accept.
- Pricing and deployment that fit your team: SaaS or self-hosted, and a cost that makes sense at your scale.
How CertGov handles each stage
| Stage | In CertGov |
|---|---|
| Discovery | Certificate Transparency log scanning, active TLS probing, and CA connector imports from DigiCert, Sectigo, and internal CAs |
| Request and approval | Domain Trust Profiles define domains, CAs, validity, key rules, and approvers; requests can require justification and multiple approvers |
| Issuance | A built-in ACME endpoint (RFC 8555), REST API and CLI, public and internal CAs, and a built-in private CA |
| Deployment | Closed-loop delivery to ACME clients, Kubernetes, Linux and Windows servers, and network devices |
| Monitoring | A dashboard of managed, tracked, expiring, and ungoverned certificates, with expiry alerts routed to each service owner |
| Renewal | Automated renewal through the same policy and delivery paths, including the cert-manager external issuer |
| Revocation | Revocation via CRL for certificates from CertGov's internal CA |
| Audit | A SHA-256 hash-chained audit trail and framework reports for SOC 2, ISO 27001, PCI DSS, and HIPAA |
See the full feature list, or how CertGov compares with other CLM platforms on the comparison page.
Common questions
What does CLM stand for?
In security, CLM stands for certificate lifecycle management. (The same acronym is also used for contract lifecycle management, which is unrelated.)
Do small teams need certificate lifecycle management?
If you have more certificates than you can track from memory, yes. The tooling doesn't need to be heavyweight, but someone needs an accurate inventory, automated renewal, and a record of who issued what. Shrinking certificate lifetimes make that true for almost every team.
Is Let's Encrypt or cert-manager enough?
They handle issuance and renewal well for the systems they run on. They don't give you an inventory of certificates issued elsewhere, enforce who may request which names, require approvals, or produce an audit trail. Many teams keep them and add a governance layer on top.
How much does certificate lifecycle management cost?
Enterprise CLM platforms are typically quote-based. CertGov publishes its prices: free for up to 10 certificates, Pro at $179/month, Enterprise from $799/month, and self-hosted from $6,900/year. See pricing.
Manage the whole certificate lifecycle in one place
Free tier. No credit card. Your inventory in minutes.