The Expanding Attack Surface at the Bedside
The average mid-sized hospital now has more than 10,000 connected medical devices on its network—infusion pumps, patient monitors, MRI systems, ventilators, and an ever-growing fleet of Internet of Medical Things (IoMT) endpoints. Each one represents a potential entry point for threat actors and a compliance liability under the HIPAA Security Rule. Yet most health systems still lack comprehensive visibility into what devices are on their networks, what software versions they're running, and what vulnerabilities they carry.
The stakes are not abstract. In 2020, CISA issued emergency advisories for critical vulnerabilities in devices from major manufacturers including GE, Baxter, and BD. Ransomware attacks have forced hospitals to divert ambulances and delay surgeries. The FDA's 2023 Refuse to Accept (RTA) policy now requires premarket cybersecurity documentation for new device submissions, signaling that regulators view this as a patient safety issue—not just an IT problem. For CISOs and clinical engineering leaders, the mandate is clear: build a mature, risk-based medical device security program now.
Understanding the Regulatory and Standards Landscape
FDA Premarket and Postmarket Guidance
The FDA's guidance on "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (updated 2023) establishes expectations for manufacturers to deliver a Software Bill of Materials (SBOM), a threat model, and a plan for addressing vulnerabilities throughout the device lifecycle. For health delivery organizations (HDOs), this means you should be demanding SBOMs from every vendor and incorporating cybersecurity requirements into procurement contracts.
NIST Cybersecurity Framework and SP 800-82
The NIST Cybersecurity Framework (CSF) 2.0 provides the backbone for most healthcare security programs. Its five core functions—Identify, Protect, Detect, Respond, and Recover—map directly to the medical device risk management lifecycle. Additionally, NIST SP 800-82 (Guide to Operational Technology Security) offers specific controls for environments where IT and operational technology converge, which is precisely the reality on a modern clinical floor.
HIPAA and HITRUST
Under the HIPAA Security Rule, covered entities must implement technical safeguards for all ePHI-touching systems, including medical devices. The HITRUST CSF r11 maps these obligations into assessable controls and explicitly addresses IoMT environments. If your organization is pursuing HITRUST certification, connected medical devices must be in scope or you're leaving a significant gap in your risk posture.
Building a Defensible Medical Device Security Program
1. Establish Complete Asset Visibility
You cannot protect what you cannot see. Deploy passive network monitoring tools purpose-built for clinical environments—solutions like Claroty Medigate, Armis, or Ordr that can identify device type, manufacturer, firmware version, communication patterns, and known vulnerabilities without disrupting clinical workflows. This asset inventory should feed directly into your CMDB and risk register, creating a single source of truth shared between IT security and clinical engineering.
2. Conduct Risk Assessments Using MDS2 and Threat Modeling
Request the Manufacturer Disclosure Statement for Medical Device Security (MDS2) from every vendor. Use this data alongside your vulnerability scan results to perform risk assessments aligned with NIST SP 800-30. Prioritize devices based on clinical criticality, data sensitivity, network exposure, and exploitability. A compromised infusion pump in the ICU carries a fundamentally different risk profile than a smart refrigerator in the pharmacy—your program should reflect that distinction.
3. Implement Network Segmentation
Flat networks are the single greatest amplifier of medical device risk. Implement microsegmentation to isolate device classes into dedicated VLANs with strict access control lists. Apply zero-trust principles: medical devices should communicate only with their necessary clinical systems and management servers. Document these segmentation policies and test them regularly through penetration testing and tabletop exercises.
4. Formalize Vendor Risk Management and Procurement Requirements
Cybersecurity must become a non-negotiable criterion in medical device procurement. Require SBOMs, patching commitments, end-of-life timelines, and incident notification obligations in every contract. Establish a security review process that involves both clinical engineering and the information security team before any new device connects to your network. The Health Industry Cybersecurity Practices (HICP) publication from HHS 405(d) provides a practical template for these conversations.
5. Plan for Legacy and End-of-Life Devices
The uncomfortable truth is that many critical medical devices run outdated operating systems—Windows XP, embedded Linux distributions that haven't seen a patch in years—and cannot be upgraded without FDA re-certification. For these devices, implement compensating controls: network isolation, application whitelisting where possible, enhanced monitoring, and documented risk acceptance signed by appropriate clinical and executive stakeholders. Track end-of-life dates proactively and budget for replacements years in advance.
Governance: Making It Sustainable
A medical device security program cannot live exclusively in the CISO's office. Establish a cross-functional governance committee that includes clinical engineering, biomedical technicians, nursing informatics, IT operations, procurement, legal, and risk management. This committee should own the device security policy, review risk acceptance decisions quarterly, and report to the board on program maturity using metrics aligned to the NIST CSF or HITRUST maturity model.
Document everything. When OCR comes knocking—or when a device is compromised—your ability to demonstrate a reasonable, standards-aligned, and continuously improving program is your strongest defense. The goal is not perfection; it's defensibility, transparency, and a relentless commitment to reducing risk to patients.
The Path Forward
Medical device cybersecurity is no longer a niche concern relegated to biomedical engineering. It is a board-level patient safety issue, a regulatory compliance imperative, and an operational resilience priority. Health systems that invest in visibility, segmentation, governance, and vendor accountability today will be far better positioned to weather the threat landscape of tomorrow. The connected care environment is here to stay—our security programs must evolve to match.