SSL Certificates Are About to Expire 8× Faster. Here's What That Means for Your Agency.

What the CA/B Forum decided — and why

In April 2025, the Certificate Authority/Browser (CA/B) Forum ratified Ballot SC-081v3 — a proposal originally put forward by Apple. The ballot introduces a phased schedule for reducing the maximum lifetime of publicly trusted SSL/TLS certificates from the current 398 days down to 47 days. Every major browser vendor voted in favour: Apple, Google, Mozilla, and Microsoft.

The reasoning behind the change comes down to three things:

• Reduced attack surface. A compromised certificate that lasts 47 days causes far less damage than one that lasts 13 months. Shorter lifetimes shrink the window of exploitation.
• Forcing automation. The CA/B Forum has been pushing the industry toward automated certificate management for years. At 47-day validity, manual processes simply become infeasible — the change effectively mandates automation.
• Post-quantum readiness. With quantum computing threatening current cryptographic standards, the ability to rapidly cycle certificates across the internet becomes critical. Shorter lifetimes build that muscle before it's urgently needed.

The phased timeline: three deadlines you need in your calendar

The change isn't happening all at once. There are three hard dates:

The first deadline — 200-day maximum — lands on 15 March 2026. That is less than three weeks away. Certificates issued on or after that date from any publicly trusted CA will be capped at 200 days. If you renew a certificate before that date, you can still get the current 398-day maximum. After that, 200 days is the ceiling.

Note also that the Domain Control Validation (DCV) reuse period shrinks in parallel. Currently, a CA can reuse domain ownership proof for up to 398 days. By 2029 that drops to 10 days — meaning the domain ownership validation process itself becomes nearly continuous.

What this means for agencies managing client SSL

If your agency manages SSL certificates for client websites — whether handling renewals yourself, delegating to clients, or bundled into a managed hosting package — the operational impact scales directly with the number of domains you look after.

The maths are stark. Consider an agency with 50 client domains on SSL:

• Today (398 days): roughly 50 renewal events per year
• From March 2026 (200 days): roughly 90 renewal events per year
• From March 2027 (100 days): roughly 180 renewal events per year
• From March 2029 (47 days): roughly 400 renewal events per year

If each renewal is a 30-minute task — noticing it's due, generating or requesting it, installing it, verifying it — 400 events is 200 hours per year, from one person, just on SSL. For an MSP with 500 client domains, that's 2,000 hours.

And that's the optimistic scenario where nothing goes wrong. The moment a renewal is missed — even by a day — the client's browser starts throwing certificate errors. Browsers don't distinguish between "we forgot" and "this site is dangerous." The visitor experience is identical: a full-screen red warning.

Why monitoring is the foundation of everything

Before you can automate SSL renewals, you need to know what you have. That sounds obvious, but in practice most agencies have a surprisingly fuzzy picture of their SSL estate:

• Certificates issued by different CAs across different client projects
• Certificates installed on hosting platforms the agency no longer directly controls
• Certificates on subdomains that were added years ago and since forgotten
• Wildcard certificates that cover a domain but expire separately from others on the same client account

In the 398-day world, a fuzzy inventory was manageable — there was usually enough time to discover a certificate had expired and fix it before the client escalated. In a 47-day world, a certificate that slips through the cracks creates a problem within weeks of issuance.

This is where Aideworks fits. We continuously monitor the SSL state of every domain you add — tracking expiry date, issuer, and any certificate change. When a certificate is approaching expiry, you get an alert with enough lead time to act. When a certificate is replaced (or suddenly invalid), you know immediately — not when a client calls.

Monitoring doesn't replace automation — but it gives you the visibility that makes automation trustworthy. You can't confidently say "our automation handles SSL renewals" unless you also have independent monitoring that confirms the automation actually ran successfully.

The automation case: manual renewal is dead

The CA/B Forum's decision was explicitly designed to make manual certificate management untenable. The industry standard for automated certificate issuance and renewal is ACME — the Automatic Certificate Management Environment protocol, defined in RFC 8555 and used by Let's Encrypt and most major CAs today.

ACME automates the full certificate lifecycle: it requests a certificate, completes the domain validation challenge automatically, retrieves the issued certificate, installs it, and schedules the next renewal — all without human intervention. On most modern hosting stacks (nginx, Caddy, Kubernetes cert-manager, Cloudflare), ACME is either built in or trivial to add.

ACME supports three domain validation methods:

• HTTP-01 — places a verification file on the web server. Standard for public-facing sites.
• DNS-01 — adds a TXT record to the domain's DNS. Required for wildcard certificates; works even without an active web server.
• TLS-ALPN-01 — validates via a TLS handshake. Useful when HTTP and DNS challenges aren't viable.

The catch with ACME and the new 10-day DCV reuse period is timing: your automation needs to be configured to renew early enough that domain validation, issuance, and installation all complete before a certificate expires. With a 47-day certificate and no buffer, there is essentially no margin for automation failures. Monitoring alerts become the early warning system that tells you when automation has silently stopped working.

What to do now

The window to act before the first real change is small. Here's a practical sequence:

1. Audit your current SSL estate

Before anything else, get a complete picture of what you have. Add all your client domains to an SSL monitoring tool — Aideworks will check the current certificate, report the expiry date, and flag anything already expired or expiring within your configured threshold. Do this for all domains, including subdomains.

2. Renew long-lived certificates before 15 March 2026

If you have certificates due for renewal in the next 3–6 months, consider renewing them now — before the deadline — to lock in the current 398-day maximum. Certificates issued before 15 March 2026 remain valid until their natural expiry date, even after the new rules take effect.

3. Identify which domains can be automated

For domains hosted on platforms you control, assess ACME compatibility. Caddy and modern nginx installations support ACME natively. cert-manager handles it for Kubernetes. Platforms like Cloudflare, AWS, and most major hosting providers have built-in auto-renewal. The goal is to move as many domains as possible to zero-touch renewal.

4. Establish monitoring as a safety net

Even with ACME running everywhere, monitoring is your fallback. Add all domains to Aideworks and set alerts to trigger 14–21 days before expiry. That window gives you time to investigate and intervene if automation has silently failed — and at 47-day lifetimes, silent failures are exactly the kind of thing that catches agencies off-guard.

5. Plan for OV certificates separately

If any of your clients use OV (Organisation Validated) or EV (Extended Validation) certificates, note that while the same lifetime limits apply, OV/EV certificates require manual identity re-validation annually. They can't be fully automated via ACME alone — your automation renewals will also trigger CA callbacks and identity checks. Identify these now and build their workflow separately.