The HTTPS padlock is about to need renewing eight times a year

· Carl Heaton · Infrastructure Security

Somewhere in your business there is a certificate quietly counting down. Most people meet certificates as the padlock next to a web address, the thing that stops browsers warning visitors away. That is the visible one. But the same kind of certificate sits behind a lot of things a customer never sees: the login page on your phone system, the link between two internal servers, the management screen on a machine on the factory floor, the connection a payment terminal makes back to base. Anything that talks to anything else over an encrypted connection tends to rely on one. For your website the certificate almost certainly renews itself and you have never had to think about it. For the quieter systems, someone has been renewing them by hand, roughly once a year, whether they realise it or not. That once-a-year chore is about to become a once-every-six-weeks chore, and the systems that depend on a person remembering are the ones that will break.

That window is shrinking because of a decision made by the group that sets the rules for these certificates. In April 2025 the CA/Browser Forum, the body where the big web browsers and the companies that issue certificates agree the rules, passed a ballot called SC-081, originally proposed by Apple. It cuts how long a certificate is allowed to last. Today the maximum is 398 days, a little over a year. By 2029 it will be 47 days. That is not a typo. A certificate that used to last a year will last about six weeks, and you will be renewing it roughly eight times a year instead of once.

What a certificate is, in plain terms

A TLS certificate, the kind people still call an SSL certificate, is a small file that does two jobs. It proves a website is really the site it claims to be, and it sets up the encryption that scrambles the traffic between a visitor and the server. When it is valid, browsers show the padlock and connect quietly. When it expires, browsers throw a full-page red warning, and a lot of software simply refuses to connect at all.

That second part is the bit that catches people out. We tend to think of certificates as a website thing. They are not. Internal admin pages, mail servers, VPNs, the link between your phone system and the network, payment terminals, the management screen on a piece of industrial kit: all of these can carry a certificate, and many do. None of them shows a padlock to a customer, so they are easy to forget. When one of these expires, the failure is not a warning a visitor can click past. The two systems simply stop trusting each other and the connection dies.

It is worth being honest about how these systems have survived so far, because it tells you who is actually at risk. The maximum certificate lifespan has been falling for years. It was eight years once, then five, then three, then two, and since September 2020 the cap has been 398 days, a little over a year. So any system still working today has not been genuinely untouched: someone has been renewing its certificate at least once a year, by hand or on a reminder, or it would already have stopped. The change ahead is not that forgotten machines suddenly start breaking. It is that the annual renewal job most people barely tolerate is about to happen three times a year, then eight, and a once-a-year chore done by memory does not survive that pace.

The schedule, and why it is gradual

The change does not happen all at once. It steps down over three years, and the first step has already landed:

  • From 15 March 2026, the maximum is 200 days, a little over six months.
  • From 15 March 2027, it drops to 100 days, roughly three months.
  • From 15 March 2029, it reaches 47 days, about six weeks.

DigiCert, one of the larger certificate issuers, lays the schedule out in full. The staged approach is deliberate. It gives everyone time to move from renewing by hand to renewing automatically, because by 2027 doing it by hand stops being realistic. Renewing one certificate a year is a calendar reminder. Renewing every system you own every three months, then every six weeks, is a full-time job nobody has the hours for.

There is a second change riding along with the first, and it matters more for the hand-renewed systems than the headline number does. Alongside the certificate lifespan, the rules also cut how long the proof that you own a domain can be reused. Today that proof lasts up to 398 days. By March 2029 it lasts 10 days. In practice that means the renewal process has to re-check that you still control your domain far more often, which makes a one-off manual setup even harder to sustain. The whole system is being pushed toward automation, on purpose.

Why your website is fine and your old systems are not

If your website runs on anything modern, a mainstream host, Cloudflare in front of it, a platform like Microsoft 365 or a typical cloud setup, you are largely covered already. These services renew certificates automatically using a standard called ACME, the same machinery Let's Encrypt pioneered to hand out free certificates that renew themselves without anyone lifting a finger. Shorter lifespans are a non-event for systems built this way. They renew on a schedule measured in days, and 47 days is just a smaller number in a process that was already automatic.

The risk sits with everything that was not built that way. The phrase worth holding in your head is "the systems that do not renew themselves". In a typical small business that means:

  • The web interface on an older phone or VoIP system, where the certificate is renewed by an installer who turns up, or by whoever still has the admin password.
  • Industrial or building kit with a management screen: door entry, CCTV, heating, a machine on the production line, often supporting only manual certificate changes.
  • An internal application or server a supplier configured, where renewing the certificate means getting that supplier back in or doing it yourself.
  • Network hardware, firewalls, and storage boxes with admin pages that someone logs into once a year purely to swap the certificate before it lapses.

These share a pattern. The certificate is renewed by a person, by hand, often by someone outside the business, on a cycle slow enough that it has been a minor annual nuisance rather than a real problem. That is exactly what stops working as the lifespan falls. A job you do once a year by remembering is survivable. The same job three times a year is a standing commitment, and eight times a year by hand is not realistic for anything but a short list. When one slips, the failure is not subtle: the system stops accepting connections, and the people who depend on it tend to find out before you do.

What to actually do this quarter

None of this is urgent in the sense of "drop everything today". The first deadline has already passed quietly, and the painful one is in 2029. But it is exactly the kind of slow-moving change that is cheap to handle early and expensive to handle in a panic when a certificate expires on a Friday afternoon. A few sensible steps:

Find out where you actually rely on certificates. This is the whole game, and it is the same stocktake that pays off for half a dozen other reasons. Walk through your systems and list anything with a web login, an admin page, or an encrypted connection back to another system: the website, yes, but also the phone system, the VPN, the payment terminals, the internal apps, the bits of kit on the network. For each, note who renews the certificate today and whether that happens automatically or by hand. The ones renewed by hand are your list.

Sort the easy wins onto automation. Wherever a system can use ACME, the free automatic-renewal standard, turn it on. Let's Encrypt and similar issuers hand out certificates that renew themselves, and most modern web servers and hosting platforms support this out of the box. Putting a service behind something like Cloudflare can also take certificate renewal off your plate entirely. The goal is to shrink the manual list down to only the things that genuinely cannot automate.

Make a plan for the awkward legacy boxes. Some old systems cannot do automatic renewal, and never will. For those you have a choice to make now, while there is no pressure: replace the kit, put it behind something modern that handles the certificate for it, take its admin interface off the public internet so a browser warning matters less, or simply diarise the manual renewal and accept the chore. The wrong answer is to make no decision and let it expire in 2029 during the busiest week of your year.

Ask your IT person or supplier the direct question. "When certificate lifespans drop to 47 days, which of our systems renews automatically and which one of us is renewing the rest by hand?" A good answer means someone has thought about it. A blank look means you have just found the work before it found you.

The headline number, eight renewals a year, sounds like a problem for the IT department, and for your website it is barely even that. The real value in this change is the nudge it gives you to deal with the systems still being renewed by hand. That manual job was a tolerable once-a-year chore right up until now. The shrinking certificate is simply the thing that turns it into a treadmill, and forces the question of which of those systems should be automated, replaced, or taken off the open internet before a renewal gets missed.

How Steelwise can help

Working out where your business actually relies on certificates, which systems renew themselves and which are one expiry away from an outage, is a straightforward review and a useful one to do before a deadline forces it. It is the kind of stocktake we run for clients. Get in touch.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.