What should be used instead of the AWS IAMReadOnlyAccess managed policy for least privilege?

Use a custom read-only policy limited to the IAM objects and actions the role actually needs to inspect. IAMReadOnlyAccess exposes broad visibility across IAM configuration, which is often more than a support or audit role requires. Prefer tightly scoped read permissions, and separate audit access from administrative access.

Why a custom read-only IAM policy is the better least-privilege pattern

A managed read-only policy is convenient, but convenience is not the same as least privilege. For roles that only need to inspect a narrow slice of IAM state, a custom policy lets you permit just the read actions and resource scope that job actually requires. That reduces unnecessary visibility into broader identity configuration and keeps audit, support, and troubleshooting roles bounded to their real task.

That matters because IAM permissions are not just about access to data, they also shape what an operator can learn about roles, trust policies, policy relationships, and account structure. A broad read-only policy can reveal far more than the role needs to function. An AWS IAM Policies and Roles Guide is useful background when you are deciding whether to use identity-based policies, permissions boundaries, or role trust constraints as part of that scoping.

In practice, the right replacement is usually a custom policy tailored to the exact inspection workflow: view only the required IAM objects, limit access to the minimum set of actions, and keep administrative changes on a separate path. That separation is especially important when audit work must stay read-only while admin duties remain tightly controlled. The broader the read surface, the easier it is for a diagnostic role to become a reconnaissance role.

What the custom policy should include and exclude

Start from the questions the role must answer, not from the full IAM console experience. If the role only needs to verify whether a user, role, or policy exists, it should not automatically inherit the ability to enumerate every policy relationship or inspect unrelated configuration. The policy should reflect the exact IAM objects involved, such as the specific users, roles, groups, policies, and trust relationships the role is responsible for reviewing.

That same discipline applies to actions. Read-only does not mean “read everything.” A tightly scoped policy should include only the AWS API actions needed for inspection, reporting, or validation, and nothing that expands into write, attach, detach, or privilege-management workflows. The goal is to make the policy useful enough for the task while eliminating unnecessary discovery of unrelated identities, permissions, and delegation paths.

If the role is used for periodic review, treat scope creep as a policy design defect, not as an operational shortcut. A well-scoped custom policy can be revised as the audit workflow changes, but it should always be anchored to an explicit business need. Where teams are building a broader identity governance practice, IAM and IGA Basics provides the governance context for separating provisioning, access review, and entitlement oversight.

How to keep read-only access from becoming excess visibility

Least privilege is not only about preventing edits, it is also about limiting unnecessary knowledge. In IAM, visibility itself can be sensitive because it exposes how privileges are assembled, where trust is granted, and which identities are powerful enough to matter. A custom policy should therefore be treated as part of an access design, not just a convenience layer for support staff.

For that reason, separate inspection duties from administrative duties wherever possible. A support role that can confirm configuration state should not automatically inherit the same visibility as the team that designs or changes the policy model. If you need a broader operational view for a small number of responders, use an exception path with clear ownership and expiry rather than making the everyday role broader by default. The same principle is central to Privileged Access Management Guide, especially where standing access should be replaced with bounded review and just-in-time access.

That mindset also makes reviews easier. When a custom policy is narrow, access recertification becomes a check on necessity rather than a debate about why the role can see so much in the first place. If the task changes, the policy can be adjusted; if it does not, the privilege should stay narrow.

Risk and Threat Considerations

Overbroad read access is a common precursor to privilege escalation planning, lateral reconnaissance, and mistaken trust in “harmless” diagnostic roles. In IAM, a read-only policy can still expose enough structure to help an attacker understand where the real privileges sit, which trust paths exist, and which identities are worth targeting next.

Failure mechanism: A generic read-only managed policy grants visibility across IAM objects that the role does not actually need, allowing unnecessary discovery of trust relationships, privilege structure, and identity inventory.

Impact: The role gains a larger reconnaissance surface than intended, which can increase blast radius if the account is compromised and can also normalize excessive visibility inside routine operations.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Least-privilege scoping is the core decision behind replacing broad read access.
	AC-3 — Access Enforcement	Custom policies enforce the exact read boundary instead of a broad managed policy.
	IA-5 — Authenticator Management	Read-only IAM exposure often intersects with credential and account governance.
Recommendation — Restrict IAM read permissions to the minimum actions and resources the role needs. Enforce role access with a narrowly tailored policy instead of a generic read-only grant. Review the accounts and credentials that can inspect IAM, and remove unnecessary access paths.
CIS Controls v8	CIS-6 — Access Control Management	The question is about tightening access rights for a specific role.
Recommendation — Define and maintain role permissions at the smallest practical scope.
ISO/IEC 27001:2022	A.5.15 — Access control	A custom IAM policy is an access-control implementation choice for least privilege.
Recommendation — Apply access control rules that limit read access to the needed IAM objects and actions.

Practitioner Guidance

What to verify: Define the exact IAM objects and read actions the role must inspect, then confirm the policy does not permit broader enumeration than the workflow requires. If the role cannot explain why it needs a given IAM view, remove that view.

Decision rule: If a role is only validating configuration or producing an audit result, prefer a custom read-only policy; if it also needs to administer access, split those duties and use a separate privileged path.

Practitioner takeaway: The safest default is not “read-only for everything,” it is “read only what this job truly needs,” because in IAM, excess visibility is often excess privilege in disguise.