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

Use a customer-managed policy that grants only the required Systems Manager actions for the exact instances, documents and tasks involved. Avoid full access, because SSM can be used to run commands, change state and reach managed hosts. Limit both the action set and the resource scope to reduce the impact of credential compromise.

Why the replacement should be a customer-managed, scope-limited policy

The right substitute is a customer-managed policy that is built around the exact Systems Manager workflows you actually need, not a broad managed policy that can reach every supported action. That matters because least privilege is not only about reducing the action list, it is also about limiting which instances, documents, and tasks the role can affect. When the policy is narrowly defined, credential compromise is less likely to become full SSM control.

For AWS IAM design, the difference is practical rather than theoretical: a managed policy is convenient for broad enablement, while a customer-managed policy lets you align permissions to a specific operating model. That is the right pattern when you need one role for patching, another for run command, and a different scope for maintenance tasks. It also keeps future changes explicit, instead of inheriting new capabilities silently as the managed policy evolves. See the AWS IAM Policies and Roles Guide for the policy evaluation logic behind that choice.

Least privilege here should be read as both action scoping and resource scoping. A policy that allows only the Systems Manager actions required for the job, and only against the intended instances or documents, is much safer than one that can start sessions, send commands, and manage state across an entire fleet. For a broader access-governance view, the IAM and IGA Basics guide explains why entitlement scope and reviewability matter as much as the permission model itself.

How to shape the policy so it stays least privilege

Build the policy from the task outward. Start with the one or two Systems Manager capabilities the role truly needs, then constrain the resources those actions can target. If the role only needs to run a command on a known fleet, do not grant unrelated document management or broad instance control. If it only needs to use a specific document, allow that document rather than every document in the account. That is the difference between a usable control and a paper restriction.

Use conditions and segmentation where they reduce blast radius. In practice, that often means separating admin workflows, automation workflows, and break-glass workflows instead of reusing one high-power role everywhere. It is also a good place to apply role separation for human operators versus automation, because the right scope for an interactive maintenance role is usually not the same as the right scope for a scheduled task or pipeline. The Privileged Access Management Guide is the best fit when you need to decide where time-bound elevation, session controls, or standing privilege removal belong.

If the permission set is growing because teams keep adding exceptions, treat that as a design smell. In that case, the issue is usually not a missing action but a too-broad role boundary, a weak ownership model, or an attempt to make one role serve too many systems. Rework the permissions around a smaller trust boundary instead of expanding the policy until it mirrors the managed policy you were trying to avoid.

What to check before you replace the managed policy in production

Before switching, verify the actual Systems Manager use cases, the target resources, and the escape hatches. Many teams discover that they need only a subset of the actions they thought were required, or that a document can be restricted to a tagged resource set instead of the whole environment. Confirm who owns the role, who approves new actions, and which maintenance paths are exempt only by exception. That gives you a defensible baseline when auditors or incident responders ask why the role was granted.

Review the replacement through the same lens you would use for any privileged cloud permission: if a stolen credential could use it to execute commands or change host state, treat that permission as materially sensitive. The policy should therefore be tested with the principle of explicit deny where appropriate, and with a clear understanding of how role assumption, session duration, and document access interact. The Cloud PAM and CIEM Guide is useful when you need to right-size cloud permissions rather than merely replace one broad policy with another.

Keep the review evidence because the operational risk is not just overpermission, it is also drift. A custom policy that is correctly scoped at launch can become too broad if new documents, instances, or automation paths are attached later without a fresh access review. That is why the review process matters as much as the initial authoring.

Risk and Threat Considerations

A broad Systems Manager policy increases the blast radius of credential theft or role misuse. If an attacker or an overly empowered operator can use the same role to reach many hosts, they can move from a single compromised credential to remote command execution, configuration change, or persistence on managed instances.

Failure mechanism: Overbroad SSM permissions combine high-value actions with weak resource scoping, so one compromised role can affect more systems than the business intended.

Impact: The result can be fleet-wide command execution, unauthorized state changes, expanded lateral movement opportunities, and a harder incident response because the same role can touch many hosts and documents.

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, OWASP ASVS 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 issue in replacing a broad SSM policy.
	IA-5 — Authenticator Management	Managed policy replacement changes the impact of credential exposure and role misuse.
Recommendation — Restrict SSM permissions to the minimum actions and resources the workflow needs. Rotate and tightly manage credentials that can assume the SSM role.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is about constraining access to only required Systems Manager actions and resources.
	A.8.2 — Privileged access rights	Broad SSM access behaves like privileged access and should be tightly assigned and reviewed.
Recommendation — Define and enforce access rules that limit SSM permissions to approved use cases. Review and limit privileged SSM access paths to the smallest necessary set.
OWASP ASVS	V8 — Authorization	The answer hinges on scope-limited authorization rather than broad allowed actions.
Recommendation — Verify that each SSM action is authorized only for the intended resources and tasks.
CIS Controls v8	CIS-6 — Access Control Management	Replacing a full-access managed policy is an access-control hardening task.
Recommendation — Remove broad SSM access and provision only task-specific permissions.

Practitioner Guidance

What to prioritise: Start by identifying the smallest real SSM permission set for each job type, then separate interactive administration from automation. The common mistake is to build one reusable “admin” role and hope future conditions will compensate for the excess access.

What to verify: Test the replacement role against the exact documents, instances, and task flows it must support, then confirm it cannot be repurposed for unrelated host management. If the test role can do more than the workflow requires, the policy is still too broad.

Practitioner takeaway: Least privilege for Systems Manager is achieved when the policy is narrow enough that a stolen credential exposes only the intended maintenance path, not the whole host management surface.