← Back to news 20.10.2026

At 47 days, nobody renews by hand any more

Since March 2026, public TLS certificates may be valid for at most 200 days, from March 2027 for 100 and from March 2029 for only 47. What the CA/Browser Forum schedule means for operations, which systems become the problem, and what should be done before the 100 days apply.

Until March 2026, a publicly trusted TLS certificate could be valid for 398 days. Since 15 March 2026, the maximum is 200 days. From 15 March 2027 it is 100, and from 15 March 2029 only 47. This is set out in the Baseline Requirements of the CA/Browser Forum, which every certification authority whose certificates browsers trust must follow:

"Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days."

The schedule was adopted in April 2025 with Ballot SC-081. It does not only shorten the validity period. The proof that you control the domain may also be reused only for a limited time: until March 2026 it was 398 days, since then it has been 200, and from March 2029 it will be ten days.

What this means in work

A certificate valid for one year is replaced once a year. At 47 days, with the usual buffer before expiry, it is ten to twelve replacements a year, for every single certificate. An organisation with 60 public certificates ends up with around 600 replacements a year, two to three on every working day.

That cannot be done by hand. The way forward is ACME, the protocol from RFC 8555 that lets a server request and renew its own certificate. Most web servers and reverse proxies support it. The problem is everything else: appliances, load balancers, phone systems, business applications with their own web interface, where the certificate used to be uploaded once a year by someone who knew where the form was.

Certificates from your own internal PKI are not affected by the schedule. The Baseline Requirements apply only to publicly trusted certificates. Anyone who moves a system to internal certificates for that reason must then make sure that all clients trust the internal certification authority.

What should be done by March 2027

The inventory. Not the list from the last project, but what a scan actually finds. A certificate nobody knows about also expires unnoticed.
A responsible person for each certificate. At ten replacements a year, an expiry warning to a shared mailbox is no longer a warning, it is noise.
The split: automatic or manual. The second list is the work list, and it has to be shorter before the 100 days apply.
A decision for every system on that list. Retrofit ACME, terminate TLS at a proxy in front, replace the system, or deliberately move it to an internal certificate.
Domain validation. With ten days of reuse from 2029, validation runs again for practically every issuance. Anyone who has DNS records changed by ticket at their provider needs an interface for it.

How isidaten handles this

Certificate management does not renew certificates. It is the inventory and the warning. Certificates found by attack surface management are imported every night. If a certificate comes from an ACME certification authority, it is listed as renewed automatically, all others as manual. Also every night, the module checks expiry in the stages warning (by default 30 days before), critical (7 days) and expired, and notifies the responsible person. If there is none, the warning goes to everyone with access to the certificates.