The HHS Healthcare and Public Health Cybersecurity Performance Goals are written for hospitals, but they have become a procurement requirement for the devices hospitals buy. This guide maps each Essential and Enhanced CPG to the medical device manufacturer evidence that hospital security and biomed teams are asking for.
Last reviewed: June 2026 against the HHS HPH Cybersecurity Performance Goals (Essential and Enhanced), the FDA February 3, 2026 final premarket cybersecurity guidance, and the HSCC Medical Device and Health IT Joint Security Plan (JSP2).
Related: MDS2 and HSCC Procurement Disclosure is the service that operationalizes this mapping for sponsors. Postmarket SBOM and VEX Monitoring covers the postmarket evidence hospitals tie back to the CPGs.
TL;DR, why a device manufacturer should care about a hospital framework
| What the CPGs are | What the CPGs are not | |
|---|---|---|
| Audience | Healthcare delivery organizations (hospitals, health systems, clinics) | Medical device manufacturers |
| Status | Voluntary HHS framework, but cited in HRSA and CMS funding criteria and in HHS sector risk management | A regulation enforced against device vendors |
| Structure | Essential CPGs (baseline) and Enhanced CPGs (maturity target), mapped to NIST CSF | A standalone control catalog like NIST 800-53 |
| Why MDMs see them | Hospital procurement and biomed teams ask "how does your device help us meet CPG X" in RFPs and MDS2 follow-ups | A direct FDA submission requirement |
| What MDMs owe | A clean mapping from device capabilities to each relevant CPG, surfaced in MDS2 and HSCC procurement responses | A claim that the device "is CPG compliant" (the hospital is the accountable entity) |
If you sell a connected device into a US hospital in 2026, expect at least one customer to send you a CPG mapping questionnaire before contract. The vendors that answer cleanly close faster. The vendors that say "the CPGs do not apply to us" lose deals.
The CPGs in one paragraph
HHS published the HPH CPGs to give the sector a single, prioritized list of cybersecurity practices, replacing the patchwork of frameworks that hospitals were being asked to implement. The Essential CPGs are the floor: practices every healthcare organization should have in place. The Enhanced CPGs add maturity, defense in depth, and resilience. Both layers are mapped to the NIST Cybersecurity Framework and to the HHS 405(d) Health Industry Cybersecurity Practices (HICP). They are voluntary today, but HHS has signaled that future federal funding, cyber insurance underwriting, and HHS sector incentives will reference the CPGs as the expected baseline.
How the CPGs interact with FDA Section 524B
The CPGs and FDA Section 524B address the same problem from opposite ends:
- FDA Section 524B and the February 2026 final premarket cybersecurity guidance require the manufacturer to design, document, and maintain a secure device, with a threat model, SBOM, vulnerability management, and a coordinated disclosure process. This is the design and submission layer.
- The HHS HPH CPGs require the hospital to operate a secure environment, with MFA, asset inventory, vulnerability management, segmentation, incident response, and recovery. This is the deployment and operations layer.
A connected device sits in the middle. The hospital cannot meet several CPGs without features and disclosures the manufacturer provides. The manufacturer cannot meet several Section 524B postmarket commitments without the hospital cooperating. The CPG mapping is the contract between those two layers.
The mapping, Essential CPGs
The table below lists each Essential CPG, the hospital obligation, and what the manufacturer is expected to deliver to support it. Use it as the source for MDS2 supplemental responses, HSCC JSP2 mappings, and direct RFP answers.
| Essential CPG | Hospital obligation | What the device manufacturer provides |
|---|---|---|
| Mitigate Known Vulnerabilities | Patch internet-facing and known-exploited vulnerabilities on a defined timeline. | Patchable architecture, signed update mechanism, published patch SLA, VEX statements against the device SBOM, KEV catalog monitoring. |
| Email Security | Block phishing, enforce DMARC, train staff. | Not directly applicable; confirm device does not require unauthenticated SMTP from the hospital network. |
| Multifactor Authentication | Enforce MFA on all internet-facing and privileged access. | Device supports MFA for administrative access (or documents the compensating controls and trust boundary if it cannot). |
| Basic Cybersecurity Training | Annual training for all staff. | Provide role-based training materials for biomed and clinical users of the device. |
| Strong Encryption | Encrypt data in transit and at rest for sensitive data. | TLS 1.2+ for all network interfaces, documented cipher suites, encryption of PHI at rest on the device, key management description. |
| Revoke Credentials of Departing Workforce | Disable accounts on termination. | Device supports centralized identity (LDAP/SAML/OIDC) or documents how local accounts are managed and offboarded. |
| Basic Incident Planning and Preparedness | Documented incident response plan, tested annually. | Coordinated vulnerability disclosure (CVD) program, security contact, defined escalation path, support during hospital incident response. |
| Unique Credentials | No shared accounts on critical systems. | Device enforces unique per-user accounts (no shared service or "biomed" logins) or documents why a shared account is technically required. |
| Separate User and Privileged Accounts | Separate accounts for admin work. | Role-based access control in the device with distinct user and admin roles. |
| Vendor / Supplier Cybersecurity Requirements | Require cybersecurity terms in procurement. | MDS2 (latest version), HSCC JSP2 mapping, CycloneDX or SPDX SBOM, VEX, coordinated disclosure policy URL, contractual security commitments. |
| Cybersecurity Mitigation | Detect and respond to anomalous activity. | Security event logging in a parseable format, syslog or equivalent egress, documented events and severity. |
| Detect Relevant Threats and TTPs | Detection coverage aligned to sector threats. | Map device telemetry to MITRE ATT&CK for ICS / Enterprise techniques relevant to the device class. |
| Incident Reporting | Report incidents to CISA and HHS as required. | Notify customers of confirmed device vulnerabilities under your CVD policy and through CISA ICS-CERT / NCCIC where applicable. |
| Unique Credentials for Privileged Users | No shared admin accounts. | Same as above; enforced for service and engineering accounts. |
| Email Security (advanced filters) | n/a for devices. | Not applicable. |
Several Essential CPGs are pure hospital operations (email security, workforce training, etc.) and do not require a device-level answer. Saying "not applicable" against those, with a one-line reason, is the correct response in an MDS2 supplemental.
The mapping, Enhanced CPGs
The Enhanced CPGs are where buyer expectations are climbing fastest. Hospitals with mature security programs (academic medical centers, large IDNs) increasingly require Enhanced-level answers for any new connected device purchase.
| Enhanced CPG | Hospital obligation | What the device manufacturer provides |
|---|---|---|
| Asset Inventory | Complete inventory of IT and medical assets, including OS and software versions. | Machine-readable SBOM (CycloneDX or SPDX), unique device identifier, ability to expose firmware and software versions to a CMMS/CMDB integration. |
| Third-Party Vulnerability Disclosure | Process for receiving and acting on third-party reports. | Public coordinated vulnerability disclosure policy at /cvd, security@ contact, security.txt, response SLA. |
| Third-Party Incident Reporting | Be notified of vendor incidents that affect the hospital. | Notification process for confirmed vulnerabilities and incidents affecting deployed devices, with timelines committed in contract. |
| Cybersecurity Testing | Regular testing of critical systems. | Pen test summary letter and remediation evidence for the device, refreshed on a defined cadence and on material change. |
| Cybersecurity Mitigation | Implement compensating controls when patches are not available. | Provide compensating controls guidance per known vulnerability (typically delivered through a VEX statement plus a mitigation note). |
| Detect and Respond to Relevant Threats and TTPs | Active detection program. | Logging output that aligns to common SIEM ingest formats; documented detection use cases per device class. |
| Network Segmentation | Segment medical devices from general IT. | Document required network flows (ports, protocols, destinations), publish a network topology diagram, support deployment behind a segmentation boundary. |
| Centralized Log Collection | Send logs to a central SIEM. | Syslog or equivalent log export, documented event catalog, no requirement for plaintext credentials in log forwarding. |
| Centralized Incident Planning and Preparedness | Coordinated IR across the system. | Named security contact, on-call escalation, support during hospital-side incident response engagements. |
| Configuration Management | Hardened baseline configurations. | Provide a documented secure configuration baseline for the device and detection of drift where feasible. |
| Supply Chain Incident Reporting | Notify on upstream supplier incidents. | Track and report third-party component incidents through your VEX and customer notification process. |
| Supply Chain Vulnerability Disclosure | Require disclosure from suppliers. | SBOM coverage of third-party components, VEX statements that distinguish exploitable from non-exploitable findings. |
What to put in your MDS2 and HSCC responses
Treat the CPG mapping as a supplemental tab attached to your MDS2 and HSCC JSP2 responses. For each CPG the customer cites, answer in this structure:
- Applicability: applicable / partially applicable / not applicable.
- Device capability: what the device provides (be specific, name the feature and version).
- Customer responsibility: what the hospital must configure or operate to make the capability effective.
- Evidence: the document, SBOM artifact, configuration guide, or pen test letter that backs the claim.
The vendors that lose CPG questionnaires are the ones that write "yes" with no evidence or "not applicable" with no reason. The vendors that win write one short paragraph per CPG and attach the artifact.
Common mistakes
- Claiming the device is "CPG compliant". The CPGs apply to the hospital, not the device. The correct claim is "this device supports the hospital in meeting CPG X by providing Y."
- Treating the CPGs as a replacement for FDA Section 524B. They are additive. A clean FDA submission does not satisfy a hospital CPG questionnaire, and vice versa.
- Using a different MFA story per customer. Pick one supported identity model (typically OIDC or SAML against the customer IdP, plus local fallback) and reuse it across every CPG response.
- Skipping the SBOM and VEX line items. Asset Inventory, Supply Chain Vulnerability Disclosure, and Mitigate Known Vulnerabilities all depend on the SBOM you already produce for FDA. Reuse the artifact.
- Treating "not applicable" as a free pass. Hospital security teams flag every blank or unjustified N/A. Always include a one-line reason.
How Blue Goat approaches this
We build the CPG mapping as part of every premarket cybersecurity engagement, alongside the threat model, SBOM, and Section 524B evidence package. Our team, led by engineers with CISSP and OSCP credentials and prior US military red team experience, has answered CPG-style procurement questionnaires for connected diagnostic, infusion, monitoring, and SaMD devices across IDN, academic, and federal hospital customers. The mapping is delivered as a supplemental to the MDS2 and HSCC JSP2 responses, in the same format every time, so hospital procurement teams can compare it against their own CPG scorecards in minutes. See MDS2 and HSCC Procurement Disclosure for the engagement scope and deliverables. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
FAQ
What are the HHS HPH Cybersecurity Performance Goals?
The HHS Healthcare and Public Health Cybersecurity Performance Goals are a voluntary set of prioritized cybersecurity practices that HHS published for the healthcare sector. They are organized into Essential CPGs (the baseline every organization should meet) and Enhanced CPGs (a maturity target), and they map back to the NIST Cybersecurity Framework and the HHS 405(d) Health Industry Cybersecurity Practices.
Do the HHS CPGs apply to medical device manufacturers?
Not directly. The CPGs apply to healthcare delivery organizations, hospitals, health systems, and clinics. The reason device manufacturers care is that hospital procurement, biomed, and security teams increasingly ask vendors to show how each device supports the CPGs the hospital is accountable for, typically through MDS2 and HSCC JSP2 procurement disclosures.
How are the HHS CPGs different from FDA Section 524B?
Section 524B and the FDA February 3, 2026 final premarket cybersecurity guidance govern how a manufacturer designs, documents, and submits a secure device. The HPH CPGs govern how a hospital operates a secure environment around that device. They are complementary, a clean FDA submission does not satisfy a hospital CPG questionnaire, and a CPG mapping does not replace the Section 524B evidence package.
Are the HHS CPGs mandatory?
The CPGs are voluntary today. HHS has signaled that future federal funding, HRSA and CMS criteria, and cyber insurance underwriting will reference the CPGs as the expected baseline, and several large health systems already require Essential-level responses in procurement. Treat them as a de facto requirement for selling connected devices into US hospitals.
What is the minimum evidence package to answer a hospital CPG questionnaire?
At minimum: current MDS2, HSCC JSP2 mapping, machine-readable SBOM (CycloneDX or SPDX), VEX statements for known vulnerabilities, a public coordinated vulnerability disclosure policy, a secure configuration guide, and a pen test summary letter. Each of those artifacts maps to multiple Essential and Enhanced CPGs at once.
Ready to map your device to the HHS CPGs?
Blue Goat Cyber builds the CPG mapping alongside your FDA Section 524B evidence package so the same SBOM, VEX, threat model, and pen test letter answer both the regulator and your hospital customers. Talk to our team about a CPG-ready procurement package. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
Author: Albert Konik, Director of Cybersecurity, CISSP, OSCP. Albert leads premarket cybersecurity engagements at Blue Goat Cyber, including MDS2, HSCC JSP2, and HHS HPH CPG mappings for connected medical devices across diagnostic, infusion, monitoring, and SaMD product lines.