47 Days: The End of Manual Certificate Management

In July 2024, an expired TLS certificate inside the Bank of England took the UK’s CHAPS payments system offline for 91 minutes. CHAPS clears around £360 billion in transactions every business day. Two months later, an expired root certificate inside ServiceNow’s MID Server disrupted operations at 616 customer organizations. In 2013, an expired SSL certificate inside Microsoft’s Azure Storage took the service down globally for hours.

Each of those failures had a known expiry date in a calendar somewhere and a named owner whose process did not fire in time. None of them were exotic attacks.

That problem is about to get harder by an order of magnitude.

Why public TLS certificates keep getting shorter

The CA/Browser Forum is the industry body that sets baseline requirements for publicly trusted certificate authorities. Apple, Google, Microsoft, and Mozilla all participate as browser-root operators. Apple authored Ballot SC-081v3 and the Forum approved it on April 11, 2025.

The ballot’s preamble lists four reasons for the cuts:

1. Revocation does not work at scale. Browsers cannot reliably check whether a certificate has been revoked. CRLs are large and stale, and OCSP has both privacy and reliability problems. Short-lived certificates side-step this by expiring before revocation propagation would have mattered.
2. Smaller blast radius from key compromise. A stolen private key from a 47-day certificate has a maximum useful life of 47 days. From a 398-day certificate it has up to 398 days, regardless of whether the issuer revokes.
3. Tighter binding to current domain control. Domain ownership changes. Companies merge, sites get sold, registrations lapse, and DNS gets reconfigured. Forcing fresh ownership proof on every renewal catches stale assertions before an attacker does.
4. Crypto agility for post-quantum. NIST finalized its first post-quantum standards in 2024. Migrating the public web off RSA and current elliptic curves before quantum attacks become practical requires the operational machinery to roll certificates fast. Forty-seven-day cycles build that machinery.

The benefit accrues to the ecosystem. The cost lands on operators.

The schedule: 47 days by March 2029

The reduction runs on a fixed timeline. The 200-day maximum has already been in effect since March 15, 2026.

Pre-Mar 2026 (398 / 398) 398d

Mar 2026 (200 / 200) ↑ in effect today 200d

Mar 2027 (100 / 100) 100d

Mar 2029 (47 / 10) 47d 10-day DCV reuse

0 100 200 300 400 days

The schedule applies only to publicly trusted TLS certificates. Private PKI used for internal services and machine-to-machine traffic is unaffected.

Domain validation reuse drops to 10 days

The validity number gets the headlines. The reuse number is the harder change.

Certificate authorities cache the result of a domain ownership check so they can reissue without revalidating every time. SC-081v3 collapses that cache to 10 days at the 2029 floor. Every renewal will require a fresh DNS, HTTP, or email-based check that the requester still controls the domain.

For ACME-based automation that already revalidates on every renewal, this is a non-event. For organizations that manage critical certificates by ticket and email, it is a wall.

At 47 days, eight renewals every workday

Take a working environment with 250 publicly trusted certificates. That is conservative for any organization running a few production sites, internal tools, monitoring dashboards, vendor integrations, and email gateways.

Validity	Renewals per year	Renewals per workday
398 days (pre-2026)	~230	~1
200 days (today)	~456	~2
100 days (Mar 2027)	~913	~4
47 days (Mar 2029)	~1,941	~8

A team that ran this manually at 398 days might have survived on calendar reminders. The same team at 47 days needs eight successful, atomic certificate operations every working day. One sick day or one botched renewal becomes an outage.

Three recent outages preview the failure mode

The Bank of England outage came from a certificate inside the bank’s own infrastructure that had a known expiry date and a renewal owner. The ServiceNow outage came from a root certificate that had been flagged internally roughly two weeks before it expired. Neither failed because someone forgot. Both failed because manual processes have soft edges (handoffs, ticket queues, “I thought you owned that one”) that hold up at one renewal a year and collapse at one a week.

The recurring failure modes look the same across every postmortem:

• Inventory gaps. Certificates issued for one project get inherited by another and lose their owner.
• Untracked dependencies. A renewed leaf certificate is fine, but the issuing intermediate or root expires and takes everything with it.
• Notification dead ends. Expiry alerts go to a mailing list whose original owner left the company.
• Renewed but not deployed. The new certificate gets issued and then never makes it onto the load balancer, the API gateway, or the legacy appliance with a separate cert store.

At 398-day cadence you find these problems once a year. At 47-day cadence you find them in 30 days, or you find them as a Sev-1.

Four controls separate teams that survive

Practical readiness comes down to four things:

1. An accurate certificate inventory. Every public certificate, where it terminates, who owns it, and which intermediate signs it. Discovered by scan, not declared by spreadsheet.
2. ACME automation everywhere it is supported. Let’s Encrypt, ZeroSSL, Sectigo, DigiCert, and Google Trust Services all support the protocol. The exceptions are appliances, vendor SaaS, and legacy load balancers. Those are the renewal queue you actually have to staff.
3. Pre-expiry monitoring with paging. Alerts at 30, 14, and 7 days, routed to an on-call rotation rather than a shared inbox. The Bank of England and ServiceNow outages both had advance warning that the right humans never saw.
4. Renewal as a deploy. Treat certificate rotation the same way you treat any other production change: tested, observable, and rollback-capable. A renewal that succeeds inside the CA portal and never reaches the edge is a failure, not a save.

The 200-day floor was the warning shot. Teams still issuing one-year certificates out of a portal in early 2027 will see their first incident before the end of that calendar year.

How Fruition handles certificates for hosting clients

Fruition runs hosting on Kubernetes infrastructure managed through our internal platform, FCP. Certificate lifecycle is part of the operating contract, not a customer responsibility. The pieces that matter for the 47-day world are already in place:

• SSL/TLS certificate analysis on a scheduled cadence as part of Infrastructure Scanning, with findings surfaced in the client dashboard alongside other security results.
• Pre-expiry alerting routed to Slack and PagerDuty when configured, so renewal failures get a paged human, not a buried email.
• ACME-based renewal at the ingress layer for everything that supports it, which is the majority of public web traffic for our managed clients.
• Operational queue for the rest. Vendor appliances, third-party SaaS endpoints, and anything the client owns outside our cluster get tracked, monitored, and renewed on a documented runbook.
• Shield WAF in front for the production sites that need rate limiting, geo-blocking, and bot control on top of TLS termination.

If you operate a regulated, public-sector, or airport environment and want a hand inventorying your public certificate footprint and standing up renewal automation, reach out. It is the kind of work we already do for managed-hosting clients.