Most companies treat TLS certificates as background noise. Something renews them, nobody is entirely sure what, and roughly once a year a site drops for forty minutes while someone hunts down the login for a registrar account that belongs to a contractor who left in 2023.
That arrangement survived for a decade because certificates lasted a year. It will not survive what is already happening to certificate lifetimes.
What actually changed, and when
In April 2025 the CA/Browser Forum approved Ballot SC-081v3, a proposal sponsored by Apple that caps how long a publicly trusted TLS certificate may live. Every public certificate authority in the browser root programs has to comply. The schedule is fixed and it is not optional:
- Since 15 March 2026: 200 days maximum, down from 398. This phase is already in force, so any certificate you issued this year is already shorter than the one you issued last year.
- 15 March 2027: 100 days maximum.
- 15 March 2029: 47 days maximum.
The same ballot also cuts the reuse period for domain validation data. By 2029 a CA can lean on a prior validation for only ten days. Combine the two numbers and a single 47-day certificate needs roughly thirty-five separate domain validations a year. Those validations used to happen once, as a side effect of the original order.
Let's Encrypt is moving faster than the baseline. Its six-day certificate profile went generally available in January 2026, its 45-day profile arrived in May 2026, and its default profile drops to 64 days in February 2027. Google Trust Services already issues custom lifetimes down to single-digit days.
Private internal CAs are not covered by any of this. If your certificates come from an internal PKI, the rules do not bind you. Most companies still have a surprising number of publicly trusted certificates on internal-facing endpoints, partner APIs, mail gateways and admin panels that were exposed once and never moved back.
Short lifetimes are a different problem, not a faster version of the old one
The usual reaction to the 47-day number is to schedule a reminder more often. That misreads what changed.
Certificate lifetimes are shrinking largely because revocation does not work. Browsers and operating systems check revocation inconsistently, so a stolen key stays usable until the certificate expires no matter what the CA publishes. The industry's answer is to make expiry happen sooner. A 47-day certificate is a revocation mechanism that cannot be ignored, because the clock is short enough that the exposure window is small.
The consequence for operations is that a failed renewal stops being a nuisance and becomes a deadline with no grace period. There is no "we'll deal with it Monday." At 398 days a team could absorb a broken renewal for a quarter and still ship. At 47 days, two missed renewals mean an outage, and at six days, one missed renewal is a same-night emergency.
The failure also moves somewhere less obvious. Manual renewal fails because a person forgets. Automated renewal fails because a permission silently died: the DNS API token got rotated during a security cleanup, the service account that writes to the load balancer was disabled when someone left, a WAF rule added in March now blocks the challenge path, the ACME client's version is too old to speak the current profile. Those failures are invisible until the day the certificate is needed, which is exactly the worst day to discover them.
Where renewal pipelines break
Across the estates we audit, the same three patterns account for almost every certificate incident.
The certificate has no owner
A public certificate is terminated at a CDN, a hardware load balancer, a VPN concentrator, an email security appliance, or a partner's API gateway. Automated issuance needs a place to write: a file on a host, a secret store, or a vendor API. When the device terminating TLS has no usable API, a cron job cannot help you, and nobody notices the gap until the device's support contract lapses along with its certificate.
The inventory is usually the real problem. Teams routinely discover certificates they did not know existed, because the person who ordered them left and the renewal notice went to a shared mailbox that nobody reads.
The private key lives in six places at once
Certificates get mounted as Kubernetes secrets, baked into container images, copied onto VMs by hand, pasted into an nginx config, and stored in a wiki. Renewal updates one copy. The other five go stale. The symptoms are distinctive and infuriating: HTTPS works on two of five pods, works from the office but not through the CDN, works on the old hostname but not the new one.
Copying a certificate is cheap and feels harmless, which is why it happens. The fix is not discipline, it is architecture. One store owns the certificate and everything else reads from it at runtime.
The challenge still needs a human
HTTP-01 validation breaks when a WAF blocks /.well-known/acme-challenge/, when a redirect chain mangles the request, or when the origin sits behind a proxy in a mode that intercepts unknown paths. DNS-01 validation breaks when a single person holds the only registrar login, or when the API token was scoped to a zone that was renamed.
The durable pattern is to delegate only the validation record to a zone the pipeline controls, then give the pipeline its own credential with a short rotation cycle. If a certificate renewal depends on a human logging into a registrar, it is not automated. It is manual with extra steps.
What a defensible setup looks like
Start with an inventory you did not write yourself. Certificate Transparency logs are public. Pulling every entry for your domains from a CT log search reveals certificates issued for hostnames nobody on the team remembers provisioning. It is the fastest way to find the ones that will expire unnoticed.
Use the CA's renewal advice, not a fixed timer. ACME Renewal Information lets a client ask the CA when to renew, and it accounts for incidents and mass revocations that a hardcoded "renew at 30 days" rule cannot. Most current clients support it, and it costs nothing to enable.
Store once, distribute at runtime. Whether the store is a secrets manager, a cloud certificate service, or a cluster-native secret, there should be exactly one authoritative copy. Distribution happens by reference, not by file copy.
Monitor from outside the renewal path. The most common outage pattern is a monitoring system that shares fate with the thing it watches. If the same automation that renews the certificate also reports on it, then a broken automation produces silence, and silence looks healthy. Probe the endpoint from a different network with a different credential and parse the certificate's actual notAfter value.
Set thresholds against lifetime, not against a constant. A 30-day warning makes sense for a 398-day certificate. On a 47-day certificate it fires with two thirds of the life remaining and trains everyone to ignore it, and on a six-day certificate it never fires before the certificate is already gone. Alert at roughly a third of remaining life and escalate at a seventh. For a 47-day certificate that is about 15 days and 7 days. For a six-day certificate it is two days and twenty hours.
A sequence that avoids the crunch
- Inventory every public certificate, its terminating device, its current renewal mechanism, and the human who owns it. Include the ones found in CT logs.
- List the manual steps in each renewal and file them as tickets. This is the backlog that matters, and it is usually shorter than people fear.
- Delegate the validation zone and issue a scoped, rotating credential to the pipeline. Remove the personal-account dependency before shortening anything.
- Consolidate to a single certificate store and change consumers to read from it at runtime.
- Enable ARI, then move one non-critical domain to the 45-day profile. Run it for a full quarter before touching production.
- Add external expiry monitoring that does not depend on the renewal automation.
- Only after those are stable, shorten the rest.
The order matters. Teams that shorten lifetimes first spend the next quarter debugging renewals under time pressure, on live traffic, with no inventory to tell them what broke.
The numbers worth watching
Four metrics separate teams that will be fine in 2029 from teams that will be firefighting:
- Percentage of certificates issued and deployed with no human in the loop. Anything below 95% is a risk register entry.
- Time from issuance to deployment. Manual steps show up here as hours or days, and at 47 days of validity, a two-day gap is five percent of the certificate's life.
- Renewal failures per month that required a human to fix. Track the cause behind each one, since the causes cluster around expired credentials and DNS permissions.
- Days of remaining life at the moment of the first alert. If that number is drifting down, the monitoring is decaying alongside the automation.
Renewal is a machine identity problem
Every certificate renewal is an authenticated action performed by a machine. The pipeline needs a credential, that credential needs to be scoped, and it needs to rotate on a schedule that does not depend on a person remembering. That is the same shape as the secret sprawl and over-privileged service account problems most teams are already working through for cloud access.
Which is also why the deadline is less interesting than it looks. Companies that finish this work in 2026 will mostly do it as a side effect of projects they already had queued: moving static secrets into a manager, removing hand-copied configuration, giving automation its own identity instead of borrowing a human's. The certificate change is a forcing function for work that pays for itself anyway.
The teams that wait will do the same work in a weekend, after an outage, with an executive asking why the storefront returned a security warning to every customer for eleven minutes. The technical work is identical. Only the cost differs.
Where to start this week
Pull your domains from a CT log search and compare the result against your asset inventory. If the second list is shorter, you have certificates nobody is tracking. That gap is the actual starting point, and it exists in almost every organisation that has been running long enough to accumulate acquisitions, abandoned marketing domains, and one-off partner integrations.
Tech Hub Services builds and audits certificate automation for enterprise platforms, storefronts and partner integrations, including ACME delegation, external expiry monitoring, and migration off hand-managed certificates. If you want a second pair of eyes on your inventory before the 2027 deadline lands, get in touch.
