What breaks when organisations do not maintain an inventory of access keys and integrations?

Why This Matters for Security Teams

An access-key inventory is not a paperwork exercise. It is the control plane that tells defenders which applications can authenticate, what each token or secret can reach, and which integrations should already be dead. Without that map, teams cannot confidently revoke access during an incident, and stale keys become quiet persistence paths. NHIMG’s Ultimate Guide to NHIs frames this as a core governance failure, not just an operations issue.

The risk compounds because secret sprawl is fast and often invisible. In the The State of Secrets in AppSec research, the average time to remediate a leaked secret is 27 days, which is far longer than the time an attacker needs to attempt abuse. Once an organization loses sight of dormant integrations, it also loses the ability to separate legitimate service-to-service traffic from attacker movement. This is exactly the kind of exposure that OWASP highlights in the OWASP Non-Human Identity Top 10. In practice, many security teams discover the missing inventory only after a compromised integration has already been used to deepen access.

How It Works in Practice

A usable inventory should answer four questions: what is the credential, where is it stored, which workload or integration uses it, and what privilege does it confer. That includes API keys, OAuth grants, service accounts, certificates, and machine-to-machine tokens. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this through identification, access control, and auditability requirements, but the practical goal is simpler: defenders need a live record they can query when something breaks.

For operational teams, the inventory should connect to rotation, expiry, and revocation workflows. A stale credential is dangerous because it is still technically valid even when the integration is no longer needed. Current best practice is to make ownership explicit, assign each secret to a business service, and continuously reconcile cloud, CI/CD, SaaS, and code repository findings against the approved list. NHIMG’s 52 NHI Breaches Analysis shows why that matters: attackers routinely exploit forgotten credentials, not just obviously exposed ones.

• Track every key, token, and certificate with an owner, purpose, scope, and expiry date.
• Tag integrations by environment so production and non-production access do not blur together.
• Reconcile IAM, secrets managers, SaaS audit logs, and source code scans on a fixed cadence.
• Delete unused integrations, not just their credentials, to remove hidden trust links.

This guidance breaks down in heavily decentralized environments where teams create machine credentials directly in SaaS tools, because ownership and usage data never converge in one authoritative system.

Common Variations and Edge Cases

Tighter inventory control often increases operational overhead, requiring organisations to balance visibility against the speed at which engineers spin up new integrations. That tradeoff is real, especially in cloud-heavy or M&A environments where credential sprawl grows faster than central governance. Current guidance suggests that teams should prioritize high-risk systems first, then expand coverage rather than waiting for a perfect master register.

There is no universal standard for this yet, but the direction is consistent: inventory must be tied to enforcement. If a secret is listed but never rotated, or an integration is known but never reviewed, the inventory becomes a passive catalog instead of a control. The most common edge case is shadow IT, where business teams create OAuth apps or automation bots outside security workflows. Another is service accounts embedded in legacy jobs, where no one can easily prove whether the integration is still needed. NHIMG’s Klue OAuth Supply Chain Breach is a reminder that connected apps can become cascading risk across many tenants, not just a single account.

In those environments, the right answer is usually progressive cleanup: discover, classify, assign, revoke, and then monitor for reappearance. Where the inventory cannot be made authoritative, security teams should assume any unmanaged integration can still authenticate until proven otherwise.

Related resources from NHI Mgmt Group

• What breaks when organisations do not maintain an inventory of personal data and access paths?
• What breaks when organisations rely on indefinite access for privileged systems?
• What breaks when third-party integrations have more access than they need in source code platforms?
• What breaks when organisations do not have visibility into integration permissions and required access scopes?