Why do security audits often miss the most important identity risks?

Why This Matters for Security Teams

Security audits are valuable for proving that controls exist, but they are weak at showing whether those controls actually stop abuse. That gap matters most for identity, where a documented review can coexist with an over-privileged service account, a stale API key, or a third-party connection that still has live access. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition a checklist audit can miss.

Frameworks such as the NIST Cybersecurity Framework 2.0 help teams organise governance, but the audit lens still tends to favour evidence of process over evidence of exploitability. That distinction is why identity risk often remains hidden until a breach review or incident response exercise uncovers it. The problem is not that audits are useless, but that they are answering a different question than attackers are asking.

In practice, many security teams encounter the most damaging identity exposure only after a routine review has already marked the environment as compliant.

How It Works in Practice

Auditors usually test whether identity controls are present, approved, and repeated on schedule. That means they look for policies, tickets, access review evidence, vault usage, and revocation workflows. They rarely simulate what happens when an attacker chains those identities together, reuses a token from CI/CD, or calls an exposed API with a permission set no one has exercised recently. NHI Management Group’s Top 10 NHI Issues and 52 NHI Breaches Analysis both show how often hidden identity sprawl, missed rotation, and inherited privilege create real-world exposure.

In operational terms, the mismatch comes from measuring governance artifacts instead of attack paths. A team can show that:

• access reviews were completed, even if the reviewer did not understand the workload’s actual use cases
• secrets were stored in a vault, even if the vault policy still allows broad retrieval
• service accounts were documented, even if no one verified their current outbound permissions
• offboarding steps exist, even if the associated tokens remain valid long after the review

Current guidance suggests identity audits should be supplemented with continuous control validation, permission graph analysis, and active secret inventory checks. For identity-heavy environments, that means confirming what an account can do right now, not just what a policy says it should be able to do. The most useful evidence often comes from runtime telemetry, short-lived credential issuance, and explicit validation of standing access against actual dependencies. These controls tend to break down when identity sprawl spans cloud, SaaS, CI/CD, and third-party integrations because no single audit sample can capture the full attack surface.

Common Variations and Edge Cases

Tighter identity auditing often increases operational overhead, requiring organisations to balance assurance against speed and engineering friction. That tradeoff becomes sharper in environments with thousands of service accounts, ephemeral workloads, or autonomous agents, where static review cycles age out before the next deployment. In those settings, best practice is evolving toward real-time policy checks, just-in-time access, and workload identity rather than long-lived secrets.

There is no universal standard for this yet, especially for AI-driven systems and multi-agent pipelines. A traditional audit may confirm that an agent platform has access approvals in place, while missing the fact that the agent can independently chain tools, request new permissions, or reuse a token outside the original approval scope. For those cases, the relevant question is not whether access was reviewed, but whether access is constrained at the moment it is used.

The strongest audit programs now pair compliance evidence with attack-path testing, secret exposure checks, and exception tracking. That approach is especially important when third parties, inherited roles, or machine-to-machine trust relationships are involved, because those are the places where a clean audit trail can still conceal immediate exploitability.

Related resources from NHI Mgmt Group

• How should security teams support SOX audits with identity governance?
• Why is proactive secret scanning important for NHI security?
• Why is it important to integrate identity and data governance?
• How should security teams handle risks from AI browser extensions?