What is Certificate Lifecycle Management? A 2026 Guide
Certificate lifecycle management (CLM) is the practice of managing digital certificates across their full lifespan — request, issuance, deployment, discovery, monitoring, renewal, revocation and retirement — at scale and, in most modern environments, through automation rather than manual tracking.
Every secure connection your organisation makes, from websites to APIs to internal applications, depends on a digital certificate. Those certificates authenticate identities, encrypt data and establish the trust that digital systems need to function. But they are not permanent. They expire, they get compromised, and they need replacing.
In a small environment that might be manageable with a spreadsheet. In an enterprise with tens of thousands of certificates issued across multiple PKI environments, cloud providers and business units, manual management is not just inefficient. It is a direct source of risk.
Key points
- A certificate passes through seven distinct stages. Manual processes usually break down at discovery and renewal.
- Most organisations cannot state how many certificates they hold. That gap is where outages come from.
- Public TLS lifetimes are falling to 47 days by 2029, multiplying renewal volume roughly eightfold.
- The rules apply to publicly trusted certificates only, but internal estates face the same operational pressure.
The certificate lifecycle: from issuance to retirement
A digital certificate passes through a series of defined stages. Understanding them matters because each one is a point where manual processes tend to fail.
1. Request and issuance
The lifecycle begins when a system, user or application generates a Certificate Signing Request (CSR) and submits it to a Certificate Authority. The CA validates the request and issues the certificate.
How that exchange happens depends on which certificate management protocols your environment supports — ACME, EST, CMP or SCEP. Each suits different use cases, from web servers to IoT devices to enterprise desktops.
2. Enrolment and deployment
Once issued, the certificate has to reach the right system: installed on a web server, pushed to endpoints via Group Policy, provisioned to a Kubernetes cluster, or distributed across a device fleet.
This is where automation most often falls short. A renewal is not complete when the certificate is issued. It is complete when the application is actually serving it, which usually requires a service restart or configuration reload.
3. Discovery and inventory
Organisations rarely have a complete picture of every certificate in their environment. They get issued by different teams, across different CAs, in different cloud environments, through different tools — and frequently by suppliers who embedded them in an appliance before delivery.
Discovery is the process of scanning infrastructure to find every certificate, including those created outside formal PKI processes. Building a cryptographic bill of materials provides the foundation for that visibility, and it is the prerequisite for everything else on this list.
4. Monitoring
Certificates have finite validity periods, and when they expire the services depending on them fail immediately. Effective monitoring tracks more than expiry dates — chain and trust store problems, weak algorithms and short key lengths all need surfacing before they reach production.
5. Renewal
Renewal replaces certificates before expiry, ideally through automated workflows requiring no manual intervention. As TLS lifetimes shorten, the window for catching an approaching expiry shrinks with them — and so does the time available to recover from a renewal that fails silently.
6. Revocation
Sometimes a certificate needs invalidating before its natural expiry, typically because a private key has been compromised or an employee has left. Revocation updates Certificate Revocation Lists or triggers OCSP responses so relying parties stop trusting the certificate.
Effective revocation depends entirely on knowing which certificates exist and where they are deployed. It is also worth testing: in segmented networks, revocation checking often behaves differently in production than it did in the lab.
7. Retirement
At end of life a certificate is removed from systems, its records archived for audit, and any residual dependencies cleared. Orphaned certificates — still deployed, no longer monitored — are a common and avoidable source of risk.
Why certificate lifecycle management matters
Outages
The consequences of poor certificate management are immediate and highly visible. Expired certificates disrupt services, break encrypted connections, trigger browser warnings and erode customer confidence. The Microsoft Teams global outage in 2020, caused by a single expired authentication certificate, remains the most widely cited example — but smaller versions of it happen constantly and never make the news.
The cost is not theoretical. ITIC's 2024 research found that more than 90% of mid-size and large enterprises put the cost of a single hour of downtime above $300,000, with 41% placing it between $1 million and over $5 million. Those figures exclude litigation and regulatory penalties. We have covered the real cost of expired certificates in more detail separately.
Security exposure
Unmanaged certificates create risk beyond availability. Weak algorithms, excessive validity periods and inadequate key protection all expand the attack surface. Certificates created outside governed PKI processes — sometimes called shadow certificates — sit unmonitored in production.
Without a complete inventory, an organisation also cannot assess its exposure to post-quantum cryptography requirements, because it does not know which algorithms and key lengths are in use.
Compliance and audit
Regulatory pressure is increasing. GDPR, PCI DSS, HIPAA and eIDAS either explicitly require or implicitly depend on effective certificate governance. Audit findings related to expired, unknown or non-compliant certificates are becoming more common, particularly in financial services and healthcare — and an organisation without an inventory cannot produce evidence without a manual scramble.
The impact of shorter certificate lifetimes
In April 2025 the CA/Browser Forum voted unanimously to reduce the maximum validity of public TLS certificates on a phased schedule:
- March 2026 — maximum lifetime reduces to 200 days
- March 2027 — maximum lifetime reduces to 100 days
- March 2029 — maximum lifetime reduces to 47 days
By 2029, the same set of certificates that currently requires annual renewal will need renewing roughly eight times a year. For an organisation managing 10,000 public TLS certificates, that is a move from 10,000 renewal events annually to approximately 80,000.
Manual processes will not survive that transition. Organisations that have not implemented automated CLM before the deadlines take effect face a choice between continuous firefighting and systematic certificate-related outages. This is the single largest driver of CLM adoption in 2026, and we have written separately on what the reduction in TLS certificate lifetimes means in practice.
These rules apply to publicly trusted TLS certificates only. Internal PKI certificates are not subject to CA/Browser Forum rules, though many organisations are choosing to align internal practice with external standards for consistency and reduced operational risk.
The four pillars of CLM
Effective certificate lifecycle management rests on four capabilities, covered in full in our article on the four pillars of CLM.
- Visibility provides a complete, current picture of every certificate in the environment. Without it you cannot monitor expiry, enforce policy or identify what you do not know about. This one comes first — the others operate on the inventory it produces.
- Applicability ensures the platform matches your actual requirements: hybrid infrastructure, multiple CAs, and both legacy and cloud-native environments.
- Availability maintains continuous certificate validity through proactive monitoring, automated renewal and rapid revocation and replacement.
- Automation orchestrates issuance, renewal, deployment and revocation at scale, reducing human error and enforcing consistent policy.
Why manual certificate management fails
Manual management usually means tracking certificates in spreadsheets, relying on calendar reminders, and handling each issuance as a standalone task. It fails at scale for three reasons.
Spreadsheets go stale
The moment a certificate is issued outside the tracked process, the inventory is incomplete. Teams issue certificates independently, and without automated discovery those certificates remain invisible until they expire and take something down.
Manual renewals are error-prone
A single missed renewal can take down a production service. When renewal volumes increase eightfold, the probability of human error moves from likely to certain.
Policy enforcement is inconsistent
Without automation there is no mechanism ensuring every certificate meets organisational standards for key length, algorithm, validity period and permitted use. Standards drift, and the drift is only discovered during an audit or an incident.
Modern CLM platforms address this through automated discovery across hybrid environments, automated renewal and deployment workflows, centralised policy enforcement, integration with SIEM, secrets management and ITSM tooling, and real-time alerting and compliance reporting.
Resistance to automation is common and usually practical rather than technical — teams have been burned before by automation that broke something. Our guide to overcoming resistance to automation covers how to work through it.
Certificate management protocols
CLM platforms interact with Certificate Authorities through standardised protocols, each suited to different environments. Our protocol comparison guide covers these in detail.
- ACME (Automatic Certificate Management Environment) is the protocol behind Let's Encrypt and now supported by most major CAs and CLM platforms. The default choice for automating public TLS issuance and renewal, and increasingly for private certificates too.
- EST (Enrolment over Secure Transport) is designed for device and IoT enrolment, using TLS for transport security. Well suited to modern REST-based environments.
- CMP (Certificate Management Protocol) is a mature, feature-rich protocol used in telecommunications, government and industrial PKI. Supports complex operations including key recovery and cross-certification.
- SCEP (Simple Certificate Enrolment Protocol) is common in Microsoft and mobile device management environments. Straightforward to implement but lacking the security features of newer protocols.
Protocol support determines which parts of your estate a platform can actually manage. A platform supporting only ACME will not address SCEP-based device enrolment, and the gap usually surfaces after purchase rather than before.
How to choose a CLM platform
The platform will become foundational infrastructure for trust, compliance and operational continuity. Key considerations:
- Multi-CA support. The platform should manage certificates from any CA rather than locking you to one vendor — public CAs, private enterprise CAs such as Microsoft AD CS or EJBCA, and cloud CA services.
- Deployment flexibility. On-premises, SaaS or hybrid. Air-gapped support where defence and government requirements apply.
- Discovery capability. Network scanning, agents, API integrations or a combination — and whether it reaches cloud providers, containers and legacy infrastructure.
- Automation depth. Whether the full lifecycle is automated, including deployment and the service reload that follows, and whether it integrates with DevOps pipelines and CI/CD.
- Integration ecosystem. Out-of-the-box connectors for SIEM, ITSM, PAM and HSM systems.
- Post-quantum readiness. Support for PQC algorithms and cryptographic discovery to inform migration planning.
- Licensing model. Per-certificate pricing behaves very differently at 47-day lifetimes than it does today. Stress-test any model against eight times your current renewal frequency before signing.
Our CLM vendor and licensing evaluation guide covers this in full, and inside an enterprise CLM deployment sets out the features that matter once you are live.
The CLM product landscape
The market has consolidated significantly. CyberArk's $1.54 billion acquisition of Venafi in 2024 reshaped the competitive landscape, while Keyfactor's acquisitions of InfoSec Global and CipherInsights in 2025 strengthened its cryptographic discovery and PQC capabilities.
- Keyfactor Command — native EJBCA integration, leading post-quantum support, and on-premises, SaaS and air-gapped deployment. The strongest fit for most mid-size and large enterprises.
- Venafi (CyberArk Certificate Manager) — the broadest integration ecosystem and the longest track record above one million certificates. Now being folded into CyberArk's identity security portfolio.
- DigiCert Trust Lifecycle Manager — cloud-based and CA-agnostic, strongest where DigiCert is already the primary CA.
- Sectigo Certificate Manager — cloud-native with strong ACME support and a dedicated SMB tier.
- Entrust PKI Hub — a container-based virtual appliance bundling CA, CLM, enrolment and validation in one deployment.
- Certdog by Krestfield — UK-developed CA and CLM platform, particularly strong in AD CS environments, with a free tier for smaller estates.
Other options include AppViewX CERT+, GlobalSign Atlas and LifeCycleX, Nexus Certificate Manager, HashiCorp Vault PKI for ephemeral certificates in DevOps environments, and AWS Private CA for cloud-native workloads.
Where CLM connects to everything else
CLM is rarely a standalone programme. It sits underneath two other initiatives most organisations are already running.
Zero Trust requires cryptographic proof of identity for every request. That proof comes from certificates, and it is only as reliable as the process managing them. Organisations frequently deploy Zero Trust tooling before their certificate estate can support it.
Crypto-agility and post-quantum migration depend on the same foundations: a complete inventory, and the ability to re-issue at scale without manual effort. Every capability the quantum transition will demand is a capability CLM builds first, which is why the two should be planned together rather than sequentially.
Unsung's certificate lifecycle management services
Unsung provides specialist certificate lifecycle management consultancy and technical delivery. We are vendor-neutral, working with whichever platforms and CAs suit your environment.
- Assessment and advisory — reviewing your current certificate inventory, PKI architecture and management processes to identify visibility gaps, governance weaknesses and efficiency improvements.
- Design and implementation — CLM solutions aligned to your security objectives and compliance requirements, supporting both internal PKI and cloud-based deployments.
- Automation integration — automated provisioning, renewal, revocation and policy enforcement, removing manual error and ensuring consistent governance.
- Monitoring and alerting — certificate status tracked across the estate, unknown certificates identified, and teams alerted before expiry affects services.
- Crypto-agility and PQC readiness — building the capability to change algorithms systematically rather than in a crisis.
Our consultants hold SC and DV security clearance and deliver across central government, defence, financial services, healthcare and transport. A PKI health check is usually the right starting point — it establishes what is actually deployed before any platform decision is made.
Frequently Asked Questions
What is the difference between PKI and CLM?
Why can't I manage certificates manually?
What is certificate discovery?
What happens when a certificate expires?
What is a Certificate Authority (CA)?
What protocols do CLM platforms use?
Do the 47-day certificate rules apply to internal certificates?
How does CLM support zero trust?
What is crypto agility and why does it matter for CLM?
What is the difference between CLM and a Certificate Authority?
How do I know if my organisation needs CLM?
How long does a CLM implementation take?
What is the difference between PKI and CLM?
Why can't I manage certificates manually?
What is certificate discovery?
What happens when a certificate expires?
What is a Certificate Authority (CA)?
What protocols do CLM platforms use?
Do the 47-day certificate rules apply to internal certificates?
How does CLM support zero trust?
What is crypto agility and why does it matter for CLM?
What is the difference between CLM and a Certificate Authority?
How do I know if my organisation needs CLM?
How long does a CLM implementation take?


