Workload-based segmentation so a single intrusion can't spread laterally

What the control is

Workload-based segmentation is the architectural pattern in which every workload — every server, every container, every application instance — is treated as its own enforced policy boundary, with cross-workload connectivity governed by identity- and application-aware rules rather than by network address. It is the practical realisation of the principle NIST SP 800-207 articulates as “resource-level enforcement”: the network is no longer the trust boundary; the workload is.

This is a meaningfully different control from traditional perimeter or VLAN-level segmentation. A VLAN-tier design typically gives an enterprise four or five internal zones — corporate, server, DMZ, OT, guest — each defended by a small number of north-south firewalls. Within each zone, the network is flat. Workload-based segmentation gives the same enterprise tens of thousands of policy boundaries — one per workload — with east-west traffic between any two workloads explicitly allowed, denied, or alerted on. The blast radius of a single compromise is bounded to the workload it lands on until the policy explicitly permits an onward connection.

The implementation pattern does not need to be a particular product or architecture. Whatever delivers identity- and application-aware enforcement at the workload level — host-agent, hypervisor-layer, service-mesh, eBPF, or a combination — qualifies. The standards-body view is implementation-agnostic, which is why none of the citations below name a vendor.

Why it matters

The catalogue is unusually clear on this. NotPetya, in June 2017, weaponised a single compromised Ukrainian accounting-software update into a global IT collapse for Maersk, Merck, FedEx, Mondelēz and dozens of others — because once the wiper was inside the network, the network was flat. Maersk’s recovery story is the canonical worked example: the entire IT environment had to be rebuilt from a single Active Directory domain controller that survived only because it happened to be offline in Ghana when the worm ran. Workload-level enforcement would have stopped the spread at the first or second hop because the wiper’s lateral-movement primitives — Mimikatz-pulled credentials, SMB writes, WMI execution — would have been blocked at every workload boundary it tried to cross.

Colonial Pipeline (May 2021) was a ransomware event on the corporate IT network that forced an OT shutdown precisely because IT-to-OT pivot paths could not be ruled out. Workload-level policy that explicitly disallows IT-server-to-OT-asset connectivity would have answered the ringfencing question definitively. JBS Foods, in the same week, paid eleven million dollars in part for the same reason. Saudi Aramco’s Shamoon attack in 2012 wiped 35,000 workstations because the wiper found no segmentation barriers between user populations — workload-level enforcement at the endpoint tier would have constrained that to a fraction of the footprint.

Ireland’s HSE attack (May 2021) saw Conti spread across essentially every hospital network in the country because the HSE was a federation stitched together at the network layer with minimal internal boundaries. WannaCry, in May 2017, hit the entire NHS England trust network from one infection because internal SMB exposure was unsegmented. Travelex went into administration after Sodinokibi spread across the corporate environment. The Bangladesh Bank SWIFT heist of February 2016 succeeded because the path between business systems and the SWIFT gateway was insufficiently controlled. Cosmos Bank’s FASTCash event in 2018 followed the same pattern in the ATM-to-core-banking direction.

The British Library (October 2023, Rhysida ransomware), Norsk Hydro (March 2019, LockerGoga), and Jaguar Land Rover (late 2025) each had blast-radius problems whose magnitude was dictated by how flat the workload-to-workload connectivity was when the initial intrusion occurred. None of these required exotic attacker capability. What they required was the absence of internal lateral-movement barriers at the workload level.

The nation-state pre-positioning incidents — Volt Typhoon across US critical infrastructure, the broader carrier-level pattern visible in Salt Typhoon and UNC3886 — exploit the same gap from the other direction. Persistent perimeter access only matters if the perimeter is the only thing keeping the attacker from interesting workloads. Workload-level enforcement turns persistent perimeter access into a much weaker capability, because every onward step is a separate, observable, blockable control point.

Where the regulators sit

NCSC’s Cyber Assessment Framework principle B4 (“System security”) requires that “networks and systems are designed and configured to maintain the security of the data they hold and process.” NCSC’s separate Zero Trust Architecture design principles are the clearest UK-government articulation of resource-level enforcement, and frame perimeter-only segmentation as a known anti-pattern. NIST Special Publication 800-207 (“Zero Trust Architecture”) is the foundational international standard and the primary citation for workload-level enforcement. NIST SP 800-46 covers the implications for remote-access architectures.

CIS Controls v8 splits the work across Control 12 (Network Infrastructure Management) and Control 13 (Network Monitoring and Defense), with explicit sub-controls for east-west traffic enforcement and monitoring. The CISA and NSA joint “Network Infrastructure Security Guide” is the clearest plain-English government statement on segmenting against lateral movement. For organisations with operational technology in scope, IEC 62443’s zone-and-conduit model — applied at host level rather than network level — is the right starting point and is mandatory in many jurisdictions. MITRE D3FEND maps workload-level isolation to specific defensive techniques and links them to the ATT&CK lateral-movement tactics they counter.

The framework view is consistent across jurisdictions. The technical case is settled. The disagreement that remains in the literature is about implementation, not about whether to do it.

Where it usually breaks

Workload-based segmentation programmes fail in three places, and the failures are organisational rather than technical.

The first is application discovery. Most enterprises do not have a current map of which workload talks to which workload, on which port, for what business reason. Segmenting at workload level requires that map. Most programmes stall in the discovery phase and never deliver enforced policy. The fix is to instrument first and enforce later — collect connection telemetry across the estate for a quarter before writing a single rule. Discovery is unromantic, unglamorous, and the most common reason a segmentation budget gets cut after twelve months without visible enforcement.

The second is monitor-mode discipline. Enforcing a deny-by-default workload policy on a previously flat estate will break things, because the things were quietly relying on the previously flat estate. The fix is to roll out in monitor-only mode first, surface the unexpected dependencies, normalise the genuine ones, and only then escalate to enforcement zone-by-zone, application-by-application. Trying to enforce everywhere at once is the most common reason segmentation programmes get rolled back and never finished. The discipline of staying in monitor mode for longer than feels comfortable is what separates programmes that ship from programmes that don’t.

The third is OT/IT interface ownership. The boundary between corporate IT workloads and operational-technology workloads is almost always politically contested — neither team wants to own it, both teams have legitimate reasons. The fix is governance, not technology: an explicit owner with explicit authority, a documented policy for every cross-boundary connection, and a regular review cycle. IEC 62443’s zone-and-conduit vocabulary is the right vocabulary for the conversation.

What good looks like

A current map of every workload in the estate, generated continuously rather than as a one-off project. A workload policy framework that is identity-based and application-aware, not address-based. A monitor-mode rollout with a defined transition gate to enforcement, application-by-application, over multiple quarters. A documented and tested cross-boundary connection register, with deviations alerted and reviewed. A separate, tighter policy zone for identity infrastructure (Active Directory, cloud directory, privileged access workstations) with no production-user connectivity into it. For OT-bearing organisations, hard isolation between corporate IT and OT workloads, with a named demilitarised zone for the few necessary interfaces, governed against IEC 62443.

The cost is real and the lift is multi-quarter. The benefit is the difference between a NotPetya-shape outage and a contained one. The catalogue contains both shapes; the choice between them is largely architectural.