Best Practices for IoMT Vulnerability Scanning

If you scan hospital devices the same way you scan office IT, you can disrupt care. For IoMT, the right approach is simple: know what devices you have, use low-impact scan methods, rank issues by both exploit risk and patient impact, and track every fix or exception.

Here’s the short version:

• Start with inventory. I need device model, firmware, owner, network location, and clinical use before I scan.
• Use safe scan methods. Passive monitoring fits many bedside and life-support devices better than active probing.
• Set scan timing around care. Quarterly baselines, more frequent checks for high-risk or internet-facing assets, and change-based scans after updates or new devices.
• Rank findings by context, not score alone. CVSS, Known Exploited Vulnerabilities (KEVs), exposure path, and patient care impact all matter.
• Use vendor rules. I should check MDS2s, SBOMs, and manufacturer limits before testing device classes.
• Track every decision. Patches, compensating controls, exceptions, review dates, and vendor follow-up all need records.
• Tie scans to governance. FDA guidance, AAMI TIR57, NIST CSF, and HHS 405(d) shape how I assess and respond.

A few data points make the risk clear: a 2025 report found 99% of HDOs in the dataset had IoMT devices with KEVs, and 89% had devices with KEVs linked to ransomware. Another dataset covered more than 2.25 million devices across 351 healthcare organizations and found KEVs across 99% of organizations.

Here’s the main takeaway: IoMT scanning is less about running more scans and more about running the right scans, at the right time, on the right devices, with the right follow-up.

If I keep those six steps in place, I can cut exposure without disrupting patient care.

The Evolution of IoMT Risk Assessment: From Static to Dynamic Customized Frameworks

sbb-itb-535baee

Aligning Scanning With FDA, AAMI, and Healthcare Cybersecurity Frameworks

Running IoMT scans without a governance framework leads to uneven results. You might spot weak points, but that alone doesn't show whether your response will hold up in an audit or review. When scans are tied to FDA guidance, AAMI TIR57, NIST CSF, and HHS 405(d), the process becomes repeatable and auditable. These frameworks spell out how findings move from detection to triage, remediation, and reporting.

FDA Cybersecurity Expectations for Monitoring and Remediation

For IoMT scanning, the main issue isn't just finding flaws. It's deciding which findings need action NOW.

FDA's cybersecurity expectations now directly require manufacturers of "cyber devices" to monitor, identify, and address postmarket vulnerabilities, including coordinated vulnerability disclosure (CVD) and timely security updates and patches.^[3][18][21] For HDOs, this helps set vendor expectations and shape internal response workflows.

FDA's postmarket guidance also draws a practical line between controlled and uncontrolled risk.^[7][1][20] If a vulnerability can be handled through routine patching or compensating controls, without putting essential clinical performance at risk, it may stay in a controlled state and move through normal cybersecurity update processes. Uncontrolled risk - where patient safety may be affected - calls for faster action and may trigger notification.^[7][1][20]

In day-to-day use, your scanning program should plug straight into a risk assessment workflow. Every major finding on an IoMT device should be reviewed not only by CVSS score, but also by whether it creates controlled or uncontrolled risk. Keep records that show how each vulnerability was assessed, whether it was reported through CVD, and how patches or compensating controls were applied. That paper trail supports audits and FDA review. Implementing a unified risk operations approach helps teams respond faster to these findings.^[7][1][11]

Using AAMI TIR57, NIST, and 405(d) to Scope and Govern Scanning

FDA sets the postmarket response bar. AAMI TIR57 helps turn scanner output into a risk decision. It extends ISO 14971 into security and covers threat identification, risk analysis, controls, and postmarket monitoring.^{[13][4][14][15]} For scanning programs, TIR57 gives teams a clear structure: each scan activity can be traced to known threats, tied to specific controls, and documented with residual risk justification.^{[4][8][10][12]} It also helps to use TIR57 terms in policies and reports so they line up with manufacturer documentation.

NIST CSF and HHS 405(d)/HICP add the day-to-day layer that organizes scanning across the full security lifecycle. 405(d) calls for a vulnerability management program that takes in device disclosures and responds to them.^[17] So your scanning program needs more than automated scanner output. It also needs a set intake process for manufacturer advisories.

Use the matrix below to connect each scan activity to the record or decision it should produce.^{[4][8][9][10][12]}

These mappings also help define scan scope, scan timing, and device handling rules.

Designing a Safe and Effective IoMT Scanning Program

With scope and governance in place, the next step is day-to-day control. Frameworks set the rules. This section focuses on how to run scans safely.

Build the Right Prerequisites Before You Scan

Don't start scanning until your IoMT asset inventory is complete, addressing the foundational security risks inherent in these devices.

Catalog each device by type, manufacturer, model, serial number, IP/MAC address, location, firmware/software version, owner, and clinical criticality. Classify devices as life-sustaining, patient-facing, or PHI/ePHI-bearing. ^[23][24][27]

You also need a clear map of VLANs, segmentation boundaries, and communication paths to EHR, PACS, cloud systems, and remote sites. That map helps determine how often each segment can be scanned without disrupting care. ^[23][27]

SBOMs help match scanner findings to the actual components and firmware on the device. MDS2 helps confirm vendor scanning limits and device sensitivities before anything touches the network. ^{[22][23][24][26][27][30]}

Set Scan Schedules and Profiles That Protect Patient Care

Once the inventory is done, set scan timing and scan intensity around care delivery, not the other way around.

Use quarterly baseline scans for full coverage. For high-risk or internet-exposed assets, use monthly or continuous scans. Run change-triggered scans after new devices are added or after major configuration changes. ^[25][27][28]

For fragile or life-sustaining devices, passive discovery is the safer choice. Use active scans only when the vendor approves them, and only during maintenance windows with clinical engineering sign-off. ^[24][27]

Keep scan settings read-only, throttled, and low-concurrency. If a device can't be scanned, document that exception and use segmentation, ACLs, and tighter monitoring to lower risk. ^[27]

Prioritize Findings by Exploitability and Clinical Impact

After scans run safely, the next job is triage. And in healthcare, triage can't stop at severity scores.

Prioritize findings based on CVSS, KEV status, exposure path, and clinical impact. ^{[24][25][27][28]} KEV status matters a lot in practice. A 2025 analysis of more than 2.25 million IoMT devices across 351 healthcare organizations found confirmed KEVs in 99% of organizations. That makes KEV-aware triage less of a nice-to-have and more of a daily operating need. ^[5]

The table below turns those factors into remediation timelines teams can actually use.

If a patch isn't available - or isn't safe to deploy - document the compensating controls in place, set a review date, and rescan after any change to confirm that residual risk hasn't shifted. ^[1][7][27] Every finding that gets closed, or formally accepted, should leave a clear audit trail for both internal oversight and external review.

These requirements define the tool features and configurations your scanning platform must support.

Selecting and Configuring Tools for IoMT Vulnerability Scanning

Core Scanner Types and Their Roles in Healthcare

Once scan limits are in place, the next step is simple: pair each tool with the device type and protocol it can test without causing trouble. In healthcare, one tool rarely does the whole job. A mixed stack works best - active scanners for core infrastructure, web and API scanners for exposed interfaces, TLS analyzers for encryption checks, and passive monitoring for fragile devices.

Network vulnerability scanners are used for asset discovery and baseline CVE identification across hosts, ports, and services. They fit infrastructure segments well, but they need tight rate limits and careful scoping around devices that can’t handle probing.

Web application and API scanners - including Burp Suite, OWASP ZAP, Acunetix, Invicti, and Nuclei - fit EHR portals, device management interfaces, PACS web front ends, and FHIR/REST APIs. These tools test HTTP/HTTPS interfaces directly, including authentication, input validation, API methods, and session handling.^[35][39][41]

TLS/SSL analyzers such as SSL Labs, SSLyze, OpenSSL s_client, and testssl.sh add another layer by checking cipher suites, certificate chains, and protocol versions on services that may carry PHI or device management traffic.^{[33][34][35][6][42]}

For high-risk devices like infusion pumps, imaging systems, and implants, passive IoMT monitoring is often the safer path. These tools identify devices from network traffic through SPAN or TAP ports and map device details against CVE databases, SBOMs, and FDA safety communications - without sending probes to the device.^{[32][36][38][40]}

Configuration Practices for HL7, DICOM, MQTT, APIs, and Sensitive Devices

Protocol-aware setup is what turns scanning from noisy guesswork into something teams can use. If the tool doesn’t understand the protocol, the result is usually a pile of false positives and wasted time for clinical engineering.

Start with SPAN or TAP capture to confirm which protocols are live - HL7, DICOM, MQTT, and FHIR - before running protocol-specific tests.^[29][38][39] Use HL7Spy or Wireshark dissectors for HL7, DCMTK to verify DICOM association settings, and tightly rate-limited tests for MQTT brokers.^[35][6][37]

Credentialed scanning can cut false positives on systems that allow it, such as EHR servers, PACS back ends, databases, virtualization hosts, and vendor-supported devices. The rule here is strict: scanners should pull versions, settings, and permissions only. They should never access PHI.^[31][29] If a device supports only limited testing, stick with passive monitoring and credentialed checks instead of active probes.

When a finding may affect a high-risk clinical workflow, clinical engineering needs to weigh in before anyone acts. A flagged port, for example, may just be normal vendor behavior. That’s why high-risk findings should be checked with clinical engineering before remediation starts.

Connecting Scan Findings to Enterprise Risk Workflows

Tool selection matters only if findings move into day-to-day risk work. A scanner dashboard full of open issues doesn’t lower risk on its own. What helps is moving those findings into a centralized risk register, adding asset criticality and ownership, and tracking each item through remediation.

The workflow should move from import, to enrichment, to assignment, to closure. Every open exception should include a compensating control, a review date, and a clear audit trail. Executive dashboards should track remediation trends, open exceptions, and patch status by facility or by device class.

Platforms such as Censinet RiskOps can centralize scanner findings, ownership, remediation, and benchmarking for HDO workflows.

Use the matrix below to line up each scanner type with its clinical use case and deployment risk.

Building Continuous Improvement and Executive Oversight Into Your Scanning Program

Embed Scanning Into Risk Registers, Governance, and Vendor Coordination

Once scans are set up and prioritized, the next step is governance: turning findings into tracked risk decisions. A scanner that runs on a fixed schedule and spits out reports gives you a snapshot. It does not give you a program.

Governance starts with structure. Every finding needs a clear owner, a due date, and, if patching would disrupt care, a documented exception plus an interim control. FDA postmarket cybersecurity guidance and AAMI-aligned processes expect structured intake, triage, and documentation.^[46][47]

For executive oversight, track coverage, remediation speed, and control effectiveness. Those metrics show whether the program is getting better or just staying busy.

For manufacturer-supported devices, remediation often depends on vendor coordination as much as internal patching. Route findings for manufacturer-supported devices through coordinated vulnerability disclosure, and document the agreed remediation path. If active scanning is unsafe or unsupported on certain devices, CVD becomes the main path for resolving vulnerabilities that the HDO can't fix on its own. FDA's postmarket guidance expects HDOs to assess safety and security risk jointly with manufacturers and document the outcome.^[44][7] Keep a log of every disclosure, manufacturer response, and agreed remediation timeline.

NIST CSF 2.0 Govern and HHS 405(d) call for defined roles, a stated risk appetite, and periodic maturity reviews.^[45][48][16] Platforms like Censinet RiskOps™ help by centralizing risk register management, remediation tracking, and cybersecurity benchmarking across HDO workflows, which supports reporting to auditors and leadership.

Conclusion: The Practices That Matter Most

These governance habits keep IoMT scanning operational, auditable, and safe for clinical use. A few practices tend to separate programs that reduce risk from those that just generate reports:

• Align scanning to FDA and AAMI guidance - use FDA postmarket cybersecurity expectations and AAMI TIR57's risk-management principles to shape how you classify, remediate, and disclose vulnerabilities.^[1][3][2]
• Maintain live asset visibility and safety-aware scan methods - without a current inventory that includes model, firmware version, and clinical function, findings lack context; configure tools and schedules to protect clinical workflows and follow manufacturer guidance on device tolerances.^{[25][43][2][19]}
• Prioritize by exploitability and clinical impact, then benchmark and improve - combine CVSS scores and KEV status with device criticality so teams focus where patient harm is most plausible, and measure coverage, remediation speed, and control effectiveness against internal targets and changing FDA, NIST, AAMI, and 405(d) guidance.^{[43][19][25][1][3]}

Done right, IoMT vulnerability scanning isn't just a technical task with a box to check. It's an ongoing risk-management function that should get sharper over time.

FAQs

Which IoMT devices should be scanned passively instead of actively?

Use passive scanning for highly sensitive, continuously operating medical IoMT devices where even small disruptions could affect patient care. This includes life-support systems, ventilators, infusion pumps, and devices that can’t safely handle active scans.

This usually relies on agentless packet-level monitoring or mirrored-traffic monitoring, such as SPAN/TAP. The goal is simple: avoid interference while still profiling protocols and configurations.

How should we prioritize IoMT vulnerabilities when patching could affect patient care?

Prioritize IoMT remediation based on patient safety and clinical impact, not CVSS scores alone.

That means ranking issues by a few practical factors:

• Exploitability
• PHI exposure
• Clinical criticality
• Internet-facing exposure

In plain English, a flaw on a patient-connected device in active use may matter far more than a higher-scoring issue on a less sensitive system. CVSS helps, but it doesn't tell the whole story.

Never actively scan devices that are treating patients. That's a hard line.

Instead, use passive monitoring to get visibility into device activity and risk. Schedule active scans during maintenance windows, set risk-based SLAs, and use compensating controls for devices that are hard to patch. Common examples include network segmentation and enhanced monitoring. At the same time, coordinate closely with vendors on update timing and patch plans.

What records should we keep to make IoMT scanning auditable and compliant?

Keep time-stamped records of each scan, including the date and time, scanner settings, asset scope, identified CVEs, severity ratings, and follow-up scans that show fixes were made.

You should also keep risk registers, mitigation plans, and signed risk acceptance memos. Store these records in tamper-evident, read-only formats for at least six years to support HIPAA compliance.

Censinet RiskOps can help keep this evidence in one place, track who owns each remediation task, and produce audit-ready reports.

Related Blog Posts

• How Automated Scanning Improves Medical Device Security
• Q&A: Medical Device Vulnerability Scanning Explained
• IoMT Penetration Testing: Key Strategies
• Best Practices for IoT Device Security