TL;DR: Only 7 of 20 credential configurations across 19 major platforms expire by default, 5 are documented to never expire, and 8 have no documented default expiration at all, according to Identra.ai. Default lifetime is still a governance control point, not a convenience setting, because credential persistence shapes blast radius and accountability.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Identra.ai's research: A documentation audit across 19 platforms found that most credential types still default to permanence, silence, or administrator-dependent expiry rather than enforced lifetime.
Why it matters: IAM, PAM, and NHI teams need to treat credential lifetime as a first-class governance control because non-expiring secrets and tokens expand standing access, weaken accountability, and lengthen incident blast radius.
Context
A credential without an enforced lifetime is a governance decision, not a neutral default. In non-human identity programmes, the real issue is not whether a token can be rotated eventually, but whether the platform forces expiry, exposes an admin control, or leaves lifetime entirely to manual discipline.
Identra.ai reviewed the official documentation for 20 credential configurations across 19 major platforms in developer tools, cloud, SaaS, and data services. The central finding is that credential persistence still dominates platform design, which means identity teams cannot assume modern platforms have solved default expiry for them.
The article is especially relevant for NHI governance because many of the credentials in scope are machine-facing tokens, keys, and secrets rather than human login factors. That makes expiry, revocation, and admin enforceability part of the identity lifecycle, not just a secrets hygiene task.
Key questions
Q: What breaks when a platform still relies on default credentials?
A: Default credentials destroy the trust boundary before any deeper control can help. Attackers can reach administrative functions without needing phishing, malware, or a known exploit. Once that happens, MFA, logging, and monitoring become damage-limitation controls rather than preventive ones. The practical answer is to eliminate default access paths entirely before a system reaches production.
Q: Why do forever keys increase IAM and NHI risk?
A: Because they outlive the assumption that access will be periodically re-justified. A forever key can remain valid after the original project, owner, or integration has changed, which makes dormant access easier to forget and harder to govern. The risk is not only compromise, but also accountability drift.
Q: What do security teams get wrong about token expiration in JWT authentication?
A: Teams often assume that short expiration alone solves token risk. In reality, expiry only limits the time window, and a compromised token is still usable until it expires unless revocation exists. Effective control needs both short-lived tokens and an explicit way to invalidate them when access changes or compromise is suspected.
Q: Should organisations prioritise short-lived credentials over legacy tokens?
A: Yes, when the platform supports both. Short-lived credentials reduce the duration of misuse and force periodic re-validation, while legacy long-lived tokens tend to persist until someone notices them. The right sequencing is to shrink standing access first, then tighten review and revocation around whatever remains.
Technical breakdown
Why default expiry is a control, not a convenience
Default expiry determines whether a newly created credential carries a built-in review point or becomes a standing access path. In identity terms, expiry forces re-justification of access, while non-expiring credentials push governance into manual inventory, rotation discipline, and revocation hygiene. That is why a platform that omits a default lifetime is not neutral. It is effectively delegating lifecycle control to the operator, which breaks down quickly at scale across service accounts, API keys, refresh tokens, and other non-human identities.
Practical implication: classify credential lifetime as an access governance requirement and not just a secrets-management setting.
The difference between never expires and no expiration documented
Never expires means the vendor documentation explicitly states the credential stays valid until revoked or rotated. No expiration documented is different: the documentation does not establish a default lifetime, so a security team cannot infer whether the platform expires credentials automatically or simply fails to document the behavior. That distinction matters in assurance work, because audit evidence depends on stated lifecycle behavior, not assumptions. For NHI governance, both states require scrutiny, but only one is a confirmed forever key.
Practical implication: separate confirmed non-expiring credentials from undocumented lifetimes in your inventory and risk register.
Why admin-enforced lifetime changes the governance model
A platform with a documented maximum lifetime gives identity teams a policy lever, even if the default still allows long-lived access. Without that lever, lifecycle management depends on local process quality, which is fragile for distributed engineering teams and third-party integrations. The control question is therefore not only what the vendor defaults to, but whether an organisation can centrally enforce a shorter maximum. In NHI programmes, that is the difference between policy-backed governance and credential-by-credential exceptions.
Practical implication: prefer platforms where lifetime policy can be enforced centrally and use exceptions only where no control exists.
NHI Mgmt Group analysis
Credential lifetime is an identity governance control, not a platform preference: The audit shows that default expiry is still inconsistent across major credential types, which means lifecycle governance remains uneven by design. That matters because a credential that persists without review becomes standing authority, and standing authority is the condition identity programmes are supposed to eliminate. Practitioners should treat expiry policy as part of identity architecture, not as a usability option.
Forever keys create trust debt across the full identity lifecycle: When a platform documents no expiration or a never-expire default, it shifts the burden from issuance to perpetual oversight. That creates trust debt because the organisation must keep proving a credential is still needed after the platform has stopped asking. The practical consequence is that inventory, ownership, and revocation discipline become the only backstop for machine access.
Legacy credential types are where governance assumptions have aged out: The pattern in the article is that newer or redesigned credential types are more likely to expire by default, while older designs still behave like durable access artifacts. That tells us the problem is not technical impossibility, but inherited lifecycle assumptions. Identity teams should read this as a signal that legacy token classes are still carrying yesterday's control model into today's attack surface.
Default lifetime should be evaluated as blast-radius policy: A short-lived credential does more than limit exposure time. It also narrows the window in which a forgotten token can be misused without detection or accountability. In practice, expiry policy is one of the few controls that directly reduces the duration of undetected standing access, which is why it belongs in NHI governance reviews alongside privilege scope and revocation coverage.
What this signals
Credential lifetime is now a control-plane question: Identity teams should stop treating token expiry as an implementation detail and start treating it as a policy boundary that separates governed access from inherited access. Where platforms do not expose a maximum lifetime, the organisation has to compensate with inventory, ownership, and revocation discipline.
Legacy token classes are the highest-priority cleanup area: The article’s pattern is clear enough to guide programme focus. Older credential types are more likely to lack default expiry or admin enforceability, so they should be the first candidates for replacement, restriction, or compensation through tighter lifecycle controls.
For practitioners
- Inventory every credential class with no stated default expiry Separate confirmed forever keys from credentials whose documentation is silent on lifetime, then assign an owner, business purpose, and review cadence to each one.
- Enforce maximum lifetime wherever the platform allows it Use org-level or authentication-policy controls to cap credential duration, and remove or restrict token types that cannot be bounded centrally.
- Prefer short-lived credential types over legacy long-lived ones Choose the newer credential format when a vendor offers both, because the newer type is more likely to carry an enforced expiry and a clearer lifecycle boundary.
- Build revocation into operational ownership Make revocation and rotation part of the service or integration owner’s normal responsibility so non-expiring credentials do not become orphaned standing access.
Key takeaways
- The core problem is not just long-lived credentials, but platform designs that make lifetime optional, undocumented, or fully manual.
- The audit shows a clear split between newer credential types with enforced expiry and older token classes that still behave like perpetual access.
- IAM and NHI teams should focus on enforceable lifetime, ownership, and revocation coverage because that is what turns credential hygiene into governance.
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 and MITRE ATT&CK address 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 | The article centers on credentials that never expire or lack a stated expiration default. |
| NHI-01 — Improper Offboarding | Forever keys remain valid after owners, projects, or integrations should have been retired. | |
| Recommendation — Set maximum lifetimes for long-lived secrets and remove any credential class that cannot be bounded. Tie credential retirement to offboarding and revoke access when ownership changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 covers lifecycle control of authenticators, including expiration and revocation. |
| Recommendation — Apply authenticator management to enforce expiry, rotation, and revocation of machine credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Credential lifetime is part of governing access permissions and their duration. |
| Recommendation — Govern credential permissions so access expires on a defined schedule instead of persisting indefinitely. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Long-lived credentials extend the window for credential abuse and movement after compromise. |
| Recommendation — Map non-expiring credentials to credential access and lateral movement risk in your threat model. | ||
Key terms
- Credential Lifetime: Credential lifetime is the period during which a token, key, secret, or refresh credential remains valid. In identity governance, lifetime determines how long access can exist without re-approval, making it a control boundary for revocation, review, and accountability.
- Forever Key: A forever key is a credential that remains valid indefinitely unless someone manually rotates or revokes it. The term applies to non-human identities such as API keys, tokens, and service credentials where the absence of enforced expiry turns access duration into a human discipline problem.
- Admin-Enforced Expiry: Admin-enforced expiry is a platform control that lets an organisation cap the maximum lifetime of a credential regardless of what a user selects at creation. It matters because lifecycle governance is stronger when the platform can override long-lived defaults and impose a policy-backed boundary.
- Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
Deepen your knowledge
NHI governance, secrets management, and workload 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 programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org