What is the difference between flattened access data and raw directory structure in an access review?

Why This Matters for Security Teams

An access review is only as useful as the view behind it. Raw directory structure shows nesting, group membership, and trust relationships, but it can hide the privileges that actually land on a person, service account, or NHI after inheritance is resolved. Flattened access data exposes effective access, which is what reviewers must judge against least privilege, separation of duties, and audit requirements.

This distinction matters even more where NHI sprawl is high. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations report full visibility into their service accounts in the Ultimate Guide to NHIs. When teams review only directory structure, they often miss inherited privileges, transitive group access, and stale entitlements that remain active long after ownership has changed.

Security teams should treat the flattened view as the evidence layer and the raw tree as the relationship layer. The raw directory helps explain why access exists; the flattened view shows whether it should exist. In practice, many access review failures are discovered only after auditors or incident responders reconstruct effective privilege from the directory, rather than through intentional review design.

How It Works in Practice

Raw directory structure is the source model. It shows users, groups, nested groups, roles, ACLs, and upstream trust paths exactly as they are stored in the directory or identity system. Flattened access data is the computed result after inheritance, nesting, and policy resolution are applied. For a reviewer, that means one account can appear simple in the tree but inherit broad access through several layers of indirection.

That difference is why review tooling should separate visibility from decision-making. The raw structure is useful for troubleshooting and delegation mapping, but the review packet should prioritise effective access: what the identity can actually reach, change, approve, or execute. This aligns with the intent of OWASP Non-Human Identity Top 10 and the control logic described in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access validation depends on the actual entitlement state, not just the directory shape.

In mature access reviews, the workflow usually looks like this:

• Extract raw directory memberships, role bindings, and trust links.
• Resolve nested groups and inherited policies into a flattened entitlement set.
• Deduplicate repeated paths so reviewers see effective privilege once, not many times.
• Map each entitlement to a business owner, system owner, or control domain.
• Flag exceptions such as shadow admin access, stale service accounts, and indirect privileged roles.

NHI Mgmt Group’s NHI Lifecycle Management Guide is especially useful here because lifecycle ownership and revocation only make sense when the effective access set is known. These controls tend to break down when directories are federated across multiple tenants and identity sources because flattening can miss cross-system inheritance or duplicate entitlements.

Common Variations and Edge Cases

Tighter flattening often increases processing cost and review noise, requiring organisations to balance completeness against the operational burden of long entitlement lists. That tradeoff becomes more visible in complex environments such as hybrid AD and cloud IAM, multi-forest mergers, and delegated administration models where a single raw group path can expand into dozens of effective permissions.

There is no universal standard for how much context should appear in a flattened review record. Current guidance suggests the reviewer should see enough provenance to understand why access exists, but not so much raw topology that the effective privilege is obscured. For service accounts and NHIs, the Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference because static membership alone often understates real exposure.

Edge cases include temporary elevation, JIT access, nested privileged groups, and access granted through application roles rather than directory groups. In those situations, raw structure is still necessary for root-cause analysis, but flattened access is what should drive attestation, revocation, and audit evidence. If the environment does not reliably resolve inheritance across systems, then the flattened view may underreport privilege and the review process needs compensating validation. That gap is common in directories with stale sync, custom ACL logic, or incomplete entitlement normalization.

Related resources from NHI Mgmt Group

• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between protecting applications and protecting access?
• What is the difference between entitlement review and data access governance?