Notifications
Clear all
Topic starter
24/06/2026 7:32 pm
TL;DR: Shorter TLS lifetimes now move to 200 days in 2026, 100 days by 2027, and 47 days by 2029, forcing organisations to prove they can replace certificates fast enough to survive the next compromise, according to DigiCert. The real issue is not routine renewal but whether PKI operations have the inventory, automation, and emergency rotation discipline needed to absorb change without outage.
NHIMG editorial — based on content published by DigiCert: Why shorter certificate lifetimes actually matter
By the numbers:
- TLS lifetimes dropped to 200 days in March 2026, dropping again to 100 days by 2027 and 47 days by March 2029.
Questions worth separating out
Q: How should teams prepare for shorter certificate lifetimes in production?
A: Teams should start with inventory, automation, and rollback readiness.
Q: Why do shorter certificate lifetimes improve security if keys are not already compromised?
A: They improve security by shrinking the time window in which a stolen or exposed certificate can remain useful.
Q: What breaks when certificate lifecycle management is still manual?
A: Manual certificate management breaks when organisations need speed, completeness, and repeatability at the same time.
Practitioner guidance
- Build complete certificate inventory Map every certificate, private key, issuing CA, and deployment location across all environments, then verify the map with automated discovery rather than spreadsheet ownership lists.
- Automate replacement end to end Script issuance, deployment, validation, and rollback so certificate replacement can happen without manual handoffs, ticket chasing, or environment-specific exceptions.
- Test emergency rotation as an incident drill Run a live exercise where a certificate is assumed compromised and teams must replace it under pressure, confirm service continuity, and document where the process fails.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The full certificate lifecycle timeline behind the 200-day, 100-day, and 47-day changes
- The operational reasoning DigiCert uses to connect shorter lifetimes with post-quantum agility
- The product-specific detail on Trust Lifecycle Manager and how it supports discovery and renewal
- The article's longer discussion of revocation limits, browser behaviour, and emergency replacement
👉 Read DigiCert's analysis of why shorter certificate lifetimes matter →
Shorter certificate lifetimes: is your PKI ready for the change?
Explore further
25/06/2026 4:52 am
Shorter certificate lifetimes expose a certificate lifecycle governance gap, not a certificate technology problem. The pressure comes from the gap between cryptographic validity and operational readiness. Organisations that can still only renew certificates on human schedules are already out of alignment with how machine trust now has to work. The implication is that certificate lifecycle management has become a governance discipline, not a clerical one.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to our research on NHI and secrets exposure.
A question worth separating out:
Q: Who is accountable when a certificate expires and services fail?
A: Accountability sits with the team that owns certificate lifecycle governance, not just the operator who clicks renewal. Organisations should define ownership for discovery, reissue, deployment, and validation so expiry failures are tracked as operational control failures rather than isolated incidents.
👉 Read our full editorial: Shorter certificate lifetimes and the agility gap in PKI
