Cloud network security is now an identity problem, not a perimeter one

At a glance

What this is: Cloud network security is now framed as an identity and control problem, with SecurityScorecard arguing that perimeter assumptions fail across distributed cloud environments.

Why it matters: For IAM, NHI, and cloud security teams, the practical issue is that access control, verification, and visibility have to replace implicit network trust across every cloud boundary.

Context

Cloud network security is the set of controls that governs who and what can reach cloud resources, but that model breaks when the environment is distributed across public cloud, private cloud, hybrid cloud, and third-party services. The article argues that the perimeter no longer provides a reliable boundary, so the governance problem shifts to identity, segmentation, and continuous monitoring.

The shared responsibility model is where many programmes fail in practice. Cloud providers secure the underlying infrastructure, while customers remain responsible for identity management, configuration, traffic visibility, and access policy inside the environment. That makes cloud network security a control design problem, not a simple infrastructure problem, and the identity angle is genuine because every network decision now depends on proving who or what is asking for access.

Key questions

Q: What breaks when cloud security is still built around a fixed network perimeter?

A: A fixed perimeter breaks down when workloads, data, and applications move across hybrid and multi-cloud environments. Security teams lose coverage during transit, temporary storage, and rapid scaling events, which creates blind spots for attacks and policy drift. The result is inconsistent protection, weaker visibility into communication paths, and a higher chance that cloud activity escapes traditional controls.

Q: Why does the shared responsibility model reduce security gaps in cloud environments?

A: The model reduces gaps because it forces explicit ownership for every part of cloud security. Without that split, teams assume someone else is monitoring a control, which leaves exposures in identity, data, or configuration management. When both sides understand their scope, organisations get better coverage, faster detection, and fewer blind spots across infrastructure, applications, and user access.

Q: How do teams know if cloud segmentation is actually working?

A: Segmentation is working when a compromised workload cannot reach adjacent services, data stores, or admin paths without a deliberate policy exception. Measure whether east-west connections are explicitly approved, whether sensitive services sit in smaller trust zones, and whether tests confirm that blocked paths stay blocked during runtime changes. If lateral movement is still possible, segmentation is only documented, not enforced.

Q: How should security teams govern machine identities in cloud environments with shared responsibility models?

A: Security teams should treat machine identities as first-class identities, not secondary technical artifacts. That means applying governance, access review, lifecycle controls, and privileged access discipline to service accounts, API keys, bots, and workload identities. Cloud shared responsibility does not remove customer accountability for identity sprawl, over-privilege, or unmanaged access paths. Behavioral and anomaly-based analytics help spot misuse that static controls can miss.

Technical breakdown

Why the cloud perimeter model fails

Traditional network security assumed a definable boundary, with firewalls and physical control points separating trusted internal traffic from external traffic. In cloud environments, workloads move, services are ephemeral, and traffic crosses environments that the customer does not physically own. That makes perimeter-based trust brittle because the control point is no longer the network edge, but the identity and policy attached to each request. The security model has to follow the workload and the user, not the location.

Practical implication: Treat network location as an unreliable trust signal and move enforcement to identity-aware access policy.

How shared responsibility changes access control

Shared responsibility divides cloud security into provider-managed infrastructure and customer-managed security in the cloud. The customer still owns identity management, authorization, configuration, and data protection, even when the provider manages the hardware and core platform. The risk is that teams assume the provider covers more than it actually does, leaving gaps in segmentation, logging, and permission governance. This is where cloud network security becomes an IAM problem as much as a network problem.

Practical implication: Document which access and configuration controls remain yours, then enforce them explicitly across every cloud service.

Why segmentation and monitoring now define blast radius

Cloud segmentation limits how far an attacker can move if one workload or credential is compromised, while traffic inspection shows whether access patterns match policy. In distributed environments, those controls matter because lateral movement can span VPCs, subnets, SaaS integrations, and hybrid links. Without continuous monitoring, teams lose visibility into both legitimate and malicious flows, and they cannot prove whether an identity or workload should be talking to a given resource.

Practical implication: Use segmentation and flow monitoring together so compromised access can be contained before it spreads across environments.

Threat narrative

Attacker objective: The attacker wants to turn one cloud access weakness into broader reach across the cloud estate, increasing the chance of data exposure or operational disruption.

1. Entry occurs when an exposed cloud service, third-party integration, or mis-scoped identity is used to reach a workload that should not have been reachable.
2. Credential or access abuse follows because the environment grants trust based on network position or incomplete authorization checks rather than continuous verification.
3. Escalation and lateral movement become possible across cloud segments, hybrid links, or SaaS connections when segmentation and monitoring are too coarse to contain the session.
4. Impact is broader breach scope, with attackers able to access additional cloud resources, data, or dependent services beyond the first foothold.

Breaches seen in the wild

• HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud network security has become an identity governance problem because network location no longer proves trust. Cloud boundaries are now dynamic, distributed, and partly outside customer control, so access decisions have to be made at request time rather than at the perimeter. That means IAM policy, authorization scope, and continuous verification are now core network security controls, not adjacent disciplines. Practitioners should govern cloud access as identity-first policy enforcement.

Shared responsibility creates a control gap when organisations assume the provider has covered customer-side security. The provider secures the infrastructure, but the customer still owns identities, configurations, and internal access paths. That assumption failure is where cloud programmes often lose control, especially across hybrid estates with inconsistent logging and segmentation. Practitioners should make responsibility boundaries explicit and audit them against actual control ownership.

Blast-radius reduction is now the decisive metric for cloud security architecture. Once identity becomes the control plane, the question is not whether intrusion is possible, but how far a compromised access path can travel. Segmentation, least privilege, and continuous monitoring only matter if they shorten the path from first access to containment. Practitioners should measure how quickly one compromised workload can reach another.

Cloud network security is converging with NHI governance as workloads, service accounts, and APIs become access actors. That intersection matters because many cloud paths are not human user paths at all, but machine-to-machine trust relationships that expand the attack surface silently. NHI governance becomes relevant wherever credentials, tokens, or workload permissions control network reach. Practitioners should inventory machine identities as part of cloud network design, not as a separate exercise.

Continuous visibility is the named control gap this article exposes. Without discovery of cloud resources, integrations, and flows, security teams cannot know which identities are allowed to talk across the environment or where segmentation is missing. That is a governance failure before it is a technical failure. Practitioners should treat unknown cloud assets and unmanaged access paths as unresolved risk, not minor hygiene issues.

From our research library:

• 82% of breaches involved data stored in the cloud, according to IBM (2024).

What this signals

Identity-first cloud security is now the practical operating model. Once workloads, APIs, and service accounts become the real access actors, perimeter controls lose explanatory value and governance has to move to request-time authorization. For practitioners, that means cloud security design and IAM design can no longer be separated cleanly.

Cloud workload identity is the control layer that now determines how far compromise can travel. When a workload’s identity is over-scoped, segmentation loses much of its value because access already exists before the network control is even consulted. Teams should review workload permissions and trust boundaries together, not as isolated programmes.

The biggest programme risk is not lack of tools, but lack of control ownership. If teams cannot say which cloud access decisions they own versus which the provider owns, they will miss gaps in logging, policy enforcement, and containment. Practitioners should close that governance gap before expanding into more complex multi-cloud architectures.

For practitioners

• Inventory cloud identities and access paths Map every user, workload, service account, API, and third-party connection that can reach cloud resources. Include sanctioned services and shadow IT so the access model reflects actual traffic and not only intended architecture.
• Separate provider and customer security responsibilities Document which controls are managed by the cloud provider and which remain customer-owned, especially identity management, configuration, logging, and segmentation. Review that split against each cloud and hybrid environment.
• Enforce least privilege at the network boundary Limit each identity and workload to the minimum network reach needed for its task, and remove broad east-west access where it is not operationally required.
• Correlate traffic monitoring with identity events Tie flow logs and network alerts to the specific identity or workload that initiated the request so teams can distinguish normal service communication from misuse or lateral movement.
• Measure blast radius before and after segmentation changes Test how far a compromised account, token, or workload can move across VPCs, subnets, and hybrid links, then adjust segmentation where the containment boundary is too wide.

Key takeaways

• Cloud network security has shifted from perimeter enforcement to identity-aware control because cloud boundaries are distributed and partly provider-managed.
• The article’s core governance warning is that shared responsibility is often misunderstood, leaving customer-owned access and configuration gaps unaddressed.
• Segmentation, monitoring, and least privilege matter most when they shorten the blast radius of a compromised workload or identity.

Key terms

• Cloud Network Security: Cloud network security is the set of controls that govern traffic, access, and segmentation across cloud environments. In practice it blends network controls, identity policy, logging, and configuration management so distributed workloads can be protected without relying on a fixed perimeter.
• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Cloud-Native Workload Identity: Cloud-native workload identity is the digital identity assigned to an application, service, container, or function running in a cloud environment. It lets systems prove who they are to other services without using shared secrets. In practice, it is enforced through short-lived credentials, certificates, tokens, and policy controls tied to runtime context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps practitioners connect identity controls to real-world cloud and hybrid access decisions.