East-West Is the New Battleground: Why Microsegmentation Is No Longer Optional

Every breach post-mortem tells the same story. An attacker gets in — through a phishing email, a stolen credential, an unpatched edge device. That initial foothold is rarely the catastrophe. The catastrophe is what happens in the next hours: the attacker moves east-west across a flat network, reaches systems the initial compromise had no business touching, and only then does the damage become irreversible.

We have been defending the perimeter for decades. We have largely lost that argument. The question worth asking now is not whether the perimeter will be breached — it will — but whether your internal architecture assumes that it already has been.

The pattern that repeats across every sector

Six recent incidents, drawn from different industries and geographies — including organisations operating under DORA, NIS2, and PCI DSS obligations — share one root cause: the absence of enforceable internal network boundaries after initial access.

Healthcare — Synnovis / NHS London (June 2024, UK). Qilin ransomware gained entry to Synnovis, a pathology provider serving seven NHS hospitals in London. After confirming lateral movement through the hybrid network, attackers exfiltrated 400 GB of data covering 900,000+ patients, then encrypted nearly all systems. Over 10,000 appointments and 1,700 elective operations were cancelled. At least one patient death was later attributed to the disruption. A $50 million ransom was refused. The entire cascade followed from unconstrained east-west movement after the initial compromise — confirmed by Synnovis’s own 18-month forensic investigation.

Energy / OT — Danish energy sector (May 2023, Denmark). In the largest coordinated attack on Danish critical infrastructure to date, 22 energy companies were simultaneously breached via CVE-2023-28771 in Zyxel perimeter firewalls. Attackers reached the industrial control systems of multiple operators. SektorCERT’s published report was explicit: the operators had very little segmentation beyond the perimeter. Several companies were forced to disconnect from the national grid and operate in emergency island mode. Without internal OT/IT segmentation, a firewall compromise became an ICS compromise.

Pharmaceutical — Cencora cascade (February 2024, EU/global). Attackers breached pharmaceutical distributor Cencora and, because no workload-level isolation existed between Cencora’s systems and its clients’ data environments, the breach propagated to 27 downstream companies — including AbbVie, Bayer, Novartis, GlaxoSmithKline, and Regeneron. All are European-headquartered entities subject to GDPR and sector regulation. One breach at one distributor reached three dozen organisations. The mechanism was not sophisticated; it was a flat network with shared data access.

BFSI / fintech — Santander / Snowflake (May 2024, Spain/global). ShinyHunters exploited credentials stolen via infostealer malware to access Santander’s cloud database through a third-party Snowflake environment. Because no network-level isolation existed between cloud data stores, the same credential-based campaign ultimately breached 165 organisations, including Ticketmaster (560 million records). Valid credentials in a flat cloud environment provided unrestricted traversal. Santander’s official statement confirmed the breach occurred via a third-party hosted database — no internal boundary blocked the movement.

Gaming / gambling — MGM Resorts (September 2023, global). A single 10-minute helpdesk call — impersonating an employee found on LinkedIn — gave Scattered Spider Okta administrator privileges. From Okta they pivoted to Azure, from Azure to on-premise VMware ESXi hypervisors. ALPHV then encrypted more than 100 ESXi hosts, taking down slot machines, room keys, and reservation systems across 30+ properties. MGM reported a $100 million Q3 loss. Post-incident analysis noted the rapid encryption of 100 ESXi servers “potentially indicates a network which was not segmented very well.” Three distinct environments, no internal boundary at any step.

Gaming / gambling — Fast Track iGaming (October 2025, Malta). Fast Track, a Malta-based CRM provider serving 100+ iGaming operators globally, suffered a sophisticated breach affecting multiple operator clients through a single compromised vendor environment. The same structural failure as MGM: a trusted third-party platform with broad access and no tenant-level isolation. Fast Track held a SOC 2 Type 2 certification renewed four months before the incident — demonstrating that point-in-time compliance audits do not substitute for continuous enforcement.

The consistent finding across all six: in no case did the initial compromise cause the full damage. In every case, unconstrained east-west movement did.

What microsegmentation actually is

Traditional network segmentation — VLANs, firewall perimeters, DMZ zones — divides a network into zones. It controls traffic between zones. It does not restrict traffic within a zone. An attacker who has reached any asset inside a segment can freely reach every other asset in that same segment. In a large enterprise, a single VLAN may contain hundreds of servers.

The diagram below shows the structural difference:

Microsegmentation places a policy-enforced micro-perimeter around each individual workload — each server, VM, container, endpoint, or OT device. Traffic between any two workloads requires an explicit allow policy. Everything else is denied by default. This is not a configuration style. It is an architectural assumption: that the network interior is not trusted, that any asset may already be compromised, and that no workload should reach another without a documented, policy-defined reason.

The practical implementation uses the host-based firewalls already present on every modern operating system — Windows, Linux, Unix, macOS — with a centralised policy engine configuring and enforcing them at scale. For assets that cannot run an agent — OT devices, legacy systems, IoT hardware, medical equipment — an agentless gateway appliance enforces the same policies without touching the protected devices.

The coverage model looks like this:

Two points are worth emphasising. First, discovery precedes enforcement. Before any policy is written, the platform maps all assets, traffic flows, and application dependencies automatically. Policies reflect observed behaviour rather than architecture diagrams that may be years out of date. Second, policy authoring separates from policy push — new policies can be simulated against historical traffic before going live. In environments where service continuity matters (which is every environment in this list), this prevents a legitimate business process from being accidentally blocked during rollout.

What the regulators now require

Three frameworks with direct applicability to European organisations — and to CEE and MENA companies accessing EU markets or handling EU data — contain specific, enforceable requirements on internal network control.

DORA — Regulation (EU) 2022/2554. The Digital Operational Resilience Act became applicable on 17 January 2025. Article 9(4)(b) requires financial entities to “design the network connection infrastructure in a way that allows it to be instantaneously severed or segmented in order to minimise and prevent contagion, especially for interconnected financial processes.” The word “instantaneously” is technically significant — it rules out manual isolation procedures. Commission Delegated Regulation (EU) 2024/1774, Article 13(c), adds a requirement for “a separate and dedicated network for the administration of ICT assets.” That is a direct requirement for the management/operational boundary that, had it existed at MGM, would have blocked the Azure-to-ESXi pivot. For the full operational and supervisory implications, see DORA in Practice.

NIS2 — Directive (EU) 2022/2555. NIS2 applies to essential and important entities across sectors including energy, transport, health, digital infrastructure, and financial services. Article 21(2)(e) requires “network and information systems security,” with implementing guidance pointing to network segmentation as a baseline control for limiting propagation between systems. The Danish energy incident — where 22 operators were simultaneously compromised through shared perimeter exposure — is precisely the scenario NIS2 Article 21 is designed to address. Poland’s KSC Act transposition is expected to enter into force in 2026, making NIS2 obligations enforceable for Polish entities. For the three operational artifacts that decide NIS2 outcomes, see NIS2 Without Drama.

PCI DSS 4.0.1. The current active version of the Payment Card Industry Data Security Standard (v3.2.1 was retired December 2024). Requirement 1 addresses network security controls and CDE isolation. If segmentation is used to reduce compliance scope, Requirements 11.3 and 11.4 mandate regular penetration testing to verify that segmentation is actually effective — not merely asserted. The PCI SSC published dedicated supplemental guidance on microsegmentation and modern network architectures in September 2024, explicitly addressing zero trust environments and containerised workloads.

ISO 27001:2022 — Annex A Control 8.22. The 2022 revision replaced the earlier Control 13.1.3 with a strengthened Annex A 8.22, “Segregation of Networks.” It requires organisations to segregate networks into distinct security domains based on trust levels and criticality, and to control traffic between those domains. The control explicitly frames segregation as a mechanism to limit blast radius — ensuring a breach in one segment cannot reach systems in another. A certification maintained against this control on the basis of VLAN separation alone, where VLANs contain mixed workloads with no intra-segment enforcement, does not satisfy the intent of the control.

Why this remains difficult in practice

The technical case for microsegmentation has been settled for years. Adoption at scale has been slow for four concrete reasons.

Visibility. You cannot write a policy governing which workloads may communicate without first knowing what is actually communicating. Most organisations do not have this. Network diagrams are outdated. Shadow assets are undocumented. Cloud workloads provisioned directly by development teams are invisible to the network team. Any segmentation approach that starts from the policy layer before establishing an accurate picture of real traffic flows will disrupt legitimate business processes.

Operational complexity. Traditional hardware-based segmentation requires network team involvement for every policy change. In environments where workloads are deployed daily, this does not scale. Policy management across separate firewall consoles — one for the data centre, another for cloud, another for OT — creates exactly the visibility gaps that attackers exploit.

Heterogeneity. A modern enterprise spans on-premise servers, multi-cloud workloads, Kubernetes clusters, user endpoints, OT devices, and IoT hardware. Any segmentation approach that covers only part of this estate leaves the uncovered portion as a viable lateral path. In the Danish energy case, the OT layer was the uncovered portion.

IT/OT convergence. Operational technology was historically air-gapped. Digital transformation has eliminated that air gap. OT devices now share network segments with IT infrastructure but operate under completely different constraints: they cannot be patched on standard cycles, cannot run security agents, and have availability requirements that override almost everything else. Standard enterprise segmentation tools fail entirely in this environment. This is a particularly relevant gap for industrial and energy operators in CEE and MENA, where OT estates often combine legacy protocols with modern cloud connectivity.

The practical starting point

Before any tool evaluation, two questions deserve an honest answer from whoever owns the network:

How much do I actually know about my own network — right now, while reading this?

Not what the architecture diagram from three years ago shows. What is actually communicating with what, in production, at this moment? Can you name the 20 most active east-west flows in your environment today? Has any host in your network initiated a connection to another host on an unexpected port in the last hour — and if it has, do you have an alert for it, or would you only find out during a post-incident forensic review weeks from now?

In most environments, the honest answer to that last question is: you would find out weeks later. The architecture is documented; the actual traffic state is not.

This is where discovery-first segmentation platforms make the most immediate impact before any policy is written. Deploying a passive telemetry layer that maps real traffic flows — workload to workload, across cloud and on-premise, including OT and legacy — turns the network from an assumed architecture into an observed one. You will find traffic that should not exist. You will find assets that should not be there. You will find services that were decommissioned six months ago still accepting connections.

How would I know if a host is compromised and scanning others right now?

This is the question that flat networks cannot answer. In a segmented environment, an anomalous connection attempt from workload A to workload B — where no allow policy exists between them — generates a policy violation event at the moment it occurs. The policy enforcement layer provides not just protection but continuous visibility: every denied connection attempt is logged, timestamped, and attributed to a source workload. A compromised host attempting to enumerate the network produces a visible, auditable trace of exactly where it tried to move and what it was denied.

In a flat network, that scan is invisible. The traffic is permitted by default. There is nothing to log. The attacker’s reconnaissance phase — which can last days or weeks before ransomware deployment — happens in silence.

The practical implication: the first value of microsegmentation is not the enforcement. It is the visibility. An organisation that deploys discovery and observation tooling before writing a single enforcement policy gains an accurate picture of what is actually on its network and what it is doing. That picture alone frequently reveals compromises, misconfigurations, and legacy exposures that were invisible in the assumed architecture.

Enforcement — the actual micro-perimeters — comes next, progressively. A phased approach applies broad controls first (blocking high-risk ports and suspicious lateral flows enterprise-wide) then advances to fine-grained application-specific policies over time. The security posture improves from day one, before the deployment is complete.

A practitioner’s perspective

Having evaluated the available approaches against the operational constraints described above, the gap between concept and working deployment is real and consistent: most programmes stall because the solution either does not cover the full estate (OT and legacy systems are excluded), or it requires manual policy authoring against a topology that was never accurately documented, or it treats enforcement as a single phase rather than a progressive one.

Among the solutions I have looked at seriously, Xshield from ColorTokens handles all three constraints directly. Discovery is automatic. Coverage spans IT, cloud, containers, endpoints, OT/IoT, and legacy systems including out-of-support operating systems — from a single policy console. The OT and legacy gap is addressed through an agentless Gatekeeper appliance that enforces policies without requiring any modification to the protected devices. The implementation model separates observation from enforcement, allowing organisations to progress at a pace that does not risk operational continuity.

ColorTokens Xshield was recognised as a Leader in the Forrester Wave for Microsegmentation Solutions (Q3 2024) — the only vendor among 15 evaluated to receive a perfect score across key feature categories — and was selected as a Visionary Vendor at RSAC 2025 by Enterprise Management Associates.

I note this not as a vendor endorsement but because the evaluation criteria matter more than the selection. An organisation evaluating microsegmentation should demand: discovery-first deployment, full-estate coverage including OT and legacy, agentless enforcement where agents cannot be installed, and integrated compliance reporting that produces audit artefacts for DORA, NIS2, PCI DSS, and ISO 27001:2022 without manual evidence collection. Solutions that meet these criteria produce working deployments. Solutions that do not leave the hardest environments uncovered and deliver partial protection at best.

What prepared looks like

An organisation ready to answer the east-west question has three things in place: an accurate, continuously updated map of what is communicating across its network; policy-enforced micro-perimeters that limit lateral movement to explicitly authorised flows; and a violation log that surfaces anomalous east-west traffic in real time.

The regulatory frameworks point to the same place. DORA’s requirement for instantaneous segmentation capability, NIS2’s network security controls, PCI DSS’s mandate for tested and demonstrable CDE isolation, and ISO 27001:2022’s requirement for risk-based network segregation all reflect the same technical reality: zone-based perimeter separation is insufficient for the current threat model.

The organisations that will navigate the next significant incident with the least damage are not necessarily those with the most sophisticated detection. They are those whose internal architecture assumed the breach had already occurred — and built accordingly. For security teams across CEE and MENA operating under multiple regulatory frameworks simultaneously, that architecture starts with knowing what is on the network and what it is doing.

Eugene Titaev — March 2026