Cloud workloads change quickly, and their connections are often mediated by non-human identities, service accounts, and indirect network paths. Without visibility, teams cannot tell which flows are required and which are risky. That makes segmentation more likely to disrupt business than reduce risk.
Why This Matters for Security Teams
Cloud segmentation is rarely a clean network exercise. Workloads are ephemeral, identities are dynamic, and many critical paths are authenticated by service accounts, API keys, or other non-human identities rather than a fixed host-to-host rule. That means the real question is not simply where traffic should be blocked, but which identities, services, and dependencies actually need to communicate. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because visibility is a prerequisite to implementing access control, monitoring, and system integrity in a defensible way.
Teams that skip visibility often build segmentation from assumptions: subnet maps, stale asset inventories, or architecture diagrams that no longer match runtime reality. In cloud environments, that approach can block legitimate east-west traffic, mask hidden dependencies, and create outages that are blamed on “the firewall” rather than on incomplete discovery. The security problem is amplified when workloads scale automatically or are deployed through CI/CD pipelines faster than control baselines are updated. In practice, many security teams encounter segmentation failure only after a production service has already been interrupted by an enforcement rule that was never validated against live traffic.
How It Works in Practice
Effective segmentation usually starts with observing runtime behaviour before enforcing boundaries. Security teams need to identify who is talking to whom, over which protocols, with what identities, and for what operational purpose. That visibility can come from flow logs, eBPF-based telemetry, workload identity assertions, service mesh data, and application-layer logs. The goal is to build an evidence-based dependency map rather than an idealised network diagram.
Workload identity is especially important because cloud services often authenticate without stable IPs. The SPIFFE workload identity specification is a useful reference point here because it ties communication to cryptographically verifiable identity instead of only to network location. That matters when containers are rescheduled, nodes are replaced, or multiple tenants share the same infrastructure. Once identity and flow baselines are understood, teams can introduce policy in stages:
- observe and classify flows to identify business-critical dependencies
- group workloads by trust level, sensitivity, and communication patterns
- apply alert-only controls before blocking to validate impact
- move from broad allow rules to narrowly scoped service-to-service permissions
- review exceptions regularly so temporary access does not become permanent
This approach also supports better detection, because unexpected connections stand out once normal patterns are known. It is particularly useful in hybrid environments where legacy systems, container platforms, and managed services all coexist under different logging standards. These controls tend to break down when telemetry is incomplete across shared cloud services and third-party integrations, because policy decisions are then based on partial dependency data.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance reduced blast radius against faster change delivery. Best practice is evolving for highly dynamic cloud estates, and there is no universal standard for how much pre-enforcement visibility is enough. In some environments, especially regulated workloads, teams may accept slower rollout in exchange for stronger confidence in segmentation rules. In others, they may prefer soft enforcement with continuous review to avoid interrupting customer-facing services.
There are also edge cases where visibility is harder to achieve. Managed services may expose limited flow telemetry, serverless functions can generate short-lived connections that are difficult to classify, and encrypted east-west traffic may obscure application intent without workload identity or service-level instrumentation. In those situations, teams should not treat “no visibility” as “no risk.” It usually means the policy should remain permissive until enough evidence exists to narrow it safely. For identity-heavy cloud architectures, the practical control is often not network blocking first, but binding segmentation decisions to verified workload identity, supported by monitoring and exception handling.
Where the environment includes shared clusters, multi-account cloud estates, or rapid deployment pipelines, segmentation policies should be tested against live traffic and rollback plans before they become mandatory. That is the difference between control and disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Segmentation depends on understanding and constraining access pathways. |
| NIST SP 800-53 Rev 5 | AC-4 | Information flow enforcement requires knowing legitimate dependencies first. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes continuous verification, not blind segmentation. |
Enforce policies based on verified identity and observed trust signals, not static network assumptions.
Related resources from NHI Mgmt Group
- Should organisations modernise ERP governance before moving systems to cloud applications?
- What is the difference between threat intelligence and enforcement in cloud security?
- How should organisations govern access when PAM does not fit cloud-native workloads?
- Should organisations prioritise least privilege before adding more cloud controls?
