TL;DR: Let’s Encrypt’s move to 45-day server certificates, the shutdown of its tlsclient profile, and the new Generation Y chain together force enterprises to automate renewal, inventory by EKU, and verify chains at every rotation, according to AppViewX research. Certificate operations now behave like infrastructure, not paperwork.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's blog post: Let’s Encrypt’s shift to 45-day TLS server certificates, tlsclient shutdown, and Generation Y chaining makes renewal automation and chain verification mandatory.
Why it matters: Identity and platform teams need certificate inventory, renewal, and trust-chain checks to survive shorter validity periods and profile retirement without service disruption.
Context
TLS certificate operations are moving from periodic maintenance to continuous governance. Shorter validity periods, profile retirement, and intermediate chain changes mean trust can no longer be assumed from a one-time deployment check.
The practical issue is not only expiry. Ownership, renewal timing, EKU scope, and chain validation now all need to be tracked as part of the certificate lifecycle, especially where certificates support internal authentication or client access.
This is already visible in environments that depend on machine identity certificate lifecycle patterns, where renewal and trust decisions have to be observable rather than improvised.
Key questions
Q: How do 45-day TLS certificates change renewal operations?
A: 45-day TLS certificates force renewal to become continuous rather than calendar-based, because the certificate expires before manual ticket queues and quarterly maintenance windows can cope. Organisations usually pair short lifetimes with event-driven automation, inventory reconciliation, and alerting on issuance, renewal, and failed deployment so certificates are replaced before service interruption.
Q: Why do client authentication certificates need separate inventory?
A: Client authentication certificates need separate inventory because they are issued and trusted for a different purpose from server certificates, typically via the clientAuth EKU. That separation lets teams track where each certificate is installed, which service or device owns it, and whether its private key, rotation date, and intended use still match the workload.
Q: How can renewal logging prevent certificate chain failures?
A: Renewal logging prevents certificate chain failures by showing which certificate was renewed, which intermediate or root certificate was deployed, and whether every server and client received the same trust material. If logs reveal trust-store drift, missing intermediates, or partial rollout, operators can fix the chain before handshake failures spread across services.
Q: What is the difference between mTLS and client authentication certificates?
A: mTLS is the handshake pattern where both sides authenticate with certificates, while client authentication certificates are the specific certificates presented by the connecting party. In practice, mTLS uses a server certificate plus a client certificate, and the client certificate must carry the correct clientAuth EKU so the peer accepts it for authentication.
Technical breakdown
Why 45-day certificates break calendar-based renewal
Validity shrinkage changes the operating model for TLS. A certificate that expires in 45 days doubles the renewal pressure compared with a 90-day certificate, which means fixed quarterly reviews, ticket-driven renewals, and hand-run checklists will miss the window. The real mechanism is not expiry itself but the loss of slack. If renewal still depends on a person noticing a date, the process fails as cadence compresses. Automation has to be triggered by certificate state and not by calendar habit.
Practical implication: Replace date-based renewal routines with event-driven automation that renews before the certificate enters a narrow expiry window.
What chain changes mean for trust validation
A new intermediate chain can validate cleanly in modern browsers and operating systems while still breaking older or pinned trust stores. That is why chain verification has to be treated as a lifecycle signal, not a deployment note. When roots rotate or intermediates are reissued, the certificate may still be valid while the trust path is not. Renewal logging should therefore capture the actual chain produced, not just the certificate subject and expiry date. Read Certificate trust stores and root CA management.
Practical implication: Log the full chain at renewal time so trust-store drift becomes visible before it causes an outage.
Why EKU scope now drives certificate ownership
Extended Key Usage is not an administrative detail. It defines what the certificate can authenticate, and that makes EKU inventory central when client-auth certificates must be migrated off a retiring profile. Certificates used for mTLS, application access, or protocol-specific client authentication often sit outside central PKI ownership, which means the application team is usually the only reliable source of truth. Discovery by EKU is the mechanism that exposes these hidden dependencies. See the JWT Client Authentication Guide.
Practical implication: Inventory certificates by EKU, not just hostname or subject, so client-auth uses can be found before the migration deadline.
Threat narrative
Attacker objective: The practical objective is not compromise but service disruption through expired certificates, broken trust chains, or failed client authentication.
- entry: the operational failure begins when renewal or trust validation depends on manual review rather than machine-triggered lifecycle checks.
- escalation: shortened validity and changed intermediates amplify the chance that an outdated runbook misses a renewal, chain, or EKU dependency.
- impact: services depending on client-auth certificates or old trust stores fail when the next rotation or profile cutoff arrives.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
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
Certificate lifecycle has become an infrastructure control, not a renewal task. Shorter validity periods turn certificate management into a continuous operating discipline because the old slack disappears. Quarterly review cycles, manual approvals, and spreadsheet tracking no longer align with the failure window. The implication is that certificate governance has to be treated like production infrastructure, with state, ownership, and renewal behaviour visible at all times.
Chain verification must move into the renewal event. Trust-store drift and intermediate reissuance mean that a certificate can be technically valid while still breaking in a real environment. The assumption that chain validation happens once at deployment is no longer defensible. The implication is that renewal logs now need to prove the chain that was actually issued and accepted.
EKU is now a governance boundary, not a metadata field. Certificates carrying client-auth usage are often hidden in application-owned estates, which makes them invisible to generic inventory processes. That is a lifecycle governance problem, not a tooling problem. The implication is that certificate ownership has to be resolved from function and usage, not from central registry convenience.
Vendor-neutral CA agility is becoming the default requirement. Industry-wide validity compression means the control objective is no longer to adapt to one CA’s roadmap but to absorb repeated CA changes without redesigning the workflow each time. This is where mTLS, trust stores, and renewal orchestration intersect. The implication is that certificate programmes now need portability by design, not exception handling by project.
5.7% visibility into service accounts is a warning sign for certificate estates too. The same visibility gap that leaves service accounts unmanaged also leaves certificates scattered across app teams, integration owners, and legacy trust stores. When inventory is incomplete, deadlines become surprises. The implication is that certificate governance should be measured by discoverability, not just by successful renewals.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Shorter certificate lifetimes force governance to move from review cycles to issuance cycles. The moment renewal cadence compresses, the meaningful control is no longer who approved a certificate months ago, but whether the organisation can issue, validate, and retire it without manual intervention. That shift also exposes which teams still depend on static runbooks.
Certificate lifecycle hygiene now overlaps with workload identity governance. When certificates support application access, renewal, ownership, and chain validation become identity controls rather than infrastructure chores. Programmes that already track root CA management will be better positioned to absorb repeated CA changes without visible service risk.
For practitioners
- Inventory certificates by EKU and owner Build discovery around certificate purpose, not just subject names or hostnames, so client-auth and mTLS uses are visible before shutdown dates arrive.
- Log the full certificate chain at renewal time Capture the issued chain, intermediate path, and validation result in the renewal event record so trust-store drift can be investigated later.
- Replace manual renewal thresholds with event-driven automation Trigger renewal from certificate state and validity thresholds rather than quarterly calendars, tickets, or runbook reminders.
- Map every client-auth dependency to an application owner Require each internal integration using TLS Client Authentication EKU to name the team that can prove whether the certificate is still required.
Key takeaways
- Shorter TLS validity periods turn certificate management into a continuous control problem rather than a periodic maintenance task.
- The most fragile point is not just expiry, but incomplete visibility into which certificates use client authentication or depend on older trust chains.
- Practical resilience comes from automated renewal, EKU-based inventory, and logging the chain that every renewal actually produced.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate trust stores and root CA management · mTLS Guide · JWT Client Authentication 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 and NIST CSF 2.0 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 | Shorter certificate validity makes long-lived certificate handling the central operational issue. |
| NHI-01 — Improper Offboarding | The tlsclient cutoff forces retirement of certificates and profiles that no longer belong in the estate. | |
| NHI-03 — Vulnerable Third-Party NHI | Public CA and root-chain changes can break externally managed certificate dependencies. | |
| Recommendation — Automate certificate renewal before validity windows collapse and manual handling becomes unreliable. Track and retire expired certificate profiles and dependencies before they outlive their approved use. Validate third-party certificate chains and migration dependencies before trust-store updates reach production. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate renewal, rotation, and revocation are authenticator lifecycle controls. |
| Recommendation — Apply IA-5 to enforce renewal, revocation, and rotation handling for certificate authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate EKU scope determines what access the identity can authorize. |
| Recommendation — Treat certificate EKU scope as an authorization boundary and verify it during lifecycle changes. | ||
Key terms
- Extended Key Usage: Extended Key Usage is the certificate extension that limits what a certificate can be trusted to do. In practice, it separates server authentication, client authentication, code signing, and other trust roles so one certificate cannot safely be reused everywhere without policy consequences.
- Client Authentication EKU: Client Authentication EKU is a certificate usage flag that says a certificate may be used to prove the identity of a client during TLS authentication. It appears in the extended key usage field, and relying parties check it before accepting the certificate for mutual TLS or other client-side authentication.
- 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.
- Mutual Tls: Mutual TLS is a transport security method where both client and server present certificates and authenticate each other. In implant frameworks, it helps prevent impersonation, supports encrypted sessions, and ties each deployment to its own trust material rather than shared credentials.
Deepen your knowledge
NHI governance, identity lifecycle management, and machine identity security 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 or certificate governance programme, it is worth exploring.
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