They can limit identity actions but still leave resources reachable through permissive bucket, key, or queue policies. That creates a gap between what an identity can do and what a resource will accept, which is exactly where cloud exposure often hides.
Why This Matters for Security Teams
SCPs can narrow what an identity is allowed to request, but they do not automatically control what a bucket, key, or queue will accept. In cloud environments, that distinction matters because resource-based policies can still expose data or permit actions even when identity permissions look tight. NIST’s Cybersecurity Framework 2.0 treats access control as a system property, not an IAM checkbox.
That is why NHI governance has to include both sides of the authorization boundary. NHIMG’s Top 10 NHI Issues and Regulatory and Audit Perspectives both stress that visibility and control failures often appear only after a resource policy has already created unintended reach. In practice, many security teams encounter cross-account exposure only after a storage policy, queue policy, or key policy has already bypassed the restrictions they thought SCPs enforced.
How It Works in Practice
SCPs are guardrails at the organisation or account boundary. They are useful for preventing broad classes of actions, but they do not replace resource control. If a resource policy grants access to a principal, a service, or a wider trust boundary, the resource may still accept requests unless the resource policy is also constrained. That is why a secure design needs layered control: organisational guardrails, identity permissions, and explicit resource-side policy review.
In operational terms, teams should inspect the complete authorization path for every sensitive service:
- Check what the identity can request through IAM or workload permissions.
- Check what the resource will accept through bucket, queue, key, topic, or secret policies.
- Validate whether cross-account principals, wildcard conditions, or service principals create unintended paths.
- Confirm that deny statements and boundaries are present on both the identity and resource sides where supported.
This is especially important for NHI estates because credentials are often over-permissioned, long-lived, and hard to inventory. NHIMG’s Lifecycle Processes for Managing NHIs notes that lifecycle control and revocation discipline are central to reducing exposure, while the NIST CF 2.0 resource at NIST Cybersecurity Framework 2.0 reinforces governance and continuous monitoring as core practices. The practical takeaway is simple: if the resource policy is permissive, SCPs cannot prevent a misconfigured bucket, key, or queue from remaining reachable. These controls tend to break down when teams assume organisation-level denial automatically overrides resource-level allow rules in multi-account environments.
Common Variations and Edge Cases
Tighter SCPs often increase administrative overhead, requiring organisations to balance central control against service-team autonomy. That tradeoff becomes visible in environments with many shared services, delegated admin models, or third-party integrations, where teams may intentionally grant resource access that SCPs were never designed to model.
There is no universal standard for this yet, but current guidance suggests treating SCPs as one control plane and resource policies as another. Edge cases include S3 bucket policies that allow public or cross-account access, KMS key policies that grant decryption independently of IAM intent, and queue or topic policies that expose message ingestion paths even when identity permissions are restricted. NHIMG’s Standards guidance and the Regulatory and Audit Perspectives section both point toward evidence-based policy review, not assumption-based assurance.
The main exception is when a service does not support strong resource-side policy semantics or when a legacy application uses embedded trust shortcuts. In those cases, organisations should compensate with explicit deny patterns, tighter segmentation, and continuous policy analysis rather than assuming SCP coverage is enough.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Misaligned identity and resource permissions are a core NHI access-control risk. |
| NIST CSF 2.0 | PR.AC-4 | Access control must cover both identity and resource authorization boundaries. |
| NIST AI RMF | Governance and risk management apply when cloud policy gaps expose autonomous workloads. |
Map each sensitive resource to the full authorization chain and enforce least privilege at every layer.
