31 October 2026 · 12 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Healthcare penetration testing: what hospitals, health systems and medical device manufacturers need to test, and which rules require it
Healthcare carries the highest breach costs of any sector and runs some of the oldest technology connected to a network. This sector guide covers the regulatory frame in the United States and Europe, the attack surface from the electronic health record to the infusion pump, and the order in which a hospital CISO should scope testing. For the HIPAA Security Rule itself, our separate HIPAA penetration testing guide is the regulation deep-dive; this page is the sector overview.
Why healthcare is tested differently
Three things set healthcare apart. First, the data: protected health information cannot be reissued like a payment card, and a single hospital record sells for more on criminal markets than almost any other personal data. Second, the consequence of downtime: when the February 2024 ransomware attack on Change Healthcare took a clearinghouse offline, pharmacies could not fill prescriptions and providers went weeks without reimbursement across the United States; the attack on Ascension in May 2024 forced hospitals to divert ambulances and return to paper charts. The entry point in the Change Healthcare case, according to the company's own testimony, was a remote access portal without multi-factor authentication. Third, the technology: imaging modalities, infusion pumps and laboratory analysers often run operating systems their vendor stopped patching years ago, cannot be scanned without risk, and sit on the same network as the clinicians' workstations.
A healthcare penetration test therefore has to do more than a generic network and application test. It has to respect clinical safety (no active exploitation of a device connected to a patient, agreed testing windows, a clinical escalation contact), it has to understand healthcare protocols (HL7 v2, FHIR, DICOM) that generic tools misread, and it has to produce evidence that maps to the regulations your compliance team answers to. This guide is organised around those regulations first, because they decide what gets tested and how the report is read.
The US regulatory frame: HIPAA, HHS 405(d), FDA and HITRUST
Four sources of obligation, with different legal weight. Together they describe the testing programme a US healthcare organisation is expected to run in 2026.
1. HIPAA Security Rule: 45 CFR 164.308(a)(8) and the 2025 proposed rule
The current Security Rule requires a risk analysis under 164.308(a)(1)(ii)(A) and a periodic technical and non-technical evaluation under 164.308(a)(8). It does not name penetration testing, but OCR has long treated testing as the normal way to perform the technical evaluation. In January 2025 HHS published a proposed rule to update the Security Rule that would, among other changes, require vulnerability scanning at least every six months and penetration testing at least every twelve months, alongside mandatory multi-factor authentication, encryption, network segmentation and a technology asset inventory. It remains a proposal until HHS publishes a final rule; treat the twelve-month cadence as the direction of travel and the baseline a regulator will measure you against. Our HIPAA penetration testing guide covers the rule in detail.
2. HHS 405(d) and the Health Industry Cybersecurity Practices (HICP)
The 405(d) programme, created by the Cybersecurity Act of 2015, publishes HICP: ten cybersecurity practices for small, medium and large organisations, with technical volumes that include vulnerability management and penetration testing of the external perimeter and internal network. HICP matters legally because Public Law 116-321 (2021) directs OCR to consider whether an organisation had 'recognized security practices' such as HICP or the NIST Cybersecurity Framework in place for the prior twelve months when deciding fines and audit scope. A documented testing programme aligned to HICP is one of the clearest ways to show that.
3. FDA premarket cybersecurity guidance and Section 524B of the FD&C Act
For device manufacturers the frame is Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act, 2023 and in force since 29 March 2023. Any 'cyber device' submission must include a plan for monitoring and addressing postmarket vulnerabilities, processes giving reasonable assurance that the device and related systems are cybersecure, and a software bill of materials. The FDA's final guidance 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions', first issued in September 2023 and since revised, describes the cybersecurity testing it expects to see in a submission, including penetration testing performed by testers independent of the development team, with the report, the scope and the testers' qualifications included. Hospitals should ask vendors for that evidence during procurement.
4. HITRUST CSF
HITRUST is the certification health systems and their vendors most often require of each other. The CSF harmonises HIPAA, NIST, ISO 27001 and PCI DSS controls and, in its validated assessments, requires independent penetration testing of internet-facing systems and internal networks on a defined cadence with documented remediation. A penetration test report scoped to the HITRUST assessment boundary saves a second engagement when the assessor arrives.
The European and Dutch frame in brief
In the European Union, hospitals and other healthcare providers fall under NIS2 (Directive (EU) 2022/2555), where the health sector is listed in Annex I and large hospitals are essential entities subject to the strictest supervision. Article 21(2) requires risk-management measures that include policies for assessing the effectiveness of those measures, which supervisors read as regular security testing. In the Netherlands NIS2 is transposed through the Cyberbeveiligingswet, and the healthcare sector additionally works to NEN 7510:2024 for information security management, with NEN 7512 for secure exchange and NEN 7513 for access logging; NEN 7510 expects independent technical testing of systems that process patient data. Medical devices sold in the EU follow the Medical Device Regulation (EU) 2017/745, whose Annex I general safety and performance requirements oblige manufacturers to design software to the state of the art for IT security, with the MDCG 2019-16 guidance describing how cybersecurity, including security testing, should be demonstrated. Our NIS2 guide covers the directive's testing expectations across sectors.
The healthcare attack surface
Six domains, each with its own protocols, failure modes and testing constraints.
EHR and EMR platforms
The electronic health record is the crown jewel and the integration hub. We test role-based access across clinical, administrative and break-glass roles, audit logging, interface engines, reporting and data-warehouse exports, and the single sign-on and context-sharing layers that connect the EHR to hundreds of departmental systems.
Patient portals and telehealth
Internet-facing applications where a patient (or an attacker with a patient account) can reach records, appointments, messaging and payments. Authorisation between patients and proxies (parents, carers), identity verification at enrolment, and the APIs behind mobile apps are the common weak points.
HL7 v2, FHIR and DICOM interfaces
HL7 v2 over MLLP is usually unauthenticated and unencrypted by design; a foothold on the network often means the ability to read or inject clinical messages. FHIR R4 APIs with SMART on FHIR need OAuth 2.0 scope and tenant checks tested like any API. DICOM and PACS servers exposed to the internet have leaked millions of imaging studies.
Medical devices and IoMT
Infusion pumps, patient monitors, imaging modalities and laboratory analysers, often running out-of-support operating systems with vendor default credentials. Tested passively and in agreed windows, never on a device connected to a patient, with the vendor's hardening guide as the baseline and network segmentation as the primary control.
Legacy OT and building systems
Building management, HVAC for operating theatres and pharmacies, badge access, nurse call and pneumatic tube systems. Frequently flat-networked, remotely accessible by the facilities vendor, and invisible to the security team's asset inventory until a test maps them.
Ransomware readiness
The path from a phished workstation or an unprotected remote-access portal to domain administrator and to the backup infrastructure. Active Directory, privileged access, remote access without MFA, vendor VPNs and backup immutability are tested as one chain, because that is how the incidents happen.
What each regulation or framework asks of your testing programme
A single well-scoped programme can produce evidence for all of them. The scope statement has to name each one.
| Framework | Who it binds | Testing expectation | Evidence the reviewer wants |
|---|---|---|---|
| HIPAA Security Rule (current) | Covered entities and business associates | Periodic technical evaluation (164.308(a)(8)); testing is the accepted method | Risk analysis, evaluation report, remediation tracking |
| HIPAA Security Rule (2025 proposed rule) | Same population | Vulnerability scans every 6 months, penetration test every 12 months (proposed) | Dated test reports, scan records, asset inventory and network map |
| HHS 405(d) HICP | Voluntary; weighs in OCR enforcement under Public Law 116-321 | Perimeter and internal penetration testing within vulnerability management practice | Twelve months of documented practice aligned to HICP |
| FDA Section 524B and premarket guidance | Manufacturers of cyber devices | Independent penetration testing as part of premarket cybersecurity testing; postmarket vulnerability plan | Test report, scope, tester independence and qualifications, SBOM |
| HITRUST CSF | Organisations seeking certification and their vendors | Independent external and internal penetration testing on a defined cadence | Reports scoped to the assessment boundary, remediation evidence |
| NIS2 / NEN 7510:2024 | EU hospitals and healthcare providers | Assessment of control effectiveness; independent technical testing | Test programme, reports, management review |
| EU MDR Annex I / MDCG 2019-16 | Device manufacturers selling in the EU | Security testing demonstrating state-of-the-art IT security | Technical documentation including test evidence |
What a hospital CISO should scope first
Budgets and testing windows are finite. This is the order we recommend when a health system has not tested comprehensively before.
- The external perimeter and every remote-access path: VPN, Citrix or virtual desktop gateways, vendor remote support tools, and whether each one enforces multi-factor authentication
- The internal network and Active Directory as an assumed-breach test from a standard clinical workstation: how far a phished user gets, and whether the path to domain administrator and to the backups is open
- The patient portal, telehealth platform and their mobile APIs, tested with patient and proxy roles
- The EHR's access model and its integration layer: interface engines, HL7 feeds, FHIR endpoints, and the service accounts that connect departmental systems
- A passive medical-device and IoMT inventory and segmentation assessment, before any active testing of devices in agreed maintenance windows
- PACS, DICOM and imaging infrastructure, which are frequently internet-exposed without anyone realising
- Third-party and vendor access: who can reach the network, through what, with what rights, and whether their access is logged
- Backup and recovery infrastructure: immutability, separation from the production domain, and whether a domain administrator can delete it
Testing safely in a clinical environment
The first rule is that no test may put a patient at risk. We never actively test a device that is in clinical use; device testing is done on spare units, in biomedical engineering workshops, or in vendor-agreed maintenance windows with clinical engineering present. Network scanning of clinical segments is rate-limited and scheduled, because some legacy devices fail when probed. Every engagement has a clinical escalation contact who can halt testing in minutes, and a rollback plan for any configuration change. The scope statement names the systems that are explicitly out of bounds and the windows for everything else.
The second rule is that findings must be usable by three audiences: the engineers who fix them, the compliance team that files them against HIPAA, HITRUST, NIS2 or NEN 7510, and the executives who decide what to fund. Each finding therefore carries technical reproduction steps, a mapping to the relevant control, and a plain-language statement of clinical and business impact. A missing tenant check on a FHIR endpoint and an unauthenticated DICOM server are both high severity; the report should make clear why, in terms a board understands.
How HackersHub tests healthcare organisations
Our healthcare engagements are led by OSCP-certified testers who have tested hospitals, health systems, laboratories, telehealth platforms and device manufacturers on both sides of the Atlantic. We scope to the regulations that bind you, test the perimeter, internal network and Active Directory as a single ransomware-path assessment, test patient-facing applications and FHIR APIs with clinical and patient roles, and assess medical devices and OT passively first and actively only under agreed conditions. Every report maps findings to HIPAA, HICP, HITRUST, FDA premarket expectations, NIS2 or NEN 7510:2024 as applicable, and comes with a retest and an attestation letter your assessor and your customers can rely on. Scope and effort are agreed in writing after a scoping call; we do not publish prices. Michael van Mameren leads the practice and signs every attestation.
Frequently asked questions
Scoping a testing programme for a hospital, health system or device?
A 30-minute scoping call maps your regulatory obligations to the systems that need testing and the order to test them in, with clinical safety constraints built into the scope. You receive a written proposal with named OSCP testers. Talk to an expert.