Hardware Security in Medical Devices: What We Find in the Lab

Most medical device security conversations focus on software — APIs, authentication, encryption. But when a device arrives in our lab, the first thing we do is flip it over, open the enclosure, and look at the board. Hardware is where some of the most critical vulnerabilities live, and it's the attack surface manufacturers most often overlook.

This post walks through the hardware security issues we see most frequently in medical device penetration tests.

Exposed Debug Interfaces

JTAG and UART ports are the most common hardware finding across every device class we test. These interfaces are used during development for programming, debugging, and diagnostics. The problem is they're often left enabled — and accessible — in production devices.

An exposed JTAG port gives an attacker direct access to the processor. From there, they can:

• Read and write flash memory
• Extract firmware for offline analysis
• Bypass authentication entirely
• Modify device behavior in real time

UART is similarly dangerous. We routinely find devices that drop into a root shell over UART with no authentication. On a patient monitor or infusion pump, that's a direct path to modifying dosage parameters or disabling alarms.

What manufacturers should do

• Disable JTAG and UART in production firmware (fuse-based disable is strongest)
• If debug interfaces must remain for field servicing, require authentication before granting access
• Don't assume physical access is unlikely — devices are shipped, stored, serviced, and sometimes returned

Unencrypted Flash Storage

We extract flash storage on nearly every device we test. On about half the devices we see, the contents are completely unreadable without decryption — which is good. On the other half, we find:

• Firmware images stored in plaintext
• Hardcoded credentials (Wi-Fi passwords, API keys, default PINs)
• Patient data or configuration files with no encryption
• Private keys for TLS or code signing stored alongside the firmware

If an attacker can desolder the flash chip (or read it via SPI/I2C without desoldering), they have everything they need to reverse-engineer the device, clone it, or extract secrets.

What manufacturers should do

• Encrypt firmware at rest using a hardware-backed key (TPM or secure element)
• Never store credentials or keys in flash alongside firmware
• Use secure boot to verify firmware integrity before execution
• Consider anti-tamper mechanisms that detect physical intrusion

Insecure Boot Processes

Secure boot is the chain of trust that verifies each stage of the boot process — from bootloader to OS to application. When it's missing or improperly implemented, an attacker who can modify the firmware (via flash extraction, JTAG, or a compromised update) can make the device run arbitrary code.

We test secure boot by:

1. Extracting the firmware
2. Modifying a non-critical component (like a startup banner or log message)
3. Re-flashing the modified firmware
4. Observing whether the device boots normally or rejects the modification

A surprising number of devices boot the modified firmware without complaint.

What manufacturers should do

• Implement a hardware root of trust (e.g., secure element that holds the signing key)
• Verify every stage of the boot chain cryptographically
• Use code signing for all firmware images
• Ensure the bootloader itself cannot be modified without hardware-level access

Exposed Test Points and Components

Beyond JTAG and UART, we look for other test points and exposed components on the PCB:

• SPI/I2C buses that allow direct read/write to flash, EEPROM, or sensors
• Unpopulated headers that were used in development and can be soldered to restore debug access
• Labeled silk screen that identifies components, bus lines, and test points by name — this saves an attacker hours of reverse engineering
• Removable storage (SD cards, USB ports) that may contain logs, configurations, or firmware update mechanisms

These aren't always critical on their own, but they lower the barrier to exploitation significantly. An attacker who can identify the SPI flash chip and its pinout from the silk screen can extract firmware in minutes.

What manufacturers should do

• Remove or obfuscate silk screen labels on production boards
• Depopulate unnecessary headers and test points
• Disable external storage interfaces that aren't required for clinical use
• Implement access controls on any interface that remains exposed

Side-Channel Vulnerabilities

Side-channel attacks are less common in our standard assessments, but we test for them when the device handles sensitive operations — particularly cryptographic key management and authentication.

The most practical side-channel attacks we perform:

• Power analysis: Monitoring power consumption during cryptographic operations to extract keys
• Timing attacks: Measuring response times to infer information about PIN validation or authentication checks
• Electromagnetic emanation: In some cases, electromagnetic emissions from the processor can leak information about internal operations

These are advanced attacks, but they're well within the capability of a motivated adversary targeting a high-value medical device.

What manufacturers should do

• Use constant-time comparison functions for PIN and password validation
• Implement cryptographic operations in hardware (secure elements) rather than software
• Consider shielding for devices that process highly sensitive data

The Physical Access Assumption

The most common pushback we hear from manufacturers is: "An attacker would need physical access to the device, and that's unlikely in a clinical setting."

This assumption is wrong for several reasons:

• Devices are shipped through supply chains where they can be intercepted
• Devices are returned for servicing and may pass through untrusted hands
• Some devices are used in home settings with minimal physical security
• The FDA doesn't accept "physical access is unlikely" as a mitigation — they expect you to test for it

Our reports always include physical attack vectors because the FDA's premarket cybersecurity guidance explicitly requires manufacturers to consider them.