11 Microsegmentation and East-West Control

11.1 Design From the Path, Not the Subnet

Allow One Useful Path and Refuse Its Neighbours

Picture a temperature sensor that should send readings to one building service. It shares the site with cameras, door controls, and staff systems. Placing it inside the building network does not explain why it should reach only its own service.

Telemetry means readings and status sent by a remote device. Write one allowed path as a sentence: this named sensor may send this kind of reading to this named service while these conditions hold. Then name the point that checks the request, the evidence it records, and the person who owns the rule.

Try the correct reading, a request for a camera record, a command toward a door, an old identity, and a request after the rule expires. The useful path should remain open. Every neighbouring path should fail closed and leave a clear reason without relying on the sensor’s location as proof of trust.

This small path test does not prove the whole site is secure. The deeper sections show how resource lists, enforcement placement, rule drift, bypass checks, and repeated denial tests limit movement after one device is compromised.

Begin with a single path: a sensor needs to publish telemetry to one service. The zero trust segmentation question is not "which network is the sensor on?" but "which subject may perform which action on which resource, through which enforcement point, and what proves every other path stays closed?"

Traditional segmentation begins with where a device sits: this building, that subnet, this wireless network. Zero trust segmentation begins somewhere else: with the resource that needs protecting and the specific path a requester needs to reach it. Network location can still be a useful signal, but it must not become the reason a device is trusted. The guiding principle, set out in the NIST zero trust architecture, is to never grant access based on location alone and to verify each request against a policy.

The practical consequence is a change in the unit of design. A segment should not mean "everything inside can talk to everything else." The useful unit is an allowed path: a named subject may perform a specific action on a specific resource when the required conditions hold, and everything else is denied. Designing this way directly limits east-west movement, the lateral hops an attacker uses to spread, which is the same as limiting the blast radius of any single compromise.

This overview gives the practitioner a way to stop trusting location: maintain inventory accountability, watch for policy drift, test east-west denials, and look under the hood for any bypass path.

On the left of Figure, the box labelled Flat segment places Sensor, Camera, and Ctrl inside one shared reachability boundary. The line beneath it states the failure directly: Location alone creates broad reachability. Now compare the Approved resource paths panel. Its rows separate Subject from Enforce, and distinguish the Data path from the Device and Cmd path instead of treating every neighbour as trusted. That contrast turns the chapter's abstract design unit into something reviewable: "Sensor group A may publish telemetry to broker topic X through gateway G" names an enforceable path, whereas "sensor group A is on VLAN 40" records only placement. The next sections use that resource-path model to define policy fields and choose enforcement points.

The One-Minute View

Beginner Examples

Work from the simplest case toward the broader design consequence. First, sensors may send telemetry to the intake service through a gateway, but may not talk to each other. Next, controllers accept commands only from the command service, never from a peer device on the same network. Finally, "They are on the IoT VLAN" is not an access decision; the decision is which resource each device may reach, and how.

Overview Knowledge Check

If you can explain why a segment is not a trusted zone and why design starts from resources, you have the core idea. Continue to Practitioner to build the inventory and place enforcement.

11.2 Write and Enforce Allowed Paths

The work is to turn "least access" into reviewable records and to put enforcement where a path can actually be denied. Begin with an inventory that connects each subject group (grouped by purpose, owner, and update support, not just by where they connect) to each protected resource (telemetry intake, command service, configuration store, update service, dashboard, export, management interface), the allowed action, the condition, and the evidence.

Write Allowed Paths, Test Denied Paths

Express policy as paths, not zones. Building sensors may send telemetry to intake through the local gateway; controllers may receive approved commands from the command service, not from peers; maintenance workstations may reach the management interface only through an approved, time-bound workflow; dashboards may read summaries, never raw credentials or update channels. For every allowed path, write the matching denied paths and test them: sensor-to-sensor, sensor-to-command-service, dashboard-to-device-management, and any routine device reaching the update or credential store.

Place Enforcement Where It Can Deny

A policy is only real where something can enforce it. IoT gives you several layers, and a strong design combines them rather than trusting one. Trace Figure from the wireless edge to the service and data store to decide where each allowed path can actually be denied.

In Figure, inspect the layers in traffic order: admission and client isolation at the wireless edge, coarse separation at the network boundary, protocol and endpoint mediation at the gateway, and the final identity-action-resource check at the service. Monitoring records the decisions across those boundaries. The comparison prepares the ledger by showing why one broad firewall rule cannot enforce every path with the same precision.

Record the Policy and Roll Out by Observation

In Figure, inspect the layers in traffic order: admission and client isolation at the wireless edge, coarse separation at the switch or firewall, protocol and endpoint mediation at the gateway, and final identity-action-resource checks at the service. Monitoring closes the loop by recording decisions across those boundaries. Each rule can now name its subject, resource, action, conditions, enforcement point, and evidence. When paths are uncertain, observe first, pilot controlled denials, review exceptions, and expand only when the evidence supports enforcement.

Practitioner Knowledge Check

If you can build the inventory, write allowed and denied paths, and place enforcement that logs its decisions, you can stop here. Continue to Under the Hood for east-west mechanics, accountability, and drift.

11.3 Keep Lateral Movement Denied

The deeper layer explains the mechanics that make or break IoT segmentation: lateral movement, who actually gets identified at the enforcement point, and how policy decays.

North-South Versus East-West

North-south controls govern traffic entering or leaving a broad environment; east-west controls govern traffic between devices, services, and segments inside it. IoT deployments fail at east-west because devices on the same local network can reach peers directly. Microsegmentation enforces per-resource policy so one compromised sensor cannot hop to its neighbour. Use Figure to inspect the denied peer paths, the approved gateway path, the isolated management path, and the monitoring evidence in that order.

Read Figure from the crossed-out peer links toward the approved mediated route. Devices cannot move laterally to neighbours, permitted traffic crosses the gateway, management remains isolated, and monitoring observes both grants and denials. The ordering connects the diagram to the next design constraint: mediation must preserve the originating endpoint's identity or the gateway becomes a blanket pass for the whole group.

Mediation Must Not Erase Accountability

Read Figure from the crossed-out peer links toward the one mediated route. Devices cannot talk laterally, approved traffic passes through the gateway, management remains on a separate controlled path, and monitoring observes both grants and denials. Gateways are essential for constrained endpoints, but mediation must preserve the originating identity rather than forwarding everything under one shared credential. Otherwise the service loses per-device accountability and quietly recreates the trusted zone the diagram is designed to remove.

Wireless Lateral Movement

Wireless groups need explicit treatment, because a shared wireless network can become an accidental trusted zone. Without separate admission for IoT, management, guest, and operator devices, and without client isolation, wireless peers can still discover and reach each other even when the wired policy looks tight. Wireless lateral paths must be tested directly, not assumed to be covered by segment labels.

Drift and the Limits of Observe Mode

Segmentation decays as new devices, support paths, firmware behaviors, temporary exceptions, and emergency workarounds are added without review. Drift is therefore monitored, not assumed away: watch for new subjects in a segment, new destinations from a subject group, denied lateral attempts and scan patterns, allowed paths with unexpected volume or timing, expired or repeated exceptions, and enforcement points with missing or stale logs. And because routing changes and workarounds can reopen a closed path, denied-path tests are repeated, not run once at rollout.

Mechanisms and Failure Modes

Common Pitfalls

Review these failure modes in order. First, Treating a segment as trusted. Membership is not permission; deny peer paths unless a specific reason and test exist. Next, Ignoring management and update paths. These high-impact paths need their own records, stronger conditions, and review. Then, Forgetting wireless lateral movement. Test wireless peer paths directly; admission and client isolation are easy to get wrong. Then, Never retesting denied paths. Routing changes and workarounds reopen paths, so deny tests must repeat. Finally, Losing endpoint identity at the gateway. Preserve which endpoint caused each request, or accountability disappears.

Under-the-Hood Knowledge Check

At this depth, zero trust segmentation is a resource-path discipline enforced where it can deny: allowed paths instead of trusted zones, east-west controls that limit blast radius, gateway mediation that keeps endpoint identity, wireless isolation that is tested directly, and drift monitoring that repeats its deny tests. A trustworthy review asks which resource each path reaches, where it is enforced, whose identity the service actually sees, and what proves the denied paths stay denied.