47-Day Certificates: What Actually Changes and What to Do About It
The industry says automate faster. We think you're automating the wrong thing.
April 12, 2026 · [cyphrs] Team · 14 min read
1. The Headline Everyone Saw
In April 2025, the CA/Browser Forum unanimously passed Ballot SC-081. The headline: TLS certificate lifetimes are being compressed from 398 days to 47 days. Apple proposed it. Google, Mozilla, and every major certificate authority voted for it. The timeline is phased but non-negotiable.
The reaction was predictable. Vendors published "what you need to know" articles. Security media covered the 8x increase in renewals. Reddit threads split between practitioners who understood the security rationale and operators who dreaded the operational fallout. Most coverage landed on the same conclusion: you need to automate your certificate renewals.
That conclusion is correct but incomplete. Automating renewals solves the symptom. The deeper question – the one almost nobody in those threads or articles is asking – is whether the certificates causing you pain should be public certificates at all.
2. The Timeline: What's Actually Happening
SC-081 doesn't just reduce certificate lifetimes. It compresses two separate clocks simultaneously: the maximum certificate validity period and the Domain Control Validation (DCV) reuse window. Understanding both is critical, because the interaction between them is where the real operational pain lives.
| Effective Date | Max Validity | DCV Reuse | Renewals/Year | DCV Challenges/Year |
|---|---|---|---|---|
| Before March 2026 | 398 days | 398 days | ~1 | ~1 |
| March 15, 2026 | 200 days | 200 days | ~2 | ~2 |
| March 15, 2027 | 100 days | 100 days | ~4 | ~4 |
| March 15, 2029 | 47 days | 10 days | ~8 | ~37 |
Most coverage focuses on the "8x renewals" number. That's the certificate validity story. But look at the last column. By 2029, you'll need to prove domain ownership roughly every 10 days – that's 37 DCV challenges per domain per year. Every single one requires a successful DNS challenge, HTTP token placement, or email verification. Every single one can fail.
The Hidden Multiplier
The DCV reuse window shrinking to 10 days is the detail most 47-day articles bury or miss entirely. Certificate renewal is one operation. Domain validation is a separate operation that must succeed first. When DCV reuse was 398 days, you proved domain ownership once a year. At 10 days, you prove it 37 times. If you manage 200 domains across different registrars and DNS providers, that's 7,400 domain validation events per year that need to succeed without human intervention.
3. Why This Is Happening
The security rationale is straightforward and, frankly, hard to argue with. Shorter certificate lifetimes address three structural problems with the current public PKI ecosystem.
CRLs are too large for browsers to download reliably. OCSP has latency and privacy problems (your browser tells the CA which sites you visit). OCSP stapling helps but requires server support and correct implementation, which is spotty. The practical result: if a certificate is compromised, revoking it doesn't reliably prevent its use. Shorter lifetimes reduce the window of exposure because the certificate expires before revocation would have taken effect anyway.
A 398-day certificate means a compromised key can be used for over a year. A 47-day certificate means the same compromised key is useful for at most 47 days. In a "harvest now, decrypt later" threat landscape, with post-quantum computing on the horizon, reducing key lifetimes is a meaningful defense-in-depth measure.
Domains change hands. Organizations lose control of subdomains. DNS records go stale. A 398-day DCV reuse period means a certificate can attest to domain ownership that hasn't been verified in over a year. Tighter DCV reuse ensures the entity holding the certificate actually still controls the domain.
All three arguments are valid. Browser vendors and CAs are solving a real problem. The tension isn't with the reasoning – it's with the assumption that every certificate in your infrastructure is subject to these constraints.
4. The Question Nobody's Asking
Read any of the top-ranking articles on 47-day certificates. DigiCert, Keyfactor, CyberArk, SSL.com, Sectigo. Every one reaches the same conclusion: you need certificate lifecycle management automation. They're right. But they're answering "how do we renew faster?" when the better question is "why are we renewing these at all?"
SC-081 applies exclusively to publicly trusted TLS certificates – certificates issued by CAs in browser root stores. It does not apply to certificates issued by private certificate authorities. Your internal CA, whether it's Microsoft ADCS, HashiCorp Vault, step-ca, EJBCA, or any other private CA, is not subject to the 47-day timeline. Not now. Not in 2029. Not ever.
This distinction matters because, in most organizations, a significant percentage of certificates that are currently public don't need to be. The services holding those certificates don't need browser trust. They got public certificates because Let's Encrypt was free and easy, or because the team that set it up didn't know there was another option, or because nobody thought hard about trust boundaries.
The Reframe
Every certificate you move from public to private trust is a certificate you permanently remove from the 47-day treadmill. Not by automating the renewal, but by eliminating the need for it. Private certificates operate on whatever lifecycle your policy dictates: 90 days, a year, an hour. The decision is yours, driven by your security requirements, not a browser vendor's timeline.
5. Which Certificates Actually Need to Be Public
Public certificate authorities exist to solve one specific problem: proving identity to clients you don't control – primarily web browsers. The entire public trust model, from the CA/Browser Forum's governance to Chrome's root program, is built for that single use case.
Here's the classification that matters:
Customer-facing websites and web apps
Public APIs consumed by external clients
Email servers communicating with external MTAs
Any endpoint where the client is unknown
These stay on public PKI. Automate them with ACME.
Internal APIs and microservices
Kubernetes service-to-service mTLS
Internal dashboards and admin panels
Database connections and message queues
VPN concentrators and jump hosts
IoT and OT devices on isolated networks
Client authentication (mTLS)
CI/CD pipeline authentication
Candidates for private CA. Immune to SC-081.
For most organizations, the second column is significantly longer than the first. That asymmetry is the opportunity. Every service you migrate from public to private trust is one fewer certificate on the 47-day treadmill, one fewer DCV challenge to manage, one fewer point of failure in your renewal pipeline.
6. The Let's Encrypt Factor
The 47-day timeline arrives at a particularly awkward moment for organizations that built their certificate infrastructure on Let's Encrypt. Two concurrent changes make the landscape harder than the headline suggests.
First, Let's Encrypt removed the Client Authentication Extended Key Usage (EKU) from its certificates. Default removal happened February 11, 2026. Full removal comes July 8. Anyone using Let's Encrypt certificates for mTLS or client authentication – and many organizations do, particularly self-hosters and smaller shops that used the same certificate for everything – is discovering that the foundation shifted underneath them.
Second, Let's Encrypt now offers 6-day certificates. The intent is positive: shorter lifetimes mean even smaller compromise windows. But operationally, 6-day certificates require bulletproof automation with zero tolerance for failure. A single failed renewal at 3 AM on a Friday means your service is down by Monday. For public-facing sites with mature automation, this is fine. For the internal services that got Let's Encrypt certificates because it was convenient, it's a trap.
The convergence is significant: certificate lifetimes are compressing while the scope of what public certificates can do is narrowing. These aren't separate trends. They're two expressions of the same structural shift: public PKI is becoming more specialized, more automated, and less suitable for internal use cases. The industry is telling you, in increasingly direct terms, that internal services belong on internal trust.
7. A Practical Playbook
Whether you act now or wait until 2029, the work is the same. The only difference is how much pressure you're under when you do it. Here's the playbook, ordered by impact and dependency.
Step 1: Discover what you have
You cannot plan a migration you can't see. Most organizations undercount their certificates by 30-50%. Certificates live on load balancers, CDN edges, Kubernetes ingress controllers, container images, appliance firmware, mail servers, VPN concentrators, and dozens of other places that don't appear in any single inventory. A comprehensive scan across your infrastructure – internal and external – is the non-negotiable first step.
For each certificate you find, you need three pieces of information: when it expires, who issued it (public CA or private), and what service it's attached to. That third piece is the one most inventories miss, and it's the one that determines everything else.
Step 2: Classify by trust requirement
For every certificate in your inventory, answer one question: does this service need to be trusted by unknown external clients? If the answer is yes, it stays on public PKI. If the answer is no – and for internal APIs, service mesh communication, admin dashboards, database connections, and most mTLS implementations, the answer is no – it's a candidate for migration to private trust.
This classification exercise alone will reframe your 47-day exposure. Instead of "we have 500 certificates that need to renew 8 times a year," the picture becomes "we have 50 public certificates that need automation and 450 internal certificates that can move to private trust and operate on our own terms."
Step 3: Automate what stays public
For the certificates that genuinely need public trust, ACME automation is now mandatory. Not recommended. Mandatory. At 47-day lifetimes with 10-day DCV reuse, manual renewal is mathematically impossible at scale. Deploy certbot, acme.sh, or your CA's ACME client. Test renewal in staging. Monitor for failures. Build alerting that triggers before expiry, not after.
If a service can't support ACME – legacy appliances, air-gapped networks, devices without ACME clients – that's a strong classification signal. The inability to automate public certificate renewal means the service doesn't fit the public trust model. It belongs on private PKI.
Step 4: Stand up private trust
This used to be the hard part. Running an internal CA historically meant Microsoft ADCS (complex, requires Active Directory, expensive to maintain) or deploying Vault, step-ca, or EJBCA (powerful but operationally heavy). For mid-market organizations without a dedicated PKI team, both paths felt like trading one set of problems for another.
That's changed. Modern internal CA solutions compress deployment from weeks to hours. They issue certificates instantly, support ACME for internal services, handle revocation in real time, and operate on whatever lifecycle policy makes sense for your infrastructure. The barrier to private trust is lower than it's ever been.
Step 5: Migrate incrementally
You don't need to migrate everything at once. Start with the services that are easiest to move and cause the most renewal pain. Internal APIs behind a load balancer are typically straightforward – update the certificate source, distribute the CA root to internal clients, done. Kubernetes service-to-service communication is often already designed for private certificates. Internal dashboards and admin tools are low-risk migrations with high payoff.
Each migration permanently removes a certificate from the public renewal pipeline. By the time 47-day lifetimes arrive in 2029, the only certificates on that treadmill should be the ones that genuinely need browser trust.
8. The Math That Actually Matters
Most analyses of the 47-day transition focus on raw renewal counts. Here's the math that tells a more useful story.
| Scenario | Public Certs | Private Certs | Annual Public Renewals | Annual DCV Events |
|---|---|---|---|---|
| All public (status quo) | 500 | 0 | 4,000 | 18,500 |
| After classification | 75 | 425 | 600 | 2,775 |
| Reduction | – | – | 85% fewer | 85% fewer |
The assumption in this table – that 85% of certificates don't need public trust – is conservative for most enterprise environments. The actual ratio is often higher. But even at 85%, the operational difference is transformative. Instead of managing 18,500 DCV events per year, you're managing 2,775. Instead of 4,000 automated renewals that can each individually fail and cause an outage, you have 600.
The 425 certificates on private trust? They renew on your schedule, with your CA, without domain validation challenges, without rate limits from external providers, and without dependency on internet connectivity. If you want to renew them every 30 days for security, you can. If you want to issue them for a year while you build out shorter-lived automation, you can do that too.
9. What Happens If You Just Automate Everything
It's a fair question. If ACME automation works and you can renew 500 certificates every 47 days, why bother with the public/private classification? Why not just automate your way through?
You can. But you're accepting several constraints that don't go away with better tooling.
Every renewal depends on an external CA's availability and your ability to reach it. Let's Encrypt has had outages. CAs rate-limit issuance. DNS propagation delays can cause DCV failures. Your internal services' uptime is now coupled to external infrastructure you don't control.
Every DCV challenge is an attack surface. DNS challenges require write access to DNS records – if an attacker compromises that access, they can issue certificates for your domains. HTTP challenges expose validation tokens. At 37 DCV events per domain per year, you're exposing these surfaces constantly.
Public CAs are removing client authentication support. Chrome's root program is mandating the separation. Let's Encrypt has already dropped the Client Auth EKU. If you need mTLS – and in a zero-trust architecture, you do – public certificates can't provide it.
CyberArk's research estimates 4 hours of operational overhead per certificate lifecycle event when factoring in troubleshooting, monitoring, and incident response. At 4,000 renewals per year, that's 16,000 hours – roughly 8 full-time engineers doing nothing but certificate operations. Even with automation handling the happy path, failures still require human intervention.
Automation is essential for the certificates that must stay public. But treating it as the complete answer ignores the structural opportunity to remove most of your infrastructure from the public PKI treadmill entirely.
10. Your Timeline for Action
The phased SC-081 timeline gives you milestones to plan against. Each step is an opportunity to reduce exposure before the next compression hits.
200-day certificates issued in March 2026 start expiring around October. This is your first test. Scan your infrastructure, identify what you have, classify by trust requirement. Fix any certificates that will expire before your team expects them to. Start migrating the easiest internal services to private trust.
Renewal frequency doubles again. Manual processes that survived 200-day lifetimes will break at 100. ACME automation must be solid for all remaining public certificates. Private CA infrastructure should be operational and handling the majority of internal certificate issuance.
The end state. If you've done the classification and migration work, only genuinely public-facing services are on this timeline. Your automated pipeline handles them. Everything else runs on private trust with lifecycle policies you control. The 47-day deadline arrives and your internal infrastructure doesn't notice.
11. The Real Transition
The 47-day certificate timeline is real and it's coming. But the most important transition it triggers isn't about renewal frequency. It's about trust architecture. The organizations that come through this well won't be the ones with the best ACME automation. They'll be the ones that asked the right question early: which of our services actually need public trust?
That question leads to a simpler infrastructure. Fewer external dependencies. Smaller attack surfaces. Full control over certificate lifecycle policies. And an architecture that's structurally immune to every future compression the CA/Browser Forum decides to impose.
The 47-day countdown is already running. The question isn't how fast you can renew. It's how many certificates you're renewing that never needed to be public in the first place.
Start with visibility
The [cyphrs] Scout scanner finds every certificate across your infrastructure – public and private – and shows you exactly which ones are exposed to the 47-day timeline. The [cyphrs] Score gives you a single number that reflects your readiness.