Best Practices for IoT Device Security

If you don’t have a live view of your medical devices, you’re already behind. In one 2025 review, 99% of healthcare groups had devices with known exploited flaws, which means device security has to be watched all the time - not checked once a year.

I’d sum the article up like this: secure healthcare IoT by keeping a current device inventory, ranking devices by patient and data risk, tracking new flaws, patching with care, using network limits when patches don’t exist, and setting clear ownership across IT, biomed, compliance, and clinical teams. The point is simple: find device risk early, contain it fast, and avoid care disruption.

Here are the main takeaways:

• Start with visibility: keep one inventory across IT, clinical engineering, and vendor records
• Tag devices by risk: include clinical use, internet exposure, remote access, ePHI use, and support status
• Watch for flaws all the time: track CVEs, FDA notices, vendor alerts, and SBOM-linked component risk
• Patch with control: test first, schedule downtime, verify device function, and document rollback steps
• Use backup controls when patching isn’t possible: segment networks, restrict traffic, and watch behavior through passive monitoring
• Set ownership: make sure security, IT, biomed, compliance, and clinical leaders each know who decides what
• Stay aligned with U.S. rules: FDA guidance, NIST device security work, and HIPAA risk analysis all point to the same need: keep device risk review current

A few numbers make the issue plain:

• 99% of reviewed healthcare groups had devices with known exploited flaws
• 46% of medical IoT devices had an unaddressed flaw
• 19% ran unsupported operating systems
• 44.4% of ransomware attacks on U.S. healthcare groups disrupted care delivery

Bottom line: if I were putting this into practice, I’d begin with a single device inventory and risk tags first. That gives me the base I need to monitor flaws, set patch order, and lock down device traffic without getting in the way of patient care.

Understand healthcare IoT risk and U.S. regulatory requirements

The healthcare IoT risk categories that matter most

Focus on five healthcare IoT risks first: patient safety, care disruption, ePHI theft or tampering, insecure remote access, and third-party and supply-chain exposure.^[4][5]

Patient safety comes first. A cyber incident can change an infusion pump dose, disable a cardiac device, or send wrong imaging or vital-sign data to clinicians. That creates a direct threat to a patient's life.^[6][7]

Care disruption is another major problem. If ransomware knocks out ventilators, anesthesia workstations, or PACS, staff have to switch to manual workarounds. And when that happens, the chance of mistakes goes up.^[5][7]

Bedside monitors, telehealth devices, and connected lab analyzers all send patient data across networks. If an attacker intercepts or changes that data, it can hurt both HIPAA compliance and clinical decisions.^[4][5]

Remote access adds even more risk. Many medical devices rely on vendor remote access for support and updates. Weak authentication, shared credentials, or unencrypted connections can give attackers a direct route into clinical networks and safety-critical systems.^[5][7]

Third-party and supply-chain exposure also matters. Many devices depend on software components, cloud services, and vendor-managed platforms. If a shared component or remote portal has a flaw, many devices can be exposed at the same time. That’s why coordinated risk management matters here.^[5][8]

Use these five categories to decide what to monitor first, which patches need fast action, and where response time matters most.

What FDA, NIST, and HIPAA require for ongoing risk management

These frameworks split responsibility in different ways, but they all point to the same idea: risk management can't be a one-time task.

FDA's postmarket cybersecurity guidance, including its 2023 final guidance on Cybersecurity in Medical Devices, expects manufacturers to monitor for new vulnerabilities, assess patient safety impact, communicate mitigations to users, and provide timely updates and patches. Critical vulnerabilities that create uncontrolled risks should be addressed as soon as possible.^[3][4][2][1] On the buyer side, that means vendors should be required to monitor vulnerabilities and support coordinated disclosure.

NIST IR 8259 lays out the baseline security capabilities IoT devices should have before deployment. These include:

• Unique device identification
• Secure configuration controls
• Data protection for stored and transmitted information
• Restricted logical access to interfaces
• Security event logging

Procurement teams should verify those capabilities before approving a device for use.^{[9][11][12][13][15]}

HIPAA turns this into a day-to-day monitoring issue. The HIPAA Security Rule requires covered entities and business associates to conduct an ongoing risk analysis across every system that creates, receives, maintains, or transmits ePHI. Networked medical devices clearly fall into that group.^[10][14] HHS repeatedly cites missing or incomplete risk analysis as a top HIPAA failure.^[10] That analysis should be updated at least once a year and whenever major changes happen, like adding new devices or changing network architecture.^[14]

All of those requirements rest on one thing: a live inventory that shows every connected device, who owns it, and what it’s exposed to.

sbb-itb-535baee

Protecting Healthcare IoT Devices: Best Security Practices

Build a real-time IoT asset and risk inventory

Continuous monitoring starts with a current device inventory. Without one, it's hard to set patch priority, react to vendor advisories, or show auditors that controls are in place. Recent studies found that 46% of medical IoT devices had an unaddressed vulnerability, and 19% ran unsupported operating systems.^[18][17]

Create a unified inventory across IT, clinical engineering, and vendor records

Bring together IT, clinical engineering, and vendor records using a shared device key. In practice, that usually means a single device key made up of manufacturer, model, serial number, and physical location. That key lets teams match records across systems instead of dealing with disconnected entries that refer to the same device in different ways.

From there, connect feeds from your CMDB, CMMS, and vendor portals into one risk platform through APIs or scheduled exports. Then clean up naming so different labels point to the same device type. If one system says "IV Pump" and another says "Infusion Pump", they should roll up into one clear record, not two half-useful ones.

Once that shared inventory is in place, the next step is to rank each device by clinical criticality and exposure.

Tag devices by clinical criticality and exposure

CVSS scores help, but they don't tell the whole story. A moderate-CVSS issue on a life-sustaining ventilator with internet exposure may call for faster action than a high-CVSS flaw on a non-networked diagnostic device in a low-acuity area. That's where clinical and exposure tags earn their keep.

Tag devices by function, such as:

• Life-sustaining: ventilators, anesthesia machines, ECMO systems
• Therapeutic: infusion pumps, dialysis machines
• Diagnostic imaging: CT, MRI, ultrasound
• Monitoring: bedside physiologic monitors, telemetry
• Ancillary: lab analyzers

Then pair those with exposure tags like internet-facing status, ePHI handling, network zone, remote access setup, and vendor support or end-of-life dates.

Devices marked Critical Exposure / High Clinical Criticality should trigger rapid review, compensating controls, and executive notice if patches are delayed. Lower-tagged devices can move through normal patch cycles.

Those tags should feed patch priority, monitoring thresholds, and escalation workflows.

Use a risk platform to keep inventory current

Manual tracking falls behind fast. Devices move. Firmware changes. Systems get retired. A 2023 study found that about 20% of surveyed organizations relied on manual spreadsheets as their main tracking method, and 19% said their inventory was either never updated or updated only once a year.^[19]

The most workable approach combines passive network monitoring, CMDB integration, and periodic clinical validation. Passive discovery uses SPAN ports, TAPs, or NetFlow data to spot devices through manufacturer OUIs, traffic tied to protocols like DICOM or HL7/FHIR, and behavior patterns, without sending probes that could interfere with sensitive equipment.^{[16][20][21][22]}

That matters more than it might seem at first glance. Many medical devices, including infusion pumps and bedside monitors, can't safely handle active scanning. That's why NIST and U.S. healthcare guidance keep pointing teams toward passive methods in clinical settings.^{[20][21][22][24]}

Censinet RiskOps™ puts device records, vendor artifacts, vulnerability status, and remediation tracking in one place for healthcare teams.

With a live inventory in place, teams can track vulnerabilities and patch status on a continuous basis.

Set up continuous vulnerability and patch management

The next step is to spot new vulnerabilities as soon as they show up - and deal with them without getting in the way of patient care.

Monitor vulnerability intelligence for medical devices

Keep an eye on NVD/CVE entries, FDA cybersecurity communications, vendor advisories, healthcare ISAC alerts, and public research disclosures.^{[1][27][28][30]}

Scope is a big deal here. A vulnerability might live in firmware, embedded operating systems, wireless protocols like Bluetooth, or third-party libraries bundled into the device. SBOM data makes it much easier to map new CVEs to affected components fast, so teams can see exposure without waiting for a separate vendor notice.^[30][31]

Those alerts help teams figure out which devices need an immediate clinical-context review.

Assess vulnerabilities in clinical context

CVSS by itself doesn’t tell you whether the affected device is an ICU ventilator or a low-risk ancillary device. That difference shapes both priority and response time.

Risk scoring should look at exploitability, patient safety impact, operational dependency, ePHI exposure, and active threat use.^[29][30][32] In plain terms, that means checking whether segmentation and authentication controls lower real-world exploitability, whether the issue could affect essential clinical performance, whether the device is tied to day-to-day operations, whether it stores or transmits ePHI, and whether attackers are actively using the vulnerability.

Document every risk-based decision. If your team accepts risk on a device because it sits on a segmented VLAN, write down the rationale, approver, and review date.

Apply patches safely and use compensating controls when patches are unavailable

Once a vulnerability has been prioritized, the next move is validated change control or mitigation.

Hospital patching takes testing, downtime planning, and close coordination with clinical teams. Many medical devices are end-of-life and have no available security patches,^[33] while others need manufacturer validation before any update can be installed.

The process usually follows a clear sequence:

• Confirm the patch is manufacturer-approved
• Test it in a lab or on a non-critical device first
• Schedule a maintenance window with clinical leadership
• Document a rollback plan
• Deploy during the agreed window
• Run functional checks
• Monitor for post-patch anomalies^[3][25][26]

Biomedical engineering, IT security, compliance, and clinical leadership all need clear roles in that process.

When patches aren’t available - which is common with legacy devices - network segmentation is one of the best compensating controls.^[29] Use patches when approved updates exist. When patching isn’t possible, lean on segmentation, authentication, and passive monitoring. Those controls need the same level of documentation as a patch.

Censinet RiskOps™ can organize workflows, evidence, and remediation tracking across IT, biomed, and compliance.

Design network segmentation, monitoring, and governance

Patching matters. But patching alone doesn't stop one infected device from moving across a hospital network. Containment does. And when patching is slow, blocked by vendor limits, or simply not possible, segmentation and monitoring become the front line. Those controls should map directly to the device criticality and exposure tags already stored in the inventory.

Segment medical IoT networks and secure device communications

Put medical devices in dedicated VLANs or security zones, then allow only approved traffic flows, such as pump-to-drug-library or modality-to-PACS connections.^[20][39][40] High-criticality devices should sit in the tightest zones, with the narrowest traffic paths and the fastest escalation routes when something goes wrong.

Microsegmentation pushes this further. Instead of trusting an entire subnet, it limits each device or device class to the exact systems it needs to reach. Internet access should work the same way: as an exception, not the default. Outbound traffic from IoMT VLANs should be limited to known destinations needed for device function, such as vendor update servers, secure time sources, and cloud PACS gateways, with deny-by-default firewall rules in place.^[37]

Vendor remote access needs the same level of control. Route it through a brokered DMZ or jump host protected by MFA, logging, and time-limited access tied to change tickets.^[37]

Where devices support it, require TLS for device-to-server traffic and remove legacy protocols such as unencrypted Telnet or FTP. If a device can't handle modern encryption, the answer isn't to shrug and hope for the best. Use tighter segmentation, strict host allowlists, and passive traffic monitoring instead.^[37][38] Those zone rules also tell you what should trigger an alert.

Use passive monitoring and SOC integration to detect abnormal device behavior

Start with passive telemetry and build baselines by device class. Then alert on anything outside the normal pattern, whether that's protocol, destination, traffic volume, or timing.^[37][38] A pump may normally talk to a medication server and a time server on a small set of ports. A bedside monitor may keep a low-bandwidth telemetry stream open to a central station. That's normal.

When a device steps outside that pattern, it should stand out fast. A pump contacting an external IP is a red flag. An imaging device scanning the network over SMB is another. That's the kind of drift that should fire an alert right away.

Those alerts should feed into the SOC and SIEM so IoMT activity can be tied to endpoint alerts and firewall logs. That correlation matters. A single alert may look minor on its own, but paired with other signals, it can show a bigger problem unfolding. Incident responders also need device criticality at a glance. For devices like ventilators or anesthesia machines, isolating the device from the network is almost always safer than shutting it down during care.^[37][38] Those cases should move through the governance path below.

Regulators and expert guidance are leaning more heavily toward segmented and microsegmented designs, especially where PHI and safety-critical devices are in play, because these setups support continuous monitoring and align with HIPAA and FDA postmarket cybersecurity expectations.^{[3][34][4][1][37][38]}

Set up governance, coordinated disclosure, and peer benchmarking

Security, IT operations, biomedical engineering, compliance, and clinical leadership all need clear ownership for device risk decisions.^[23] Without that, segmentation rules drift, exceptions pile up, and no one is quite sure who can say yes, no, or not yet. Governance keeps those decisions current and tied to day-to-day monitoring instead of a one-time network diagram.

Coordinated vulnerability disclosure should be formal, documented, and repeatable, not something handled on the fly. FDA guidance expects manufacturers of cyber devices to keep a plan to monitor, identify, and address vulnerabilities within a reasonable time and to use coordinated vulnerability disclosure processes.^[34][31] For HDOs, that means a clear intake policy, acknowledgment of reports within set timeframes, severity-based triage, coordination with affected vendors, and records of decisions about FDA reporting under 21 CFR Part 806 when corrections are needed to prevent serious injury.^{[3][35][7][36]}

Track segmentation rules, approved flows, exceptions, and review dates in a risk register.

Conclusion

When governance, segmentation, and monitoring work in sync, healthcare IoT risk becomes something teams can handle. Healthcare IoT security isn't a one-and-done project. It's a program that keeps moving because the risk keeps moving too. New devices show up, new flaws surface, and exposure shifts over time.

That only works if the pieces connect: a live inventory, risk-based vulnerability management, safe patching, compensating controls, and clear governance. On their own, each one helps. Together, they form the system.

In healthcare, medical device security risks doesn't just create a compliance problem. It can affect patient care.

The clearest next step is visibility. For U.S. healthcare organizations, that means closing the visibility gap and building a current inventory with clinical criticality and exposure tags. Censinet RiskOps™ can support that continuous view and risk tracking.

The goal isn't perfect security. It's faster detection, tighter containment, and uninterrupted care.

FAQs

How do we start securing medical IoT devices?

Start with a complete and accurate asset inventory. In healthcare, you can’t protect what you can’t see, and guessing is a bad bet.

Use passive network monitoring to find servers, clinical applications, and IoT devices without disrupting patient care. That matters. The last thing any team wants is a scan that interferes with a bedside device or slows a clinical system at the wrong moment.

Once assets are found, group them by:

• device or system type
• clinical importance
• data sensitivity

That gives you a clearer view of which assets carry the most risk and which ones need attention first.

Key first steps include:

• building a unified inventory
• assigning clear ownership across teams
• using passive discovery to identify shadow IT
• ranking devices by risk and setting governance

What if a medical device cannot be patched?

If a medical device can't be patched, healthcare teams should put compensatory controls in place to cut risk without disrupting patient care.

That usually means a few practical steps:

• Isolate the device with network segmentation
• Enforce stronger access controls
• Use virtual patching through next-generation firewalls
• Document time-bound risk exceptions with clinical justification and review them quarterly
• Continuously monitor device behavior and communication, and coordinate future updates or retirement

This approach helps protect the device while keeping it available for clinical use. It also gives security and care teams a clear path for managing risk until the device can be updated or phased out.

Who should own IoT device security in a hospital?

IoT device security works best with a federated governance model. In plain English, that means one central group sets direction, while different teams handle their part of the work. The enterprise risk committee should lead that model, with the Chief Information Security Officer overseeing the overall strategy. A multidisciplinary team made up of IT security, network operations, clinical engineering, and compliance helps keep everyone moving in the same direction.

At the device level, use dual ownership. Each device should have:

• a business owner, such as Facilities or Clinical Operations
• a technical owner, such as IT or Security

That split matters. The business owner is accountable for how the device supports day-to-day work. The technical owner handles the security and technical side. It’s a simple setup, but it helps avoid the all-too-common problem where everyone assumes someone else is in charge.

Related Blog Posts

• 7 Critical Medical Device Security Risks in Healthcare
• Medical Device Patching: Challenges and Solutions
• Study: 162 New Medical Device Vulnerabilities Found
• Best Practices for IoT Device Inventory in Healthcare