How do you audit who holds the AWS AmazonSSMManagedInstanceCore Managed Policy?

You audit who holds the AWS AmazonSSMManagedInstanceCore Managed Policy by identifying every instance profile or role attached to it and then confirming which managed instances use those roles. Review the scope of access those instances need and remove attachments from systems that no longer use AWS Systems Manager. Also check whether the permissions are broader than the operational task requires.

What “audit who holds it” means for an AWS managed policy

For a managed policy like AmazonSSMManagedInstanceCore, the audit is really an attachment and usage review. Start by identifying every role or instance profile that has the policy attached, then map those roles to the EC2 instances or managed nodes that actually assume them. That tells you who can use Systems Manager capabilities through that policy and where the access is still operationally justified.

The practical question is not just “who has it?” but “which running systems still need it?” Some attachments are legitimate because the instance is enrolled in Systems Manager and depends on the policy for core operations. Others are leftovers from old fleets, test builds, or migrated workloads. The audit should separate current operational need from stale attachment.

Because this is an IAM control question, the useful evidence is in the relationship chain: policy to role, role to instance profile, instance profile to instance. If that chain is incomplete, you cannot be sure the policy is still needed or that it is not attached more broadly than intended. That is why the direct answer focuses on inventorying attachments and then validating actual managed-instance usage rather than stopping at the policy document alone.

How to interpret the results of the attachment review

Once you have the list of attached roles, review each instance against its operating purpose. If a system no longer uses AWS Systems Manager, the policy should usually be removed after confirming there is no dependent automation, patching, inventory, or session workflow still relying on it. If the instance does use Systems Manager, confirm whether the policy is sufficient for that role and not a convenient catch-all for unrelated access.

The attachment review is also a scope review. Managed policies are often reused because they are easy to apply, but that convenience can hide privilege creep. A role that only needs basic Systems Manager functionality should not accumulate extra permissions just because it was created for an older deployment pattern. Keep the policy attached only where the operational task still depends on it.

For teams running mixed fleets, include launch templates, Auto Scaling groups, and image-based rollouts in the review. A policy can persist through the role attached at launch even when the original instance has been terminated. That makes stale infrastructure and stale identity attachments the same audit problem, not separate ones.

What to do when the policy is still attached but the instance no longer needs it

Remove the attachment from the role or instance profile after confirming the instance is not using Systems Manager features. Then validate that the system still operates normally without the policy, because some teams discover hidden dependencies only after access is withdrawn. If a workload breaks, that usually means the operational dependency was undocumented and should be corrected before the policy is reattached.

When a role still needs Systems Manager, prefer tightening the surrounding permissions instead of widening the policy’s use. The policy should support the instance’s real management function, not become a permanent standing permission for every server in the account. This is especially important where roles are reused across environments or copied from golden images.

In larger environments, pair the audit with periodic recertification of role attachments. That makes it easier to remove access when instances are decommissioned, repurposed, or moved to another management pattern. It also helps you spot cases where the policy is attached to systems that were never intended to be managed by Systems Manager in the first place.

Risk and Threat Considerations

Unused or overbroad attachments increase the blast radius of a compromised instance role. If an attacker reaches a system that still carries this policy unnecessarily, they may gain a cleaner path to Systems Manager functions than the workload actually requires. That can turn an overlooked attachment into an avoidable access path.

Failure mechanism: The policy remains attached after the instance is no longer managed through Systems Manager, or it is attached through a reused role that serves multiple systems with different needs. That leaves standing access in place even when the business justification has disappeared.

Impact: You keep unnecessary operational authority alive on systems that no longer need it, which increases privilege exposure, complicates incident response, and makes it harder to prove that access is still least privilege. In a compromise, that extra access can also expand what an attacker can do from the affected role.

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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Roles attached to instances are access relationships that need inventory and review.
	IA-5 — Authenticator Management	Managed-policy access rides on credentials and role lifecycle, which must be governed.
	AU-6 — Audit Record Review, Analysis, and Reporting	Auditing who holds the policy depends on reviewing attachment and usage evidence.
Recommendation — Review and remove stale role attachments from systems that no longer need Systems Manager access. Rotate or retire role credentials and trust paths when a managed instance is decommissioned. Correlate role attachments with instance usage evidence to confirm who actually holds the policy.
CIS Controls v8	CIS-5 — Account Management	This audit is fundamentally about identifying and removing unnecessary access paths.
Recommendation — Inventory and remove stale policy attachments from roles that no longer need them.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Managed-instance roles can become overprivileged when policy scope exceeds operational need.
	NHI-01 — Improper Offboarding	Decommissioned instances should not retain managed-policy attachments.
Recommendation — Reduce policy scope where the attached role grants more access than the workload requires. Remove the policy from decommissioned instances and retired roles during offboarding.

Practitioner Guidance

What to verify: For each attached role, confirm both the attached policy and the actual managed-instance population using that role. If a role is shared across multiple instances, verify every consumer before removing anything, because one legitimate user of the role can mask several stale ones.

What to prioritise: Prioritise removal from decommissioned, test, and copied image roles first. Those are the places where stale managed-policy attachments usually persist longest and create the least visible exposure.

Practitioner takeaway: Treat this as a living attachment inventory, not a one-time policy check, because the real risk comes from policy reuse and stale role-to-instance relationships.