Medical Device Security Guide

Connected medical devices, the Internet of Medical Things (IoMT), run clinical care on software that is hard to patch, owned by someone else and expected to stay in service for a decade or more. An infusion pump, imaging modality or patient monitor cannot be rebooted for Patch Tuesday, cannot run an endpoint agent the manufacturer has not validated, and may harm a patient if a security control blocks it at the wrong moment. Regulators now treat cybersecurity as part of device safety: in the US through section 524B of the FD&C Act and FDA's premarket guidance, and in the EU through the Medical Devices Regulation and MDCG 2019-16. This guide covers both sides of the problem, what manufacturers must build and disclose and what hospitals and other healthcare delivery organisations (HDOs) must do to buy, run, segment and recover devices. It is written for clinical engineering, security and product security teams. It summarises regulatory requirements and is not legal or regulatory advice.

Key takeaways

• Security is a safety property for devices. FDA's guidance lists secure and timely updatability alongside authenticity, authorisation, availability and confidentiality, and risk is judged by exploitability and patient harm.
• Section 524B made it law in the US. Since 29 March 2023, premarket submissions for cyber devices must include a postmarket vulnerability plan, secure development processes and a software bill of materials (SBOM).
• The MDS2 and SBOM are procurement tools. Ask for them before purchase, check end-of-support dates and network ports, and put patching and support duties in the contract.
• Segmentation is the main control for devices you cannot patch. Put devices, especially legacy ones, on dedicated segments with allow-listed flows, and do not run active scans against equipment in clinical use.
• Plan for clinical downtime, not just IT recovery. Recovery from a major incident can take weeks, systems come back in stages, and devices may need reloading with the manufacturer's help.

Why medical devices are a different security problem

• Change is regulated: a manufacturer that changes software must assess whether the change needs a new submission. FDA lists "changes to authentication or encryption algorithms, new connectivity features" as modifications that may affect cybersecurity. HDOs usually cannot install patches or agents themselves without voiding validation or support.
• Long service life: capital equipment such as CT and MRI scanners outlives the operating systems it ships with, so unsupported Windows and embedded Linux versions are common on hospital networks.
• Availability over confidentiality: a ransomware attack that stops a lab analyser or a picture archiving and communication system (PACS) delays diagnosis and treatment. Controls that lock out a clinician in an emergency are themselves a safety hazard, a point MDCG 2019-16 makes directly.
• Multi-patient harm: a vulnerability in a fleet of identical networked devices, or in the server that programs them, can affect many patients at once. FDA asks manufacturers for a specific Multi-Patient Harm architecture view.
• Shared responsibility: MDCG 2019-16 states that manufacturers, integrators, operators and users "share responsibilities for ensuring a secured environment". In practice the HDO owns the network and the manufacturer owns the software, and gaps open between them.
• Implantables and home devices: pacemakers, insulin pumps and home monitors connect through programmers, phones and cloud services, so fixes may depend on clinic visits or patient action.

Regulations and standards at a glance

FDA defines a cyber device as one that includes software validated, installed or authorised by the sponsor, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. Most networked devices meet that definition.

What manufacturers must build and submit

FDA describes an SPDF as "a set of processes that help identify and reduce the number and severity of vulnerabilities in products" and recommends one integrated with the quality system. IEC 81001-5-1 is the international process standard for the same activities. A premarket submission is expected to show the following.

• Threat model: security objectives, risks and vulnerabilities across the whole device system, including servers, apps, cloud services and update infrastructure, maintained throughout design.
• Cybersecurity risk assessment: based on exploitability rather than the probability estimates used in ISO 14971 safety risk management, with residual risk linked to patient harm.
• Security controls: authentication and authorisation (FDA states "Do not use passwords that are hardcoded, default, easily guessed, or easily compromised"), cryptographically strong authentication of commands and software, anti-replay nonces for critical commands, event detection and logging, resiliency and recovery, and secure updates.
• Testing: penetration testing, fuzz testing, attack surface analysis, vulnerability chaining and software composition analysis, with reports showing tester independence, scope, duration, methods and results.
• SBOM: required for cyber devices and covering commercial, open-source and off-the-shelf components, machine-readable to the NTIA minimum elements, with each component's level of support, end-of-support date and known vulnerabilities.
• Labelling: recommended security controls for the user, a list of network ports and interfaces with function, direction and approved endpoints, cybersecurity end of support, and an MDS2.
• Postmarket plan: sources for vulnerability information, periodic testing, coordinated vulnerability disclosure, and a process for vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue. Most manufacturers run this through a product security incident response team (PSIRT).

Postmarket vulnerability management

FDA's 2016 postmarket guidance sorts vulnerabilities by patient risk. Controlled risk means "sufficiently low (acceptable) residual risk of patient harm"; uncontrolled risk means an unacceptable residual risk. The response differs.

In the EU, MDCG 2019-16 expects manufacturers to gather postmarket information on incidents, vulnerabilities in third-party components and threat changes, and treats serious cybersecurity incidents under the normal vigilance and field safety corrective action process.

What healthcare delivery organisations must do

Procurement

• Request the MDS2 and SBOM for every networked device before purchase, and compare the MDS2 answers (authentication, encryption, audit logging, malware protection, remote service) with your minimum requirements.
• Contract terms: the FDA-sponsored MITRE regional playbook suggests covering SBOM delivery, patching responsibilities, manufacturer participation in exercises, support during recovery and timely notification, and points to the Health Sector Coordinating Council model contract language.
• End of support: get the cybersecurity end-of-support date in writing; it decides how long the device stays on a normal segment.
• Remote service: require brokered, logged, time-limited vendor access instead of always-on VPNs or modems. See the Third-Party Access Guide.

Inventory

The MITRE playbook lists the fields an incident responder needs: device name and description, physical and logical location, owner, maintenance arrangements, operational and patch status, embedded components (SBOM), dependencies on other devices or IT, and diagnostic logs. ASPR TRACIE adds IP and MAC addresses and software details that often sit outside the IT configuration management database. Passive network monitoring tools that understand clinical protocols are the usual way to find what clinical engineering records miss. Reconcile both sources monthly.

Network segmentation

• Dedicated segments: put devices, "especially legacy devices that cannot be easily secured", on their own protected segments, as the MITRE playbook advises, grouped by device type and clinical function.
• No trust with corporate IT: ASPR TRACIE recommends isolating life-safety equipment and eliminating trust relationships between life-safety and corporate networks.
• Allow-list flows: use the manufacturer's port and endpoint list from the labelling. Typical flows include DICOM to PACS (DIMSE commonly on TCP 104 or 11112, DICOM over TLS on 2762), HL7 v2 interfaces (commonly TCP 2575) and vendor update servers. Block internet access unless the manufacturer documents a need.
• Encrypt where supported: the DICOM standard "merely facilitates the use of encryption but does not mandate it", so TLS for DIMSE and HTTPS for DICOMweb have to be switched on deliberately. See the Network Ports and Protocols Security Guide.

Vulnerability management for devices

• No active scanning in clinical use: ASPR TRACIE warns that "vulnerability scans of medical equipment in clinical use may lead to adverse patient outcomes". Use passive detection, manufacturer advisories, SBOM matching and scans only in maintenance windows agreed with clinical engineering.
• Prioritise by exploitability and clinical impact: CISA KEV entries and internet-reachable devices first, then life-sustaining devices and multi-patient systems.
• Apply only validated patches: follow the manufacturer's advisory; where none exists, apply compensating controls and record the risk acceptance.

Legacy devices: deciding what to do

• Small hospitals and clinics: focus on an accurate inventory, removing internet exposure, a handful of segments (imaging, monitoring, lab, other devices) and a vendor access process. Use manufacturer and ISAO advisories instead of building a device lab.
• Large health systems: need a joint clinical engineering and security function, passive monitoring across sites, contract standards enforced in procurement, a device risk register reviewed by clinical leadership, and regional incident exercises.

Clinical downtime and recovery

Clinical downtime is the period when clinical systems or devices are unavailable or cannot be trusted and care continues on manual procedures. Clinical downtime recovery is the staged, verified return of those systems to clinical use, including reconciling what was recorded on paper. ASPR TRACIE tells facilities to "Define downtime for the organization and what this will activate internally" and to "Err on the side of enacting longer downtime procedures".

• Prepare: downtime forms, printed and offline copies of plans, read-back procedures for verbal orders, and supplies. ASPR TRACIE suggests that for large organisations short-term may mean three days or fewer.
• Know the device dependencies: which devices stop working when the EHR, PACS, directory or network fails, and which keep running standalone.
• Separate eradication from restoration: ASPR TRACIE stresses that removing the attacker and restoring services are different steps, and that "Systems will NOT be restored at once".
• Restore devices with the manufacturer: recovery may involve reloading or patching software on capital medical equipment. The MITRE playbook advises HDOs to "first reach out to the manufacturer and then to the broader healthcare community", and to plan for recovery of "weeks or even months".
• Reconcile records: plan the migration of manual documentation back into electronic systems once they are restored.

Ransomware (ATT&CK T1486, Data Encrypted for Impact) against hospital IT is the usual cause of extended downtime, even when no device is directly attacked.

Rolling out a medical device security programme

1. Set governance: name an owner jointly accountable across clinical engineering (healthcare technology management) and security, and agree who may touch device configuration.
2. Build the inventory: start with passive discovery on two or three clinical networks, reconcile with the clinical engineering asset system, and add MDS2 and SBOM data.
3. Remove internet exposure and default credentials: the fastest risk reduction, done with the manufacturer where devices need it.
4. Segment in monitor mode first: log flows for several weeks, build allow-lists from observed traffic and manufacturer port lists, then enforce on one device group in one site as a pilot. Keep the previous rule set so rollback is a single change, and have clinical engineering on hand during cut-over.
5. Extend by device group and site, prioritising multi-patient systems and life-sustaining devices.
6. Embed in procurement: security review and contract terms before purchase orders are raised.
7. Exercise downtime: run a tabletop and a live downtime drill with clinical departments at least yearly.

Detection and measurement

• Monitor: new devices appearing on clinical segments; flows outside the allow-list; device connections to the internet; remote service sessions; configuration changes and login attempts on devices and their management servers (event types FDA asks manufacturers to log); manufacturer advisories and CISA medical advisories matched to the inventory.
• Watch the management plane: device management servers, programmers and vendor jump hosts are higher value than individual devices.

Metrics that show the programme is working:

• Percentage of networked devices in the inventory with owner, location, OS and end-of-support date.
• Percentage of devices on enforced, allow-listed segments.
• Number of devices past end of support, with a compensating control or replacement date.
• Median days from manufacturer advisory to patch or compensating control.
• Percentage of new device purchases with MDS2 and SBOM reviewed before contract.
• Time to restore priority clinical systems in the last downtime exercise.

Common failure patterns

• Remote access without strong authentication: exposed remote access is a common entry point into healthcare (ATT&CK T1133, External Remote Services). The Change Healthcare Breach 2024 began with one Citrix login without MFA and disrupted claims and prescriptions across the US.
• Flat networks: devices share VLANs with workstations, so ransomware that starts with phishing or a public-facing exploit (T1190) reaches modalities and their servers.
• Inventory owned by nobody: clinical engineering tracks assets, IT tracks IP addresses, and neither knows which device runs which OS.
• Shared and default vendor accounts: the same service password across a fleet turns one leak into fleet-wide access (T1078, Valid Accounts).
• Scanning like corporate IT: aggressive active scans that crash or reset devices in use, which then lead to scanning being banned altogether.
• Ignoring the manufacturer's own IT: a device maker's corporate systems are part of the supply chain. In the Stryker Cyberattack 2026, one hijacked admin account used Microsoft Intune to wipe tens of thousands of the company's devices; ask suppliers how they would support you during their own incident.

Framework mapping

Where identity fits

Devices authenticate to PACS, EHR interfaces, update servers and cloud services with service accounts, certificates and API keys, and vendors reach them with support accounts. These non-human identities need owners, unique credentials per device or fleet, rotation and removal at decommissioning. Clinician access, EPCS and break-glass design are covered in the Healthcare Identity Security Guide; device credentials and certificates in the Device and IoT Identity Guide.

Practitioner checklist

• Maintain one reconciled device inventory with owner, location, OS, SBOM and end-of-support date.
• Require MDS2, SBOM, port lists and patching terms before any networked device purchase.
• Remove internet exposure and default or shared credentials from every device you can.
• Segment devices by type, allow-list flows, and isolate life-safety equipment from corporate IT.
• Use passive monitoring and manufacturer advisories; scan devices only in agreed maintenance windows.
• Broker, log and time-limit all vendor remote access.
• Keep a register of legacy devices with compensating controls and replacement dates.
• Define clinical downtime, keep offline procedures, and exercise them with clinical teams yearly.
• For manufacturers: run an SPDF aligned to IEC 81001-5-1, a CVD process and a PSIRT that meets the 524B plan.

Standards and references

• FDA: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• FDA: Postmarket Management of Cybersecurity in Medical Devices
• European Commission MDCG: MDCG 2019-16 Rev.1 Guidance on Cybersecurity for Medical Devices
• IEC: IEC 81001-5-1 Health software and health IT systems safety, effectiveness and security, Part 5-1
• ANSI/NEMA: HN 1-2019 Manufacturer Disclosure Statement for Medical Device Security (MDS2)
• MITRE: Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook
• ASPR TRACIE: Healthcare System Cybersecurity Readiness and Response Considerations
• DICOM Standards Committee: Security and DICOM

Related NHI Mgmt Group resources: Healthcare Identity Security Guide · Device and IoT Identity Guide · OT and ICS Identity and Access Guide · Ransomware Prevention Guide · Third-Party Access Guide. This guide summarises medical device cybersecurity requirements and is not legal advice.