Cybersecurity Due Diligence for Connected Medical Devices

A procurement-stage playbook for CIOs, CMIOs, and biomedical engineering teams operating under FDA Section 524B and the 2025 final guidance

Why this matters (specific scenarios)

Connected medical devices have become both the largest and least-governed slice of the hospital attack surface. IBM estimates that U.S. hospitals house between 10 to 15 million medical devices, averaging 10–15 connected devices per patient bed. The exposure that this creates is no longer hypothetical:

Ascension, May 2024. Ascension Health suffered a ransomware attack that caused severe disruptions across its network, affecting claims submission, payment processing, and overall revenue cycle operations. Facility volumes dropped by 8%-12% in May and June 2024 compared to the previous year.

It's estimated this will cost Ascension anywhere from $1.1 billion to $1.6 billion.

The downtime tax. The average day of downtime cost healthcare organizations $1.9 million, with recovery times ranging from minimal disruption to several months. Organizations experienced an average of more than 17 days of downtime per attack , and for the 14th year in a row, healthcare tops the list with the most expensive breach recoveries, coming in at USD 9.77 million on average.
The vulnerability baseline you inherit at signing. Per Claroty's 2023 State of CPS Security Report, 14% of medical devices in U.S. hospitals run an unsupported or end-of-life operating system while actively connected to clinical networks, and 53% of networked devices carry at least one known critical vulnerability.

The structural problem is well-understood and worth restating to the finance committee: devices are designed to last 15 to 20 years. Vendors support the underlying software for three to five. Hospitals use them for everything in between. The result: clinical equipment running unsupported OS versions, firmware that hasn't received a security update in years, and legacy communication protocols originally designed for air-gapped environments now sitting on connected clinical networks. Procurement is the only stage where you can price that gap into the contract.

The decisions that shape the outcome

1. Confirm the device meets FDA Section 524B obligations as a "cyber device"

Since March 29, 2023 , FDA can refuse to accept (RTA) submissions that don't include cybersecurity documentation. On June 27, 2025, the FDA released its final guidance on "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," building on the foundations set by the guidance and select updates issued in 2023 and 2024. Crucially, FDA considers a cyber device to be a device that contains software or is itself software. This removes ambiguity from the interpretation of manufacturers who previously would have provided a justification for why their software device did not fall under the criteria of "cyber device"; if a device contains software, the guidance applies, whether or not it is network-enabled.

For any device cleared after March 2023, ask procurement legal to verify the 510(k) summary references the cybersecurity premarket documentation. The cybersecurity risk report should include (or reference) the threat model, cybersecurity risk assessment, the software bill of materials (SBOM), component support information, vulnerability assessments, and unresolved anomaly assessments.

2. Demand the SBOM — and read it

New FDCA section 524B(b)(3) requires SBOMs in marketing applications for cyber devices, including 510(k)s, PMAs, and Humanitarian Device Exemptions. The SBOM should be in established standards, with the FDA expressing support for formats like SWID tags and SPDX. What you're looking for in the SBOM:

Component support windows, not just versions. A library that's three patches behind matters less than a library whose maintainer dropped support last quarter.
Transitive dependencies. The transparency created by SBOM requirements extends throughout the software supply chain. Manufacturers must understand not just direct dependencies but transitive dependencies—the components used by the libraries they incorporate.
Update cadence vs. CISA KEV. FDA recommends that the [CISA KEV] vulnerability database be incorporated into the Cybersecurity Management Plan to reflect more extensive ongoing vulnerability monitoring.

3. Insist on a current MDS2 — and treat it as an interview, not a checkbox

The Manufacturer Disclosure Statement for Medical Device Security is your standardized intake form. Each MDS2 form contains approximately 240 questions organized into 23 distinct security control groups. A few procurement-side mechanics:

Reject 2008/2013-era forms. Several MDS2 forms received from MDMs are created using outdated or old forms from 2008 and 2013. If you are using an IoMT solution and this data is being used, make sure your MDS2 documents are current as this can affect your risk analysis.
Match SKUs and firmware. The MDS2 form is meant to provide a way of reporting the technical, model-specific elements of information needed by an HDO to begin medical device security risk assessments. Note: There may be variations based on SKUs, operating system and software version installed.
Don't stop at the public-facing copy. Many vendors have 2 versions of many forms. One, with little or no proprietary information is shared for sales and marketing. The second version is usually obtained during purchasing process and obtained after signing an NDA. These forms will have far more information, mostly proprietary.

4. Negotiate the EOL/EOS clauses in writing

IMDRF defines a legacy medical device as one "that cannot be reasonably protected against current cybersecurity threats." Procurement is where you fight to delay that designation:

Require the vendor to state EOL and EOS dates for the device and each major software component (OS, web stack, cryptographic libraries).
Bake patch SLAs into the master agreement: discovery-to-patch windows for critical CVEs, a coordinated vulnerability disclosure (CVD) program, and ISAO/Health-ISAC participation.

Suppliers should ensure the security of all procured or developed systems and technologies, including all subcomponents, throughout the useful life including any extension, warranty, or maintenance periods. This includes, but is not limited to, workarounds, patches, hotfixes, upgrades, and any physical components which may be necessary to fix all security vulnerabilities published or known to the Supplier anywhere in the Systems, including Operating Systems and firmware. The Supplier should ensure that Security Fixes do not negatively impact the Systems.

5. Validate against recognized consensus standards

Manufacturers historically blended ISO 14971 (for safety risk) and AAMI TIR 57 (for security risk).

ANSI AAMI SW96 has been a recognized consensus standard for the last two years, but industry adoption has been arguably slow. Asking how the manufacturer maps controls to SW96, IEC 62304 (software lifecycle), and IEC 81001-5-1 (health-software security lifecycle) separates mature programs from marketing decks.

6. Specify network architecture before the PO is cut

Capture default ports, required outbound destinations, certificate management approach, authentication mechanisms (multi-factor where supported), and whether the device can function on a segmented VLAN with no internet egress. If the vendor needs internet for "remote support," confirm whether it's site-to-site VPN, a vendor-managed jump host, or a SaaS tunnel — each has different liability implications under your BAA.

Common mistakes

Treating the MDS2 as a marketing artifact. A signed MDS2 with "N/A" in 40 cells is not due diligence; it's a future incident report.
Letting clinical leadership negotiate the patch SLA. Patch latency is a CISO/biomed conversation. Clinical engineering teams often accept 90-day windows that legal and security would have refused.
Buying through GPO without device-specific terms. GPO master terms rarely contemplate SBOMs or KEV-driven patching.
Ignoring decommissioning at procurement. Improper device retirement: too often, equipment leaves service with PHI, clinical trial data, or even user or Wi-Fi credentials still stored locally. These artifacts can surface later in secondary markets, exposing sensitive data long after the device's "official" life is over. Effective decommissioning should include data purging, credential resets, verification that no sensitive information can be recovered, and documentation of these activities.
Underestimating the ransomware vector. The most common attack vectors in healthcare ransomware attacks were exploited vulnerabilities (34%) and compromised credentials (34%) — the two categories most directly addressed by SBOM hygiene and authentication controls on devices.
Not budgeting for backup compromise. In 95% of healthcare ransomware attacks in the past year, backups were targeted. In 66% of ransomware attacks on healthcare organizations, backups were compromised.

A practical pre-procurement workflow

Pre-RFP. Add cybersecurity requirements (SBOM, current MDS2, IEC 81001-5-1 conformance, EOL/EOS commitments) to the technical specification.
RFP response review. Cross-reference vendor MDS2 against your network policies (e.g., 802.1X support, TLS minimums, local admin behavior). Score the 23 MDS2 control groups; flag any "no" answer in encryption, authentication, or audit logging for written justification.
SBOM ingestion. Run components against CISA KEV and NVD. Note any component within 12 months of EOS.
Threat model walkthrough. Request a redacted threat model. The 2023 Final Guidance reinforces the non-probabilistic nature of assessing cybersecurity risk (i.e., no likelihood or probability in calculating cybersecurity risk) and points instead to exploitability as the opportunistic measure that should be used.
Penetration test artifacts. Request the most recent third-party pen test summary under NDA.
Contract language. Patch SLAs, vulnerability notification windows (recommend ≤72 hours from CVE publication for KEV items), liability for downtime caused by unpatched vulnerabilities, decommissioning obligations, right to audit.
Network design sign-off. Biomed and network security agree on VLAN, firewall rules, and monitoring before installation.
Acceptance testing. Verify firmware version matches the MDS2; capture a baseline of normal traffic patterns.
Asset registration. Add to CMDB with EOL date, support contact, and CVD email.

Edge cases worth flagging

Pre-2023 inventory. Devices cleared before Section 524B aren't required to have an SBOM. FDA may approve the continued use of legacy medical devices based on hardware safety, even if the software is no longer secure. This leads to situations where devices meet clinical safety standards but fall short of HIPAA requirements. Build a remediation backlog.
High-cost imaging and radiotherapy. Cost is another major factor, with some replacements reaching $1 million to $2 million per unit. Compensating controls (segmentation, virtual patching, passive monitoring) are not optional — they're the depreciation strategy.
AI/ML-enabled devices. Confirm whether models are updated via the device's normal patch path or a separate cloud channel; the latter expands your supply-chain attack surface.
Combination products and SaMD. The 2023/2025 guidance updates expanded scope to CBER submission types, considerations for combination products, and elements required under Section 524B of the FD&C Act.
"Related systems" interpretation. FDA interprets "related systems" to encompass, "among other things," a seemingly broad range of "manufacturer-controlled elements" such as "healthcare facility networks." Vendor responsibility may extend further than their EULA suggests; preserve that leverage in contract language.
Decommissioned but still in clinical service. Stage 3 or the Limited Support phase begins when the manufacturer declares end of life (EOL) for the product and no longer markets or sells it. During this phase, the HCP may continue to operate the device, and the device can be reasonably protected against current cybersecurity threats. When devices fall into the End of Support phase or Stage 4, they can no longer be reasonably protected. Track Stage 3→4 transitions explicitly.

Sources

FDA, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (final guidance, June 27, 2025; supersedes September 2023 final guidance). fda.gov/medical-devices/digital-health-center-excellence/cybersecurity
FD&C Act Section 524B (Consolidated Appropriations Act, 2023, Section 3305), effective March 29, 2023.
IMDRF N70, "Principles and Practices for the Cybersecurity of Legacy Medical Devices" (May 2022).
NEMA/MITA HN 1-2019, Manufacturer Disclosure Statement for Medical Device Security (MDS2).
ANSI/AAMI SW96:2023, Standard for medical device security.
ISO 14971 (risk management) and AAMI TIR 57 (principles for medical device security risk management).
CISA Known Exploited Vulnerabilities (KEV) Catalog.
Claroty, 2023 State of CPS Security Report (legacy OS prevalence, critical vulnerability rates).
Sophos, "State of Ransomware in Healthcare 2024" (att