Why Pre-Purchase Security Assessment Is Non-Negotiable
The average health system now manages between 10,000 and 15,000 connected medical devices, and that number is accelerating. Each device represents a potential attack surface—an infusion pump that communicates patient data over the network, an MRI system with an embedded Windows operating system that may never receive a patch, or a bedside monitor transmitting ePHI to the EHR. The time to understand a device's security posture is before the purchase order is signed, not after it's deployed on the clinical network. Yet too many organizations treat medical device cybersecurity as an afterthought, discovering critical vulnerabilities only during post-deployment vulnerability scanning or, worse, after an incident.
The Manufacturer Disclosure Statement for Medical Device Security—commonly known as the MDS2 form—was developed jointly by ACCE (now AAMI), ECRI, HIMSS, and NEMA specifically to address this gap. Updated most recently in 2019, the MDS2 provides a standardized framework for manufacturers to disclose the security-relevant characteristics of their devices. For CISOs and clinical engineering leaders, it is the single most important pre-procurement security document you should be demanding from every vendor.
Anatomy of the MDS2: What You're Actually Evaluating
The MDS2 form is organized into 23 sections covering a comprehensive range of security capabilities and characteristics. Key areas include whether the device maintains, transmits, or stores ePHI; its authentication mechanisms; data encryption capabilities (at rest and in transit); audit logging; malware protection; software update and patching processes; network connectivity requirements; and data backup and disaster recovery features. Each section maps directly to obligations under the HIPAA Security Rule's administrative, physical, and technical safeguards (45 CFR §§ 164.308–164.312).
Critically, the MDS2 is a disclosure document, not a certification. A manufacturer is telling you what the device can and cannot do—it is your responsibility to assess whether those capabilities meet your organization's risk tolerance and regulatory obligations. This distinction is essential: the MDS2 does not guarantee security. It gives you the raw material to make an informed risk decision.
Mapping MDS2 Responses to Your Risk Framework
To extract maximum value from an MDS2, you need to map its disclosures against a structured risk framework. Organizations using NIST CSF should evaluate MDS2 responses against the Identify (asset management, risk assessment), Protect (access control, data security, maintenance), and Detect (continuous monitoring, logging) functions. If your program is built on HITRUST CSF, cross-reference MDS2 disclosures against relevant control domains such as Access Control (01), Communications and Operations Management (09), and Information Systems Acquisition, Development, and Maintenance (10). For organizations employing FAIR (Factor Analysis of Information Risk), MDS2 data directly informs threat capability and vulnerability assessments by quantifying the loss event frequency factors associated with a device's security gaps.
Building a Rigorous Pre-Purchase Evaluation Process
Simply collecting MDS2 forms is insufficient. Leading health systems embed MDS2 review into a formal, repeatable procurement workflow. Here is a practitioner-level framework:
1. Mandate MDS2 submission as a procurement prerequisite. Work with supply chain and clinical engineering to ensure that no connected medical device purchase proceeds without a completed, current MDS2. Make this a contractual requirement in your RFP templates. If a vendor refuses or cannot provide one, treat that as a material risk finding.
2. Establish a multidisciplinary review team. MDS2 evaluation should not live solely in IT security. Assemble a review team that includes clinical engineering (biomedical), information security, network operations, privacy/compliance, and clinical stakeholders. Each brings a distinct lens: clinical engineering understands device function and FDA classification; information security evaluates technical controls; privacy assesses ePHI handling against HIPAA requirements.
3. Score against a weighted rubric. Develop an internal scoring rubric aligned with your risk appetite. Assign higher weights to critical controls—encryption of ePHI in transit (aligning with CIS Control 3: Data Protection), support for centralized authentication such as Active Directory integration (CIS Control 5: Account Management), and the vendor's documented patching cadence (CIS Control 7: Continuous Vulnerability Management). A device that cannot support encryption or receives patches only annually presents a fundamentally different risk profile than one with robust, automated update mechanisms.
4. Identify compensating controls for gaps. No device will score perfectly. When the MDS2 reveals a gap—for example, a legacy operating system that cannot be patched—document the compensating controls you will deploy: network segmentation, intrusion detection, enhanced monitoring. These compensating controls should be costed and factored into the total cost of ownership presented to procurement decision-makers.
5. Retain MDS2 documentation for compliance and audit. Under the HIPAA Security Rule, covered entities must conduct risk assessments that account for all systems handling ePHI (§ 164.308(a)(1)). Archived MDS2 forms, along with your scored evaluations and compensating control documentation, serve as auditable evidence that you performed due diligence. This documentation is invaluable during OCR audits and HITRUST assessments.
Beyond the Form: Supplementing MDS2 with Deeper Diligence
While the MDS2 is foundational, it has limitations. It is self-reported by the manufacturer and may not capture emerging vulnerabilities or real-world configuration risks. Supplement your MDS2 review with additional diligence: request a Software Bill of Materials (SBOM) to identify third-party components and known CVEs; ask for the manufacturer's vulnerability disclosure policy and coordinated disclosure track record; review FDA premarket cybersecurity submissions (per the FDA's 2023 Refuse to Accept guidance under Section 524B of the FD&C Act); and, where feasible, conduct or commission independent penetration testing of the device in a lab environment before production deployment.
The 2023 FDA mandate requiring cybersecurity documentation in premarket submissions represents a watershed moment, but it applies only to new device submissions. For the vast installed base of legacy devices already on your network, the MDS2 remains your primary vendor-provided security intelligence tool.
Strategic Imperative: Shifting Left on Medical Device Security
Every CISO knows that the cheapest, most effective place to mitigate risk is before deployment—not after. The MDS2 questionnaire, when embedded into a disciplined procurement process and evaluated against established frameworks like NIST CSF, HITRUST, and CIS Controls, transforms medical device purchasing from a clinical-only decision into a risk-informed organizational decision. The goal is not to block procurement but to ensure that every connected device entering your environment arrives with a clear-eyed understanding of its security posture, the compensating controls required, and the residual risk your organization is consciously accepting. That is defensible cybersecurity governance.