By NHI Mgmt Group Editorial TeamPublished 2026-02-04Domain: Cyber SecuritySource: Elisity

TL;DR: Claroty argues that medical device security depends on continuous visibility, evidence-based risk scoring, and network enforcement across IoMT and OT, with Team82 research showing over 650 vulnerabilities disclosed and KEVs present in 99% of 351 healthcare organisations studied. The real issue is not whether devices can be scanned, but whether identity-aware controls can keep pace with clinical reality.


At a glance

What this is: This is an analysis of how Claroty approaches medical device security through visibility, risk scoring, and enforced least-privilege access across healthcare IoMT and OT environments.

Why it matters: It matters because healthcare teams need device intelligence that can support segmentation, remediation, and governance decisions without disrupting clinical operations or over-trusting unmanaged connected assets.

By the numbers:

👉 Read Elisity's analysis of Claroty's medical device trust model


Context

Medical device security in healthcare depends on knowing what is connected, how it behaves, and what risk it introduces before teams can safely apply controls. The article is about continuous device visibility and risk-aware enforcement for IoMT and OT, with a clear identity angle where device attributes become the basis for policy.

That matters because healthcare environments cannot rely on aggressive scanning, static CMDB records, or broad network trust when clinical devices have long lifecycles and vendor constraints. Claroty's model sits at the intersection of device governance and identity-based access control, which is where modern segmentation and remediation decisions now converge.


Key questions

Q: What breaks when healthcare teams do not know which connected devices are on the network?

A: When teams lack accurate device visibility, they cannot segment effectively, prioritise remediation, or prove that risky assets are under control. In healthcare, that failure is amplified by proprietary protocols, long-lived devices, and clinical uptime constraints. The result is trust by assumption rather than by evidence, which creates avoidable exposure for IoMT and OT environments.

Q: Why do IoMT and OT devices complicate zero trust in hospitals?

A: IoMT and OT devices complicate zero trust because many cannot run agents, patch quickly, or tolerate aggressive scanning, yet they still need precise access boundaries. The answer is not to exempt them from policy, but to enrich device context and enforce least privilege at the network edge. That is how hospitals avoid broad trust based on location alone.

Q: How do security teams know if device risk scoring is working?

A: Risk scoring is working when it changes prioritisation, not just reporting. Teams should see KEV-bearing, internet-exposed, and clinically critical devices move to the top of segmentation and remediation queues, while low-risk devices stay low priority. If the score does not alter network policy or work order sequencing, it is just a dashboard metric.

Q: Who should be accountable for compensating controls on legacy medical devices?

A: Accountability should sit jointly with security, clinical engineering, and operations, because legacy medical devices are governed by both patient-safety requirements and cybersecurity risk. Organisations need named owners for exceptions, documented compensating controls, and review cycles tied to device lifecycle status. Without that, exception handling becomes permanent trust.


Technical breakdown

How device visibility works across IoMT and OT environments

Claroty combines passive monitoring, safe queries, edge collection, project file analysis, and ecosystem enrichment to build device profiles without disrupting clinical operations. The technical point is that healthcare networks need non-invasive discovery because many devices speak proprietary protocols, have strict uptime requirements, or cannot tolerate active scanning. That makes visibility a continuous correlation problem, not a one-time inventory exercise. The platform attributes device type, firmware, communication patterns, and clinical function so security teams can reason about risk in context rather than in isolated asset lists.

Practical implication: validate that discovery methods are safe for clinical environments before using them as the basis for policy or remediation.

Why risk scoring matters more than raw vulnerability counts

The article describes a dynamic risk score that weighs known exploited vulnerabilities, ransomware linkage, internet exposure, OS lifecycle status, and clinical criticality. This is a better security model than raw CVSS because it ranks devices by exploitability and operational importance, which is what actually drives containment priorities. In practice, a legacy imaging device with a KEV and internet exposure should be treated very differently from a patched device with the same nominal vulnerability score. Risk scoring becomes the bridge between vulnerability management and operational decision-making.

Practical implication: prioritise remediation and segmentation by exploitability, exposure, and clinical impact rather than by CVSS alone.

How device identity feeds least-privilege network enforcement

Claroty's value in the article is not just identifying assets, but supplying attributes that enforcement platforms can turn into network policy. That creates a device identity model where risk score, device type, and operating context determine access boundaries, which is the same logic security teams apply in other identity programmes. This is especially relevant for healthcare because many devices cannot host agents or support traditional endpoint control. The architecture works when visibility outputs are translated into identity-based policy at the network edge.

Practical implication: connect device intelligence to segmentation enforcement so discovery results become active controls, not dashboard output.


Threat narrative

Attacker objective: The attacker aims to reach high-value healthcare devices or supporting OT systems in ways that create disruption, lateral movement, or leverage for ransomware-style impact.

  1. Entry begins with unmanaged IoMT or OT exposure, including devices that are internet-connected, insufficiently inventoried, or operating with outdated lifecycle status.
  2. Escalation follows when known exploited vulnerabilities and ransomware-linked weaknesses remain unsegmented, giving an attacker a path from device visibility gaps to broader network reach.
  3. Impact occurs when critical clinical or building systems are disrupted, forcing security teams to prioritise containment under operational and patient safety constraints.

NHI Mgmt Group analysis

Device intelligence has become an access-control input, not just an inventory function. The article shows why healthcare teams can no longer treat IoMT discovery as a reporting exercise. When device attributes feed segmentation and enforcement, visibility becomes part of the control plane. That shifts the governance question from 'what do we have?' to 'what are we allowing it to do?' and that is where identity-style policy thinking belongs.

Healthcare has a genuine device identity problem, even when the assets are not human or cloud-native. IoMT and OT devices behave like enduring non-human identities because they must be recognised, profiled, and constrained over long lifecycles. The governance challenge is similar to NHI lifecycle management: stale records, unmanaged connectivity, and unreviewed trust accumulate until enforcement becomes guesswork. Practitioners should treat device identity as a governed control surface, not a passive asset label.

Risk-based prioritisation is the only practical path when patching is constrained by clinical operations. The article correctly recognises that many medical devices cannot be fixed on an IT timetable. That makes exploitability, internet exposure, and clinical criticality the deciding factors in which devices get segmented first. Security programmes that still rely on broad vulnerability counts are effectively managing noise, not exposure, and that is a governance failure.

Claroty's model validates a broader convergence between CPS security and identity-based policy. The important shift is not the vendor, but the architecture: device intelligence plus enforcement. That pattern is increasingly necessary in environments where security tools must interpret identity, context, and operational constraints together. Practitioners should expect more security decisions to be made from enriched asset identity rather than from scan results alone.

Named concept: clinical trust decay. In healthcare environments, trust in connected devices erodes over time as lifecycle status, exposure, and vulnerability state drift out of sync with the assumptions that originally allowed them onto the network. The article shows that this decay is measurable and operationally relevant. Teams should manage trust as a continuous state, not a one-time approval.

What this signals

Healthcare security programmes should expect identity-aware policy to move deeper into operational technology, especially where device attributes become enforcement inputs. The practical shift is that inventory, segmentation, and exception handling will increasingly be judged as one governance workflow rather than separate controls.

Clinical trust decay: the longer a connected medical device remains outside active governance, the more its original trust assumption diverges from reality. That creates a need for continuous reassessment, especially where patching is delayed by clinical validation cycles and vendor support constraints.

The strongest programmes will connect device intelligence to policy enforcement and exception review through the same operating model. For readers working across NHI and healthcare security, the lesson is simple: unmanaged device identity is now a security control gap, not just an asset management issue.


For practitioners

  • Build a device identity register Create a living inventory that records device type, firmware, communication behaviour, clinical function, and lifecycle status so segmentation and remediation decisions have current context.
  • Prioritise KEV-bearing devices first Use known exploited vulnerabilities, ransomware linkage, internet exposure, and clinical criticality to rank IoMT and OT devices for containment before broad patch campaigns.
  • Wire discovery into enforcement Send enriched device attributes into microsegmentation or network policy tools so access decisions are enforced at the edge instead of staying in dashboards or reports.
  • Separate clinical constraints from security exceptions Document which devices cannot be patched, scanned aggressively, or agented, then apply compensating controls and review those exceptions on a fixed governance cycle.

Key takeaways

  • Healthcare device security depends on continuously governed trust, not one-time asset discovery.
  • Claroty's research shows why KEV exposure, internet reachability, and clinical criticality should drive prioritisation.
  • The control that matters most is translating device intelligence into enforced least-privilege policy at the network edge.

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, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.AM-1Asset inventory and device profiling are central to the article's visibility model.
NIST SP 800-53 Rev 5CM-8The article is about discovering and tracking hardware and software assets in healthcare environments.
CIS Controls v8CIS-1 , Inventory and Control of Enterprise AssetsContinuous discovery and asset awareness are the foundation of the post's security model.
NIST Zero Trust (SP 800-207)The article explicitly links device trust to Zero Trust and least-privilege enforcement.

Use Zero Trust principles to move from location-based trust to identity- and context-based access.


Key terms

  • IoMT: Internet of Medical Things refers to network-connected medical devices that support diagnosis, monitoring, treatment, or clinical operations. These assets often have long lifecycles, vendor constraints, and safety requirements that make traditional enterprise security controls insufficient on their own.
  • CPS security: Cyber-physical systems security protects environments where digital compromise can affect physical outcomes such as patient safety, manufacturing output, or infrastructure uptime. It requires visibility into both technical exposure and operational context, because the control objective is resilient operation, not just software hardening.
  • Microsegmentation: Microsegmentation is the practice of limiting east-west network communication to narrowly defined paths and identities. In healthcare, it is often the compensating control that makes risky or unpatchable devices less exposed while preserving the traffic they genuinely need.
  • Device risk scoring: Device risk scoring is a method for ranking assets by exploitability, exposure, and operational criticality rather than by raw vulnerability counts alone. It helps security teams decide what to isolate or remediate first when patching windows are constrained by real-world operations.

What's in the full article

Elisity's full article covers the operational detail this post intentionally leaves for the source:

  • Claroty xDome and CTD deployment context for healthcare and OT environments, including where each approach fits.
  • Step-by-step explanation of the five discovery methods used to profile IoMT and OT assets without disrupting clinical operations.
  • Team82 research summaries on healthcare device exposures, vulnerability trends, and remediation prioritisation.
  • Integration detail showing how device attributes flow into enforcement platforms for network segmentation.

👉 Elisity's full article covers the device discovery methods, risk scoring logic, and enforcement workflow in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners responsible for access and lifecycle control. It is designed for security teams that need a stronger operating model for identity-led risk decisions.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-02-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org