Medical Device Penetration Testing

We start with the device’s intended use and its risk profile. A device that delivers a drug dose has a different threat model than one that only displays a reading, so we map the functions where a compromise would harm a patient and prioritise those. This aligns with the safety risk management your quality system already runs, and it keeps the test focused on what matters clinically rather than on a long list of low-consequence noise.

We examine the physical device for exposed debug interfaces, extract and analyse the firmware for hardcoded credentials, keys and vulnerable components, and test whether secure boot and the update mechanism actually prevent a modified image from running. A device that accepts unsigned firmware is a device an attacker can reprogram, and on a therapy-delivering unit that is a patient-safety finding, not just a security one.

Connected devices talk over BLE, Wi-Fi or proprietary radio, and clinical systems talk HL7, DICOM and increasingly FHIR. We test pairing and authentication on the wireless links, attempt to intercept and inject commands, and probe the clinical protocols for tampering, replay and data exposure. Many devices trust any peer that can reach them, which is exactly the assumption an attacker exploits.

We assess how the device behaves on the hospital network, including whether it can be attacked laterally and whether it can be used as a pivot toward other systems. Where we find a real issue, we prove it on a test unit with reproduction steps, always stopping short of anything that could endanger a device in clinical use. You get the report within days, mapped to safety impact, with a live walkthrough and a free retest of the fixed device.

Service passwords, maintenance accounts and keys baked into the firmware, identical across every unit shipped, are a persistent finding. Extract them from one device and you have access to the entire fleet, including the back-end services the device authenticates to.

Wireless interfaces that pair without real authentication, or accept commands from any nearby transmitter, let an attacker in radio range interact with the device. Depending on the product, that can mean reading patient data, changing a setting, or interfering with therapy, which is the scenario that makes headlines, triggers recalls and erodes clinical trust in the product.

Devices that do not verify firmware signatures, or that allow rollback to a vulnerable version, can be reprogrammed by an attacker. Because medical devices stay in service for many years, an insecure update path is a long-lived risk that only grows as the underlying components age.

HL7 and DICOM were designed for trusted networks and often run without authentication or encryption. On a flat hospital network, patient data crosses in the clear and messages can be tampered with, altering records or imaging. We test these interfaces for exposure, injection and manipulation, and show where authentication and encryption need to be added without breaking interoperability with the systems the device already talks to.

Many devices run old operating systems and libraries that can no longer be patched easily, and are protected mainly by the assumption of a segmented network that hospitals do not always deliver. We identify the vulnerable components and test what an attacker achieves when that segmentation is absent, which is a realistic and common condition.

Under the EU Medical Device Regulation (MDR), cybersecurity is part of the essential requirements, and MDCG 2019-16 gives the specific guidance on how to meet it. We assess against IEC 62443 for the device as a system component, IEC 62304 expectations for the software lifecycle, and the connected-product baseline in ETSI EN 303 645 where it applies. The evidence slots into your safety and security risk management under ISO 14971.

For products heading to the US market, the FDA premarket cybersecurity guidance expects a security risk assessment, a software bill of materials, and evidence of security testing. Our deliverables, including an SBOM with reachable-CVE analysis, are structured to support that submission and the equivalent expectations of other regulators.

For devices already deployed, the results also support IEC 80001 on IT-network risk management for medical devices and inform the hospital’s own segmentation and monitoring. Where the device or its cloud handles patient data, we test with GDPR obligations firmly in mind.