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 This Matters for Security Teams
Unpatchable OT and IoMT devices are not just “old assets.” They are durable footholds that attackers can abuse long after the original vulnerability is understood. In a flat network, every reachable service becomes part of the blast radius, so one compromised sensor, controller, or medical device can expose adjacent systems, shared credentials, and management interfaces. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing non-human identities is essential for zero trust, which is directly relevant when those devices depend on long-lived machine credentials.
The operational mistake is assuming patching is the primary control. For these environments, containment is often more important than remediation because many OT and IoMT systems cannot tolerate downtime, agent installation, or rapid firmware changes. Zero Trust guidance from NIST SP 800-207 Zero Trust Architecture is useful here because it shifts the question from “is the device trusted?” to “is this specific flow allowed right now?” In practice, many security teams encounter the failure only after an attacker uses a single weak protocol or shared credential to move laterally, rather than through intentional segmentation design.
How It Works in Practice
Flat networks collapse trust boundaries. If an unpatchable device shares the same broadcast domain as workstations, servers, historians, or IoMT management consoles, an attacker who reaches any one exposed service can probe everything else that answers on the network. In OT, that may mean engineering stations, PLCs, remote access gateways, or vendor maintenance channels. In IoMT, it may mean imaging devices, nurse stations, or device management systems. The issue is not only exploitation of the device itself. It is also credential reuse, permissive firewall rules, legacy protocols, and hidden trust relationships.
Containment usually starts with segmentation that reflects operational reality rather than organizational charts. Best practice is evolving, but current guidance generally favors:
- Separating device classes into dedicated network zones with deny-by-default policy.
- Restricting east-west traffic so the device can only talk to the minimum required collector, controller, or update server.
- Using protocol-aware controls where industrial or medical protocols must be permitted.
- Applying stronger authentication for admin and maintenance paths, especially where shared accounts still exist.
- Logging device-to-device connections so lateral movement is visible even when the device cannot be patched.
NHI Mgmt Group’s Schneider Electric credentials breach is a useful reminder that attackers often do not need a novel exploit when credentials and reachable paths are available. That risk maps closely to device fleets that keep long-lived secrets in place for years. For broader identity hygiene, the Ultimate Guide to NHIs also highlights how common excessive privilege and weak rotation remain across non-human identities.
These controls tend to break down when flat network design is preserved for vendor convenience, because segmentation exceptions quickly become permanent trust paths.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance uptime and vendor support against exposure reduction. That tradeoff is especially sharp in OT and clinical settings where legacy systems depend on broad connectivity, time-sensitive traffic, or remote maintenance windows. There is no universal standard for every environment, but the safest answer is usually to constrain connectivity first and expand only where a documented business need exists.
Edge cases matter. Some devices cannot sit behind aggressive proxies or TLS inspection. Some may fail if VLAN changes break discovery, multicast, or time sync. Others are so critical that full isolation is impossible, which means compensating controls become the real answer: jump hosts, protocol gateways, strict admin separation, and continuous monitoring of outbound sessions. For Internet-connected IoMT, the risk is often compounded by third-party servicing models and weak asset inventory. For OT, a flat network can also hide unsafe trust between the control plane and the corporate IT plane, making a compromise in one zone immediately relevant to the other.
The emerging consensus is that unpatchable devices should be treated as permanently high risk, not as temporary exceptions. Where possible, pair segmentation with identity-aware access decisions and device-specific allowlists. Where that is not possible, document the residual risk and monitor for any flow that does not match the approved operational pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived machine credentials on flat networks increase exposure and lateral movement. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be limited to the minimum network paths the device truly needs. |
| NIST Zero Trust (SP 800-207) | Zero Trust directly addresses flat-network trust assumptions that enable lateral movement. | |
| NIST AI RMF | Risk management should account for persistent operational exposure from unpatchable assets. | |
| NIS2 | Critical sectors must reduce systemic exposure from legacy devices and weak segmentation. |
Use segmentation, logging, and incident readiness to reduce blast radius in critical environments.
