Claroty’s medical device trust model raises the bar for IoMT governance

At a glance

What this is: This is an analysis of Claroty’s IoMT trust model and how it links device visibility, risk scoring, and enforcement to healthcare governance.

Why it matters: It matters because healthcare security teams need a way to translate device identity and exposure into access decisions, segmentation, and remediation priorities without disrupting care.

Context

IoMT governance is a visibility and enforcement problem before it is a vulnerability problem. Healthcare networks contain clinical devices that cannot tolerate aggressive scanning, patching, or frequent reconfiguration, yet those same assets often sit alongside IT systems and vendor connections that expand exposure. In that environment, the practical challenge is building enough identity and risk context to enforce least privilege without interrupting patient care.

Claroty’s trust model matters because it treats device trust as dynamic rather than binary. That aligns with healthcare reality, where a device’s communication patterns, lifecycle status, and known-exploited exposure often matter more than a simple healthy or unhealthy label. The identity angle is real here: once devices are profiled, security teams can connect device attributes to network policy and microsegmentation decisions.

This is typical of modern healthcare environments, not an edge case. Large hospitals and integrated delivery networks routinely inherit unmanaged device sprawl, mixed ownership between IT and clinical engineering, and remediation constraints that make conventional endpoint-style controls incomplete.

Key questions

Q: How should healthcare teams govern connected medical device identity?

A: Treat connected medical devices as managed identities with their own lifecycle. Each device should have a unique trust record, controlled authentication method, and revocation path. Governance must cover manufacturing, deployment, backend access, patching, and retirement, because the risk does not end when the device leaves the factory.

Q: Why do connected medical devices create such a difficult segmentation problem?

A: They mix long-lived clinical functions with changing exposure conditions, proprietary protocols, and patch constraints. A device may remain operational for years while its risk changes quickly, so static VLAN placement or broad allow lists leave hidden exposure. Segmentation works only when policy follows device context, not just network location.

Q: What breaks when IoMT inventory is incomplete?

A: Remediation prioritisation becomes guesswork, and security teams end up protecting what they can see rather than what is most exposed. Incomplete inventory also weakens segmentation because policy cannot distinguish a critical imaging system from a low-risk peripheral. The result is persistent blind spots in healthcare risk governance.

Q: When should organisations prioritise compensating controls over immediate patching?

A: They should prioritise compensating controls when the patch is likely to disrupt production, requires extended testing, or cannot be safely deployed before the exposure window closes. In those cases, containment reduces immediate risk while preserving time for controlled remediation. This is a scenario decision, not a replacement for patching.

Technical breakdown

Why IoMT visibility depends on non-disruptive discovery

IoMT discovery is harder than standard asset inventory because many medical devices use proprietary protocols, long maintenance windows, and operational constraints that make active scanning risky. Non-disruptive methods such as passive monitoring, targeted safe queries, and ecosystem enrichment are designed to identify device type, model, firmware, and communication behavior without affecting care delivery. The technical point is that security teams need sufficient fidelity to classify a device and its exposure state before they can apply any meaningful control.

Practical implication: Use low-impact discovery methods first, then feed the resulting device profile into segmentation and remediation workflows.

How evidence-based risk scoring changes medical device prioritisation

A useful IoMT risk model does not stop at CVSS. It combines whether a device is known to be exploitable, whether it is internet exposed, whether ransomware linkage exists, and whether the device is clinically critical or trapped in a long lifecycle. That approach matters because two devices with the same vulnerability may represent very different business risk depending on where they sit, how they communicate, and how difficult they are to patch. Risk scoring becomes a governance layer, not just a technical dashboard.

Practical implication: Prioritise remediation and compensating controls by exploitability, exposure, and clinical impact rather than vulnerability counts alone.

How device identity becomes enforceable network policy

Once device attributes are known, they can be used as policy inputs for network enforcement. In practice, this means a device profile can drive identity-based microsegmentation rules that restrict which systems a pump, monitor, or imaging platform may communicate with. The model works because the enforcement layer does not need to understand every medical protocol in depth if it can trust the upstream identity and risk context. That is the bridge between visibility and control in healthcare networks.

Practical implication: Tie discovered device attributes to least-privilege network rules so access decisions reflect current device state, not static VLAN placement.

Threat narrative

Attacker objective: The attacker aims to gain durable access to connected healthcare devices or adjacent systems in order to disrupt operations, exfiltrate data, or create leverage for extortion.

1. Entry typically begins when a connected medical or OT device is exposed to network reachability that was not intended for its actual clinical role.
2. Credential or exposure abuse follows when known exploited vulnerabilities, internet-facing services, or weak device segmentation give an attacker a usable path into the environment.
3. Escalation occurs when that foothold can be used to move laterally toward higher-value clinical systems, support infrastructure, or adjacent devices with broader reach.
4. Impact is the disruption of care, unsafe device access, or ransomware-driven operational degradation across healthcare workflows.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IoMT trust is a governance model, not a product feature. Healthcare teams do not need another static asset list. They need a way to continuously translate device identity, exposure, and clinical criticality into control decisions. That makes trust an operational state that must be recalculated as devices, firmware, and network paths change, not an approval stamp that lasts indefinitely. The practitioner conclusion is straightforward: if trust does not change with exposure, it is not governing risk.

Claroty-style device confidence closes the gap between inventory and enforcement. Visibility by itself does not reduce exposure unless it can inform segmentation and access policy. That is where the identity bridge matters for healthcare: device attributes become policy inputs, and the network becomes the control plane for assets that cannot host agents or tolerate intrusive controls. Practitioners should treat this as identity-aware network governance for IoMT, not traditional endpoint security. The conclusion is to make enforcement dependent on current device context.

Medical device security creates a lifecycle trust gap that most enterprise IAM models do not cover. Clinical devices often remain in service for years, but their exposure state changes far more quickly than their replacement cycle. That creates a named failure mode we can call clinical-device trust drift: the device remains operational while its security posture quietly diverges from its assumed trust level. Teams should assume this drift exists and design governance around it.

Team82-style research functions as an external pressure test for healthcare governance. When a dedicated research arm repeatedly surfaces device vulnerabilities and exposure patterns, it exposes how much of the healthcare risk picture is still inferred rather than known. The value is not just disclosure volume, but the way those findings force risk models to prioritise exposed, exploitable, and clinically critical devices together. Practitioners should use that evidence to harden prioritisation, not just expand inventory.

Healthcare segmentation is now an identity problem as much as a network problem. Once device identity and risk attributes drive policy, segmentation stops being a flat topology exercise and becomes a governance process over who or what may speak to whom. That is especially important for IoMT, where broad access assumptions can outlive the operational need that created them. The conclusion is to align segmentation rules with device role and exposure, then verify them continuously.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 36% of health IT leaders say their organisation applies a privileged access strategy consistently across the enterprise, according to Ponemon Institute research.
• Read next: NHI Lifecycle Management Guide

What this signals

Clinical-device trust drift: healthcare teams should assume that operationally healthy devices can still be security liabilities when exposure, firmware, and connectivity change faster than replacement cycles. The governance response is to recalculate trust from observed device context, not from installation history or asset ownership alone.

The operational decision point is now between visibility that informs policy and visibility that merely inventories risk. Healthcare programmes should verify that device intelligence actually flows into enforcement, because discovery without segmentation leaves the same exposure path in place.

For practitioners

• Map every connected medical device to a current trust state Classify IoMT, OT, BAS, and related assets by type, firmware, communication pattern, exposure, and clinical criticality so policy is based on current context.
• Prioritise KEV-bearing and internet-exposed devices first Use exploitability, internet reachability, and ransomware linkage to rank remediation and containment so the riskiest devices are addressed before lower-exposure assets.
• Feed device attributes into segmentation policy Pass device identity, risk score, and role data into network enforcement so pumps, monitors, and imaging systems only reach the clinical services they require.
• Build compensating controls for unpatchable legacy devices Where OEM validation or clinical schedules block patching, restrict communications at the network edge and verify that the allowed paths stay aligned with device function.

Key takeaways

• IoMT governance fails when medical devices are treated as static assets rather than changing trust objects with clinical and network context.
• Claroty’s model combines visibility, risk scoring, and enforcement inputs so healthcare teams can prioritise the devices most likely to be exploited.
• The practical control shift is from inventory alone to identity-aware segmentation and compensating controls for legacy or unpatchable devices.

Key terms

• IoMT Trust Model: A framework for deciding how much confidence to place in a connected medical device based on its identity, exposure, and operational context. It treats trust as dynamic and reviewable, not as a permanent status, so controls can change as risk changes.
• Clinical-Device Trust Drift: The gap that appears when a medical device remains operational but its assumed security posture no longer matches its actual exposure or communications. It is common in healthcare because device lifecycles are long, patching is constrained, and network conditions change faster than replacement cycles.
• Risk-Based Device Prioritisation: A method for ranking connected assets by exploitability, exposure, and business criticality rather than by vulnerability count alone. In healthcare, it helps teams focus on devices that combine known exploitation paths with clinical importance and limited patch options.
• Identity-based Microsegmentation: A segmentation approach that uses identity, context, and policy to decide whether a connection should be allowed inside a network zone. In OT, it helps reduce lateral movement without relying only on IP addresses or broad subnet rules.

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. It helps practitioners translate identity context into practical control decisions across complex environments.