Apple's 47-day TLS certificates are official: what every team needs to do before March 2029

TL;DR: In April 2025 the CA/Browser Forum unanimously approved Ballot SC-081v3, codifying a phased reduction in public TLS certificate maximum validity: 398 days today → 200 days (March 2026) → 100 days (March 2027) → 47 days (March 2029). By 2029 an enterprise with 600 public certs will renew them ~4,660 times a year. Manual cert management is over. This is the story of why, the math, and what to do.

1. The headline change

For a long time the public TLS certificate ecosystem operated on a one-year cadence. Cert lasts 13 months, you renew once a year, the spreadsheet works. That world is ending.

The CA/Browser Forum — the standards body whose Baseline Requirements every publicly trusted Certificate Authority must follow — approved Ballot SC-081v3 on April 11, 2025, by a unanimous 25-0 vote. It commits the whole ecosystem to a phased reduction in maximum certificate validity:

By 2029 a certificate's entire lifetime is the same length as a single billing cycle. Eight issuances per cert per year. Manual cert management — the kind that lives in a spreadsheet and a calendar reminder — is no longer just inefficient; it's mathematically impossible at any reasonable scale.

2. Why the industry is doing this

Five reasons, roughly in order of weight.

2.1 Limit the damage from key compromise

If a private key is stolen or a cert is mis-issued, you want the worst-case exposure window to be short. Today the worst case is a year-plus. With a 47-day cert, even if revocation fails or isn't honoured, the certificate dies on its own within weeks.

This is the single largest argument, and it's the one industry experts keep coming back to. Revocation in TLS has always been weak — CRLs are huge, OCSP is often soft-fail, and the whole infrastructure was designed for a world that doesn't exist any more. Short lifetimes route around the problem entirely.

2.2 Force regular key rotation

Long-lived certificates encourage long-lived keys. With certificates rotating every six weeks, you naturally end up with fresh keypairs every six weeks too. That eliminates a class of long-term cryptographic exposures and makes algorithm migrations (think: post-quantum) easier to execute when the time comes.

2.3 Drive automation, not just suggest it

Let's Encrypt proved automation works at scale with 90-day certs and ACME. The CA/B Forum's view is essentially: "the rest of the ecosystem is now going to follow." With 47-day certs you cannot, as a practical matter, not automate. The change forces the question.

2.4 Align with modern operational practice

Look at how the rest of the credential world has trended. Cloud IAM short-lived tokens. Workload identity. ssh certificate authorities. Secret rotation. Everywhere you look, the move is toward ephemeral credentials. TLS certificates were the last bastion of "set it and forget it for a year." That's finally falling.

2.5 Reduce dependence on flawed revocation infrastructure

We mentioned this already, but it's worth saying twice. The TLS revocation story has never worked the way RFC 5280 imagined. CRLs are too big to download; OCSP queries leak browsing history; OCSP stapling adoption is patchy. Shorter lifetimes are how the ecosystem stops needing those failures to work.

3. The math: how many renewals are you about to be doing?

Take a realistic enterprise: 600 public TLS certificates across websites, APIs, load balancers, CDN edge configs, WAF endpoints, VPN portals, customer-facing services. Today, at 398-day validity, that's about 600 issuances per year — manageable with a small team and some scripting.

Walk it forward:

Hundred-and-twenty issuances per business day, every business day. That's not a spreadsheet workflow.

It's also worth being honest about what those numbers don't include: validation reuse changes. Today an OV/EV certificate can lean on previously-validated organisation data for up to 825 days. Under SC-081v3, certs issued from March 2026 onwards can only reuse OV validation for 398 days. So as well as eight times more renewals, you'll be re-doing organisation vetting roughly annually, even if you bought a "3-year coverage" plan.

The cost isn't really in CA fees. Most resellers will keep selling multi-year subscriptions that bundle a sequence of short-lived certificates. The cost is in operational work: more issuances, more validation refreshes, more places where the chain can break.

4. What changes for different setups

4.1 Fully ACME-automated (Let's Encrypt, ZeroSSL, BuyPass)

Best position. You're already on 90-day certs and your renewal pipeline is automated. The transition costs you nothing on the issuance side. The thing you DO need is robust monitoring of the deployed certificate — ACME renewal can fail silently (DNS changes, rate limits, webroot mis-config) and your only sign of trouble is an outage when the existing cert expires. Watch the cert that's actually serving traffic, not the renewal cron.

4.2 Manual paid certs (Sectigo, DigiCert, GlobalSign, GoDaddy SSL)

You're going to need to either:

1. Move the same CA over to ACME-style automation (most of them now offer it — ask your account manager), or
2. Switch to a CA whose automation story is mature, or
3. Adopt a Certificate Lifecycle Management (CLM) platform that abstracts over multiple CAs.

The "renew manually when the calendar reminder fires" workflow stops being sustainable in 2027 and stops being possible in 2029. Start now.

4.3 OV/EV certs with annual organisation validation

You're hit twice: certificates expire faster AND the organisation validation data behind them can be reused for shorter periods. Build a process for annual re-vetting (paperwork, identity attestations) that doesn't require a human to chase it. Many CAs offer pre-validation programmes — use them.

4.4 Internal PKI / private CAs

You're not directly affected by CA/B Forum rules — internal roots can issue certs of any duration. But most organisations will align voluntarily. The same operational pressures (key rotation, automation, secret-rotation hygiene) apply just as much to internal certs. Many internal PKIs are moving to 90-day defaults or shorter.

4.5 Network appliances and devices that don't speak ACME

This is the long tail of pain. Old firewalls, load balancers, VPN concentrators, mail servers — anything where renewing the cert means a vendor portal upload and a service restart. Either replace those endpoints (often not realistic), upgrade vendor firmware to add ACME (sometimes available), or shim with a reverse proxy that handles the cert automatically and re-encrypts upstream.

5. What you should do this year, next year, and the year after

5.1 This year (2026): inventory

Find every public TLS certificate you currently have. Every domain, every subdomain, every endpoint. Include things you may have forgotten: CDN edge certs, status pages, legacy mail submissions, partner integrations.

For each, capture:

• Hostname and port
• Current expiry date
• CA / issuer
• Renewal mechanism (ACME / API / manual)
• Owner (which team / person)
• Critical? (revenue-affecting? customer-facing?)

A spreadsheet is fine for this stage. The point is to know what you have.

5.2 This year (2026): set up monitoring on every single one

Not just the critical ones. ALL of them. The cost is small; the upside is huge. If you don't have a tool already, get one — including ours: Trace Warrior's SSL/TLS expiry monitor does exactly this, with email and webhook alerts, two-stage thresholds (warning + critical), and recovery alerts when you successfully renew.

Daily checks are plenty for cert expiry. You don't need 1-minute polling. What you need is to never be surprised.

5.3 Next year (2027): switch every renewable cert to automation

ACME wherever possible. CA API wherever ACME isn't supported. By the end of 2027, your manual-renewal list should be down to "the appliances we can't upgrade" — and you should have a remediation plan for each of those too.

5.4 By 2028: dry-run a 47-day cadence

A year before the change. Set internal certs to 47-day max. See what breaks. Fix it. The companies that wait until March 2029 to find out their renewal pipeline can't keep up are going to be the ones with outages.

5.5 Treat alerts like SRE pages, not like emails

If your cert-expiry alerts go to a team mailbox that nobody reads, they will fail. Wire them into the same on-call rotation that gets paged for production outages. Cert expiry IS a production outage, just one that you can schedule.

6. The forecast: where this goes after 2029

SC-081v3 is the codified plan through March 2029. After that, the trajectory is clear even if the next ballot hasn't been written yet. The direction is shorter still — eventually treating TLS certificates as just one more flavour of ephemeral, software-managed credential, on par with cloud IAM tokens.

Two-week certificates by 2032? Seven-day certs by 2035? Nobody has voted on it yet. But anyone planning infrastructure for the late 2020s and early 2030s should be building for "certificates as a continuously-rotating secret," not "certificates as a long-lived config file."

7. What we're doing about it

Trace Warrior's SSL/TLS certificate expiry monitor is built for exactly this world. You add a hostname, we open a real TLS connection on every check interval, we read the days remaining, and we email you (and your webhook) before any cert expires. Two thresholds. 24-hour dedupe to avoid spam. Recovery alerts when you successfully renew. We do five monitor types well, not five hundred features poorly.

Try the free SSL/TLS certificate checker right now — no signup, instant results. Then add the certs you actually care about to the monitor — 3 monitors are free on every account, 15 on Starter ($9/mo), 50 on Professional ($29/mo), unlimited on Enterprise, with a 14-day free trial on every paid plan.

We'll keep updating this guide as the March 2026, 2027, and 2029 milestones approach. Bookmark it.

Further reading

• CA/Browser Forum Ballot SC-081v3 (official text) — the source document
• Apple's original 45-day proposal — the discussion that started it
• Let's Encrypt on 6-day certificates — a glimpse of what comes next
• Trace Warrior: SSL/TLS Certificate Expiry Monitor · SSL Certificate Checker