12 Core Areas of Consideration You Can’t Avoid When Mitigating Risk in IoMT

Healthcare delivery organizations (HDOs) increasingly rely on Internet of Medical Things (IoMT) devices to improve patient care outcomes. However, these devices come with unique risks that traditional security processes and tools are unable to manage adequately. 

Unlike traditional IT systems, IoMT devices often run on proprietary or outdated software, making them difficult or impossible to patch without vendor involvement. However, a cyberattack that takes them offline can impact patient care and undermine clinical safety. 

Additionally, these devices involve various technology functions across the HDO, including IT, security, clinical engineering, and vendor risk management teams. With so many departments involved, many HDOs struggle to assign responsibility, leaving their IoMT devices at risk. 

HDOs must find ways to incorporate IoMT device security and risk management into their overarching security programs. With these 12 actionable considerations, they can enhance overall policies, processes, and capabilities, thereby maturing their IoMT risk management strategies. 

1. Vulnerability Identification & Exploit Analysis + Impact Analysis

Using a passive scanning technology enables HDOs to identify vulnerabilities without disrupting device service. Passive scanners use network traffic patterns to identify and create a device profile that includes:

• Operating system
• IP address
• MAC address
• Port numbers
• Applications
• Hostname
• Version number

With this information, organizations can identify potentially vulnerable operating systems and applications, especially with insight about the version running on the device. 

While all vulnerabilities carry attack risks, not all vulnerabilities create the same level of risk. Every HDO’s environment and system architecture is unique, and attackers need a direct path to vulnerable IoMT devices. To understand the risk that a vulnerability poses to the organization, HDOs need insight into:

• Exploitability: the ability to take advantage of a CVE within a given environment and any compensating controls that mitigate the risk.
• Impact: the effect that a successful attack would have on operations or device availability.

For example, a critical vulnerability may not impact the HDO’s security posture if the affected IoMT device has limited communications with the rest of the network. 

2. Remediation Prioritization: Evaluating Device Exposures

Insight into exploitability and impact are only the first steps to managing vulnerability risk. Even if attackers could use a vulnerability to gain unauthorized access, they may not be using the exploit for various reasons. Criticality and severity are not related to what attackers are doing in the real world. 

When prioritizing vulnerability remediation, HDOs should consider the following:

• System architecture design: Whether attackers can reach a vulnerability.
• Network communication flows: Whether network communication flows allow sensitive data on the same network where the vulnerable device resides. 
• Current security controls: Mitigations currently in place that would thwart an attacker from using the device vulnerability to compromise the network or system.
• Threat intelligence: How attackers are currently using or not using the vulnerability in the real world.

By aggregating and correlating this data, HDOs can then use artificial intelligence (AI) to prioritize their vulnerability remediation activities by starting with the ones that pose the highest risk to critical operations and sensitive data. 

3. Orchestration of Risk Control Measure Implementation

For IoMT devices, vulnerability and risk remediation may not always be as straightforward as applying a security patch. Often, manufacturers are slow to release security updates or fail to release them entirely. Since every HDO’s system architecture is different, generic remediation steps may be too complex to implement within the organization’s environment.

When patches are available, HDOs should work to apply them across as many vulnerable devices as possible. However, this can be time-consuming when the organization has hundreds or thousands of devices. In this case, using an automated solution for IoMT patching can streamline the process by providing pre-tested patches and a unified patching process. 

When implementing risk control measures, HDOs should consider identifying the most secure, lowest-effort remediation activities, like: 

• Deactivating unnecessary services to limit connectivity.
• Blocking risky ports using a Network Access Control (NAC) tool.
• Altering configurations to harden devices.

4. Evaluation of Clinical Impacts & Biomed Implementation Training

Since IoMT devices are highly specialized, the staff responsible for managing their security should have the appropriate training on how to secure them while maintaining patient safety and clinical workflow integrity. Often, these activities require collaboration across:

• Clinical engineering/biomed teams who manage the devices.
• IT/security teams who identify vulnerabilities and push patches.
• Clinical staff who rely on these devices for patient care.

This training should include assessing the clinical impact that a security update might have across:

• Patient safety, like the potential harm if a device fails during treatment.
• Clinical outcomes, like delays in care arising from taking a device offline.
• Operational workflows, like system downtime from applying a patch.

Additionally, the biomedical engineering staff who manage, maintain, and service the devices should have training about:

• Safely applying patches or mitigations to IoMT devices.
• Vulnerability reports and security advisories.
• Coordinating with clinicians and IT to minimize clinical disruption.
• Using proper procedures for device validation after patching.
• Maintaining compliance with regulatory standards (e.g., FDA, HIPAA).

5. Anomaly Identification, Prioritization & Mitigation Planning

Integrating IoMT devices into the HDO’s overarching security and privacy monitoring is critical to protecting patient data and complying with regulations like HIPAA. Anomaly detection is critical to bringing IoMT security under the larger cybersecurity monitoring program. The first step in this process should be to understand how the devices normally behave by identifying incoming and outgoing communications. 

Security teams need information about changes that can help detect malicious behavior, including misconfigurations, like:

• Default passwords
• Basic Authentication
• Missing HTTPS
• External DNS
• Expired Certificate or Obsolete SSL or TLS Version
• Wrong network or VLAN connections

The HDO’s security team can correlate this data with other security information to create simple or advanced detection rules in its security information and event management (SIEM) tool that include:

• Data from the MITRE ATT&CK Framework that outlines attacker tactics, techniques, and procedures (TTPs).
• Device and vulnerability data from the Manufacturer Disclosure Statement for Medical Device Security (MDS2) and Software Bill of Materials (SBOM).
• Network monitoring tool
• Endpoint detection and response (EDR) tools

Further, the incident response team should prepare to capture forensic data so they can correlate medical device network activity with:

• RAM information from servers.
• Traffic information from network devices.
• Data transferred to an FTP server.

6. Anomaly Policy Creation and Review

An Anomaly Policy defines how an HDO detects and responds to suspicious or unusual IoMT behavior and the related network activity. 

An HDO’s Anomaly Policy formalizes thresholds for what the organization considers abnormal IoMT device behavior and how to respond to detected anomalies. The policy should include:

• Defining baseline behaviors for different types of devices, like infusion pumps and patient monitors. 
• Identifying normal communication patterns, like the typical systems the device communicates with. 
• Identifying data transmission frequencies and volumes. 
• Creating an approved software or firmware version list. 
• Setting thresholds for triggering alerts, like devices communicating with unknown IP addresses, transferring too much data, or operating outside clinical hours. 
• Creating incident response processes that include alerting the security team, isolating the device from the network, and communicating with the biomed and clinical teams.

Since IoMT ecosystems are dynamic, HDO needs to regularly review their policies, especially when updating devices, changing clinical use cases, or identifying emerging threats. The review process typically involves:

• Re-evaluating baselines as device usage evolves.
• Analyzing false positives/negatives from past anomaly detections.
• Incorporating threat intelligence about new attack vectors targeting medical devices.
• Validating policies with IT, biomed, and clinical input to ensure clinical operations aren’t disrupted unnecessarily.

7. Audit & Developing a Strategic and Operational Roadmap

To plan structured, long-term improvements to its IoMT environment, an HDO needs to assess its current cybersecurity posture and understand the risks that new devices would create. Further, to comply with industry regulations like HIPAA, the HDO needs to provide an annual third-party assessment proving that its security and privacy controls function as intended, including the ones in place for IoMT. 

Developing and implementing an IoMT audit plan enables the HDO to assess how the devices impact its current cybersecurity posture. The audit process typically includes auditors asking for the following documentation or engaging in the following activities:

• Asset Inventory: Identifying and cataloging all IoMT devices (e.g., infusion pumps, MRI machines, patient monitors).
  Risk Assessment: Evaluating risks based on device criticality, known vulnerabilities (CVEs), usage context, and potential patient safety impacts.
• Policy Review: Assessing existing security policies, procedures, and controls related to IoMT.
• Compliance Check: Ensuring alignment with regulations (e.g., HIPAA, FDA guidelines, NIST frameworks).
• Technical Testing: Performing vulnerability scans, network segmentation reviews, or penetration testing where feasible.
• Stakeholder Interviews: Engaging clinical engineering, IT security, compliance officers, and clinicians to understand operational challenges.

As the HDO expands its IoMT device fleet, it needs to consider how new devices will impact the security posture. As part of developing a strategic plan, the organization needs to build an operational roadmap that identifies new devices that will improve patient health outcomes and how to mitigate the risks that those new devices may create. The strategic roadmap should include broader objectives mapped to the organization’s overall mission and revenue growth, including:

• Defining cybersecurity goals for IoMT, like achieving a certain risk maturity level or zero-trust architecture.
• Budget planning for tools, training, and staffing.
• Governance models for managing cybersecurity responsibilities across IT, biomed, and clinical teams.
• Vendor engagement strategies include procurement policies requiring security assurances.

The operational roadmap takes a more tactical approach that focuses on executing the following:

• Short-term tasks like implementing targeted segmentation for device networks, anomaly detection, and security patches. 
• Medium- and long-term initiatives, like deploying a medical device security platform or integrating IoMT monitoring into SIEM.
• Device risk analysis and review during procurement. 
• Review cycles to keep the roadmap current with evolving threats and technologies.

8. Governance of IoMT Risk Controls with OEMs and Device Manufacturers

HDOs need to consider how they fit original equipment manufacturers (OEMs) and device manufacturers into their vendor risk management programs. Since IoMT devices have little or no built-in cybersecurity mechanisms, HDO needs to implement a governance strategy for their providers, especially since patching or modifying the devices can implicate warranties or compliance violations. 

Governance over OEMs and device manufacturers should include the following:

• Defining security requirements during procurement: requiring SBOMs, documentation of secure-by-design principles, patch service level agreements (SLAs), and secure configuration guidance.
• Coordinating vulnerability disclosures: ensuring OEM participates in coordinated vulnerability disclosure (CVD) processes so HDOs can expect timely communications and mitigation options, even before patches are available.
• Patch and update management agreements: defining clear timelines for security patches and firmware updates, support for legacy devices, and patch notification and documentation.
• Lifecycle risk management: defining end-of-life device and OEM support commitments and plans for replacing or segmenting unsupported equipment.
• Audits, certifications, and compliance: requiring that OEMs comply with healthcare security frameworks like the FDA Premarket Guidance for Cybersecurity in Medical Devices.
• Regular risk reviews: periodically assessing OEM security maturity and incident response capabilities through vendor security questionnaires.

9. IS Policies & Procedures

As part of managing compliance, an HDO must bring its IoMT device fleet under the larger umbrella of its information security (IS) program. These policies define the organization’s security objectives and how employees use organizational assets. 

As part of building comprehensive IS policies that include IoMT, HDOs should update the following categories:

• Acceptable Use Policy (AUP): Who can access IoMT devices and how they are allowed to use them
• Access Control Policy: Who can access device settings, data, and admin interfaces
• Patch Management Policy: how and when IoMT firmware/software is updated
• Network Security Policy: How IoMT is segmented or firewalled
• Incident Response Policy: What to do if a device is compromised

The HDO’s IS procedures offer more detailed instructions for how to implement the policies. For example, an HDO might want to consider processes for how IT, biomed, and clinical staff can:

• Safely take devices offline for patching
• Onboard new devices and assign them to the correct network segments
• Respond to security alerts triggered by IoMT devices
• Document and report security incidents involving IoMT devices

HDOs need to consider the different challenges and risks arising from their IoMT fleets to tailor their IS policies and procedures accordingly. Without the inherent security controls that traditional devices have, HDOs need to address, at minimum:

• Access Control: Since IoMT lacks native authentication, procedures may require compensating network controls.
• Patch Management: Policies must include coordinating with OEM and manufacturers and implementing risk-based prioritization. 
• Asset Management: Procedures must ensure complete, real-time inventory of all IoMT devices, including make/model, IP, OS, and firmware version.
• Incident Response: Policies must balance threat containment and eradication with clinical safety, like not disconnecting a compromised device mid-surgery.
• Data Protection: IoMT devices often fail to encrypt data, so the organization may need to implement compensating controls for stored and transmitted ePHI. 

10. HTM/Biomed Policies & Procedures

Biomed and HTM teams manage and maintain IoMT devices, yet they may not be security experts. For biomed and HTM teams, managing the IoMT device lifecycle includes incorporating them into the overarching policies and procedures for handling:

• Device acquisition, deployment, and configuration
• Preventive and corrective maintenance
• Software and firmware updates
• Security vulnerability management
• Device decommissioning and disposal

As part of their responsibilities, the biomed and HTM policies and procedures should incorporate the following areas:

• Device onboarding: Procedures for network registration, asset tagging, and verifying device security features before deployment.
• Patch and firmware management: Assessing, testing, and applying patches while coordinating with OEMs, IT, and clinical teams.
• Vulnerability response: Steps for evaluating clinical risk, applying compensating controls, and reporting known vulnerabilities. 
• Secure configurations: Hardening deployed devices, like disabling unused ports or changing default credentials.
• Inventory management: Maintaining a real-time, accurate inventory of all connected medical devices, including software versions.
• End-of-life device management: Procedures for decommissioning devices, wiping data, and updating risk registries.
• Incident handling: Protocols for isolating a compromised device with minimal disruption to care, and reporting incidents to IT/security.

11. Development IoMT Risk Management Playbook

Developing an IoMT risk management playbook enables the HDO to create a detailed, actionable guide so that teams can consistently handle security incidents affecting these devices. Since every device type is different, the playbook defines the device-aware and context-specific actions that reduce incident response times and improve cross-functional coordination. 

By translating high-level risk policies into actionable workflows, the handbook provides predefined response paths for common threats so that the security, IT, biomed, clinical, and OEM teams can coordinate more efficiently. 

Some key components of an IoMT risk management playbook include:

• Risk identification: How to discover and categorize risks, like CVEs, FDA recalls, and alerts from medical device monitoring platforms.
• Risk assessment framework: Methodology for ranking risk based on clinical impact, device criticality, exploitability, and exposure.
• Response Workflows: Step-by-step guide for handling specific threat scenarios, like what to do when a device is found running outdated firmware.
• Communication processes: Who to notify across the biomed, IT, clinical, and OEM teams, when they need to know, and how to provide notification, like escalation paths for troubleshooting and incident response.
• Mitigation strategies: How to implement compensating controls when no patch is available, like segmenting networks or restricting usage. 
• Patch management: when and how to apply patches, validate their functionality, and return devices to clinical use. 
• Incident response: How to handle IoMT devices during a general security incident or when a data breach occurs. 
• Documentation and audit: Templates for logging risk assessments, actions taken, and compliance documentation.
• Device lifecycle risk management: Processes for identifying, analyzing, and mitigating risk that start during the procurement process and follow the device through decommissioning. 

12. Annual Tabletop Exercises, Stress Testing, Vulnerability Management, and Anomalies

The tabletop exercises are non-technical simulations that allow teams to practice and test their vulnerability management and incident response processes. Unlike penetration testing or red-teaming, these exercises focus on walking through the handling of a security event rather than fine-tuning security tools. 

Tabletop exercises enable IT, security, HTM/biomed, clinical staff, and OEM to test how well their risk management playbooks and procedures work. Typically, these activities involve:

• Scenarios or simulations: A process use case, like “CVE affecting an infusion pump” or “device connecting to a known risky geographic area.”
• Explanation of procedure: Each team explains their response processes to determine whether the steps and coordination work as intended. 
• Stress points: Introduction of complications to test how stakeholders would respond to a realistic situation, like inability to patch a device or lack of vendor response. 
• Documentation: Participants document their response activities, including decisions, escalation paths, and actions taken, to see if they would match the written processes. 
• Post-exercise review: Participants discuss the lessons learned so they can identify areas of improvement, like unclear ownership, training needs, or technical control gaps. 

In today’s healthcare landscape, effectively reducing IoMT risk requires a holistic, nuanced approach—one that addresses everything from passive vulnerability identification and exploit analysis to remediation prioritization, patch orchestration, and ongoing anomaly detection. Asimily’s risk reduction platform is purpose-built to support healthcare delivery organizations at every stage of this journey. By enabling passive device profiling, real-time exploitability and impact analysis, and AI-driven remediation prioritization, Asimily empowers organizations to focus on the vulnerabilities that matter most within their unique environments. Automated patch management and orchestration streamline the deployment of risk controls, while robust anomaly detection and policy management ensure that evolving threats are quickly identified and addressed. Asimily also facilitates collaboration across IT, clinical, and biomedical teams and supports compliance through comprehensive audit and documentation tools. With Asimily, healthcare organizations can confidently develop and execute a strategic, operational, and governance roadmap for IoMT risk management—protecting patient safety, maintaining regulatory compliance, and enabling innovation without compromise.