When should teams use SCPs instead of permission boundaries?

When SCPs and permission boundaries solve different problems

SCPs and permission boundaries both constrain AWS permissions, but they operate at different layers of control. SCPs define the outer guardrails for accounts in an AWS Organization, while permission boundaries limit what an individual IAM role or user can ever receive, even if a policy is attached later. The right choice depends on whether you need organisational guardrails or delegated administration.

That distinction matters because both controls are preventive, but they answer different governance questions. SCPs are useful when central security or platform teams need to set a hard ceiling across many accounts. Permission boundaries are better when you want teams to self-serve within a safe envelope, especially for role creation and delegated IAM administration.

Where SCPs are the stronger control

Use SCPs when the main concern is organisational consistency, shared risk reduction, or blocking entire classes of permissions across accounts. They are especially useful for preventing risky actions from being granted anywhere in a member account, even if local administrators try to broaden access. That makes them a better fit for baseline restrictions such as denying sensitive regions, blocking dangerous services, or enforcing global least privilege.

SCPs also work better when you need one control plane for many accounts rather than a per-role control. If the risk is that a single account owner could create broad access paths that violate enterprise guardrails, an SCP is the stronger boundary because it constrains what any principal in that account can ever exercise. For cloud privilege design and escalation paths, NHIMG’s Cloud PAM and CIEM Guide and Just-in-Time Access and Zero Standing Privilege Guide are useful references for thinking about blast radius and standing privilege.

Where permission boundaries are the better fit

Use permission boundaries when the problem is delegated creation or administration of IAM roles and you want to stop that delegated activity from exceeding a predefined ceiling. They are a practical control for platform teams that need to let application or account teams create roles, attach policies, or operate with some autonomy without giving them unrestricted authority. The boundary acts as a maximum permission set, even if identity policies would otherwise allow more.

That makes permission boundaries especially valuable in self-service environments. They help preserve separation between what teams can manage and what those teams can actually use. In practice, they are most effective when paired with role templates, approval workflows, and clear ownership of who can modify the boundary itself. NHIMG’s Authorisation Models Guide and Privileged Access Management Guide are helpful for framing delegated access as a privilege ceiling problem rather than a blanket permissions problem.

How to choose in practice

If the requirement is “no one in this organisation should ever be able to do X,” start with an SCP. If the requirement is “a team may create or manage roles, but those roles must never exceed Y,” start with a permission boundary. SCPs are the better control for organisation-wide denial and standardisation; permission boundaries are the better control for constrained delegation.

The common mistake is treating them as interchangeable layers. They are often complementary: an SCP can set the outer guardrail, while a permission boundary limits what delegated administrators can build inside that guardrail. When the subject is overprivilege, the cleanest design is usually to combine broad organisational restraint with narrower delegated ceilings rather than relying on one control to do both jobs.

Practitioner Guidance

What to prioritise: Decide first whether the risk is “too much power anywhere in the organisation” or “too much power in delegated role creation.” That choice determines whether the control should sit at the account boundary or the identity boundary.

What to verify: Confirm who can edit the SCPs, who can edit the boundary policy, and whether the delegated team can still reach the effective permissions you intended after policy evaluation. Test a realistic role creation path, not just the policy document in isolation.

Common mistake: Teams often use permission boundaries to solve an organisation-wide governance problem, or they use SCPs to manage day-to-day delegated administration. Both patterns leave gaps, either by over-restricting operations or by allowing local privilege growth inside an account.

Practitioner takeaway: Use SCPs for top-down guardrails that apply across many accounts, and permission boundaries when the security objective is to let teams delegate IAM work without letting those delegated permissions escape a defined ceiling.

Related resources from NHI Mgmt Group

• How should security teams use IAST and RASP in NHI governance?
• Why do permission boundaries and SCPs reduce risk even when application teams write their own IAM policies?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?