From 398 to 47 days: what short TLS certificates set off in a network

Certificates are treated as a solved problem: buy one, install it, set a calendar reminder, enjoy a year of quiet. That model is being abolished right now — not at once, but in three steps, the first of which is already running.

The schedule and where we are in it

In April 2025 the CA/Browser Forum decided to lower the maximum validity of publicly trusted TLS certificates step by step. The period during which a completed domain validation may be reused shrinks alongside it.

In addition, since 15 March 2026 the validation of Subject Identity Information may only be reused for 398 days instead of 825 — which affects OV and EV certificates, exactly the class enterprises often use for portals and services.

Where it hurts in the network

The discussion usually revolves around web servers. Automation has been normal there for years and the pain is limited. The awkward certificates sit elsewhere — everywhere a network device terminates TLS itself:

• Web interfaces of switches, routers and firewalls. Usually self-signed or internally issued, often untouched since commissioning.
• Wireless controllers and guest portals. An expired portal certificate produces no monitoring alert but a warning page on every device in the building.
• RADIUS server certificates for EAP-TLS. When this expires, clients stop authenticating to the wireless network or the 802.1X-protected port outright — the loudest failure imaginable.
• VPN gateways and remote access. Expiry hits the people working from outside first, which typically means the on-call engineers.
• Management platforms and controllers. They speak TLS to each other; an expired certificate does not interrupt traffic but does interrupt control.

The order that works

The reflex is to buy a certificate management platform. The more effective first step is duller and costs nothing but time: find out how many certificates exist at all and who renews them.

1. 01

   Certificate inventory

   Every TLS-terminating point with issuer, expiry, owner and renewal path. Gathered actively — by querying the endpoints, not by circulating a survey.

2. 02

   Classification

   Publicly trusted or internal? Only the first class falls under the schedule, but the second decides how many procedures you end up operating.

3. 03

   An automation path per class

   ACME wherever it is supported; EST or SCEP where network devices meet an internal PKI. What matters is not the protocol but that exactly one applies per class.

4. 04

   Name the exceptions

   Some devices cannot automate. They belong on a short, justified list with a date — not in the quiet remainder.

5. 05

   Expiry monitoring

   An alert 30 days ahead becomes a permanent tone at 47-day lifetimes. The threshold belongs tied to the lifetime, not to a fixed number.

Why this is an automation topic

The reduction is not a security problem you solve with more care. It is a change of frequency, and frequency is solved with repeatability. A certificate swap that runs as a change through the same path as any other configuration change — versioned, tested, logged — costs no more at 47 days than at 398.

That is the same principle we describe under network automation: the effort of a task is decided less by its difficulty than by how often it is done by hand. How the certificate estate fits the wider picture is described under enterprise networks.

What to do now

The 200-day step is already running. Order a certificate with a one-year term today and you will not get one. That is the simplest opportunity to build the inventory: the next renewal wave arrives earlier than planned anyway, so it can carry the survey with it.

The second date is 15 March 2027. By then every class should have an automated path and the exception list should be shorter than today. Starting only in 2029 means migrating under outage pressure instead of calmly.