Risk Assessment for IoT Devices in Healthcare

If you don’t know which connected devices you have, where their data goes, and how they could fail, you can’t judge risk in a hospital. In many U.S. hospitals, there are about 15,000 connected devices and roughly 10–15 devices per bed, while 53% of connected medical and IoT devices have known critical flaws and 98% of IoT traffic has been found unencrypted.

I’d sum up the article like this: healthcare IoT risk assessment is about ranking devices by patient safety impact, PHI exposure, downtime risk, ransomware spread, and compliance gaps. To do that well, I need to look at the device inventory, data flows, trust boundaries, lifecycle stage, known flaws, patch status, remote access, segmentation, and vendor support.

Here’s the core takeaway in plain English:

• Start with the inventory. Record device type, model, software version, location, owner, and network links.
• Map clinical criticality. A ventilator and an infusion pump do not carry the same risk as a camera or HVAC controller.
• Trace PHI and network paths. Check where data is created, stored, sent, and viewed.
• Review trust boundaries. Focus on EHR links, cloud services, vendor portals, and internal network zones.
• Assess the full lifecycle. Include procurement, deployment, maintenance, patching, incident response, and retirement.
• Use more than one method. Standards guide the process, threat modeling finds attack paths, and scoring helps rank fixes.
• Tie findings to FDA, HIPAA, and AAMI records. Risk only counts if it is documented and tracked.
• Keep watching after go-live. Risk changes when firmware, network access, vendor support, or clinical use changes.

A few numbers make the problem clear:

• 73% of infusion pumps had at least one flaw in one cited hospital dataset
• 38% of the healthcare IoT footprint in hospitals was tied to infusion pumps
• 83% of medical imaging devices were running unsupported operating systems in one cited review
• 72% of healthcare VLANs mixed IoT and IT assets
• 4% of surgical devices were found on guest networks

So the short version is simple: know the device, know the setting, know the data path, score the risk, document the controls, and reassess when things change. That’s the frame the rest of the article builds on.

Risk Assessment Scope: Assets, Data Flows, and Clinical Context

Once risk is framed in terms of likelihood and impact, the next job is defining the scope around the assets and the clinical setting that shape both. Before anyone starts scoring, assessors need a full asset inventory: device model, software version, function, location, owner, connectivity, and vendor support. Without that starting point, risk scoring doesn’t hold up. Asset class, data flow, and care setting all shape both likelihood and impact.

Device Classification and Criticality Mapping

Start by classifying devices based on clinical function, care setting, and the harm that could happen if the device is compromised. Life-support devices sit at the top of the list and need the closest review. Cynerio’s data from over 300 hospitals found that 73% of infusion pumps have at least one vulnerability that could affect patient safety, data confidentiality, or service availability, and infusion pumps alone account for 38% of a hospital’s healthcare IoT footprint.^[4]

Diagnostic imaging systems, surgical equipment, and patient monitoring devices come next. Facility IoT still matters because it can affect network security and PHI exposure, but the direct patient-safety impact is usually lower.

Mobility matters too. A device that moves across care areas doesn’t face the same exposure as one that stays in a fixed location. A pump used across multiple units, for example, may cross more network segments, interact with more staff, and enter settings with different controls in place.

After devices are grouped by criticality, the next step is to map where their data goes and which boundaries it crosses.

Data Flows, Trust Boundaries, and Compliance Boundaries

Trace where PHI is created, transmitted, stored, displayed, or accessed. Then map whether it moves into the EHR, cloud analytics tools, vendor portals, or local device storage. These paths show whether the device handles PHI, which controls are needed, and what evidence supports HIPAA-aligned auditing.

Palo Alto Networks’ Unit 42 IoT Threat Report found that 98% of all IoT device traffic was unencrypted, and 72% of healthcare VLANs mix IoT and IT assets, which makes lateral movement from user endpoints to medical devices easier.^[6] Claroty’s 2023 CPS Security report flagged another issue: 4% of surgical devices were found communicating on guest networks, a boundary misconfiguration that should be logged during scoping.^[7]

The main trust boundaries to document include:

• The connection between the device and the EHR
• Any cloud service tied to the device
• Vendor remote support portals
• The broader internal network

Each boundary should be checked for authentication strength, encryption status, segmentation, and monitoring coverage.

Those same boundaries need review across the full device lifecycle, not just at deployment.

Lifecycle Stages Covered in Assessment

The assessment should cover procurement, deployment, configuration, maintenance, patching, incident response, and retirement. Procurement is where security requirements need to be set up front: logging capability, encryption support, updateability, and documentation such as MDS2 forms and SBOMs. Deployment then decides whether those features are turned on and used the right way.

Palo Alto’s research found that 83% of medical imaging devices were running unsupported operating systems at the time of assessment,^[6] which points straight to gaps in patching and end-of-life management. Risk should be reassessed whenever software or firmware changes, integrations expand, remote access is turned on, or the device moves into a new clinical setting.

sbb-itb-535baee

Frameworks and Methods Used to Assess Healthcare IoT Risk

Once assets and trust boundaries are mapped, the next step is deciding how to assess risk. In practice, three methods show up most often: standards-based models, threat modeling, and scoring. Each one answers a different question. The strongest programs don't pick just one. They use all three together.

Standards-Based Models: NIST, ISO/IEC 27005, and Healthcare Guidance

Standards-based frameworks, which can be automated using ERM assessment tools, define the process. They don't automatically tell you which device is most risky.

NIST SP 800-30 structures risk assessment around framing, identification, analysis, and response. ISO/IEC 27005 follows a similar lifecycle: context, identification, analysis, evaluation, treatment, and monitoring. Both give teams a repeatable, auditable way to assess risk across many device types.

For healthcare, AAMI TIR57 connects cybersecurity risk to ISO 14971 safety risk. AAMI TIR97 extends that work into monitoring, patching, disclosure, and retirement. Put simply, they bring safety and security into the same workflow instead of treating them as separate tracks.

The big strength here is governance and consistency. These models make it easier to compare assessments across departments and line up cybersecurity decisions with enterprise risk management. The catch is that they still need to be shaped to the clinical setting. A device's risk in a hospital depends on patient-safety impact and workflow dependency, not only on technical exposure.

Threat Modeling Methods: STRIDE and Medical Device Security Analysis

Standards set the process. STRIDE helps teams spot failure modes.

The method looks at six threat categories:

• spoofing
• tampering
• repudiation
• information disclosure
• denial of service
• elevation of privilege

AAMI TIR57 guidance recommends STRIDE-style analysis as part of device cybersecurity risk work.

In healthcare IoT, STRIDE maps well to the interfaces and connections that matter most: ports, wireless links, APIs, companion apps, cloud dashboards, vendor support, update paths, and EHR integrations. That's where things often get messy in the field. Clinical impact then depends on what the device does and where it's used.

STRIDE's main limit is pretty simple: it is good at identifying threat types, but it does not, on its own, rank them by clinical harm or operational likelihood. That's where scoring helps.

Scoring-Based Approaches Compared

Scoring models turn risk analysis into ranked priorities. They combine inputs such as device criticality, known vulnerabilities, exploitability, network exposure, patch availability, and compensating controls into a single score. That score helps teams decide what to fix first.

FDA risk-based frameworks put weight on severity and exploitability, which supports semiquantitative scoring and audit evidence.

The table below compares the three approaches for healthcare use.

A simple way to think about it: use standards to set the process, STRIDE to expose failure modes, and scoring to rank remediation. Those rankings should then feed compliance mapping and audit evidence.

Compliance Mapping, Risk Scoring, and Audit Evidence

Once devices are ranked by risk, the next job is turning those rankings into the proof compliance teams need. A risk finding only goes so far on its own. It has to connect to the controls and records auditors look for under FDA, HIPAA, and AAMI guidance.

Mapping Findings to FDA, HIPAA, and AAMI Expectations

Since March 29, 2023, FDA premarket submissions for cyber devices have required postmarket vulnerability monitoring, update and patch processes, and a machine-readable SBOM. ^[5][3]

That means a firmware issue in an infusion pump can't live in a random spreadsheet or disappear into an email thread. It should appear in the device security risk file, with exploitability, patient harm, and the controls used to reduce the risk documented under AAMI TIR57 or AAMI SW96. ^[11][13]

HIPAA sets a similar bar, but from the ePHI side. The Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI. ^[15] So every connected IoT device that touches ePHI should be inventoried, with its OS version, patch status, network location, and remote access paths documented. If patching isn't feasible, the residual risk and compensating controls need to be recorded, along with a clear justification that matches the organization's risk. ^[16]

AAMI TIR57 helps tie all of this together by folding security risk management into ISO 14971 safety risk management. In plain English, security findings move through the same clinical safety workflow instead of sitting off to the side. ^[11] If an assessment finds a gap, like missing audit logging or weak authentication, AAMI guidance points teams to the security capabilities that should be chosen and documented in the risk file.

Those mappings become the audit trail for both remediation and ongoing monitoring.

Risk Variables and Audit Criteria That Matter Most

In practice, auditors usually zero in on a small group of variables that decide whether a finding is material.

Device criticality tends to carry the most weight. If a ventilator or cardiac monitor is compromised, the impact can hit patient safety directly. That is why these devices call for the strictest documentation. Unsupported or end-of-support software is another major issue. Components that no longer get patches should be clearly flagged in SBOM-related materials and risk files because they create a known, continuing exposure. ^[3][14]

Auditors also spend a lot of time on core security controls tied to ePHI, including:

• Authentication strength
• Encryption
• Secure boot
• Network segmentation
• Firewalling
• Remote access controls, especially vendor remote service

Weaknesses in authentication, encryption, and secure boot affect ePHI confidentiality and integrity. ^[12][15][16] Network segmentation, firewalling, and remote access controls get the same level of scrutiny because auditors want proof that medical devices sit in dedicated, tightly governed network zones with least-privilege access in place. ^[17][18]

Managing third-party risk matters too. Auditors often review business associate agreements, manufacturer disclosure statements (MDS2 forms), and contractual cybersecurity commitments to confirm that third-party obligations can actually be enforced.

The evidence they usually expect includes:

• A full asset inventory
• A formal security risk analysis with likelihood-impact ratings and residual risk rationale
• Network diagrams that show segmentation
• Configuration exports that confirm access controls and logging
• Records of vulnerability notifications and remediation activities ^[1][15][16]

Running Assessments at Scale with Healthcare RiskOps

The hard part is operations. All of this evidence has to be gathered, updated, and kept current across a large device fleet. Manual assessment falls apart fast when you're dealing with hundreds or thousands of devices. Pulling device attributes, vendor documents, SBOMs, and control evidence can swamp a small team.

Censinet RiskOps™ brings questionnaires, evidence collection, benchmarking, and compliance mapping into one place across internal teams and vendors. ^[9][10][11] It also supports benchmarking across device and vendor risk profiles, which helps teams decide what to fix first and can shape procurement choices. Its collaborative features let HDOs and vendors share SBOMs, vulnerability disclosures, patch plans, and security artifacts in a structured way, supporting both premarket review and postmarket monitoring.

Postmarket Monitoring, Governance, and Conclusion

Risk assessment doesn't stop at go-live. It has to keep going through the full device lifecycle because vulnerabilities, system settings, and clinical workflows change after deployment.

Once teams document risk findings, those findings should move straight into ongoing monitoring and response.

FDA postmarket guidance says manufacturers must monitor, identify, and address vulnerabilities throughout the device lifecycle.^[2][1][8] Section 524B also requires a postmarket monitoring plan in premarket submissions, including coordinated vulnerability disclosure.^[5][3] The need for that kind of follow-through is hard to ignore. As of January 2022, an FBI Cyber Division report found that 53% of connected medical devices and IoT devices in hospitals had known critical vulnerabilities, with an average of 6.2 vulnerabilities per medical device.^[19][20]

That is why postmarket governance needs a few basic pieces in place:

• Active tracking of newly found vulnerabilities
• Vendor escalation paths
• Clear internal escalation paths

Those steps sound simple, but they fall apart fast if no one owns them. Monitoring, escalation, and disclosure need named owners before deployment, not after a problem shows up.

Reassess after any device, network, or clinical change. AAMI refers to this as continual management.^[21]

Key Takeaways for Healthcare Leaders

For healthcare leaders, the operational priority is straightforward: keep the risk program current after deployment.

That means keeping the asset inventory up to date, tracking vulnerabilities as they appear, staying in contact with vendors, and assigning clear ownership for monitoring, disclosure, patching, and escalation. Those activities should line up with FDA Section 524B, HIPAA, NIST, and AAMI guidance.

Censinet RiskOps™ helps HDOs keep risk records current and coordinate vendor input across the postmarket lifecycle.

FAQs

How do hospitals prioritize IoT device risk?

Hospitals rank IoT device risk by keeping a complete, always-updated inventory and scoring each issue based on two things: patient safety impact and how easy it is to exploit.

They deal with the most dangerous problems first. That usually means vulnerabilities that:

• allow remote compromise
• are easy to exploit
• put medical data integrity at risk
• affect key device functions, such as infusion pumps or ventilators that are in active use

They also look at whether the problem sits in the hardware or the software.

What makes a medical IoT device high risk?

A medical IoT device becomes high risk when its cyber weak spots could realistically hurt patients or expose sensitive health data.

A few red flags tend to show up again and again. The device may store or send PHI/ePHI. It may run unpatched or legacy software. Access controls might be weak, or the device may still use default credentials. Other warning signs include insecure interfaces, weak encryption, poor logging, remote exploitability, or a role in critical clinical functions.

Risk also goes up when devices are past end-of-life, set up the wrong way, or backed by weak vendor or supply-chain controls. In plain terms, if a device can be tampered with, reached from afar, or used to get at patient data or care systems, the stakes are high.

How often should healthcare IoT risks be reassessed?

Reassess healthcare IoT risks on a set schedule. For most devices, that means every 6–12 months. For higher-acuity clinical equipment, check more often, such as quarterly or semiannually for deeper reviews.

You should also reassess when major changes happen. That includes:

• Critical CVE disclosures
• Vendor advisories
• Device relocation
• New third-party services
• Major firmware or software updates

Continuous monitoring helps keep risk scores current and confirms that remediation steps were completed.

Related Blog Posts

• NIST SP 800-213 for Medical Devices: What to Know
• HIPAA Compliance for IoT Medical Devices
• Ultimate Guide to IoT Risk Assessment in Healthcare
• Best Practices for IoT Device Security