Certificate Lifecycle Management: What Breaks and How to Automate It

Certificate lifecycle management is the practice of discovering, issuing, deploying, renewing, and revoking certificates across an organization. Most teams have a certificate authority and no lifecycle management, which is why expired certificates remain one of the most common causes of self-inflicted downtime.

That is about to get harder. The CA/Browser Forum approved Ballot SC-081v3 in April 2025, phasing maximum public TLS certificate validity from 398 days down to 47 days between 2026 and 2029. A yearly renewal is a calendar entry. A six-weekly renewal across a few hundred certificates is a full-time job, or an automation problem.

This is what the lifecycle actually involves, where it breaks, and what to automate first. For the concepts see PKI, X.509, and certificate lifecycle.

The six stages

1. Discovery and inventory

You cannot renew what you do not know about, and every organization has certificates nobody remembers: on a forgotten load balancer, inside a container image, on a vendor appliance, issued from an internal CA that was decommissioned. Discovery scans network ranges, certificate transparency logs for your domains, and cloud provider certificate stores.

The output that matters is not a list, it is a list with an owner against each entry. An inventory of 4,000 certificates with no owners is an inventory you cannot act on.

2. Issuance and enrolment

How a certificate request is authenticated and approved. For public TLS this means domain control validation, usually over ACME. For private PKI it means an enrolment protocol appropriate to what is enrolling:

• ACME for anything that can run a client, including internal services against a private CA
• SCEP for network equipment and older device fleets
• EST for devices needing a modern, TLS-based enrolment path
• CMP in industrial, telecommunications, and utility estates

The security question at this stage is what proves the requester is entitled to the identity in the certificate. For workloads, platform attestation answers it better than a shared enrolment secret. See workload identity.

3. Deployment and installation

The stage that quietly defeats automation. A certificate is issued and then has to reach the load balancer, the Kubernetes secret, the Java keystore, the appliance's web console, and every replica. Where deployment is manual, renewal cadence is limited by human availability regardless of how automated issuance is.

4. Monitoring and renewal

Expiry monitoring should be independent of the issuing system, because the failure mode you are guarding against includes the issuing system not renewing. Alert on time-to-expiry with enough lead time to act, and alert on renewal failures rather than only on expiry, which is too late.

5. Revocation and key rotation

Revocation through CRL and OCSP has never worked well at internet scale, which is a large part of why the industry chose shorter lifetimes instead. Treat revocation as necessary for private PKI, where you control the clients, and as unreliable for public certificates, where expiry is the real control.

Key rotation matters more than most teams treat it. Renewing with the same key indefinitely means a key compromised years ago is still valid today. Generate a new key pair on renewal.

6. Ownership and governance

The stage nobody assigns. A certificate is a machine credential, so it needs the same things every other non-human identity needs: a named owner, a known expiry, a rotation path, and a record of where the private key lives. Without ownership, the other five stages produce reports rather than outcomes.

What the 47-day schedule actually changes

Three things break under a six-weekly cadence:

Manual renewal stops being viable. A process that works for 50 certificates once a year fails at eight times the frequency. Anything still renewed by a human needs an automation path or a plan to move it behind something that has one.

Deployment automation becomes the bottleneck, not issuance. ACME solves getting the certificate. Getting it onto the appliance that only accepts a manual upload through a web console is the remaining work, and it is usually the argument for putting such systems behind a reverse proxy that can automate.

Certificate inventory accuracy becomes operationally critical. At annual renewal, an unknown certificate fails once a year. At 47 days it fails eight times a year, which at least surfaces the problem faster.

Note the scope: the CA/Browser Forum requirements bind public CAs. Private CAs can still issue long-lived certificates, and many organizations will. That is a legitimate choice for internal service-to-service traffic, and a bad habit if it means internal certificates are never rotated.

Device certificates specifically

Device estates are the hardest case and they follow different rules:

• Enrolment must be attestable. The device needs to prove it is the device, ideally through a hardware root of trust such as a TPM or secure element rather than a shared enrolment password.
• Lifetimes are longer by necessity. A device deployed in the field for ten years cannot be treated like a web server, which is why private PKI with SCEP, EST, or CMP dominates here.
• Renewal has to survive intermittent connectivity. Renew early and tolerate failure, rather than assuming a device is online at the moment its certificate expires.
• Revocation actually matters, because you control the relying parties and can enforce it, unlike on the public web.

What to automate first

1. Public-facing TLS. Highest outage risk, best automation support. ACME against a public CA, with Let's Encrypt or a commercial CA depending on your requirements. See the Let's Encrypt challenge types documentation for how validation works.
2. Kubernetes workloads. cert-manager turns certificate lifecycle into a controller you install once, whether the issuer is a public CA, a private CA, or a secrets platform.
3. Internal service-to-service. Move to short-lived certificates issued on platform attestation rather than long-lived ones distributed by configuration management. SPIFFE and SPIRE are the vendor-neutral pattern; see our open-source machine identity guide.
4. Device fleets. Last, because it is the hardest and the lifetimes are longest, but plan the enrolment attestation story before you scale.

Build or buy

Open-source PKI is capable enough to run in production: EJBCA for full enterprise hierarchies with SCEP and CMP, step-ca for lightweight ACME-native internal CAs, Dogtag inside FreeIPA estates. Our open-source PKI comparison covers the trade-offs.

Commercial certificate lifecycle platforms earn their cost on discovery breadth across heterogeneous estates, integration with the appliances and platforms you cannot automate yourself, and the reporting a regulated environment needs. See the PKI and certificate lifecycle vendor category.

The decision usually comes down to how heterogeneous your estate is. A cloud-native environment with everything behind load balancers and Kubernetes can automate with open-source tooling. An estate with network equipment, industrial systems, and appliances across multiple vendors is where a commercial platform pays for itself.

Primary sources

• CA/Browser Forum Ballot SC-081v3, the certificate validity reduction schedule
• CA/Browser Forum Baseline Requirements, the rules public CAs operate under
• RFC 8555: Automatic Certificate Management Environment (ACME)
• Let's Encrypt: challenge types, for how domain control validation works in practice

Related reading

• What is machine identity
• Top 6 open-source PKI and certificate management tools
• Top 5 machine identity management platforms
• mTLS and certificate lifecycle