Topic starter
25/09/2026 5:31 pm
TL;DR: Akeyless explains that publicly trusted TLS server certificates will drop to a 47-day maximum by March 15, 2029, with intermediate reductions to 200 days in 2026 and 100 days in 2027, forcing organisations to automate discovery, issuance, deployment, and verification instead of treating renewal as periodic maintenance. The real control shift is from calendar-based certificate management to continuous lifecycle governance.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “47-Day Certificates: What Changes and How to Prepare”.
By the numbers:
- Certificate authorities can reuse domain control validation data for only 10 days by 2029.
Key questions
Q: What breaks when certificate lifetimes shrink to 47 days?
A: Manual certificate processes break first, followed by renewal consistency, deployment timing, and outage tolerance.
Q: Why do shorter certificate lifetimes create more operational risk?
A: Shorter lifetimes compress the time teams have to discover, approve, renew, and validate trust without interruption.
Q: How do teams know whether certificate automation is actually working?
A: Look for fewer human-mediated renewals, cleaner ownership records, lower expiry-driven outage rates, and reliable reporting across hybrid systems.
Practitioner guidance
- Build a complete public TLS certificate inventory Map every publicly trusted certificate across cloud accounts, data centres, Kubernetes, load balancers, CDNs, appliances, and managed services.
- Automate issuance through deployment and verification Connect request, validation, issuance, installation, reload, and post-deployment checks into one workflow.
- Set renewal buffers before the expiry window closes Define renewal timing that leaves room for CA delays, DNS updates, approvals, and retry attempts.
Bottom line: Shorter public TLS lifetimes force certificate management out of the occasional-maintenance model and into continuous lifecycle governance.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step certificate lifecycle demo across discovery, issuance, deployment, and monitoring
- Operational examples for Windows, Linux, Kubernetes, web apps, and internal services
- Workflow details for associating managed certificates with targets and automating renewal
- Health tracking, notifications, and audit logging used to catch expiration before service impact
👉 Read Akeyless's analysis of the 47-day certificate lifecycle shift →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/09/2026 5:31 pm
47-day certificates make certificate lifecycle governance continuous, not periodic. The article shows that public TLS validity reductions turn a once-annual maintenance task into a repeating operational chain across discovery, validation, issuance, deployment, and verification. That does not just increase workload; it exposes every ungoverned handoff in the certificate estate. Practitioners should read this as a governance shift, not a date change.
A few things that frame the scale:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
A question worth separating out:
Q: Should organisations prioritise inventory cleanup before the 100-day phase?
A: Yes. Inventory gaps, orphaned certificates, and unclear ownership become harder to remediate as renewal cadence tightens. The 200-day phase is the best window to find unknown certificates, remove manual handoffs, and test automation before the shorter deadlines leave little margin for correction.
👉 Read our full editorial: 47-day certificates turn TLS renewal into continuous lifecycle control