Certificate validity periods have shrunk from five years to one year—and they’re about to get even shorter. Here’s why it’s happening, who benefits, and why small IT teams are paying the price.
This week I renewed a TLS certificate for a client’s booking website. The old certificate was due to expire on 26th March. The new one, freshly issued, expires on 9th October. Not 26th March next year—9th October this year. A one-year certificate that doesn’t actually last a year from when you install it.
This is an Organisation Validated (OV) certificate for a site that takes payments. It required email verification, phone callbacks, and identity checks against official company records. And I’ll be doing it all again in about six months.
It wasn’t always like this. Not long ago, I was renewing these certificates every three years. Before that, every five years. Now it’s effectively twice a year, and if the browser vendors get their way, it could soon be four times a year.
This isn’t a technical improvement. It’s a burden being imposed on the entire industry by a handful of enormous companies who have the infrastructure to automate their way around it—and apparently no understanding of how the rest of us work.
How We Got Here
TLS certificate validity periods are set by the CA/Browser Forum, a consortium that includes certificate authorities (the companies that issue certificates) and browser vendors (the companies that decide which certificates to trust). In practice, the browser vendors hold all the power—if Google or Apple decide not to trust certificates longer than a certain validity, certificate authorities have no choice but to comply.
Here’s how the maximum validity period has changed over the years:
Before 2015: Up to 5 years
2015: Reduced to 3 years
2018: Reduced to 2 years
2020: Reduced to 398 days (approximately 1 year)
Proposed: 90 days, possibly as soon as 2027
Google has been particularly aggressive in pushing for shorter validity periods. Apple unilaterally decided in 2020 that Safari would reject any certificate valid for more than 398 days, forcing the rest of the industry to follow. The direction of travel is clear: certificates are going to keep getting shorter.
The Official Justification
The security argument for shorter certificate validity goes like this: if a certificate is compromised (either the private key is stolen, or the certificate was issued fraudulently), a shorter validity period limits how long that compromised certificate can be abused.
This sounds reasonable until you think about it for more than a few seconds.
We already have a mechanism for dealing with compromised certificates: revocation. Certificate authorities can revoke a certificate the moment they learn it’s been compromised, and browsers can check revocation status before trusting a certificate.
The problem is that revocation checking is a mess. OCSP (Online Certificate Status Protocol) has reliability and privacy issues. CRLs (Certificate Revocation Lists) are too large and slow. Most browsers have given up on hard-fail revocation checking—if they can’t reach the revocation server, they just trust the certificate anyway.
So instead of fixing revocation infrastructure—which would be hard engineering work—the browser vendors have decided to make certificates expire faster. It’s not a solution to the security problem; it’s an admission that they can’t be bothered to solve it properly. And the cost of this workaround falls entirely on the people who have to manage certificates.
Who Actually Benefits
Let’s be honest about who wins from shorter certificate validity:
Big tech companies have already built automated certificate management into their infrastructure. Google, Amazon, Microsoft, Apple—they issue and renew certificates programmatically at massive scale. Shorter validity periods don’t cost them anything; they’ve already solved the problem.
Automation vendors benefit from pushing more organisations towards automated certificate management tools. If you can’t manage certificates manually anymore, you need to buy their products.
That’s about it. Everyone else loses.
Certificate authorities don’t benefit—you pay for a year’s certificate regardless of how many times you have to renew it. They’re doing more validation work, more support, more issuance transactions, all for the same money. They’re getting squeezed just like the rest of us.
Small IT teams, managed service providers, and anyone who has to deal with certificates that can’t be fully automated are left with more work, more complexity, and more opportunities for something to go wrong—which brings us to the real problem.
The Problem With Organisation Validated Certificates
There are three types of TLS certificate:
Domain Validated (DV): The CA verifies that you control the domain. This can be fully automated using protocols like ACME (used by Let’s Encrypt). Issue a certificate in seconds, renew it automatically, job done.
Organisation Validated (OV): The CA verifies the domain AND confirms that your organisation legally exists and has authorised the certificate request. This requires checking against official records, email verification, and often a phone callback to a verified number.
Extended Validation (EV): Even more rigorous identity verification, including checks on the individual requesting the certificate. Used to display the company name in the browser address bar (though most browsers have removed this).
“Just automate it with Let’s Encrypt” is the standard response to anyone who complains about certificate management. And for basic websites, that’s fine—DV certificates are perfectly adequate.
But if you’re taking payments, if you’re in a regulated industry, if your compliance framework requires organisation validation, if you want your customers to be able to verify that your certificate was actually issued to your company—you can’t use Let’s Encrypt. You need an OV or EV certificate, and those cannot be fully automated because they require human verification.
The CA may cache your organisation’s validation data for a period (typically 1-2 years), so not every renewal requires a phone call. But that’s CA-dependent, not guaranteed, and if they’re pushed to shorten validation periods alongside certificate validity, you could be going through full re-verification multiple times a year.
The Real Cost
Managing a certificate renewal isn’t just clicking a button. For an MSP managing certificates across multiple clients, each renewal involves:
Tracking expiry dates across dozens of certificates, each with different CAs and different renewal contacts. Generating a new CSR or retrieving the certificate from the CA portal. Completing whatever verification the CA requires—email confirmation, DNS records, phone callbacks. Installing the new certificate on the server, load balancer, or hosting platform. Testing that everything works correctly. Updating documentation. Dealing with whatever goes wrong—wrong file format, missing intermediate certificate, forgotten password for the CA portal, client contact who’s on holiday.
Multiply that by however many OV/EV certificates you manage. Now do it twice as often. Now imagine doing it four times a year when 90-day validity arrives.
This is time that isn’t being spent on actual security work. It’s not threat detection, not vulnerability management, not security awareness training. It’s administrative overhead created by browser vendors who decided this was someone else’s problem to solve.
The Disconnect
The people making these decisions work at companies with dedicated PKI teams, automated infrastructure, and essentially unlimited engineering resources. They can rebuild their certificate management systems around 90-day validity without breaking a sweat.
They don’t understand—or don’t care—what this means for a three-person MSP managing IT for thirty small businesses. They don’t understand that “just automate it” isn’t an answer when the certificates require human verification. They don’t understand that their theoretical security improvement creates real operational costs that fall on people who are already stretched thin.
The CA/Browser Forum discussions are dominated by the big players. Small operators don’t have representatives at the table. The decisions get made, the announcements go out, and the rest of us are left to deal with the consequences.
What Can You Do
The honest answer is: not much. The browser vendors have made their decision, and the industry has to follow.
But you can make the process less painful:
Centralise your tracking. Don’t rely on calendar reminders scattered across different people’s accounts. Use a proper certificate monitoring tool that alerts you well in advance of expiry.
Consolidate your CAs. If you’re managing certificates from five different certificate authorities, you’ve got five different portals, five different processes, five different sets of credentials. Consolidating to one or two CAs reduces complexity.
Automate what you can. For DV certificates, use ACME automation. That frees up your time for the OV/EV certificates that genuinely require manual intervention.
Plan for 90 days. It’s coming. Build your processes now so you’re not caught out when the change arrives.
Consider whether you actually need OV. For some use cases, DV certificates are genuinely sufficient. Don’t pay for organisation validation if you don’t need it—but don’t downgrade if your compliance or customer trust requires it either.
The Bigger Picture
This isn’t really an article about TLS certificates. It’s about a pattern that keeps repeating in our industry: big tech companies making decisions that suit their infrastructure and their priorities, then imposing those decisions on everyone else.
Sometimes those decisions are genuinely good for security. Sometimes they’re just convenient for the companies making them. And sometimes—like shorter certificate validity as a substitute for fixing revocation—they’re a way of offloading the cost of a problem onto people who have no say in the matter.
If you’re an MSP or IT team struggling with certificate management overhead, you’re not alone. The frustration is shared across the industry. The best we can do is build efficient processes, share knowledge with each other, and keep doing the work that keeps businesses secure—even when the people at the top keep making it harder.
At Trichromic, we manage certificates for our clients as part of our ongoing service. If you’d rather not deal with this yourself, give us a call on 020 3327 0310. We’ll still be frustrated by the process, but at least it won’t be your problem.