47-Day Certificates Are Coming — Is Your Team Ready?
Google’s Moving Forward proposal. Apple’s push for shorter validity periods. The CA/Browser Forum’s trajectory toward 47-day maximum certificate lifespans. This isn’t speculation — it’s an active, concrete industry direction with broad support.
And when it arrives, every manual certificate process in your organization will break. Not degrade. Break.
The Timeline
| Year | Maximum Cert Lifespan | Renewals/Year (per cert) |
|---|---|---|
| Pre-2020 | 2 years (825 days) | 0.5 |
| 2020-present | 1 year (398 days) | 1 |
| Proposed Phase 1 | 200 days | 2 |
| Proposed Phase 2 | 100 days | 4 |
| Proposed Final | 47 days | 8 |
From 1 renewal per year to 8. That’s an 8x increase in certificate management workload for every single certificate.
Why Shorter Lifespans?
-
Reduced exposure window. If a private key is compromised, a 47-day cert limits the attack window. Revocation (CRL/OCSP) is unreliable in practice — shorter lifespans are more effective.
-
Forced automation. Manual processes work (barely) with annual renewals. They fail completely with 47-day rotation. The industry is explicitly forcing automation as a security baseline.
-
Faster algorithm agility. When cryptographic standards change (post-quantum, key size increases), short-lived certificates allow faster ecosystem-wide rotation.
What Works Today (That Will Fail Tomorrow)
| Current Practice | Works at 1 Year | Works at 47 Days |
|---|---|---|
| Manual renewal via MMC/certutil | YES (barely) | NO |
| Spreadsheet tracking | YES (stale but functional) | NO |
| Quarterly certificate reviews | YES (catches most) | NO |
| Email reminder to cert owner | YES (time to act) | NO |
| Manual load balancer updates | YES (tolerable frequency) | NO |
| One-person PKI management | YES (manageable volume) | NO |
Every single row fails. Not “becomes harder.” Fails completely.
The Math That Breaks Everything
300 certificates, current 1-year lifespan:
- Renewals per year: 300
- Average per week: ~6
- Total annual workload: 150 hours (one engineer, manageable)
300 certificates, 47-day lifespan:
- Renewals per year: 2,400
- Average per week: ~46
- Total annual workload: 1,200 hours (0.6 FTE doing nothing but renewals)
At 500 certificates: 1 full-time engineer doing nothing but renewals.
This is not sustainable manually. Period.
Renewal Workload Explosion
300 certificates: annual renewals & engineer hours as lifespans shrink
8×
More renewals at 47 days vs 1 year
1,200 hrs
= 0.6 FTE doing nothing but renewals
What Breaks First
- Volume Overwhelm — 46 renewals per week exceeds human capacity
- Error Rate Increases — 2% error rate × 2,400 renewals = 48 problems/year
- Missed Renewals — Miss one week = 6-7 simultaneous expiries
- Staffing Crisis — Nobody stays in a role clicking through 46 renewals weekly
- Audit Nightmare — Documentation quality drops under firefighting conditions
What Must Be Automated
| Process | Why It Can’t Be Manual |
|---|---|
| Certificate renewal request | 2,400/year impossible to trigger manually |
| CSR generation | Repeatable, error-prone |
| Certificate deployment | Can’t hand-deploy 46 certs/week |
| Service binding | Must update automatically |
| Validation/testing | Can’t manually verify 46 renewals/week |
| Rollback on failure | Too frequent for manual intervention |
The Transition Plan
Phase 1: Assessment (Now)
- Inventory all certificates by renewal method (auto vs manual)
- Calculate your environment-specific workload multiplier
- Identify which certificates will be affected
Phase 2: Quick Wins (Months 1-3)
- Enable auto-enrollment for all Windows certificates
- Implement ACME for publicly-facing certificates
- Automate load balancer certificate deployment
Phase 3: Full Automation (Months 3-6)
- Automate remaining manual processes
- Implement automated deployment verification
- Test at increased rotation frequency
Phase 4: Optimization (Months 6-12)
- Achieve target: less than 5% of renewals require human intervention
- Build exception processes for certificates that can’t be automated
- Reduce certificate count through consolidation
What About Internal Certificates?
“But 47-day maximums are for public TLS certificates. Our internal certs aren’t affected.”
Partially true. But:
- The security logic applies equally to internal certificates
- Tools and expectations will align — auditors will ask why internal certs lag behind
- If you build automation only for external certs, you maintain two processes
- Internal certificate lifespan reduction will follow within 2-3 years
The Bottom Line
47-day certificates will arrive. The timeline is 12-36 months for public certs. Internal practices will follow.
Your current workload × 8. That’s what’s coming. Can your current process survive that multiplier?
Start automating now, while you have the luxury of time.
47-day certificates aren’t a threat. They’re a forcing function for automation that should have happened years ago.
Tags: 47-Day Certificates, Short-Lived Certificates, Certificate Automation, ACME, PKI Automation, Certificate Lifecycle Management, CLM, Google Apple CA/Browser Forum