MDS² draft in 8 minutes

MDS² Generator (HN1-2019)

Draft a Manufacturer Disclosure Statement for Medical Device Security against the 21 HN1-2019 sections. Hand the Markdown to your regulatory and product security leads to finalize.

Reviewed by

Christian Espinosa

Founder & CEO, Blue Goat Cyber

Last reviewed June 29, 2026

Manufacturer

Device name

Model / catalog number

Software / firmware version

Security contact (email)

HN1-2019 sections

0 / 21 answered (0%)

Management of Authentication of Users (MAUTH)

Unique IDs, role-based access, password policy, MFA support.

Automatic Logoff (ALOF)

Inactivity timeout for clinical / admin sessions.

Audit Controls (AUDT)

Tamper-evident event logging of security-relevant actions.

Authorization (AUTH)

Role / permission model that restricts what each user can do.

Configuration of Security Features (CNFS)

Customer-modifiable security settings + safe defaults.

Cybersecurity Product Upgrades (CSUP)

Mechanism for delivering security updates over the lifecycle.

Health Data De-Identification (DTBK)

Support for de-identifying PHI in exports and logs.

Data Backup and Disaster Recovery (DIDT)

Backup, restore, and continuity capabilities.

Emergency Access (EMRG)

Break-glass override that is logged and reviewable.

Integrity and Authenticity Assurance (IGAU)

Code signing, image integrity, secure boot.

Malware Detection / Protection (MLDP)

Allowlisting, AV, or platform protections appropriate to the device.

Node Authentication (NAUT)

Mutual auth between device, gateway, EHR, cloud.

Person Authentication (PAUT)

Identity proofing for clinical / patient users.

Physical Locks (PLOK)

Tamper-evident enclosures, port locks, key locks.

Third-Party Components in Product Lifecycle Roadmaps (RDMP)

Plans for component EoL, replacement, hardening.

System and Application Hardening (SAHD)

Disabled services, least privilege, removed defaults.

Security Guidance (SGUD)

Customer-facing security configuration and operations guide.

Health Data Storage Confidentiality (STCF)

At-rest encryption of PHI and credentials.

Transmission Confidentiality (TXCF)

In-transit encryption (TLS 1.2+ / equivalent).

Transmission Integrity (TXIG)

Integrity protection on all transmitted clinical/control data.

Cybersecurity Practices (CYBR)

SBOM, CVD, vulnerability management, threat-model status.

What you'll see after you submit

21 HN1-2019 sections become a Markdown MDS² ready for customer security review

Each section gets a Yes / No / N/A answer plus a free-text note for configuration and limitations.
Markdown export with manufacturer, device, model, version, and security contact baked in.
Aligned to the HIMSS / NEMA HN1-2019 manufacturer disclosure standard referenced by hospital procurement teams.
Pairs with the eSTAR Cybersecurity Checklist - eSTAR flags MDS² as required customer-facing security labeling.

Common misconceptions

What teams usually get wrong

Myth: MDS² is an FDA submission document.

Reality: MDS² is a customer-facing disclosure for hospitals and IDNs. The FDA looks for it as evidence of postmarket transparency, but the form itself is HIMSS / NEMA HN1-2019, not an FDA template.
Myth: A blank or all-N/A MDS² satisfies procurement.

Reality: Hospitals score MDS² answers against IEC 80001 risk practices. All-N/A answers drive RFP rejections and contracting delays.
Myth: Once published, MDS² stays static.

Reality: MDS² is versioned with the device. Any change to authentication, encryption, OTA, or supported OS triggers a refresh.