The Role of MDS² in Medical Device Cybersecurity

Reviewed September 17, 2026

A poorly completed MDS2 form can stall a hospital purchasing decision for months or trigger a security exception review that manufacturers never see coming. Hospital value analysis committees increasingly require the form before they will even evaluate a device, and many manufacturers treat it as an afterthought filled out by whoever is available. That approach creates inconsistent answers across a product line, contradicts other regulatory submissions, and signals to buyers that security was not built into the product. Understanding what the form actually asks, who inside an organization should own it, and how it fits alongside SBOM and the FDA's current premarket guidance turns the MDS2 from a procurement hurdle into a credible sales asset. This guide walks through the form section by section, flags the mistakes reviewers see most often, and clarifies where the MDS2 stops and other documentation must start.

Why This Matters

Hospitals cannot inspect source code or run their own penetration tests on every device before purchase, so they rely on manufacturer disclosures to gauge risk. The MDS2 form is the closest thing the industry has to a common language for that disclosure, and its consistent, accurate use directly affects patient safety decisions. A device with unpatched authentication weaknesses that goes undisclosed can end up on a clinical network without the compensating controls a hospital would otherwise put in place.

Manufacturers also have a commercial stake. Many health systems now require a completed MDS2 as a gating document in their procurement workflow, meaning an incomplete or inconsistent form can delay or block a sale entirely. Cybersecurity and clinical engineering teams cross-reference MDS2 answers against network segmentation plans, vulnerability management contracts, and incident response expectations.

Finally, the form intersects with regulatory expectations. While the MDS2 itself is not an FDA-mandated document, its content overlaps with disclosures manufacturers must also make in premarket submissions and labeling under the FDA's current guidance. Treating the MDS2 as a one-time checkbox exercise, rather than a living document tied to the same underlying security data used elsewhere, creates conflicting records that both hospitals and reviewers can catch.

What Is the MDS2 Form?

The MDS2 is a standardized disclosure form published under HIMSS/NEMA HN 1-2019 that manufacturers use to communicate a medical device's cybersecurity-relevant characteristics. It was developed jointly by HIMSS and NEMA to give healthcare delivery organizations a consistent format instead of dozens of vendor-specific security questionnaires. The current version covers categories such as authentication controls, data encryption in transit and at rest, audit logging, remote access capability, malware protection, and the manufacturer's patching and vulnerability disclosure process.

Each section asks the manufacturer to answer yes, no, or "see notes," with a free-text field to add context. [KEY REQUIREMENT] Every "yes" or "no" answer should be verifiable against the device's actual architecture and current software version, not an aspirational answer based on a future release.

Who Fills Out the MDS2 and When

The manufacturer's quality, regulatory, or product security team typically owns the MDS2, drawing on input from engineering. It is not something a sales or marketing team should complete independently, since inaccurate technical claims create liability and damage trust once discovered.

The form should be completed before a device is offered for sale to healthcare providers, and updated at defined trigger points rather than left static for years.

How Hospitals Use the MDS2 in Procurement

Hospitals use the MDS2 as an early screening tool during vendor evaluation, often before a purchase order is issued. Clinical engineering and information security teams read the form to decide whether a device needs network isolation, additional monitoring, or contractual security commitments before it connects to the network.

Larger health systems frequently require the MDS2 as a mandatory attachment in their value analysis or capital equipment approval process. A missing or vague MDS2 can push a device evaluation back to the vendor for clarification, adding weeks to a sales cycle that manufacturers rarely anticipate.

Section-by-Section Walkthrough

Each MDS2 section maps to a specific operational concern for the buyer.

• Management of Private Data: what patient data types the device stores, transmits, or processes.
• Automatic Logoff and Access Controls: whether sessions time out and how user roles are enforced.
• Audit Controls: whether the device logs security-relevant events and how those logs are accessed.
• Node Authentication and Encryption: how the device authenticates to a network and protects data in transit.
• Remote Service and Support: whether the manufacturer or a third party can access the device remotely, and under what controls.
• System and Application Hardening: malware protection, patching cadence, and third-party component management.

Buyers most closely scrutinize the remote access and patching sections, since those answers determine ongoing operational risk rather than a one-time design decision.

Some procurement teams also compare the MDS2 answers against publicly known vulnerability disclosures for similar device classes before approving a purchase. A device with strong MDS2 answers but no visible history of security patches for known component vulnerabilities can still raise flags during this cross-check.

Common Mistakes Manufacturers Make

See also: AAMI SW96 vs TIR57: Did SW96 Replace It?, IEC 80001-1: Hospital Network Risk Management Explained, and MDCG 2019-16 & MedTech Cybersecurity.

The most frequent MDS2 errors are inconsistency and vagueness rather than outright dishonesty. Below are patterns reviewers flag repeatedly.

MDS2, SBOM, and the FDA's February 2026 Guidance

The MDS2 and a software bill of materials serve different but complementary purposes. The MDS2 gives a narrative, checkbox-style summary of security features, while an SBOM is a structured, machine-readable inventory of every software component and its version. Hospitals increasingly ask for both: the MDS2 to understand the security posture at a glance, and the SBOM to run vulnerability correlation against components like OpenSSL or embedded operating systems.

The FDA's February 3, 2026 final guidance on premarket cybersecurity (following the September 2023 final guidance and the June 27, 2025 update) expects manufacturers to provide SBOM, a documented security risk management process aligned to ISO 14971, and evidence of a secure product development lifecycle referencing AAMI SW96 (recognition number 13-131). [KEY REQUIREMENT] None of these premarket submission artifacts can be satisfied by pointing the FDA to an MDS2 form; the agency expects the underlying technical documentation, not the summary disclosure built for hospital buyers.

Where the MDS2 Is Not a Substitute for Security Documentation

The MDS2 was never designed to serve as a threat model, risk management file, or premarket submission artifact, and treating it that way creates gaps in both regulatory and procurement contexts. It summarizes features at a point in time; it does not document the manufacturer's process for identifying vulnerabilities, assessing their severity, or tracking remediation.

Hospitals that rely solely on the MDS2 for vendor risk assessment, without requesting an SBOM or asking about the manufacturer's vulnerability disclosure program, are working from an incomplete picture. Manufacturers should maintain the MDS2 as one output of a broader security documentation set, not as the whole set.

How Blue Goat Cyber Approaches This

Blue Goat Cyber helps manufacturers complete MDS2 forms that are accurate, consistent with their premarket submissions, and defensible under hospital procurement scrutiny. This starts with a technical review of the device's architecture, authentication design, encryption implementation, and patching process, so every MDS2 answer is grounded in verified fact rather than assumption. The same underlying documentation is then cross-checked against the manufacturer's SBOM and security risk management file to eliminate contradictions between what hospitals see and what regulators see.

Manufacturers preparing a submission under the FDA's current framework can review our FDA premarket cybersecurity services for how MDS2 completion fits into a broader submission strategy, including SBOM generation and risk documentation aligned to ISO 14971.

Frequently Asked Questions

What is the MDS2 form used for?

The MDS2 form discloses a medical device's cybersecurity features, such as authentication, encryption, and patching practices, to healthcare providers. Hospitals use it during procurement and risk assessment to decide what network controls or contractual protections a device needs before deployment.

Is the MDS2 form required by the FDA?

No. The MDS2 is a HIMSS/NEMA industry standard used primarily for hospital procurement, not a document the FDA requires in premarket submissions. Manufacturers still need separate documentation such as an SBOM and a security risk management file to meet the FDA's current premarket cybersecurity guidance.

Who should complete the MDS2 form at a manufacturer?

Quality, regulatory affairs, or product security staff with direct knowledge of the device's architecture should complete the MDS2, with technical input from engineering. Sales or marketing teams should not complete it independently, since inaccurate answers create liability.

How often should a manufacturer update the MDS2?

Update the MDS2 whenever a software release changes security-relevant functionality, when a new vulnerability affecting the device is disclosed, or at least annually as part of routine review. Static, years-old MDS2 forms are a common red flag for hospital security reviewers.

Does an MDS2 form replace an SBOM?

No. The MDS2 is a summary disclosure of security features, while an SBOM is a structured inventory of software components used for vulnerability tracking. Hospitals and regulators increasingly expect both documents, and each serves a distinct purpose.

CTA

Need an MDS2 form that holds up under hospital scrutiny and aligns with your FDA submission? Blue Goat Cyber can review your device architecture, complete accurate disclosures, and connect that work to your SBOM and risk documentation. Schedule a discovery session to get started.