47-day TLS certificates raise the stakes for machine identity governance

At a glance

What this is: This is an analysis of the CA/B Forum’s move to 47-day TLS certificate lifetimes and the operational shift it forces on certificate and machine identity management.

Why it matters: It matters because shorter certificate validity turns renewal, revocation, and auditability into continuous identity governance work across NHI, infrastructure, and adjacent IAM programmes.

By the numbers:

• The CA/B Forum’s latest move to 47 days represents the most dramatic evolution yet.
• A 47-day validity period means companies will need to renew and redeploy certificates nearly eight times more frequently than they do today.
• The rollout begins in stages, shortening validity from 398 to 200 days in 2026, and ultimately to 47 days by 2029.

👉 Read Akeyless's analysis of 47-day TLS certificate governance

Context

Publicly trusted TLS certificates are a machine identity control as much as a web security control. When validity periods shrink, the problem is no longer just cryptographic hygiene, but whether an organisation can prove it can issue, renew, deploy, and revoke certificates before service disruption occurs.

The governance gap is operational, not theoretical. Enterprises that still depend on human-tracked renewal windows, ticket queues, and ad hoc certificate inventories will struggle as renewal cadence tightens, especially where certificates are embedded in load balancers, Kubernetes ingress, and hybrid environments. That is why certificate lifecycle management now sits alongside broader NHI governance rather than a separate infrastructure task.

Key questions

Q: How should security teams manage certificate renewals as validity periods shrink?

A: Security teams should treat certificate renewal as a continuous automated workflow rather than a periodic manual task. That means discovery, issuance, deployment, validation, and revocation must be connected, with ownership and rollback defined for each certificate-bearing system. If any step depends on a human reminder, expiry risk remains.

Q: Why do short-lived TLS certificates increase operational risk?

A: Short-lived TLS certificates increase operational risk because every renewal creates another chance for delay, misconfiguration, or missed deployment. The shorter the validity window, the less tolerance there is for human queues and partial inventories. The result is more outage exposure unless the organisation can automate the full lifecycle.

Q: What breaks when certificate lifecycle management is still manual?

A: Manual certificate lifecycle management breaks when the renewal cadence is faster than the organisation’s approval and deployment process. Expired certificates can interrupt services, trigger emergency change work, and leave compliance teams without reliable evidence that trust controls were applied on time.

Q: Who is accountable when a certificate expires and causes an outage?

A: Accountability should sit with the team that owns the certificate lifecycle, not just the infrastructure team that hosts the service. In mature programmes, security, operations, and application owners share responsibility for inventory accuracy, automation coverage, and exception handling. The key question is whether ownership is explicit before expiry occurs.

Technical breakdown

Why short-lived certificates change machine identity operations

TLS certificate lifetime is the maximum period a certificate remains trusted before it must be renewed. As lifetimes shorten, the certificate itself becomes a high-frequency identity artefact, not a long-lived asset. This shifts the control problem from issuance alone to continuous lifecycle management, including validation, distribution, replacement, and revocation. In hybrid estates, the blast radius of a missed renewal grows because one expired certificate can interrupt multiple services that share the same trust chain.

Practical implication: treat certificate renewal as a continuous control plane function, not a periodic admin task.

Why automation becomes mandatory for certificate renewal

Automation is the only practical way to maintain certificate validity at a 47-day cadence. The process includes CSR generation, CA validation, issuance, deployment to endpoints, and downstream restart or reload events. Manual steps break under that frequency because the human approval path, change window, and deployment lag all become failure points. The real technical issue is not the CA rule itself, but the mismatch between machine-time renewal cycles and human-paced operations.

Practical implication: map every certificate renewal step to an automated workflow with validation, deployment, and rollback built in.

How auditability ties certificate lifecycle to governance

Certificate lifecycle management is also an evidence problem. Security teams need immutable records of issuance, renewal, revocation, and policy enforcement to demonstrate compliance and to troubleshoot outages quickly. When certificate actions are dispersed across tools and teams, governance breaks down because no single source of truth exists for what was issued, when it changed, and whether it was rotated on time. That turns certificate operations into an audit and resilience issue, not just an access issue.

Practical implication: centralise certificate events into an auditable system of record that can feed SIEM and compliance reporting.

Threat narrative

Attacker objective: The objective is not a traditional breach but prolonged service disruption and weakened trust through certificate expiry and poor lifecycle control.

1. Entry occurs when an organisation depends on manual certificate renewal processes that cannot keep pace with shorter validity windows.
2. Escalation follows when expired or unmanaged certificates create service interruption, failed trust validation, or delayed remediation across dependent systems.
3. Impact is operational outage, compliance failure, and wider trust degradation across services that rely on machine certificates.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Short-lived certificate governance is now a machine identity problem, not a PKI housekeeping problem. Once certificate lifetimes fall to 47 days, the control question changes from whether certificates are issued correctly to whether the organisation can govern machine identity continuously across provisioning, deployment, and revocation. That brings TLS directly into NHI governance because the certificate is the identity artefact that proves workload trust. Practitioners should stop treating certificate lifecycle as a back-office activity.

Manual renewal assumptions were designed for longer trust windows and they fail under compressed validity. The assumption that an operations team can see, ticket, approve, and redeploy a certificate before expiry was built for a much slower renewal rhythm. That assumption fails when renewal cycles collapse to 47 days because the organisation cannot rely on human-paced intervention as the control point. The implication is that certificate governance must be modelled as continuous machine identity lifecycle management.

Ephemeral trust debt: the shorter the certificate lifetime, the more hidden operational debt accumulates in inventories, exceptions, and remediation queues. Every certificate left outside automation becomes a time-bomb for outage, audit finding, or emergency renewal. This is not solved by more reminders or larger teams because the debt is structural and grows with the number of endpoints. Practitioners should identify where renewal risk is being deferred rather than eliminated.

Crypto-agility is becoming a governance discipline, not a cryptography slogan. The article’s emphasis on automation, auditability, and key protection points to a broader shift in identity programmes: cryptographic controls now need lifecycle policy, evidence, and ownership as much as they need algorithms. Organisations that separate crypto from identity governance will miss the operational dependency that short-lived certificates expose. The practitioner conclusion is to govern certificates as part of the broader identity control fabric.

Consolidating certificates, secrets, and workload identity reduces the chance of hidden trust islands. When certificate management sits apart from API tokens, SSH keys, and workload credentials, organisations create shadow trust paths that are hard to inventory and harder to govern. The broader lesson is that identity programmes need one operating model for machine credentials, not separate silos for each artefact. Practitioners should align certificate policy with the same lifecycle discipline used for other NHIs.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• The same research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, showing how often identity governance still breaks at the boundary between inventory and control.
• For teams extending certificate governance into broader machine identity programmes, the next step is NHI Lifecycle Management Guide, which connects lifecycle ownership to provisioning, rotation, and offboarding.

What this signals

Ephemeral trust debt: certificate programmes that rely on ticketing and human reminders will become increasingly brittle as validity periods compress. The practical signal is simple: if a renewal cannot be discovered, approved, deployed, and verified without a person chasing it, the control is already behind the curve.

The stronger the convergence between certificates, secrets, and workload identity, the more important a single lifecycle model becomes. Teams that separate these controls will create hidden exceptions and duplicate inventories, while programmes aligned to the NIST Cybersecurity Framework 2.0 can map renewal risk into governance, protect, detect, and respond functions.

If your inventory cannot show which certificates are automated, which are exception-managed, and which are one missed change window away from expiry, the issue is no longer compliance cadence. It is programme visibility, and that is where machine identity governance usually starts to fail.

For practitioners

• Inventory every certificate-bearing dependency Build a current map of certificates tied to load balancers, ingress controllers, service endpoints, and internal APIs. Include owners, renewal dates, CA source, and downstream dependencies so the organisation can see where a missed renewal would cause service disruption.
• Automate renewal, deployment, and rollback together Do not automate issuance in isolation. Tie renewal to endpoint deployment, health checks, and rollback so the workflow can complete without waiting for manual change windows or ad hoc tickets.
• Create a system of record for certificate events Centralise issuance, renewal, revocation, and exception handling into an auditable inventory that can feed compliance reporting and incident response. This closes the gap between certificate operations and governance evidence.
• Review exception paths for shadow certificates Identify certificates managed outside the standard process, including temporary deployments and environment-specific overrides. These are the places where expiry risk and audit failure typically accumulate first.

Key takeaways

• Shortened TLS lifetimes turn certificates into a continuous machine identity governance problem rather than a periodic renewal task.
• The operational evidence points to a steep cadence increase, with renewal cycles moving toward eight times the current frequency by 2029.
• The control that matters most is end-to-end automation with auditable lifecycle ownership, not manual reminder-based renewal.

Key terms

• Certificate lifecycle management: Certificate lifecycle management is the discipline of issuing, renewing, distributing, revoking, and auditing certificates across their full usable life. In mature environments it is an identity control, because certificate validity determines whether workloads can prove trust to one another without interruption.
• Crypto-agility: Crypto-agility is the ability to change cryptographic mechanisms, keys, or policies quickly without breaking service. For identity teams, it means the environment can adapt to shorter certificate lifetimes, new trust requirements, or key compromise without redesigning the whole platform.
• Machine identity: Machine identity is the identity used by a non-human system such as a workload, service, certificate, token, or key to authenticate and interact with other systems. It needs lifecycle governance because it is often invisible, widely distributed, and easy to over-trust.
• Ephemeral trust: Ephemeral trust is a short-lived trust relationship that must be renewed frequently to remain valid. In identity operations it reduces exposure windows, but it also demands stronger automation, better inventory, and tighter evidence because the trust artefact expires quickly.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• Specific automation patterns for certificate issuance and renewal across public and private CAs
• Implementation detail for zero-knowledge key protection and how DFC is applied in the platform
• Examples of policy-driven rotation timing, downstream restarts, and audit logging integrations
• Platform-level packaging of certificate lifecycle management alongside broader secret handling

👉 Akeyless's full post covers the certificate automation, key protection, and compliance mechanics in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.