How should security teams manage dormant non-human credentials in integrated business systems?

Security teams should inventory every API key, OAuth token, and service credential, map each one to an owner, and revoke anything unused for more than 90 days. Dormant credentials are dangerous because they are often unmonitored yet still valid. In integrated environments, a single forgotten credential can become a bridge into customer systems, so lifecycle review and expiry are essential controls.

Why This Matters for Security Teams

Dormant non-human credentials are not harmless leftovers. In integrated business systems, an API key, OAuth token, or service account can remain valid long after the original owner has moved on, the application has changed, or the partner connection has been forgotten. That creates quiet exposure that bypasses normal user offboarding controls. The issue is especially acute because secrets often sit outside standard IAM review cycles and are rarely tied to a visible business owner.

Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward continuous asset visibility, credential lifecycle control, and least privilege as the practical baseline. NHIMG research shows why this matters operationally: in the State of Non-Human Identity Security, lack of credential rotation was cited as the top cause of NHI-related attacks by 45% of organisations.

In practice, many security teams discover dormant access only after a partner integration, internal workflow, or forgotten automation token has already been used to reach customer data or cloud resources.

How It Works in Practice

The practical goal is to turn dormant credentials from hidden liabilities into governed assets with an owner, a purpose, and an expiry date. Start with a complete inventory of every secret used by business systems, including OAuth grants, service credentials, signed certificates, and machine-to-machine tokens. Then map each credential to the system it supports, the business owner, the technical owner, and the last known use. A credential with no owner or no verified use history should be treated as suspect until proven otherwise.

Security teams should combine discovery, telemetry, and lifecycle enforcement. Discovery finds the credential. Telemetry shows whether it is actually used. Lifecycle enforcement decides whether it stays active. The strongest programs align with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Guide to the Secret Sprawl Challenge, which both emphasize continuous inventory and disposal of stale secrets rather than periodic cleanup alone.

• Set a review threshold, such as 60 or 90 days of inactivity, and require explicit re-approval before renewal.
• Prefer short-lived, dynamically issued secrets where the integration can support them.
• Revoke credentials that are unused, unowned, duplicated, or impossible to map to a current business process.
• Monitor for unexpected use after dormancy, especially from new IPs, new geographies, or new workloads.
• Store evidence of ownership, rotation, and revocation so auditors can verify the control without manual reconstruction.

This approach aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls expectations around access control and account management, but it breaks down when the environment has no reliable inventory, when shared service accounts are embedded in legacy code, or when third-party integrations cannot tolerate rotation without redesign.

Common Variations and Edge Cases

Tighter credential control often increases operational overhead, requiring organisations to balance security gains against application fragility and partner coordination. That tradeoff is real in ERP connectors, payment rails, industrial systems, and vendor portals where a single secret may be embedded in code, configuration, and recovery scripts at the same time.

Best practice is evolving on how aggressively to expire credentials in these environments. There is no universal standard for this yet, but current guidance suggests treating long-lived static secrets as exceptions, not the default. Where rotation is hard, teams should compensate with stronger monitoring, tighter scope, and break-glass procedures that are separately protected and regularly tested. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce the same principle: long-lived secrets should be exceptional and tightly governed.

One common edge case is dormant credentials that are not truly unused but are only exercised during quarter-end, disaster recovery, or rare customer workflows. Those should not be blindly revoked. Instead, validate the business cadence, document the expected interval, and make the expiration policy match that reality. Another edge case is OAuth consent granted to a third-party app: if the app is no longer needed, revoke the grant itself, not just the stored token.

Teams that follow the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 will usually get the governance structure right, but the hardest failures still come from exceptions hidden in legacy integrations, where no one remembers the credential exists until an incident exposes it.

Related resources from NHI Mgmt Group

• How should security teams manage third-party non-human identities in supply chain environments?
• How should security teams reduce the risk from leaked non-human credentials?
• How should security teams manage non-human identities during M&A?
• How should security teams audit non-human credentials in cloud environments?