TL;DR: TLS certificate lifetimes are shrinking to 200 days in 2026, 100 days in 2027 and 47 days by 2029, according to AET Europe, which means manual renewal processes will fail under the new cadence. Certificate lifecycle management is now a control requirement, not an administrative convenience.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AET Europe's blog post: TLS certificate lifetimes are shortening fast, making certificate lifecycle management an operational control instead of a back-office task.
Why it matters: IAM, platform and cloud teams need lifecycle visibility because expired certificates now create service failure risk faster than manual processes can absorb.
By the numbers:
- As of March 15, 2026, newly issued public TLS certificates may be valid for a maximum of 200 days.
- This will drop further to 100 days in 2027, and ultimately to a mere 47 days by 2029.
Context
Certificate lifecycle management is the discipline that tracks where certificates live, who owns them, when they expire and how they are renewed. Without that visibility, trust assets drift into spreadsheets and memory, which does not scale across cloud workloads, internal services and third-party integrations.
The practical problem is not only expiration, but the speed at which trust now decays. As certificate lifetimes shorten, teams must treat renewal, validation and deployment as governed processes, not ad hoc maintenance.
Key questions
Q: How do certificate lifecycle controls reduce outage risk?
A: Certificate lifecycle controls reduce outage risk by ensuring certificates are discovered, owned, renewed and redeployed before they expire. The key is to remove dependence on manual tracking and instead enforce policy-driven automation across the certificate estate. That turns expiration from a surprise event into a governed process with clear accountability.
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: How does automated certificate renewal work in distributed environments?
A: Automated certificate renewal uses a control plane or agent to request, issue and replace certificates before expiry, then reloads services or rotates trust bundles without manual intervention. In distributed environments, it usually relies on ACME, SPIFFE or an internal PKI, with health checks and rollback to prevent outages if renewal fails or a certificate chain changes.
Q: What is the difference between certificate expiry and certificate compromise?
A: Certificate expiry is a control lapse that usually disrupts availability, while compromise means the private key or certificate trust has been exposed and can be abused for impersonation or interception. Both are identity problems, but compromise carries a much higher security consequence because trust can be used by an attacker before anyone notices.
Technical breakdown
Why shortening certificate lifetimes change operational risk
TLS certificates are time-bound trust objects. When their validity window shrinks, the renewal burden increases non-linearly because every delay compounds across issuance, distribution, deployment and validation. The security rationale is clear: shorter lifetimes reduce the value of stolen private keys and limit the window for mis-issuance. The operational consequence is equally clear: any process that still depends on manual tracking or periodic clean-up will fail under the new cadence. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Move certificate renewal from calendar-based administration to automated lifecycle control.
How certificate lifecycle management governs trust at scale
CLM is not a vault or a scanner. It is the control layer that discovers certificates, maps ownership, monitors expiry, coordinates renewal and verifies deployment. That matters because certificates are scattered across load balancers, APIs, customer portals, cloud workloads and internal applications. Without inventory and ownership, no team can prove which certificates are active, which are stale and which renewal path will break first.
Practical implication: Build a complete certificate inventory with ownership and expiry data before shortening lifetimes expose blind spots.
Why certificate failure is an availability event, not a breach
An expired certificate does not usually mean compromise. It means the trust system has stopped accepting a service, API or application because the certificate is no longer valid. Browsers warn, connections fail and dependent systems break abruptly. That makes certificate expiry an availability and resilience issue first, even though the underlying trust mechanism is also an identity control for machines and services.
Practical implication: Treat certificate expiry as a resilience control failure and test renewal paths under production-like timing.
Threat narrative
Attacker objective: There is no attacker objective in the primary failure mode; the operational outcome is the loss of trusted service availability when certificates expire.
- Entry occurs when an organisation relies on unmanaged certificates across websites, APIs and internal services instead of a governed lifecycle process.
- Credential access is not the main issue here; the failure mode is expired trust, where systems stop accepting valid-looking certificates once the lifetime ends.
- Impact appears as outages, failed API calls, browser warnings and service interruptions that interrupt business operations without any external attack being present.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shorter certificate lifetimes create governance debt: the real problem is no longer whether certificates can be issued, but whether organisations can prove they will be renewed, redeployed and validated on time. As the renewal window shrinks, ownership ambiguity becomes a control failure, not an administrative nuisance. Teams that still treat certificates as static assets will experience avoidable trust outages.
Certificate lifecycle management has become infrastructure governance: CLM now sits across identity, platform and resilience work because certificates authenticate machines, services and APIs. That makes certificate inventories and renewal automation part of access governance for non-human systems, not just a technical cleanup exercise. Certificate lifecycle management is where trust, availability and ownership meet.
Manual renewal is the new single point of failure: when validity windows fall from years to months and then weeks, spreadsheet-driven renewal cannot absorb the operational tempo. The consequence is not gradual drift but abrupt service failure when expired certificates reach production. Practitioners should measure how much of their certificate estate still depends on human scheduling rather than policy enforcement.
The industry is moving from certificate management to trust operations: the governance question is shifting from how many certificates exist to whether trust can be maintained continuously across distributed systems. That changes the role of platform, IAM and security teams, because machine trust now needs the same disciplined lifecycle thinking long applied to human access. Practitioners should align certificate handling with identity governance and resilience planning.
Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate lifecycle debt is now an identity governance issue: as certificates become shorter-lived, the control question shifts from storage to continuous renewal, ownership and revocation. Machine identity programmes that cannot reconcile those duties will accumulate avoidable trust failures across services and APIs.
Trust operations will replace calendar-based maintenance: teams should expect certificate handling to merge with platform reliability work, because a missed renewal now looks like a production incident. The practical response is to govern certificates as active identity assets rather than passive configuration items.
For practitioners
- Automate certificate discovery and ownership mapping Build a continuously updated inventory of certificates across public-facing services, internal applications, cloud workloads and integrations so each certificate has an owner, expiry date and renewal path.
- Replace manual renewal with policy-driven automation Use automated issuance, renewal and deployment workflows so shortened lifetimes do not depend on calendars, spreadsheets or individual memory.
- Test renewal failure as a resilience scenario Run controlled failure exercises that simulate missed renewals, delayed redeployment and expired trust so teams can see which services break first.
- Classify certificates as machine identity assets Govern TLS and code-signing certificates as part of your machine identity estate, with lifecycle controls that cover issuance, rotation, revocation and retirement.
Key takeaways
- Shorter certificate lifetimes turn renewal timing into an operational risk that manual processes struggle to absorb.
- The main evidence is the phased move to 200 days in 2026, 100 days in 2027 and 47 days by 2029.
- Automated discovery, renewal and deployment are now the practical controls that keep trust from expiring with the certificate.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Guide to SPIFFE and SPIRE · Code Signing Security Guide · Breach and Attack Simulation (BAS) Guide
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix 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 | Shortening certificate lifetimes directly changes how long machine trust credentials can remain valid. |
| NHI-02 — Secret Leakage | Certificate material, especially private keys, becomes harder to protect when renewal and redeployment are manual. | |
| Recommendation — Shorten certificate validity windows and automate renewal before trust expires. Inventory certificate material and revoke any exposed private key immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates function as authenticators for services and APIs, so their lifecycle needs governed management. |
| Recommendation — Apply IA-5 to automate issuance, rotation and retirement of certificate authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificates grant machine access and trust, which must be controlled as part of authorisation governance. |
| Recommendation — Map certificate-based access to PR.AA-05 and verify entitlement scope at each renewal. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud certificates underpin workload and service trust across distributed environments. |
| Recommendation — Use IAM governance to track certificate ownership, renewal and revocation across cloud workloads. | ||
Key terms
- TLS Certificate: A TLS certificate is a machine credential used to prove a server or service is authentic during encrypted communication. In practice, it is a non-human identity artifact with a fixed expiration date, ownership requirement, and renewal workflow that must be governed like any other sensitive credential.
- 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.
- Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
- X.509 Standard: The X.509 standard defines how digital certificates prove identity across networks. It specifies certificate fields, public key binding, issuing authorities, validity periods, and revocation methods, enabling trust for TLS, device authentication, and workload identities in IAM, NHI governance, and secure automated systems.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers machine identity security, secrets management and NHI governance. It is relevant for practitioners who need to connect identity controls to broader platform and resilience work.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org