CSA Publishes New Zero Trust Microsegmentation Guidance

The Cloud Security Alliance has published its new Zero Trust Microsegmentation Guidance. I led the workstream with Michael Roza, supported by contributors and reviewers from across the CSA Zero Trust Working Group.

The guidance provides a technical and operational blueprint for applying Zero Trust microsegmentation across IT, OT, IoT, cloud, edge, and agentic AI environments. Its central argument treats microsegmentation as a Zero Trust outcome, rather than a product category or a one-off network project.

The test: does the network explicitly permit, enforce, observe, and govern a given communication over time? Answering that starts by separating two different ways of defining what’s allowed to communicate in the first place.

Two Complementary Segmentation Models

The guidance calls these topology-defined and connection-defined segmentation, and treats them as complementary rather than competing approaches.

• Topology-defined segmentation controls where traffic may flow. It uses zones, routes, VLANs, security groups, network policies, firewalls, gateways, and other enforcement points. It’s particularly useful for deterministic containment, local east-west control, regulatory boundaries, and OT zones and conduits.
• Connection-defined segmentation controls who or what may establish a session with a specific resource, under which identity, posture, entitlement, service intent, and contextual conditions. The system makes that decision before it grants reachability, reducing exposure and ambient discovery.

Mature Zero Trust architectures layer the two: connection-defined controls prevent unnecessary paths from existing, while topology-defined controls contain movement if an attacker compromises a system, credential, or authorized session.

This also moves microsegmentation beyond its traditional association with east-west data-center traffic. Teams can enforce the same segmentation intent across workloads, hosts, cloud-native controls, gateways, session brokers, API boundaries, and OT conduits. Whether traffic is north-south, east-west, cloud-to-edge, partner-to-service, or entering an OT environment matters less than whether the relationship is authorized.

Macro, Micro, and Nano Segmentation: Choosing the Right Depth

The guidance also provides a clearer taxonomy for choosing the appropriate depth of segmentation:

• Macro-segmentation establishes broad boundaries around environments, sites, zones, and trust domains.
• Microsegmentation determines which users, devices, workloads, services, or other identities may communicate.
• Nano-segmentation constrains specific processes, containers, agents, tools, or runtime behaviors.

Teams should select these layers according to the protected surface, operational constraints, and risk. An OT cell containing legacy systems may require predictable gateway enforcement, while a Kubernetes workload or AI agent may support identity, workload, and runtime controls much closer to the application.

The goal is to preserve a consistent least-privilege policy outcome across different enforcement planes, regardless of which technical model each environment uses.

Microsegmentation as an Ongoing Operating Model

Visibility is essential for discovering assets and understanding dependencies, but visibility alone is not segmentation. Teams must translate observed flows into explicit policy and maintain that policy as applications, workloads, and business requirements change.

The paper recommends an iterative operating model:

Observe → hypothesize → simulate → canary → enforce → monitor → retire exceptions.

That means defining protected surfaces as business assets rather than collections of IP addresses, assigning ownership, expressing policy through durable attributes such as identity and service role, and setting rollback conditions before enforcement begins.

It also means measuring outcomes. Useful measures include the percentage of protected surfaces with explicit allow-lists, mean time to isolate, exception half-life, policy drift, and the time required to introduce a legitimate connectivity change.

Without that lifecycle and governance, microsegmentation gradually becomes another collection of broad rules, undocumented dependencies, and permanent exceptions.

Extending Microsegmentation into OT and Agentic AI

The guidance gives specific attention to environments where conventional endpoint enforcement is impractical.

In OT and ICS, safety, latency, legacy protocols, and limited agent support affect where teams can place controls. Existing topology-defined zones and conduits remain important, while identity-aware gateways can provide more precise control over the users, partners, workloads, and services permitted to communicate across them.

Agentic AI creates a different version of the same problem. Agents may dynamically select tools, call APIs, retrieve data, and interact with services across several trust domains. Their segmentation policies must therefore define which agents may reach which tools, models, APIs, and data sources, under what delegated authority and runtime conditions. Governed egress is part of that model: an agent should not inherit unrestricted outbound connectivity simply because its workload is running inside an approved environment.

This becomes more urgent as AI accelerates vulnerability discovery, reconnaissance, and exploitation. If a service or tool path is unnecessarily reachable, automated systems can find and use it faster than many human-led patching and firewall processes can respond.

The Progression Toward Identity-Defined Reachability

This paper continues a deliberate progression in CSA’s work, addressing a limitation inherited from traditional networking.

Traditional networks were built around addresses, routes, and ports, so teams commonly express access through IP addresses, VLANs, firewalls, and VPNs. These remain essential for boundaries and containment, but the usual sequence is connect first, constrain later: establish reachability, then restrict it.

Zero Trust requires a different decision: which authenticated user, workload, device, partner, or agent may connect to which named service, under what policy and conditions?

NIST SP 800-207 removes implicit trust based on network location, while SP 800-207A and CISA’s Zero Trust Maturity Model move toward identity-based, service-specific, just-in-time, and just-enough connectivity.

Implementing every new service relationship through routes, NAT, firewall rules, VPNs, DNS, and change control creates a recurring connectivity tax. A reusable identity and policy control plane standardizes and automates that work across changing environments.

The SDP Architecture Guide v3 applied this approach through authenticate-before-connect and authorize-before-connect, extending SDP beyond human access and Single Packet Authorization to workloads, services, devices, OT, and AI. The new microsegmentation guidance now places this connection-defined model alongside topology-defined containment.

Identity-Defined Reachability brings those models together. Identity establishes the subject; context and governance determine authority; policy defines the permitted service relationship; and telemetry and automation make it observable and adaptable. Reachability becomes a governed outcome rather than a pre-existing network condition.

The controls remain complementary:

• Topology establishes boundaries and containment.
• Governance determines whether the relationship is permitted.
• IDR makes only the authorized service path usable.
• Application and runtime controls govern what happens across it.

My recent CSA article, AI-Speed Risk Requires Identity-Defined Reachability, explains why this matters as AI reduces the time available to close exposed attack paths. A forthcoming CSA paper will develop IDR as a common model across human, workload, OT, and agentic AI use cases.

Putting Identity-Defined Reachability into Practice

NetFoundry and OpenZiti make this practical today. NetFoundry evaluates policy before connectivity exists, keeps protected services dark, and lets the fabric create an encrypted path only for an authorized identity-to-service relationship; the same model NetFoundry brings to market as Identity-First Reachability™. The model can extend upward into Kubernetes, IT/OT, and agentic AI, and downward across heterogeneous networks, legacy systems, and evolving cryptography such as PQC. 

This abstraction lets applications, security controls, and transport infrastructure evolve at different speeds while reducing the cost and effort of connecting them securely.

Want to see where your own environment stands against this model? Talk to NetFoundry about applying Identity-Defined Reachability to your microsegmentation strategy. Need more info first? Read the complete CSA Zero Trust Microsegmentation Guidance.

---

Frequently Asked Questions

What is Zero Trust microsegmentation?

NetFoundry defines Zero Trust microsegmentation as controlling exactly which users, devices, workloads, or services can communicate with each other, based on identity and policy rather than network location. CSA’s new guidance treats it as a required outcome, measured by whether every connection is explicitly permitted, enforceable, observable, and governable over time — not by which product enforces it.

What’s the difference between topology-defined and connection-defined segmentation?

At NetFoundry, we distinguish between segmentation that controls where traffic can flow (topology-defined, using zones, VLANs, and firewalls) and segmentation that controls who or what can establish a connection in the first place (connection-defined, based on identity and policy). Most mature Zero Trust architectures use both: connection-defined controls prevent unnecessary paths from ever existing, and topology-defined controls contain any breach that does occur.

What is Identity-Defined Reachability (IDR)?

NetFoundry helped shape this concept through its contributions to CSA’s Zero Trust standards work. Identity-Defined Reachability makes network reachability a governed outcome instead of a pre-existing condition: a path only becomes usable after an authenticated identity is authorized under policy. NetFoundry’s own Identity-First Reachability™ architecture applies this model in production, keeping protected services invisible until a specific identity-to-service connection is authorized.