By NHI Mgmt Group Editorial TeamPublished 2026-05-20Domain: Workload IdentitySource: GlobalSign

TL;DR: TLS certificate validity is shrinking from 200 days in 2026 to 100 days in 2027 and 47 days in 2029, which makes manual renewal, revocation, and audit workflows operationally fragile, according to GlobalSign. The real issue is not shorter lifetimes themselves, but the assumption that certificate lifecycles can still be governed by human-paced processes.


At a glance

What this is: This is an analysis of the move to 47-day TLS certificate lifetimes and the operational failure of manual certificate lifecycle management.

Why it matters: It matters because certificates are NHI credentials, and shorter validity windows expose weak rotation, revocation, and ownership models across workload, platform, and infrastructure identity programmes.

By the numbers:

👉 Read GlobalSign's guidance on the 47-day certificate management shift


Context

47-day TLS certificate lifetimes are a certificate lifecycle management problem, not just a PKI housekeeping issue. When validity windows shrink from months to weeks, every renewal, revocation, inventory check, and exception path becomes part of the identity control plane for machine credentials.

Manual certificate governance depends on humans noticing expiry, coordinating renewal, and proving revocation before service disruption. That model breaks as certificate cadence accelerates, because workload identities and service endpoints cannot tolerate the same delay windows as human access workflows.


Key questions

Q: How should security teams prepare for 47-day TLS certificate lifetimes?

A: Security teams should move from manual renewal to automated certificate lifecycle management. That means inventorying every certificate, assigning ownership, integrating issuance and revocation workflows, and testing replacement paths before expiry windows shrink further. The goal is to remove human timing from a process that will soon operate on near-weekly cadence.

Q: Why do shorter TLS certificate lifetimes create governance risk?

A: Shorter lifetimes compress the time available for discovery, approval, renewal, and revocation. If those steps depend on humans, organisations will miss deadlines, keep stale trust active, and expose services to avoidable outage or compliance failure. The risk is operational first, but it quickly becomes identity governance failure.

Q: What breaks when certificate renewal is still manual?

A: Manual renewal breaks first in inventory accuracy, then in execution timing, and finally in auditability. Teams may know certificates exist, but not who owns them or which services depend on them. When the renewal window shrinks to weeks, even small delays can cause widespread service disruption.

Q: Who is accountable when a certificate expires and services fail?

A: Accountability sits with the team that owns the certificate lifecycle, not just the infrastructure it protects. Organisations should define ownership for discovery, renewal, revocation, and exception handling before the expiry date arrives. If those responsibilities are split across teams, failure becomes predictable rather than accidental.


Technical breakdown

Why short-lived certificates break manual renewal workflows

TLS certificates are NHI credentials because they bind trust to a machine or service rather than a person. When lifetime shrinks to 47 days, renewal stops being an occasional maintenance task and becomes a continuous lifecycle process. Manual queues, ticket handoffs, and spreadsheet-based ownership all create exposure windows where certificates expire before action is taken. The technical risk is not simply expiry. It is the loss of deterministic lifecycle control across inventory, validation, issuance, and revocation.

Practical implication: teams need machine-readable inventory and automated renewal triggers before validity windows compress further.

Certificate lifecycle management versus secrets rotation

Certificate lifecycle management is broader than secret rotation because it covers issuance, renewal, revocation, key protection, and replacement across integrated systems. In short-lived certificate environments, the weak point is often not cryptography but the operational chain that surrounds it. If renewal depends on a person confirming state, the control is already too slow. API-driven workflows, inventory accuracy, and auditability become the mechanism that keeps trust current.

Practical implication: treat certificate management as an identity lifecycle workflow, not as an isolated PKI task.

Why auditability becomes a control requirement

Shorter certificate lifetimes force every renewal and revocation event into a much tighter evidence window. That changes the technical requirement from simple compliance recordkeeping to continuous proof that certificates are issued, replaced, and revoked on time. Integrations with ITSM, vaults, and access governance tools matter because they connect state changes to evidence. Without that chain, teams may be able to renew certificates but not prove control over them.

Practical implication: build event-level logs and reporting that tie certificate state changes to specific owners and systems.


Threat narrative

Attacker objective: The objective is not always an external attacker in this pattern, but the resulting condition is the same: exploit stale trust to disrupt services or widen exposure before the organisation can respond.

  1. Entry occurs when a certificate expires or a renewal window is missed, causing service disruption or forcing fallback trust behaviour.
  2. Escalation follows when teams rely on delayed manual processes, leaving stale certificate states and revoked credentials active longer than intended.
  3. Impact is outage, failed authentication, compliance exposure, and avoidable operational risk across VPNs, websites, and internal services.

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 validity is a lifecycle stress test for machine identity governance: The shortening certificate window does not create a new category of identity, but it exposes whether certificate management has actually been operationalised as lifecycle control. Manual renewal models assume enough time for humans to notice, validate, approve, and execute replacement. That assumption becomes false as renewal cadence accelerates, which is why certificate governance must be treated as a machine identity discipline, not a periodic admin task.

Certificate expiry is a standing privilege problem in disguise: A certificate that outlives its intended trust window behaves like a privileged credential that was never revoked on schedule. That is the same governance failure pattern seen in over-retained service accounts, only applied to TLS trust. The practical implication is that ownership, revocation, and replacement logic must be tied to the identity lifecycle itself, not left to local infrastructure teams.

Automated certificate lifecycle control is now the baseline, not the optimisation: Once certificate validity compresses to 100 days and then 47 days, the operational question shifts from whether to automate to what will break if automation is absent. API-driven issuance, renewal, revocation, and reporting are no longer efficiency upgrades. They are the only way to keep certificate state aligned with actual trust relationships.

Post-quantum readiness and cryptographic agility depend on the same control foundation: Shorter lifetimes are part of a wider shift toward more agile trust infrastructure. Organisations that still manage certificates manually will struggle to adapt when algorithm changes, certificate policy changes, and lifecycle windows all move together. Practitioners should read this as a signal that certificate governance, not just cipher selection, is becoming the limiting factor.

From our research:

  • 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which is why certificate inventories and ownership mapping often fail before renewal does.
  • That visibility gap connects directly to Ultimate Guide to NHIs , 2025 Outlook and Predictions, where lifecycle pressure and future identity sprawl are treated as a governance problem, not a tooling detail.

What this signals

47-day certificate lifetimes will expose which IAM programmes still treat machine identity as a back-office problem. The organisations that survive this shift will be the ones that can tie certificate inventory, ownership, and renewal to a governed lifecycle, not a manual checklist. The control question is no longer whether certificates can be renewed, but whether the identity programme can prove continuous trust state.

Identity lifecycle discipline is now the bridge between human IAM and NHI governance. Certificate automation, secrets rotation, and workload identity management are converging on the same operational need: state must change faster than humans can process tickets. For teams maturing their programme, that means aligning renewal workflows with policy, audit evidence, and service dependency mapping rather than leaving them inside platform silos.


For practitioners

  • Automate certificate discovery and ownership mapping Build a current inventory of all TLS certificates, their issuing authorities, expiry dates, business owners, and consuming services. If the certificate cannot be mapped to an owner and renewal path, it is already a governance risk.
  • Replace ticket-based renewal with API-driven lifecycle workflows Use automated issuance, renewal, replacement, and revocation workflows for high-volume certificates. Keep human approval only for exception handling, not for every routine renewal event.
  • Prioritise high-risk certificates for immediate migration Start with internet-facing services, VPNs, internal platforms with business-critical uptime requirements, and certificates that already fail compliance or ownership checks. These are the places where an expiry event creates the greatest operational blast radius.
  • Tie certificate state changes to audit evidence Log renewal, revocation, replacement, and exception handling in a way that can be traced back to a named owner and system. Without evidence at the event level, the organisation cannot prove control over the certificate lifecycle.

Key takeaways

  • Shorter TLS certificate lifetimes turn certificate governance into a machine identity lifecycle problem, not a periodic maintenance task.
  • Manual renewal, revocation, and ownership models will not scale to 100-day and 47-day validity windows without creating outage and audit risk.
  • Automated discovery, lifecycle orchestration, and evidence-linked reporting are now the baseline controls for certificate trust.

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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Short-lived certificates are a lifecycle and rotation problem for non-human identities.
NIST CSF 2.0PR.AC-1Certificate ownership and access control align with managed identity trust state.
NIST SP 800-53 Rev 5IA-5Authenticator management covers certificate issuance, renewal, and replacement controls.
NIST Zero Trust (SP 800-207)Zero Trust depends on continuously verified machine trust, which short-lived certs support.
CIS Controls v8CIS-5 , Account ManagementCertificate owners and service identities need managed lifecycle controls.

Automate certificate discovery, renewal, and revocation as part of NHI lifecycle governance.


Key terms

  • Certificate Lifecycle Management: Certificate lifecycle management is the discipline of discovering, issuing, renewing, replacing, and revoking certificates before trust breaks. In machine identity programmes, it is the control layer that keeps cryptographic credentials aligned with service ownership, expiry, and compliance evidence.
  • Machine Identity: Machine identity is the identity assigned to a non-human system such as a service, workload, or device. For TLS certificates, it represents the trust binding that allows a system to authenticate itself without a human user in the loop.
  • Cryptographic Agility: Cryptographic agility is the ability to change algorithms, certificate policies, or trust settings without redesigning the whole environment. It matters because shorter certificate lifetimes only help if the organisation can also adapt when policy or cryptographic requirements change.

What's in the full article

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

  • The stepwise certificate-validity timeline and the operational milestones tied to each reduction.
  • The eBook's practical planning guidance for certificate inventory review, risk classification, and automation prioritisation.
  • The integration examples for ServiceNow, Azure Key Vault, and Intune that show how lifecycle automation can be wired into existing workflows.
  • The post's cost and workload framing around manual certificate management across cloud and endpoint platforms.

👉 GlobalSign's full article covers the lifecycle automation and planning detail behind the 47-day change.

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 building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org