Once you accept that renewing certificates by hand won't survive a 47-day world, the obvious question is: what replaces it?
"Automation" is an easy word to say and a vague one to act on. So rather than sell you on a tool, this article lays out what good actually looks like inlcuding the principles behind a certificate process that scales, whatever products you use to get there, and a realistic place to start if you're beginning from spreadsheets and good intentions.
Principle 1: You can't manage what you can't see
Every durable solution starts in the same place - a complete, current inventory of every certificate you hold, across every environment: internal and public-facing, production and non-production, the ones attached to services and the ones buried in pipelines.
This sounds basic but it's also the step most organisations have never fully completed, which is exactly why expired-certificate outages keep happening. Automation built on top of an incomplete inventory just automates your blind spots. Visibility first, always.
Principle 2: Issuance and renewal should happen without a human in the loop
The core of lifecycle automation is simple: certificates should be requested, issued, deployed, and renewed by a system, triggered by policy and timing, not by a person remembering.
Done well, a renewal becomes a non-event. The system knows a certificate is approaching expiry, requests and validates a replacement, deploys it to the right place, confirms it's live, and logs the whole thing - with no ticket, no afternoon lost, and no risk of it being forgotten. The shorter the certificate lifespan, the more valuable this becomes, because the frequency that overwhelms a manual process is trivial for an automated one.
Principle 2b: Automating renewal isn't enough - validation is the step most plans miss
Here's the trap that catches even teams who think they've solved this: automating the renewal while leaving the validation manual.
Before a certificate authority issues a certificate, you have to prove you control the domain - domain control validation, or DCV. Until now, that proof could be reused for a long time (up to 398 days), so you could reissue certificates freely without re-proving anything. That reuse window is collapsing on the same schedule as certificate validity, and in the final phase it drops to just 10 days, shorter than the 47-day certificate itself.
The practical consequence is easy to miss and expensive to discover late: once the validation proof expires faster than the certificate, almost every renewal needs a fresh proof of domain control. Any workflow that still relies on a person clicking a validation email or pasting a DNS record - even occasionally - breaks at that cadence, no matter how well the renewal itself is automated.
So real lifecycle automation has to cover both halves: not just issuing and deploying certificates without a human, but proving domain control without one either. The teams who automate only the renewal and leave validation manual will find they've solved the easier half of the problem and left the half that actually breaks.
Principle 3: Shorter-lived, identity-bound certificates are a feature, not a threat
It's tempting to see shrinking validity purely as a burden, but once renewal is automated, short-lived certificates become genuinely better: less time for a compromised certificate to be abused, less reliance on long-lived credentials sitting around as a target, and a security posture that improves as a side effect of the automation you built for efficiency.
This is the reframe worth internalising: the teams who automate don't just cope with the new rules, they come out more secure than they were under the old ones.
Principle 4: One consistent approach, everywhere
Fragmentation is where automation often fails. If every environment, team, and platform handles certificates differently, you don't have one problem to solve, you have a dozen. A process that works in production but not in development, or for public certificates but not internal ones, leaves exactly the gaps that cause outages. Consistency across the whole estate is what turns automation from a patch into a posture.
Where to start
If this feels like a lot from a standing start, it is. But the first move is smaller than you'd think.
Start with visibility. Before any tooling decision, get an accurate picture of how many certificates you hold, where they live, and how often each will need renewing under the new schedule. That single exercise does two things: it tells you the true size of the problem (almost always bigger than assumed), and it gives you the baseline every later decision depends on.
From there, the path is incremental: automate the highest-volume, highest-risk certificates first, prove the model, and expand. You don't have to automate everything at once. You do have to start before the volume forces your hand.
The bottom line
Certificate lifecycle automation isn't a single product you buy, it's a shift from a process that depends on people to one that depends on policy. Visibility, automated issuance and renewal, short-lived identity-bound certificates, and consistency across environments: get those right and the 47-day deadline stops being a threat and becomes a non-issue. The hard part is rarely the technology, it's knowing where to start and having a partner who's done it before.
Talk to OneTeam IT about automating your certificate lifecycle - we'll help you find where to start. [Talk to OneTeam IT →] or [Calculate your renewal load first →]
