Where do vaults and IGA most often miss privileged access today?

Where vaults stop protecting privileged access

Vaults and IGA usually work well for what they can see: checked-out secrets, named privileged accounts, and reviewable entitlements. The gap opens when privilege is granted through objects that were never built for the original checkout model, such as cloud roles assigned directly to users, service accounts embedded in pipelines, and OAuth applications that carry elevated rights without a person holding the secret interactively.

That is why governance often looks complete on paper while privilege still escapes runtime enforcement. A vault can store and rotate secrets, and IGA can certify what is in its inventory, but neither control automatically captures every path by which an identity can assume authority, delegate access, or keep using a standing token outside the governed workflow.

In practice, the blind spot is usually less about discovery than about control placement. Teams may know the identity exists, yet if the access path is not bound to the same approval, review, and enforcement path as the rest of the privileged estate, the identity remains effectively unmanaged where it matters most, during use.

Why cloud roles, service accounts, and OAuth apps slip through

These identities fail for different reasons, but the outcome is similar: privilege is real, yet fragmented across systems that do not share one operating model. Cloud roles are often attached through IAM or platform-native permissioning, service accounts are created for automation and then left to run indefinitely, and OAuth applications can accumulate broad API rights long after the original business need has changed.

Vault-centric controls tend to assume a secret is the unit of control. That assumption breaks when the more important control point is the entitlement, the token audience, or the delegated permission behind the secret. A long-lived key in a vault may be visible, but a high-privilege app registration or role assignment can still expose the same capability through a different enforcement path.

For that reason, the strongest Cloud PAM and CIEM Guide and Just-in-Time Access and Zero Standing Privilege Guide both matter here: they address the difference between holding a secret and having durable standing privilege. The same pattern is visible in Active Directory and Entra ID Hardening Guide, where delegation, privileged groups, and hybrid identity can preserve access even when the original account path looks controlled.

What a common governance path has to do differently

A common governance path has to treat privilege as a lifecycle, not as an inventory row. That means discovery, approval, review, revocation, and runtime limitation must all cover the same identity object, whether that object is a human account, a cloud role, a workload credential, or an application grant. If one of those stages is missing, the identity can remain discoverable but still operationally exempt from enforcement.

That is why mature programmes connect vaulting, entitlement review, and access enforcement instead of running them as separate tracks. NHI Lifecycle Management Guide is the clearest example of this model because it ties provisioning, rotation, offboarding, and visibility together. The same lifecycle logic is echoed in Privileged Access Management Guide, where vaulting and rotation are only part of the control story, not the whole answer.

The practical implication is that governance must reach beyond named users. A service account in a data pipeline or an OAuth application with elevated rights needs the same change control and retirement discipline as a privileged human account, otherwise the organisation will keep certifying the wrong surface while the active privilege path stays open.

Risk and Threat Considerations

When privileged access sits outside the original checkout model, attackers do not need to defeat the vault first. They can target the delegated role, the application grant, the pipeline credential, or the surrounding identity wiring and still reach the same authority. The result is often quieter than a direct password theft because the access looks legitimate to downstream systems.

Failure mechanism: Privilege is granted through a separate control plane, such as cloud IAM, OAuth consent, or service-to-service authentication, while vault and IGA controls only cover the secret or the reviewed account. That split leaves standing access paths untouched even when the central inventory appears clean.

Impact: Excess privilege persists, revocation becomes incomplete, and compromise of one overlooked identity can produce broad lateral movement, data access, or administrative abuse. The risk is highest where automation, third-party integrations, or cloud-native delegation create access that is technically valid but never brought into the same governance path.

Practitioner Guidance

What to verify: Confirm that every privileged path has an accountable owner, a revocation path, and a runtime enforcement point. If the identity can act without a fresh governance decision, it is not really inside the control boundary.

Common mistake: Treating vault coverage as proof of privilege coverage. In reality, a vaulted secret can be well managed while the underlying role assignment, app consent, or token scope remains over-broad or never reviewed.

What good looks like: The governance record, the runtime permission, and the retirement process all point to the same identity object. That is the standard to aim for when you want privileged access to stay observable and removable, not merely discoverable.

Practitioner takeaway: The control question is not whether the identity can be found, it is whether its effective authority can be forced through the same approval, review, and enforcement path as everything else privileged.

Related resources from NHI Mgmt Group

• Why do HR, directory, IGA, and PAM controls often miss dormant access after offboarding in hybrid environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?