Because PAM can only enforce control over credentials it can discover and manage. When secrets live in code, configuration files, or CI/CD tools, the organisation loses visibility over where privilege exists and who can use it. That makes rotation, revocation, and audit evidence incomplete.
Why This Matters for Security Teams
The PAM gap appears when an organisation assumes a vault is the control plane for privilege, but secrets have already leaked into places PAM cannot govern: source code, build logs, tickets, chat, and CI/CD variables. At that point, access review becomes incomplete because the credential lifecycle is no longer visible end to end. Current guidance from the OWASP Non-Human Identity Top 10 treats unmanaged secrets as a core identity risk, not just an operational hygiene issue.
NHIMG research shows how common this exposure is: in the 2025 State of NHIs and Secrets in Cybersecurity, 44% of NHI tokens were reported as exposed in the wild, including code commits and collaboration tools. That means the control failure is not merely weak rotation, but lost inventory. If a secret is duplicated outside the vault, PAM cannot reliably revoke every copy, prove who used it, or confirm whether a token is still active after an incident. In practice, many security teams discover this only after a leak has already spread across repositories, pipelines, and support tooling.
How It Works in Practice
PAM is strongest when it can broker access to a known credential, issue it just in time, and enforce checkout, approval, and revocation. The gap starts when developers or automation systems bypass that path and hardcode secrets or inject them into build systems. At that point, the credential becomes a shadow identity that exists outside policy enforcement.
Operationally, closing the gap requires treating secrets as governed assets across their entire lifecycle, not just at the vault. That usually means:
- Scanning code, CI/CD configurations, chat exports, and ticketing systems for embedded secrets.
- Replacing long-lived static secrets with short-lived tokens where the workload can support it.
- Revoking and rotating credentials when a secret is found outside approved storage, not only when a vault policy changes.
- Mapping each secret to an owner, workload, and purpose so audit evidence is tied to an actual business use case.
This is also where Guide to the Secret Sprawl Challenge is useful, because sprawl is usually a discovery and inventory problem before it becomes a vaulting problem. NIST guidance on access control and secrets handling reinforces the same idea: if the organisation cannot identify the credential, it cannot meaningfully govern it. The practical goal is not simply “move everything into a vault,” but make sure every privilege-bearing secret is discoverable, attributable, and revocable. These controls tend to break down in fast-moving DevOps environments because secrets are created and copied faster than inventory and rotation processes can keep up.
Common Variations and Edge Cases
Tighter secret control often increases delivery overhead, requiring organisations to balance developer speed against the cost of manual remediation. That tradeoff is most visible in environments with many ephemeral workloads, third-party integrations, and legacy applications that cannot easily adopt modern token exchange.
Best practice is evolving for these edge cases. Some teams can move to dynamic credentials and automated brokered access, while others still need a phased approach that combines vault enforcement, secret scanning, and aggressive rotation. There is no universal standard for this yet, especially where vendor platforms store secrets in proprietary formats or where CI/CD tools generate credentials on behalf of multiple applications.
Two patterns deserve extra attention. First, a secret in a vault is not safe if copies remain in repositories or deployment logs. Second, a credential that is technically vaulted but broadly shared across applications still creates a high-impact compromise path. NHIMG’s research on Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack shows how quickly exposed secrets can turn into lateral movement and broader compromise. The lesson is simple: vaulting helps, but PAM closes the gap only when secret discovery, revocation, and usage monitoring extend beyond the vault boundary.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses unmanaged and overexposed secrets that bypass PAM visibility. |
| NIST CSF 2.0 | PR.AC-1 | Access control breaks when credentials exist outside governed systems. |
| NIST AI RMF | AI risk governance applies when autonomous systems generate or consume secrets. |
Inventory every secret source and rotate or revoke anything PAM cannot see or control.
