If you have worked in IT or web administration for more than a decade, you likely remember a time when managing SSL/TLS certificates was a relaxed, infrequent ritual. You purchased a certificate, installed it on your server, and essentially forgot about it for three, or sometimes even five, years. It was a “set it and forget it” task, a minor line item on a long-term maintenance schedule.
Those days are decisively over. The lifespan of digital trust is collapsing.
In 2020, Apple unilaterally pushed the industry standard down to 398 days, roughly one year. More recently, Google has signaled its intention to reduce validity periods for public trust certificates even further, aiming for a 90-day maximum. Meanwhile, security best practices and automated authorities are already operating on cycles as short as 47 days SSL [199 days max from February 24, 2026 (DigiCert) and March 12-14, 2026 (Sectigo/GlobalSign)].
This rapid compression isn’t just a bureaucratic headache designed to annoy system administrators. It represents a fundamental shift in the architecture of the internet. We are moving from a model of long-term static trust to one of short-term, dynamic verification. Understanding why this is happening is essential for any organization that wants to remain secure, and online, in the coming years.
The Myth of Revocation
To understand why certificates are getting shorter, we first have to admit a dirty secret of the PKI (Public Key Infrastructure) industry: certificate revocation is broken.
Theoretically, if a private key is stolen or a certificate is misissued, the Certificate Authority (CA) “revokes” it. Browsers are supposed to check a list, either a Certificate Revocation List (CRL) or via the Online Certificate Status Protocol (OCSP), to see if a website’s certificate is still valid.
In practice, this system is unreliable. CRLs are large files that can slow down browsing, so browsers often don’t download them in real-time. OCSP lookups can fail or time out; when they do, many browsers default to “soft fail,” meaning they accept the certificate anyway to avoid breaking the user experience.
This creates a dangerous gap. If a hacker steals your private key today, and your certificate is valid for another year, they can effectively impersonate your website for that entire year. Even if you revoke the certificate, there is no guarantee that every user’s browser will respect that revocation.
Short-lived certificates solve this problem by making revocation redundant. If a certificate expires every 47 days, the window of opportunity for an attacker is drastically smaller. Expiration is the only revocation mechanism that works 100% of the time, on every device, without requiring an external lookup. By forcing certificates to expire quickly, the industry ensures that compromised keys become useless automatically, usually within weeks rather than years.
The Era of Crypto Agility
Beyond the immediate threat of stolen keys, there is a looming, existential threat on the horizon: quantum computing.
We are currently in a transition period known as “post-quantum cryptography” (PQC). The mathematical algorithms that currently secure the internet (like RSA and ECC) will eventually be breakable by sufficiently powerful quantum computers. When that day comes, or when a significant vulnerability is found in a current algorithm, the entire internet will need to switch to new encryption standards overnight.
This concept is called “Crypto Agility.” It is the ability to replace cryptographic primitives across an entire infrastructure without tearing the system down.
Long-lived certificates are the enemy of crypto agility. If you have thousands of certificates valid for 398 days scattered across your network, and a vulnerability is discovered in the encryption method they use, you are looking at a year-long migration project to replace them. You cannot simply flip a switch if the certificates themselves are hard-coded to expire next year.
By normalizing shorter validity periods, we train our infrastructure to be agile. If we are already replacing certificates every few weeks, swapping out the underlying cryptographic key during one of those renewals becomes a routine operational task rather than a panic-induced emergency. Short lifecycles ensure that the global fleet of certificates is always fresh and capable of adopting the latest security standards.
Goodbye Spreadsheet
Perhaps the most tangible impact of this shift is on the daily operations of IT teams. For years, “Certificate Lifecycle Management” was often a synonym for “a spreadsheet saved on the SysAdmin’s desktop.”
When you only have to renew a certificate once a year, manual management is tedious but sustainable. You get an email reminder, you generate a Certificate Signing Request (CSR), you pay the invoice, you validate the domain, and you install the file.
When that timeline shrinks to just a couple of weeks, the workload quadruples. If you have 50 certificates, you are suddenly dealing with 200 renewal events a year. If you move to a 47-day cycle, you are dealing with hundreds. At this scale, manual management is no longer just difficult; it is mathematically impossible to sustain without error. A single missed email or a sick day during a renewal window results in an expired certificate and a public outage.
The push for shorter validity is, effectively, a mandate for automation. Tech giants like Google and Apple know that by shortening the window, they are forcing organizations to abandon manual processes. They are pushing the industry toward protocols like ACME (Automated Certificate Management Environment), where servers talk directly to Certificate Authorities to renew credentials without human intervention.
While this forces a painful transition period for organizations still relying on legacy processes, the end state is a more robust internet. Automated systems don’t forget renewal dates. They don’t make copy-paste errors. They don’t go on vacation. By making manual management impossible, the industry is making outages less probable.
Why 47 Days?
You might hear the number “90 days” referenced regarding Google’s proposal, but “47 days” is increasingly cited as the operational sweet spot. Why this specific number?
It comes down to simple risk mathematics. If a certificate is valid for 47 days, you cannot wait until day 46 to renew it. If something goes wrong, a validation failure, a network issue, a billing hiccup, you need a buffer zone to resolve it before the site goes dark.
A 47-day cycle (or roughly 45 days) ensures that a certificate is never “stale.” It aligns with the cadence of modern DevOps sprints and CI/CD pipelines. It means that every month and a half, your organization is proving its identity and refreshing its cryptographic posture. It turns security from an annual compliance hurdle into a continuous, breathing part of your infrastructure.
Ending Notes
The shift to shorter validity periods is inevitable. To survive the move to shorter validity cycles, you must replace manual processes with automation and crypto-agility. Don’t let your security crumble. Visit Certera – a global Certificate Authority, for trusted SSL and Code Signing Certificates, and PKI solutions that keep your infrastructure secure, compliant, and always online.
