How should security teams balance account boundaries, SCPs, and IAM policies?

Why This Matters for Security Teams

Account boundaries, SCPs, and IAM policies only work when each layer has a distinct job. Accounts create the outer blast-radius boundary, SCPs cap what any principal in that account can ever do, and IAM policies decide what a workload can do in the moment. That separation matters because most failures are not caused by one bad policy alone, but by overlapping permissions, delegated admin sprawl, and assumptions that “local” policy mistakes stay local.

The practical risk is over-confidence in inherited controls. Security teams often discover that a well-designed IAM policy still cannot save a badly scoped account model, while a strong SCP cannot compensate for weak role hygiene or poor secret handling. NHIMG research shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a strong signal that layered governance is still being implemented unevenly. For baseline control thinking, NIST Cybersecurity Framework 2.0 remains useful for organising accountability across protect and govern functions.

In practice, many security teams encounter policy drift only after a delegated team has already created permissions that exceed the organisation’s intended ceiling.

How It Works in Practice

The cleanest operating model is to treat accounts as administrative and security boundaries, SCPs as hard guardrails, and IAM policies as task-level authorisation. That means an account should represent a bounded trust domain, such as a product line, environment, or regulatory scope. SCPs then define the maximum permissions allowed in that domain, including explicit denies for risky services, regions, or actions. IAM policies work inside that ceiling to grant the minimum access needed for a role, service, or automation task.

For security teams, the design question is not “where can we allow access?” but “where do we want to make unsafe access impossible?” That is why SCPs are best used to prevent whole classes of mistakes, such as disabling logging, creating overly permissive roles, or using unsupported services. IAM policies should stay narrower and more adaptive, especially for non-human identities that need task-specific access. This approach aligns with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, where least privilege and boundary enforcement are separate design concerns.

• Use the account boundary to separate environments, business units, or risk tiers.
• Use SCPs to block actions that should never be possible in that boundary.
• Use IAM policies to grant only the specific actions a workload or operator needs.
• Review whether delegated admins can still create shadow paths around intended controls.

This layered model becomes especially important for NHIs because credentialed workloads often accumulate permissions faster than human users. NHIMG’s Top 10 NHI Issues highlights how over-privilege, weak lifecycle discipline, and inconsistent governance frequently show up together. These controls tend to break down in large multi-account environments where teams copy role templates across accounts without revalidating SCP exceptions and effective permissions.

Common Variations and Edge Cases

Tighter account and SCP boundaries often increase operational overhead, requiring organisations to balance stronger containment against slower delivery and more complex delegation. That tradeoff is real, especially in cloud estates where platform teams need reusable guardrails but application teams still need autonomy.

Best practice is evolving on how strict SCPs should be for shared-platform accounts and centralised services. In some organisations, overly aggressive SCPs block legitimate automation, monitoring, or incident response. In others, permissive exceptions erode the value of the boundary entirely. The right answer depends on how mature the organisation is at policy-as-code, exception management, and continuous review. Where possible, map account structure to risk ownership first, then apply SCPs to enforce non-negotiable limits, and keep IAM policies as the most flexible layer.

A second edge case is third-party or cross-account access. Here, account boundaries alone do not guarantee safety if federation, role chaining, or service-linked roles create indirect paths around intended constraints. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful when teams need to translate those boundaries into audit evidence and control ownership. In practice, the model fails most often when exceptions become permanent and nobody re-tests the effective permissions after a change in service architecture.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• What do IAM teams get wrong about AI and API security boundaries?
• How should security teams choose user account management software for IAM governance?
• How should security teams balance IAM security with user productivity?