Common Vulnerabilities We Find in Connected Medical Devices

Every medical device is different, but the vulnerabilities we find are surprisingly consistent. After testing devices across every major category — infusion pumps, patient monitors, imaging systems, wearables, implantables, and diagnostics — clear patterns emerge.

These are the findings that show up in the majority of our penetration test reports. If you're building a connected medical device, this is your checklist of what to get right before your FDA submission.

1. Default and Hardcoded Credentials

The single most common finding. It takes many forms:

• A default admin password that ships with the device and is documented in the user manual (or worse, not documented but trivially guessable)
• A hardcoded service account password embedded in the firmware binary
• A shared Wi-Fi password used across every unit of the same device model
• API keys or tokens baked into the companion app or firmware

Why it matters: An attacker who knows the default password for your device model can access every deployed unit. For devices that control drug delivery or life support functions, this is a patient safety issue.

The fix: Unique per-device credentials generated during manufacturing. Force password changes on first use. Never embed secrets in firmware or companion apps — use secure provisioning.

2. Unencrypted Communications

We consistently find devices that transmit sensitive data without encryption:

• Patient vitals sent over BLE in plaintext
• Device configuration commands transmitted over unencrypted HTTP
• Firmware updates delivered without TLS
• Telemetry data sent to cloud backends over unprotected channels

Why it matters: An attacker on the same network (or within wireless range) can intercept patient data, modify device commands, or inject malicious firmware updates.

The fix: TLS 1.2+ for all network communications. Application-layer encryption for BLE. Signed and encrypted firmware update packages. No exceptions for "internal" or "local" traffic — the FDA doesn't distinguish.

3. Missing or Broken Authentication

Even when devices have login screens, the authentication is often bypassable:

• Authentication checked on the client side (companion app) but not enforced on the device itself
• API endpoints that accept commands without verifying the caller's identity
• BLE GATT characteristics that allow read/write without pairing or application-layer auth
• Session tokens that don't expire or can be reused across devices

Why it matters: If an attacker can send commands to your device without authenticating, they can control it. The authentication needs to be enforced on the device, not just in the app.

The fix: Server-side (device-side) authentication for every command and data access. Mutual authentication between device and companion app. Session tokens with expiration and rotation. Don't trust the client.

4. Insecure Firmware Update Mechanisms

Firmware updates are how manufacturers patch vulnerabilities after deployment. But the update mechanism itself is frequently vulnerable:

• Updates not cryptographically signed — the device accepts any binary
• Signature verification implemented but using a key stored in the firmware itself
• Updates delivered over HTTP, allowing man-in-the-middle substitution
• No rollback protection — an attacker can downgrade to a version with known vulnerabilities
• Update files not encrypted, allowing an attacker to reverse-engineer the firmware from an intercepted update

Why it matters: A compromised update mechanism is a persistent backdoor. An attacker who can push a malicious update controls the device indefinitely.

The fix: Cryptographic signature verification with keys stored in hardware (secure element or fused OTP). Encrypted update packages. Rollback protection (monotonic version counter). TLS for delivery. Verify the entire chain — not just the outer package.

5. Exposed Debug Interfaces

JTAG, UART, and SWD ports left enabled in production devices. We cover this in detail in our hardware security article, but it's worth listing here because of how common it is.

Why it matters: An attacker with physical access can extract firmware, read/write memory, and bypass all software security controls.

The fix: Disable debug interfaces in production (fuse-based disable is strongest). If they must remain for field service, require authentication.

6. Weak Bluetooth Low Energy (BLE) Security

BLE is the most common wireless protocol in medical devices, and it's consistently misconfigured. The most frequent issues:

• Just Works pairing mode (no authentication, no MITM protection)
• No application-layer authentication on top of BLE transport encryption
• Sensitive data transmitted without additional encryption
• Debug GATT services left active in production firmware

We have a full deep dive on BLE security testing if you want the details.

The fix: Use Passkey Entry or Numeric Comparison pairing. Implement application-layer authentication and encryption. Audit your GATT profile before submission.

7. Insufficient Input Validation

Devices that don't properly validate data from external sources — network packets, BLE writes, USB input, companion app commands, or configuration files. This leads to:

• Buffer overflows that crash the device or allow code execution
• Format string vulnerabilities
• Integer overflows that affect dosage calculations or sensor readings
• Command injection through unsanitized input fields

Why it matters: In firmware running on bare metal or an RTOS without memory protection, input validation bugs often lead directly to complete device compromise. And in a medical device, a corrupted calculation can harm patients.

The fix: Validate all external input at the boundary. Use safe string handling functions. Implement bounds checking on all numeric values, especially those used in clinical calculations. Fuzz test every input interface.

8. Inadequate Logging and Monitoring

Many devices have no security logging at all — no record of failed authentication attempts, configuration changes, firmware updates, or error conditions. This makes it impossible to detect attacks or investigate incidents.

Why it matters: The FDA expects manufacturers to have a post-market cybersecurity plan that includes monitoring. If your device doesn't log security-relevant events, you can't detect when something goes wrong — and neither can the clinical facility operating it.

The fix: Log authentication events (success and failure), configuration changes, firmware updates, and security-relevant errors. Store logs securely (don't allow users to modify them). Provide a mechanism for clinical IT to access security logs.

9. Lack of Network Segmentation Awareness

Devices that assume they're on a trusted network — accepting connections from any source, broadcasting services to all listeners, or trusting data from any device on the same subnet.

Why it matters: Hospital networks are complex, shared environments. Your device will coexist with hundreds of other devices, workstations, and IoT equipment. Assuming the network is trusted is assuming that every other device on that network is secure.

The fix: Authenticate all connections regardless of network origin. Don't trust data from other devices without verification. Support network segmentation — your device should work correctly behind a firewall with restricted access.

10. No Secure Boot

The device boots whatever firmware is present on flash storage without verifying its integrity or authenticity. We test this by extracting the firmware, modifying it, re-flashing the modified version, and observing whether the device boots normally.

Why it matters: Without secure boot, any attacker who gains write access to flash storage — through a debug port, a vulnerable update mechanism, or physical access — can permanently compromise the device.

The fix: Hardware root of trust with signature verification at every stage of the boot chain. Use a secure element to store signing keys. Ensure the bootloader itself is protected.

How These Findings Affect Your FDA Submission

Every vulnerability on this list maps to something the FDA asks about in their premarket cybersecurity guidance. If your submission doesn't address these areas — with either evidence that your device isn't vulnerable or documentation of how you've mitigated the risk — expect an ANIN letter.

The manufacturers who get through review on the first try are the ones who test early, remediate before submission, and document everything in terms of clinical impact.