PMapper is used to analyse AWS Identity and Access Management permissions and identify paths an attacker or over-privileged user could use to reach higher-impact actions. Security testers use it to map privilege escalation and lateral movement routes, then validate least-privilege design. It is most useful when reviewing role trust and transitive access.
How PMapper fits into AWS IAM security testing
PMapper is a graph-based analysis tool for AWS IAM. It helps testers turn a large permission set into a map of reachable actions, showing how apparently modest permissions can chain into far more powerful access. That makes it useful for reviewing privilege boundaries, cross-role trust, and the real blast radius of an AWS account.
In practice, the value is not just identifying what a principal can do directly. The more important question is what that principal can reach through role assumption, attached policies, trust relationships, and transitive permissions. PMapper is especially helpful when an organisation believes it has implemented least privilege but has not tested the full path structure of its IAM graph.
Because of that, security testers use it as an attack-path validation tool rather than a compliance checker. It can surface places where a seemingly low-privilege identity can pivot into actions that affect data, infrastructure, logging, or other security-sensitive resources. For a broader view of attack-path mapping and closure, see Identity Attack Paths Guide.
What PMapper is actually helping you test
The core test is whether AWS IAM design behaves as intended under transitive access. That includes role trust policies, permission combinations, and indirect paths that emerge only when multiple identities, roles, or resources are considered together. A single policy may look acceptable in isolation, but the path graph can reveal that it still enables privilege escalation once combined with another reachable permission.
This is why PMapper is most useful during red-team style assessment, privilege review, and cloud security architecture validation. It answers questions such as: can this role reach admin-like capabilities, can this user assume a more powerful role, and does a “temporary” access path actually persist across environments or workloads. In other words, it tests the difference between intended access and effective access.
It is also useful for spotting lateral movement routes inside AWS. If one compromised principal can enumerate or assume another principal’s permissions, the issue is not only over-privilege, but also trust structure. That distinction matters because fixing the wrong layer, for example removing one action but leaving the trust chain intact, can leave the attack path unchanged.
What good testing looks like with PMapper
A useful assessment starts with a current inventory of IAM entities, roles, and trust relationships, then checks which paths reach high-impact actions such as policy changes, credential management, data access, or infrastructure control. The output should be interpreted as a set of candidate abuse paths, not as proof of exploitation. Testers still need to validate whether each path is operationally reachable in the real environment.
That makes least-privilege validation more concrete. Rather than asking whether an identity “should” have broad permissions, you can ask whether the role graph makes those permissions reachable through assumption, inheritance, or chaining. When the answer is yes, remediation usually means tightening trust, separating duties, and reducing the number of roles that can be chained into sensitive actions.
Used well, PMapper helps teams prioritise review effort toward the riskiest access paths instead of reviewing IAM policies one by one. That is especially valuable in accounts with many roles, federated access paths, or legacy permissions that have accumulated over time.
Risk and Threat Considerations
PMapper is aimed at an access problem with real security consequences: hidden privilege escalation paths are often more dangerous than obvious broad permissions, because they survive policy review and become reachable through trust relationships, inherited access, or role chaining.
Failure mechanism: A principal with limited direct permissions can still reach higher-impact actions by assuming another role, combining multiple narrow permissions, or following a transitive path that was not obvious from any single policy.
Impact: An attacker or over-privileged insider can move from a low-value foothold to control-plane actions, data exposure, persistence, or lateral movement across AWS resources, even when the initial account appears constrained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | PMapper exposes chained access and trust paths that enable account or role abuse. |
| Recommendation — Map discovered role-chaining paths to T1098 and review trust relationships for abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | PMapper helps verify whether accounts and roles have only necessary effective access. |
| Recommendation — Audit AWS identities and roles for excess access and remove unnecessary role paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The tool tests whether effective permissions exceed intended least-privilege access. |
| Recommendation — Use AC-6 to reduce reachable privileges and eliminate unnecessary escalation paths. | ||
Practitioner Guidance
What to verify: Treat PMapper findings as path hypotheses and confirm whether the highlighted route is actually usable in your environment, including trust policy conditions, session constraints, and any boundary controls that may block the chain.
Decision rule: If a path reaches sensitive actions through more than one role or trust hop, prioritise breaking the chain over trimming a single permission, because the path can remain exploitable even after a narrow-looking policy cleanup.
Practitioner takeaway: The real test is not whether an IAM policy looks restrictive in isolation, but whether the account still contains a reachable path to high-impact actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org