Microsegmentation vs ZTNA: East-West Workload Control vs User-to-App Access

Zero trust network access stops a remote user reaching everything on the network, but it does nothing about a compromised server talking to every other server once an attacker is inside. Microsegmentation and ZTNA are both zero trust controls and both are sold as replacements for flat networks, so teams often fund one and assume the other problem is solved. They enforce in different places, protect different traffic and fail in different ways. This guide is for security architects and network leads deciding which to build first, how far each should go and how to make them share one policy model. For segmentation design detail see the Network Segmentation Guide; for remote access mechanics see Conditional Access vs ZTNA.

Key takeaways

• They control different traffic directions. ZTNA governs north-south, user-to-application sessions through a broker; microsegmentation governs east-west, workload-to-workload flows between servers, containers and devices already inside the estate.
• ZTNA in front of a flat network only moves the problem. If a user's one permitted application server can reach every other server, an attacker who lands on that server through a stolen session, a vulnerability or a malicious upload has the same lateral reach a VPN user once had.
• Microsegmentation does not fix remote access. It shrinks blast radius after compromise but does not authenticate the person, check the device or remove an internet-facing VPN concentrator.
• Identity is the shared language. ZTNA policy keys on user and device identity; microsegmentation policy that survives change keys on workload identity (labels, service accounts, certificates, SPIFFE IDs) rather than IP addresses.
• Both need a learning phase before enforcement. CISA's 2025 microsegmentation guidance puts dependency mapping and a permissive test mode before any blocking; ZTNA needs the same application discovery before VPN routes are withdrawn.

The short answer

If your biggest exposure is remote and third-party access over VPN, start with ZTNA, because it removes broad network paths for people and closes the internet-facing concentrator. If your biggest exposure is ransomware spreading server to server, or a data centre and cloud estate where any workload can reach any other, start with microsegmentation of your crown jewels. Most organisations past the early stage need both, because ZTNA decides who may open a session to an application and microsegmentation decides what that application, and everything else inside, may then talk to. NIST SP 800-207 treats them as complementary: section 3.1 lists micro-segmentation and network-based segmentation with software-defined perimeters (the model most ZTNA products follow) among three deployment approaches and says a full solution includes elements of all three. See the NIST SP 800-207 Zero Trust Architecture Guide.

Microsegmentation vs ZTNA compared

Threat model for each

What microsegmentation is built to stop

Microsegmentation assumes an attacker is already inside and limits where they can go next. NSA's network and environment pillar guidance calls lateral movement one of the most common techniques after initial access and frames segmentation as the way to contain an intrusion to a small part of the network. The techniques it constrains are concrete: Remote Services (T1021), including SMB/Windows Admin Shares (T1021.002); Exploitation of Remote Services (T1210); Lateral Tool Transfer (T1570); and the internal scanning of Network Service Discovery (T1046). CISA's #StopRansomware Guide asks organisations to block or limit internal SMB so that only systems that need it can talk, because ransomware operators use SMB to spread. A host that can only reach the three services it genuinely uses gives an encryptor very little to work with.

It does not address the front door: a user with valid VPN credentials still lands somewhere.

What ZTNA is built to stop

ZTNA assumes the network path is the risk. A traditional VPN gives an authenticated user an IP address on an internal network and relies on firewall rules behind it, which in practice are often broad. Attackers use External Remote Services (T1133) and Valid Accounts (T1078) to log in like employees, and the #StopRansomware Guide notes that actors often gain access by exploiting VPNs or using compromised credentials. ZTNA replaces the network path with a per-application session, checked against identity and device posture each time, which matches the NIST SP 800-207 tenet that access to one resource does not grant access to another. Outbound-only connectors also remove the listening concentrator. See Securing the ZTNA broker and remote access VPN itself.

The two NHI Mgmt Group breach analyses that show the gap most clearly both start with remote access: the Colonial Pipeline Ransomware Attack 2021 began with an unused VPN account protected only by a leaked password, and in the Change Healthcare Breach 2024 attackers logged in to a remote access portal without MFA and then moved through the environment for nine days before deploying ransomware. ZTNA with phishing-resistant MFA addresses the first step; only internal segmentation addresses the nine days.

Architecture in words

ZTNA: a user opens an application name. The client, or a browser for clientless access, sends the request to a broker, which redirects the user to the identity provider. The broker's policy engine combines the identity decision with device posture (managed, encrypted, EDR running, patch level) and context. If allowed, the broker stitches the user's session to an outbound tunnel from a connector that sits next to the application. The user never receives a subnet route and the application has no inbound internet listener. In NIST SP 800-207 terms this is the device agent/gateway or resource portal variation, with the broker as policy decision point and the connector as policy enforcement point.

Microsegmentation: a central policy manager holds rules written as relationships between labelled workloads, for example "web tier in production may reach payments API on 443; nothing else may reach the payments database". It pushes those rules to many distributed enforcement points: Windows Filtering Platform or nftables through host agents, security groups in each cloud, NetworkPolicy objects in Kubernetes, authorisation policy in a service mesh, or ACLs on an internal firewall for devices that cannot run an agent. The CISA microsegmentation guidance describes exactly these network, endpoint, cloud-native, container and hypervisor enforcement options and notes that agents may not exist for OT and legacy devices.

Agent-based or agentless

Failure modes

Microsegmentation failure modes

• Policy written on IP addresses: rules break or silently widen when workloads autoscale, move between hosts or change addresses, and teams respond with broad subnet allows.
• Endless monitor mode: the learning phase never ends because nobody owns the decision to enforce, so the product becomes an expensive flow map.
• Management plane left open: hypervisor managers, backup consoles, deployment servers and the segmentation manager itself can reach everything by design. Ring-fence these first; ransomware operators target them because one console reaches many hosts.
• Tier-wide allow rules: "any web server to any database" lets one compromised web server reach every database.

ZTNA failure modes

• Flat network behind the connector: the connector itself sits on a broad subnet and can reach far more than the published applications, so a compromised application or connector host becomes a pivot point.
• Wildcard application definitions: publishing whole IP ranges or "all ports" recreates the VPN under a new name.
• Long sessions and one-time posture checks: a session admitted once can outlive the device posture that justified it, so a stolen session is valuable for hours. NIST SP 800-207 expects authentication and authorisation to be re-evaluated during a session.
• VPN left running in parallel indefinitely: the old concentrator remains exposed and remains the easier path.

Where identity fits

Both controls depend on identity, but different kinds. ZTNA is only as strong as the user authentication behind it, so put phishing-resistant MFA and device compliance in the identity provider policy that the broker trusts. Microsegmentation is only as durable as the workload identity behind it. NIST SP 800-207A describes moving cloud-native access control from network parameters such as IP addresses and subnets to policies based on application and service identities, enforced by API gateways and sidecar proxies, with identity infrastructure such as SPIFFE. Rules written against a SPIFFE ID, a Kubernetes service account or a cloud workload identity keep meaning the same thing when IPs change, and an attacker who lands on an allowed subnet does not inherit the identity. Treat those workload identities as non-human identities: inventory them, give them short-lived credentials and alert when a new identity starts talking to a protected service. See the SPIFFE and SPIRE Guide, the Cloud Workload Identity Guide and the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide.

Service accounts used by backup, monitoring and deployment tools deserve their own segment rules: they legitimately reach many hosts, so constrain the source (only the tool's servers), the destination ports and the times they run.

Worked scenario: one firm, two gaps

A 3,000-person manufacturer has a VPN for 400 remote staff and 60 suppliers, a VMware data centre with 900 servers on a few large VLANs, a growing AWS estate and plant networks at three sites.

1. Quarter 1, ZTNA for suppliers: suppliers are the highest-risk VPN users and need only six applications. Publish those six through ZTNA with clientless access for web apps and an agent for the two that need RDP, then remove supplier VPN accounts. Supplier reach falls from thousands of hosts to six.
2. Quarter 1 in parallel, microsegmentation learning: deploy host agents in monitor mode on domain controllers, backup servers, hypervisor management and the ERP database tier. Build the dependency map with application owners.
3. Quarter 2, ring-fence the crown jewels: enforce allow-lists around those systems: only named administration hosts may reach hypervisor and backup consoles, only the ERP application tier may reach its database, SMB between ordinary servers is blocked.
4. Quarter 3, staff off VPN: move employee web applications to ZTNA, then non-web applications; restrict the VPN to a small break-glass group.
5. Quarter 3, connector segmentation: place ZTNA connectors in their own segment with rules allowing only the published applications, so ZTNA and microsegmentation meet in one policy.
6. Quarter 4, plants and cloud: use firewall zones and conduits at plant boundaries where agents are not possible, and security groups plus Kubernetes NetworkPolicy, keyed to labels and service accounts, in AWS.

A year later, a phished employee session reaches four web applications rather than a network, and a compromised application server cannot open SMB, RDP or database connections outside its declared dependencies.

Decision criteria

Budget for people time: microsegmentation needs application owners to confirm every dependency, which is slower than ZTNA group policy. The Microsegmentation Buyers Guide and SASE and SSE Guide cover product evaluation.

Phased enforcement for both

1. Inventory and label: list applications, workloads and owners; label each workload by application, environment and tier, and each private application by user population.
2. Map dependencies: collect flow data from agents, flow logs or firewalls for at least a full business cycle, including month-end and patch windows. CISA's guidance recommends tracking existing communications and involving stakeholders here.
3. Write policy on identity: express microsegmentation rules on labels and workload identities and ZTNA rules on groups and device posture, never on whole subnets.
4. Test in permissive mode: run microsegmentation in monitor or alert-only mode and ZTNA in parallel with the VPN; review every would-be block with owners.
5. Enforce in rings: start with a low-risk application group, then crown jewels, then broad populations. Keep a documented rollback: a per-group switch back to monitor mode and a retained VPN profile for named users.
6. Retire the old path: remove VPN routes and broad firewall allows once traffic has moved; leftovers are what attackers use.
7. Re-test regularly: verify that blocked paths stay blocked with internal reachability testing. See the Network Segmentation Testing Guide and, for estates starting from nothing, the Zero Trust Network Segmentation Playbook for Flat Networks.

Detection and measurement

Feed both control planes into the SIEM. Denied east-west connections from microsegmentation are high-value signals: a workload trying SMB, RDP or WinRM to hosts outside its declared dependencies is either a broken dependency or lateral movement, and both need attention. From ZTNA, log every allow and deny with user, device, application and posture result, and alert on access attempts to applications a user has never used, sessions from non-compliant devices and connector hosts initiating connections other than to published applications.

• Crown jewel coverage: percentage of tier-0 and critical systems (domain controllers, backup, hypervisor management, key databases) under enforced microsegmentation policy.
• Reachable surface: median number of hosts and ports reachable from a typical server, measured before and after enforcement.
• Remote access migration: percentage of private applications published through ZTNA, and number of users and routes still on the VPN.
• Identity-keyed policy share: proportion of segmentation rules written on labels or workload identities rather than IP ranges.
• Time in monitor mode: days from policy creation to enforcement per application group.
• Denied lateral attempts investigated: share of unexpected east-west denies triaged within the SOC's target time.

Framework mapping

NSA's network and environment pillar guidance offers a preparation to advanced maturity scale for segmentation. See M1030 Network Segmentation for the ATT&CK mitigation view.

Common failure patterns

• Declaring zero trust after ZTNA alone: remote access is brokered but the data centre stays flat, so the first compromised server reaches everything, the pattern behind the nine days of movement in the Change Healthcare breach.
• Segmenting users but not administrators: jump hosts and administration workstations are given "any to any" rules for convenience, which makes them the single most valuable pivot.
• Letting the connector or the segmentation manager become tier 0 without protecting it as tier 0: both hold policy that can open every path; restrict administration, require phishing-resistant MFA and log every change.
• Running two policy models that disagree: ZTNA groups and segmentation labels drift apart, so an application published to contractors is reachable from servers that should not see it. Use one application inventory as the source for both.
• Ignoring non-agent assets: OT, printers and appliances are left out of host-agent projects and remain the flat part of the network.

Practitioner checklist

• Decide which traffic direction is your bigger exposure today, north-south remote access or east-west server traffic, and fund that first.
• Ring-fence domain controllers, backup systems, hypervisor management and the segmentation and ZTNA consoles before any other segment.
• Block server to server SMB, RDP and WinRM except from named administration hosts.
• Write segmentation rules on labels and workload identities, not subnets, and track the share that still use IP ranges.
• Put ZTNA connectors in their own segment that can reach only the applications they publish.
• Require phishing-resistant MFA and device compliance in the identity provider policy behind the broker, and shorten session lifetimes.
• Run every new policy in monitor mode for a full business cycle, with a documented rollback per group.
• Set a retirement date for VPN routes and broad firewall allows, and report remaining users and routes monthly.
• Send east-west denies and ZTNA decisions to the SIEM and assign an owner for triage.
• Re-test segmentation after major changes and at least annually.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-207A A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• CISA: Microsegmentation in Zero Trust, Part One: Introduction and Planning
• NSA: Advancing Zero Trust Maturity Throughout the Network and Environment Pillar
• CISA: #StopRansomware Guide
• NCSC: Zero trust architecture design principles
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: Lateral Movement

Related NHI Mgmt Group resources: Identity-Centric vs Network-Centric Zero Trust, Lateral Movement Guide, CISA Zero Trust Maturity Model Guide, NDR vs EDR.