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.
At a glance
What this is: This is a lifecycle and automation analysis of 47-day public TLS certificates, with the key finding that renewal becomes a continuous operational process rather than an occasional maintenance task.
Why it matters: It matters because identity and security teams must govern certificate discovery, ownership, deployment, and verification end to end, or outages will show up faster than manual renewal workflows can absorb them.
👉 Read Akeyless's analysis of the 47-day certificate era and lifecycle automation
Context
Publicly trusted TLS certificates are moving to much shorter lifetimes, which means certificate management stops being an annual hygiene task and becomes a recurring operational control. The security problem is not simply expiry, but the gap between certificate issuance and certificate actually being live on every endpoint that uses it.
For identity and access teams, certificates are machine credentials. When their lifetime contracts, the governance burden shifts to discovery, ownership, lifecycle automation, and verification across the environments that consume them, including load balancers, gateways, Kubernetes, and external services.
Key questions
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. Expired certificates can stop services unexpectedly, incomplete revocation can leave stale trust in place, and auditors may not be able to verify which identities were valid at a given time. Manual processes also make it harder to maintain consistent policy across distributed teams.
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. If those steps are manual or fragmented, more frequent renewals increase the chance of missed deadlines and failed services. The risk is not the shorter lifetime itself. The risk is weak lifecycle discipline at higher tempo.
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. If certificate work still depends on spreadsheets, ad hoc tickets, or last-minute interventions, the automation layer has not replaced the underlying operational risk.
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.
Technical breakdown
Why shorter TLS lifetimes change certificate lifecycle governance
Public TLS certificates bind a domain name to a public key, but that binding only remains trustworthy while the underlying facts stay current. Shorter validity periods reduce the time an outdated, replaced, or misissued certificate can linger in trust. They also force the operational process around the certificate to mature. Issuance, validation, deployment, reload, and verification all have to happen reliably every cycle, not just when a team remembers to act. In practice, the certificate lifecycle becomes a governed production workflow rather than a renewal reminder.
Practical implication: Treat certificate renewal as a repeatable lifecycle control and map every handoff that can still fail between issuance and production use.
Why renewal-only automation leaves certificate risk behind
A certificate can renew successfully at the CA and still fail in production if the replacement never reaches the endpoint that serves traffic. That is the gap between renewal and deployment. Renewal-only tooling reduces administrative effort, but it does not prove the new certificate is installed, activated, and serving on the right system. End-to-end automation has to connect the source of truth, issuance, distribution, activation, and verification into one traceable chain. Without that, a dashboard may show success while the application continues presenting an expiring certificate.
Practical implication: Automate through deployment and verification, not just through issuance, so certificate state matches what users and services actually consume.
What certificate discovery reveals about NHI governance
Certificate inventories often span cloud accounts, containers, load balancers, appliances, and external services, which means the real problem is visibility before expiry. Once certificates are treated as non-human identities, ownership, scope, and revocation become lifecycle questions, not just crypto questions. Discovery exposes which certificates are known, who owns them, where they are deployed, and which systems depend on them. That is the minimum dataset needed to govern machine credentials responsibly when validity windows shrink and the same workflow repeats many times per year.
Practical implication: Build an authoritative inventory that links each certificate to an owner, an endpoint, an application dependency, and a renewal path.
Threat narrative
Attacker objective: The operational objective is not compromise but persistence of an expired or stale certificate in production long enough to trigger trust failure or outage.
- Entry occurs when a certificate renewal succeeds at the authority but the replacement is never deployed to every endpoint that serves the certificate.
- Escalation happens when manual handoffs, brittle scripts, or missing ownership let the expired certificate remain active in production after the trust window closes.
- Impact is service interruption, failed browser trust, or an outage caused by an outdated certificate still being presented to users and APIs.
Breaches seen in the wild
- Sisense breach: unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Renewal-only thinking breaks because the certificate state that matters is the one actually served in production. A successful CA transaction does not guarantee that the load balancer, ingress controller, appliance, or API gateway updated. This is the same failure pattern seen in other NHI programmes: the authority says the object changed, but the runtime estate did not. Practitioners should read this as a deployment-verification gap, not a certificate issuance problem.
Ephemeral trust is becoming the operating assumption for public Web PKI. Long-lived certificates allowed teams to defer lifecycle discipline because the trust window was wide enough to survive manual handling. Once lifetimes contract, the discipline has to move earlier in the process. That means discovery, ownership, and exception handling matter more than heroic last-minute renewal work.
Certificate inventories are really NHI inventories in disguise. Public TLS certificates are machine identities that authenticate systems to relying parties. When they are spread across clouds, containers, and appliances, the governance question becomes who owns the credential, where it is used, and how quickly it can be replaced. Teams that still separate certificate management from NHI governance will miss the lifecycle dependencies that create outage risk.
Continuous certificate lifecycle control is now part of resilience engineering. The shorter the validity period, the less recovery time remains after validation or deployment failures. That makes automation coverage, rollback paths, and exception reporting operational controls, not convenience features. The practitioner takeaway is to measure whether the lifecycle can survive failure, not just whether issuance succeeds.
What this signals
Continuous certificate governance: shorter public TLS lifetimes push teams toward a model where discovery, ownership, deployment, and verification are managed as one control surface. The practical change is that certificate state has to be observable at the endpoint, not just in the issuing system.
Access review habits do not solve certificate expiry. What matters is whether the organisation can prove that renewal actually changed the certificate in production, because trust failure happens where the runtime system still serves the old object.
Teams that already struggle with secrets sprawl will find certificate contraction exposes the same governance weakness in a different form. Once lifetimes shrink, manual exception handling becomes the bottleneck, not the cryptography.
For practitioners
- 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.
- Test exception handling for failed certificate workflows Simulate unreachable endpoints, failed reloads, expired automation credentials, and missing approvals so the process fails visibly instead of silently.
- Measure how many certificates are fully automated Track which certificates are manual, partially automated, or end-to-end automated, then remove exceptions that still depend on human follow-up.
Key takeaways
- Shorter TLS lifetimes turn certificate management into a continuous identity lifecycle problem rather than a periodic maintenance task.
- The main operational failure is not renewal itself but the gap between a renewed certificate and the certificate that is actually serving traffic.
- Organisations need discovery, ownership, deployment verification, and exception handling to keep public certificates from becoming outage drivers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Shorter certificate lifetimes directly challenge long-lived machine credentials. |
| NHI-01 — Improper Offboarding | Expired or unrevoked certificates persist when lifecycle offboarding is incomplete. | |
| Recommendation — Reduce certificate dwell time by enforcing shorter lifecycles and automated renewal paths. Track certificate revocation and removal as a lifecycle closure step, not an afterthought. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate rotation, renewal, and revocation fall under authenticator management. |
| Recommendation — Apply authenticator management controls to govern certificate issuance, renewal, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate ownership and deployment state are part of access authorization for machine identities. |
| Recommendation — Map certificate ownership and deployment to authorization controls and review them continuously. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen or stale certificates can support credential access and movement across systems. |
| Recommendation — Map certificate exposure to credential access paths and monitor where misuse could enable lateral movement. | ||
Key terms
- Publicly trusted certificate: A publicly trusted certificate is a certificate that browsers and other trust stores accept without custom configuration. It is part of the external trust fabric, so expiry, validation, and algorithm changes affect both availability and security for the services that depend on it.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Connection Verification: Connection verification is the post-setup test that confirms a newly created provider can authenticate and communicate with the intended service. It is more than a technical check because it also provides evidence that the credential, scope, and configuration are aligned before the provider is trusted for operations.
- Certificate Inventory: A certificate inventory is the authoritative list of all certificates in use across an environment, including owner, expiry, issuing authority, and deployment location. It is the control foundation for monitoring and renewal because teams cannot govern what they cannot reliably enumerate.
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
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
