Forever keys still dominate across major credential platforms

At a glance

What this is: A documentation audit across 19 platforms found that default credential expiry is the exception, not the norm, and that many widely used keys and tokens still have no documented lifetime limit.

Why it matters: IAM, NHI, and PAM teams need to treat credential lifetime as a governance control because platform defaults still leave many long-lived secrets outside reliable lifecycle enforcement.

By the numbers:

• Of 20 credential configurations across 19 major platforms, only 7 expire by default.
• Only 9 of the 20 configurations, on 9 of the 19 platforms, come with a documented administrator control that can enforce a maximum credential lifetime.

👉 Read Identra.ai's documentation audit of credential expiry across major platforms

Context

Default expiration is one of the clearest signals of whether a platform expects credential lifecycle to be governed or merely remembered. In this audit, many of the most common developer, cloud, SaaS, and AI service credentials still default to long-lived or indefinite validity, which means the control burden shifts to the organisation from the start.

For IAM and NHI programmes, the practical issue is not just whether a token can be rotated. It is whether the platform offers a documented expiry default, whether administrators can enforce a maximum lifetime, and whether inventory and revocation processes can compensate when the platform does not. That is why lifetime policy belongs in the same conversation as access reviews, secret inventory, and offboarding.

When platforms leave expiry undefined or non-enforceable, the identity problem becomes persistent access debt. Teams cannot assume that a credential will age out on its own, so they need explicit governance around issuance, review, and revocation across both human-managed and machine-managed access.

Key questions

Q: What breaks when credentials do not expire by default?

A: When credentials do not expire by default, access persists beyond the original business need and becomes harder to govern through ordinary reviews. The main failure is lifecycle drift: nobody can rely on the platform to age out the secret, so revocation, ownership, and accountability become manual tasks that are often delayed or missed.

Q: Why do long-lived secrets increase identity risk in cloud and SaaS environments?

A: Long-lived secrets remain reusable until someone revokes them, which gives attackers a durable target. In cloud and SaaS environments, that means one leaked token or key can be replayed across systems, copied into automation, or reused after the original exposure has faded from view. Short-lived identity reduces that persistence.

Q: How do teams know whether a credential lifetime control is actually working?

A: A lifetime control is working when the platform enforces expiration without manual reminders, the org can verify the maximum lifetime in policy, and stale credentials disappear from inventory on schedule. If reviews keep finding old tokens that should have expired, the control exists only on paper.

Q: Who should be accountable for non-expiring credentials?

A: Accountability should sit with the system owner, identity team, and platform owner together, because non-expiring credentials are both a governance and an engineering problem. The owner must justify the exception, the identity team must track it, and the platform owner must ensure that revocation and lifecycle policy are actually enforceable.

Technical breakdown

Why default expiry matters for credential lifecycle

Default expiry is the platform’s first governance decision about a secret, key, or token. If the product does not set a lifetime automatically, the credential can survive long after the original use case has changed. That matters because expiry is not only about limiting exposure time. It also creates a recurring checkpoint where accountability can be re-established, usage can be revalidated, and stale access can be removed before it becomes invisible infrastructure.

Practical implication: treat non-expiring or undocumented-lifetime credentials as lifecycle exceptions that require compensating controls.

Admin-enforceable lifetime controls versus user discipline

A documented maximum lifetime is more useful than a recommended rotation habit because it moves enforcement from the individual to the platform. Without that lever, teams depend on user behaviour, which is uneven and often fails under pressure, especially in cloud and developer workflows where credentials are created quickly and forgotten quickly. The audit shows that only a subset of platforms provide a clear organisation-level control, and that gap is where governance breaks down.

Practical implication: prioritise platforms with enforceable lifetime policies and inventory the rest manually.

Why newer credential types usually expire and legacy ones do not

The pattern in the audit is consistent: newer or redesigned credential types tend to ship with expiry by default, while legacy types often do not. That is not accidental. Vendors typically add expiry after incident pressure, policy changes, or product redesign, which means the age of the credential model often predicts its risk profile. For NHI governance, legacy permanence should be read as a design choice, not a neutral omission.

Practical implication: prefer newer credential types where available, and plan migrations away from legacy perpetual credentials.

Threat narrative

Attacker objective: The attacker’s objective is to preserve durable access by exploiting credentials that remain valid long after issuance.

1. Entry occurs when an attacker obtains a long-lived token, key, or secret that never expires or has no documented lifetime boundary.
2. Escalation follows when that credential remains valid across systems, allowing reuse, persistence, and access expansion without re-authentication.
3. Impact occurs when the stolen credential outlives the original owner, enabling silent access, data theft, or supply-chain abuse until manual revocation.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Forever credentials are a lifecycle failure, not just a secrets problem. The audit shows that many platforms still treat lifetime as optional, undocumented, or impossible to enforce. That means the credential is being governed as a static artifact instead of a time-bound identity. The consequence is persistent access debt, where issuance is easy but accountability is delayed or absent.

Default expiry is the point at which platform design either supports governance or externalises it. When a platform ships a non-expiring credential or offers no documented maximum lifetime, the organisation inherits the burden of lifecycle control. That burden is not evenly distributed across humans, service accounts, and integrations. It lands hardest on IAM and NHI teams that must compensate for a product model that assumes trust will be remembered rather than renewed.

Legacy credential models are becoming the weakest link in modern identity programmes. Newer token types increasingly expire by default because recent incidents exposed the cost of permanence. That creates a split market where modern lifecycle assumptions coexist with older perpetual credentials inside the same environment. The result is uneven policy coverage that compliance teams often miss because the issue sits in documentation rather than runtime telemetry.

NHI governance should treat undocumented expiration as a control gap in its own right. A credential whose docs do not state a default lifetime is not equivalent to one that expires. The absence of a documented expiry default means reviewers cannot verify the lifecycle boundary from the vendor material alone, which weakens auditability and complicates policy enforcement. Practitioners should treat that uncertainty as part of the risk model, not a documentation footnote.

Credential lifetime is now a category signal for the identity market. Platforms that cannot explain or enforce expiry are effectively asking customers to build their own governance layer around perpetual access. That reinforces the case for identity-first controls across human IAM, NHI, and workload identity, because access that never ages out cannot be safely managed with review cycles alone.

From our research:

• Only 9 of the 20 configurations, on 9 of the 19 platforms, come with a documented administrator control that can enforce a maximum credential lifetime, according to The 2024 Non-Human Identity Security Report.
• Another finding from the same report shows that 88.5% of organisations acknowledge their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
• For teams trying to close that gap, the NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding should be governed end to end.

What this signals

Credential lifetime should now be treated as a policy boundary, not a platform preference. When a key or token can persist indefinitely, the control plane shifts from the vendor to the organisation, which means lifecycle governance has to be explicit, auditable, and tied to ownership. That is where the NHI Lifecycle Management Guide becomes operationally useful.

Forever access creates hidden privilege creep across machine identity estates. If the same integration key survives role changes, vendor swaps, and application rewrites, the organisation accumulates access it no longer understands. That is why lifetime enforcement and offboarding need to be managed together, not as separate workstreams.

The practical signal for security teams is simple: if your inventory cannot tell you which credentials are time-bound and which are not, your IAM programme is already operating with blind spots. The next step is to align lifetime policy with the identity governance model you already use for human access, then extend it consistently to NHI and workload identity.

For practitioners

• Classify perpetual credentials as high-risk identities Build an inventory of every token, key, refresh token, and client secret that lacks a documented expiry default, then assign an owner, purpose, and review date to each one.
• Enforce platform lifetime controls where they exist Turn on organisation-level maximum lifetime settings for platforms that support them, and block creation paths that allow indefinite or unbounded credential validity.
• Replace legacy long-lived credentials first Prioritise migrations from classic tokens, permanent API keys, and unbounded refresh tokens to newer credential types that support shorter lifetimes or explicit expiration.
• Treat undocumented expiry as a policy exception If official documentation does not state a default lifetime, require explicit internal approval before the credential type is used in production.

Key takeaways

• Most major platforms still allow long-lived credential states, so expiry cannot be assumed as a default control.
• The control gap is not only in the credential itself but in whether administrators can enforce a maximum lifetime across the platform.
• Identity teams should treat undocumented or perpetual credentials as governance exceptions that require inventory, ownership, and migration plans.

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.
• Non-Expiring Credential: A non-expiring credential is a secret or token that remains valid until it is explicitly rotated, revoked, or deleted. These credentials create persistent access because the platform does not force a natural end to the credential's authority.
• Maximum Lifetime Policy: A maximum lifetime policy is an administrative control that limits how long a credential can remain valid before the platform forces renewal or expiry. It shifts lifecycle enforcement from user discretion to organisation-level governance and is central to reducing secret persistence.
• Configuration Inventory: A configuration inventory is a complete record of active policies, exceptions, routing logic, and ownership across a control environment. For email security, it shows what is actually enforced, where logic overlaps, and which settings have become technical debt rather than active protection.

What's in the full report

Identra.ai's full documentation audit covers the platform-by-platform lifecycle details this post intentionally leaves at the governance level:

• Credential-by-credential documentation notes for GitHub, AWS, Google Cloud, Salesforce, Slack, OpenAI, Anthropic, and the other platforms in scope.
• The exact wording used by vendor documentation to distinguish 'never expires' from 'no default expiration documented'.
• The admin policy settings that can enforce maximum lifetime on some platforms and the ones that do not exist publicly on others.
• The methodology and source checks used to classify each credential configuration as expiring, non-expiring, or undocumented.

👉 Identra.ai's full post covers the platform-by-platform credential table, lifecycle notes, and control gap details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.