IoT Device Security Benchmarks for Healthcare

If you can’t measure device security, you can’t lower device risk. In U.S. healthcare, that matters because 92% of organizations reported at least one cyberattack in the last year, while many hospitals still deal with weak inventories, old devices, slow patching, and limited log visibility.

Here’s the short version: I’d use FDA, NIST, AAMI, and IMDRF as the baseline, then track a small set of device checks across both clinical and non-clinical connected systems. That means watching SBOM access, patch timing, default password removal, encryption, segmentation, logging, end-of-support status, and risk review coverage.

What matters most:

• Know what you have: keep a versioned device inventory
• Check vendor security proof: SBOMs, signed updates, CVD process
• Track access risk: remove default credentials and shared admin accounts
• Watch patch delay: many medical and IoT devices still carry known flaws
• Segment devices: this helps when a patch can’t be applied fast
• Monitor device activity: send logs to a SIEM and track detection time
• Flag aging assets: unsupported devices need extra controls or replacement plans
• Report trends: leaders need risk movement, not raw device totals

A few numbers show why this matters:

• 38% of a hospital’s healthcare IoT footprint can be IV pumps
• 73% of IV pumps were found with flaws tied to safety, privacy, or uptime
• 46% of medical IoT devices had at least one known vulnerability
• In one large study, 75% of infusion pumps had known vulnerabilities
• 89% of organizations in a 2025 analysis had medical systems exposed to public exploits and insecure connections

Protecting Connected Medical Devices With Palo Alto Networks IoT Security (Sponsored)

Quick comparison

So if I had to boil the article down to one point, it would be this: the best healthcare IoT benchmark program is simple, measurable, and tracked over time - not once a year.

Standards That Define Healthcare IoT Security Benchmarks

For the devices named above, these four standards show what good security looks like in day-to-day use. In U.S. healthcare, IoT security benchmarks rest on four main sources: FDA medical device cybersecurity guidance, NIST cybersecurity and IoT publications, AAMI TIR57, and IMDRF principles. Each one plays a different role.

FDA sets device-specific compliance expectations. NIST lays out the control structure hospitals and security teams can use on the ground. AAMI connects security work to clinical risk management. IMDRF adds lifecycle accountability across infusion pumps, monitors, telehealth devices, and building systems.

The FDA sets the procurement and postmarket baseline.

FDA Guidance for Medical Device Cybersecurity

FDA's 2023 guidance implements FD&C Act §524B.^[1] As of October 2023, FDA began issuing "refuse to accept" decisions for premarket submissions that do not meet cybersecurity content requirements.^[7] That matters because it turns security from a nice-to-have into a hard gate. If the paperwork and controls are missing, the submission can stop right there.

FDA expects a machine-readable SBOM, a coordinated vulnerability disclosure process, signed updates, and a justified patch cycle that addresses critical flaws as soon as possible.^[2][6][3]

For hospitals, these expectations can be turned into plain procurement checks:

• Does the vendor provide a current SBOM?
• Is there a documented CVD process?
• Can the device receive authenticated, signed updates?
• Are default credentials removed or forced to change?

Third-party implementation guidance aligned with FDA expectations recommends 30–60 day remediation timelines for critical vulnerabilities.^[8]

NIST, AAMI, and IMDRF turn those expectations into operational and lifecycle benchmarks.

NIST, AAMI, and IMDRF Benchmark Foundations

NIST CSF's five functions - Identify, Protect, Detect, Respond, and Recover - map directly to healthcare IoT. NIST's IoT-specific publications spell out baseline device capabilities around asset identification, secure configuration, access control, cryptographic protections, event logging, and software update mechanisms. For hospitals, the practical test is simple: Is the device inventoried and grouped by clinical criticality? Is it segmented away from general-purpose networks? Can it be recovered cleanly after an incident?

AAMI TIR57 applies ISO 14971-style risk management to device security. In plain terms, it gives hospitals a way to rank risk by clinical impact, document compensating controls, and track cybersecurity inside the risk file and change-control process. That link between cyber risk and patient care is the part that makes AAMI matter in a hospital setting.

IMDRF N60 and N70 cover the full device lifecycle - development, support, limited support, and end-of-support. They give hospitals and manufacturers a shared way to classify a device's cybersecurity posture as it gets older. IMDRF N70 calls for clear communication of end-of-life dates and SBOM access for healthcare providers. Put together, these documents cover the path from design to decommissioning. The next benchmark domains make those ideas measurable.

sbb-itb-535baee

Core Benchmark Domains Healthcare Organizations Should Measure

The standards above only matter when you can turn them into checks you can track. That’s where benchmarks come in.

These benchmark domains turn broad security requirements into day-to-day operating checks for devices tied to patient care, PHI, and clinical uptime. Each metric should use a numerator/denominator format so teams can pull it from asset inventories, vulnerability scanners, or vendor attestations and compare results over time.

Risk Management, Identity, and Data Protection

Risk management starts with a basic question: How much of your device estate is actually being reviewed? A useful benchmark is the share of connected device categories with a current security risk assessment, along with how long it has been since the last review. AAMI's ANSI/AAMI SW96 standard lays out this process clearly through analysis, evaluation, control, and residual risk review, which makes assessment completion and review timing easy to track as measurable indicators.^[9] For high-risk clinical use cases like infusion pumps, patient monitors, and imaging systems, threat modeling coverage is another smart metric to watch.

For identity and access, focus on whether devices still rely on weak account practices. Track the percentage of devices using unique, non-default credentials and the number of shared administrative accounts still active. That matters because stolen credentials were involved in 88% of healthcare web application breaches^[10]. The message is pretty clear: shared admin logins and default passwords create avoidable risk. It also helps to measure the share of devices set up with least-privilege access. HHS 405(d) HICP guidance says changing default passwords can "significantly reduce the exploitability" of medical devices.^[11]

Data protection benchmarks center on encryption and firmware trust. Track the percentage of devices encrypting PHI in transit and at rest, the share using signed firmware validation, and the percentage with secure boot enabled. These checks are most important for devices that collect, transmit, or store PHI. They also line up with FDA expectations around cryptographic protections and code integrity.^[3]

Monitoring, Patching, and Network Resilience

Monitoring benchmarks show whether your team can actually see what devices are doing. Useful metrics include the percentage of devices sending event logs to a centralized SIEM, whether logs are kept long enough to support investigations, the percentage of high-risk devices with anomaly detection turned on, and mean time to detect (MTTD) device anomalies. FDA guidance also points to monitoring failed authentication attempts, integrity violations, unusual traffic, and configuration changes.^[3]

Patching is one of the clearest signs of IoT risk exposure. Track median time to patch by severity tier, the percentage of devices patched within policy timelines, and the number of devices past vendor end of support without documented compensating controls. Industry data shows 46% of medical IoT devices have at least one known vulnerability^[5], which makes patch coverage a core benchmark.

For network resilience, measure how many clinical IoT devices sit on segmented VLANs or microsegmented networks. This is especially useful when patching can’t happen fast. Both HHS and IMDRF point to segmentation as a compensating control for devices that cannot be patched quickly.^[4][11]

These metrics belong in continuous tracking, not a one-and-done audit.

What Research and Industry Studies Show About Healthcare IoT Security

Recent studies show where these benchmarks tend to break down in day-to-day use. Across U.S. healthcare organizations, the same weak spots keep showing up: incomplete inventories, slow patching, limited remediation, and poor visibility into device risk. The studies below make it pretty clear which benchmark areas need the most attention.

Common Benchmark Gaps Across U.S. Healthcare Environments

The pattern comes back to three recurring problems. First, incomplete inventories get in the way of patching, monitoring, and risk prioritization.^[26][24] If a hospital doesn’t know what it has, it can’t act with much confidence.

Patch latency and end-of-life exposure are just as stubborn. Armis found that 39% of nurse call systems had critical-severity unpatched CVEs, 27% of infusion pumps had critical-severity unpatched CVEs, and 19% of connected medical devices were running unsupported OS versions.^[25] That’s not just a technical headache. It becomes a patient-care problem fast.

These gaps are hard to close in a hurry because medical devices often come with certification limits, remote maintenance needs, and lean staff resources.^[13] Smaller hospitals tend to run into staff and tooling shortages. Bigger health systems face a different mess: device sprawl, legacy systems, and uneven tracking across sites.^[12][13]

Lessons from Major Device Vulnerability Events

Two events make this issue feel less abstract: URGENT/11 and Ripple20.

URGENT/11, disclosed in 2019, involved vulnerabilities in a real-time operating system used across many networked devices. The FDA specifically warned that a remote attacker could take control of certain medical devices, change device function, cause denial of service, or create information leaks, and that affected products included an imaging system, an infusion pump, and an anesthesia machine.^[14] The plain lesson here is simple: when inventories are incomplete, organizations have a much harder time figuring out which assets are affected and which ones are tied to patient care.

Ripple20 followed in 2020 and involved 19 vulnerabilities in the Treck TCP/IP stack, a third-party networking library embedded in devices across many vendors and sectors. Four of those vulnerabilities carried CVSS scores of 9.8 or 10.^[19][21][22] Events like Ripple20 show why inventories and SBOMs matter so much. They help teams identify affected devices faster and move on remediation sooner.^[15][26]

Both events point to the same rule: prioritize remediation by clinical criticality, not severity score alone. A high CVSS score matters, of course. But in healthcare, what matters just as much is where the device sits in care delivery and what happens if it fails.

Moving to Continuous IoT Compliance Monitoring: Key Takeaways

From Device Inventories and SBOMs to Continuous Benchmark Tracking

Those gaps point to a simple truth: compliance can't be checked once a year and left alone. The research covered in this article keeps coming back to the same issue: static, point-in-time assessments don't keep pace with how fast device risk changes. Continuous monitoring helps close that gap by tying versioned inventories to new vulnerabilities as they appear.

Once inventories and SBOMs are up to date, the next move is continuous control tracking. That starts with a complete, versioned device inventory linked to Software Bills of Materials (SBOMs) that include commercial and third-party components.^[6][30] For healthcare delivery organizations, collecting SBOMs one time isn't enough. They need to use them on a steady basis to connect new CVEs to deployed assets as those vulnerabilities surface.

Focus automation on the controls most tied to patient risk:

• segmentation
• patch status
• credential hygiene
• encryption
• remote access

These shouldn't sit in a report somewhere. They need to be treated as live operational signals.

Tooling matters, but ownership matters just as much. Clinical engineering, security, compliance, and vendor management need one shared operating view.

Key Points for Healthcare Leaders

Operational monitoring has little impact if it never reaches leadership reporting. For executives, the main question isn't how many devices are vulnerable. It's whether risk is moving down.

Boards need trend lines, not raw device counts. That includes the percentage of high-criticality assets with expired support, mean time to remediate overdue patches, and the share of devices with SBOM-linked visibility.^[28][29][30] Reporting at the board level works best when it shows whether the organization is reducing risk over time, which departments or device families are falling behind, and how remediation efforts affect clinical continuity and patient safety.

Use FDA, NIST, AAMI, and IMDRF as the baseline for benchmarks. Then track a small set of high-value controls in a steady way and update risk whenever new device or vendor information comes in.^[29][30]

FAQs

How often should healthcare IoT security benchmarks be reviewed?

Healthcare IoT security benchmarks shouldn’t be treated like a one-and-done audit.

Instead, review them on a recurring schedule.

Use annual assessments as your starting point. If your program is more mature, shift to quarterly reviews. And when new vulnerabilities show up or major software updates roll out, run event-driven reviews as well.

Which device security metrics matter most for hospital leaders?

Hospital leaders should focus on IoT security metrics that connect straight to patient safety, regulatory compliance, and day-to-day resilience.

That includes metrics like:

• Time to identify and patch vulnerabilities
• SBOM completeness
• Percentage of devices with unresolved cybersecurity anomalies
• Incident response time

Why do these matter? Because they turn security work into something you can measure in clinical terms. They also help hospitals show they’re prepared for FDA and HIPAA expectations.

What should hospitals do about unsupported or unpatchable devices?

Hospitals should put compensating controls in place to cut risk and keep clinical operations running. In plain terms, that means adding safeguards around systems and devices that may be harder to secure directly.

This can include:

• Network segmentation or microsegmentation to isolate high-risk devices on separate VLANs
• Strict role-based access controls so only the right people can reach the right systems
• Enhanced continuous monitoring to spot unusual activity early

Hospitals should also document these controls in the risk management file. That record helps show they took reasonable security steps for audit and compliance purposes.

Related Blog Posts

• Study: 162 New Medical Device Vulnerabilities Found
• FDA Patch Act: 1 Year Later in Medical Device Security
• Best Practices for IoT Device Inventory in Healthcare
• Continuous Compliance for Healthcare IoT Devices