A reachable permission is an entitlement an attacker can actually use from a current foothold, not just one that exists on paper. This concept matters because cloud risk is created by what can be composed and executed in the live environment, especially across identities, roles, and services.
What Makes a Permission Reachable
A permission is reachable when it is not merely assigned, but can be exercised from an actual foothold in the environment. That distinction shifts the question from entitlement inventory to operational exploitability: can a current identity, token, session, role chain, or service path use the permission right now?
Reachability is shaped by live trust relationships, not static policy text. An entitlement may exist in a directory, cloud role, or application policy and still be unreachable if there is no path to assume it, invoke it, or inherit it from the compromised starting point.
Why Reachability Changes the Security Meaning of Permission
Reachable permission is a practical security concept because attackers do not need every overbroad grant, only the ones they can compose into action. In cloud and identity-heavy environments, the difference between theoretical access and executable access often determines whether a foothold becomes privilege escalation, data exposure, or lateral movement.
This is why effective-permission thinking matters. A permission that looks harmless in a role review can become highly relevant when chained with role assumption, token reuse, delegated access, or a service identity that already has a trusted path into the target resource.
How Reachability Is Determined in Practice
To judge reachability, practitioners look at where the foothold sits, what it can authenticate as, what it can impersonate or assume, and which resources those identities can actually touch. The answer is often dynamic: the same entitlement may be reachable from one compromised account and unreachable from another.
In cloud systems, reachability is frequently created by composition across identities and services. A role may not be directly attached to the compromised principal, but it can still be reachable through cross-account trust, pass-role capability, federated access, workload credentials, or a chained authorization path.
That is why permission inventories alone are incomplete. The operational question is not only “what is granted?”, but “what can a real attacker execute from here without first breaking a second boundary?”
Reachable Permission as an Attack Surface Signal
Reachable permission is useful because it helps prioritise exposure by exploitability. When a permission is reachable, it belongs to the live attack surface, not just the governance register, and it deserves attention even if the underlying entitlement is technically legitimate.
This is especially important where one compromised identity can reach broad secrets or administration paths. A reachable permission can turn a minor foothold into a high-impact compromise when the path leads to key material, policy modification, data stores, or admin functions.
Risk and Threat Considerations
Reachable permissions matter because they collapse the gap between over-assignment and actual abuse. If an attacker lands on a session, role, or service identity that can already exercise a sensitive entitlement, the environment has effectively exposed a usable attack path rather than just a misconfigured record.
Failure mechanism: The permission becomes dangerous when the foothold can directly use it, assume it, inherit it, or chain into it through trust relationships, so excessive permissions, weak trust boundaries, and long-lived credentials turn into exploitable access.
Impact: The result can be privilege escalation, secret access, data exfiltration, destructive actions, or lateral movement, especially when the reachable permission includes administrative or cross-service capabilities.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Reachable permissions are the usable form of overprivilege in non-human access paths. |
| NHI-09 — NHI Reuse | Reachability often emerges when the same credential or role can be reused across paths. | |
| Recommendation — Right-size permissions to remove NHI access that a foothold can actually exercise. Eliminate reused NHI credentials and roles that expand reachable access paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege directly governs whether an assigned permission is actually usable from a foothold. |
| IA-5 — Authenticator Management | Credential lifecycle affects whether tokens and keys remain available to be used from a foothold. | |
| AC-3 — Access Enforcement | Access enforcement defines whether a permission can be executed at runtime, not just granted on paper. | |
| Recommendation — Apply least privilege to reduce permissions that are reachable from common compromise points. Rotate and retire authenticators so reachable permissions do not persist through old secrets. Enforce runtime access decisions so only intended actions remain reachable. | ||
Practitioner Guidance
Why practitioners should care: Reachable permission is the right lens for prioritising entitlement reduction because it distinguishes harmless surplus from permissions that an attacker can actually use. That makes it a stronger review target than raw grant counts or role names alone.
Governance implication: Treat permission reviews as path analysis, not just inventory checks, and focus on the identities, trust relationships, and session states that make a grant usable from a current foothold.
Practitioner takeaway: If you cannot explain how a permission is reached from a realistic compromise point, you do not yet know its true exposure.
Related resources from NHI Mgmt Group
- What is the difference between theoretical vulnerability and reachable risk?
- When should organisations revoke an OAuth grant or third-party app permission?
- What is the difference between client identity and permission scope in MCP governance?
- Why do permission boundaries fail as a scale control for cloud access?