What breaks when organisations rely only on resource-level IAM views to review access?

Why Resource-Level IAM Reviews Miss the Real Access Path

Resource-level IAM reviews answer a narrow question: who is directly attached to this resource? In cloud estates, that is often not the access path that matters. Service accounts, inherited bindings, nested folders, and transitive permissions can let a principal reach data without ever appearing on the resource itself. That creates a false sense of completeness, especially when teams equate “no direct grants” with “no access.”

This gap is one reason non-human identity programs lag so badly in practice. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and the 2024 Non-Human Identity Security Report shows 88.5% say their non-human IAM lags human IAM. Resource-only review models cannot surface impersonation paths, chained access, or privilege inherited from higher-level containers. In practice, many security teams discover the missing path only after an audit finding, incident, or failed containment exercise, rather than through intentional access review.

How the Review Should Be Built Instead

Access review needs to follow the identity graph, not just the resource policy. That means evaluating who can act on the resource directly, who can impersonate a service account, which groups or workload identities inherit access through folders or projects, and which tokens or keys can be used to pivot. A practical review should combine IAM bindings, service account role assignments, org-level inheritance, and evidence of token minting or delegation.

For cloud environments, current guidance suggests treating non-human identities as workload identities first, then tracing how they obtain authority at runtime. That aligns with the OWASP Non-Human Identity Top 10 emphasis on excessive privilege and weak lifecycle controls, and with NIST control families for access enforcement and least privilege in NIST SP 800-53 Rev 5 Security and Privacy Controls. Security teams should map direct bindings, inherited bindings, impersonation permissions, and key usage into one review workflow.

• Review the resource, its parent containers, and any delegated administrators.
• Identify service accounts that can reach the resource indirectly.
• Check whether principals can mint tokens, sign JWTs, or impersonate workloads.
• Validate whether permissions are still needed for current application flow, not historical setup.
• Remove access that exists only because of old project structures or broad admin inheritance.

This approach is especially important in large Google Cloud estates and other environments with nested organizational hierarchies, because resource-level views tend to break down when access is inherited several layers above the asset and then reused through service account impersonation.

Where the Blind Spots Show Up Most Often

Tighter review scopes often reduce noise, but they also increase the chance of missing transitive access, so organisations must balance reviewer workload against assurance. The biggest edge case is not a single overprivileged account, but an apparently low-risk resource that is reachable through a chain of identities, folders, and automated jobs.

That is why the operational question is not just “who can see this resource?” but “what identities can eventually act on it?” In environments with ephemeral workloads, CI/CD runners, or multi-project application stacks, static snapshots age quickly. The best practice is evolving toward continuous, graph-based entitlement review, because point-in-time resource lists cannot reliably show delegated access paths, especially when service accounts are reused across teams or platforms. In those situations, a clean resource policy can still mask a dangerous identity path.

Teams should also be cautious about interpreting a clean access review as a clean security posture. If the organisation has broad inherited roles, poorly governed service accounts, or weak offboarding, a resource-level review can look acceptable while the underlying privilege structure remains highly exploitable. Current guidance suggests prioritising paths that enable impersonation, token issuance, and cross-project chaining before relying on any resource-centric certification outcome.

Related resources from NHI Mgmt Group

• What breaks when organisations skip access review documentation and change tracking?
• What breaks when organisations do not review elevated access regularly?
• What breaks when organisations rely only on roles or only on scopes for API access?
• What breaks when organisations rely only on segregation of duties checks in ERP cloud security?