By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: GlobalSignPublished November 5, 2025

TL;DR: Certificate lifetimes are shortening from 398 days today to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029, according to GlobalSign. Manual renewal processes cannot keep pace, so certificate governance is shifting from periodic administration to continuous automation and crypto-agility.


At a glance

What this is: This is an analysis of how shrinking SSL/TLS certificate lifetimes and post-quantum pressures are reshaping certificate management and trust operations.

Why it matters: It matters because certificate expiry is now an availability, compliance, and identity assurance problem that affects IAM-adjacent controls for workloads, apps, APIs, and connected services.

By the numbers:

👉 Read GlobalSign's analysis of shrinking certificate lifetimes and PKI automation


Context

SSL/TLS certificates are a trust control, but they behave like an identity lifecycle problem once lifetimes collapse from years to weeks. The article argues that manual renewal, spreadsheet tracking, and email reminders no longer scale, especially when certificates authenticate websites, APIs, IoT devices, and internal services.

For IAM and NHI practitioners, the useful lens is governance, not just cryptography. Certificates are machine identities in practice, and shorter validity periods push organisations toward automated issuance, continuous inventory, and revocation-aware lifecycle management rather than ad hoc administration.


Key questions

Q: How should security teams respond to shorter certificate lifespans?

A: They should treat shorter lifespans as an automation mandate, not as a reason to add more manual review. The immediate priority is to inventory all machine identities, remove ticket-driven renewals, and enforce policy-based issuance and revocation. That approach reduces outages and creates a foundation for broader lifecycle governance.

Q: Why do short-lived certificates matter for machine identity governance?

A: Short-lived certificates matter because they are time-bound non-human credentials that define how systems prove identity to each other. When the validity period shrinks, certificate lifecycle becomes a continuous governance issue rather than a periodic maintenance task. That forces identity teams to manage issuance, renewal, and revocation with the same discipline they apply to other privileged credentials.

Q: What do teams get wrong about certificate automation?

A: They often treat it as a convenience upgrade instead of a resilience control. Automation is valuable because it shortens the gap between discovery and action, which is where outages and compliance failures begin. If the programme does not include policy, ownership, and alerting, the organisation still depends on manual intervention at the worst possible moment.

Q: Who is accountable when an expired certificate causes a service outage?

A: Accountability sits with the team that owns certificate lifecycle governance, not only with infrastructure operations. The failure usually reflects missing ownership, weak inventory, and lack of automated renewal controls, which makes the issue a programme problem as much as a technical one.


Technical breakdown

Why shorter certificate lifetimes change the operating model

Certificate lifetime reduction changes the security model because the control objective shifts from rare renewal events to continuous lifecycle execution. A certificate expiring every few weeks cannot be managed safely with manual reminders or ticket-based renewals. The real issue is not only expiry, but the volume of dependent services, the validation burden, and the need to prove every certificate is still trusted, mapped, and monitored. That makes certificate management closer to identity governance than to routine system maintenance.

Practical implication: build continuous certificate inventory and renewal workflows before validity windows shrink further.

How ACME supports automation, but not full governance

ACME automates certificate issuance and renewal by allowing systems to request and refresh certificates programmatically. That reduces human latency, but it does not by itself solve ownership, dependency mapping, reporting, or exception handling. Organisations still need a lifecycle layer that knows which services depend on which certificates, where renewal failures would cause outage, and how to prove compliance. In other words, automation is necessary, but governance decides whether that automation is safe at enterprise scale.

Practical implication: use ACME as an execution protocol inside a broader lifecycle and reporting control plane.

Why post-quantum crypto makes crypto-agility a governance requirement

Post-quantum cryptography matters because current algorithms may eventually need replacement, and organisations will not be able to reissue everything on short notice if their certificate estate is opaque. Crypto-agility means systems can adopt new algorithms, trust chains, and policy changes without redesigning every dependency. TLS 1.3 is relevant because it removes older handshake patterns and establishes a cleaner baseline for future migration. The operational lesson is that cryptographic transition planning belongs in governance now, not in a future emergency.

Practical implication: inventory algorithm dependencies and test migration paths before post-quantum transition becomes urgent.


NHI Mgmt Group analysis

Shorter certificate lifetimes create a machine identity governance problem, not just a renewal problem. The article is right to frame expiry as a trust issue, because every certificate is a machine identity with an owner, dependency chain, and failure mode. Once validity drops to weeks, the control gap is no longer technical awareness but lifecycle governance. Practitioners should treat certificates as governed identities with inventory, ownership, and validation requirements.

Certificate expiry fatigue is the operational risk that emerges when renewal becomes continuous work. Manual tracking breaks down as scale rises, especially across cloud platforms, websites, APIs, and IoT. That creates predictable outage risk and encourages shadow handling of certificates outside formal controls. Teams should expect more process debt unless renewal is automated and exception handling is explicit.

Crypto-agility is becoming a board-level resilience requirement for identity infrastructure. The move toward shorter lifetimes aligns with the broader need to swap algorithms, chains, and issuing patterns without disrupting service. That matters for organisations that rely on certificate-bound trust for authentication and encryption across business-critical systems. Practitioners should align certificate policy with future migration readiness, not just present-day compliance.

ACME solves the issuance step, but identity teams still need lifecycle ownership. The article correctly notes that protocol automation is only one layer. Without service mapping, dependency discovery, and revocation oversight, automation can simply accelerate the wrong process. Teams should define who owns certificate identity, who validates trust changes, and who answers when a renewal fails.

Certificate management is converging with broader NHI governance. Certificates, API keys, tokens, and service accounts are all non-human identities in operational terms, and they fail in similar ways when lifecycle control is weak. That intersection means IAM and PAM teams should stop treating certificates as an isolated PKI concern and fold them into NHI policy, inventory, and access governance.

What this signals

Certificate expiry management is converging with the same lifecycle pressures seen in secrets governance. When validity windows compress, organisations need continuous discovery, ownership, and remediation rather than periodic clean-up. The practical signal for identity programmes is clear: if the estate cannot be enumerated, it cannot be safely automated.

Machine identity inventory is becoming a resilience dependency for hybrid environments. Certificates underpin application access, API trust, and many internal service connections, so expiry risk now maps directly to availability risk. Teams should expect certificate governance to sit closer to IAM and NHI controls than to traditional PKI administration.

Crypto-agility should be treated as a transition capability, not a future research topic. Organisations that cannot swap algorithms, renew trust chains, and validate dependencies will struggle when post-quantum migration becomes operational rather than theoretical. That is why certificate lifecycle planning belongs in the same programme conversation as workload identity and secrets rotation.


For practitioners

  • Inventory every certificate and dependency chain Build a live register of certificates, expiry dates, issuing CAs, and the services that depend on each certificate. Include cloud-hosted workloads, internal APIs, customer portals, and IoT endpoints so renewal risk is visible before the next expiry window.
  • Automate renewal and reissue workflows Use ACME or equivalent automation to remove spreadsheet-driven renewal tasks from operational paths. Pair automation with exception routing for systems that cannot renew programmatically, and test failure handling before certificates reach end of life.
  • Assign named ownership for certificate lifecycle control Make one team accountable for issuance, renewal, validation, and revocation oversight across the estate. For shared platforms, record owner, consumer, and backup approver so no certificate is left in organisational gaps.
  • Prepare for algorithm migration now Catalogue where certificate chains, libraries, and appliances depend on current cryptographic algorithms so post-quantum changes do not become emergency projects. Run controlled tests for TLS 1.3 adoption and future algorithm swaps in non-production environments first.

Key takeaways

  • Shorter certificate lifetimes turn certificate management into a continuous identity and resilience problem.
  • Manual tracking no longer scales when renewal windows collapse from years to weeks and service outages become more likely.
  • Automation, ownership, and crypto-agility are now the controls that decide whether certificate trust remains operational.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-1Certificate trust and access provisioning sit within identity control and authentication.
NIST SP 800-53 Rev 5IA-5IA-5 directly aligns with authenticator management and certificate lifecycle control.
CIS Controls v8CIS-5 , Account ManagementCertificate ownership and lifecycle control mirror account lifecycle governance needs.
ISO/IEC 27001:2022A.8.24Cryptographic controls are directly relevant to certificate handling and future algorithm migration.
NIST Zero Trust (SP 800-207)Certificate trust supports continuous verification in zero trust architectures.

Review cryptographic control coverage and document migration readiness for algorithm changes.


Key terms

  • Certificate Lifecycle Management: The governance and operational process for issuing, renewing, validating, replacing, and revoking certificates across an environment. In practice, it treats certificates as managed trust assets with owners, expiry dates, dependencies, and controls, rather than as one-off technical tasks.
  • ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
  • Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, trust chains, and supporting systems without redesigning the entire environment. It is a resilience property that becomes essential when standards, threats, or compliance requirements shift faster than legacy infrastructure can adapt.
  • Machine Identity: A machine identity is a non-human identity used by software, services, devices, or workloads to authenticate and establish trust. Certificates, keys, and tokens can all function as machine identities, which means their lifecycle must be governed with the same discipline as human access.

What's in the full article

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

  • A practical explanation of why 47-day certificate lifetimes change renewal operations and staffing assumptions.
  • Discussion of the ACME protocol in the context of enterprise certificate automation and lifecycle management.
  • Examples of certificate failures that caused outages in major services and public sector portals.
  • The article's view of how post-quantum cryptography and TLS 1.3 shape future trust planning.

👉 GlobalSign's full article covers the certificate lifecycle, ACME automation, and post-quantum transition context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle control to the broader security and resilience work their programmes already depend on.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org