Blog

The reduction in SSL/TLS certificate lifespans is no longer a future change.

Since 15 March 2026, publicly trusted TLS certificates can have a maximum validity of 200 days. And the next change will arrive soon: from 15 March 2027, the maximum validity will be reduced to 100 days. Later, in March 2029, the limit will fall again to 47 days.

For companies, this means more than simply renewing certificates more frequently.

It means reviewing how certificates are identified, who manages them, how domains are validated, where certificates are installed and which processes still depend on reminders, spreadsheets or manual intervention.

The goal should not be to reach March 2027 and then start renewing certificates automatically.

It should be to use the coming months to determine whether the current management model will continue to work when certificate lifecycles become much shorter.

Moving from 200 to 100 days changes the pace of work

A certificate with a maximum validity of 100 days means that the issuance and renewal cycle must be repeated much more frequently.

In practical terms, we are no longer talking about a task that may arise once or twice a year.

Each certificate will need to be renewed several times over that same period.

And when a company manages different domains, subdomains, applications, APIs, servers or internal services, that increase in frequency quickly multiplies.

The problem is not necessarily renewing a certificate.

The problem is repeating the entire process correctly dozens or hundreds of times: requesting the certificate, completing the necessary validations, issuing it, installing it where required, checking that it works and maintaining traceability of what has been done.

With shorter cycles, any inefficiency that is manageable today begins to recur much more frequently.

The first step should be knowing which certificates exist

Before thinking about automation, it is worth answering an apparently simple question:

Do we know exactly which SSL/TLS certificates the company uses?

In smaller organisations, the answer may seem obvious.

But as infrastructure grows, it is common for certificates to appear across different websites, applications, APIs, load balancers, cloud environments, internal servers or services managed by external providers.

Some may be perfectly documented. Others may depend on the knowledge of one particular person.

And others may have been installed months ago without ever being added to a centralised inventory.

Shorter certificate lifespans make having that inventory increasingly important.

It is not enough to know about the main certificates used by the corporate website. It is also worth identifying where certificates are installed, which domains they protect, which certificate authority issued them, when they expire and which service could be affected if they are not renewed correctly.

A certificate that has not been identified is difficult to manage efficiently.

Manual processes that work today should be reviewed now

When a company manages only a few certificates and its infrastructure changes very little, a calendar reminder, a spreadsheet or even a fully manual renewal process may still be valid solutions.

The problem appears when those same procedures, which until now could be carried out occasionally and under relatively controlled conditions, need to be repeated every few months for a growing number of certificates and increasingly complex infrastructures.

As renewal frequency increases, so does the dependence on every step being performed correctly and at the right time. A process that works when it relies on only a few interventions each year may stop being sustainable when it requires much more frequent attention, particularly when several people, departments or providers are involved.

That is why, before 100-day certificates come into effect, it is worth reviewing how the current process would respond to common situations such as these:

• What happens if the person responsible is on holiday?
• Who checks that the certificate has been installed correctly on every server?
• What happens if a renewal requires a validation step that nobody had anticipated?
• Is there a system that warns the team if the new certificate has not been deployed in one of the environments?
• Is there a record of when the change was made?

The reduction in validity does not automatically make every manual process unsuitable, as in certain environments they may continue to be perfectly reasonable. However, it does mean assessing whether those processes will remain sustainable when they have to be carried out much more frequently and with less time to react to an error or incident.

Domain validations also become part of the new pace

The reduction to 100 days does not only affect the maximum certificate validity period.

From 15 March 2027, the maximum period during which a certificate authority may reuse a previous domain or IP address validation will also be 100 days. In March 2029, that period will be reduced even further, to 10 days.

This is particularly important because renewing a certificate does not always consist solely of generating a new one.

Depending on the process and certificate authority, it may be necessary to demonstrate control over the domain again.

It is therefore worth reviewing how these validations are currently performed.

If they depend on emails sent to specific accounts, manual DNS changes or intervention from different departments, increasing their frequency may add friction to the process.

Automated domain validation mechanisms become much more valuable in this context.

They not only reduce repetitive work. They also reduce the number of manual steps that can delay a renewal.

Documentation is becoming much more important

Infrastructure changes. New services are added, servers are replaced, new domains appear and providers change.

If documentation does not evolve at the same pace, the certificate inventory eventually becomes outdated.

With more frequent renewals, working with incomplete information creates a greater risk.

Documentation should make it possible to know at least:

• which certificates are active;
• which domains and services they protect;
• where they are installed;
• who is responsible for them;
• how validations are performed;
• how they are renewed;
• how they are deployed;
• which dependencies exist;
• which procedure should be followed if something goes wrong.

There is no need to turn every renewal into a bureaucratic process.

Quite the opposite.

Clear documentation helps reduce dependency on individuals and makes it easier for processes to be carried out consistently.

Automation should be considered before it becomes essential

The progressive reduction in certificate lifespans is pushing SSL/TLS management towards increasingly automated models.

This means that most companies need to implement an automated model quickly.

It is worth identifying which repetitive tasks can be automated.

Renewal is only one of them.

Certificate discovery, validation, issuance, deployment, alerts, checks and part of the audit trail can also be automated.

As the number of certificates or the complexity of the infrastructure increases, a Certificate Lifecycle Management (CLM) platform makes it possible to centralise these processes and manage the complete certificate lifecycle from a single environment.

The goal should not be automation for automation’s sake.

It should be to reduce the manual interventions that, with 100-day cycles and later 47-day cycles, will need to be repeated more and more frequently.

Implementing a CLM does not have to happen all at once

A company does not need to automate all its certificates on the same day.

In fact, a gradual implementation often makes it easier to understand the infrastructure and identify the most problematic processes first.

It can begin with certificates associated with critical services, those requiring the most manual work or those deployed across several systems.

Other environments can then be incorporated progressively.

This approach also makes it possible to review internal procedures before automating them.

Because automating a poorly defined process does not necessarily solve the problem.

First, it is important to understand which certificates exist, who manages them and how their lifecycle should work.

It then becomes much easier to decide which parts are worth automating.

March 2027 should not be the date to start preparing

The move to 100-day certificates has a specific date, but preparation should begin earlier.

A company can use the coming months to review its inventory, identify manual processes, check how its domains are validated, identify certificates deployed across several environments and define responsibilities.

It can also test automation across part of the infrastructure before extending it to the rest.

This makes it possible to reach the change with processes that have already been tested.

And there is another reason not to treat this as a one-off adaptation.

The 100-day limit is not the end of the process.

From 15 March 2029, publicly trusted TLS certificates will have a maximum validity of 47 days, while the reuse of domain and IP address validations will be limited to 10 days.

That is why adapting processes today solely to support 100-day certificates may not be enough.

It makes more sense to build a management model designed to continue reducing manual intervention as certificate cycles continue to shorten.

Preparing now will help avoid working under pressure later

The reduction in SSL/TLS certificate lifespans is intended to ensure that the information and keys being used remain valid for less time and that changes can propagate more quickly.

But for companies, it also has a very practical consequence: there will be less room to manage certificates as an occasional task.

The next step should not simply be adding more reminders to the calendar.

It should be reviewing the entire process.

Inventory, responsibilities, validations, renewals, deployments, documentation and automation should be analysed as parts of the same lifecycle.

At Entorno Digital, lifecycle management tools such as CertGuardian make it possible to centralise and automate some of these processes when the volume or complexity of the infrastructure means that manual management is starting to become unsustainable.

But the tool is only one part of the preparation.

The most important thing before March 2027 is for the company to know which certificates it has, how it manages them and what needs to change in order to do so much more frequently.