Notifications
Clear all
Topic starter
06/06/2026 11:29 am
TL;DR: Certificate lifespans are shrinking from annual renewals to 200 days now and 47 days next, forcing approval cycles, ownership models, and deployment workflows to operate eight times as often, according to Keyfactor. The operational issue is not policy itself but the assumption that certificate lifecycle management can still be handled on a calendar cadence.
NHIMG editorial — based on content published by Keyfactor: When Policy Moves Faster Than People: Surviving the Shift to 47-Day Certificate Lifespans
By the numbers:
- As of March 15, 2026, maximum TLS certificate lifespans dropped to 200 days.
Questions worth separating out
Q: How should security teams prepare for shorter certificate lifespans?
A: Teams should inventory every certificate, assign clear ownership, and automate renewal and deployment before renewal cadence tightens further.
Q: Why do shorter certificate lifespans create operational risk?
A: Shorter lifespans compress the time available for approval, issuance, deployment, and validation.
Q: What breaks when certificate renewals are still managed manually?
A: Manual renewal models break when the certificate interval becomes shorter than the organisation’s approval and tracking cycle.
Practitioner guidance
- Inventory certificate ownership end to end Map every certificate to a named business owner, technical owner, and renewal path so no asset depends on tribal knowledge or a single admin queue.
- Automate renewal and deployment workflows Remove ticket-based approval from the renewal critical path wherever policy and risk allow, then validate that issuance, install, and restart steps run without manual intervention.
- Measure expiry risk as an operational metric Track mean time to renew, percentage of certificates inside the renewal window, and failed deployment rates so teams can see whether cadence is keeping up.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- The comic-driven PKI Admin storyline that frames the 47-day transition in operational terms.
- The lifecycle-agility guidance for teams moving from annual renewals to repeated renewal cycles.
- The webinar series referenced in the post for readers who need implementation detail beyond the governance analysis.
- The practical examples of where manual approvals and spreadsheet tracking become bottlenecks.
👉 Read Keyfactor's analysis of 47-day certificate lifespans and PKI operations →
47-day certificate lifespans: what is your PKI team missing?
Explore further
06/06/2026 12:19 pm
Shorter certificate lifespans expose lifecycle debt, not just PKI complexity. When renewals shift from annual to near-continuous, organisations discover whether ownership, visibility, and deployment are real or merely assumed. The policy change is forcing a re-evaluation of operational maturity across certificate estates, especially where manual tracking still dominates. Practitioners should treat this as a lifecycle governance test, not a tooling upgrade prompt.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when a certificate expires and services go down?
A: Accountability should rest with the service owner, the platform team managing deployment, and the security function governing lifecycle policy. Shorter lifespans make shared ownership unavoidable, because certificate expiry now affects availability as well as security. Frameworks such as the NIST Cybersecurity Framework 2.0 help define that responsibility boundary.
👉 Read our full editorial: 47-day certificate lifespans are exposing PKI governance gaps
