
Published: June 18, 2026
HHS 405(d) is the federal program that publishes the Health Industry Cybersecurity Practices (HICP), a voluntary framework written for hospitals and health systems. It is not a manufacturer regulation, but its Medical Device Security practice (Practice #9) is what hospital procurement and biomed teams use to evaluate the devices they buy. For medical device manufacturers, aligning your FDA Section 524B artifacts (SBOM, threat model, vulnerability management, coordinated disclosure) with HICP Practice #9 is the cleanest way to satisfy both the FDA at premarket and the hospital customer at procurement.
The HHS 405(d) program was established under Section 405(d) of the Cybersecurity Act of 2015 to develop consensus-based cybersecurity practices for the Health Industry. Its flagship deliverable, the Health Industry Cybersecurity Practices (HICP), is the document hospital security teams reach for when they need a defensible baseline. Manufacturers do not file anything against 405(d), but they ship into a market where 405(d) is the language of the buyer. This post explains what 405(d) and HICP are, how Practice #9 maps to FDA Section 524B artifacts, and how a manufacturer should structure premarket and postmarket evidence so that the same package answers both the FDA reviewer and the hospital procurement team.
Key Takeaways
- HHS 405(d) and HICP are voluntary practices aimed at hospitals, not manufacturer regulations.
- HICP Practice #9 (Medical Device Security) is what hospital procurement uses to score vendors.
- HICP Practice #9 expectations overlap heavily with FDA Section 524B premarket and postmarket artifacts.
- A 524B-aligned package (SBOM, threat model, vulnerability management plan, CVD policy) answers most HICP Practice #9 procurement questions.
- Manufacturers that publish a short HICP alignment statement shorten sales cycles with HDOs.
Table of Contents
- What HHS 405(d) Is
- What HICP Is, and Who It Is For
- HICP Practice #9: Medical Device Security
- How HICP Practice #9 Maps to FDA Section 524B
- What Manufacturers Should Publish
- How Blue Goat Approaches HICP Alignment
- FAQ
Why this matters
Medical device manufacturers face two cybersecurity audiences with different documents and different vocabularies. The FDA reviews premarket submissions against Section 524B and the February 3, 2026 final premarket cybersecurity guidance. Hospital procurement and biomed teams review vendors against HHS 405(d) HICP, often via questionnaires like the MDS2 form and the AHA HSCC playbooks that reference HICP directly. The overlap is large but not obvious, and manufacturers that treat the two as separate workstreams duplicate effort and still leave gaps. Treating 524B as the source of truth and publishing a short HICP Practice #9 alignment statement on top of it satisfies the buyer without adding a parallel program.
What HHS 405(d) Is
Origin and Authority
Section 405(d) of the Cybersecurity Act of 2015 directed the Secretary of Health and Human Services to convene a public-private task group to develop consensus-based cybersecurity practices for the Health Industry. The 405(d) Program operates out of the HHS Administration for Strategic Preparedness and Response (ASPR) in coordination with the Healthcare and Public Health Sector Coordinating Council (HSCC). The program publishes HICP and supporting resources, and it convenes the 405(d) Task Group that maintains them.
Voluntary, Not Regulatory
The 405(d) program does not create regulations. HICP is voluntary guidance. The Health Industry Cybersecurity Practices were, however, recognized in the HITECH Act amendments as a factor HHS Office for Civil Rights (OCR) considers when evaluating a covered entity's security program during a breach investigation, which gives the framework material weight even though it is not binding.
What HICP Is, and Who It Is For
Audience
HICP is written for Health Industry organizations, primarily hospitals and health systems (referred to as HDOs, or Healthcare Delivery Organizations). It is structured around ten cybersecurity practices, organized into Technical Volume 1 (small organizations) and Technical Volume 2 (medium and large organizations). The practices cover email protection, endpoint protection, access management, data protection, asset management, network management, vulnerability management, incident response, medical device security, and cybersecurity oversight and governance.
Why Manufacturers Care
Hospitals score the medical devices they buy against the same practices they hold themselves to. Practice #9, Medical Device Security, is the practice that translates directly into procurement questions for manufacturers. When a hospital evaluates a connected device, the buyer is effectively asking whether the device fits inside the HDO's HICP-aligned security program. Manufacturers that can answer "yes" with documentation move through procurement faster.
HICP Practice #9: Medical Device Security
What the Practice Asks For
HICP Practice #9, Medical Device Security, expects an HDO to maintain an inventory of medical devices, manage endpoint protections appropriate to each device, segment medical device traffic on the network, manage vulnerabilities and patches across the device fleet, and coordinate with manufacturers on security updates and incident response. Sub-practices include asset inventory and SBOM ingestion, network segmentation and access control, vulnerability and patch management, and procurement security requirements.
The Manufacturer-Facing Sub-Practices
See also: FDA Section 524B Explained Subsection by Subsection: What Each Requirement Means in 2026, CAPA and Medical Device Cybersecurity: Closing the Loop on Vulnerabilities and FDA Deficiencies, and IEC 62304 Classes vs FDA Device Classes: Cybersecurity Impact.
The sub-practices that directly drive manufacturer questions are procurement security requirements (what the HDO expects vendors to provide before purchase), vulnerability and patch management (how the manufacturer will support the device after sale), and incident response coordination (how the manufacturer will communicate during a security event). These are exactly the topics the FDA expects in a Section 524B submission and postmarket plan.
How HICP Practice #9 Maps to FDA Section 524B
The Mapping
| HICP Practice #9 expectation | Corresponding FDA Section 524B artifact |
|---|---|
| SBOM ingestion at procurement | Section 524B(b)(3) machine-readable SBOM |
| Vulnerability identification on shipped components | SBOM + VEX, postmarket vulnerability monitoring plan |
| Coordinated patch and update process | Section 524B(b)(2)(B) plan to monitor, identify, and address postmarket vulnerabilities |
| Coordinated vulnerability disclosure | CVD policy (expected in submission, published externally) |
| Network and architecture documentation | Architecture views (system, multi-patient harm, updateability, security use case) |
| Risk-based security controls | Security risk assessment and threat model |
| Customer security communications | Security advisories, MDS2, customer-facing security documentation |
What the Mapping Shows
The mapping is dense. A Section 524B-aligned package already produces almost every artifact a hospital procurement team needs to score the device against HICP Practice #9. The gap is usually packaging: the 524B artifacts live inside the submission and are not framed for a procurement reader. A short HICP alignment statement and a customer-facing security documentation set close that gap without new technical work.
What Manufacturers Should Publish
A practical manufacturer-side response to HICP Practice #9 includes a handful of customer-facing documents:
- A current SBOM in CycloneDX or SPDX, refreshed on each release.
- A VEX statement set covering the SBOM's exploitable components.
- A coordinated vulnerability disclosure (CVD) policy with a public intake address.
- An MDS2 form (HSCC Manufacturer Disclosure Statement for Medical Device Security) per product.
- A short HICP Practice #9 alignment statement that maps each sub-practice to the manufacturer's evidence.
- A security advisory channel and subscription path for customers.
These are not new artifacts. Items 1 through 4 already exist for any Section 524B-compliant submission. Items 5 and 6 are lightweight packaging on top.
How Blue Goat Approaches HICP Alignment
We build premarket and postmarket cybersecurity programs against FDA Section 524B and the February 3, 2026 final premarket cybersecurity guidance, and we publish the customer-facing HICP Practice #9 alignment layer on top of the same evidence. The 524B work produces the SBOM, VEX, threat model, architecture views, vulnerability management plan, and CVD policy. The HICP layer reframes those artifacts for hospital procurement readers and adds the MDS2 and alignment statement. Our team holds CISSP, OSCP, and prior military red-team credentials, and we ground our work in Section 524B, the FDA's February 3, 2026 guidance, AAMI SW96:2023, IEC 81001-5-1, and the HSCC Joint Security Plan. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our premarket cybersecurity service or our postmarket SBOM and VEX monitoring service.
FAQ
Is HHS 405(d) a regulation that medical device manufacturers must follow?
No. The 405(d) program publishes voluntary guidance (HICP) aimed at hospitals and health systems, not at manufacturers. There is no filing or compliance obligation against 405(d) for a device maker. Manufacturers care about HICP because hospital procurement teams use it as the baseline for evaluating the cybersecurity posture of the devices they buy. Failing the hospital procurement review is a commercial problem, not a regulatory one, but it is often the bigger obstacle to revenue than the FDA submission itself.
How is HICP different from the FDA's Section 524B requirements?
Section 524B is statutory and applies to cyber device submissions to the FDA. HICP is voluntary and applies to how hospitals run their own cybersecurity programs. The two overlap heavily on medical device security: SBOMs, vulnerability management, coordinated disclosure, and patching all appear in both. The practical difference is audience and packaging. 524B speaks to a regulator and lives inside a submission; HICP Practice #9 speaks to a procurement reviewer and lives in customer-facing documentation.
What is HICP Practice #9?
HICP Practice #9 is the Medical Device Security practice within the Health Industry Cybersecurity Practices. It covers asset inventory, SBOM ingestion, network segmentation, vulnerability and patch management, procurement security requirements, and incident response coordination for medical devices in the hospital environment. For manufacturers, the practice translates into the procurement questionnaire items that hospitals ask before buying a connected device.
Do we need a separate HICP-aligned security program if we already meet Section 524B?
No. A Section 524B-aligned program already produces almost every artifact HICP Practice #9 asks a manufacturer to support. What you usually need on top is packaging: an MDS2 form per product, a short HICP alignment statement that maps each Practice #9 sub-practice to your existing evidence, and a public CVD policy and security advisory channel. These do not require new technical work, only customer-facing presentation of work you already have.
How does HICP relate to the MDS2 form?
The MDS2 is the Manufacturer Disclosure Statement for Medical Device Security, published by the HSCC and aligned to HICP. It is the standard form hospitals send to manufacturers during procurement to capture the device's security characteristics. A current MDS2 per product is one of the most effective ways to demonstrate HICP Practice #9 alignment without writing custom documentation for each customer.
Ready to align your cybersecurity program with both the FDA and HICP?
If you ship connected medical devices and need a cybersecurity program that satisfies the FDA's Section 524B reviewers and the hospital procurement teams scoring you against HICP Practice #9, we can help. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. Christian has led premarket and postmarket cybersecurity programs for connected medical devices across Class II and Class III submissions and previously commanded military red-team operations. Read more at christian-espinosa.