Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around.
Under the CA/Browser Forum's 2025 decision, Ballot SC-081v3, the maximum validity period for a publicly trusted TLS certificate is dropping on a fixed schedule: from 398 days to 200 on March 15, 2026, to 100 on March 15, 2027, and to 47 on March 15, 2029. The limits become part of the requirements for publicly trusted certificate authorities (CAs), with browser root programs enforcing compliance as a condition of trust. Organizations that need publicly trusted certificates cannot retain the old validity periods. The first maximum length certificates issued under the 200-day rule will begin expiring around early October 2026.
A certificate that renewed once a year in 2025 will need to be rotated roughly eight times a year in 2029. Across 200 certificates, that turns roughly 200 annual renewals into approximately 1,600 certificate replacements, or around six every business day. This could vary based on the organization scale and size, and you can check your impact here. For a monitoring team, that shift changes what the monitoring is for.
Why Monitoring Alone Won't Keep Up
If you run an observability practice, some form of a certificate expiration check is probably already in place, so visibility is rarely the whole problem. The harder issue is what happens after the alert. Monitoring can flag that a certificate is due or that a renewal failed, but the certificate still has to be renewed, deployed, and activated, and that work is what the schedule multiplies.
When a certificate lasted a year, that work was easy to absorb. It came up rarely, one certificate at a time, with weeks of slack to handle each one. Shorter lifespans make the same work recur far more often: several times a year across the publicly trusted certificate estate. A process that clears those renewals by hand then falls behind.
The mandate applies specifically to publicly trusted TLS certificates. Private PKI is not directly covered by Ballot SC-081v3. However, the same operational weaknesses appear in internal environments, particularly when organizations are already adopting shorter-lived private certificates as a security practice.
What ACME Solved and Where It Stops
There's already a working template for this, proven for years on web servers that use ACME. On many web servers, an ACME client can request a new certificate, install it, and reload the service to put it in use. That works because the whole chain is automated. A certificate that's issued but never installed protects nothing, so automating renewal without deployment solves very little.
Beyond common web server integrations, however, certificate automation often becomes uneven. Internal services, application key stores, appliances, and the load balancers in front of them can often get a certificate issued automatically over ACME or another CA integration. Yet there's rarely a built-in way to install it, update the relevant binding, and reload the service automatically the way there is on a web server, so that step stays manual or falls to a script someone maintains. With annual renewals, that was an occasional chore, but with eight renewals a year across the estate, it will become the part most likely to fall behind or fail unnoticed.
Automate the Chain and Let Monitoring Measure It
The way forward is to give the rest of the estate what the web tier already has. That means the same chain is automated from end to end, from discovery through renewal and deployment to the reload that puts the certificate in use. It should also include verification that the endpoint is actually serving the renewed certificate. That's a certificate life cycle management job.
A platform built for that job runs the chain: It discovers certificates by scanning for them, renews them across public and private CAs, and deploys the renewed certificates to load balancers, IIS bindings, Linux and Windows hosts, and cloud key stores. Once the required integrations and workflows are configured, a renewed certificate can reach the endpoint without a manual handoff in the middle.
Monitoring doesn't go away in that model, but its job changes. It now confirms the automation is keeping up: that renewals are completing across the estate and that nothing has slipped outside what the automation covers.
That means measuring the automation coverage, renewal success, deployment lag, reload failures, and number of certificates approaching a defined safety threshold. Additionally, monitoring also focuses on sending alerts for critical certificate renewals that can't be automated and require human intervention. That turns certificate management from a set of expiration alerts into an observable deployment pipeline.
Because the schedule is public, that load is countable in advance. Automate the renewal chain, monitor the outcomes, and treat certificate rotation as a continuously running operational pipeline. Then the 2027 and 2029 reductions will become planned capacity changes that the pipeline will handle on schedule, and missed renewal outages will drop from a recurring operational risk to a rare exception.
ManageEngine Key Manager Plus is one platform built to run this chain end to end, from discovery through renewal, deployment, and verification across public and private CAs. See how Key Manager Plus handles it.
