Manufacturer Disclosure Statement for Medical Device Security (MDS2)

Expanded Definition

Manufacturer Disclosure Statement for Medical Device Security, or MDS2, is a structured disclosure that helps healthcare organisations understand a medical device’s built-in security properties and operational dependencies before deployment. It is not a control framework, and it does not certify that a device is secure. Instead, it supports due diligence by making manufacturer claims about authentication, encryption, audit logging, patching, default accounts, remote access, and network behaviour easier to compare across devices.

In practice, MDS2 is most useful during procurement, clinical engineering review, security architecture planning, and lifecycle risk assessment. The document helps teams translate vendor statements into compensating controls, especially where a device cannot support standard enterprise security tooling. Guidance varies across vendors and product categories, so an MDS2 should be treated as a disclosure artifact, not a guarantee of operational safety. For control selection, teams often map the disclosed capabilities to NIST SP 800-53 Rev 5 Security and Privacy Controls rather than assuming the device can meet every baseline requirement.

The most common misapplication is treating a completed MDS2 as proof of compliance, which occurs when procurement teams accept the form without validating whether the actual deployed configuration matches the disclosure.

Examples and Use Cases

Implementing MDS2 rigorously often introduces procurement overhead, requiring organisations to balance faster purchasing decisions against the cost of deeper technical review and control design.

• A hospital evaluates a networked infusion pump and uses the MDS2 to confirm whether the device supports unique user authentication, encrypted traffic, and security logging before placing it on the clinical network.
• A biomedical engineering team reviews an imaging system’s disclosure to determine whether default passwords must be changed manually and whether patching requires vendor service windows.
• A security architect uses the MDS2 to identify devices that cannot be segmented with standard endpoint tools and then defines compensating network isolation, monitoring, and access restrictions.
• A procurement group compares two devices with similar clinical functionality but different disclosure detail, then asks follow-up questions where the MDS2 leaves ambiguity around remote administration and update cadence.
• A risk team checks whether the manufacturer’s statements align with documented maintenance practices, then records residual risk where the device depends on unsupported operating systems or restricted logging features.

Used well, MDS2 supports evidence-based purchasing rather than assumption-based buying. It also helps organisations understand where vendor documentation must be paired with independent verification, configuration hardening, and ongoing asset governance.

Why It Matters for Security Teams

MDS2 matters because medical devices often operate for long periods, support clinical workflows that cannot tolerate disruption, and expose security constraints that are hard to infer from product marketing alone. Without a reliable disclosure, security teams may overestimate patchability, assume encryption is always available, or miss hidden dependencies such as vendor-managed remote access and static credentials. That creates avoidable exposure in environments where devices may connect to patient data systems, identity services, and broader hospital networks.

For security governance, the value of MDS2 is that it gives teams a common language for comparing device constraints against enterprise policy, network segmentation, and control families in NIST SP 800-53 Rev 5 Security and Privacy Controls. It is especially relevant when organisations need to determine whether a device can support least privilege, logging, or secure maintenance without introducing clinical risk. The disclosure also helps procurement and security teams spot where compensating controls, isolation, or contractual commitments are required before the device enters service.

Organisations typically encounter the real importance of MDS2 only after an audit finding, an exposed device, or a failed security review, at which point the disclosure becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when medical device security is only checked after release?
• Medical Device Lifecycle Security
• How should security teams govern device-bound payment credentials in open finance?
• How should security teams handle authentication when device trust may be compromised?