The countdown to a quiet but massive change in how TLS certificates are managed has already started. The CA/Browser Forum has officially approved a schedule to gradually reduce the maximum lifetime of public TLS certificates until they are limited to just 47 days in 2029. On paper, this improves web security. In practice, it directly impacts the day-to-day work of system administrators, platform engineers and DevOps teams around the world.
The question is no longer if this will affect organisations, but whether they are ready for a world where manual certificate renewals simply stop being viable.
From 398 days down to 47: a timeline that changes everything
Until now, public TLS server certificates could be issued with a maximum lifetime of 398 days. That already required some tracking of expiration dates, but many organisations still relied on manual processes, spreadsheets or scattered reminders.
With the CA/Browser Forum’s new decision, that window will be shortened in several stages:
- Until 15 March 2026
- Maximum TLS certificate lifetime: 398 days
- Maximum reuse of domain/IP validation: 398 days
- From 15 March 2026
- Maximum certificate lifetime: 200 days
- Maximum reuse of domain/IP validation: 200 days
- From 15 March 2027
- Maximum certificate lifetime: 100 days
- Maximum reuse of domain/IP validation: 100 days
- From 15 March 2029
- Maximum certificate lifetime: 47 days
- Maximum reuse of domain/IP validation: 10 days
In practice, this means that from 2029 onwards, operations teams will have to assume certificate renewal cycles of roughly 45 days to keep a safety margin. Without automation, the risk of unexpected expirations and service outages will be huge.
Why certificate lifetimes are being shortened so aggressively
The reasoning from the CA/Browser Forum and major players like Apple and Google is straightforward: the longer a certificate stays in circulation, the less trustworthy the information inside it becomes.
- Domain ownership or control can change over time.
- Old validation data (via email, DNS or HTTP) loses value as months go by.
- The traditional revocation system (CRL, OCSP) has performance and reliability issues and is often ignored by browsers in failure scenarios.
Shorter lifetimes reduce the impact of compromise: if a private key is leaked or a domain changes hands, the associated certificate will have a much shorter window of abuse. At the same time, organisations are forced to re-validate domain and identity data more frequently, avoiding “zombie” certificates based on outdated checks.
Apple, which pushed hardest for this aggressive reduction, has openly argued that the industry has been sending the same message for years: without automated certificate lifecycle management, the current model is not sustainable. With this schedule, that message stops being a recommendation and becomes an operational requirement.
The end of “set-and-forget” certificates
For sysadmins, the shift is deep. The era of buying a certificate, installing it once a year and forgetting about it until browsers start throwing red warnings is over.
With lifetimes of 200, 100 and finally 47 days:
- Manual inventories of certificates will become a constant source of errors.
- “Hand-crafted” renewals across dozens or hundreds of servers will turn into a bottleneck.
- A simple oversight (failing to renew a certificate on an internal API, a load balancer or a remote appliance) can lead to recurrent outages.
On top of that, cutting domain/IP validation reuse down to just 10 days in 2029 makes manual processes even more painful: teams will not only be renewing certificates constantly, but also repeating domain validation much more frequently. Operationally, this is incompatible with occasional tickets or one-off maintenance tasks.
Automate or fail: the new reality for TLS infrastructures
In this context, the conclusion is clear: not using automation for certificate renewal becomes operational madness.
For system and DevOps teams, this translates into several concrete workstreams:
- Adopt ACME broadly
- Integrate ACME clients (
certbot,acme.sh,lego, or commercial agents) into every point where certificates are used: web servers, reverse proxies, load balancers, API gateways, security appliances, etc. - Take advantage of the fact that some advanced CAs already support ACME not only for DV, but also for OV and EV certificates via extensions such as ACME Renewal Information (ARI).
- Integrate ACME clients (
- Centralise lifecycle visibility
- Build a single view of all certificates: expiry dates, type (DV/OV/EV), issuing CA, automation status.
- Integrate alerts and dashboards with monitoring systems (Prometheus, Grafana, Zabbix, etc.) and notification tools (Slack, Teams, email, PagerDuty, and so on).
- Integrate automation into the infrastructure itself
- Use orchestration tools such as Ansible, Terraform, Puppet or Chef to deploy and update certificate configurations in a repeatable way.
- Implement automated certificate updates for services that do not integrate easily with ACME directly, using scripts or hooks if necessary.
- Design infrastructure around frequent rotations
- Avoid setups where a certificate is “baked into” multiple appliances with no clear update path.
- Minimise services that require manual intervention or maintenance windows just to change certificates.
- Normalise the use of short-lived certificates even before 2029 to “stress-test” renewal workflows under more frequent rotation.
Impact on hybrid, legacy and edge environments
System administrators know that not all infrastructure is ready for this new world.
- In legacy environments, older devices or systems without good ACME support can become weak points.
- In multi-cloud and hybrid deployments, where services span on-prem, public clouds and edge locations, certificate management was already complex; with 47-day lifetimes it becomes much more so.
- DevOps and sysadmin teams will need to revisit internal APIs, microservices, TLS tunnels, VPNs and network appliances that rely on certificates for mutual authentication, not just public websites.
The drastic reduction in lifetime forces organisations to take a hard look at every place where TLS is used and answer an uncomfortable question: how many of our certificates still depend on someone SSH’ing into a box and running three manual commands?
Revocation under scrutiny… and short lifetimes as a workaround
The CA/Browser Forum is also implicitly acknowledging another reality: the traditional revocation system is not reliable. CRLs and OCSP suffer from latency, availability and adoption issues, and many browsers choose to ignore revocation checks in failure scenarios to avoid degrading user experience.
The adopted solution is pragmatic: if revocation cannot be trusted, shorten the lifetime. This way, even if revocation is not applied correctly, the window of risk for a compromised certificate is much smaller.
In this direction, the Forum already approved short-lived certificates in 2023 (7-day validity) that do not require CRL or OCSP support at all. The trend is clear: rely less on real-time revocation, more on fast expiry and automation.
What about cost for companies?
A frequent concern among CA customers is whether this change implies paying more because certificates are replaced more often. Major providers have clarified that their model is based on annual or multi-year subscriptions, not on charging per individual issuance.
In other words: if an organisation already has an active subscription with a CA, it can issue and renew certificates within that period without extra per-rotation fees, as long as it stays within the contract limits.
In fact, many CAs report that once customers adopt automation, they voluntarily move to shorter lifecycles, because it stops being an operational burden and clearly improves security.
Are ops and sysadmin teams really ready?
For sysadmin-focused media and communities, the strategic question is simple:
- Are there still certificates managed in spreadsheets?
- Are there critical services that depend on a single technician “remembering” to renew them?
- Is ACME adoption extended beyond the main public reverse proxy?
- Are there parts of the infrastructure where an expired TLS certificate would make not only a website unavailable, but also internal processes, backups or third-party integrations?
With the CA/Browser Forum schedule now approved, the grace period is limited. The coming years – especially the step down to 100 days in 2027 and, above all, 47 days in 2029 – will be a real-world test of how mature certificate automation processes are in organisations of all sizes.
Shorter TLS certificate lifetimes are undoubtedly a security improvement. But they are also a direct message to system administrators: the era has definitely arrived where certificate lifecycle management must be as automated as the applications themselves.
Frequently asked questions about the new TLS certificate lifetimes
How will the move to 47-day certificates affect my servers?
In practice, it will force you to design automatic renewal processes. Renewing once a year will no longer be enough: every server or service using TLS will need to integrate with an issuance and deployment workflow (ACME, DevOps pipelines or a certificate lifecycle management platform) that can handle frequent rotations.
Is it still realistic to renew certificates manually under the new rules?
Technically yes, but operationally no for most organisations. With a maximum lifetime of 47 days and domain validation reuse limited to just 10 days, manual procedures will inevitably lead to expirations, outages and an unsustainable workload for sysadmin teams.
What should system administrators start doing now?
Build a complete inventory of certificates, identify those that are not automated, roll out ACME clients wherever possible, integrate expiry alerts into monitoring systems, and experiment with shorter lifecycles (for example, 60 or 90 days) well before the new limits become mandatory.
Do the new limits affect DV, OV and EV certificates in the same way?
They are treated the same in terms of maximum TLS certificate lifetime. However, there are differences in how validation data is handled and reused: OV and EV certificates include Subject Identity Information (SII) such as company name and legal details, and the reuse period for that data will also be shortened, forcing more frequent re-validation of corporate information associated with those certificates.
