Should organisations prioritise identity-level controls or traditional network controls in cloud?

Organisations should prioritise identity-level controls for cloud access decisions because the real question is who can use which service or dataset after authentication. Network controls still matter, but they cannot express enough context for distributed cloud resources. Identity-first security is the more precise control model for modern access governance.

Why Identity-Level Controls Usually Win in Cloud

Cloud access is mediated by identities, tokens, roles, and short-lived credentials, so the most precise control point is usually the identity layer rather than the packet path. That is where organisations decide whether a user, workload, or automation can reach a specific API, dataset, or control plane action. Network controls still add value, but they are typically coarser and less expressive than access decisions tied to authentication and authorization.

Identity-first design becomes especially important when resources are distributed across regions, managed services, and SaaS-like control planes. A perimeter rule can say something is reachable, but it cannot reliably express who is allowed to do what after the session is established. That makes identity the better place to enforce least privilege, conditional access, and time-bounded access.

For cloud workload access, the difference is visible in the control model itself: a service account, role, or federated token is what actually opens the door. The practical guidance in Cloud Workload Identity Guide is useful here because it shows how temporary credentials and workload federation replace static network trust. A network boundary may still reduce exposure, but it is not the primary authority for modern cloud access governance.

Where Traditional Network Controls Still Matter

Network controls are still important for segmentation, attack-surface reduction, and limiting how far a compromise can travel once access is obtained. They are also useful for restricting administrative paths, controlling inbound exposure, and reducing noisy lateral movement opportunities. In other words, they are a strong compensating control, not the main decision engine for cloud authorization.

Their weakness is that cloud resources are often accessed over shared infrastructure and standard service endpoints, so “allowed by network” does not mean “allowed by business context.” A network rule can be blind to user purpose, device trust, workload attestation, or whether the request is coming from an approved automation path. That is why organisations that rely too heavily on network policy often end up with exceptions that quietly erode the model.

Cloud identity guidance such as Ultimate Guide to NHIs, what are Non-Human Identities helps make this distinction concrete: service principals, tokens, and workload identities are the objects that need governance, while network position is only one part of their operating environment. If those identities are overprivileged or long lived, a strong perimeter will not compensate for weak authorization.

What an Identity-First Cloud Model Changes Operationally

Identity-first security changes how teams design access reviews, incident response, and cloud governance. Instead of asking only whether traffic is inside a trusted boundary, teams ask whether the identity is correctly scoped, how the credential was issued, whether the session should still exist, and what resource-level permissions are actually present. That is a more useful model for auditability and for reducing blast radius.

It also changes how organisations handle shared platforms and third-party integrations. A network-centric approach often overgeneralises trust to an entire subnet, VPC, or virtual network. An identity-centric approach can distinguish one workload from another, even when they share the same infrastructure, and can support environment isolation, access review, and credential rotation in a much more targeted way.

When cloud identity is the enforcement point, lifecycle controls become part of the security baseline, not an administrative afterthought. The lifecycle perspective in NHI Lifecycle Management Guide is relevant because provisioning, rotation, offboarding, and recertification all shape whether access remains valid. This is exactly where identity-level controls outperform traditional network controls: they can express who should retain access over time, not just where traffic may flow.

Risk and Threat Considerations

Identity-first cloud designs reduce exposure, but they also concentrate trust in the credential and authorization layer, so compromise there can have outsized impact. If a token, role, or federated path is stolen or over-scoped, an attacker may move directly to the target service without needing to bypass the network boundary first.

Failure mechanism: Excessive permissions, weak lifecycle management, or token theft can let an attacker authenticate legitimately and then abuse allowed service access from a normal-looking network location.

Impact: The result can be silent data access, privilege escalation, and faster lateral movement than a perimeter-centric model would detect.

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, NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Cloud access often depends on service and federated identities.
	AC-6 — Least Privilege	The question is about choosing the better access control model for cloud.
Recommendation — Enforce strong authentication for non-organizational cloud identities and their service-to-service access. Scope cloud permissions to the minimum needed for each identity and workload.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Cloud access decisions should be based on explicit verification, not network location.
Recommendation — Treat every cloud request as untrusted until identity and context are verified.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud governance relies on identity-centric access decisions and lifecycle control.
Recommendation — Prioritise IAM controls for cloud authorization, lifecycle, and privilege management.
ISO/IEC 27001:2022	A.5.15 — Access control	Cloud access governance requires controlled, policy-based access decisions.
Recommendation — Define and enforce access rules that are identity-aware and resource-specific.

Practitioner Guidance

What to prioritise: Use identity-level controls for cloud authorization, then let network controls act as a containment layer. The first question should be whether the identity, role, or token is correctly scoped to the resource and action, not whether the source IP is on an approved path.

What to verify: Confirm that every privileged cloud path is backed by short-lived, individually attributable credentials and that network restrictions are not being used as a substitute for access governance. If a control cannot distinguish one workload from another, it is probably too coarse to be the primary gate.

Common mistake: Treating private networking, IP allowlists, or VPC boundaries as if they were access control. Those controls can reduce exposure, but they do not express least privilege for distributed services, especially where automation and cross-account access are involved.

Practitioner takeaway: In cloud, network controls are best used to narrow exposure, while identity controls should decide authority; if you reverse that order, you usually get a system that is harder to govern and easier to abuse.