Privileged access review is the highest-stakes category of access governance, and AWS admin paths are consistently where it breaks down — not because teams don't care, but because effective permission in a multi-account AWS organization is genuinely hard to see without purpose-built tooling.
Why AWS Privileged Access Is Different From SaaS Admin Review
Reviewing "who's an admin in Salesforce" is straightforward — the platform has one clear admin role and a UI that lists exactly who holds it. AWS privileged access doesn't work that way. A principal's effective permission is the product of:
- Directly attached IAM policies
- Group membership and the policies attached to those groups
- Role assumption chains — a user assuming Role A, which trusts and can assume Role B in another account
- Resource-based policies (S3 bucket policies, KMS key policies) that grant access independent of the principal's own IAM policies
- Service control policies (SCPs) at the AWS Organizations level that can restrict — but also sometimes unexpectedly permit — actions across the whole org
Reviewing only the first-hop IAM policy attached to a user misses the real risk sitting in a role chain two or three hops deep.
Resolving Effective Permissions, Not Just Attached Policies
The core engineering problem is building an accurate effective-permission graph across accounts, not just querying each account's IAM API in isolation:
def resolve_effective_admin_paths(org_accounts: list[str]) -> list[AdminPath]:
admin_paths = []
for account_id in org_accounts:
iam = get_iam_client(account_id)
roles = iam.list_roles()["Roles"]
for role in roles:
trust_policy = role["AssumeRolePolicyDocument"]
assumable_by = extract_trusted_principals(trust_policy)
if has_admin_equivalent_policy(role, iam):
admin_paths.append(AdminPath(
account_id=account_id,
role_name=role["RoleName"],
reachable_from=assumable_by,
last_assumed=get_cloudtrail_last_assume(role["RoleName"]),
))
return admin_paths
This produces a graph of every account-to-account admin path in the organization — the data an auditor or security lead actually needs to answer "who can ultimately reach production admin in Account X," which a per-account IAM console view can't answer on its own.
Break-Glass and Emergency Access Accounts
Most mature AWS organizations maintain break-glass credentials for emergency access when normal federated auth is unavailable. These accounts are exactly the kind of standing, rarely-used privileged access that auditors focus review attention on — and the review evidence needs to show not just that the account exists and is documented, but that its usage (ideally zero, outside genuine emergencies) is monitored via CloudTrail and alerts on any access event.
Cross-Account Admin Risk in Multi-Account Organizations
Organizations using AWS Organizations with multiple member accounts face a specific risk: a role trusted across accounts for legitimate operational reasons (a shared CI/CD deployment role, a centralized logging role) can become an unreviewed privilege escalation path if its trust policy is broader than intended. Reviewing privileged access at the organization level — not account by account — is the only way to catch this class of risk.
Building the Review Cadence Around Actual Usage, Not Just Existence
A privileged role that exists but hasn't been assumed in six months is a different risk profile than one exercised daily — both need review, but the review question differs: "should this even still exist" versus "is this being used as intended." Pulling last-assumed timestamps from CloudTrail into the review evidence lets reviewers make that distinction instead of treating every privileged path identically.
Frequently Asked Questions
How do you handle SCPs when resolving effective permissions?
Service control policies are evaluated as a ceiling on what's possible within an account, so the resolution logic checks the applicable SCPs at each level of the OU hierarchy alongside the role's own attached policies — an SCP denial overrides an otherwise-permissive IAM policy, and the review evidence should reflect the actual resulting effective permission, not just the IAM policy in isolation.
What's the difference between privileged access review and standard user access review?
Privileged access review focuses specifically on admin-equivalent, cross-account, and break-glass access paths, typically reviewed on a shorter cadence and with stricter escalation requirements than standard application-level access, given the higher blast radius of privileged credentials.
Can this integrate with AWS IAM Identity Center (formerly SSO)?
Yes — for organizations using IAM Identity Center, the effective-permission resolution incorporates permission set assignments across accounts as part of the same graph, since Identity Center is itself a layer that grants federated role access across the organization.
How often should privileged AWS access be reviewed?
Quarterly is a common baseline for standard privileged roles, but genuinely high-risk paths (organization management account admin, break-glass credentials) often warrant more frequent review or continuous usage monitoring with alerting rather than relying solely on a periodic manual review.
Does this help satisfy CC6.3 evidence requirements specifically?
Yes — CC6.3 focuses on the timely removal of access when no longer needed, and the ability to show a resolved, accurate privileged access inventory with usage data directly supports that control's evidence requirements for privileged and admin-level access specifically.
Talk to us about your credential elimination pilot → rutagon.com/contact or call 907-841-8407.