What is a practical example of a Manufacturer Disclosure Statement for Medical Device Security (MDS2)?

What an MDS2 Example Looks Like in Practice

A practical MDS2 example starts with procurement, not incident response. The hospital uses the manufacturer’s disclosure to see whether the device supports the security capabilities it expects before it is connected to clinical networks. The value is comparative: it helps buyers ask consistent questions across vendors and spot where a device will need compensating controls.

That review usually focuses on whether the device supports authentication, logging, patching, encryption, and remote access restrictions. Those answers are not just feature checkboxes. They indicate whether the device can fit the hospital’s baseline architecture, or whether the hospital will need to isolate it, restrict connectivity, or accept a documented exception.

For a connected infusion pump, imaging system, monitor, or similar device, the MDS2 often becomes the bridge between vendor claims and security engineering. A product may be clinically suitable but still require extra network segmentation, stricter admin controls, or compensating monitoring if it lacks strong built-in protections. The disclosure gives the security team a common reference point for that decision.

How Teams Use the Disclosure to Make a Buying Decision

An MDS2 is most useful when it is read alongside the hospital’s own technical requirements, not as a standalone guarantee. Security, biomed, clinical engineering, and procurement teams can use it to compare devices on the same criteria, then determine whether the device meets policy or only partially meets it. That makes the document a practical input to procurement, risk acceptance, and deployment planning.

In practice, the team looks for gaps that affect deployment design. If the device cannot encrypt data in transit, for example, the hospital may compensate with network controls. If it cannot support modern authentication, the team may restrict administrative access or place it behind controlled management channels. If logging is limited, the hospital may require additional network telemetry or stronger compensating oversight.

That is why the disclosure matters before purchase. It can prevent a clinical device from becoming a hidden exception after installation. It also gives the organisation an auditable way to explain why a device was accepted despite weaknesses, which is useful when the product is clinically necessary but not fully aligned to internal security standards.

What Makes a Good MDS2 Review

A good review does not stop at whether the form is completed. Teams should check whether the answers are specific enough to support a real deployment decision, then compare them against the intended use case. If the disclosure is vague, outdated, or silent on important controls, the buyer should treat that as a risk signal rather than assuming the device is secure by default.

This is also where compensating controls become important. A device may be acceptable only if the hospital can enforce segmentation, tightly control remote access, restrict who can administer it, or monitor it more closely than other endpoints. The disclosure helps identify those conditions early, before the device is allowed onto a production network.

In that sense, the MDS2 is a decision aid for residual risk. It does not remove the need for local assessment, but it gives the organisation the facts needed to decide whether the device is secure enough for its environment, what must be added around it, and what should be documented for governance and lifecycle review.

Risk and Threat Considerations

Medical devices often have long lifecycles, limited patch flexibility, and operational constraints that make weak security disclosures material rather than theoretical. If the MDS2 understates those limits, the organisation may connect a device to a production network without realising that its authentication, update, or logging model is too weak for the environment.

Failure mechanism: A gap between the manufacturer’s disclosure and the device’s actual controls can lead to over-trust, weak segmentation decisions, and delayed remediation when the device is deployed.

Impact: The result can be harder detection, greater lateral movement opportunity, and a larger blast radius if the device is abused or compromised.

Practitioner Guidance

What to verify: Treat the MDS2 as evidence to validate, not as proof of safety. Confirm that the disclosed capabilities match the hospital’s required controls for the specific deployment, including administration model, update path, logging visibility, and remote access conditions.

Decision rule: If the device cannot meet a required control directly, decide early whether a compensating control is realistic and enforceable. If not, document the residual risk before purchase rather than discovering the gap after installation.

Practitioner takeaway: The practical value of an MDS2 is not that it says a device is secure, but that it exposes where the hospital must add controls, tighten access, or formally accept residual risk before the device goes live.

Related resources from NHI Mgmt Group

• Guide: Medical Device Security Guide
• What are common mistakes with Manufacturer Disclosure Statement for Medical Device Security (MDS2)?
• Manufacturer Disclosure Statement for Medical Device Security (MDS2)
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?