Why do IoMT environments need identity-based policy instead of network-only controls?

Why This Matters for Security Teams

IoMT environments are operational technology with patient care consequences, so the security model has to reflect who or what is actually acting, not just where traffic originates. A ventilator, infusion pump, nurse workstation, and maintenance script can all be legitimate participants, yet they do not deserve the same access. That is why identity-based policy matters more than network-only segmentation in clinical settings. The NIST Cybersecurity Framework 2.0 emphasizes governance, asset visibility, and protective controls that are grounded in business context rather than convenience.

Network controls still matter, but they are too blunt on their own. Flat VLANs, IP allowlists, and port-based rules can hide trust assumptions until an attacker, contractor laptop, or misconfigured device lands inside the right subnet. In IoMT, the harder problem is not merely stopping external traffic. It is preventing overbroad access between devices, users, and service identities that were never meant to be interchangeable. Identity-based policy gives teams a way to express that distinction clearly.

In practice, many security teams encounter IoMT exposure only after a device compromise, lateral movement event, or clinical outage has already exposed how weak the trust model was.

How It Works in Practice

Identity-based policy in IoMT ties access decisions to a combination of device identity, user identity, workload identity, and context. Instead of asking only whether a connection comes from the right subnet, teams ask whether the requester is a known pump, a managed clinician account, a maintenance tool, or a vendor service identity, and whether the action is appropriate for that role. This aligns closely with NIST SP 800-207 Zero Trust Architecture, where trust is continuously evaluated and access is scoped as narrowly as possible.

Operationally, this usually means combining several layers:

• Asset inventory that distinguishes bedside devices, shared workstations, and back-end services.
• Strong device identity, such as certificates or attestation, so the policy engine can recognize managed assets.
• Role-aware access rules that separate clinical workflow access from maintenance and vendor support.
• Continuous validation of session context, including location, time, and whether the request matches expected behavior.
• Logging into SIEM or SOAR so anomalous device-to-device or account-to-device activity can be investigated quickly.

This approach is especially important where service accounts, API keys, and embedded credentials are used to keep legacy devices operational. Without identity-based rules, those secrets can become permanent bypasses around segmentation. The same pattern shows up when hospital systems rely on shared admin accounts, unmanaged biomedical equipment, or vendor remote support paths that were never engineered for least privilege. Identity becomes the policy anchor that lets the network enforce intent rather than just connectivity.

These controls tend to break down when devices are legacy, cannot support certificates or modern agents, and must remain reachable through shared services because the technical stack cannot expose reliable identity signals.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance clinical availability against access precision. In well-managed environments, that tradeoff is acceptable. In mixed-vendor estates, it can become difficult because some devices support modern authentication while others only speak fixed protocols or depend on embedded secrets.

Best practice is evolving for these cases. There is no universal standard for how much identity telemetry every IoMT device must provide, so teams often combine compensating controls such as microsegmentation, jump hosts, protocol-aware gateways, and strict vendor access windows. The goal is not to force every device into the same trust model. It is to prevent the weakest class of device from setting policy for the entire environment.

Identity-based policy is also more effective when paired with procurement and onboarding requirements. If a device cannot present a manageable identity, the organisation should decide in advance whether it will be isolated, proxied, or excluded. That matters because clinical networks often contain a long tail of equipment with inconsistent support lifecycles. Where identity is not available, network-only controls may still reduce exposure, but they should be treated as a fallback, not the primary trust model.

Current guidance suggests that hybrid models are often the most realistic path in healthcare: identity-first for supported assets, compensating segmentation for legacy equipment, and explicit exceptions for vendor support flows that are documented and monitored.

Related resources from NHI Mgmt Group

• What breaks when network controls are used instead of request-level policy for machine access?
• What is the difference between Kubernetes network policy and identity-based access control?
• Why are identity-based attacks growing faster than traditional network attacks?
• What is the difference between network controls and identity controls for infrastructure access?