Notifications
Clear all
Topic starter
10/07/2026 9:09 pm
TL;DR: Certificate lifetimes will shrink from 200 days in 2026 to 47 days in 2029, turning manual renewal, revocation, and inventory management into a near-continuous operational burden, according to GlobalSign. The real issue is not the date itself, but the fact that certificate governance now depends on automation, ownership, and auditability rather than periodic maintenance.
NHIMG editorial — based on content published by GlobalSign: The journey to 47-day certificates, from chaos to clarity in certificate management
By the numbers:
- For 2026, certificates will expire every 6 to 7 months, and by 2029 that drops to 47 days.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when certificate lifetimes become too short for manual renewal?
A: Manual renewal breaks first, followed by ownership visibility and revocation timing.
Q: Why do short-lived certificates matter to non-human identity governance?
A: Certificates are a form of non-human identity because they authenticate services, workloads, and systems.
Q: How do security teams know if certificate automation is actually working?
A: Look for fewer missed expiries, shorter revocation delays, complete certificate inventory coverage, and fewer emergency renewals.
Practitioner guidance
- Map every certificate to an owner and service Build a live inventory that links each certificate to its system, business owner, renewal date, and dependency chain.
- Automate renewal and revocation workflows Move high-volume certificates into policy-driven workflows so renewal, validation, and revocation happen through API-based processes instead of tickets and reminders.
- Prioritise high-risk certificate estates first Start with externally exposed services, VPNs, and internal applications whose failure would interrupt business operations.
What's in the full article
GlobalSign's full article covers the operational detail this post intentionally leaves for the source:
- A staged timeline for the move from 200-day to 100-day and 47-day certificate lifetimes.
- Practical implementation examples for certificate lifecycle management across AWS, Azure, and endpoint environments.
- Operational arguments for why manual certificate administration breaks at scale and where automation changes the model.
- A future-facing discussion of cryptographic agility and post-quantum preparation in certificate programmes.
👉 Read GlobalSign's analysis of the 47-day certificate lifecycle transition →
47-day certificate lifetimes: are your controls ready for the change?
Explore further
10/07/2026 9:33 pm
Short-lived certificates are becoming machine identity governance, not just PKI maintenance. As certificate validity shrinks, the control problem moves from periodic renewal to continuous lifecycle assurance. That is the same pattern identity teams already know from non-human identity governance: ownership, inventory, rotation, and revocation all matter at machine scale. The practical conclusion is clear. Certificate programmes must be run as identity programmes, not as ticket queues.
A question worth separating out:
Q: Who is accountable when expired certificates cause outages or exposure?
A: Accountability should sit with the system owner, the platform owner, and the security function that governs machine identity policy. If certificate expiry can take down services or extend trust beyond its intended window, it is a lifecycle governance failure, not just a technical mistake.
👉 Read our full editorial: 47-day certificates will break manual TLS operations by 2029
