The CA/Browser Forum passed Ballot SC-081 in April 2025. By March 2029, the maximum validity for publicly-trusted TLS certificates drops to 47 days. Not 90 days. Not 60 days. Forty-seven.
This isn’t a proposal anymore. It’s ratified. The timeline is set. And most enterprises aren’t ready.
If your organization manages certificates manually — spreadsheets, calendar reminders, ticket-based renewal workflows — you have roughly 3 years to completely overhaul how you handle TLS certificates. After that, every certificate in your infrastructure needs renewal every 6 weeks. Miss one, and your service goes down.
The Timeline: What’s Actually Happening
The reduction isn’t instant. It’s phased:
| Date | Maximum Validity | DCV Reuse Period |
|---|---|---|
| Before March 2026 | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
The “DCV Reuse Period” column is equally important. Today, when a CA validates your domain ownership, that validation is reusable for up to 398 days. By 2029, domain validation expires after just 10 days. This means even if you have automation, the validation challenge (DNS record, HTTP file) must be completable within a 10-day window every renewal cycle.
Why 47 Days? The Security Rationale
The argument is straightforward:
1. Revocation doesn’t work. CRLs and OCSP are fundamentally broken for public web certificates. Browsers soft-fail (accept the certificate even if they can’t check revocation). The only reliable way to “revoke” a certificate is to let it expire. Shorter validity = shorter exposure window.
2. Domain validation goes stale. A certificate proves domain ownership at issuance time. If the domain changes hands (sold, expired, hijacked), the old certificate remains valid until expiry. At 398 days, a stolen domain’s certificate works for over a year. At 47 days, it works for 6 weeks maximum.
3. Key compromise exposure. If a private key is stolen, the attacker can impersonate the server until the certificate expires (since revocation is unreliable). Shorter certificates bound this window.
4. Forces automation. The CA/Browser Forum explicitly acknowledges that 47-day certificates are impossible to manage manually. This is intentional — it forces the ecosystem toward automation, which eliminates the human errors that cause most certificate outages.
What This Means for Your Infrastructure
The Math Problem
Let’s say your organization has 500 TLS certificates today, managed with 398-day validity:
- Current renewal workload: ~500 renewals per year (roughly 1.4 per day)
- At 47-day validity: ~3,900 renewals per year (roughly 10.7 per day)
That’s a 7.8x increase in renewal operations. Every single day, you need ~11 certificates renewed, deployed, and verified. Weekends included. Holidays included.
If even 2% of renewals fail (DNS timeout, deployment error, service not reloaded), that’s 78 failed renewals per year — each one a potential outage.
Systems That Break First
1. Legacy load balancers with manual cert upload. F5 BIG-IP, Citrix ADC, and older HAProxy deployments where certificates are uploaded through a web GUI. No API, no automation path. These need replacement or an automation layer in front of them.
2. Appliances and embedded systems. Firewalls, VPN concentrators, IoT gateways, and network devices that serve TLS but have no ACME client and no certificate API. Each one is a manual renewal every 47 days.
3. Third-party SaaS with custom domains. You use a SaaS product with your custom domain (e.g., portal.yourcompany.com hosted on a third-party platform). The SaaS provider manages the certificate. If they don’t support 47-day automation, your custom domain breaks.
4. Multi-cloud deployments without unified CLM. Certificates in AWS ACM, Azure Key Vault, GCP Certificate Manager, and on-premises — each with different renewal mechanisms. Without a single control plane, something gets missed.
5. Partner integrations with certificate pinning. If a partner pins your certificate (or its public key), every renewal requires coordination. At 47-day cycles, this coordination happens every 6 weeks.
How to Prepare: A Practical Roadmap
Phase 1: Inventory (Do This Now)
You can’t automate what you can’t see. Before anything else:
- Scan all network endpoints for TLS certificates (ports 443, 8443, 636, 993, and any custom TLS ports)
- Query cloud APIs — AWS ACM, Azure Key Vault, GCP Certificate Manager
- Check Kubernetes — all
tlsSecrets across all clusters and namespaces - Identify non-automatable systems — devices with no API, no ACME support, manual-only cert upload
- Map certificate ownership — who is responsible for renewing each certificate?
The output: a complete inventory with renewal method (automated/manual) and owner for every certificate.
Phase 2: Automate the Easy Ones (Next 6 Months)
For certificates that CAN be automated today:
- Web servers (Nginx, Apache, Caddy): Deploy ACME clients (certbot, acme.sh, Caddy’s built-in). Use DNS-01 challenges for wildcard and CDN-fronted domains.
- Kubernetes: Deploy cert-manager with appropriate issuers. Every Ingress and Gateway should have automated certificate provisioning.
- Cloud load balancers: AWS ACM already auto-renews. Azure App Service has auto-renewal. GCP managed certificates auto-renew. Verify these are configured.
- CDN/edge: Cloudflare, Fastly, and CloudFront handle their own certificates. Verify custom domain certificates are in auto-renewal mode.
Phase 3: Solve the Hard Problems (6-18 Months)
For systems that can’t run ACME clients:
- Legacy load balancers: Deploy a CLM platform that can push certificates via vendor APIs (F5 iControl REST, Citrix NITRO). If no API exists, plan hardware replacement.
- Network appliances: Use a certificate proxy pattern — ACME client renews the cert centrally, then pushes to the appliance via SSH/SCP/API.
- IoT and embedded: Evaluate whether these devices need publicly-trusted certificates at all. Many can use private CA certificates (which aren’t subject to CA/B Forum rules).
- Partner integrations: Start conversations now about certificate rotation procedures. Establish automated notification workflows.
Phase 4: Validate at 47-Day Cadence (12-24 Months)
Before the deadline, prove your automation works at the target cadence:
- Issue certificates with 47-day validity from a test CA (or Let’s Encrypt staging)
- Run for 3+ months — observe renewal success rates
- Identify and fix failures (DNS propagation delays, rate limits, deployment race conditions)
- Monitor: alert on any certificate with <7 days remaining (your buffer is only 7 days at 47-day validity)
The Automation Stack You Need
At 47-day validity, you need a complete automation pipeline:
Certificate Authority (ACME-compatible)
↓
Orchestrator (cert-manager, CLM platform, or custom automation)
↓
Deployment (push to target systems — LB, CDN, K8s, servers)
↓
Reload (trigger service to load new cert — nginx reload, API call)
↓
Verification (connect to endpoint, confirm new cert is served)
↓
Monitoring (alert if any step fails, alert on approaching expiry)Every step must be automated. Every step must be monitored. A failure at any step means the certificate isn’t renewed — and at 47-day validity, you have very little buffer before expiry.
What About Private Certificates?
The 47-day rule applies only to publicly-trusted certificates (issued by CAs in browser trust stores). Private CA certificates (issued by your own internal CA) are not subject to CA/Browser Forum rules.
This means:
- Internal mTLS certificates: unaffected (set whatever validity you want)
- Development/staging certificates: unaffected
- IoT device certificates from private CAs: unaffected
- VPN and Wi-Fi certificates: unaffected
However, if you use publicly-trusted certificates for internal services (some organizations do, for convenience), those ARE affected. Consider migrating internal services to a private CA to avoid the 47-day constraint where it’s unnecessary.
The Business Case for Acting Now
The organizations that will struggle most are those that wait until 2028 to start preparing. Here’s why acting now matters:
- Automation deployment takes 6-12 months for complex environments (legacy systems, multi-cloud, partner integrations)
- Testing at 47-day cadence takes 3-6 months to validate reliability
- Budget cycles — if you need hardware replacement (legacy LBs without APIs), that’s a capital expense that needs planning
- Vendor evaluation — if you need a CLM platform, evaluation + procurement + deployment is 6-12 months in enterprise environments
The math: 6-12 months (deploy) + 3-6 months (validate) + 6-12 months (procurement) = 15-30 months of lead time. The deadline is March 2029 — roughly 34 months away. The window is tight.
FAQ
Q: Is this really happening? Could it be reversed? A: Ballot SC-081 passed with overwhelming support (browser vendors unanimously in favor). It would require a new ballot to reverse, and no browser vendor has indicated interest in doing so. Plan as if it’s final.
Q: Does this affect wildcard certificates? A: Yes. Wildcard certificates are subject to the same validity limits. They’ll need renewal every 47 days just like single-domain certificates.
Q: What about EV and OV certificates? A: Same rules. The validity reduction applies to all publicly-trusted TLS certificates regardless of validation level.
Q: Can I just use longer-lived certificates from a private CA for everything? A: For internal services, yes. For anything that needs to be trusted by public browsers (customer-facing websites, public APIs), no — you must use publicly-trusted certificates subject to the 47-day limit.
Q: What if my ACME automation fails? A: At 47-day validity with renewal at day 30, you have a 17-day buffer. If automation fails and isn’t fixed within 17 days, the certificate expires. This is why monitoring and alerting on renewal failures is critical — not just monitoring expiry dates.
Key Takeaway
47-day certificates aren’t a technical challenge for organizations with mature automation. cert-manager, ACME clients, and cloud-managed certificates already handle this cadence trivially. The challenge is for organizations with manual processes, legacy systems, and no certificate inventory. For them, this is a 2-3 year infrastructure modernization project — and the clock is already ticking.
The question isn’t whether to automate certificate management. That decision has been made for you. The question is whether you start now (with time to plan and test) or later (under pressure, with outages as motivation).