SCP

Service control policy is a guardrail used in AWS to limit what accounts and identities can do, even when local permissions exist. It acts as a preventative boundary at the organisation or account level. Security teams use it to block risky services and contain permission creep across cloud environments.

Expanded Definition

SCP, or service control policy, is a preventative governance control in AWS Organizations that constrains the maximum permissions available to accounts, OUs, and identities. It does not grant access by itself; instead, it sets a boundary that local IAM policies cannot exceed. In NHI security, SCPs matter because many machine identities inherit broad capabilities from roles, automation pipelines, and federated trust paths, so a central deny boundary helps limit blast radius.

Definitions vary slightly across vendors and cloud platforms, but the practical pattern is consistent: use SCPs to enforce non-negotiable guardrails such as blocking risky services, restricting regions, and preventing privilege escalation. AWS documents the mechanics through its service control policy model, while NIST’s NIST Cybersecurity Framework 2.0 frames the broader need for policy-enforced access governance and least privilege.

The most common misapplication is treating SCPs as a substitute for IAM design, which occurs when teams assume a deny guardrail will compensate for overly permissive roles or unmanaged service accounts.

Examples and Use Cases

Implementing SCPs rigorously often introduces operational friction, requiring organisations to weigh stronger containment against the need for controlled exception handling and workload mobility.

• Blocking creation of long-lived access keys in production accounts so automation must use approved role-based flows instead of ad hoc credential sprawl.
• Denying high-risk services, such as unmanaged remote administration or unsupported compute products, to reduce attack surface for NHIs and agent workloads.
• Restricting actions outside approved regions to prevent compromised identities from moving laterally into shadow environments.
• Pairing SCPs with Ultimate Guide to NHIs guidance on lifecycle governance so service accounts, API keys, and automation roles cannot outlive their intended scope.
• Using SCPs as a control layer above IAM and federation policies when multiple teams manage distinct accounts but must still obey one security baseline.

In practice, SCPs are most effective when they are written from observed NHI behaviors, not from abstract policy ideals. That means aligning them with known service dependencies, deployment pipelines, and federation paths, then validating them against change-management workflows and identity telemetry.

Why It Matters in NHI Security

SCPs are important because NHIs frequently accumulate permissions faster than human identities, especially in automated build, deploy, and integration paths. NHIMG reports that 97% of NHIs carry excessive privileges, which means a single mis-scoped role or token can become a broad compromise path if no boundary control exists. SCPs help prevent that by ensuring even privileged local policies cannot exceed centrally approved guardrails.

This matters most in cloud estates where service accounts are difficult to inventory and secrets often persist longer than intended. NHIMG also reports that only 5.7% of organisations have full visibility into their service accounts, so policy enforcement becomes a compensating control when discovery is incomplete. That is particularly relevant for preventing unapproved services, excessive administrative access, and account-level drift across accounts and OUs.

For practitioners, the lesson is that SCPs are not just compliance paperwork. They are a containment mechanism that becomes indispensable after a role is over-permissioned, a secret is exposed, or a deployment pipeline begins to create identities faster than governance can review them.

Related resources from NHI Mgmt Group

• How do organisations know whether an SCP will break production?