Notifications
Clear all
Topic starter
25/06/2026 10:34 pm
TL;DR: CA/B Forum rules shortened publicly trusted TLS/SSL certificate validity to 825 days from March 1, 2018, forcing certificate authorities and site operators to adjust renewal and validation processes, according to DigiCert. The change makes certificate lifecycle management more automated, because long-lived certificates slow standards changes and extend risk windows.
NHIMG editorial — based on content published by DigiCert: 3-Year Certificates to Be Eliminated in Industry-Wide Change
By the numbers:
- EV certificates have been limited to a 2-year maximum since their introduction in 2007.
Questions worth separating out
Q: How should teams manage certificates when validity periods are shortened?
A: Teams should move from calendar-based tracking to automated certificate lifecycle management.
Q: Why do shorter certificate lifetimes matter for security operations?
A: Shorter lifetimes reduce how long weak or outdated trust settings can remain in circulation.
Q: What breaks when certificate ownership is unclear?
A: Renewal and replacement break first, because no one is accountable for validating the certificate before expiry.
Practitioner guidance
- Automate certificate renewal workflows Replace manual certificate replacement steps with automated issuance, validation, and deployment workflows that operate before expiry windows close.
- Create a complete certificate inventory Maintain a continuously updated inventory of certificates, their owners, expiry dates, and the services that depend on them.
- Assign accountable owners to certificate-bearing services Map each certificate to a named operational owner so renewal, replacement, and incident response do not depend on shared team memory.
What's in the full article
DigiCert's full post covers the operational detail this post intentionally leaves for the source:
- The CA/B Forum timing details behind the 825-day certificate validity change and how it affects issuance planning.
- The transition implications for DV, OV, and EV certificate handling across public trust environments.
- The operational rationale DigiCert gives for shorter lifetimes and how it connects to algorithm and key-length changes.
- The practical timing constraints for stopping three-year certificate requests before the industry deadline.
👉 Read DigiCert's guidance on the end of three-year TLS certificates →
3-year TLS certificates are ending: what should IAM teams do?
Explore further
25/06/2026 11:09 pm
Shorter certificate lifetimes expose the fragility of manual trust administration. When certificate validity collapses from years to a shorter window, spreadsheet-based tracking and occasional renewal campaigns stop being viable at scale. The operational issue is not just more work, but a tighter trust cadence that leaves less room for missed ownership, delayed validation, or forgotten endpoints. Practitioners should treat certificate lifecycle maturity as a core identity control, not a back-office task.
A few things that frame the scale:
- 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
- Manual processes still dominate, with 61% relying on spreadsheets or manual tracking for machine identity management, according to The Critical Gaps in Machine Identity Management report.
A question worth separating out:
Q: Who is accountable when a certificate expires and causes an outage?
A: The accountable party should be the service or system owner, with PKI or platform teams providing the renewal controls and automation. In practice, responsibility must be assigned before expiry so the organisation can prove oversight, respond quickly, and avoid treating certificate failure as an unexpected event.
👉 Read our full editorial: Shorter certificate lifetimes are reshaping PKI governance
