For years, renewing TLS certificates was an annual chore. You bought a certificate, set a calendar reminder, and forgot about it until next year. That era is officially over.
The CA/Browser Forum — the industry body where certificate authorities and browser vendors agree on the rules of public trust — has approved a stepwise reduction of public TLS certificate lifetimes. The maximum validity drops in stages over the coming years, from today's 398 days down to 200 days, then 100 days, and finally 47 days by 2029. Domain validation reuse periods shrink alongside it.
In other words: a certificate you renew once a year today will need to be renewed roughly every six weeks by the end of the decade.
Why is this happening?
This is not browsers being difficult. There are two solid security reasons behind the change.
Smaller compromise windows. When a private key leaks or a certificate is mis-issued, revocation is supposed to fix it. In practice, revocation checking has always been unreliable — many clients simply ignore it. The only mechanism that reliably limits the damage is expiry itself. A stolen certificate that dies in 47 days is a much smaller problem than one that stays valid for a year.
Faster crypto agility. When the industry needs to move away from a weak algorithm, deprecated root, or flawed validation method, the transition can only complete as fast as the oldest valid certificate expires. Short lifetimes mean the whole ecosystem can rotate to new cryptography in weeks instead of years. That property is about to matter a lot — more on post-quantum below.
What breaks at 47 days
Most organizations manage certificates the same way they did a decade ago: a spreadsheet with expiry dates, a shared mailbox for CA reminder emails, and one engineer who "knows where the certs are."
That process barely works at one renewal per year. At eight renewals per year, per certificate, it collapses:
- The spreadsheet is always stale. Nobody updates it after that emergency Friday renewal, and the certificate that was "temporarily" issued for a test system never makes it in at all.
- The renewal ritual becomes a treadmill. Generating a CSR, opening a ticket, waiting for approval, downloading the bundle, converting formats, deploying to three servers, restarting services — multiply that by every certificate, every 47 days.
- Forgotten certificates become outages. This is not theoretical. Some of the most visible outages of recent years have been traced back to a single expired certificate — Microsoft Teams went down globally in 2020 for exactly this reason, and an expired certificate in Ericsson's equipment knocked out mobile data for millions of users across several countries in 2018. If a yearly cadence produces these incidents, a 47-day cadence with manual processes will produce far more.
The uncomfortable truth: manual certificate management does not scale down to 47 days. The change effectively makes automation mandatory.
What a modern certificate process looks like
Teams that handle this well converge on the same pipeline.
1. Automated discovery. You cannot renew what you cannot see. Discovery combines network scanning (finding TLS endpoints across your ranges and ports) with reading server certificate stores directly, so internal certificates that never touch the network edge are found too. The output is a living inventory — not a spreadsheet.
2. Protocol-based issuance. The ACME protocol — the standard behind Let's Encrypt, now supported by most commercial CAs — lets servers request, validate, and receive certificates automatically. For internal PKI, the same automation applies against AD CS or a private CA.
3. Approval-gated issuance. Automation does not mean anarchy. Requests for sensitive domains should pass through an approval workflow before issuance, so security keeps control without becoming a bottleneck.
4. Automated deployment. Issuing a certificate is half the job; the outage happens when it never reaches the server. Renewed certificates should land on nginx, Apache, and IIS automatically, with services reloaded — no ticket, no SSH session, no 2 a.m. copy-paste.
5. Expiry monitoring as a safety net. Even with full automation, you monitor. Alerts on approaching expiry and failed renewals catch the edge cases before your customers do.
The post-quantum clock is ticking too
Short lifetimes are also preparation for a bigger transition. NIST standardized the first post-quantum cryptography algorithms in 2024, and migration to them is already on the roadmap of every serious security program — partly because of the "harvest now, decrypt later" threat, where adversaries record encrypted traffic today to decrypt it once quantum computers can.
An organization that can rotate every certificate in 47 days has, almost for free, the crypto-agility needed to swap algorithms when the time comes. An organization that still renews by hand does not.
Certificates are machine identities
One more shift in perspective. A certificate is not just a padlock icon — it is the identity of a machine or workload, and machine identities now vastly outnumber human ones in a typical enterprise. Every server, container, load balancer, and service-to-service connection carries one.
Seen that way, it is natural that certificate management is converging with identity security. Privileged access management platforms already govern the credentials of humans and service accounts; certificate lifecycle management extends the same discipline — inventory, ownership, rotation, audit — to machine identities.
That is exactly the approach behind Monopam's Certificate Manager: automated discovery across networks and server stores, issuance through ACME, AD CS, or a built-in CA, and agentless renew-and-deploy to nginx, Apache, and IIS — with approvals and expiry monitoring in the same platform that already governs your privileged access.
The 47-day era rewards teams that automate early. If your certificate inventory still lives in a spreadsheet, this is a good year to retire it.
