How do you audit who holds the AWS AmazonSSMReadOnlyAccess managed policy?

What you are actually auditing in AWS

The question is not just “who can read SSM data,” but who is bound to the AmazonSSMReadOnlyAccess managed policy through any path. In AWS, that includes direct attachments to IAM users, groups and roles, plus indirect exposure through inherited group membership and role assumptions. The useful outcome is a complete entitlement picture, not a single policy attachment list.

Start by treating the managed policy as an access-granting object that can travel through multiple identity paths. A role, group, or user attached to the policy may be the visible binding, but the real question is whether that identity is still needed for operational monitoring, troubleshooting, inventory review, or support workflows. If the answer is no, the entitlement should be removed rather than merely documented.

Because this is a managed policy, you should also verify where it is being used across accounts and environments. Shared administration roles, break-glass access paths, and service-linked or automation roles can all create indirect exposure that looks harmless at first glance. Auditing the policy holder means validating the effective permissions of the whole path, not just the named principal.

How to find every principal attached to the policy

The most direct way to audit the policy is to enumerate every principal that references it and then trace inheritance. For IAM users and groups, look for both direct attachments and group-based permissions. For roles, include assumed roles, cross-account roles, and any automation role that inherits the policy as part of a broader permission set.

Use AWS IAM reporting, policy attachment queries, and access analysis to build the list from the policy outward. A clean audit should answer three separate questions: who is directly attached, who inherits through a group or composite role design, and which principals can assume a role that carries the policy. If you stop at direct attachments, you will miss legitimate but hidden exposure.

This is also where you should compare the policy against the job function of each principal. Read-only Systems Manager access may be justified for a small operations team, but it is often over-retained on legacy roles, temporary support access, and dormant automation identities. The audit should therefore end with a necessity check, not just an inventory export.

How to judge whether the assignment is still justified

Once you have the list, validate purpose, scope and recency. The right question is whether the principal still needs visibility into SSM inventory, run command metadata, session-related details, or configuration state. If the answer is historical rather than operational, the policy is probably obsolete for that identity.

Also check whether the access is broader than intended. A principal that only needs one subsystem or one account should not keep a broad managed policy if a tighter custom policy can do the job. The same applies when multiple principals have inherited the policy through the same group simply because the group was once convenient for administration.

Keep an eye on whether the policy is compensating for weak role design elsewhere. If teams are relying on a read-only managed policy as a substitute for better scoping, temporary elevation, or clearer ownership, the entitlement will tend to spread. That pattern usually signals a governance problem, not just an access-review problem.

Risk and Threat Considerations

Read-only SSM permissions still expose operational intelligence, and that information can help an attacker map hosts, spot naming conventions, identify patching gaps, or understand how systems are managed. A policy that seems low risk on paper can still support recon, privilege planning, and target selection.

Failure mechanism: The entitlement remains attached to users, groups, or roles after the operational need has ended, or it propagates through inherited memberships and assumed roles that were never re-reviewed. That creates quiet overexposure across identities that can still authenticate successfully.

Impact: An attacker or insider with access to one of those principals can collect environment metadata, improve lateral movement planning, and learn which systems are worth targeting next. Even without write access, the visibility itself can materially reduce defender uncertainty.

Framework alignment

AWS IAM Policies and Roles Guide supports the attachment and inheritance logic behind tracing which users, groups and roles hold a managed policy.

Ultimate Guide to NHIs, Regulatory and Audit Perspectives supports the audit-review lens for access justification and entitlement recertification.

Cloud Workload Identity Guide supports checking whether roles and automation identities inherit access paths that were not obvious in the original policy view.

SOC 2 Trust Services Criteria (AICPA) supports reviewing access assignments as part of controlled, evidence-backed entitlement governance.

NIST SP 800-53 Rev 5 Security and Privacy Controls supports formal access review and least-privilege control expectations for AWS permissions.

Practitioner Guidance

What to verify: Confirm effective permissions, not just explicit policy attachments. The audit is incomplete until you have checked group inheritance, role assumption paths, and any automation or service-linked identities that inherit the policy indirectly.

Decision rule: If the principal does not need operational visibility into SSM data today, remove the policy and replace it with a narrower permission set only where a documented use case remains. If the principal is shared, temporary, or legacy, treat the justification threshold as higher, not lower.

Practitioner takeaway: The key control is entitlement hygiene, because read-only access is still meaningful access when it reveals enough about your environment to help someone plan the next step.

Related resources from NHI Mgmt Group

• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• How do you audit who holds the AWS AmazonDynamoDBReadOnlyAccess managed policy?
• How do you audit who holds the AWS AmazonEKSClusterPolicy managed policy?
• How do you audit who holds the AWS IAMAccessAnalyzerReadOnlyAccess managed policy?