They should be able to show a current inventory of all infrastructure identities, a clear owner for each one, and a revocation or rotation path for every credential type. If an account or key cannot be explained in business terms, traced in logs, or retired on schedule, control is not working.
Why This Matters for Security Teams
shadow access is not just an inventory problem. It is a control failure when service accounts, API keys, workload identities, and automation tokens cannot be explained, owned, or revoked on demand. That is why current guidance from the OWASP Non-Human Identity Top 10 treats visibility, lifecycle, and privilege as a single risk surface rather than separate hygiene tasks. NHI Mgmt Group’s Ultimate Guide to NHIs shows why: NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts.
Security teams often think shadow access is “under control” because secrets are stored in a vault or permissions are technically least-privilege. That is not enough. If the owner is unknown, the purpose is undocumented, or revocation is manual and slow, the access is still effectively shadowed. The practical test is whether the organisation can prove who can use the credential, why it exists, where it is used, and how it is retired. In practice, many teams discover the gap only after an incident, not through routine governance.
How It Works in Practice
Control starts with a living inventory of all non-human identities, not a one-time spreadsheet. Each identity should map to a named business owner, a technical owner, a system dependency, and an expiration or review date. That inventory must include service accounts, API keys, certificates, workload identities, CI/CD tokens, and any embedded secret that can reach production systems. NIST’s SP 800-53 Rev. 5 is relevant here because it reinforces accountability, access restriction, and auditability as operational controls, not optional documentation.
The next layer is proof of control over the lifecycle. Organisations should be able to show:
- who approved issuance of each credential
- what system or workload it is bound to
- how rotation happens and on what schedule
- how revocation is triggered when the owner changes or the system is retired
- what logs confirm actual use, not just presumed use
That is also why NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks is so focused on secrets sprawl and unmanaged exposure. A key can be technically valid yet functionally abandoned, and abandoned access is where shadow control fails. Mature teams reduce standing exposure by shortening TTLs, binding credentials to workload identity, and making revocation automatic rather than dependent on ticket queues. These controls tend to break down when credentials are hard-coded into apps or copied into CI/CD systems because the organisation loses the ability to discover, rotate, or retire them centrally.
Common Variations and Edge Cases
Tighter credential control often increases operational overhead, requiring organisations to balance rapid automation against change friction and system downtime. That tradeoff is especially visible in legacy platforms, third-party integrations, and emergency access paths, where owners resist short TTLs because jobs may fail if tokens expire too soon. Best practice is evolving here: there is no universal standard for every environment, but the direction is clear. Short-lived credentials, just-in-time issuance, and per-task authorization are stronger indicators of control than static long-lived secrets.
Edge cases matter. Shared service accounts may still exist for technical reasons, but they should be exceptional, documented, and monitored with compensating controls. Orphaned keys in source code are another common exception: if they cannot be traced to a current service owner, they should be treated as active exposure, not background noise. The same applies to third-party and supplier access, which often lingers after a contract or integration has changed. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how quickly weak ownership and stale credentials become real incidents, not theoretical gaps.
Organisations know shadow access is under control only when every exception has a reason, an owner, a log trail, and a retirement path. If any one of those is missing, control is partial at best.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers discovery and inventory of non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Addresses access control and identity management for systems and users. |
| NIST AI RMF | GOVERN | Supports governance, accountability, and lifecycle oversight for automated systems. |
| NIST Zero Trust (SP 800-207) | 5.1 | Zero Trust requires continuous verification instead of implicit trust in access. |
| CSA MAESTRO | T1 | Agentic and workload governance depends on controlled identities and policy enforcement. |
Build a complete NHI inventory and tie every credential to an owner, purpose, and review date.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
