Why You Can’t Segment What You Can’t See: The Zero Trust Visibility Gap
In February 2024, attackers used stolen credentials to access a Citrix remote access portal at Change Healthcare, a claims-processing subsidiary of UnitedHealth Group. The portal let staff access their desktops remotely, and it did not have multi-factor authentication enabled. Once inside, attackers moved laterally through Change Healthcare’s systems for nine days before deploying ransomware, exfiltrating several terabytes of data along the way.
UnitedHealth’s own CEO confirmed the details under oath before Congress. Andrew Witty testified that the company paid a $22 million ransom, and the breach ultimately affected roughly 190 million Americans, the largest healthcare data breach in U.S. history. The failure was not a missing firewall. It was the absence of Zero Trust Network Segmentation: no boundary limiting what a single unprotected remote access point could reach across the rest of the network.
This is the core problem with segmentation as it is usually built. Policies get written against an assumed map of the network, not the live one. When that map is wrong, segmentation looks solid on paper while leaving the real attack path wide open.
What Is Zero Trust Segmentation?
Zero Trust Network Segmentation divides a network into small, tightly controlled zones and enforces per-request access decisions between them, rather than granting broad trust based on network location.
The concept comes from NIST Special Publication 800-207. It defines zero trust architecture around one principle: no user, device, or connection is trusted by default, even inside the network perimeter. Every access request gets verified based on identity, device posture, and context before it is granted.
Microsegmentation is the mechanism that makes this enforceable at the network level. Instead of broad zones like “internal” and “external,” microsegmentation divides the network down to individual workloads, applications, or processes. Each segment enforces its own access policy.
A working Zero Trust Network Segmentation program typically requires:
- Verified identity for every user, device, and workload requesting access
- Least-privilege policies that grant only the access a system needs to function
- Continuous monitoring and re-verification, not one-time authentication
- Granular segmentation down to individual assets rather than broad network zones
The Hidden Problem
None of this works without knowing what is actually talking to what. You cannot write a least-privilege policy for a communication path you don’t know exists. NIST’s own guidance places asset discovery and communication flow mapping as the first phase of a zero trust rollout, before policy design even begins.
| Without accurate communication maps | What happens |
|---|---|
| Policies written from assumptions | Segments end up too broad, or block legitimate traffic |
| Undocumented service dependencies | Applications break the moment segmentation is enforced |
| Shadow communication paths | Attackers find and use the paths nobody accounted for |
| One-time, static discovery | Segmentation drifts out of sync as infrastructure changes |
Why Is Zero Trust Segmentation Important?
Zero Trust Network Segmentation exists to contain what a single compromised credential or device can reach. It matters because perimeter defenses have already failed as a strategy on their own. Attackers get in through phishing, stolen credentials, or an unprotected remote access point, the same way they did at Change Healthcare. What happens after that initial foothold determines whether the incident stays small or becomes a headline.
A 2026 Omdia survey of 352 security leaders found that 99% of organizations are implementing or planning microsegmentation. Yet over 90% have protected fewer than 80% of their critical systems. Nearly half had experienced a lateral movement attack in the past year. The intent is nearly universal, but execution consistently falls short.
The reason execution lags is straightforward. Writing accurate segmentation policy requires knowing the current, real communication paths across the environment, and that data usually does not exist anywhere a policy writer can act on it.
Three Failure Modes
1. Overly Permissive Policies Written from Guesswork
Security teams under pressure to deploy segmentation quickly often default to broad rules: allow this subnet to reach that subnet. Without a live map of actual service-to-service traffic, teams cannot write narrow rules with confidence, so they widen the policy to avoid breaking something they cannot see.
Result: the segmentation exists on paper, but the effective policy is barely tighter than the flat network it replaced.
2. Broken Applications from Blind Enforcement
The opposite failure happens when teams enforce segmentation aggressively without full visibility. A policy blocks a communication path that turns out to be a legitimate, undocumented application dependency: a batch job, a monitoring agent, a shared authentication service. The application breaks in production as a result.
Result: teams roll back the policy, or carve out broad exceptions that quietly recreate the original flat network.
3. Lateral Movement Through Unmapped Segments
Attackers do not need every path mapped. They only need one path nobody accounted for. An unmonitored device, an undocumented service account, or a forgotten integration becomes the bridge to a high-value segment, exactly like the unprotected Citrix portal at Change Healthcare.
Result: segmentation contains the attack everywhere it was correctly mapped, and fails at exactly the point it wasn’t.
The Real Cost of Segmenting Blind
For Security Leaders
IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.44 million. Organizations took an average of 241 days to identify and contain an incident, the fastest pace in nine years. That is still enough time for an attacker to move well beyond their point of entry if nothing stops them.
IBM’s earlier analysis of critical infrastructure organizations found that those without a zero trust strategy saw average breach costs rise to $5.4 million. That is $1.17 million higher than organizations that had a zero trust strategy in place. Segmentation is what turns a zero trust strategy from a policy document into an operational control.
For IT Operations Teams
Segmentation projects that break production applications generate rollback requests, war rooms, and eroded trust between security and operations. Every outage caused by a segmentation policy makes the next rollout phase harder to approve and slows the entire program.
For Regulated Environments
Auditors reviewing PCI DSS, HIPAA, or similar frameworks expect documented evidence of segmentation controls and the exact boundaries they enforce. This is the same evidence cybersecurity asset management programs already need to produce for compliance reviews. When actual traffic patterns do not match the documented segmentation design, that mismatch becomes an audit finding regardless of whether it has been exploited yet.
Market-Scale Challenge
Legacy segmentation tools compound the problem. Most security teams still rely on VLANs, access control lists, and host-based firewalls, tools that were never built to track east-west traffic between modern workloads, containers, and cloud services. In the same Omdia survey, 44% of security leaders named comprehensive device and communication visibility as their most critical capability gap.
A separate 2026 State of IT Maturity Report from EZO found a similar gap in asset management. 53% of organizations rely on CMDB or ITSM platforms as their primary system of record, while 16% still depend on spreadsheets to track assets and configurations. Segmentation policy built on top of either system can’t be more current than the record it reads from.
How Accurate Dependency Maps Enable Zero Trust Segmentation
An accurate, continuously updated map of system-to-system communication does three things for a segmentation program.
1. Reveals Real Communication Paths Before Policy Writing
Before teams write a single segmentation rule, they need a complete, current picture of which systems actually talk to which other systems, and over which ports and protocols. This has to be discovery-driven data, not an architecture diagram from three years ago or an org chart.
This is precisely what Virima’s service mapping addresses: continuously scanned, discovery-sourced dependency data that shows live communication paths, not documented assumptions about them.
2. Makes Least-Privilege Policies Enforceable Without Breaking Apps
When policy writers can see the full dependency chain for a given service, they can scope segmentation rules tightly around what a system actually needs, not what it might need. That same dependency view is what change teams use to assess blast radius before approving infrastructure changes, and it applies just as directly to segmentation policy design.
3. Continuously Validates Segmentation as the Environment Changes
New services deploy, cloud workloads spin up and down, and integrations get added constantly. A segmentation policy built once against a static map degrades the moment anything changes. Continuous discovery keeps the underlying map, and therefore the policy, current.
Zero Trust Examples: Segmentation in Practice
- Isolating remote access points from core systems. A single unsegmented Citrix or VPN portal can become the pivot point into an entire environment, exactly what happened at Change Healthcare in 2024. Placing remote access infrastructure in its own segment limits what a single compromised credential can reach.
- Reducing PCI scope in payment environments. Card processing systems get isolated into their own segment, walled off from vendor connections and general corporate traffic. This remains one of the most common starting points for a segmentation program today.
- Isolating IoT and OT devices from IT networks. Healthcare and manufacturing environments run large volumes of connected devices, infusion pumps, building controls, and industrial sensors that were never designed with modern authentication in mind. Segmenting these devices away from core IT systems limits what a single compromised device can reach.
- Containing a compromised segment during incident response. When an incident is confirmed on a specific system, responders can isolate that segment immediately rather than waiting to trace every downstream connection manually. Speed here depends entirely on already knowing what sits on the other side of that boundary.
- Segmenting cloud workloads from legacy on-premises systems. Hybrid environments often connect cloud-native applications to older on-premises databases and services through paths that were never formally documented. Zero Trust Network Segmentation treats that connection with the same scrutiny as any external one.
How Virima Powers the Map Behind Zero Trust Segmentation
Virima’s discovery engine frequently scans hybrid environments, on-premises, cloud, and containerized, to build a live picture of what exists and how it connects. That data feeds directly into Virima’s ViVID™ service mapping, giving security and network teams the same continuously updated view that change management and incident response teams already rely on.
Immediate Operational Impact
Before a segmentation rollout, teams can pull up the current dependency map for a given application or business service. Every real communication path feeding into it becomes visible, not just the paths someone assumed exist. During incident response, the same map lets responders isolate a compromised segment with confidence about what that isolation will and will not affect.
Long-Term Accuracy
Segmentation policies built on Virima’s discovery data stay aligned with reality as the environment evolves:
- New workloads and cloud assets appear in the map as soon as discovery finds them
- Decommissioned systems get flagged rather than lingering as stale policy targets
- Vulnerability data from the NIST National Vulnerability Database overlays directly onto the same CIs, so segmentation priorities can align with actual exposure
Integration with Existing Workflows
Virima integrates with ServiceNow, Jira Service Management, and Ivanti, so segmentation and dependency data show up inside the tools security and network teams already use. Teams get this without a separate mapping platform to maintain alongside the ITSM system of record.
Moving from Blind Segmentation to Map-Driven Zero Trust
The shift from assumption-based segmentation to map-driven Zero Trust Network Segmentation requires two foundational changes:
For teams currently segmenting from static documentation, the benefits cascade across three areas:
- Policy design gets scoped to actual traffic instead of broad guesses, cutting both over-permissive gaps and application-breaking false positives.
- Incident containment speeds up because responders isolate compromised segments with the dependency map already showing what sits on either side of every boundary.
- Audit readiness improves because documented segmentation controls match live traffic patterns, so compliance evidence reflects what the network actually does.
Getting Started
- Run automated discovery across the full hybrid environment to surface every connected asset.
- Build a live service dependency map from that discovery data, not from architecture documentation.
- Identify the highest-value segments first: payment systems, regulated data stores, and critical infrastructure.
- Write initial segmentation policies scoped to the real communication paths the map reveals.
- Keep discovery running continuously so the map, and the policy behind it, stay current.
Ready to see what Zero Trust Network Segmentation looks like with a live dependency map behind it? Schedule a demo to see Virima’s discovery and ViVID™ service mapping in action, or read more about how application dependency mapping supports the same underlying data layer.
