Penetration Testing Services › Medical devices

Medical device security

We test the whole product,
not just the box you ship us.

Penetration testing for medical devices and the systems around them — the device and its firmware, the companion app, the API it reports to and the portal your clinicians log into. When there is physical hardware, you ship it to us and it is tested in our lab.

Talk to us about your device What the FDA asks for

Who we do this for

Medical device manufacturers, pharmaceutical and life-science companies — from names whose devices are in every hospital you have heard of, to start-ups getting their first system through a submission.

And: Edwards Lifesciences · LTS · Asensus Surgical · MeMed · Ummanu · Levo Medical · FeelBetter · Syqe Medical · PathKeeper Surgical · Diagnostic Robotics · Vectorious Medical · MindTension · SoftWave · Mentiq Eye · GrayMatters Health · GiView · HeartTrends · Pulmone · Vuze Medical

The ecosystem

The device is the smallest part of the product

A modern medical device is one node in a system. It pairs with a phone over BLE, reports to a cloud API, and is administered from a portal your clinicians and your support team both log into. Test the device alone and you have covered the component with the smallest attack surface, and left every seam between the parts untouched.

Some of it is the hardware itself: across those engagements the single most common finding we report is a kiosk or lockdown breakout (13), and among the rest are outdated software components (6), unencrypted firmware and secrets hardcoded in source (5 each). But the ones that end up mattering are usually a hop away from the box — in the API that trusts the device, the app that pairs with it, and the portal behind both.

What that means in practice

One engagement across the whole product, scoped to what your system actually is rather than to a device checklist.

The device

Firmware extraction and reversing, secure boot and the update chain, debug interfaces (UART, JTAG, SWD, USB), local storage, the kiosk boundary, and the physical tamper paths.

Firmware extraction & reversing Exposed debugging interfaces Device application vulnerabilities

The radio link

BLE pairing and bonding, authentication and encryption at the characteristic level, replay and spoofing, plus Wi-Fi and cellular where the device carries them.

Network traffic testing Side-channel attacks

Companion mobile app

iOS and Android: data at rest, key material, the app's own API session, and the deep links other apps on the phone can reach.

Local data storage Mobile application testing

Cloud backend and REST API

Authorization, isolation between clinics and between patients, IDOR on patient and device identifiers, rate limits, and the device-provisioning path.

Authorization testing API penetration testing

Clinician and admin portal

Role separation, vertical and horizontal privilege boundaries, and what PHI a support account can reach that nobody intended it to.

Broken authorization Web application testing

The seams between them

The part nobody owns: a token minted by the app and trusted by the device, a device identifier that doubles as an API key, an update server anyone can reach. A device-only tester stops at one end and a web tester starts at the other, so this is the ground both of them walk past.

The full test catalogue

Our lab

Ship us the device

When there is physical hardware, it is tested in our lab. Categories we have worked on:

Smart infusion pump
Auto-injector
Patient monitor
Wearable
Aesthetics and laser
Inhalation and drug delivery
Sterilisation equipment
Surgical navigation
Telehealth and home diagnostics
Implant programmer
Diagnostic analyser

Hardware is tested on the bench: powered up, opened up and instrumented, with the companion app and the backend it talks to running alongside it. Tell us what the system is and we will tell you what we need shipped, and for how long.

Evidence

What device testing actually turns up

Numbers from our own engagement records, each one with the sample it came from.

30.4%of the findings we report on device engagements are high or critical250 findings · 50 device engagements · 2021–2026
15.7%across all our work, for comparison6,643 findings · 890 engagements · 167 organisations
1 in 4of the fixes we retest come back not actually fixed307 of 1,159 retests that reached a verdict · all project types

The limits, because they matter: our platform record opens in October 2021 and we were testing medical devices well before that, so these are floors rather than lifetime totals. And a scanner will find the outdated component and the missing header on a device just as it does on a web application — buying expert hours for those wastes them. What needs us is the firmware, the radio, the authorization model and the kiosk boundary.

What you get back

A report written for the person who fixes it

Reproduction steps, evidence, real impact and a concrete fix for every finding. Severity rated by what an attacker can actually achieve in your system, not by a scanner's default.

Submission-grade by construction

Structured against the five elements FDA guidance asks a penetration test report to contain, because where a third party does the testing the guidance says the manufacturer should provide the original report. It does not clear your device — the FDA reviews the whole submission, and a supplier who implies otherwise is selling.

The retest is part of the engagement

Every reported finding is verified against your fixed build. Not a change order, not a second project — part of the work.

How this fits an FDA submission

Tell us what the system is.

Send us the device, the app and the API it talks to — or just describe them and we will tell you what a real engagement looks like.

Talk to us Penetration testing services

We test the whole product,not just the box you ship us.