What permissions does the AWS IAMReadOnlyAccess managed policy grant?

The AWS IAMReadOnlyAccess managed policy grants read-only access to IAM resources and configuration. It allows a principal to inspect users, roles, policies, and related settings without changing them. Use it for review and audit tasks, and avoid granting it where only narrower IAM visibility is needed.

What IAMReadOnlyAccess lets you inspect in AWS

The policy is useful when you need to understand how an AWS identity is configured, who can assume roles, and which policies are attached without granting change capability. It is a visibility policy, not an operational permission set, so the practical question is what evidence you can collect from IAM and how confidently you can trust that view for review work.

That distinction matters because IAM data often drives access reviews, incident triage, and privilege analysis. A read-only policy can reveal the shape of the identity model, but it cannot validate whether permissions are actually used, whether trust relationships are overly broad, or whether adjacent services are also exposing access paths.

Why read-only IAM access still needs careful scoping

Read-only access is safer than write access, but it is still sensitive because IAM metadata can expose the account’s privilege structure, trust relationships, and policy design choices. In practice, that means the main risk is not direct mutation, but intelligence leakage about who can do what, which roles are assumed, and where privilege boundaries are weak.

It is also easy to overgrant this policy when a narrower inspection scope would do. If a reviewer only needs to confirm whether one role has a particular attachment, or whether a specific trust policy exists, broader IAM visibility can create unnecessary exposure without improving the review outcome.

How to use it for audit and investigation work

Use the policy when the task is inspection, documentation, or control validation, especially for access reviews and baseline assessments. A useful way to think about it is that the policy supports inventory and analysis, not administration.

For practitioners who need a broader control model around permissions and review workflows, NHIMG’s AWS IAM Policies and Roles Guide is the natural parent concept. It helps place a read-only policy in the context of evaluation logic, role trust, permission boundaries, and policy analysis.

If your review work extends beyond IAM into effective permissions, right-sizing, or privilege reduction across cloud estates, the Cloud PAM and CIEM Guide is the better companion resource because it focuses on how permissions are assessed and constrained in practice.

For identity lifecycle and governance context, the NHI Lifecycle Management Guide is relevant when the review task includes discovering, classifying, and recertifying non-human access in the cloud.

Risk and Threat Considerations

Read-only IAM access can still be material to an attacker or insider because it exposes how the environment is governed. That visibility can assist privilege mapping, trust-path discovery, and preparation for later escalation, especially when other systems or logs leak enough detail to connect identities to effective permissions.

Failure mechanism: A broad inspection policy gives a principal enough structural visibility to enumerate users, roles, policies, and trust relationships, which can help an adversary identify the best path to higher privilege or persistence.

Impact: The likely consequence is accelerated privilege abuse, better-targeted lateral movement, and weaker confidentiality around your access model, even if no IAM setting is directly changed.

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, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	IAM read access should be limited to the minimum visibility needed for review tasks.
	AU-6 — Audit Record Review, Analysis, and Reporting	Read-only IAM access is commonly used to examine identity state during audit and investigation work.
	IA-5 — Authenticator Management	IAM policies govern how identities and credentials are managed, reviewed, and controlled.
Recommendation — Limit IAM inspection rights to the narrowest role or account scope that still supports the review. Use read-only IAM visibility to support audit review and analysis of identity configuration. Review credential and policy governance whenever IAM visibility exposes identity configuration.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	The policy can be overbroad when narrower IAM visibility would satisfy the task.
	NHI-08 — Environment Isolation	IAM visibility should be constrained across environments to avoid unnecessary cross-account exposure.
	NHI-10 — Human Use of NHI	People using machine or workload access for review must avoid turning broad read access into standing operational access.
Recommendation — Right-size review permissions so principals only see the IAM data they need. Separate review access by environment and account to reduce unnecessary IAM exposure. Keep human review access distinct from operational non-human privileges.
NIST CSF 2.0	PR.AA-05 — Least Privilege	The question is about assigning only read-only IAM permissions needed for a review role.
	ID.AM-01 — Physical devices and systems within the organization are inventoried	IAMReadOnlyAccess supports inventory-style visibility into identity resources and configuration.
Recommendation — Apply least-privilege assignment when granting IAM inspection access. Use inventory-style reviews to confirm which IAM resources a principal can inspect.
OWASP ASVS	V8 — Authorization	The policy is fundamentally about what a principal is allowed to inspect versus change.
Recommendation — Verify authorization boundaries so inspection rights do not become write rights.

Practitioner Guidance

What to verify: Confirm the reviewer actually needs account-wide IAM visibility, not just role, policy, or trust-policy inspection for a narrow object set. If the job is a one-off audit, prefer the smallest scope that still supports the review evidence you must collect.

Decision rule: If the principal will use the policy repeatedly across accounts or environments, treat the policy assignment as part of your access governance review and confirm that it is time-bound, approved, and monitored. If the use case is temporary, pair the access with a clear end date and explicit removal step.

Practitioner takeaway: Treat IAMReadOnlyAccess as a review aid with real visibility value, not as a harmless default, because broad observability into identity structure can still expand exposure if it is granted more widely than the task requires.