Manufacturer Disclosure Statement for Medical Device Security (MDS2)

What MDS2 Does in Medical Device Procurement

MDS2 is not a control in itself, it is a procurement disclosure mechanism. It gives buyers a structured way to compare how a device handles authentication, encryption, logging, patching, and network dependencies before the device enters a hospital environment.

That matters because many healthcare security decisions are made around product constraints, not idealized requirements. A usable disclosure helps procurement, biomedical engineering, clinical IT, and security teams understand what must be enforced outside the device and what the manufacturer already supports.

For a practical overview of how the form fits into the wider medical device security lifecycle, see Medical Device Security Guide.

How MDS2 Supports Risk-Based Device Selection

MDS2 is most valuable when organisations are comparing devices that look similar clinically but differ materially in cyber behaviour. A device that cannot support strong authentication, secure logging, or workable patching windows may still be suitable, but only if the buyer understands the compensating controls required to operate it safely.

The form helps teams separate vendor promises from operational reality. It surfaces whether the device expects open network access, depends on external services, or has limitations that could affect segmentation, monitoring, or incident response.

That is why MDS2 is commonly used alongside broader security and regulatory due diligence, including FDA Medical Device Cybersecurity Guide and EU MDR Cybersecurity and MDCG 2019-16 Guide, when procurement decisions need both technical and compliance context.

What Information Buyers Should Read Closely

The most useful parts of an MDS2 disclosure are the sections that affect deployment design, not marketing claims. Authentication requirements, default account handling, encryption options, log export capability, remote service access, wireless behaviour, and patch dependencies all shape how the device fits into a hospital network.

Buyers should also look for operational caveats, such as whether the device requires special network exceptions, vendor-mediated maintenance, or specific versions of dependent systems. These details often determine whether the organisation can monitor the device, isolate it, or recover from a vulnerability without disrupting care.

When the device depends on clinical network design, a companion review of Hospital Clinical Network Segmentation Guide helps translate the disclosure into practical network zoning and access decisions.

Why MDS2 Matters After Purchase Too

MDS2 should not be treated as a one-time buying checkbox. The disclosure remains useful after deployment because it gives operators a baseline for vulnerability handling, maintenance windows, and post-incident review when the vendor later releases security updates or operational advisories.

It also helps security and engineering teams decide where compensating controls must stay in place for the life of the device. If a device cannot be patched quickly, or if logging is limited, the organisation may need stronger segmentation, tighter remote access rules, or more frequent review of exposed services.

That lifecycle view aligns closely with standards and guidance around security-by-design and post-market support, including IEC 81001-5-1 Health Software Security Lifecycle Guide and AAMI TIR57 and SW96 Medical Device Risk Guide.

Risk and Threat Considerations

MDS2 reduces ambiguity, but it does not reduce risk by itself. If a manufacturer understates limitations, omits dependencies, or provides stale disclosure data, buyers can approve a device that is harder to defend, harder to patch, or more exposed than expected.

Failure mechanism: Weak or incomplete disclosure can leave authentication, logging, update support, and network exposure assumptions untested until the device is already in production.

Impact: That can produce silent exposure across a clinical fleet, slow incident containment, and force hospitals into reactive compensating controls after deployment rather than deliberate design choices.

Practitioner Guidance

What to watch for: Treat MDS2 as an input to risk assessment, not as proof of assurance. The disclosure is most useful when it is reviewed alongside asset inventory, vendor advisories, and the actual network role the device will play.

Governance implication: Procurement, clinical engineering, and security teams should agree who validates the disclosure, who owns follow-up questions, and who signs off when the device needs exceptions or compensating controls. That ownership avoids the common failure mode where everyone assumes another team has checked the details.

Practitioner takeaway: Use MDS2 to force explicit decisions about exposure, supportability, and compensating controls before the device becomes part of patient care.

Related resources from NHI Mgmt Group

• Device Security
• What are common mistakes with Manufacturer Disclosure Statement for Medical Device Security (MDS2)?
• What is a practical example of a Manufacturer Disclosure Statement for Medical Device Security (MDS2)?
• Why does Manufacturer Disclosure Statement for Medical Device Security (MDS2) matter for security teams?