OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide

A secret that never expires turns any single leak into indefinite access, and most organisations still run on API keys, tokens and certificates with lifetimes measured in years. OWASP lists this as NHI7:2025 Long-Lived Secrets in the OWASP Non-Human Identities Top 10, rating it widespread, severe in technical impact and, unusually, easy to detect. This guide explains what OWASP says about NHI7, how to set lifetime targets per credential type, how to replace static secrets with short-lived ones, how to assess and measure progress, and where NHI7 sits in NIST SP 800-53, ASVS 5.0, cloud benchmarks and ATT&CK. It is for platform, cloud, IAM and NHI governance teams, and for auditors assessing credential lifecycle. Rotation runbooks and vault operation are covered in the linked guides rather than repeated here.

Key takeaways

• NHI7 is about lifetime, not leakage: OWASP notes that an attacker must first obtain the secret by another route, which is why exploitability is rated hard, but once they have it a long-lived secret gives them unlimited time.
• Detection is the easy part: secret managers, cloud credential reports and benchmark controls already show key age, so the gap is usually ownership and the engineering to rotate safely.
• Short-lived beats rotated: OWASP's preferred fix is credentials that expire and refresh automatically (federated workload tokens, leased dynamic secrets, user delegation SAS); scheduled rotation is the fallback for what cannot move.
• Set maximum lifetimes in policy, then enforce them in platforms: examples include GitHub's fine-grained PAT maximum lifetime, Google Cloud key expiry for new keys, and Azure SAS expiration policies.
• Revocation capability is part of NHI7: if you cannot revoke a credential quickly, its effective lifetime is however long the attacker keeps it, as the Microsoft SAS token extended to 2051 showed.

What it is and who it applies to

The OWASP Non-Human Identities Top 10 (2025) ranks NHI7 Long-Lived Secrets seventh, after NHI6 Insecure Cloud Deployment Configurations and before NHI8 Environment Isolation. OWASP describes NHI secrets (API keys, tokens, encryption keys and certificates) as long-lived when their expiry date is too far in the future or they have none. Developers use them so applications can authenticate to services; when one is leaked, an attacker can use it without any time limit. OWASP attributes their prevalence to two causes: rotation is hard, and short-lived alternatives are often unavailable.

• Who it applies to: every organisation with cloud access keys, service account keys, SaaS API keys, personal access tokens, database passwords, signing keys, certificates or session cookies used by machines. In practice that is everyone.
• Relationship to NHI2: NHI2 Secret Leakage is how a secret is exposed; NHI7 decides how long the exposure is exploitable. Fixing NHI7 is the most reliable way to make NHI2 incidents survivable, because leaks will never reach zero.
• Relationship to NHI1: keys that outlive the workload or person that created them are both an offboarding failure and a lifetime failure. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Structure and key requirements

OWASP's prevention requirements are four:

1. Automate rotation of keys and credentials with cloud-native tools or scripts.
2. Use short-lived credentials that refresh automatically where the platform supports them.
3. Apply zero trust principles, requiring re-authentication for sensitive access or high-risk actions.
4. Enforce least privilege so a compromised credential can do limited harm.

OWASP gives two scenarios: an attacker with low-level network access finds an old data dump containing a still-valid admin token and escalates privileges; and an infostealer harvests a long-lived web session cookie from a corporate browser, which is sold and used to enter the network. The second is a reminder that sessions and refresh tokens are secrets too. The page also cites survey data from Datadog (2024: about 46% of AWS organisations using long-lived console credentials and 60% of cloud keys older than a year), the Cloud Security Alliance (lack of rotation behind about 45% of NHI-related incidents; 51% of organisations with no formal process to revoke long-lived API keys) and Orca Security (2022: 80% with KMS key rotation disabled, 79% with an access key older than 90 days). These figures are as cited by OWASP; confirm them in the original reports before reuse.

Identity and NHI requirements

Lifetime is a property of the identity's authentication method. The practical requirement is a target lifetime per credential type, the platform control that enforces it, and the short-lived replacement to migrate to.

• Owner per credential: rotation of a key nobody owns is an outage risk, so it does not happen. See the NHI Ownership Guide.
• Single consumer: a key shared across services cannot be rotated on one team's schedule. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide.
• Authentication method: static secrets are one of the insecure patterns OWASP addresses under authentication. See the OWASP NHI Top 10 NHI4 Insecure Authentication Guide and the NHI Authentication Guide.
• AI agents: issue agents task-scoped, expiring credentials through a broker rather than long-lived API keys in configuration. See the Credential Vaulting for AI Agents Guide.

Implementation steps

1. Inventory key age (weeks 1 to 2): pull the AWS credential report and access key last-used data, the Google Cloud key list per service account, Azure storage accounts with Shared Key allowed, GitHub organisation PAT listings, and secret manager metadata. Record creation date, last rotation, last use and owner. See the Secret Sprawl Measurement Guide.
2. Write the lifetime standard: set a maximum lifetime per credential class (for example 90 days for any remaining static cloud key, aligned to Security Hub IAM.3, and hours or less for anything federated), the exception process, and who approves exceptions. ASVS 5.0 V13.1.4 expects the secrets and their rotation schedule to be documented, and V13.3.4 expects secrets to expire and rotate accordingly.
3. Remove unused credentials first: credentials with no use in 45 days (IAM.22) are the cheapest win. For AWS keys, set the key Inactive, wait through a full business cycle, then delete; reactivation is the rollback.
4. Enforce at the platform: lower GitHub's fine-grained PAT maximum lifetime and restrict classic PATs (non-compliant tokens are blocked, not revoked, so warn owners first); set Google Cloud key expiry for new keys and disable key creation where federation is possible; set an Azure SAS expiration policy and disallow Shared Key where clients support Entra authorisation.
5. Migrate to short-lived credentials (pilot then waves): start with CI/CD, where OIDC federation gives a token valid for a single job and removes cloud keys from pipeline secrets. Then move databases to leased dynamic credentials (a lease TTL that must be renewed, with revocation on expiry or by prefix), and storage access to user delegation SAS. Pilot one pipeline or service, run old and new credentials side by side, then cut over. See the Workload Identity Federation Guide and the HashiCorp Vault Guide.
6. Automate rotation for what remains: use dual-credential rotation (create new, deploy, verify, retire old) with versioning so consumers update without downtime. Test the rollback path before the first production rotation. See the Secrets Rotation Runbook Template.
7. Prove emergency revocation: rehearse revoking a high-value credential end to end, including dependent services. The CircleCI Breach 2023 required customers to rotate every secret stored on the platform; organisations that had never rotated those keys found out what depended on them during the incident.
8. Shorten sessions for high-risk actions: apply re-authentication and shorter token lifetimes to administrative APIs and sensitive data, in line with OWASP's zero trust point.

Decision guidance: choose federation or managed identity wherever both ends support it, because it removes the secret rather than shortening it. Choose dynamic leased secrets for databases and legacy systems that only accept passwords. Choose scheduled rotation only where neither is possible, such as third-party SaaS that issues static API keys; there, pair rotation with tight scope and IP or network restrictions. Small organisations can usually reach "no static cloud keys" quickly with native federation; large estates should expect a long tail of vendor integrations and plan an exception register with review dates.

Evidence and assessment

Metrics that show it is working:

• Static credential count: number of long-lived cloud keys, service account keys and PATs, trending down.
• Median and 95th percentile credential age: by credential class, against the standard.
• Short-lived coverage: percentage of workloads and pipelines authenticating with federated or leased credentials.
• Rotation compliance: percentage of remaining static secrets rotated within their maximum lifetime.
• Time to revoke: measured in drills and real incidents, from decision to confirmed failure of the old credential.

What to monitor: creation of new static keys where federation is available, attempts to set or extend expiry beyond policy (Azure Monitor logs SAS policy violations when configured), use of keys older than the standard, and API calls from credentials that should be inactive.

Mapping to other frameworks

Common pitfalls

• Extending expiry instead of rotating: in the Microsoft SAS Token Exposure 2023, a token due to expire in October 2021 was extended to October 2051, and it stayed public until June 2023. Alert on expiry extensions, not only on creation.
• No revocation path for long-lived tokens: the Home Depot Token Exposure 2025 involved a GitHub token that stayed exposed for more than a year and was revoked only after press contact. A lifetime limit would have ended it without anyone acting.
• Keys outliving their purpose: the Toyota T-Connect Key Exposure 2022 access key worked for almost five years after it was published. Age alerts on high-value keys would have forced a rotation long before discovery.
• Policy that only applies to new credentials: Google Cloud key expiry does not apply to existing keys, and GitHub blocks rather than revokes non-compliant PATs. Pair every new policy with a clean-up of the existing population.
• Rotation without consumers mapped: rotating a shared key breaks unknown dependants, the team rolls back, and rotation is quietly dropped. Map consumers from access logs before the first rotation.
• Forgetting sessions: long-lived session cookies and refresh tokens bypass MFA when stolen by infostealers, as OWASP's second scenario shows. Include them in the lifetime standard.

Practitioner checklist

• Export key age, last use and owner for every cloud, SaaS and Git credential.
• Publish a maximum lifetime per credential class with an exception register.
• Deactivate, then delete, credentials unused for 45 days.
• Lower GitHub PAT maximum lifetime and restrict classic PATs.
• Set Google Cloud key expiry and disable key creation where federation works.
• Set an Azure SAS expiration policy and prefer user delegation SAS.
• Move CI/CD to OIDC federation and databases to leased dynamic credentials.
• Automate dual-credential rotation for what cannot move, with a tested rollback.
• Run a revocation drill for one high-value credential each quarter.
• Report static credential count and credential age percentiles monthly.

Standards and references

• OWASP: NHI7:2025 Long-Lived Secrets
• OWASP: Top 10 Non-Human Identities Risks 2025
• OWASP: Application Security Verification Standard 5.0
• AWS: Security best practices in IAM
• AWS: Security Hub controls for IAM
• Microsoft Learn: Create a user delegation SAS
• GitHub Docs: Setting a personal access token policy for your organization
• HashiCorp: Vault lease, renew and revoke

Related NHI Mgmt Group resources: Secrets Rotation Runbook Template · Workload Identity Federation Guide · Secrets Management Guide · OWASP NHI Top 10 NHI2 Secret Leakage Guide · Non-Human Identity (NHI) Guide