IoMT Penetration Testing: Key Strategies
Post Summary
The Internet of Medical Things (IoMT) connects medical devices to networks, enhancing healthcare but also creating significant cybersecurity risks. Testing these devices is critical to protect patient safety and comply with regulations like HIPAA and FDA guidelines. This guide outlines seven strategies to conduct safe, effective penetration testing for IoMT systems:
- Prioritize Clinical Risk: Focus on devices with the highest potential for patient harm, not just technical severity.
- Build a Complete Device Inventory: Include all connected devices and use SBOMs (Software Bill of Materials) to identify vulnerabilities.
- Create Safe Test Scenarios: Simulate attacks without disrupting patient care by testing during low-activity periods or on isolated systems.
- Test Firmware, Protocols, and Applications: Use methods like fuzz testing and gray-box testing to uncover hidden vulnerabilities.
- Assess Network Segmentation: Ensure compromised devices can’t spread threats across clinical and IT systems.
- Coordinate with Vendors and Regulators: Establish clear communication and follow legal disclosure requirements.
- Integrate Findings into Cyber Risk Management: Use testing results to continuously address vulnerabilities and improve security.
IoMT penetration testing isn’t just about identifying flaws - it’s about reducing risks while ensuring uninterrupted healthcare. Following these strategies helps safeguard patients and meet regulatory demands.
Medical Device Penetration Testing - What Every Manufacturer Must Know
sbb-itb-535baee
1. Align IoMT Penetration Testing With Clinical Risk and Regulations
Not all IoMT vulnerabilities carry the same level of risk. For instance, a flaw in a hospital's visitor Wi‑Fi portal is vastly different from a vulnerability in an infusion pump's dosage control system. To effectively prioritize testing efforts, build a framework that focuses on clinical impact and regulatory requirements.
Don’t rely solely on CVSS scores. While CVSS ratings are useful for measuring technical severity, they fail to account for potential patient harm. For example, a medium-severity CVSS issue on a life-sustaining device could pose a greater threat than a critical flaw in a non-clinical system. To address this gap, combine CVSS with ISO 14971, which evaluates the likelihood and severity of physical harm. This dual approach ensures that technical findings are evaluated through a clinical lens, aligning them with stringent regulatory standards.
Regulatory compliance plays a key role here. Starting February 2026, the FDA mandates penetration testing evidence for any "cyber device" under Section 524B of the FD&C Act. This includes any device with software connectivity via Wi‑Fi, Bluetooth, USB, or serial ports. Missing or inadequate testing evidence can lead to an FDA Refuse-to-Accept (RTA) decision, which may cost manufacturers between $200,000 and $500,000 and delay product launches by 6 to 12 months [5]. Additionally, the 2025 HIPAA Security Rule update requires multi-factor authentication (MFA) for systems handling electronic Protected Health Information (ePHI) and accelerates audit timelines [4].
When planning your tests, focus on devices that have direct patient interaction or deliver therapy. The table below outlines a starting point for prioritization:
| IoMT Device Category | Primary Clinical Risk | Priority Level |
|---|---|---|
| Infusion Pumps | Dosage manipulation, alarm suppression | High (direct therapy delivery) |
| Implantable Sensors | Battery drain, unauthorized commands | High (life‑sustaining function) |
| Imaging Systems | Data exfiltration, lateral network movement | Medium (diagnostic/network pivot) |
| Wearables | Privacy breach, unintended location exposure | Low/Medium (monitoring) |
Ensure testing is performed on production-equivalent devices, not prototypes. Outdated or prototype test results can lead to FDA rejection. Incorporate threat modeling techniques like STRIDE or PASTA to map trust boundaries and identify attack vectors. This ensures testing efforts are guided by clinical risks. Implementing a unified risk operations approach can further streamline these efforts across departments. Establishing this framework is a critical first step toward securing IoMT devices effectively.
2. Build a Complete IoMT Inventory and SBOM-Driven Target List
Getting started with testing requires a complete inventory of IoMT (Internet of Medical Things) assets. Research shows that 30–40% of networked devices in hospitals can be "unmanaged" or unknown until dedicated discovery efforts take place [7][8]. Without a full inventory, it's nearly impossible to properly scope testing or understand device vulnerabilities.
This inventory should include far more than just a basic list of devices. It needs to document every connected asset, from infusion pumps and bedside monitors to lab analyzers, patient wearables, and even building systems that interact with clinical environments. For each device, gather details like:
- Manufacturer, model, and serial number
- Firmware and OS versions
- IP and MAC addresses
- Physical location and clinical owner
- Connectivity methods
- Dependencies such as vendor remote-access tools or companion apps
Don't overlook "shadow IoMT" devices - these could include temporary setups or equipment purchased outside of formal processes.
To build this inventory in live environments, rely on passive network discovery tools, such as SPAN or TAP, to monitor traffic without disrupting operations. Supplement this data with information from biomedical engineering systems, DHCP logs, NAC platforms, CMDB exports, and procurement records. Cross-referencing these sources helps create a reliable and comprehensive target list [7][8].
Leveraging SBOM Data for Prioritization
Integrating SBOM (Software Bill of Materials) data into the inventory takes things a step further. An SBOM outlines every software component on a device, from operating systems to libraries and middleware. This allows you to cross-check against vulnerability databases like the NVD (National Vulnerability Database) or CISA's Known Exploited Vulnerabilities (KEV) catalog.
Why does this matter? A device that seems low-risk on the surface might actually run outdated software, such as an unsupported Linux kernel or an old version of OpenSSL, potentially exposing an entire fleet. CISA highlights the value of SBOMs, stating that organizations with this capability can identify affected systems "in hours instead of weeks" when new vulnerabilities are discovered [6][9].
The FDA now mandates SBOMs for premarket submissions and ongoing vulnerability management. This makes SBOMs essential not just for testing but also for effective third-party risk assessments during procurement. Combining inventory data with SBOM insights allows you to prioritize risks more effectively.
Creating a Tiered Target List
With a complete inventory and SBOM data, you can build a tiered target list for testing. Focus first on devices that:
- Directly impact patient safety
- Have remote access enabled
- Use outdated or unsupported software
- Share vulnerabilities across multiple units
For instance, a network-connected infusion pump with a known CVE (Common Vulnerabilities and Exposures) in its TLS library and active vendor remote-access capabilities would rank higher than a non-networked device with the same flaw. Tools like Censinet RiskOps™ can help integrate this data into broader risk workflows, allowing for continuous adjustments as new vulnerabilities surface or devices change network locations [6][9][10].
This detailed and prioritized target list is the foundation for realistic and effective IoMT testing scenarios in later stages.
3. Design Safe and Realistic IoMT Test Scenarios
Once you've identified and prioritized your target list, the next hurdle is creating test scenarios that are both realistic and prioritize patient safety. This is no small feat. Simulating real-world attacks while respecting clinical limitations is a delicate balancing act. The reality is stark: many hospitals have experienced at least one exploited IoMT vulnerability, highlighting the importance of testing chained attack vectors.
Effective scenarios should go beyond testing single vulnerabilities. Attackers rarely stop at exploiting one weakness - they often combine multiple flaws to amplify their reach. For example, pairing weak default credentials with network vulnerabilities can lead to much broader access. Consider this: 53% of networked medical devices have at least one known critical CVE [4]. This makes multi-stage exploits not only possible but also highly dangerous.
Life-critical devices, like ventilators, require extra caution. As Suman Deb and colleagues explain:
"Requiring passwords on such devices [ventilators] would enhance cybersecurity, but waste precious seconds or endanger the patient's life in emergency scenarios, especially if the caregiver forgets the password."
– Suman Deb et al., College of Computing and Data Science, NTU [12]
Beyond addressing attack chains, practical testing must also respect operational realities. Testing should be scheduled during low-activity periods or conducted on isolated twin devices that replicate live systems. For legacy devices that can't be patched, passive tools like Wireshark or Tcpdump are invaluable for minimizing disruption to sensitive equipment.
To keep everything on track, formally document your testing scope before starting. Clearly outline which devices are included, which ones are off-limits, and ensure clinical teams are informed. This step is crucial to maintain control over the process and avoid unintended disruptions to patient care.
4. Test Firmware, Protocols, and Application Layers in Depth
This step dives into the firmware, communication protocols, and application layers where vulnerabilities often hide. It builds on earlier efforts like clinical assessments and inventory management.
Use a gray-box approach for testing. This method combines partial knowledge of the system, such as documentation and architecture details, which helps minimize the risk of crashes compared to blindly scanning systems [5][11].
When evaluating communication protocols, leave no stone unturned. IoMT devices frequently rely on Bluetooth/BLE, Wi-Fi, USB, Ethernet, HL7, DICOM, and even proprietary RF channels. Each of these must be carefully examined [5]. Pay special attention to protocols like HL7 and DICOM, as encryption gaps in these can lead to sensitive data being exposed [5].
Fuzz testing is another essential tool in your arsenal. By feeding invalid or unexpected inputs into device interfaces - whether through network protocols, API endpoints, or USB connections - you can uncover issues like logic flaws and buffer overflows that traditional scanning tools might overlook [5].
Your testing shouldn't stop at the device level. You also need to assess supporting applications and cloud-based tools. Mobile apps, cloud dashboards, telemedicine platforms, and the APIs linking them to device gateways are all part of the equation [15]. Frameworks such as OWASP IoT Top 10 and WSTG can help you identify vulnerabilities like SQL injection, cross-site scripting (XSS), and insecure direct object references (IDOR) [13][14]. Brian Tant, Chief Penetration Testing Officer at Raxis, highlights the importance of these efforts:
"Web application pen testing involves more perimeter tampering and business logic testing." [13]
Always test on hardware that mirrors production conditions. This ensures your testing reflects real-world scenarios without jeopardizing patient safety [5]. Re-testing should occur at least every six months, reinforcing the continuous risk management strategy mentioned earlier [11]. Regular testing and prompt reassessments are key to staying ahead of potential threats.
5. Test Network Segmentation and Lateral Movement Paths
It's crucial to evaluate whether a compromised IoMT (Internet of Medical Things) device can infiltrate broader clinical or enterprise networks. This is where network segmentation testing plays a key role.
Many IoMT devices are deployed on flat networks where clinical and IT systems coexist. This setup can turn a single compromised device into a launchpad for more extensive attacks. As Palo Alto Networks highlights:
"IoMT devices are frequently placed on flat networks, mingling clinical and IT systems without segmentation. That means a compromised imaging system or infusion pump can become a launchpad for broader attacks." [17]
To assess this risk, simulate a pivot attack starting from a compromised endpoint - such as an infusion pump or imaging device - and attempt to access critical systems like electronic health record (EHR) databases or clinical applications. Tools like Nmap, Wireshark, and Metasploit are invaluable for network discovery, traffic analysis, and exploitation [16]. Deep Packet Inspection (DPI) is also useful for identifying unauthorized east–west movement between network segments, which automated scans often miss [16][17]. These tests ensure that device-level vulnerabilities are addressed while protecting broader healthcare operations.
Manual testing is indispensable for uncovering complex lateral movement paths, especially in hybrid environments that involve hardware, firmware, and cloud components [16]. Every finding should be mapped to the MITRE ATT&CK for ICS/IoT framework, providing insights into segmentation weaknesses and proprietary protocol vulnerabilities. Deliverables like communication flow diagrams and exploit path visualizations can help clinical, IT, and security teams respond effectively.
For legacy or unpatchable devices, strict network isolation is non-negotiable. Enforce Zero Trust principles, implement robust access controls, and rely on network-level anomaly detection to catch early signs of lateral movement. Since many IoMT devices lack the processing power for traditional endpoint protection, these measures are essential for securing the entire IoMT ecosystem [17]. Integrating these steps into continuous risk management practices helps mitigate threats at both the device and network levels.
6. Coordinate With Vendors, Regulators, and Internal Governance Teams
Before testing kicks off, it's crucial to establish clear agreements with device vendors about the scope of testing. This includes third-party integrations like cloud backends, mobile apps, and APIs. Vendors bear responsibility for the security of their entire supply chain, which includes third-party libraries and operating system components embedded in their devices [2]. Without clear boundaries, disputes over findings and delays in remediation can easily arise.
Coordinated Vulnerability Disclosure (CVD) is a legal requirement under FDA Section 524B and the EU Cyber Resilience Act. These regulations demand predefined processes for triaging, notifying, and reporting vulnerabilities within strict timelines [2][5]. For instance, the EU Cyber Resilience Act mandates that manufacturers report actively exploited vulnerabilities to ENISA within 24 hours of discovery [2]. This means organizations must have communication channels set up in advance - last-minute improvisation won't cut it. These governance processes act as a bridge between technical testing and regulatory compliance, strengthening overall risk management.
Every vulnerability must be documented with a clear plan for mitigation, a rationale for acceptance, or a justification for why it’s by design [5]. Internal governance teams are responsible for recording all vulnerabilities, no matter their severity. As Ran Chen, a global expert in MedTech, highlights:
"In 2026 submissions, the most common reason for cybersecurity-related delays is insufficient penetration testing evidence - not missing documentation, but testing that fails to demonstrate real-world device resilience." [5]
For vulnerabilities classified as high or critical, the FDA requires evidence of retesting to confirm remediation [5]. Governance teams need to oversee this retesting process and ensure the results are integrated into the organization's Quality Management System (QMS) and Design History File. This satisfies both FDA QMSR and ISO 13485 standards. Additionally, maintaining an up-to-date living SBOM (Software Bill of Materials) in formats like CycloneDX or SPDX, cross-referenced with CISA's Known Exploited Vulnerabilities (KEV) catalog, ensures the process stays relevant throughout the device's lifecycle [5]. This seamless coordination helps technical findings feed into ongoing risk management efforts.
To ensure regulatory credibility, testing should always be carried out by an independent team with no ties to product development. This independence is critical during disclosure [18]. Platforms such as Censinet RiskOps™ can assist governance teams by tracking third-party vendor risk management assessments, managing third-party security postures, and keeping the documentation trail regulators expect throughout the process.
7. Feed Pentest Findings Into Continuous Risk Management
The real value of penetration testing lies in its ability to drive actionable outcomes. Unfortunately, many findings end up buried in a PDF report, only to be revisited during the next annual test. This is a dangerous oversight, especially in IoMT environments where 53% of medical devices have known vulnerabilities that remain unpatched [1], and each device averages 6.2 software bugs [4].
To address this, establish a continuous, closed-loop process. Integrate pentest findings directly into your vulnerability management workflow. Assign issues to the appropriate teams, track progress, and ensure resolutions are completed. Tools like Censinet RiskOps™ can simplify this process by automating task assignments, centralizing asset intelligence with clinical context, and fostering collaboration among clinical engineering, IT security, and HTM teams [1]. This unified approach transforms a one-time test into an ongoing effort to reduce risk.
It's not just about identifying vulnerabilities - it’s about prioritizing them. Rank findings based on urgency using clinical risk scoring, which considers factors like patient proximity and care impact alongside technical severity. This approach can reduce the number of "critical" vulnerabilities by up to 80% [1]. For the 60% of IoMT devices that are end-of-life and can’t be patched, focus on implementing compensating controls, such as network segmentation, and track these measures within the same platform [4].
To minimize disruptions to patient care, schedule remediation during off-peak hours using device utilization data [1]. For devices too sensitive for active scanning, passive network monitoring can detect anomalies without interfering with functionality.
Finally, align findings and remediation efforts with frameworks like NIST CSF, HIPAA, or ISO/IEC 80001-1 [3][4]. This not only keeps your risk management program audit-ready but also ensures that insights from each test cycle contribute to a progressively stronger security strategy over time.
Comparison Table
7 IoMT Penetration Testing Strategies: Clinical Impact vs. Risk Reduction
The table below breaks down the seven strategies, highlighting their clinical relevance, effectiveness in minimizing risk, and the challenges tied to implementation. Each strategy is ranked based on clinical impact, risk reduction potential, and implementation complexity:
- Clinical impact assesses how well the strategy protects patient safety and care delivery.
- Risk reduction potential evaluates how much it reduces vulnerabilities in the system.
- Implementation complexity considers the technical skills, coordination, and resources needed.
| Strategy | Clinical Impact | Risk Reduction Potential | Implementation Complexity |
|---|---|---|---|
| 1. Align with Clinical Risk & Regulations | Very High - focuses on life-critical devices | High - addresses the most dangerous gaps | Medium - requires collaboration across clinical departments |
| 2. Build Inventory & SBOM Target List | Medium - provides a foundational understanding | Very High - identifies vulnerabilities across many devices | High - managing large-scale data is resource-intensive |
| 3. Design Safe & Realistic Test Scenarios | Very High - avoids causing harm during testing | Medium - ensures safe testing in live environments | High - demands expertise in non-destructive testing |
| 4. Test Firmware, Protocols & App Layers | High - addresses the average 6.2 software bugs per device [4] | High - uncovers firmware and protocol weaknesses | Very High - requires advanced knowledge of IoMT hardware |
| 5. Test Network Segmentation & Lateral Movement | High - stops breaches from reaching critical systems | Very High - limits the spread of attacks | Medium - standard IT practice, but challenging in clinical VLANs |
| 6. Coordinate With Vendors & Internal Governance | Medium - builds safety through governance frameworks | Medium - ensures compliance and vendor cooperation | High - involves navigating vendor relationships and regulations |
| 7. Feed Findings Into Continuous Risk Management | High - supports long-term care resilience | Very High - shifts focus to proactive defenses | Medium - requires integration with existing SOC and ITSM tools |
This breakdown helps identify strategies that deliver quick clinical protection and those requiring more extensive investment, enabling better prioritization.
Key Observations
Some clear patterns emerge from this comparison. Strategies 1 and 3 stand out for their high clinical impact. Strategy 1 focuses on life-critical devices where any compromise could endanger patients, while Strategy 3 prevents poorly designed tests from introducing risks during implementation. Meanwhile, Strategies 2, 5, and 7 provide the strongest potential for risk reduction, making them essential for addressing systemic vulnerabilities in IoMT environments.
However, Strategies 2, 3, 4, and 6 demand significant resources, both in terms of expertise and coordination. This is why sequencing is so important. Attempting to tackle all seven strategies at once without proper tools and a skilled team could lead to incomplete or ineffective results.
"Even minor vulnerabilities like default passwords on an IV pump can have fatal consequences." - Mohammed Khalil, Cybersecurity Architect, DeepStrike [4]
For teams starting out, strategies with medium complexity - such as clinical risk alignment, network segmentation, and continuous risk management - offer a balanced approach. They provide strong protection without requiring deep technical expertise upfront, making them ideal entry points for building a robust IoMT security framework.
Conclusion
IoMT penetration testing isn’t a one-and-done task - it’s an ongoing effort that’s critical for safeguarding patient safety and meeting regulatory standards. According to a Cynerio/Ponemon Institute report, 56% of healthcare organizations experienced security incidents involving IoT/IoMT devices in the past two years. Even more concerning, 21% of these incidents negatively impacted patient care, leading to delayed procedures and test results.[19]
To maintain strong IoMT security over time, organizations need to follow a structured lifecycle. This includes aligning testing efforts with clinical risks, maintaining detailed device inventories, creating safe testing scenarios, and regularly updating risk assessments. These seven strategies form a cohesive system - from identifying assets to evaluating vulnerabilities and managing risks continuously. Together, they ensure IoMT devices remain secure without disrupting patient care. By addressing critical medical device security risks and governance challenges discussed earlier, this lifecycle turns fragmented testing efforts into a coordinated security program.
A centralized approach to risk management makes this process more effective. Tools like Censinet RiskOps™ consolidate risk data from medical devices, clinical applications, PHI, and supply chains. They connect penetration testing results directly to specific vendors and device models, enabling IT security teams, clinical engineers, and vendors to collaborate on remediation. Additionally, benchmarking dashboards provide executives and board members with a clear view of the organization’s security posture over time. For healthcare organizations managing thousands of connected devices, this level of visibility is essential to keep IoMT security manageable.
Static reports from individual tests quickly become outdated as device fleets grow, firmware updates roll out, and new vulnerabilities emerge. That’s why healthcare organizations need a solution that not only tracks remediation efforts but also connects testing results to procurement and vendor management decisions - all in one system.
The cost of inaction is staggering. IBM’s Cost of a Data Breach report estimates that the average healthcare breach costs around $10 million, making it the most expensive sector for data breaches.[20] Implementing a continuous IoMT testing program isn’t just about compliance - it’s an investment in patient safety and the long-term resilience of healthcare operations.
FAQs
How do you prioritize IoMT pentesting by patient safety, not just CVSS?
To ensure IoMT penetration testing prioritizes patient safety, it's crucial to simulate real-world attacks that could expose weaknesses affecting patient care. Instead of depending entirely on CVSS scores, include proactive risk assessments and incident response plans that specifically address threats to both patient safety and device functionality.
What’s the safest way to test IoMT devices without disrupting care?
The best way to go about this is by conducting penetration testing and incident simulations in a controlled, non-production environment. This ensures that live systems remain unaffected during the process.
To keep testing isolated from clinical operations, consider using strategies such as:
- Network segmentation to separate test environments from operational networks.
- Device authentication to control access and maintain security.
- Real-time monitoring to quickly identify and address any potential issues.
Additionally, performing regular risk assessments and vendor evaluations can help maintain a secure testing process without disrupting patient care.
What evidence does the FDA expect for IoMT penetration testing in 2026?
The FDA has set a requirement for thorough penetration testing of IoMT devices starting in 2026. This involves conducting vulnerability scans, fuzz testing, and providing evidence that these devices can withstand cyberattacks. These steps are now mandatory for device submissions, ensuring strong cybersecurity measures and adherence to regulatory standards.
