Topic starter
25/09/2026 5:31 pm
TL;DR: The move to 47-day public TLS certificates will force organisations to treat renewal, deployment, and verification as a continuous lifecycle, not a calendar task, because shorter validity sharply increases the number of operational touchpoints, according to Akeyless. The real issue is not the expiry date itself, but the assumption that certificate management can still be reviewed and remediated manually at human pace.
NHIMG editorial: based on content published by Akeyless: 47-day certificates turn TLS renewal into continuous lifecycle control
Questions worth separating out
Q: What breaks when certificate revocation and renewal are not automated in cloud environments?
A: The main failure is not cryptography, it is operational control.
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 certificate inventory Record every public TLS certificate, its owner, CA, expiration date, deployment target, and application dependency so you can see where lifecycle gaps exist.
- Automate issuance through deployment and verification Connect validation, issuance, distribution, activation, and post-deploy checks so the replacement certificate is confirmed on the endpoint that serves traffic.
- Set renewal buffers before the expiry window tightens Define renewal thresholds that leave room for retries, domain validation failures, endpoint restarts, and rollback when automation or infrastructure is unavailable.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- The phased certificate-validity schedule from 398 days to 200 days, 100 days, and 47 days
- The end-to-end lifecycle stages that extend beyond renewal into deployment, verification, and revocation
- The demo-oriented workflow details for certificate discovery, association, and automated provisioning
- The practical readiness steps for inventorying certificates across cloud, Kubernetes, Windows, Linux, and external services
👉 Read Akeyless's analysis of the 47-day certificate era and lifecycle automation →
47-day certificates: are your renewal controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/09/2026 5:31 pm
47-day certificates expose certificate management as a governance problem, not a renewal problem. The useful control is no longer the reminder date. The useful control is whether an organisation can discover, assign, deploy, verify, and revoke certificates as one lifecycle. That shifts ownership from isolated admins to an identity governance model that treats certificates as machine credentials with accountable lifecycle states.
A question worth separating out:
Q: Should organisations treat TLS certificates as NHI assets?
A: Yes. TLS certificates are machine identities because they prove a non-human system is who it claims to be. That means they should be governed with the same discipline used for other sensitive NHI credentials: inventory, ownership, rotation, auditability, and retirement when no longer needed.
👉 Read our full editorial: 47-day certificates turn TLS renewal into continuous lifecycle control
