Certificate Lifecycle Management: The Operational Reality of Managing Digital Certificates at Scale

Here is a number worth sitting with. An organization managing 1,000 TLS certificates under the current 200-day validity limit must complete approximately 1,825 certificate renewal operations per year. Under the 47-day limit scheduled for March 2029, that same inventory requires roughly 7,750 renewal operations annually. That is not a larger version of the same problem. It is a categorically different operational challenge that breaks manual certificate management as a viable strategy.

Certificate Lifecycle Management (CLM) is the discipline — and increasingly the platform category — that exists to address this. At its core, CLM means maintaining accurate knowledge of every certificate in an organization’s infrastructure, ensuring none expire unnoticed, and automating as much of the renewal, deployment, and revocation process as the environment permits.

That definition is simple. The execution is not. This guide covers what CLM actually involves, where organizations consistently fail without it, what distinguishes a functional CLM approach from a nominal one, and how the 47-day validity trajectory changes what is required of any CLM program.

The Mathematics of Manual Certificate Management

Manual certificate management worked reasonably well when certificates lasted one to three years. A team could maintain a spreadsheet, set calendar reminders 30 days before each expiry, and handle renewals sequentially. The process was imperfect but survivable.

The CA/B Forum’s Ballot SC-081v3, approved in April 2025, established the following validity reduction schedule: 200 days maximum from March 15, 2026; 100 days from March 15, 2027; 47 days from March 15, 2029. Each stage roughly doubles the renewal frequency required for a given certificate inventory.

A human operator completing one certificate renewal per hour, working eight-hour days, can handle approximately 2,000 renewals per year. An organization with 1,000 certificates under 47-day validity needs 7,766 per year — nearly four full-time employees doing nothing but certificate renewals, assuming zero complications, zero vacation, and zero other responsibilities. This is why the CA/B Forum’s stated intent is explicit: the shortened validity periods are designed to force automation adoption. Manual renewal is not an option the math permits at 47 days.

The operational burden argument for CLM has been made for years but was easy to defer when annual renewal was sufficient. The 47-day timeline removes the deferral option. Organizations that have not built CLM capability by 2029 will face either continuous certificate-related outages or a crash automation implementation under time pressure. Starting in 2026, with 200-day validity already in effect, is the time to build the foundation.

What Certificate Lifecycle Management Actually Involves

CLM is not a product you install and walk away from. It is an ongoing operational capability that spans discovery, inventory management, issuance, deployment, monitoring, renewal, and revocation. Each stage has failure modes, and failure in any stage can result in expired certificates, service outages, compliance gaps, or security incidents.

Discovery: finding every certificate you have

Most organizations significantly underestimate their certificate inventory. Certificates are issued by multiple teams, on multiple CA accounts, by different individuals over years. Some are for production systems, some for test environments, some for developer workstations, some for internal tools. Some were issued by the IT team following a formal process. Others were obtained by development teams on their own accounts, never tracked centrally. Shadow certificates, as these undiscovered assets are called, are the leading cause of unexpected expiry incidents.

Active discovery involves scanning the network for active TLS certificates by connecting to every endpoint on every port and recording the certificate presented. This catches certificates on web servers, email servers, API gateways, load balancers, and any other service that terminates TLS. Passive discovery involves collecting certificates from network flow data, DNS records, and Certificate Transparency logs. CT log monitoring in particular surfaces certificates issued for your domains that your team may not know exist.

Discovery is not a one-time exercise. Certificates are constantly being issued, deployed, and changed. A CLM inventory that is not continuously refreshed drifts out of sync with reality within weeks.

Inventory and classification

A certificate inventory is only useful if it provides actionable information. A spreadsheet listing certificate names and expiry dates is an inventory but barely qualifies as management. A functional inventory records: the certificate’s location (which servers, load balancers, or CDNs are serving it), who is responsible for it, which CA issued it, what validation level it carries, whether it is publicly trusted or from a private CA, what service or application it supports, and when it must be renewed to avoid expiry.

Classification goes further: identifying certificates that use deprecated algorithms (SHA-1 signatures, RSA keys below 2048 bits, old cipher suite requirements), certificates that are not compliant with current CA/B Forum requirements, certificates that are approaching expiry, and certificates that are duplicated across multiple locations.

Issuance and enrollment

Certificate issuance in a CLM context means having defined, repeatable processes for requesting certificates — processes that capture the right information, route requests to the appropriate CA, complete domain control validation automatically where possible, and produce certificates with the correct Subject Alternative Names, validity periods, and key parameters from the outset.

The ACME protocol (RFC 8555) is the key enabling technology for automated issuance. ACME allows software to request, validate, and obtain a certificate without human intervention. Let’s Encrypt built its entire model on ACME. Most major commercial CAs now support ACME endpoints. An organization that has ACME-based issuance configured for its certificate inventory can request renewals automatically, regardless of whether the CA charges for the certificates.

Deployment

Issuance and deployment are separate operations that many CLM discussions conflate. A certificate can be issued (the CA produced it and it is available to download) without being deployed (no server is actually presenting it to clients). The gap between issuance and deployment is where many renewal incidents originate: the certificate file was written to disk but the web server was not reloaded, or the certificate was renewed at the CA level but the updated file was not distributed to all servers in the cluster, or the CDN edge nodes cached the old certificate.

A CLM program that treats deployment as part of the managed lifecycle — verifying after each renewal that the new certificate is actually being served from the external perspective — closes this gap. External verification using the live endpoint (not the file on disk) is the only reliable confirmation that a renewal was successful from the visitor’s point of view.

Monitoring and alerting

Certificate monitoring serves two distinct purposes. Pre-expiry alerting warns when a certificate is approaching its renewal deadline, giving time to complete renewal before expiry. Anomaly alerting flags unexpected changes: a certificate that was replaced without going through the normal renewal process, a new certificate issued for a domain that was not in the planned inventory, a certificate with an unexpected CA or validation level. Both types of alerting are necessary. Pre-expiry alerting prevents outages. Anomaly alerting detects unauthorized certificate issuance and configuration drift.

External monitoring — checking what certificate is being served to an actual client making a real connection — catches the deployment gap problem that internal monitoring misses. An internal monitor that checks the certificate file modification date or queries the CA’s issuance records confirms the certificate was renewed but not that it is being served.

Renewal

Automated renewal via ACME is the target state for any certificate that can be validated automatically. HTTP-01 or DNS-01 challenge validation can be automated for DV certificates across most infrastructure types. The renewal attempt should begin 30 days before expiry, with retry logic and escalation alerting if renewal fails. Post-renewal, automated deployment and external verification should confirm successful deployment within minutes.

OV and EV certificates require human identity re-verification and cannot be fully automated on the same cycle as DV certificates. Organizations that need OV or EV certificates in high volumes face a genuine tension between the CA/B Forum’s shortening validity periods and the human time required for re-verification. Some CAs are developing faster OV re-verification pathways. EV certificates may become impractical for very short validity periods as the 2027 and 2029 deadlines approach.

Revocation

Certificate revocation is the process of ending trust in a certificate before its natural expiry. Revocation is required when a private key is compromised, when a certificate was mis-issued, when the domain or organization it was issued to no longer owns or operates the relevant systems, or when the certificate configuration needs to be changed (different SANs, different key type) before the current certificate expires.

Revocation in practice has two parts: requesting revocation from the CA (who publishes the revocation in CRL and OCSP infrastructure) and replacing the revoked certificate with a new one on every endpoint that was using it. A CLM program with good deployment inventory makes the second part tractable: it knows exactly which servers were serving the revoked certificate and can target replacement deployment precisely.

Where Certificate Management Programs Break Down

Organizations that experience certificate expiry incidents typically have one or more of these structural failures. Understanding them is more useful than a checklist of CLM requirements.

The inventory problem: you cannot manage what you cannot see

The most fundamental CLM failure is an incomplete inventory. A certificate that is not in the inventory receives no monitoring, no renewal alerts, and no automated renewal. It expires when its validity period ends, and the first indication of the problem is a visitor or a monitoring system reporting a certificate error.

Inventory completeness is harder than it sounds. An organization’s infrastructure changes continuously. New services are deployed, new certificates are issued, old services are decommissioned (sometimes without revoking their certificates). Keeping the inventory synchronized with the actual deployment state requires either continuous discovery scans or reliable integration between certificate issuance and deployment systems so every issued certificate is automatically registered in the inventory.

The ownership problem: nobody is responsible

In many organizations, certificate ownership is unclear. A certificate was issued two years ago by a team member who has since left. The application it supports is maintained by a different team. Nobody receives the renewal alerts, nobody monitors the expiry date, and when it expires, the incident postmortem cannot identify who should have acted.

Assigning clear ownership for every certificate — a named owner, a team email alias, and an escalation path if the owner is unavailable — is a prerequisite for any CLM program. Ownership information belongs in the inventory alongside the technical certificate details.

The deployment gap: renewed but not deployed

A certificate renewal that completes at the CA level but does not update the actual served certificate is a failed renewal from the visitor’s perspective. This gap is more common than most post-mortems reveal. The certificate file was written to the wrong path, the web server was not reloaded, one server in a cluster received the new certificate but others did not, or the CDN continued serving the old certificate from cache.

Post-renewal external verification closes this gap. Any CLM program that considers the renewal complete when the certificate is issued — rather than when external verification confirms it is being served — has a structural failure that will produce incidents.

The scope problem: only public TLS certificates are managed

Public-facing web servers are the most visible certificate holders, but most enterprise environments have far more certificates than those. Internal services, APIs, message brokers, database connections, mTLS service mesh configurations, code signing certificates, email signing certificates, and device identity certificates all have lifecycles. An organization that manages public TLS certificates carefully but ignores internal certificates will have internal service outages caused by expired certificates that are harder to diagnose because they do not produce browser-visible warnings.

The Post-Quantum Cryptography Dimension

CLM is becoming more complex precisely as it becomes more urgent, because shortening validity periods coincide with the beginning of post-quantum cryptography migration. NIST finalized its first post-quantum algorithm standards in 2024 (FIPS 203, 204, 205), and guidance from major regulatory bodies and standards organizations is now pointing organizations toward beginning the migration from RSA and ECC to quantum-resistant algorithms.

For CLM, post-quantum migration means: inventorying not just certificate expiry dates but also the cryptographic algorithms in use across the certificate estate, identifying which certificates and which key pairs are at risk from quantum cryptanalysis (primarily RSA and ECC key pairs), planning migration timelines that align with certificate renewal cycles, and building the CLM infrastructure to issue and deploy post-quantum algorithm certificates when CAs begin offering them.

The organizations that will complete post-quantum migration with least disruption are those with mature CLM programs. If you know every certificate in your environment, know who owns it, can renew and deploy it automatically, and have external verification confirming deployment, migrating algorithm by algorithm is a managed operational process rather than an urgent crisis.

The 47-day certificate validity period and post-quantum cryptography migration are being discussed in the security community as the two major drivers of CLM investment in 2025 and 2026. Both reward the same underlying capability: continuous, automated, verified certificate renewal with complete inventory visibility. An organization building CLM capability for the 47-day transition is also building the foundation for its post-quantum migration.

Build, Buy, or Automate: CLM Approaches for Different Scales

The right CLM approach depends on the size of the certificate inventory, the complexity of the infrastructure, and the available operational capacity. Not every organization needs an enterprise CLM platform. Some do, and should start building now.

Open-source and low-cost options for smaller deployments

cert-manager is a Kubernetes-native certificate controller that handles issuance, renewal, and deployment of certificates within Kubernetes clusters. It integrates with Let’s Encrypt via ACME and with commercial CAs that support ACME endpoints. For organizations running modern container infrastructure, cert-manager provides automated certificate lifecycle management for workloads in the cluster without requiring a separate CLM platform.

step-ca from Smallstep is an open-source private CA that provides ACME-based certificate issuance for internal infrastructure. It handles short-lived certificates well and integrates with existing identity providers for authentication. For organizations that need a private CA with automated renewal, step-ca is a capable open-source option that avoids the cost of commercial private CA infrastructure.

Where to Start: Building CLM Capability Incrementally

A comprehensive CLM program is not built in a week. The operational practices that prevent certificate incidents can be built incrementally, starting with the highest-risk gaps.

• Week 1: Inventory audit. Run a CT log search for all certificates issued for your domains. Use a tool like crt.sh or SSL Labs’ API to find every publicly visible certificate for your domain. Compare this to what your team believes you have. The gap is your shadow certificate risk.
• Week 2: Monitoring baseline. Set up external certificate monitoring for every domain you know about. UptimeRobot, StatusCake, and similar services provide SSL expiry monitoring for free or low cost. Set alert thresholds at 30 days and 14 days before expiry.
• Month 1: Automate your highest-risk renewals. Identify which certificates are most likely to expire unnoticed. Certificates managed by individuals rather than teams, certificates on non-standard ports, certificates for internal services. Implement ACME automation for any DV certificate that can support it.
• Quarter 1: Assign ownership. Every certificate in the inventory should have a named owner and a team email alias. This single practice prevents the most common cause of missed renewals: nobody was responsible.
• Quarter 2: Deploy external verification. Add post-renewal verification to every renewal process: a check from outside the server confirming the new certificate is being served. This catches the deployment gap before it becomes a visitor-visible incident.
• Year 1: Evaluate CLM platform need. With inventory, monitoring, and basic automation in place, assess whether the certificate volume and infrastructure complexity justify a dedicated CLM platform. For most organizations under 200 certificates, the practices above are sufficient. Above 500, a dedicated platform usually pays for itself in prevented incidents.

Frequently Asked Questions

What is certificate lifecycle management?

Certificate lifecycle management (CLM) is the set of processes and tools that govern the complete lifecycle of digital certificates within an organization: discovering all certificates in use, maintaining an accurate inventory, automating issuance and renewal, verifying successful deployment, monitoring for expiry and anomalies, and managing revocation when certificates must be retired early. The goal is ensuring no certificate expires unnoticed, no unauthorized certificate goes undiscovered, and no renewal process is dependent on a single person’s memory or a manual calendar reminder.

Why is certificate lifecycle management suddenly more urgent?

The CA/B Forum’s April 2025 ballot reducing TLS certificate validity to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029) multiplies the renewal operations required for any certificate inventory. Under 47-day validity, an organization managing 1,000 certificates must complete approximately 7,750 renewal operations per year. This volume is impossible to manage manually at any realistic staffing level. The shortened validity periods are designed to force automation adoption. Organizations without CLM programs face exponentially increasing operational burden and outage risk as each deadline takes effect.

What is the difference between CLM and just using Certbot?

Certbot automates the renewal of Let’s Encrypt certificates on individual servers. It handles one specific renewal path (Let’s Encrypt via ACME on a server with HTTP access) and provides no inventory, no ownership tracking, no anomaly detection, no support for other certificate types (OV, EV, code signing, client certificates), and no support for certificates issued by commercial CAs or deployed to cloud services. CLM is the broader discipline that includes all certificate types, all CAs, all deployment targets, and the organizational practices (ownership, monitoring, audit) that prevent incidents across the full portfolio. Certbot is a CLM tool for one narrow use case.

What are shadow certificates and why do they matter?

Shadow certificates are certificates issued for an organization’s domains that the IT or security team does not know exist. They are typically issued by developers on personal CA accounts, by teams bypassing formal certificate procurement, or through automated processes that never registered the certificate in a central inventory. Shadow certificates expire without warning because nobody is monitoring them. They may also be configured with insecure parameters, issued from untrusted CAs, or represent security gaps if they cover sensitive production infrastructure. Certificate Transparency log monitoring — checking CT logs for any certificate issued for your domains — is the most reliable way to detect shadow certificates.

What is crypto agility and how does it relate to CLM?

Crypto agility is the organizational capability to replace cryptographic algorithms across a certificate estate rapidly, without service disruption, when a new vulnerability is discovered or when algorithmic standards change. It requires knowing what algorithm every certificate uses, having the operational processes to re-issue certificates with new algorithms, and being able to deploy the new certificates to the relevant endpoints quickly. A mature CLM program that provides full inventory visibility and automated deployment is the foundation of crypto agility. Organizations without CLM capability discovered this painfully during the SHA-1 deprecation period (2015-2016) and will face it again during the post-quantum migration.

Does every organization need a dedicated CLM platform?

No. For small organizations with under 50 to 100 certificates that are all DV and can be automated via ACME, a combination of Certbot (or acme.sh), external certificate monitoring, and a maintained inventory spreadsheet provides adequate CLM. A dedicated CLM platform becomes cost-effective when the certificate volume is high enough that inventory management and cross-CA visibility require automation, when certificate types include OV, EV, or private CA certificates that require different management, or when compliance requirements (PCI DSS, healthcare regulations) require audit trails and formal certificate governance that a spreadsheet cannot provide.