Published: June 11, 2026
Published June 11, 2026
The MDS2 (Manufacturer Disclosure Statement for Medical Device Security) is a voluntary, standardized form maintained by the Health Sector Coordinating Council (HSCC) that medical device manufacturers use to disclose security-relevant features of a device to hospital procurement and biomedical engineering teams. The FDA's February 3, 2026 final premarket cybersecurity guidance does not mandate MDS2 specifically, but it expects cybersecurity-relevant information to be communicated to the user organization. MDS2 is the most widely accepted format for that communication and is filed under the Labeling section of eSTAR v7.0.
Key Takeaways
- MDS2 is a voluntary HSCC-maintained disclosure form, not an FDA-mandated submission deliverable.
- The Feb 2026 final guidance expects cybersecurity labeling for the user organization; MDS2 is the de facto standard format.
- The current version is MDS2 v3.0 (HSCC, 2023), with structured sections covering management of personally identifiable information, audit controls, authentication, configuration, cybersecurity product upgrades, health data de-identification, network security, software, and physical controls.
- MDS2 is filed under eSTAR v7.0's separate Labeling section (not under the Cybersecurity section).
- Hospital procurement teams treat a missing or stale MDS2 as a reason to delay or reject a purchase.
Table of Contents
- Key Takeaways
- Why this matters
- What MDS2 actually is
- What goes in MDS2 v3.0
- Where MDS2 fits in an FDA submission
- Common deficiency and procurement-rejection patterns
- How Blue Goat Cyber writes MDS2 disclosures
- FAQ
Why this matters
Two audiences read your MDS2: hospital cybersecurity and biomedical engineering teams during procurement, and FDA reviewers during premarket review. The first audience will block a purchase if MDS2 is missing or thin. The second audience treats MDS2 as one acceptable form of the cybersecurity labeling the Feb 2026 guidance expects.
"Cybersecurity labeling should provide the user organization with sufficient information about the cybersecurity features, configuration, and limitations of the device to support its secure operation throughout the deployment lifecycle."
The agency does not name MDS2, but it does describe the content. MDS2 is the format the user-organization side of the market converged on.
What MDS2 actually is
MDS2 stands for Manufacturer Disclosure Statement for Medical Device Security. It is a structured questionnaire that a manufacturer completes for each medical device, declaring how the device handles a defined set of security topics. The form is maintained by the Health Sector Coordinating Council (HSCC) Joint Cybersecurity Working Group.
Key facts about the current form:
- Current version: MDS2 v3.0 (issued 2023, aligned to the HSCC Medical Device and Health IT Joint Security Plan)
- Voluntary. No FDA regulation requires MDS2 specifically.
- De facto required by hospitals. Most large IDNs (Integrated Delivery Networks) have procurement gates that block purchases without a current MDS2.
- Per device, per major version. A new MDS2 is expected when a device changes materially.
The HSCC publishes the MDS2 template; manufacturers complete it.
What goes in MDS2 v3.0
MDS2 v3.0 is structured as a series of sections, each with a set of Yes/No/N/A/See note questions and a notes field. The major sections include:
- Management of Private Data (MPD) — what private data the device handles, where it lives, how it is protected
- Audit Controls (ADT) — logging, retention, log protection
- Authentication (AUT) — authentication factors, account lifecycle, default credentials
- Configuration of Security Features (COF) — what is configurable by the operator, defaults
- Cyber Security Product Upgrades (CSUP) — how the device receives and applies patches
- Health Data De-Identification (DIDT) — whether the device handles de-identification, methods used
- Data Backup and Disaster Recovery (DTBK) — backup capabilities, recovery
- Emergency Access (EMRG) — break-glass and emergency overrides
- Health Data Integrity and Authenticity (IGAU) — data integrity controls
- Malware Detection / Protection (MLDP) — anti-malware posture
- Node Authentication (NAUT) — device-to-device authentication
- Connectivity Capabilities (CONN) — protocols, ports, services
- Person Authentication (PAUT) — clinician/patient/service authentication
- Physical Locks (PLOK) — physical security features
- System and Application Hardening (SAHD) — OS and application hardening posture
- Security Guidance (SGUD) — operator-facing security documentation
- Health Data Storage Confidentiality (STCF) — at-rest encryption
- Transmission Confidentiality (TXCF) — in-transit encryption
- Transmission Integrity (TXIG) — in-transit integrity controls
- Cyber Security Risk Management (RDMP) — SDLC and risk-management posture
The notes fields matter. Hospital cyber teams read them. A Yes/No without context invites a follow-up question that delays procurement.
Where MDS2 fits in an FDA submission
In eSTAR v7.0, MDS2 is filed under the Labeling section, not under the Cybersecurity section. This is a frequent source of confusion. The Cybersecurity section has 8 attachment slots (Management Plan, Risk Management, Threat Model, Risk Assessment, SBOM, Controls, Testing, Metrics) — MDS2 is not one of them. Labeling lives in its own eSTAR section.
The Cybersecurity Management Plan (Slot 1) and the cybersecurity labeling narrative (referenced from Slot 6 Controls) should both point to the MDS2 as the consolidated user-facing disclosure.
For depth on the slot layout see our eSTAR v7.0 mapping guide.
Common deficiency and procurement-rejection patterns
See also: Interoperability Labeling for Connected Medical Devices, eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions, and Unresolved Anomalies in FDA Cybersecurity Submissions.
FDA side:
- Submission has no MDS2 and no equivalent cybersecurity labeling → AI request asking for user-facing security documentation
- MDS2 present but inconsistent with the Slot 6 Controls description → reviewer flags the inconsistency
Hospital procurement side:
- MDS2 missing → purchase order blocked
- MDS2 stale (older version of the form, or older version of the device) → security review committee delays approval
- MDS2 Yes/No answers with no notes → cyber team rejects until clarified
- MDS2 inconsistent with the SBOM (different component list, different patchability claims) → cyber team escalates
The MDS2 is one of the rare deliverables where the operator is a more critical reviewer than the regulator.
How Blue Goat Cyber writes MDS2 disclosures
We complete MDS2 v3.0 disclosures as the cross-reference of three artifacts: the threat model (so the answers reflect the real device behavior), the SBOM (so the patchability and component answers reconcile), and the pen test report (so anything claimed in MDS2 has been exercised). We write the notes fields, not just the Yes/No. We reconcile MDS2 against the Slot 6 Controls description so reviewers and procurement teams see a consistent story. See our MDS2 / HSCC procurement disclosure service.
If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
FAQ
Is MDS2 required by the FDA?
No. The Feb 2026 final guidance expects cybersecurity labeling for the user organization but does not name MDS2 specifically. MDS2 is the de facto industry format that satisfies the expectation. Most manufacturers use it because hospital procurement requires it independently.
Which version of MDS2 should we use?
Use MDS2 v3.0 (HSCC, 2023). Older versions (v2.x) are still accepted by some procurement teams but increasingly flagged as stale. New submissions should default to v3.0.
How often does MDS2 need to be updated?
When the device changes materially in any way that affects an MDS2 answer — new authentication mechanism, new connectivity, new patch mechanism, changed default configuration, changed crypto, new third-party component with security impact. Many manufacturers refresh annually as a default cadence even without material change.
Does MDS2 replace the SBOM?
No. MDS2 is a manufacturer disclosure of security features and behavior. The SBOM is a component inventory. They serve different purposes and live in different eSTAR sections.
Who in the manufacturer should complete MDS2?
A cybersecurity-knowledgeable individual with access to the device's threat model, SBOM, and test evidence — typically the cybersecurity lead named in the Cybersecurity Management Plan. Procurement teams discount MDS2s that read as completed by marketing.
Where do hospitals expect to find MDS2?
Most large IDNs require MDS2 as part of the RFP response or the post-award security review. Many publish their MDS2 expectations in their vendor security questionnaire. The HSCC template and the device's MDS2 should both be readily available — typically on the manufacturer's security or trust portal.
Need help completing MDS2 for your device?
If you are preparing a submission or responding to hospital procurement and need an MDS2 v3.0 that reconciles with your SBOM, threat model, and Slot 6 Controls, we will write it. Request a scoping call.
Christian Espinosa — Founder, Blue Goat Cyber. CISSP, ex-military red team. Has prepared MDS2 disclosures across more than 250 connected medical devices, including infusion pumps, implantables, IVD analyzers, and SaMD platforms. More on the author.