Certificates are changing forever (and many infrastructures are not ready)
January 28, 2026 | Jordi Genescà Prat
Certificados SSL
If you manage certificates for servers, web services, email, APIs or internal applications, this affects you. The industry has been warning for some time about a major change in digital certificate validity periods, but that change is no longer a forecast. It is now imminent.
From 2026, certificates will no longer behave as they have for years: shorter validity cycles, much more frequent renewals and greater exposure to risk if management remains manual. This is not a decision by a single provider or a commercial move. It is a structural change in how trust on the Internet is managed.
In this article we explain what is changing, why it affects all types of certificates, and why many infrastructures may be impacted even if the certificate has been properly purchased and paid for.
Why certificate validity periods are changing
The reduction in digital certificate validity is not a trend or an isolated commercial strategy. It is part of an evolution driven by the CA/Browser Forum, the body that defines the security requirements certificate authorities and browsers must follow.
The aim is to reduce the risk window. The shorter a certificate’s validity, the smaller the potential impact of a compromised key, a weakened algorithm or an incorrect configuration that goes unnoticed for long periods.
This process is not new. Over the years, maximum certificate duration has been progressively reduced. Moving towards roughly six-month periods is the logical continuation of a clear trend towards shorter, more controlled cycles.
What exactly changes from 2026
From 2026, publicly trusted digital certificates issued under the new requirements will have a maximum validity of around 199 days per issuance. While the focus is often on web SSL/TLS certificates, this change directly affects the wider server certificate ecosystem, including:
- TLS/SSL certificates for websites and applications
- Certificates used on email servers (SMTP, IMAP, POP, STARTTLS)
- Certificates for APIs and exposed services
- Certificates in hybrid or cloud environments
- Certificates associated with internal infrastructures connected to the Internet
A key point is that purchasing does not change, but operations do. You may still buy certificates for one or several years, but each issued certificate within that period will be valid for much less time and must be renewed multiple times.
In addition, reuse windows for validations, both domain and organisation, are also being reduced, introducing more critical events into the certificate lifecycle.
What is true… and what is not
Many confusing messages have appeared around these changes, and it is worth clarifying them.
It is not true that certificates will stop working due to billing or purchasing issues. It is also not true that this change only affects certain certificate authorities. This is a regulatory update that impacts all publicly trusted certificates, regardless of provider.
What is true is that manual processes become unsustainable. What used to be solved with a single yearly renewal now repeats several times, increasing operational load and widening the margin for error.
The real impact on companies and technical teams
The impact of this change is not measured by how many certificates you purchase, but by how many services depend on them. Websites, email servers, APIs, system integrations and production or testing environments all share one thing: if the certificate expires, the service stops working, even if it has been paid for.
In organisations with multiple services and environments, this new scenario implies:
- More renewals throughout the year, not only for websites but also for email and critical services
- Greater dependence on periodic validations that can be delayed
- More points where human error can cause an outage
- Higher risk of incidents caused by expired certificates
These failures remain one of the most common causes of avoidable service interruptions.
More frequent renewals: the hidden risk
One of the most important aspects is that a certificate’s operational validity is independent of the purchasing period. A certificate can be bought for a year or more and still stop working if it is not renewed or reissued on time under the new deadlines.
The most common problems in this context typically come from:
- Renewals that are not executed in time despite being covered contractually
- Certificates installed on less visible services such as email servers or internal APIs
- Lack of centralised visibility of where certificates are used
- Manual processes that depend on specific people or informal reminders
With six-month cycles, any oversight quickly becomes an incident.
Automation and certificate lifecycle management
In this new scenario, the challenge is no longer issuing certificates, but managing their full lifecycle. That means knowing what certificates exist, where they are installed, when they expire, which validations they require and which services depend on them.
Certificate Lifecycle Management (CLM) solutions make it possible to centralise web, email and server certificates, automate renewals and reduce reliance on manual tasks.
Tools like CertGuardian are designed for this context: multiple certificates, shorter validity cycles and the need for continuous control. Their purpose is not to replace the certificate, but to prevent a missed renewal from taking down a website, an email server or a critical API.
How to start preparing
Preparing for this change does not require an immediate transformation, but it does require reviewing your processes. The first step is to gain real visibility into existing certificates and the services that depend on them.
From there, it is worth analysing how renewals are handled, which validations are involved and where friction points may appear. The earlier you carry out this analysis, the more room you have to adapt in an orderly way, without urgency.
Conclusion: this is not a technical change, it is an operational change
Shorter certificate validity periods do not introduce a new technology, but a new way of operating. The risk is not the certificate itself, but continuing to manage it as if nothing had changed.
A certificate can stop working even if it has been properly purchased. The difference between suffering this change or absorbing it without impact comes down to one thing: control of the certificate lifecycle.
In this new scenario, manual certificate management stops being reliable and becomes an operational risk.
