Certificate Lifecycle Management for 47-Day Certificates

Certificate lifecycle management (CLM) is the discipline of knowing every certificate you have, who owns it, and when it expires, then issuing, deploying, renewing and revoking certificates without anyone having to remember to do it. With public TLS certificates heading to a 47-day maximum lifetime by 2029, CLM stops being a nice-to-have and becomes the only way to keep the lights on.

Most organizations have more certificates than they can name. That was survivable when a certificate lasted a year or more and renewal was a calendar reminder and a ticket. It isn’t survivable when the same certificate needs replacing roughly eight times a year.

A common version of this: Picture the usual expired certificate outage. A certificate on a load balancer or an internal API gateway expires on a Saturday, the renewal reminder went to someone who changed teams, and the first alert is customers or partners reporting errors. The fix takes minutes once someone finds the right certificate. Finding it, getting access to the device and getting an emergency change approved takes hours. The cost is rarely the certificate. It’s the downtime and the people pulled in to chase it.

What is certificate lifecycle management?

A certificate is a machine identity. It tells a browser, an API client or another server “this really is payroll.example.com,” and it carries an expiry date that nobody can negotiate with. Certificate lifecycle management is the process (and usually the tooling) that tracks that identity from request to retirement.

It’s worth framing it that way because it puts CLM where it belongs: alongside the rest of identity. We spend a lot of energy governing human accounts and privileged access. Machine identities often outnumber human ones, and the certificates behind them tend to be managed by whoever happened to set up the server. If you’re building the identity pillar of a Zero Trust program, machine identities belong in scope from day one.

The six stages of the certificate lifecycle

Every CLM product slices this a little differently, but the stages are the same.

Stage	What happens	What goes wrong when it’s manual
Discovery and inventory	Find every certificate on endpoints, load balancers, cloud services and CA logs; record owner, issuer, expiry and where it’s installed	Certificates nobody knows about, so nobody renews them
Issuance	Request a certificate from the right CA, with the right key type, validity and fields, under policy	Wrong key sizes, wildcards everywhere, certs bought on a credit card outside any process
Deployment	Install the certificate and private key on every system that needs it	Private keys emailed around, one renewed copy and three forgotten ones
Monitoring	Watch expiry, configuration and policy compliance; alert the owner	Expiry alerts sent to a distribution list for someone who left in 2022
Renewal	Replace the certificate (ideally with a new key) before it expires	The outage
Revocation	Kill a certificate early when a key is compromised or a system is retired	Compromised keys left valid because nobody knows how to revoke, or who’s allowed to

Discovery comes first, and it’s always bigger than you think

Discovery is where every CLM program starts, and it’s the stage people underestimate. Certificates live in places the network scan won’t find: inside appliances, in Java keystores, in cloud load balancers spun up by a project team, on the printer fleet. Public certificates at least show up in Certificate Transparency logs, which makes them easier to find. Certificates from your internal CAs don’t.

A good inventory answers four questions for every certificate: where is it installed, who issued it, when does it expire, and who owns it. That last one is the hardest.

What this usually looks like: Teams going into a first discovery scan usually expect a number close to their spreadsheet. What comes back is typically several times larger: self-signed certificates on appliances, internal certificates on servers nobody listed, copies of the same wildcard on dozens of hosts, and a fair share already expired and still installed. The useful reaction isn’t panic. Sort by what’s in use and exposed, find owners for those first, and treat the expired leftovers as cleanup.

Certificate expiration: the CA/Browser Forum’s 47-day timeline

In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for publicly trusted TLS certificates, approved Ballot SC-081. It phases down the maximum validity of public TLS certificates in steps, and it shrinks how long a CA can reuse a previous domain validation.

Effective date	Max TLS certificate validity	Max domain validation reuse
Before March 15, 2026	398 days	398 days
March 15, 2026	200 days	200 days
March 15, 2027	100 days	100 days
March 15, 2029	47 days	10 days

As this post goes up, the first step is less than two weeks away. From March 15, 2026, there is no such thing as a “one-year” public certificate: the most you can buy is a little over six months. The 100-day step follows a year later.

The domain validation column matters as much as the lifetime. At 10 days of reuse, you’re effectively proving control of the domain every time you renew. That’s easy when it’s automated through DNS or HTTP challenges. It’s miserable when it’s an email to a webmaster address that routes to nowhere.

The reasoning behind the change is simple enough. Shorter certificates limit how long a mis-issued or compromised certificate stays useful, and they reduce dependence on revocation checking, which has never worked as well as anyone hoped. They also force organizations to automate, which is the point. When the cryptography itself has to change, as it will with the post-quantum transition, automated renewal is how you roll new algorithms out across the estate without a multi-year project.

For the authoritative text, go to the CA/Browser Forum and look up SC-081 in the ballots list.

Why manual certificate renewal stops working

Manual renewal works when the volume is low and the lifetime is long. A team with 200 public certificates at roughly a year each handles about 200 renewals a year, under one a working day. Someone can do that with a spreadsheet and patience.

Cut the lifetime to 47 days and the same 200 certificates generate well over 1,500 renewals a year, around six or seven every working day. Each one involves generating a key, requesting the certificate, passing domain validation, installing it everywhere it lives, and checking that the service picked it up. Nobody is doing that by hand for long, and the person who tries will eventually go on vacation.

Shorter lifetimes also remove the slack. With a one-year certificate, a renewal that slips a week is an annoyance. With a 47-day certificate, a broken renewal job has a few weeks of buffer at most before something user-facing breaks.

How to automate certificate renewal

ACME

ACME (Automatic Certificate Management Environment, RFC 8555) is the protocol that made free, automated certificates normal. A client on the server, or a CLM platform acting on its behalf, requests a certificate, proves control of the domain through a DNS record or an HTTP file, receives the certificate, installs it and schedules the next renewal. No human in the loop.

Most public CAs now support ACME, including the commercial ones. The ACME Renewal Information (ARI) extension adds a useful refinement: the CA can tell the client when to renew, which lets a CA spread out renewals or ask for early replacement after an incident.

ACME covers a lot, but it doesn’t cover everything:

• Appliances and legacy systems that can’t run an ACME client still need a deployment path, usually through a CLM platform’s connectors or an API on the device.
• Domain validation at scale needs DNS API access, and that means deciding who gets to write TXT records in which zones. That’s an access control decision, so treat it like one.
• Private key handling still matters. Automation that copies keys to a shared drive isn’t an improvement.

My rule of thumb: if a system can’t be renewed without a human logging into it, it goes on a list, and that list gets a plan now, not when the 47-day limit is a year away.

What to look for in a CLM tool

You can build a good chunk of CLM from open-source ACME clients, your CA’s APIs and a decent inventory. Many organizations still buy a platform once the estate gets large. Whether you buy or build, check for:

1. Discovery across network scans, CA integrations, cloud accounts and CT logs
2. Multi-CA support, because you will have more than one, public and private
3. ACME and API-based automation for issuance and renewal, with connectors for the load balancers and appliances you actually run
4. Ownership and workflow, so alerts go to a named owner and policy is enforced at request time
5. Reporting that tells you what will expire in the next 30 days and what’s non-compliant with your key and algorithm policy

That last point pays off twice. An inventory that records key type and algorithm is the start of a cryptographic inventory, which is where post-quantum readiness begins.

Who owns a certificate? (Usually nobody)

Ask who owns certificates and you’ll typically hear “the PKI team,” “security,” or “the app team,” depending on who’s in the room. In practice the PKI team owns the CAs, the app team owns the server, and the certificate itself falls in the gap.

CLM only works when ownership is explicit:

• The PKI or crypto team owns policy: approved CAs, key types, validity, who can request what.
• The service owner owns the certificate on their service, including making renewal automatic.
• Security operations owns monitoring for rogue certificates and responding to key compromise.

Every certificate in the inventory should map to a person or a team with a current email address, not a distribution list. When ownership is assigned, automation has someone to escalate to when it fails. When it isn’t, automation fails silently, which is worse than manual renewal because nobody is even watching the calendar.

What I’d look for: Ownership that sticks is usually tied to something that already exists. I’d map certificates to the application or service owner in the CMDB, make owner a required field at request time so nothing new is issued without one, and have the CLM tool route expiry alerts to that person, escalating to their manager if unresolved. What makes it last is the mover/leaver process: when an owner changes roles, their certificates get reassigned like any other asset.

Internal PKI vs. public certificates

SC-081 applies to publicly trusted TLS certificates, the ones browsers trust out of the box. It does not apply to certificates issued by your own private CAs, such as Microsoft AD CS or a cloud private CA. You set those lifetimes yourself.

That’s not a reason to relax. A few points I’d make to anyone planning around the timeline:

• Don’t use public certificates for internal-only systems if you can avoid it. You inherit the 47-day schedule, and you publish your internal hostnames to Certificate Transparency logs for anyone to read. A private CA is usually the better fit for internal services.
• Check how you use public certificates beyond web servers. Browser root programs are pushing public TLS hierarchies toward server authentication only, so if you’ve been using public certificates for client authentication or other non-web purposes, talk to your CA about what changes.
• Short-lived internal certificates are a good idea anyway. The same logic that justifies 47 days for the public web applies inside, and once renewal is automated, a shorter lifetime costs you very little.
• OT is different. Certificates on controllers, HMIs and field devices live under different constraints: limited connectivity, long equipment lifecycles, and change windows measured in months. They usually belong under a separate private PKI with its own policy. I covered that split in What Is PKI?, and the OT security primer explains why those environments play by different rules.

Where to start

Don’t start by buying a tool. Start by finding out what you have. Run discovery, build the inventory, and assign an owner to every certificate that matters. Then sort the inventory into three buckets: already automated, can be automated with ACME or an API, and can’t be automated without changes. The third bucket is your real project.

Aim to have every public certificate on automated renewal before the 100-day limit takes effect on March 15, 2027. If you get there, 47 days in 2029 is a configuration change. If you don’t, it’s an outage calendar.

More on certificates and crypto readiness lives in the PKI hub.