How should IAM and PAM teams work together on AWS standing access?

How IAM and PAM Should Divide the Work on AWS Standing Access

AWS standing access is usually created through roles, policies, and account design, so IAM and PAM teams need a shared operating model rather than separate queues. IAM owns the shape of access, but PAM should decide which roles are truly privileged, which ones need stronger controls, and which ones should be temporary instead of always on. The boundary is practical, not political: privileged cloud roles deserve the same discipline as traditional admin access.

IAM teams should start by mapping what each role can actually do in AWS, then right-size the entitlement to the minimum needed for day-to-day work. PAM teams should review the same roles for high-impact actions such as policy changes, key management, cross-account access, and break-glass capability, because a role can look ordinary while still having privileged blast radius. That is where standing access becomes a governance issue, not just an IAM hygiene issue.

Good collaboration also means agreeing on who owns revocation and time bounds. Cloud PAM and CIEM guidance is useful here because it connects effective permissions, safe right-sizing, and escalation-path review in one operating model. On AWS, that often means IAM manages the role inventory and permission boundaries, while PAM defines which roles require JIT activation, approval, or session oversight before they can be treated as acceptable standing access.

Where Standing Access Blurs the Line Between IAM and PAM

Standing access is the area where cloud administration and privileged access management overlap most. An AWS role can be technically “just IAM” but functionally privileged if it can change security groups, edit trust policies, create access keys, or pass a more powerful role to another principal. Privileged Access Management Guide is a useful reference point because it treats cloud admin roles, zero standing privilege, and break-glass access as part of the same control problem.

That overlap matters because standing access is often what survives after project work ends. IAM teams may see a role as an entitlement issue, while PAM teams see the same role as a privileged pathway that should be brokered, logged, and revocable. The shared question is not whether the role exists, but whether continuous access is justified for the actions it can perform.

The cleanest way to reduce confusion is to classify AWS roles by impact rather than by team ownership. Read-only and low-risk operational roles can remain under IAM stewardship, while roles with policy editing, secret access, root-adjacent recovery, or cross-account control should be treated as privileged regardless of where they sit in the account structure.

What Good Joint Governance Looks Like on AWS

Joint governance works best when IAM and PAM share one review cycle, one inventory, and one exception process. IAM should keep the role catalogue accurate, including trust relationships, policy attachments, and service-linked usage. PAM should define the escalation criteria, approval rules, and revocation expectations for roles that create elevated impact. If those controls live in separate spreadsheets, standing access will drift.

For long-lived roles, the practical control is not only whether access exists, but whether the access is still needed at that standing level. Just-in-Time Access and Zero Standing Privilege Guide is relevant because it frames the preferred end state: eligible access that is activated only when needed, instead of always being permanently available. In AWS, that often means converting persistent admin-style roles into time-bound elevation with explicit review and cleanup.

Teams also need a common language for exceptions. Break-glass roles, emergency recovery paths, and tightly scoped automation roles are not the same as ordinary standing access, but they still need ownership, monitoring, and expiry discipline. When IAM and PAM agree on which exceptions are acceptable, the organization can avoid both over-restriction and unmanaged privilege creep.

Practitioner Guidance

What to prioritise: Start with AWS roles that can change security posture, access secrets, or assume other roles. Those are the roles most likely to benefit from PAM review even if they were originally provisioned as normal IAM access.

Decision rule: If a role can meaningfully widen blast radius or bypass peer review, treat it as privileged access and put it on a revocation and elevation path, not a permanent-access path.

What to verify: Confirm that the role inventory shows both effective permissions and trust relationships, not just assigned policies. A role that looks harmless on paper can still be highly privileged through assume-role chains or cross-account trust.

Common mistake: Letting IAM own provisioning while PAM only covers human admin accounts. In AWS, standing access often sits inside cloud roles, so the control boundary has to follow function, not legacy team labels.

Practitioner takeaway: The goal is to make privileged AWS access reviewable, time-bound where possible, and easy to revoke, even when it is delivered through ordinary IAM constructs.

Related resources from NHI Mgmt Group

• How should PAM, IAM, and NHI teams work together on privileged access?
• How do IAM and network security teams work together on privileged access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?