There’s a question worth asking your security team this week: How many TLS certificates does the organization hold, and what percentage of them renew without a human touching them? If the first answer is an estimate and the second is a shrug, you’re looking at a governance gap that picked up a hard deadline last year.
The validity of your SSL/TLS certificates is already dropping
In April 2025, the CA/Browser Forum, the industry body where certificate authorities and browser makers set the rules of public trust, passed ballot SC-081v3, which cuts the maximum lifespan of public TLS certificates on a fixed schedule. The limit dropped to 200 days in March 2026, drops again to 100 days in March 2027, and settles at 47 days in March 2029. Unlike most compliance timelines, this one can’t be lobbied against or phased in on your own terms, because browsers enforce it at the root store level. Every organization with a public-facing service is already inside the schedule.
The security reasoning behind the change is sound. Shorter lifespans shrink the window during which a compromised or misissued certificate stays dangerous, and they move the ecosystem toward the crypto-agility that NIST’s post-quantum migration guidance assumes. What the schedule also changes is whose problem this is.
Why this belongs on the risk register
An expired certificate is, in practice, an availability incident, with customers seeing error pages, APIs that stop responding, and partner integrations failing closed. Under DORA, an availability incident at a financial entity can trigger regulatory reporting obligations, and NIS2 applies similar logic to essential and important entities across the European Union. An outage caused by a forgotten renewal is both self-inflicted and, depending on your sector, reportable.
What the mandate changes is the frequency of that exposure rather than its nature. A certificate that renewed once a year will renew roughly every six and a half weeks by 2029, which, for a mid-size estate of 500 certificates, works out to around 3,900 renewal events a year, or about 15 every working day. Each of those events is routine, and each is also an opportunity for the failure described above. This also comes with potential business impact for your organization—you can check the potential impact on yours here.
How to find out where you stand
The useful next step is finding out where you currently stand as an organization. Four questions in a quarterly conversation will do it, and what matters in each case is understanding what the answer tells you.
How is our certificate inventory produced?
If certificates are found by regularly scanning the network, the inventory can be trusted, and every other answer in this conversation rests on solid ground. If it’s a list someone maintains by hand, every other answer is only as reliable as that list, because nobody can renew, automate, or take ownership of a certificate they don’t know exists. That’s why this question comes first.
What percentage of renewals happen without a human touching them?
If the answer is, “We use ACME,” that deserves real credit, since ACME-managed web servers have handled short lifespans well for years. The follow-up that tells you more is what fraction of the estate ACME actually reaches, because the load balancers, keystores, and appliances behind the web tier usually sit outside it, and those manually renewed leftovers are where expiry outages tend to originate.
Who owns certificate operations?
The answer you want is a named owner with a renewal metric. At a renewal every six and a half weeks, certificate operations becomes routine work in the way patching is routine work, and routine work without an owner, a metric, and an escalation path is where things get dropped.
Could we switch certificate authorities in 30 days?
This one looks ahead rather than at the present. Certificate authority (CA) acquisitions and distrust events have happened repeatedly, and when they happen, affected organizations have to reissue at scale on someone else’s timeline. If your renewal automation only works with one CA, the outage risk you solved has become a concentration risk. The answer you want is that tooling and processes would carry over to another CA without being rebuilt.
Where the math points
If those answers came back shaky, there are several ways to absorb the added load, including more headcount, a smaller public footprint, or outsourcing the function entirely, and some organizations will choose each of those. For most, though, the practical answer is automation, since the work is routine, high-frequency, and well understood. Certificate life cycle management platforms such as ManageEngine Key Manager Plus automate the chain from discovery through issuance, renewal, and deployment across multiple certificate authorities, which also keeps the 30-day CA-switch question answerable.
The useful precedent here is patching, which moved a decade ago from a tribal-knowledge task to a governed, automated hygiene function with executive visibility, because the frequency of the work left no realistic alternative. Certificates are making the same transition now, on a published schedule with fixed milestones. Organizations that make the move before March 2027 will treat this as a solved problem, and those that wait will end up doing the same work later with less room to plan it.
