TL;DR: CA/B Forum policy will shorten public TLS certificate lifetimes from 398 days to 200 days in 2026, 100 days in 2027, and 47 days by 2029, compressing renewal windows and exposing manual lifecycle weaknesses, according to CyberArk. The real issue is not certificate duration itself, but whether identity governance can sustain continuous renewal, inventory, and ownership at machine scale.
At a glance
What this is: This is an analysis of the shift to 47-day public TLS certificate lifetimes and the operational pressure it puts on certificate lifecycle management.
Why it matters: It matters because certificate governance is part of NHI, workload identity, and broader IAM control coverage, and manual renewal processes will not scale to the new operating model.
By the numbers:
- CA/B Forum policy will shorten public TLS certificate lifetimes from 398 days to 47 days by 2029.
- The first enforcement step in March 2026 will reduce maximum validity to 200 days.
👉 Read CyberArk's analysis of the 47-day TLS certificate lifecycle shift
Context
Public TLS certificates are a machine identity control, not just an operational detail. When certificate lifetimes shrink, the programme shifts from occasional renewal work to continuous lifecycle management, and any manual dependency becomes a reliability problem as well as a security problem.
The article argues that the shortest-path risk is not the new expiry date itself. The real gap is the mismatch between certificate volume, ownership clarity, and renewal cadence, especially in hybrid and multi-cloud environments where certificates are spread across teams and systems.
Key questions
Q: How should security teams prepare for shorter TLS certificate lifetimes?
A: Security teams should inventory all public certificates, assign clear ownership, and automate discovery and renewal before the next validity reduction arrives. The goal is to remove human dependency from recurring renewal work, because shorter lifetimes make manual tracking unreliable. Certificate governance should be treated as a continuous control, not a periodic maintenance task.
Q: When does manual certificate renewal become a security risk?
A: Manual renewal becomes a security risk once the renewal cadence is too tight for spreadsheets, tickets, and ad hoc approvals to keep pace. That point arrives earlier than many teams expect because certificate volume and ownership fragmentation increase the chance of a missed expiry. The operational failure is also a governance failure.
Q: What breaks when public TLS certificates are managed without automation?
A: What breaks first is consistency, then availability. Without automation, teams miss renewals, lose visibility into certificate ownership, and struggle to keep pace with shortening validity periods. In practice, that means outages become more likely, exception handling becomes routine, and the certificate lifecycle stops being a controlled process.
Q: Who is accountable when a certificate expires and causes downtime?
A: Accountability should sit with the team that owns the certificate lifecycle, not just the infrastructure that hosts it. If ownership is unclear, the incident exposes a wider governance problem in identity and access management because no one is responsible for renewal, exception handling, or escalation. That ambiguity is what makes certificate outages repeat.
Technical breakdown
Why shortened TLS certificate lifetimes change certificate lifecycle management
TLS certificate validity is shrinking in stages, which forces organisations to treat renewal as an ongoing control rather than an annual maintenance task. That matters because certificate expiry is both an availability risk and an identity assurance issue. When the renewal interval collapses, any dependency on spreadsheets, ticket queues, or one-off manual approvals creates a failure path that is hard to see until services break. The governance problem is no longer whether certificates exist, but whether every public certificate is continuously tracked, attributed, and renewed within a much tighter operating window.
Practical implication: move public certificate lifecycle handling into automated discovery, policy, and renewal workflows before the next validity reduction lands.
Why manual renewal cannot keep pace with machine identity growth
Certificate management sits inside the wider machine identity problem: workloads, services, and public-facing applications depend on identities that outnumber human identities and renew more often than humans can reliably supervise. Manual handling may appear to work at low scale, but it fails when certificate counts increase, ownership fragments, and exceptions multiply. The article’s operational point is that renewal load, not just certificate count, is the pressure multiplier. If the process cannot handle recurring cycles without human intervention, the control has already become brittle.
Practical implication: quantify renewal volume per team and remove any certificate path that still depends on ad hoc human follow-up.
How discovery, policy, and orchestration reduce TLS outage risk
Certificate lifecycle automation is effective because it connects three functions: discovery, policy enforcement, and renewal orchestration. Discovery finds public certificates before expiry, policy defines what is allowed, and orchestration performs the renewal with enough lead time to avoid outages. Without that chain, teams may know a certificate exists but still fail to renew it on time. In practice, the risk is often not cryptographic failure but governance failure: an unmanaged certificate, an unclear owner, or a renewal path that was never designed to be repeatable at scale.
Practical implication: build one governed workflow that can discover, classify, and renew certificates across all public-facing environments.
NHI Mgmt Group analysis
47-day TLS is a certificate lifecycle shock, not a simple policy update. The shorter validity window forces identity teams to abandon any model built around periodic manual renewal. That model was designed for a slower operational cycle, and it fails when certificates must be renewed continuously across distributed environments. The implication is that certificate governance now belongs in the same operational conversation as NHI inventory, ownership, and lifecycle enforcement.
Manual certificate renewal is the new standing-risk pattern. Once the renewal interval shrinks, every untouched spreadsheet, ticket queue, and exception path becomes a latent outage condition. This is not just inefficiency, it is a governance gap that creates avoidable service disruption. Practitioners should treat each manual renewal dependency as evidence that certificate lifecycle control is already below acceptable maturity.
Certificate ownership is becoming as important as certificate validity. The article shows why the hardest part of TLS governance is not generating a new certificate, but proving who owns renewal, who approves exceptions, and who is accountable when a certificate lapses. That is an NHI governance problem in disguise, because machine identities fail when accountability is unclear. The practical conclusion is that ownership metadata must be as reliable as the certificate itself.
Continuous lifecycle governance will separate resilient identity programmes from reactive ones. Organisations that still manage public certificates as isolated events will carry more operational risk than those that run them as a governed identity lifecycle. The market signal is clear: certificate automation is moving from optimisation to basic resilience. Teams that delay will spend more time recovering from outages than preventing them.
Certificate expiry windows now expose the identity blast radius. A missed renewal is no longer a single certificate problem when certificates are woven through public services, APIs, and distributed application estates. The named concept here is the identity blast radius: how far a single lifecycle failure can propagate across systems. Practitioners should assume that a certificate lapse can disrupt more than one service path unless ownership and renewal orchestration are tightly controlled.
From our research:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity programmes still lack a reliable machine inventory.
- For a broader view, see: The 52 NHI breaches Report for the real-world patterns behind unmanaged identity failure.
What this signals
Certificate lifecycle governance is converging with broader NHI management. As public certificate lifetimes compress, teams will need the same discipline they use for service account oversight: ownership, inventory, renewal, and offboarding. In practice, that means certificate handling should move into the same governance conversation as workload identity and secrets management, not remain a separate ops function.
The practical signal is that renewal volume will become a capacity metric, not just a technical one. Teams that can still see every certificate and every owner will have a far easier path to automation than teams trying to reconstruct their estate after a lapse.
Identity blast radius: this is the operational reach of a single certificate failure across connected services, APIs, and customer-facing systems. Once organisations see renewal as a lifecycle control, they can reduce the blast radius by tying discovery, policy, and orchestration to one governed process.
For practitioners
- Map every public certificate to an owner and renewal path. Build a complete inventory of externally trusted certificates, then assign a named owner, renewal dependency, and escalation path for each one. If a certificate cannot be traced back to a responsible team, treat it as a governance defect rather than an operational nuisance.
- Automate renewal before validity shortens again. Move public TLS renewal into a repeatable workflow that can handle discovery, policy checks, approval, and reissuance without manual ticket chasing. Focus first on certificates tied to customer-facing services, shared platforms, and acquisition environments where outages are most visible.
- Measure renewal load against team capacity. Count the number of certificates renewed per month, the time required per renewal, and the proportion still handled manually. Use that baseline to identify where human review is already too slow for the next certificate lifetime reduction.
- Use certificate expiry as a governance test. Review whether certificate renewal failures are being caused by missing inventory, unclear ownership, or broken orchestration. Each failure mode points to a different control gap, and the fix should follow the gap, not the symptom.
Key takeaways
- Shorter TLS lifetimes turn certificate management into a continuous identity governance problem rather than an occasional operational task.
- The main risk is not the new expiry date itself, but the combination of manual renewal, unclear ownership, and incomplete certificate visibility.
- Automation, inventory, and accountable ownership are now the controls that determine whether certificate changes cause outages or pass quietly.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shorter cert lifetimes raise renewal failure risk and lifecycle control exposure. |
| NIST CSF 2.0 | PR.AC-4 | Certificate ownership and access governance align with identity control and accountability. |
| NIST Zero Trust (SP 800-207) | TLS certificates underpin trust decisions in zero trust environments. |
Map certificate lifecycle ownership to identity controls and review them before expiry windows shrink further.
Key terms
- Certificate Lifecycle Management: Certificate lifecycle management is the governed process of discovering, issuing, renewing, rotating, and revoking TLS certificates. In practice, it becomes an identity control when certificate validity windows shrink and human handling can no longer keep pace with expiry, ownership, and policy enforcement across distributed systems.
- Machine Identity: A machine identity is the credentialed identity used by a non-human system such as a service, workload, API, or application. Unlike human identity, it can exist at very high volume and often requires continuous lifecycle control because renewal, rotation, and revocation affect service availability directly.
- Identity Blast Radius: Identity blast radius is the range of systems, services, and workflows affected when one identity control fails. For certificates and other machine identities, a single lapse can spread quickly across public services, APIs, and dependent applications, making ownership and orchestration part of resilience, not just administration.
Deepen your knowledge
NHI governance, machine identity security, and secrets 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 lifecycle control in your organisation, it is worth exploring.
This post draws on content published by CyberArk: TLS certificate lifetimes are shortening, and automation is the only scalable response. Read the original.
Published by the NHIMG editorial team on 2025-08-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org