Healthcare Penetration Testing: EHR, API and Device Guide

Healthcare penetration testing is an authorized simulation of real attacks against the systems that store or move patient data and support clinical care. It covers EHR and clinical applications, patient portals and mobile apps, FHIR and HL7 interfaces, identity systems, cloud and telehealth services, third-party connections and, under strict safety rules, connected medical devices. The goal is to prove which weaknesses could expose protected health information or disrupt care, then give each owner a specific fix and retest it. Done well, it also produces evidence that supports HIPAA risk analysis without putting patients at risk.

What Is Healthcare Penetration Testing?

A penetration test goes beyond a vulnerability scan. Testers try to use weaknesses the way an attacker would, within an agreed scope, to show what could actually happen: a patient record read by the wrong person, a clinical system taken offline or a device network reached from the guest Wi-Fi.

In healthcare the same techniques apply, but the environment is different. Systems run around the clock, many devices are old and hard to patch, patient data flows through dozens of interfaces, and some assets are connected to patients. That changes what testers look at, how they test and what they are not allowed to touch.

If you are mainly asking whether the law requires a test, start with our HIPAA penetration testing requirements guide. This article focuses on how to test healthcare systems safely and usefully.

Why Healthcare Needs a Different Approach

Five things make healthcare testing harder than a typical corporate engagement.

Patient safety comes first. A test that crashes an infusion pump gateway or locks out clinicians during a shift can cause real harm. Safety rules shape the whole plan.
Patient data is everywhere. Electronic protected health information sits in EHRs, imaging archives, lab systems, billing platforms, backups, logs and integration engines.
Legacy technology is common. Imaging workstations and medical devices often run operating systems or software that cannot be patched quickly because of vendor support or regulatory constraints.
Interoperability multiplies entry points. FHIR APIs, HL7 interfaces, DICOM traffic and partner connections link systems that were built by different vendors.
Many third parties have access. Device vendors, EHR providers, billing companies and telehealth platforms often hold remote access or shared credentials.

For current figures on breaches and attacks in the sector, see our healthcare cybersecurity statistics.

What Is in Scope

A healthcare test usually spans several asset classes. Use this table to agree scope and to decide where safety limits apply.

Asset class	Examples	Main risks to test	How to test safely
EHR and clinical applications	EHR web and desktop clients, lab and pharmacy systems	Role and record-level authorization, session handling, injection	Use test tenants and synthetic patients
Patient portals and mobile apps	Scheduling, messaging, results, telehealth apps	Account takeover, viewing other patients' data, weak password reset	Staging or production with dedicated test accounts
FHIR APIs and interfaces	SMART on FHIR apps, partner APIs, HL7 v2 feeds, integration engines	Missing authorization per patient, excessive scopes, data leakage in search	Sandbox endpoints and synthetic records
Clinical workstations and thick clients	Nursing stations, imaging viewers, admin consoles	Stored credentials, local privilege escalation, shared logins	Lab images or non-clinical units
Medical devices and IoMT	Infusion pumps, monitors, imaging modalities, device gateways	Unpatched services, default credentials, unencrypted protocols	Spare or lab units with vendor involvement; never patient-connected devices
Imaging systems	PACS, DICOM nodes, viewers	Unauthenticated DICOM access, exposed archives	Off-hours windows, read-only checks
Identity and network	Active Directory, Entra ID, SSO, VPN, Wi-Fi, segmentation	Lateral movement from IT or guest networks to clinical zones	Agreed windows, no account lockouts
Cloud and third parties	Hosted EHR, telehealth platforms, vendor remote access	Misconfiguration, shared vendor accounts, over-broad remote access	Only with the provider's written permission

Eight asset classes in a healthcare penetration test, from EHRs to medical device networks

Testing FHIR APIs and Interoperability

FHIR is now the main way health data moves between apps, and HL7 is clear that FHIR does not secure itself. The specification's security page states that FHIR is not a security protocol and defers authentication and authorization to standards such as OAuth and the SMART App Launch framework, while offering the AuditEvent and Provenance resources for tracking access.

That means the security of a FHIR service depends on how each implementation applies those controls. A focused test checks:

whether tokens and scopes limit an app to the right patient and the right resource types
whether one patient's or clinician's token can read another patient's records by changing an ID
whether search parameters, _include and chained searches return records outside the caller's permission
whether bulk data export and administrative operations are restricted
whether access is recorded in audit events that the security team can actually review

Older HL7 v2 interfaces and integration engines deserve attention too. In many environments they rely on network position rather than application-level authentication, so testers check who can reach them and what an attacker could send or read from that position. Our API penetration testing guide covers general API methods in more depth.

Medical Devices: Hospital-Side vs Manufacturer Testing

Medical device testing means two different things depending on who is asking.

Manufacturers test devices before and after they reach the market. In the United States, section 524B of the Federal Food, Drug, and Cosmetic Act applies to "cyber devices": devices that include sponsor-validated software, can connect to the internet and have characteristics that could be vulnerable to cybersecurity threats. Sponsors must submit a plan to monitor, identify and address postmarket vulnerabilities, including coordinated vulnerability disclosure; maintain processes that provide reasonable assurance the device and related systems are cybersecure, with regular and urgent updates and patches; and provide a software bill of materials (21 U.S.C. 360n-2). The section took effect 90 days after the law's December 29, 2022 enactment.

The FDA explains what it expects in premarket submissions in its final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued in February 2026, which supersedes the June 2025 version. Industry groups such as the Medical Device Innovation Consortium have also published penetration testing best practices for manufacturers, covering scoping, execution, findings and documentation.

Hospitals and health systems do not usually test device firmware themselves. Their job is to understand how devices sit on the network and what an attacker could reach. A hospital-side test typically:

inventories connected devices and the services they expose
checks segmentation between IT, guest, clinical and device networks
looks for default credentials and unencrypted management interfaces on device gateways and servers
reviews vendor remote access paths
tests a spare or lab unit, with the manufacturer's agreement, when deeper device testing is needed

Comparison of manufacturer and hospital responsibilities in medical device security testing

Hospital-side testers should never run active tests against a device connected to a patient. For background on device risk, see our IoMT vulnerability statistics.

Clinical Safety Rules of Engagement

A healthcare test plan should be agreed with clinical engineering, IT operations and the privacy office, not only the security team. At a minimum, the rules of engagement should cover:

Excluded systems: patient-connected devices and life-critical systems are out of scope for active testing.
Testing windows: schedule high-impact activities outside peak clinical hours and agree change-freeze periods.
Stop conditions: define who can halt testing, how to reach them at any hour and which symptoms trigger an immediate stop.
Downtime readiness: confirm that downtime procedures and rollback plans exist before testing systems that support care.
Data handling: use synthetic patient records where possible, minimize any real PHI the testers see, and agree how evidence is stored, encrypted and deleted.
Contracts: put a business associate agreement in place when the provider may access PHI, and confirm written authorization from every system owner, including cloud and device vendors.

Our penetration testing scope guide explains how to turn these rules into a statement of work.

How Regulations and Frameworks Shape Healthcare Testing

Several rules and frameworks influence healthcare testing. They differ in who they apply to and whether they are mandatory.

Framework	Who it applies to	What it says about testing
HIPAA Security Rule	Covered entities and business associates	Requires risk analysis and periodic technical evaluation; does not currently name penetration testing. An HHS proposal would add annual penetration testing but is not final.
HHS Healthcare and Public Health Cybersecurity Performance Goals	Healthcare organizations (voluntary)	The enhanced goal "Cybersecurity Testing" includes penetration testing and attack simulation
HITRUST CSF	Organizations seeking HITRUST certification	Uses penetration testing as evidence for technical controls
FDA section 524B	Manufacturers of cyber devices	Requires vulnerability monitoring plans, cybersecurity processes and an SBOM in premarket submissions

The HHS goals are published on the HHS cybersecurity performance goals page, which describes them as a voluntary subset of practices. For HITRUST specifics, see HITRUST certification and penetration testing.

How a Healthcare Penetration Test Runs

A typical engagement follows seven stages.

Authorization and safety planning. Agree scope, exclusions, windows, stop conditions, contacts and data handling with security, IT, clinical engineering and privacy.
Discovery and data-flow mapping. Identify where PHI is created, stored and sent, including interfaces, integration engines and third parties.
External testing. Test internet-facing portals, APIs, VPNs, email and remote access.
Application and API testing. Test EHR modules, portals, mobile apps and FHIR endpoints with accounts for each role: patient, clinician, administrator.
Internal and segmentation testing. From an agreed starting point, test whether an attacker can move from user networks to clinical, imaging and device networks.
Device and workstation review. Check device gateways, management interfaces and clinical workstations within the safety limits agreed in stage 1.
Reporting and retest. Rank findings by likelihood, impact on patient data and impact on care, give a specific fix for each, then retest and record what was closed.

Common Findings in Healthcare Environments

The specifics vary, but these patterns appear often in healthcare assessments:

shared or generic clinical logins on workstations, which make actions hard to attribute
flat networks where medical devices and imaging systems can be reached from ordinary user subnets
legacy operating systems on devices and imaging workstations without compensating controls
DICOM services or imaging archives reachable without authentication
FHIR or portal APIs that check the user is logged in but not which patient they may see
vendor remote access accounts that are always on, shared or poorly monitored
weak password reset and account recovery flows in patient portals

Clinical workstation software is often a thick client, which brings its own risks. See thick client penetration testing for how those applications are tested.

Illustrative Finding: One Patient's Token, Another Patient's Records

The following example is illustrative and simplified; it does not describe a specific client.

A clinic's patient portal uses a FHIR API. A test patient signs in and opens their lab results, which the app loads by calling the API with that patient's ID. Using a second synthetic patient account, the tester changes the ID in the request. The API returns the other patient's results, because it checks that the token is valid but not that the token belongs to the requested patient.

Root cause: object-level authorization was missing in the API; the app relied on the user interface showing only the user's own records.
Impact: any portal user could read other patients' results, a PHI disclosure that would trigger breach analysis.
Fix: enforce patient-compartment checks on every request, limit token scopes to the signed-in patient, and alert on cross-patient access attempts.
Retest: repeat the request with the second account and confirm it is refused and recorded as an audit event.

How Often Should Healthcare Organizations Test?

A common baseline is to test critical systems at least once a year and after significant changes, such as a new EHR module, a new patient portal or app, a cloud migration, a merger, or new device networks. Base the schedule on your HIPAA risk analysis rather than a fixed calendar alone. Vulnerability scanning and configuration checks can run more often, while penetration tests validate whether the remaining weaknesses can actually be used.

What a Healthcare Pentest Report Should Include

A healthcare report has more readers than most: security, IT, clinical engineering, privacy, compliance and sometimes vendors. Make sure it includes:

the exact scope, dates, accounts, environments and any systems excluded for safety reasons
a data-flow view showing where PHI was reachable during testing
for each finding: evidence, affected systems, a severity rating with rationale, and separate notes on impact to patient data and impact to clinical operations
an owner for each fix, since many issues sit with device or EHR vendors rather than internal teams
confirmation of how any PHI seen during testing was handled and deleted
retest results showing which findings are closed, partly fixed or still open
a short summary that the privacy and compliance teams can use as input to the HIPAA risk analysis

Avoid reports that only list scanner output. The value of a penetration test is the validated attack path and the business context around it.

How to Choose a Healthcare Penetration Testing Provider

Ask any provider these questions before you sign:

How do you protect patient safety, and which systems will you refuse to test actively?
Will you sign a business associate agreement, and how do you handle any PHI you see?
What experience do you have with FHIR, HL7, DICOM and EHR platforms?
How do you test medical device networks without touching patient-connected devices?
What does your report include, and is retesting included in the engagement?
Who are the actual testers, and what are their credentials and healthcare experience?

Frequently Asked Questions

What is healthcare penetration testing?

It is an authorized simulation of attacks against healthcare systems such as EHRs, patient portals, FHIR APIs, identity systems, networks and, within strict safety limits, medical device networks. It shows which weaknesses could expose patient data or disrupt care and how to fix them.

Does HIPAA require penetration testing?

Not explicitly today. The HIPAA Security Rule requires risk analysis and periodic technical evaluation, and penetration testing is a common way to provide that evidence. HHS has proposed requiring annual penetration testing, but as of November 2026 that rule is not final.

Can hospitals penetration test medical devices?

Hospitals should not actively test devices that are connected to patients. They can test the networks, gateways and management systems around devices, and test spare or lab units with the manufacturer's agreement. Deep firmware testing is usually the manufacturer's responsibility.

What is a cyber device under FDA rules?

Under section 524B of the Federal Food, Drug, and Cosmetic Act, a cyber device is a medical device that includes sponsor-validated software, can connect to the internet and has characteristics that could be vulnerable to cybersecurity threats. Manufacturers of cyber devices must provide vulnerability monitoring plans, cybersecurity processes and a software bill of materials.

How do you test FHIR APIs safely?

Use sandbox endpoints and synthetic patient records, create test accounts for each role, and check that every request is limited to the right patient and scope. Avoid bulk operations against production data unless they are explicitly approved.

Why do hackers target healthcare?

Health records contain identity, insurance and medical details that are valuable for fraud, and hospitals are under strong pressure to restore systems quickly, which attackers try to exploit with ransomware. Complex networks, legacy devices and many third-party connections also give attackers more ways in.

Next Step: Plan a Safe Healthcare Penetration Test

Healthcare security depends on proving that controls hold up without putting patients or clinicians at risk. A well-scoped penetration test does both: it shows where patient data and clinical operations are exposed and gives each owner a fix to verify.

If you are planning a healthcare assessment, contact DeepStrike to discuss scope, safety rules and retesting, or review our penetration testing services.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.