Segmentation limits what a device can reach, which reduces the paths an attacker can use after compromise. Monitoring watches for behavior that deviates from baseline, such as unexpected communications or suspicious services. Segmentation is preventive control, while monitoring is detective control. Hospitals need both because no policy can perfectly anticipate every misuse, and some risk only becomes visible once the device behaves abnormally.
How segmentation changes exposure for connected medical devices
Segmentation is about constraining reach. For connected medical device, it reduces the number of hosts, services, and network paths a device can talk to, which shrinks the blast radius if the device is abused, misconfigured, or already compromised. That matters in hospitals because these devices often sit beside clinical systems, but they should not have free movement across the broader network.
In practice, segmentation is strongest when it is designed around clinical function and trust boundaries, not just IP ranges. A device that only needs to talk to a management server, a PACS, or a vendor update service should not be able to initiate arbitrary east-west traffic. NHIMG’s Network Segmentation Guide is useful here because it frames zones, east-west control, and blast-radius reduction as the core design problem.
Segmentation is also where hospitals decide how strict they want the device boundary to be. Some programs use broad network zones, while others move toward microsegmentation, especially for high-risk devices or shared clinical environments. The key operational point is that segmentation limits what a device can reach, even if the device itself never alerts on anything unusual.
What device monitoring tells you that segmentation cannot
Device monitoring answers a different question: what is the device doing right now, and does that behavior match the baseline? It looks for abnormal communications, new services, unusual ports, suspicious DNS activity, or changes in timing and volume that can indicate misuse or compromise. Where segmentation prevents or narrows paths, monitoring exposes deviations that a fixed policy cannot anticipate in advance.
That distinction matters because a medically critical device may still need to communicate inside its allowed zone, and an attacker may operate entirely within permitted routes once they gain access. Monitoring is what lets defenders notice when a device starts behaving like something else, even if the traffic technically stays inside an allowed segment.
For connected medical environments, monitoring is most valuable when the baseline is realistic and specific to the device class. A scanner, infusion pump, imaging platform, and bedside monitor do not generate the same normal traffic patterns. NHIMG’s Medical Device Security Guide is a good companion reference because it keeps the discussion anchored in medical-device lifecycle and postmarket controls rather than generic IT monitoring.
Why hospitals usually need both controls
Segmentation and monitoring are complementary, not interchangeable. Segmentation is preventive control, so it reduces exposure before an event becomes visible. Monitoring is detective control, so it helps confirm whether something abnormal is already happening. In healthcare, relying on only one leaves a gap: segmentation can be too coarse to stop every misuse, and monitoring can be too late if the device should never have had the route in the first place.
A practical way to think about it is this: segmentation limits the attacker’s options after compromise, while monitoring helps reveal that compromise or misuse is occurring. In regulated or safety-sensitive environments, that combination is stronger than either control alone because it supports both containment and response.
Hospital teams often underestimate how much hidden device traffic exists until they start watching it. That is why a real program pairs network design with asset visibility, alerting, and incident response ownership. NHIMG’s IoT Security Guide is useful for the broader device-population view, while the NIST Cybersecurity Framework 2.0 helps frame the preventive and detective functions together.
Risk and Threat Considerations
Connected medical devices are attractive targets because they often combine long service lives, inconsistent patching, and tightly coupled clinical workflows. If segmentation is weak, an attacker who reaches one device may gain a bridge into adjacent systems. If monitoring is weak, abnormal behavior can persist long enough to affect availability, integrity, or safety before anyone notices.
Failure mechanism: The device either has too much network reach or behaves in a way that blends into normal traffic, allowing misuse, lateral movement, or persistence to continue without timely containment.
Impact: The result can be broader exposure of clinical systems, delayed detection of compromise, disrupted care delivery, and a harder incident response because teams cannot easily distinguish legitimate device chatter from malicious activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Segmentation is enforced by controlling allowed network flows. |
| Recommendation — Define and enforce approved device communication paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Device reach should be restricted to only what its function requires. |
| DE.CM-01 — Networks and network services are monitored | Monitoring connected devices depends on observing network behavior for anomalies. | |
| PR.DS-01 — Data-at-rest is protected | Medical devices can expose sensitive data if network paths are overly broad. | |
| Recommendation — Limit each device to the minimum network access it needs. Monitor device traffic for deviations from baseline. Reduce the chance of unintended data exposure from device communications. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Segmentation and network controls are core to protecting connected devices. |
| Recommendation — Separate device traffic into controlled network zones. | ||
Practitioner Guidance
What to verify: Confirm the device’s minimum required destinations, protocols, and ports, then test whether any unexpected outbound or east-west traffic is still possible. If a device can reach more than its clinical function requires, segmentation is not yet doing its job.
Decision rule: Use segmentation to reduce reach first, then use monitoring to validate whether the residual traffic pattern is normal. If you can only choose one to implement immediately, prioritize segmentation for containment, but do not treat that as a substitute for telemetry.
What good looks like: The device can communicate only with explicitly approved services, alerts are tuned to device-specific baselines, and security staff can explain which behaviors are normal versus suspicious without guessing.
Practitioner takeaway: For medical devices, segmentation answers “where can it go?” and monitoring answers “what is it doing?” A mature program needs both, because one reduces blast radius and the other reveals compromise or misuse that the first control cannot see.
Related resources from NHI Mgmt Group
- What is the difference between traditional network segmentation and identity based microsegmentation for healthcare devices?
- What happens when a hospital network is breached without effective segmentation around connected medical devices?
- What is the difference between device posture checks and network segmentation in a remote access environment?
- What is the difference between tokenized device payments and exposing a card number to connected devices?