What changed
CA/Browser Forum Ballot SC081v3 was approved after the vote that ended on April 11, 2025. It reduces the maximum validity period for publicly trusted TLS server certificates in phases and also shortens domain validation reuse periods. The final phase reaches a 47-day maximum certificate lifetime in March 2029.
Last reviewed on 2026-06-02. This applies to publicly trusted TLS certificates. Private PKI and internal-only certificates are governed by your own trust model, not by browser public-trust requirements.
| Effective date | Maximum certificate lifetime | Maximum domain validation reuse | Operational effect |
|---|---|---|---|
| Before March 15, 2026 | 398 days | 398 days | Annual renewal habits may still appear to work, but public verification is still needed. |
| March 15, 2026 | 200 days | 200 days | Semiannual renewal cadence makes missed automation easier to notice too late. |
| March 15, 2027 | 100 days | 100 days | Quarterly renewal cadence makes manual ownership and alert routing fragile. |
| March 15, 2029 | 47 days | 10 days | Monthly renewal cadence requires automated issuance, deployment, verification, and alerts. |
Why this changes operations
Annual renewal habits do not survive monthly certificate lifecycles. A 47-day certificate leaves room for roughly a monthly renewal cycle with a small recovery buffer. If domain validation, issuance, deployment, or service reload fails, the team has less time to notice and intervene.
- Manual calendar reminders become unreliable because renewal becomes routine operational work.
- Domain validation must be repeatable, especially for DNS-01 and delegated DNS workflows.
- Certificate deployment must reach every CDN, load balancer, ingress, and server without manual handoffs.
- Monitoring thresholds need to be shorter and more urgent as certificate lifetimes shrink.
- Post-renewal verification matters more because old certificates can remain on public endpoints.
Let's Encrypt is also shortening lifetimes
Let's Encrypt currently has its own public timeline for reducing default certificate lifetimes. It also made short-lived 6-day certificates generally available as an opt-in profile in January 2026. These are not the default, but they are a practical stress test for whether renewal, deployment, and monitoring are actually automated.
| Date | Change |
|---|---|
| January 15, 2026 | 6-day and IP address certificates generally available as opt-in short-lived certificates. |
| May 13, 2026 | Opt-in tlsserver profile switches to 45-day certificates. |
| February 10, 2027 | Default classic profile switches to 64-day certificates with a 10-day authorization reuse period. |
| February 16, 2028 | Default classic profile switches to 45-day certificates with a 7-hour authorization reuse period. |
Update alert thresholds before lifetimes shrink
The same threshold does not mean the same thing across certificate lifetimes. A 14-day warning on a 398-day certificate is late but workable. A 14-day warning on a 47-day certificate is already inside the recovery buffer.
| Certificate lifetime | Early warning | Urgent warning | Operational implication |
|---|---|---|---|
| 398 or 200 days | 30 days | 14 and 7 days | Enough time for normal vendor and deployment coordination. |
| 100 days | 30 or 21 days | 14, 7, and 3 days | Automation should already be the default path. |
| 64 or 45 days | 21 or 14 days | 7, 3, and 1 days | Manual renewal is fragile; monitor renewal success and served certificate changes. |
| 47 days | 21 or 14 days | 7, 3, and 1 days | Monthly renewal cadence needs automatic issuance, deployment, verification, and alert routing. |
| 6 days | Daily checks | Same-day escalation | Only use when renewal and deployment are fully automated and observable. |
Build the readiness checklist now
The right preparation is not buying a calendar tool. It is removing hidden handoffs from the certificate lifecycle and proving the public endpoint changed after renewal.
- Inventory public hostnames by owner, system, environment, and certificate source.
- Move issuance to ACME or a managed certificate platform where possible.
- Make DNS validation repeatable without one person's local credentials.
- Deploy certificates through infrastructure automation, platform APIs, or managed edge services.
- Monitor the public served certificate and alert when expiry windows, SANs, issuer, fingerprint, or trust state change.
- Test shorter lifetimes on low-risk hostnames before production deadlines force the change.
Where Domain Trust Watch fits
Domain Trust Watch does not automate issuance. It helps with the visibility layer shorter lifetimes make more important: public certificate inventory, staged expiry warnings, served-certificate change detection, and alert delivery evidence.
- Use monitors to see which public hostnames are entering shorter renewal windows.
- Use certificate snapshots to prove the public endpoint moved to the new certificate.
- Use signed webhooks when certificate events should create tickets or update internal inventory.