Why does Manufacturer Disclosure Statement for Medical Device Security (MDS2) matter for security teams?

Why MDS2 matters before a device enters clinical use

MDS2 matters because it turns a vendor security conversation into a comparable, procurement-ready artifact. For security teams, the value is not the form itself, but the ability to test whether the device’s stated controls line up with how it will actually sit on a hospital network, handle updates, authenticate users or systems, and produce logs that support investigation.

It is most useful when it is treated as an input to risk decisions, not as proof that the device is secure. The disclosure helps teams separate security claims that are explicit from assumptions that still need validation through testing, configuration review, segmentation design and compensating controls.

For broader device context, the Medical Device Security Guide covers the surrounding controls that usually determine whether an MDS2 response is actionable in practice.

What security teams should verify against the disclosure

The practical value of MDS2 is in the gaps it exposes between what a device claims and what the environment requires. Security teams should use it to check whether the device supports strong authentication, what audit or event logging exists, whether remote access or update channels are protected, and whether the product introduces unexpected network exposure such as open services, hard-coded management paths or third-party dependencies.

That review should also ask what the disclosure does not say. Missing detail around patching, account management, encryption, segmentation assumptions or administrative access is often the point where additional due diligence is needed. In many cases, the right question is not “does the device have a control?” but “can our deployment enforce the control consistently across production use, servicing and downtime recovery?”

Where identity and access decisions matter, teams often pair the disclosure review with guidance from the Healthcare Identity Security Guide because device risk often becomes visible only when clinician access, shared workstations or third-party support paths are considered together.

For device trust and onboarding detail, the Device and IoT Identity Guide is useful when the MDS2 response touches certificates, default credentials or device authentication expectations.

How MDS2 fits procurement, segmentation and compensating controls

MDS2 is strongest when it is used early in procurement and again during deployment review. It helps teams decide whether a device can be placed on a segmented network, whether administrative functions need separate access paths, and whether compensating controls are required because the product cannot meet internal baseline requirements. For example, a device with weak logging or long-lived remote access assumptions may still be usable, but only if monitoring, network restriction and vendor support processes are designed around that limitation.

The disclosure is also a useful baseline for legacy or internet-reachable equipment, where the operational question is often whether the device can be hardened enough to fit the environment. That is why teams sometimes evaluate related edge-device guidance alongside MDS2 when the product behaves more like an appliance than a traditional endpoint.

The Edge Device Security Guide is relevant when the main concern is management exposure, logging quality or lifecycle handling for network-connected equipment.

Risk and Threat Considerations

MDS2 reduces information asymmetry, but it does not remove device risk. A disclosure can be accurate and still leave a dangerous deployment if the environment trusts vendor claims too much, accepts weak administrative protections, or allows a medical device to inherit broader network access than it needs.

Failure mechanism: Security teams over-rely on the disclosure, then deploy the device without validating authentication paths, update support, logging depth or exposed services in the actual clinical network.

Impact: That gap can leave a medical device easier to misuse, harder to monitor during an incident, and more difficult to contain if compromise or misconfiguration occurs.

Practitioner Guidance

What to verify: Confirm that the MDS2 answers are mapped to the real deployment model, not just the vendor brochure version of the product. If the device will be remotely serviced, shared across users, or connected to a broader clinical platform, treat those as separate validation points rather than assuming the disclosure covers them.

Decision rule: If the device cannot clearly support the authentication, logging or update expectations in your baseline, use MDS2 to justify compensating controls or procurement exceptions rather than assuming the risk is acceptable.

What good looks like: The best outcome is a disclosure that supports a clear deployment decision, with no ambiguity about who administers the device, how access is controlled, how updates are handled, and what evidence will be available if the device must be investigated later.

Practitioner takeaway: MDS2 is valuable when it changes the procurement and deployment decision, not when it simply documents vendor assurances.

Related resources from NHI Mgmt Group

• 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)?
• Manufacturer Disclosure Statement for Medical Device Security (MDS2)
• Why does Medical Device Cybersecurity matter for security teams?