Teams often underestimate the cost of doing recursive access resolution themselves. If they depend on multiple ad hoc expand calls, they create complex client logic, slower responses, and a higher chance of incomplete results. The common mistake is treating authorization as a simple lookup when the real model is a graph that must be traversed fully.
Where teams go wrong with “complete access lists”
The main mistake is assuming access can be enumerated as if it were a single flat lookup. In real systems, effective access often comes from nested groups, inherited roles, delegated permissions, linked applications, shared resources, and policy exceptions. If teams stop at the first layer, they miss legitimate paths and produce lists that look precise but are actually partial.
A second failure is treating the answer as a one-time snapshot rather than a traversal problem. The resource may be simple, but the access graph around it is not. That is why manual expansion, ad hoc recursive calls, and client-side stitching frequently create inconsistent results, duplicate entries, and slow queries that encourage teams to abandon completeness before they reach it.
This is also where visibility breaks down operationally: if the resolution logic is spread across tools or scripts, there is no single definition of “who can access this resource” that every team trusts. The outcome is often a mix of overcounting, undercounting, and uncertainty about whether the result represents direct entitlements, indirect entitlements, or both.
Why recursive resolution is harder than it looks
Access resolution becomes expensive because every extra hop can multiply the search space. Groups contain groups, roles map to policies, policies grant permissions, and applications may introduce their own authorization layers. When teams repeatedly call expand operations without a clear traversal model, they shift complexity from the server to the client and lose control over ordering, depth, termination, and deduplication.
The practical issue is not just speed. Fragmented recursion can hide edge cases such as cyclic references, transitive access through stale memberships, and inconsistent results when different systems expose different parts of the graph. A complete answer requires a method that can walk the entire relevant relationship set, not just the most obvious direct assignments. For background on the broader visibility and over-privilege problem that often sits behind these mistakes, see Ultimate Guide to NHIs, Key Challenges and Risks.
At scale, this is why teams should treat authorization data as a graph problem with a defined traversal strategy, not a reporting convenience. If the algorithm cannot explain how it handles inherited access, nested membership, exclusions, and duplicates, the final list is usually incomplete even when it appears exhaustive.
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 CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Complete access lists depend on accurate account and permission governance. |
| Recommendation — Define and review access paths centrally so effective permissions are consistently discovered and removed. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question concerns resolving who can access a resource through governed access control paths. |
| Recommendation — Maintain authoritative access relationships so authorization results are complete and traceable. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Visibility and Discovery | Incomplete access lists often come from missing visibility into nested or indirect non-human access paths. |
| NHI-05 — Privilege Management | The access-list problem is amplified when inherited or excessive privileges are hidden in the graph. | |
| NHI-02 — Lifecycle and Offboarding | Stale memberships and lingering entitlements make access enumeration incomplete and misleading. | |
| Recommendation — Inventory indirect access paths and resolve transitive permissions before trusting an access report. Review inherited entitlements and remove excess permissions that distort effective-access results. Revoke stale memberships and credentials promptly so resolved access reflects current state. | ||
| NIST SP 800-63 | AAL — Authentication Assurance Level | Access listings are only trustworthy when the identity assurance behind the subject population is sound. |
| Recommendation — Bind access decisions to appropriately assured identities before relying on authorization output. | ||
Practitioner Guidance
What to verify: Confirm whether your access inventory distinguishes direct grants from effective access. A useful test is to compare one known user or service principal against the full resolved path and verify that every intermediate group, role, policy, or inheritance edge is represented.
Implementation sequence: Start with a canonical resolution model, then centralise recursion in one service or query layer, then add deduplication and cycle handling, and only after that optimise performance. If teams optimise early, they usually preserve the wrong answer faster.
Common mistake: Do not assume a successful response from an expand endpoint means the result is complete. When the resource graph is deep or federated, “fast enough” often means “stopped too early.” For practitioners building visibility into access paths, the scale of the underlying identity population is also a reason to prefer systematic discovery over manual review: NHIMG’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises.
Practitioner takeaway: The right goal is not a long access list, it is a defensible resolution method that can prove it traversed the full graph and distinguish direct from effective access.
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to manage AWS access with static assignments?
- What do teams get wrong when they try to speed up secure remote access?
- What do teams get wrong about emergency access and cloud group membership when they try to simplify identity operations?
- What do teams get wrong when they build login and access control into Remix apps?
