Healthcare runs on systems that cannot go down and data that cannot leak. A hospital cannot take its EHR offline for a security test, a medical device cannot be fuzzed while it is attached to a patient, and a breach of protected health information carries regulatory consequences that most industries never face. Healthcare penetration testing is the discipline of finding real attack paths inside those constraints.
Why healthcare is targeted more than most industries
Health records are worth more to attackers than credit card numbers. A card gets cancelled in hours; a medical record contains a permanent identity , name, date of birth, Social Security number, insurance details, and clinical history , that can be used for insurance fraud and identity theft for years.
Combine that value with three structural weaknesses and you have the sector’s risk profile:
- Legacy systems that cannot be patched. Imaging equipment and clinical devices often run operating systems years past end-of-life because the vendor certified that exact configuration.
- Enormous third-party exposure. Billing services, transcription vendors, telehealth platforms, and cloud EHRs all touch patient data. Every business associate is an attack path.
- Availability outranks everything. In a hospital, uptime is a patient-safety issue, which makes maintenance windows scarce and legacy systems sticky.
Ransomware operators understand all of this, which is why healthcare remains one of the most attacked sectors year after year.
What HIPAA actually requires
A point of confusion worth settling: the HIPAA Security Rule does not name “penetration testing” as a required control. What it requires is a risk analysis (§164.308(a)(1)(ii)(A)) and periodic evaluation (§164.308(a)(8)) of your technical safeguards.
In practice, penetration testing is how organizations satisfy both. A risk analysis built on assumptions is an opinion; one built on tested evidence is documentation you can defend. Auditors, cyber insurers, and enterprise partners increasingly expect that evidence, and the HHS Security Risk Assessment guidance points firmly toward technical testing as the way to produce it.
If you are pursuing HITRUST, testing is explicit rather than implied, and the scope must cover the systems in your certification boundary. Our HIPAA penetration testing page covers how findings map to the Security Rule for evidence purposes.
Defining the scope: follow the ePHI
Scope is driven by one question , where does electronic protected health information live, move, and rest? That usually means:
Clinical systems , the EHR/EMR platform, PACS and imaging systems, laboratory information systems, and the interfaces between them. HL7 and FHIR interfaces deserve particular attention: HL7 v2 was designed for trusted internal networks and often carries no authentication or encryption, while modern FHIR APIs introduce standard API risks (broken object-level authorization, over-permissive scopes) to clinical data.
Patient-facing systems , portals, telehealth platforms, scheduling, and payment flows. These are internet-facing, handle ePHI, and are frequently the highest-value target in a healthcare estate.
Infrastructure , the internal network, segmentation between clinical and corporate VLANs, Active Directory, remote access, and the cloud environments hosting any of the above.
Business associates , anything a vendor operates on your behalf that touches ePHI. You cannot test their systems without written authorization, but their exposure is your regulatory problem, which is why business-associate agreements and vendor assessments matter.
Medical devices , infusion pumps, monitors, imaging equipment. This requires specialist care (see below) and is usually scoped separately.
Testing without disrupting care
This is the part that separates healthcare testing from any other engagement. A test that degrades a clinical system is not an inconvenience , it is a patient-safety incident. Professional healthcare penetration testing manages that risk explicitly:
- Test in a staging or mirrored environment wherever a production system supports patient care directly. For EHRs, this is standard practice.
- Agree exclusion rules in writing , no denial-of-service testing, no automated fuzzing of clinical devices, no aggressive scanning of biomedical VLANs during operating hours.
- Schedule around clinical operations, with a named clinical contact reachable throughout.
- Define a stop condition and escalation path before testing begins, so any sign of instability halts work immediately.
- Report critical findings on discovery, not at the end of the engagement. If a tester reaches ePHI on day one, you should know on day one.
A firm that will not discuss these constraints in detail during scoping has not tested healthcare environments before.
What a healthcare test typically finds
Across healthcare engagements the recurring themes are consistent:
- Flat networks , clinical devices, workstations, and corporate systems on the same segment, so a single phished workstation reaches imaging equipment.
- Broken access control in patient portals , the classic being a record identifier in a URL or API call that returns another patient’s data when changed. This is a HIPAA breach in one request.
- Unauthenticated HL7 interfaces reachable from the general network.
- Default and shared credentials on devices and clinical applications, often documented in vendor manuals that are public.
- Legacy protocols and unsupported operating systems on biomedical equipment.
- Excessive access rights , staff and service accounts able to reach far more patient data than their role requires.
- Cloud storage exposure , backups, imaging archives, or exports sitting in misconfigured buckets.
Medical device testing is a separate discipline
Testing a connected medical device is closer to hardware penetration testing than application testing: firmware analysis, hardware interfaces, wireless protocols, and the device’s backend communications. FDA premarket cybersecurity guidance now expects manufacturers to demonstrate this kind of testing, and health systems increasingly ask for it during procurement. It should be scoped, budgeted, and executed separately from a network or application assessment.
How often, and what it costs
Annually at minimum, plus after any significant change , a new EHR module, a telehealth launch, a merger that joins two networks, or a major cloud migration. Organizations under HITRUST or with cyber-insurance requirements often test more frequently, and many run quarterly external vulnerability scanning between annual tests.
Cost follows scope, not the word “healthcare.” A focused patient-portal test sits at the lower end of typical penetration testing pricing; a full estate covering EHR, internal network, and segmentation validation is a larger engagement. What should not vary is that the report maps findings to the Security Rule safeguards your compliance team has to evidence.
Choosing a partner
Beyond the normal criteria for choosing a penetration testing company, healthcare adds three requirements:
- Willingness to sign a Business Associate Agreement. If testing could expose the tester to ePHI, a BAA is not optional.
- Demonstrated healthcare experience, specifically with clinical systems and the operational constraints above.
- Reporting that maps to the HIPAA Security Rule, so the output is evidence your compliance officer can file rather than a technical document that needs translating.
The short version
Healthcare penetration testing is ordinary offensive security performed under extraordinary operational constraints. The technical findings , broken access control, flat networks, legacy systems, excessive permissions , are familiar. What is different is that the scope follows ePHI, the testing must never threaten care delivery, and the report has to function as regulatory evidence.
If you handle patient data and need testing that respects clinical operations while producing evidence your auditors accept, scope a HIPAA assessment and we will build the engagement around your environment.
Written by
Invadel Team
Senior penetration testers writing from real engagements — the same team that scopes, tests, and reports for our clients. About Invadel →