Access Path

What an access path represents

An access path is the route by which an identity reaches a resource. That route may be direct, but it is often indirect, such as through a role, a group membership, a delegated permission, or inherited access. The important point is not only whether access exists, but how that access is actually reached and sustained.

Access paths matter because security decisions are rarely made on a single permission in isolation. In real environments, the effective route to a resource can pass through several layers of entitlement, and those layers can accumulate broader access than intended if no one traces the path end to end.

Why access paths are a control problem

Access paths are a control problem because they reveal effective privilege, not just assigned privilege. A user, service, or workload may appear harmless at the direct assignment level while still inheriting a path that reaches sensitive data or administrative functions through a group, role, or nested entitlement.

That makes access-path review central to least privilege, entitlement governance, and periodic access certification. If teams only inspect top-level grants, they can miss transitive access that is technically valid but operationally excessive. This is one reason NIST Cybersecurity Framework 2.0 remains useful for structuring governance around access, protection, detection, response, and recovery.

Access paths also explain why permission sprawl is so difficult to unwind. A single broad group or inherited role can create many downstream routes to the same resource, so the security question becomes whether the route is justified, reviewable, and revocable, not merely whether it exists.

How access paths are analysed in practice

Analysing an access path means tracing the complete chain from actor to resource. Practitioners usually need to understand direct grants, nested groups, role composition, inheritance, policy exceptions, and any token- or session-based delegation that can extend reach beyond the obvious assignment.

This analysis is especially important where machine-to-machine access is involved, because service accounts, APIs, and automation often inherit access through infrastructure patterns rather than explicit human review. For that reason, standards such as RFC 6749: The OAuth 2.0 Authorization Framework, RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, and RFC 8707: Resource Indicators for OAuth 2.0 are relevant when access is mediated by tokens, client authentication, or audience restriction.

In broader control environments, CIS Controls v8, ISO/IEC 27001:2022 Information Security Management, and NIST SP 800-53 Rev 5 Security and Privacy Controls all support the discipline of reviewing access, privilege, authentication, and auditability as connected control concerns rather than separate silos.

What changes when access paths are indirect

Indirect access paths are harder to see, harder to explain, and often harder to remove safely. They can be created by inheritance, inherited roles, shared groups, nested entitlements, or application logic that expands access at runtime, so the effective route to a resource may differ from the permission a reviewer initially sees.

That matters because an indirect path can survive after the original business need has changed. The account, group, or role remains in place, and the resource is still reachable through a chain that no one has revisited, which increases the chance of stale privilege and hidden overexposure.

For that reason, access-path analysis is not just an inventory exercise. It is a way to test whether the organisation can explain why a route exists, who owns each hop in the route, and how quickly the route can be removed if the need disappears.

Related resources from NHI Mgmt Group

• What breaks when organisations do not map the access path of AI and SaaS integrations?
• How should organisations respond when trusted access becomes the attack path?
• What breaks when Vault access looks legitimate but the identity path is untrusted?
• Who is accountable when an MSP-managed access path is abused?