Flat networks turn a single vulnerable device into a lateral movement path. If the asset cannot be patched, attackers only need one reachable service, one weak credential, or one trusted protocol to pivot. The control failure is not the flaw itself, but the absence of network containment around a long-lived device that cannot be remediated in place.
Why Flat Network Design Becomes a Containment Failure for Unpatchable Devices
When an OT or IoMT device cannot be patched, the main security question shifts from fixing the endpoint to containing its reachable surface. A flat network removes that containment layer, so compromise of one device or one adjacent system can expose protocols, services, and trust relationships that were never meant to be widely reachable. That is especially dangerous in environments where uptime matters more than software replacement, because the device may remain in service for years after its original risk profile has changed.
For OT, this often means segmentation failure turns a single legacy asset into an entry point to engineering workstations, historians, controllers, or remote access paths. For IoMT, the same pattern can create exposure around patient systems, administrative interfaces, or other connected clinical assets. NIST’s NIST SP 800-207 Zero Trust Architecture is useful here because it frames the core issue as trust reduction and access containment rather than assuming any connected device is inherently safe. In practice, many security teams discover the operational cost of flat networking only after a legacy device is already being used as a pivot point.
How the Failure Chain Usually Unfolds in OT and IoMT Environments
Unpatchable devices are not automatically insecure in every deployment, but they become materially harder to defend when they share broad broadcast domains, permissive routing, or trust inherited from the rest of the network. The failure chain usually starts with reachability. If the device is visible to too many hosts, then an attacker, misconfigured system, or infected maintenance workstation has more opportunities to interact with it. From there, a single exposed management service, default credential, weak password, or legacy protocol can be enough to move laterally.
In OT, that lateral movement may be enough to reach supervisory systems, jump hosts, engineering tools, or credential stores that increase operational impact even if the original device itself is limited in function. In IoMT, the consequence is often less about direct device takeover and more about access to adjacent systems, administrative workflows, or connected clinical networks. The practical issue is that flat design makes trust transitive: once one node is reachable, many others are implicitly treated as reachable too.
- Containment weakens when VLANs, ACLs, and policy boundaries are absent or too coarse to isolate older assets.
- Exposure rises when legacy protocols remain broadly routable instead of being restricted to known peers.
- Detection becomes harder when normal east-west traffic looks routine across the whole subnet.
- Recovery becomes slower when the unpatchable asset cannot be quickly remediated and must instead be isolated operationally.
This guidance breaks down when the environment is so operationally constrained that segmentation cannot be enforced without redesigning the workflow or introducing dedicated compensating controls.
Where the Edge Cases and Trade-offs Show Up
Tighter segmentation often increases operational overhead, so organisations have to balance availability, vendor support, and field-service convenience against the need to contain long-lived devices. The trade-off is real: some OT and IoMT deployments cannot tolerate frequent readdressing, deep packet inspection, or aggressive change windows, yet those same constraints make flat networks even more dangerous.
One common edge case is a device that is unpatchable but not directly internet-facing and appears low risk. That can be misleading. If the device is on a flat network, the real question is not whether it is externally reachable, but whether any nearby host can be used to reach it and then expand access. Another edge case is where the device uses a trusted protocol that is considered operationally necessary. In that case, the protocol itself may be legitimate, but the trust boundary around it is often too wide. Guidance-vs-consensus matters here: there is broad agreement that segmentation helps, but there is less consensus on how much microsegmentation or protocol restriction is practical in highly regulated or safety-critical environments.
For practitioners, the strongest approach is to treat unpatchable assets as long-term containment problems, not one-time hardening problems. The more critical the device, the more important it is that adjacent hosts, routes, and allowed services be explicitly justified rather than inherited by default.
Risk and Threat Considerations
Flat networks create a material exposure problem because they turn a vulnerable legacy device into a lateral movement foothold. The risk is not limited to the device itself; it extends to whatever else becomes reachable through shared trust, shared services, or shared management paths.
Failure mechanism: An attacker, compromised workstation, or misconfigured maintenance path reaches the unpatchable device, then abuses an allowed service, credential, or trusted protocol to pivot to adjacent systems. The mechanism is trust amplification across a network that lacks meaningful containment.
Impact: The result can be broader operational disruption, loss of control over connected assets, exposure of sensitive administrative systems, and a larger remediation burden because the original device cannot be fixed in place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Flat networks weaken access boundaries around legacy devices and peer trust. |
| DE.CM — Security Continuous Monitoring | Lateral movement across flat networks depends on poor visibility into east-west traffic. | |
| RS.MI — Mitigation | Unpatchable devices require compensating containment rather than endpoint remediation. | |
| Recommendation — Segment device reachability and restrict access paths to only required peers. Monitor lateral traffic to detect unexpected device-to-device communication. Apply compensating network controls to reduce blast radius when patching is impossible. | ||
| CIS Controls v8 | 6 — Access Control Management | Legacy OT and IoMT assets fail when broad network access is left in place. |
| 13 — Network Monitoring and Defense | Flat networks hide suspicious east-west movement and weak containment. | |
| Recommendation — Restrict and review access to unpatchable devices and their management interfaces. Inspect east-west traffic for unexpected pivots through legacy devices. | ||
| NIST AI RMF | MAP — Map | For IoMT-adjacent AI or monitoring systems, asset and dependency mapping defines exposure. |
| Recommendation — Map device dependencies and reachable trust paths before allowing connected automation. | ||
Practitioner Guidance
What to prioritise: Start with containment around the device, not with perfection at the endpoint. If the asset cannot be patched, its surrounding access paths, peers, and management routes become the control surface that matters most.
What to verify: Confirm which hosts, ports, and protocols truly need to reach the device, and which relationships exist only because the network is flat. The key test is whether a device remains reachable after unnecessary east-west paths are removed.
What good looks like: The device has a clearly documented trust boundary, minimal routable exposure, and a deliberate exception process for any required legacy access. If those elements are missing, the environment is still treating a containment problem as if it were an endpoint problem.
Practitioner takeaway: The decisive control is not patch status but blast-radius reduction, because unpatchable devices are only manageable when their network reach is intentionally narrow.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
