The Rule Change Nobody Budgeted For

In April 2025 the CA/Browser Forum passed ballot SC-081, with Apple, Google, Mozilla and Microsoft all voting in favour. It sets a schedule that shortens the maximum validity of every publicly trusted TLS certificate:

From Maximum certificate lifetime
Today 398 days
15 March 2026 200 days
15 March 2027 100 days
15 March 2029 47 days

This is not a proposal and there is no opt-out. Certificate authorities cannot issue longer certificates than the browsers will trust. If your renewal process runs on an annual cycle, that cycle is already dead: the 200-day limit is in force now, and by 2029 every public TLS certificate you own will need replacing roughly every six weeks.

The stated reasoning is sound. Shorter lifetimes shrink the window in which a compromised or mis-issued certificate is dangerous, and they force the ecosystem toward automation. The practical consequence for operations teams is simpler to state: certificate renewals get 2x more frequent this year, 4x by next year, and 8x by 2029.

Manual Renewal Fails at Frequency

Most certificate processes that exist today were built for an annual event. Someone requests the certificate, someone approves it, someone installs it, and someone sets a calendar reminder for eleven months out. That process has a per-renewal failure rate, and it is not zero. Keyfactor’s research found certificate-related outages are a weekly reality for 1 in 10 enterprises, with an average of 11 people involved in recovering from each one.

The failures are not hypothetical, and they are not limited to small teams:

  • Microsoft Teams, February 2020. An authentication certificate was not renewed. Teams went down globally for around three hours, during the exact period the world was moving to remote work.
  • Azure Storage, February 2013. An expired HTTPS certificate took out storage endpoints and cascaded into an outage across dozens of dependent Azure services for most of a day.
  • O2/Ericsson, December 2018. An expired certificate in Ericsson’s core network software knocked tens of millions of UK subscribers offline for the better part of a day.

Each of those organisations had more process, more people and more monitoring than most teams reading this. The lesson is not that they were careless. It is that a manual process with a small per-event failure rate produces regular failures once the event count gets high enough. SC-081 raises the event count by design.

Run the arithmetic on your own estate. If you hold 40 public TLS certificates on annual renewal, that is 40 renewal events a year today. Under the 2027 limit it is roughly 160. Under the 47-day limit it is over 300. A process that fails once in a hundred renewals now fails several times a year, and every failure is a customer-visible TLS error.

What This Touches in an Azure Estate

SC-081 formally covers publicly trusted TLS certificates. In an Azure environment that means, at minimum:

  • App Service custom domain bindings using certificates you bring yourself
  • Application Gateway and Front Door listeners with uploaded certificates
  • API Management gateway and custom domain certificates
  • Key Vault certificates issued by public CAs and consumed by any of the above
  • Anything doing mutual TLS with an external party where the leaf certificate is publicly trusted

Two important boundaries:

Managed certificates mostly take care of themselves. App Service managed certificates, Front Door managed TLS and Key Vault certificates on an integrated CA (DigiCert, GlobalSign) with auto-renewal configured will follow the new lifetimes without your involvement. The risk sits entirely in the certificates that were uploaded by hand, imported once, or issued by a CA that is not wired into any automation. Those are the ones on somebody’s calendar reminder.

App Registration secrets and client certificates are not covered by SC-081, and that is not good news. Entra ID credentials rot on exactly the same manual process, and they fail the same way: an application silently stops acquiring tokens and everything downstream returns 401. If your team cannot reliably renew TLS certificates four times a year, it cannot reliably rotate App Registration secrets either. Fixing the process for one and not the other just moves where the outage happens.

What to Do This Quarter

The March 2026 step-down has already happened; the 2027 one is the deadline that should drive planning. Three moves, in order.

1. Inventory before anything else

You cannot automate what you have not found. The dangerous certificates are precisely the ones nobody remembers: the wildcard uploaded to an Application Gateway two years ago, the mTLS client certificate a partner integration depends on, the certificate living in a subscription owned by a team that was reorganised away.

The fastest way to get that inventory on Azure is a read-only scan across every subscription and Key Vault. Our free CLI scanner does this in a couple of minutes with your existing az login session, and never reads secret values:

pip install certifyclouds
az login
cc-scan

It lists every secret, certificate and key across all vaults and subscriptions with expiry dates, flags anything expired or inside 30 days, and runs 11 security checks. Details and other output formats (JSON for CI, HTML reports) are on the scanner page. However you produce it, the deliverable is one list with an owner against every certificate.

2. Sort every certificate into one of three buckets

  • Already automated. Managed certificates and integrated-CA renewals. Verify the automation actually works (check policy.lifetimeActions on Key Vault certificates), then leave them alone.
  • Automatable now. Certificates that can move to a managed offering, an integrated CA, or an ACME-based issuance flow. This is where the quarter’s engineering time should go, starting with anything customer-facing.
  • Stuck manual. Certificates pinned by a partner, constrained by an appliance, or otherwise resisting automation. These need layered alerting (90/30/7 days and expired), a named owner, and a documented renewal runbook, because at 47-day lifetimes a stuck-manual certificate is a standing appointment with an outage.

3. Treat the deadline as the forcing function for credentials generally

The teams that come out of SC-081 well will use it as budget cover to fix credential lifecycle across the board: TLS certificates, Key Vault secrets, App Registration credentials, the lot. Continuous discovery, expiry alerting and automated rotation are the same problem three times over, and CertifyClouds exists because solving it once, centrally, beats three separate spreadsheets.

The Uncomfortable Summary

SC-081 does not create a new risk. Your estate already contains certificates that will expire unnoticed; the 2013 Azure Storage incident proves that scale and expertise are no protection. What SC-081 changes is the frequency, which turns an occasional embarrassment into a recurring one for any team still renewing by hand.

The window to fix the process calmly is between now and March 2027. After that, the schedule fixes it for you, one outage at a time.

Further Reading