Common Compliance Gaps in Medical Device Security

Most medical device security failures come down to five gaps: missing inventory, weak patch tracking, poor access control, unclear ownership, and thin logging/incident response. If I miss any one of those, I make audits harder, slow down response, and leave patient care exposed.

Here’s the short version:

• If I don’t know what devices I have, I can’t assess risk
• If I can’t link devices to SBOMs, CVEs, and patches, I can’t track exposure
• If access, authentication, and encryption are weak, device misuse gets easier
• If ownership is split, fixes stall
• If logging and response steps are weak, incidents drag on and reporting gets messy

The numbers make the problem plain:

• 89% of healthcare groups had their highest-risk connected medical devices on the network
• 9% of IoMT devices had known exploitable flaws
• 99% of healthcare groups had devices with known exploited vulnerabilities
• 24% of healthcare groups reported a medical-device cyberattack in the past year
• 80% said patient care was moderately or heavily affected

Webinar: Master Medical Device Cybersecurity: Avoid FDA Delays

sbb-itb-535baee

Quick comparison

Gap	What breaks	What I need to fix first
Asset inventory	Unknown or unmanaged devices	Build one shared device record
Vulnerability/SBOM/patching	No clear view of exposure or fix status	Match inventory to SBOMs, CVEs, and patch records
Access and encryption	Weak login, shared accounts, cleartext data	Lock down every interface and use compensating controls for older devices
Governance	No clear owner for decisions and exceptions	Assign named owners across IT, biomed, compliance, and procurement
Logging and response	Slow detection, weak evidence, missed reporting steps	Centralize logs and test device-specific response playbooks

If I want cleaner audits and fewer gaps at the bedside, I need one owner, one record, and one traceable workflow for each device from purchase to retirement.

What These Compliance Gaps Have in Common

These five gaps may look different on the surface, but they tend to break in the same place: they weaken your proof of what devices you have, what risks come with them, and what you're doing in response.

At the center of this is weak documentation and weak monitoring. A team may have partly reduced a risk. But if the asset isn't logged, the compensating control isn't documented, and no one is assigned to follow up, the organization still can't defend its position. FDA expects cybersecurity work to be documented as part of quality-system controls, including complaint handling and corrective and preventive actions.^[3] Evidence is what turns a known risk into something you can explain during an audit instead of something that becomes an audit finding.

This problem gets much bigger in connected-device environments. A 2025 healthcare exposure report found that 89% of organizations had the top 1% riskiest connected medical devices on their networks, and 9% of IoMT devices contained confirmed known exploitable vulnerabilities.^[10] That's not a small outlier. It's what happens when teams rely on point-in-time monitoring.

Use the same four lenses below for every gap in this list.

Lens	What it asks
Regulatory exposure	What FDA requirements or other obligations are at risk if this gap persists?
Patient safety impact	Could this gap affect device availability, clinical care, data integrity, or delayed treatment?
Visibility gap	What can't the organization currently see, track, or measure because of this weakness?
Remediation priority	How urgently does this need to be addressed, and what's the documented rationale for that decision?

These lenses make risk scoring more grounded because they force a structured review. A gap may rank high for patient safety and low for regulatory exposure, or the other way around. That distinction matters when time, staff, and budget are tight, and teams need a clear reason for fixing one issue before another. Use the same lenses to keep each gap current, assigned, and ready for audit.

The first gap starts with asset inventory, because unknown devices weaken every other control.

1. Incomplete Medical Device Asset Inventory and Classification

Most healthcare organizations end up with two half-finished inventories: IT tracks network endpoints, and clinical engineering tracks physical assets. The problem is simple: neither list shows the full picture.

That gap creates a compliance problem fast. Hospitals have lost track of roughly 30% of their networked medical devices, and nearly 40% of connected enterprise devices in healthcare are unmanaged, which means they aren't monitored or listed in any asset inventory.^[20][22] The devices that slip through are often the ones people assume are already accounted for, like telemetry monitors, infusion pumps, and legacy devices sitting behind serial-to-IP gateways. And once the inventory is incomplete, every other control gets harder to show on paper.

Regulatory Exposure

HIPAA's Security Rule calls for an accurate and thorough risk analysis of every system that handles ePHI.^[16] That's hard to do if you don't know what devices you have.

The proposed HIPAA Security Rule updates push this even further. They would explicitly require covered entities to keep a technology asset inventory and a network map that shows ePHI flows, with updates at least every 12 months and whenever operations change.^[11] FDA guidance also expects asset, threat, and vulnerability tracking as part of risk management over time. If device records are missing, the risk analysis gets weaker, and so does your defense during an inspection. What starts as a paperwork gap can turn into one of several critical medical device security risks that lead to bedside issues when a device fails during an incident.

Patient Safety Impact

An untracked device can't be assessed, segmented, or planned for.^[18] That means clinical teams may not know which pumps, monitors, or imaging peripherals are affected until care has already been disrupted.^[18]

Industry case studies describe ransomware attacks on central monitoring stations that knocked out telemetry feeds from more than 20 bedside monitors that had never appeared in the IT asset list, forcing staff to revert to manual vitals checks.^[12][18]

That's the part that hits hardest. If a device isn't on the list, it can disappear right when staff need answers most.

Operational Visibility Gap

IT, security, and clinical engineering often each see a different slice of the same device fleet.^[13][17] IT may see the workstation, but not the monitor behind it. Clinical engineering may track the physical device by asset tag and room location, but not its IP address or network segment.^[12][13][17]

Then devices move. A pump gets reassigned. A monitor shifts to another department. No one updates a central record because there isn't one shared record to update.^[17] So there is no single source of truth.^[17] That leads to missed patches, fuzzy ownership, and vulnerability alerts that can't be tied back to exact devices.

A practical fix is to build one inventory from multiple data sources, including:

• Network scans
• DHCP logs
• SNMP queries
• Maintenance data

Then connect that inventory to vulnerability and recall tracking.^[13][21]

Remediation Priority

Start where the risk is highest: ICU, OR, and telemetry units.^[13][17] From there, sort newly found devices into risk tiers. Life-supporting devices or critical monitoring devices that handle ePHI come first. Diagnostic or imaging devices come next. Ancillary devices come after that.^[14][18][19]

Each device record should include, at a minimum, the following details:

• Make
• Model
• Unique ID
• Firmware
• IP/network segment
• Location
• ePHI status
• Owner
• End-of-life date

That baseline record makes later work far less messy.^[14][19] Ownership should sit jointly with IT security and clinical engineering, with a deadline tied to the next HIPAA risk analysis cycle so the inventory work flows straight into documented risk assessments.^[11][16]

Once the inventory is complete, the next task is tracking vulnerabilities, SBOMs, and patch status against it.

2. Poor Vulnerability Monitoring, SBOM Management, and Patch Governance

Once you have an inventory, the next problem hits fast: can you track the software, vulnerabilities, and patch status for each device? That’s where many teams get stuck. The issue isn’t just knowing a device exists. It’s not having a live view of what’s running on it, what’s exposed, and what has or hasn’t been fixed.

The scope of the problem is hard to ignore. 99% of healthcare organizations have devices with known exploited vulnerabilities on their networks, and many end-of-life devices get little or no patching.^[30][31][33] Without continuous monitoring, there’s no solid record of what was found, what was fixed, and what is still open. And that missing record is often what turns a security gap into a compliance problem.

Regulatory Exposure

Section 524B and FDA cybersecurity guidance call for a machine-readable SBOM, ongoing vulnerability monitoring, coordinated disclosure, and documented patching.^[6][28][5] The gap here usually isn’t that teams don’t know the rules. It’s that they can’t show proof of monitoring and patch governance when asked.

FDA also folds CISA's Known Exploited Vulnerabilities (KEV) catalog into SBOM work and ongoing vulnerability monitoring.^[5] That matters because KEVs point to flaws that attackers are already using in the wild. In plain terms, if a device is exposed to one of these issues, the risk isn’t abstract.

Manufacturers generally do not need additional FDA review to ship security-strengthening patches, which removes one of the most common reasons for delay.^[15][1] What regulators want to see instead is clear patch rationale, validation under change control, and updated SBOMs after each patch cycle.^{[15][23][24][3]} If that paperwork is missing, even a good-faith patching effort can come across as a compliance failure during an inspection.

Patient Safety Impact

WannaCry made this painfully clear. It hit medical devices and disrupted hospital operations, but it wasn’t only a malware story. It was also a failure in tracking, documentation, and governance.^[34]

The risk is still here. 8% of imaging systems in U.S. healthcare networks carry KEVs tied directly to ransomware attacks, and in one survey, 86% of organizations reported patient monitors with known exploited vulnerabilities.^[30][31] These are not edge cases sitting in a lab somewhere. These are devices tied to care delivery.

Operational Visibility Gap

At the center of this issue is a missing link: SBOMs connected to the actual configurations running on deployed devices. Without that link, teams can’t map CVEs or KEVs to specific devices in a fast, reliable way. As a result, exposure stays unmeasured and remediation doesn’t get ranked properly.^[27][35]

The numbers make that plain:

• 53% of connected medical and IoT devices have at least one unpatched critical vulnerability.^[29]
• 1 in 5 connected medical devices run unsupported operating systems.^[32]

That’s the kind of gap that leaves teams guessing. And guessing is a bad way to run patching in a clinical setting.

Remediation Priority

Patch governance needs more than a ticket queue and a few spreadsheets. It needs a defined policy, risk-based prioritization using KEV and NVD data, validation, deployment windows that fit clinical workflows, SBOM updates after every patch cycle, and audit records that hold up under review.^{[15][23][24][3]}

This work also can’t sit in separate lanes. Biomedical engineering, IT security, and compliance teams need to work from the same process, with the same records, and with a shared view of device risk. A centralized risk platform can bring device, vulnerability, and patch records into one workflow, giving teams the evidence they need when auditors ask for proof.

When patching can’t close the gap fast enough, the remaining risk has to be contained through tighter access and encryption controls.

3. Weak Authentication, Access Control, and Encryption Controls

Patching doesn't fix everything. When it falls short, weak authentication and poor encryption leave devices open. And from a compliance standpoint, it's not enough to say a control is in place. The organization has to show that it is enforced across every interface. If patching can't close the gap, access and encryption controls become the next layer of protection.

Regulatory Exposure

FDA and HIPAA both require strong authentication, access control, auditability, and encryption for devices that handle ePHI.^{[38][7][36][5]}

Patient Safety Impact

In November 2024, CISA issued an advisory for the Baxter Life2000 Ventilation System describing hard-coded credentials, missing authentication, weak debug access, and cleartext transmission of sensitive information.^[37] That's not a small issue. Weak access control can let someone change therapy settings, silence alarms, or lock staff out during active care.

A 2023 analysis of medical devices purchased online found that 9% of cases involved hard-coded credentials, and authorization problems were also common.^[25]

Those breakdowns get even harder to catch when logs are sparse or incomplete.

Operational Visibility Gap

A lot of devices don't leave much of a trail. Some log very little. Some can't export anything to a SIEM. Others store events in proprietary formats that make review a chore. As a result, security teams often can't consistently see access, logging, and encryption status across key exposure points, including:

• maintenance ports
• vendor remote support
• local web consoles
• wireless links
• clinical integrations^[37][25]

Remediation Priority

Start with the basics: remove default and shared credentials from every interface, including service ports and management consoles.

Then check that the following controls are in place:

• unique IDs
• strong passwords
• session timeouts
• MFA for administrators
• role-based access
• device-level logging

After that, apply least-privilege access, segment device networks, and require encrypted transmission for PHI wherever technically feasible. Remote access should also be formally approved, time-bound, and documented, so support sessions don't turn into open-ended doors.

Legacy devices are where things get messy. If a device can't support these controls, use compensating measures like network isolation, jump hosts, service-account restrictions, and enhanced monitoring, with documented risk acceptance. Keep policy updates, validation tests, vendor guidance, and monitoring evidence on file. This documentation is critical for real-time portfolio risk management across the enterprise.

Without clear ownership, these controls drift fast.

4. Fragmented Governance and Unclear Ownership

Even strong technical controls can fall apart when no one owns the exceptions, approvals, and follow-up. That’s the core problem with fragmented governance: device security work gets split across teams, but no single person or group is clearly on the hook.

Regulatory Exposure

Manufacturers and HDOs both have a role in medical device cybersecurity. But when ownership is vague, advisories, patch decisions, and risk acceptance can sit in limbo instead of getting handled.^[2][3][26] The same problem shows up in vendor risk management. If no one clearly owns it, gaps open up fast: missing or weak BAAs, loose rules around PHI use, and little proof that vendors meet HIPAA Security Rule requirements.^[41][42]

Patient Safety Impact

Poor governance slows down the response to vulnerabilities and misconfigurations that can affect clinical performance.^{[3][26][39][6]} If alerts or recalls don’t reach the right technical and clinical owners, devices stay exposed longer than they should.^[3][26][43]

There’s also a coordination problem. If IT segments a network without working closely with biomed or clinicians, devices can lose access to critical services or monitoring systems. On paper, the change may look fine. In practice, it can disrupt care workflows.^[39][40][44]

Vendor access creates another weak point. When remote access is left broadly enabled without least-privilege controls, a compromised vendor account can disrupt patient-critical systems or help ransomware spread.^[41][42][44]

Operational Visibility Gap

Fragmented governance creates a major visibility gap. No single function has a full picture of device owners, vendor connections, patch decisions, risk acceptances, and clinical dependencies.^[39][40][44]

A common example: biomedical teams track devices in CMMS tools, while IT keeps network-level asset lists. But those records often don’t line up. That makes it hard to know what’s actually deployed, who supports it, and what risks are still open.

Vendor access paths can be just as murky. If those paths aren’t mapped, it becomes tough to answer basic but urgent questions:

• Which vendors have active connections?
• What data can they access?
• Which patient-critical assets are reachable through those paths?^[41][42][44]

Remediation Priority

The fix starts with clear ownership. A RACI chart can help assign named roles - such as the CISO, clinical engineering director, compliance officer, and vendor management lead - to core functions like asset inventory, vulnerability monitoring, patch decisions, vendor access controls, and incident response.^[39][40]

From there, patch deferrals, segmentation changes, and vendor access approvals should move through the same review path. Security and clinical engineering should review security changes together so they can confirm those changes won’t disrupt patient care.^[45]

Vendor risk management should sit inside that same program, not off to the side. That includes pre-contract security assessments, strong BAAs, and periodic reassessments based on incident history or service changes.^[41][42]

Clear ownership also shapes how fast incidents, recalls, and postmarket issues move from detection to action.

5. Gaps in Logging, Incident Response, and Postmarket Surveillance

Even when a team has a solid inventory and clear ownership, that doesn't mean it can spot, contain, and report device events in time. In many cases, response is still slow, uneven, and hard to repeat. Weak incident playbooks and uneven postmarket surveillance remain some of the biggest compliance gaps in medical device security.

Regulatory Exposure

FDA cybersecurity guidance clearly lists event detection and logging as a core security control category.^[51] FDA includes controls such as failed logins, configuration changes, connectivity anomalies, and integrity violations. Under FD&C Act Section 524B, manufacturers must also maintain a postmarket cybersecurity management plan that covers monitoring, vulnerability identification, and timely remediation, including coordinated vulnerability disclosure.^[1][52]

Reporting adds another layer of risk. In the U.S., manufacturers must submit corrections and removals to FDA within 10 working days when they take action to reduce a risk to health under 21 CFR Part 806, including cybersecurity-related corrections.^[9] HDOs without a clear process for deciding when a cybersecurity event becomes reportable, recording that decision, or coordinating with manufacturers on adverse event submissions can miss those deadlines or send incomplete information.^[43][47] And if logs aren't preserved, the facts needed for investigation and reporting may be gone when teams need them most.

Patient Safety Impact

When incident response playbooks leave out device-specific steps, escalation paths, and log-preservation actions, hospitals tend to respond slowly and inconsistently.^[18][47] Picture a ransomware incident hitting an infusion pump fleet. Staff may wait too long to isolate affected pumps, keep using dose libraries that may have been altered, or fall back on improvised manual workarounds without a standard clinical risk assessment. Those are predictable failure points when device security and clinical response operate on separate tracks.^[18][47]

Operational Visibility Gap

Without centralized telemetry, teams often can't piece together scope, timing, or patient impact after an incident. A Claroty report that analyzed more than 2.25 million IoMT devices across 351 healthcare organizations found that 89% of organizations operate medical systems with vulnerabilities tied to publicly available exploits.^[46] That kind of number makes the visibility problem hard to ignore.

Centralized alerting can help close that gap, especially when it pulls in sources like FDA Safety Communications and CISA's Known Exploited Vulnerabilities (KEV) catalog.^[50] If those signals live in separate places, teams waste time stitching the story together after the fact.

Remediation Priority

The same named owners assigned through governance should also run logging, response, and surveillance. Once an event is detected, the workflow can't be improvised. It needs to be documented and repeatable.

Three controls matter most here:

• Implement device-level logging for security-relevant events and send those logs to a centralized system that supports incident response and regulatory reporting.^[49][8][51]
• Build and test device-specific incident response playbooks with clear criteria for device isolation, clinical escalation, log preservation, and breach notification to HHS and FDA.^[47]
• Treat postmarket surveillance as an ongoing program by monitoring vulnerability feeds, tracking FDA safety communications, and feeding findings into a corrective and preventive action (CAPA) process.^[1][48]

Quick-Reference Tables for Compliance Teams

These tables help compliance teams turn the five gaps into day-to-day work: what to track, what to watch, who owns it, and what proof to keep.

---

Table 1: Asset Inventory Fields and Compliance Implications

Inventory Field	Compliance Relevance
Device identity and manufacturer support	Establishes unique asset identity; flags vendor support status for supply chain risk and coordinated disclosure
Software / firmware version	Reveals exposure to known CVEs and unpatched vulnerabilities
Platform support and patch status	Tracks update gaps and supports FDA postmarket cybersecurity expectations
Network location / IP address	Enables segmentation review, containment planning, and incident scoping
Data types handled (e.g., PHI, telemetry)	Maps to HIPAA Security Rule risk analysis requirements for ePHI systems
SBOM / embedded software components	Identifies vulnerable software dependencies and supports machine-readable tracking
Risk / criticality rating	Enables prioritization consistent with FDA and AAMI risk-based guidance
Log availability	Confirms whether device-level security events can be captured and retained

---

Table 2: Vulnerability Monitoring Sources Mapped to Actions and Evidence

Source	Review Cadence	Trigger	Required Action	Evidence Produced
NIST National Vulnerability Database (NVD)	Continuous / weekly	New CVE affecting device model or software component	Assess exploitability; set patch or mitigation path	Vulnerability assessment record, risk rating, remediation decision
CISA Known Exploited Vulnerabilities (KEV) catalog	Weekly	New entry matching device or component	Cross-check against inventory; escalate high-risk matches immediately	Exposure register, action memo, inventory update
FDA Safety Communications	As published	New advisory for a device type in use	Verify against local inventory; coordinate with vendor on response timeline	Advisory review log, vendor correspondence
Manufacturer security advisories	As published	Patch or disclosure for a device in inventory	Verify applicability; schedule deployment during low-census hours	Change control record, device-specific patch history
Health-ISAC alerts	As published	Emerging threat or sector-wide campaign	Update segmentation rules or access controls as needed	Meeting notes, updated policy or configuration record
SBOM analysis tools	Continuous / when ingested	New vulnerable component identified in SBOM	Generate remediation ticket; update SBOM record	SBOM import log, match results, remediation ticket
Internal vulnerability scans	Periodic or after changes	Scan detects open port, misconfiguration, or unpatched component	Confirm exposure; assign owner; track to closure	Scan report, exception record if deferred

---

Table 3: Control Weaknesses Mapped to Recommended Safeguards

Control Weakness	Recommended Safeguard
Default or hard-coded passwords	Enforce unique user accounts; implement RBAC; require password rotation and MFA; integrate with centralized identity management
Shared clinical accounts	Require individual user accounts; log all access; apply MFA
Unencrypted data in transit or at rest	Enable TLS for network communications; apply VPNs for remote access; use full-disk encryption
Flat network without segmentation	Deploy dedicated VLANs for medical devices; apply firewall rules and allowlisting
Outdated or unsupported OS	Document compensating controls; accelerate replacement planning; record decisions in the risk register
Limited or disabled logging	Enable device-level security event logging; standardize retention; integrate with SIEM
Devices that are hard to patch	Define maintenance windows; use virtual patching; document deferred patches with risk rationale
Fragmented ownership	Establish a RACI matrix; schedule recurring governance reviews; document role assignments

---

Once controls are set, give each one a single owner and a clear evidence trail. That keeps accountability simple and makes audits far less messy.

Table 4: Responsibility Matrix

Function	Primary Responsibilities	Key Collaborators
Clinical engineering	Device lifecycle, maintenance scheduling, configuration changes, validation testing	IT security, vendors
IT security	Network segmentation, identity and access management, vulnerability scanning, logging and monitoring	Compliance, clinical engineering
Compliance	Regulatory interpretation, policy oversight, audit documentation	Procurement, IT security
Procurement	Cybersecurity contract language, SBOM delivery requirements, supply chain risk management	Compliance, clinical engineering
Vendors	Secure design, security advisories, patch availability, SBOM delivery, incident collaboration	IT security, procurement

Escalation path: clinical engineering → IT security → compliance/legal.

---

This last table connects monitoring to response, so teams can move from detection to documentation without scrambling.

Table 5: Incident-Readiness Mapping

Activity	Owner	Supporting Role	Evidence / Output
Device-level logging (authentication, config changes)	IT security / clinical engineering	Vendors	Event logs, alert records
Network logging (firewall, IDS/IPS, NetFlow)	IT security	SOC	Centralized SIEM correlation records
Escalation (defined thresholds, severity levels, on-call contacts)	IT security	Clinical leadership, compliance	Incident ticket, escalation notes
Internal notification (clinical leadership, affected departments)	IT security / compliance	Clinical engineering	Notification record
Regulatory notification, when required	Compliance / legal	IT security, vendors	Regulatory submission, notification log
Post-incident review (root-cause analysis, patient safety impact, control gaps)	Compliance / risk management	IT security, clinical engineering, vendors	Lessons-learned report, updated risk register, control changes

Each table works best as a live document, not something that gets built once and forgotten. Set a review cadence - quarterly for the responsibility matrix and incident-readiness table, and continuous review for vulnerability monitoring. Then tie updates to actual events: new advisories, completed patches, completed audits, or post-incident findings.

How Structured Risk Monitoring and Analytics Can Close These Gaps

Live records only matter if they feed continuous monitoring. That’s the missing link. These gaps usually come back to one problem: oversight is scattered across teams, tools, and files. Continuous risk monitoring pulls asset data, SBOMs, vulnerability intelligence, risk scoring, and remediation into one traceable workflow.

The need for this is hard to ignore. A 2026 report found that 44% of healthcare organizations run medical devices with known unpatched vulnerabilities, and 28% run devices past end of support.^[54][55] In a separate finding, 53% of connected medical and IoT devices in hospitals have known critical vulnerabilities, with an average of 6.2 vulnerabilities per device.^[53][57] An annual review can’t keep up with that pace. Compliance teams need risk scores that update when CVEs shift, exploit intelligence changes, or device settings drift.

That kind of visibility turns raw risk data into action. Dashboards should track:

• Patch timelines
• Open critical findings
• Vendor response times
• Overdue remediation

Patch guidance showed up less often in advisories in 2024,^[56][10] so organizations can’t depend on advisories alone to close the loop. Detection is only part of the job. Traceability matters just as much. Each finding should move through a documented path: finding → risk assessment → corrective action plan → validation → closure. That chain lines up with FDA postmarket cybersecurity expectations for ongoing vulnerability monitoring and timely remediation,^[4][58] and gives compliance teams a clear evidence trail during audits instead of a patchwork timeline rebuilt after the fact.

Conclusion

These five gaps come back to three basic failures: visibility, governance, and follow-through.

Incomplete inventories point to a visibility problem. Weak patching is a follow-through issue. Weak authentication and encryption show governance gaps. Fragmented ownership slows action across the board. And when all three show up at once, logging and incident response tend to fall apart too.

This isn't a fringe issue. A 2026 survey found that 24% of healthcare organizations had a medical-device cyberattack in the prior year, and 80% said it had a moderate or major effect on patient care.^{[59][60][54][61]}

Because patient care is on the line, the next move needs to be practical. Not abstract. And it doesn't call for a full technology overhaul.

Over the next 6–12 months, organizations can take a few direct steps:

• Consolidate device records
• Clarify ownership
• Form a cross-functional working group
• Use third-party risk management to track remediation

Within 30 days, clinical engineering, cybersecurity, compliance, and procurement leaders should come together to assign one owner and one quarter-specific action for each gap. That move helps shift medical device security from reactive to auditable.

Every device needs an owner, every finding needs closure, and every care team has a role.

FAQs

How do I start fixing these gaps?

Start with clear ownership and full visibility. Use continuous, agentless network discovery to build an accurate inventory of every device. Then attach a machine-readable SBOM to each one so you can track software components and known vulnerabilities without guesswork.

From there, sort advisories based on device risk and patient-care impact, not CVSS scores alone. A high score matters, of course, but in a hospital setting, context matters just as much. A flaw on a bedside device tied to patient care may need attention before an issue on a less critical system.

Route findings through a standard cross-functional workflow so security, IT, clinical engineering, and care teams stay on the same page. While longer-term remediation is in progress, put immediate controls in place, such as:

• Network segmentation
• Role-based access

That way, you reduce exposure right away instead of waiting for the full fix.

Which devices should be prioritized first?

Prioritize connected cyber devices that carry the greatest patient-safety risk, especially infusion pumps, ventilators, and patient monitors.

Then move to other connected assets based on their clinical impact, the chance of exploitation, their level of exposure, and any compensating controls already in place.

Start with an accurate inventory. From there, map device connections and dependencies so you can rank devices for action.

What evidence should be kept for audits?

Keep clear, two-way traceability from each identified threat to its security control, verification test, and residual risk rationale.

The core evidence should include:

• a traceability matrix
• a machine-readable SBOM with VEX data
• test reports, CVD process documentation, architecture diagrams, threat models, risk assessments, and logs for configuration changes, incidents, and updates

Censinet RiskOps™ can help centralize this documentation and map evidence to regulatory benchmarks.

Related Blog Posts

• Study: 162 New Medical Device Vulnerabilities Found
• Best Practices for IoT Device Inventory in Healthcare
• IoMT Firmware Security: Problems and Solutions
• Best Practices for IoT Device Security