Why do IoMT devices complicate microsegmentation planning?

Why This Matters for Security Teams

IoMT planning is difficult because segmentation is not just a network design exercise. It is a risk decision that affects patient care, device availability, and incident containment at the same time. A device that cannot tolerate active scanning, agent deployment, or frequent policy changes may force a different control pattern than a modern server. That is why security teams should treat IoMT as a special population, not a minor exception inside standard enterprise zoning.

The practical challenge is that many IoMT devices were built for persistence, not rapid reassignment. They may use fixed IPs, outdated protocols, proprietary management interfaces, or vendor support models that assume flat networks. When those realities meet aggressive microsegmentation, teams can create outages, disrupt monitoring, or break clinical workflows. Current guidance suggests that segmentation should follow business criticality and device behavior, not simply asset type. The NIST Cybersecurity Framework 2.0 is useful here because it frames segmentation as part of broader risk management rather than a standalone technical pattern.

Security teams also miss the identity dimension. Many IoMT devices are effectively non-human identities with limited authentication options, fixed trust relationships, or embedded credentials that are hard to rotate. In practice, many security teams encounter IoMT segmentation failure only after a blocked device disrupts treatment delivery or a legacy protocol is exposed during a containment event, rather than through intentional planning.

How It Works in Practice

Effective microsegmentation for IoMT starts with visibility. Teams need to know what each device talks to, which services are mandatory, and what normal communication looks like under clinical load. Without that baseline, policy design becomes guesswork. Best practice is to map device communication paths before enforcement, then gradually move from permissive observation to restrictive controls.

A workable approach usually combines several layers:

• Asset identification and classification so the device is grouped by function, vendor, and clinical criticality.
• Traffic discovery using passive monitoring, since active probing can be unsafe for some devices.
• Policy design around allowed flows, not broad subnet membership.
• Exception handling for vendor maintenance, emergency access, and life-safety workflows.
• Continuous review of policy drift as firmware, applications, or clinical use cases change.

This is where segmentation intersects with identity governance. If a device authenticates to a management plane, update service, or clinical application, that machine identity should be treated as a privileged trust relationship. In many environments, the control problem is less about blocking every lateral movement path and more about reducing the blast radius of credentials, services, and protocols that cannot be modernised quickly. NIST guidance on secure architecture and least privilege is relevant, and the operational logic aligns well with the NIST Cybersecurity Framework 2.0 because it emphasises governance, protection, detection, and recovery together.

Where possible, teams should isolate IoMT through dedicated VLANs, software-defined policies, and controlled jump paths for administration. However, segmentation should not be treated as a one-time project. Device inventories, clinical workflows, and vendor dependencies change over time, so rules must be validated continuously against live traffic and incident response needs. These controls tend to break down when devices share mandatory services across many departments because the dependency graph becomes too broad for narrow policy enforcement.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance containment against uptime and clinical continuity. That tradeoff becomes sharper in environments with infusion pumps, imaging systems, bedside monitors, or remote service requirements, where even short interruptions can be unacceptable. Best practice is evolving, but there is no universal standard for how granular IoMT microsegmentation should be in every hospital or care setting.

One common edge case is vendor-managed remote access. Some devices depend on outbound connections to proprietary services, certificate-based trust, or remote diagnostics channels that cannot be replaced quickly. Another is shared infrastructure, where multiple devices rely on the same update servers, domain services, or PACS-related dependencies. In those cases, policy must distinguish between the clinical function and the surrounding support path, otherwise the segmentation plan becomes too brittle to operate safely.

Another nuance is that older devices may not support modern authentication or encryption controls, so teams may need compensating safeguards such as protocol restriction, physical isolation, enhanced monitoring, and tighter administrative access. The NIST Cybersecurity Framework 2.0 remains useful because it allows organisations to document risk-based exceptions instead of pretending all assets can meet the same control baseline. For healthcare-specific threat modelling, current guidance from MITRE ATT&CK helps teams think about how stolen credentials, remote services, and lateral movement actually behave in mixed legacy environments.

Related resources from NHI Mgmt Group

• Why do identity providers complicate disaster recovery planning?
• Why do shared clinical devices complicate high assurance authentication?
• Why do OT devices complicate certificate governance more than standard IT assets?
• Why does microsegmentation matter for unpatchable medical devices?