The TLS Certificate Lifecycle Is Being Cut to 47 Days
Certificate lifetimes drop from 398 to 47 days between 2026 and 2029. See the exact dates, the renewal workload each phase creates, and what an automated lifecycle looks like.
The TLS Certificate Lifecycle Is Being Cut to 47 Days - Don't Panic.
For most of the last decade, a public TLS certificate was a once-a-year task. You requested it, installed it, put a reminder in a calendar, and forgot about it for twelve months. That model is already gone, and by 2029 it will be unrecognisable.
In April 2025 the CA/Browser Forum adopted Ballot SC-081v3, a fixed schedule that reduces the maximum lifetime of publicly trusted TLS certificates from 398 days to 47 days. The first phase took effect on 15 March 2026. Two more follow. This article walks through what the certificate lifecycle actually consists of, what changes on which date, and what the increased renewal frequency means in terms of hours and risk.
What the certificate lifecycle actually is
"Certificate management" sounds like a single task. It is at least six, and every one of them repeats on every renewal cycle:
- Discovery and inventory - knowing which certificates exist, on which hosts, terminating which services. This is the step most organisations underestimate, because certificates get issued by teams that never report them centrally.
- Key generation and CSR creation - producing a key pair and a certificate signing request with the correct subject, SANs, and key algorithm.
- Validation - proving to the Certificate Authority that you control the domain (Domain Control Validation, DCV) and, for OV/EV certificates, that your organisation is who it claims to be (Subject Identity Information, SII).
- Issuance - the CA signs and returns the certificate chain.
- Deployment - installing the certificate on every endpoint that serves it: web servers, load balancers, reverse proxies, API gateways, mail servers, appliances, container images.
- Monitoring and renewal - tracking expiry, revoking when keys are compromised, and starting the cycle again before the certificate lapses.
Under a 398-day lifetime, a slow or partly manual process was survivable. The cycle ran once a year and there was room for error. As the lifetime shrinks, each of these six steps has to run more often, faster, and with less margin.
Why the industry is shortening lifetimes
The CA/Browser Forum's stated reasoning, set out in the SC-081v3 ballot text, is that a certificate is a snapshot of reality at the moment of issuance. The longer it remains valid, the more likely it is that the information it attests - domain ownership, organisational details, key control - no longer matches the facts. Domains change hands, keys leak, companies restructure.
Revocation exists to handle this, but the Forum's position is that revocation infrastructure (CRLs and OCSP) does not scale or perform reliably enough at internet scale to be the primary defence. A shorter lifetime limits the damage window without depending on any party taking action. A secondary effect, acknowledged in the ballot, is that shorter lifetimes push the ecosystem towards robust automation.
Reasonable people disagreed about the pace. Five CAs abstained from the vote, with SECOM Trust Systems noting that shortening from 100 to 47 days is a steep step whose security benefit is hard to demonstrate relative to the adaptation cost subscribers will bear. The ballot nonetheless passed with no votes against, and all four major browser vendors - Apple, Google, Microsoft, and Mozilla - voted in favour.
The reduction schedule: exact dates
The limits apply based on the date a certificate is issued, not the date it was ordered. Certificates issued before a cutoff keep their original validity period until they expire.
| Effective date | Max certificate validity | DCV reuse period | SII reuse (OV/EV) | Practical renewal cadence |
|---|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 398 days | 825 days | ~1× per year |
| 15 Mar 2026 (in effect) | 200 days | 200 days | 398 days | ~2× per year |
| 15 Mar 2027 | 100 days | 100 days | 398 days | ~4× per year |
| 15 Mar 2029 | 47 days | 10 days | 398 days | ~8× per year |
Two details that catch teams out:
- CAs issue below the cap. The Baseline Requirements pair each hard limit (MUST NOT exceed) with a softer target (SHOULD NOT exceed) one day lower - 397, 199, 99, 46. In practice CAs issue at or under the lower figure and often build in an extra buffer, so a "200-day" certificate is typically 199 days or less.
- The 10-day DCV window in 2029 is the real change. At that point domain control must be re-proven on essentially every renewal. Email-based and manual file-placement validation stop being viable for production; DNS-01 or HTTP-01 automation becomes the only workable path.
What this costs in practice
The workload scales linearly with renewal frequency. PwC Germany published a worked example based on 500 public TLS certificates, four hours of effort per manual renewal, and 1,600 working hours per FTE per year:
| Year | Validity | Renewals per year | Hours | FTEs required |
|---|---|---|---|---|
| 2025 | 398 days | ~450 | 1,800 | 1.15 |
| 2026 | 200 days | ~900 | 3,600 | 2.30 |
| 2027 | 100 days | ~1,800 | 7,200 | 4.50 |
| 2029 | 47 days | ~3,600 | 14,400 | 9.00 |
An eightfold increase in a labour-intensive process, over three years, against a hiring market that will not supply eight additional PKI-literate engineers. That is the structural problem: the workload grows on a fixed schedule while the team does not.
The failure mode is well documented. CyberArk's 2025 State of Machine Identity Security Report, based on a survey of more than 1,200 security leaders, found that 72% of organisations had experienced at least one certificate-related outage in the preceding year - up sharply from prior years - with 45% reporting outages weekly, against 12% in 2022. In the same survey, 34% of organisations still managed machine identity lifecycles manually.
An expired certificate is not a degraded experience. It is a hard failure: browsers block the page with an interstitial warning, API clients refuse the connection, and integrations fail. The costs are lost transactions, support load, reputational damage, and - where the affected service falls under DORA, NIS2, or similar regimes - a compliance conversation.
The multiplier effect for MSPs and service providers
For managed service providers, systems integrators, and hosters, the numbers above are a per-client figure. An MSP running 40 client environments with 20 public certificates each is not looking at 500 renewals a year - it is looking at 800 certificates across 40 separate trust boundaries, each with its own CA account, DNS provider, change window, and approval chain.
Three problems compound in that setting:
- Fragmented visibility. Certificates are tracked per client, often in whatever the client's previous provider left behind. There is rarely one view that answers "which certificates across our entire book expire in the next 14 days?"
- Onboarding drag. Every new client arrives with an unknown certificate estate. Discovering it, taking ownership, and migrating renewals into a repeatable process is manual work that scales with client count, not with revenue.
- Contractual exposure. When an expired certificate takes down a client's shop or API, the SLA credit, the emergency out-of-hours response, and the trust damage all land on the provider - regardless of who originally installed the certificate.
At a 47-day cadence, per-client scripts and per-client calendars stop being a viable operating model. What replaces them is a single multi-tenant control plane: one inventory across all clients, per-client isolation and delegated access, ACME automation that runs unattended, and expiry reporting that can be handed to the client as evidence rather than reconstructed on request.
For providers who do not want to build and staff that themselves, the alternative is a managed service - the certificate lifecycle operated as a service, with the provider retaining oversight and client-facing reporting but not the on-call burden.
What a workable lifecycle looks like
The teams that handle this well tend to have the same four things in place:
- A complete inventory. You cannot automate what you have not found. Network-wide discovery, not a spreadsheet, and reconciled against a CMDB so coverage is provable.
- ACME as the default issuance path. Certificate issuance treated as an API-driven service rather than a ticket workflow.
- Automated deployment. Issuance alone is not enough; the certificate has to reach every endpoint and the service has to reload. Deployment is where most partial automations break.
- Independent monitoring and clear ownership. Expiry alerting that does not depend on the same system doing the renewal, and a named owner per certificate that survives staff turnover.
The first phase is already behind us. The 100-day phase arrives in March 2027, which leaves roughly eight months to move from inventory to working automation - and inventory alone typically takes longer than teams expect.
Where aethercert fits
aethercert is one option in this space: a platform for automated TLS certificate lifecycle management, ACME-based or API-based issuance and renewal, deployment to endpoints, and expiry monitoring - designed so that the 2027 and 2029 phases are a configuration change rather than a hiring problem.
For MSPs and service providers, it is built around multi-tenancy rather than bolted on afterwards: separate client tenants under one operator view, so renewals across the whole book run unattended and a new client's estate can be discovered and brought into the same process without a bespoke setup each time. Where a provider would rather not run the platform at all, the same lifecycle is available as a managed service - aethercert operates issuance, renewal, and deployment, and the provider keeps the client relationship and the reporting.
It is not the only approach. Larger enterprises may already have a CLM platform; smaller estates on a single stack may get most of the way with Certbot and a well-tested cron job. The question worth answering before comparing tools is a simpler one: do you currently know how many public TLS certificates your organisation owns, and could you replace all of them within 24 hours if you had to? If the answer to either half is no, the 2027 deadline is the constraint to plan against.
FAQ
When do 47-day certificates start? 15 March 2029. Certificates issued before that date keep their original validity period.
Does this affect internal or private CA certificates? No. The CA/Browser Forum Baseline Requirements govern publicly trusted TLS certificates only. Many organisations choose to align internal policy anyway, since the tooling is shared.
Are wildcard and multi-domain certificates exempt? No. The schedule applies to all publicly trusted TLS certificates, across DV, OV, and EV, including wildcards and SAN certificates.
We are an MSP - do we need one system per client or one across all of them? Technically either works, but per-client tooling stops scaling around the 100-day phase, because the operational load grows with the number of tenants rather than the number of certificates. A multi-tenant control plane with per-client isolation keeps onboarding and expiry reporting a single process instead of one per contract.
Can I stockpile long certificates before a cutoff? Only in a limited sense. A certificate issued at 199 days on 14 March 2027 remains valid for its full term, but this buys one cycle at most and delays rather than removes the problem.
Sources
- CA/Browser Forum - Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (April 2025) - voting record, ballot text, and rationale
- CA/Browser Forum - all posts and ballots - current and subsequent ballots affecting the Baseline Requirements
- PwC Germany - Reduktion der Gültigkeitsdauer von öffentlichen TLS-Zertifikaten auf 47 Tage (November 2025, German) - FTE and workload projection
- CyberArk - 2025 State of Machine Identity Security Report - outage frequency and automation maturity survey data