11 Microsegmentation and East-West Control
Resource Paths, Microsegments, Enforcement Points, and Evidence for IoT
zero trust network segmentation, IoT microsegmentation, east-west traffic control, policy enforcement point, gateway mediation, segmentation evidence, NIST SP 800-207
11.1 Design From the Path, Not the Subnet
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.
If you only need the intuition, this layer is enough: name the protected resources, allow only the paths each subject genuinely needs, put enforcement where a path can actually be denied, and keep evidence that denied paths stay denied. A VLAN by itself is a label, not a control.
A useful segment definition therefore names the subject, resource, action, enforcement location, and evidence expected from the decision. For example, “sensor group A may publish telemetry to broker topic X through gateway G” is enforceable and testable. “sensor group A is on VLAN 40” is only a placement fact unless the allowed and denied paths are also defined.
The One-Minute View
Resources first, not location
Start from what must be protected and who needs it, not from which subnet a device happens to join.
Allowed path, not trusted zone
A segment is not a container of mutual trust. The unit is a specific subject, action, and resource under conditions.
Limit east-west movement
Denying lateral device-to-device hops shrinks the blast radius when one device is compromised.
Beginner Examples
- Sensors may send telemetry to the intake service through a gateway, but may not talk to each other.
- Controllers accept commands only from the command service, never from a peer device on the same network.
- “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.
Record the Policy and Roll Out by Observation
Each microsegmentation rule should read as a reviewable record: subject, resource, allowed action, conditions (identity, device state, gateway observation, time window, owner approval), enforcement point, and evidence (allowed-path test, denied-path test, logs, exceptions, review date). When current paths are uncertain, start in observe mode to learn real traffic safely, then draft allowed and denied records, test denials in a controlled way, enforce a small pilot, review exceptions and monitoring coverage, and expand by waves only when the evidence supports it. Observe mode is a way to learn before blocking, not a substitute for 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 more than anywhere else, because many devices sit on the same local network and can reach each other directly. Microsegmentation is the answer: enforce per-resource policy at a point that can deny, so a compromised sensor cannot simply hop to its neighbor. The concrete moves are to deny peer-to-peer traffic unless a workflow requires it, route device traffic through an enforcement point that logs decisions, separate management paths from telemetry, and block routine devices from command, update, and credential services.
Mediation Must Not Erase Accountability
Gateways are essential for constrained and older devices, but they create a subtle failure: if a gateway authenticates upstream with a single shared credential and forwards everything as itself, the service sees only the gateway and loses track of which endpoint caused each request. That collapses per-subject accountability and per-request authorization, quietly recreating a trusted zone behind the gateway. A correct mediation binds each request to the originating endpoint’s identity, narrows the actions each endpoint may invoke, and keeps logs at both the gateway and the service, so a single authenticated gateway does not become a blanket pass.
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
- Treating a segment as trusted. Membership is not permission; deny peer paths unless a specific reason and test exist.
- Ignoring management and update paths. These high-impact paths need their own records, stronger conditions, and review.
- Forgetting wireless lateral movement. Test wireless peer paths directly; admission and client isolation are easy to get wrong.
- Never retesting denied paths. Routing changes and workarounds reopen paths, so deny tests must repeat.
- 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.
11.4 Summary
- Zero trust segmentation starts from protected resources and allowed paths, not from network location; the NIST zero trust architecture rejects trusting a device because of where it connects.
- The unit of design is an allowed path, a named subject performing a specific action on a specific resource under conditions, not a trusted zone where everything inside can talk freely.
- Build an inventory linking subject groups, resources, allowed actions, conditions, enforcement points, and evidence, grouping subjects by purpose rather than by where they connect.
- Control east-west (lateral) movement to limit blast radius: deny peer-to-peer traffic, route through enforcement points, and block routine devices from command, update, and credential services.
- Place enforcement where it can deny, combining the wireless edge, network boundary, gateway, and service boundary, and avoid single-point designs that trust the network to be perfect.
- Gateway mediation must preserve endpoint identity; a shared upstream credential collapses accountability and recreates a trusted zone.
- Wireless groups need separate admission and client isolation, and wireless lateral paths must be tested directly.
- Roll out from observe to enforce, keep per-path allow and deny tests, and monitor drift with repeated deny tests and new-destination alerts.
Segmentation limits the blast radius of a compromise, but only if it is built from resources and allowed paths rather than from trusted network zones. Write each path as subject, action, resource, and condition; enforce it where it can be denied; keep endpoint identity through every gateway; and re-run the deny tests as the network drifts. A VLAN with a friendly name is not zero trust.
11.5 See Also
Zero Trust Fundamentals
Review never-trust, always-verify, least privilege, and per-request decisions behind segmentation.
Zero Trust Architecture
Connect segments to the policy engine, policy administrator, and enforcement points.
Zero Trust Device Identity
Strengthen the subject identity that every allowed-path decision depends on.
Security Control Implementation
Connect segmentation evidence to the broader set of tailored, owned security controls.