12 Critical Findings from Medical Device Pen Tests

Free Pen-Test Guide · Updated 2026 · FDA-Aligned

A practical, ungated guide to the most common high- and critical-severity findings we surface in medical device pen tests, what each one looks like in the field, and exactly how to fix it before FDA or an attacker finds it first.

Our Pen Test Services · Readiness Checklist

By the numbers

• 250+, Submissions cleared
• 12, Most common findings
• 6-8 weeks, Full-scope engagement
• 0, FDA rejections

Why pen testing is now a gating activity, not a checkbox

FDA’s 2026 Premarket Cybersecurity Guidance and Section 524B make penetration testing an explicit submission element for cyber devices. Reviewers expect testing that exercises every interface, with a methodology that matches the device’s threat model, performed by testers who understand medical-device context. A narrow web-only report is now its own deficiency.

The patterns repeat. Across hundreds of medical device assessments, the same twelve findings show up again and again regardless of vendor, modality, or class. This guide walks through each one: what it looks like in the field, why it matters to patients and reviewers, and exactly how to fix it.

How to use this guide

• Read each finding as a self-assessment: have you tested for it on production hardware, not just dev kits?
• Use the checklist at the end to score your pen-test readiness before you scope an engagement.
• Where you find a gap, the fix list is concrete enough to start work on Monday.

What we find - and how to fix it

Every finding below is drawn from real medical device assessments. Each one is a potential FDA deficiency and a patient-safety risk.

1. Exposed debug and service interfaces (UART, JTAG, SWD)

Severity: Critical · Hardware / Firmware

What we see in the field

Production devices ship with active UART consoles, unfused JTAG/SWD headers, or vendor service ports that grant root or memory access with no authentication.

Why it matters

Physical-access attacks are explicitly in scope under FDA’s threat model expectations. An open debug port lets an attacker pull firmware, extract keys, or pivot to the patient network in minutes.

How to fix it

• Disable or fuse JTAG/SWD before manufacturing release; document the fuse state in production records.
• Authenticate or remove UART consoles; never leave a root shell on a production unit.
• Treat every physical interface as an attack surface in the threat model and pen test scope.

2. Firmware extractable and not encrypted at rest

Severity: Critical · Hardware / Firmware

What we see in the field

Firmware can be pulled from flash via SPI clip, debug interface, or update file, and decompiles cleanly to readable code, strings, and embedded credentials.

Why it matters

Once firmware is extractable in plaintext, every other control degrades: secrets leak, update logic can be reversed, and clones become trivial. FDA reviewers expect a documented firmware protection strategy.

How to fix it

• Enable secure boot and flash encryption on the MCU/SoC; verify it on production hardware, not just dev kits.
• Remove embedded credentials, API keys, and private keys from firmware images.
• Validate that update files are encrypted in transit and at rest where feasible.

3. Update mechanism without signature verification or rollback protection

Severity: Critical · Firmware / Update Path

What we see in the field

Firmware updates are accepted without cryptographic signature checks, signatures use weak keys, or downgrade attacks succeed against unpatched versions.

Why it matters

The update path is the single most dangerous interface on a connected device. An unsigned or downgrade-vulnerable updater turns one compromised endpoint into a fleet-wide incident.

How to fix it

• Enforce signature verification with a hardware root of trust; reject any unsigned image.
• Implement anti-rollback counters so older, vulnerable firmware cannot be reinstalled.
• Test the update path end-to-end including failure, interruption, and tampering scenarios.

4. Default, hardcoded, or shared credentials

Severity: Critical · Authentication

What we see in the field

Service accounts, BLE pairing PINs, web admin logins, or cloud API tokens are identical across every unit, or default passwords are never forced to change.

Why it matters

Hardcoded credentials are the #1 finding in connected medical device assessments and a frequent FDA deficiency. One leaked credential compromises the entire installed base.

How to fix it

• Generate per-device credentials at provisioning; store the root secret in secure element or TPM.
• Force credential rotation on first use for any user-facing account.
• Eliminate hardcoded API keys and certificates from firmware and mobile companion apps; use static analysis (SAST) to detect them.

Worried about hardware or firmware findings?

A 30-minute call with a senior tester can scope the right assessment.

Talk to an expert

5. Wireless stack misconfiguration (BLE, Wi-Fi, cellular)

Severity: High · Wireless

What we see in the field

BLE pairing uses Just Works, characteristics are world-readable/writable, Wi-Fi falls back to WPA2-PSK with shared keys, or cellular APNs lack mutual authentication.

Why it matters

FDA expects testing across every wireless interface with an appropriate methodology. Weak pairing or open characteristics let an attacker on the same RF range read patient data or control therapy.

How to fix it

• Use BLE LE Secure Connections with numeric comparison or OOB pairing; restrict GATT permissions.
• Require WPA2-Enterprise or WPA3 for Wi-Fi where the use environment supports it.
• Mutually authenticate cellular and cloud connections with device certificates, not shared secrets.

6. TLS implemented but not validated

Severity: High · Network / Cloud

What we see in the field

Device uses TLS but accepts any certificate, pins to an expired CA, supports deprecated ciphers (RC4, 3DES, TLS 1.0/1.1), or skips hostname verification.

Why it matters

A TLS connection that doesn’t validate the server is functionally cleartext to anyone on the path. Reviewers and pen testers both check this on every cloud interface.

How to fix it

• Pin to a defined CA or specific certificate; reject everything else.
• Enforce TLS 1.2+ with modern cipher suites; disable legacy protocols at the library level.
• Validate hostname, expiry, and revocation; fail closed when validation fails.

7. Cloud API authorization gaps (IDOR, missing tenant checks)

Severity: Critical · Cloud / API

What we see in the field

Authenticated users can access other patients’ data, devices, or organizations by changing an ID in the URL or request body.

Why it matters

Insecure direct object reference (IDOR) and broken tenant isolation are the most common findings in medical device cloud back-ends, and the most damaging when exploited.

How to fix it

• Enforce authorization on every endpoint; never trust client-supplied IDs without an ownership check.
• Add tenant scoping at the data layer (RLS, query filters) so a missing check fails closed.
• Cover IDOR explicitly in API pen testing with multiple test accounts across tenants.

8. Companion mobile app leaks secrets or weakens device security

Severity: High · Mobile

What we see in the field

iOS/Android app contains hardcoded API keys, ships in debug mode, lacks certificate pinning, or stores PHI in unencrypted local storage.

Why it matters

The mobile app is part of the device’s attack surface. A reverse-engineered app often hands an attacker the keys to the cloud back-end and every paired device. See the OWASP Mobile Top 10.

How to fix it

• Strip secrets from the app; use short-lived tokens fetched after authentication.
• Implement certificate pinning and runtime integrity checks; ship release builds only.
• Encrypt local PHI using platform keystores; clear sensitive data on logout and uninstall. Use SAST to catch secrets early.

Want a defensible pen test report FDA already recognizes?

We do fixed-fee engagements with medical-device specialists.

Our pen test services

9. Insufficient logging and tamper-evident audit trail

Severity: High · Monitoring / Post-Market

What we see in the field

Device and cloud lack logs for security-relevant events (auth, config changes, firmware updates), or logs can be modified or deleted without detection.

Why it matters

Without trustworthy logs you cannot investigate an incident, satisfy post-market monitoring expectations, or prove that a control worked. FDA’s post-market guidance assumes you can.

How to fix it

• Log authentication, authorization, configuration, and update events with timestamps and identifiers.
• Forward logs to an append-only sink; alert on gaps and integrity failures.
• Define retention aligned to incident response and regulatory needs.

10. Denial-of-service paths that affect patient safety

Severity: Critical · Availability / Safety

What we see in the field

Malformed BLE/USB/network input crashes the device, locks the UI, or forces a reboot mid-therapy; no watchdog or safe-state behavior.

Why it matters

A DoS on a medical device isn’t an availability nuisance - it’s a potential harm event. Reviewers expect both fuzz testing and a documented safe-state behavior under attack.

How to fix it

• Fuzz every external interface (BLE, USB, Wi-Fi, cloud APIs) and fix crashes, not just symptoms.
• Implement a watchdog and a defined safe state for unexpected faults.
• Tie DoS scenarios into the ISO 14971 risk file with documented mitigations.

11. Vulnerable third-party components with no monitoring plan

Severity: High · SBOM / Post-Market

What we see in the field

SBOM lists components with known CVEs, or there’s no process to learn about new vulnerabilities in the libraries shipped on the device.

Why it matters

Most exploitable findings in medical device pen tests come from outdated open-source components. FDA expects you to monitor them throughout the device lifecycle - not just at submission. Check NVD and CISA advisories.

How to fix it

• Scan the SBOM against NVD and vendor advisories on every build and on a recurring schedule.
• Define risk-based SLAs for triage and patching; document them in the post-market plan.
• Track end-of-life components and plan migrations before support runs out.

12. Pen test scope that misses real attack surface

Severity: Critical · Scope / Methodology

What we see in the field

Test report covers only the web interface or only the device, leaves out cloud APIs, mobile app, BLE, USB, or service tools, or relies on automated scanning alone.

Why it matters

FDA’s premarket guidance is explicit that testing must exercise the full system. A narrow report is a deficiency on its own, regardless of what the testing found.

How to fix it

• Scope across device hardware, firmware, wireless, cloud APIs, mobile companion app, and service tools.
• Combine manual exploitation with automated tooling; pure scans are not pen testing.
• Engage testers with documented medical-device experience and provide them the threat model.

Pen-Test Readiness Checklist

If you can’t check all twelve, you have known gaps a tester - or an attacker - will surface. Use this as a go/no-go before you book your assessment.

1. Debug interfaces (JTAG/SWD/UART) disabled or authenticated on production units

2. Secure boot and flash encryption enabled and verified on production hardware

3. Firmware updates signed, anti-rollback enforced, end-to-end tested

4. No hardcoded or shared credentials in firmware, mobile app, or cloud

5. BLE/Wi-Fi/cellular configured with strong pairing and mutual authentication

6. TLS 1.2+ with cert pinning and hostname/expiry validation across all endpoints

7. Cloud APIs covered for IDOR and tenant isolation with multi-account testing

8. Mobile app stripped of secrets, pinned, and storing PHI in platform keystores

9. Security-relevant events logged to an append-only, monitored sink

10. DoS and fuzzing scenarios tied to safe-state behavior and the ISO 14971 risk file

11. SBOM monitored against CVE feeds with risk-based patch SLAs

12. Pen test scope covers device, firmware, wireless, cloud, mobile, and service tools

Pen-Test Timeline Reality Check

Teams routinely underestimate how long a credible medical device pen test takes. Here’s what a full-scope engagement typically looks like for a moderate-complexity Class II connected device:

Note: Workstreams run partially in parallel. Most engagements complete in 6 to 8 weeks; rework after a critical finding typically adds 2 to 4 weeks of remediation and retest.

When to bring in a specialist pen-test partner

Not every test needs a specialist firm. You probably do need one if any of these are true:

• This is your first pen test cited in a 510(k), De Novo, or PMA submission.

• You’ve received an AI letter or RTA refusal citing pen-test scope or methodology.

• Your device has hardware, wireless, cloud, and mobile components and your last test only covered one of them.

• Your launch date is fixed and a critical finding would slip revenue.

• You need a report that FDA reviewers already recognize and accept without rework.

250+ submissions cleared · 0 FDA rejections

How Blue Goat Cyber Approaches Medical Device Penetration Testing

We run pen tests specifically for FDA-regulated medical devices - the scope, evidence format, and threat coverage reviewers actually want to see. Here is the model behind every engagement.

• Threat-model-driven scope. We ingest your STRIDE model and design documentation first, so the test targets the interfaces and data flows that map to declared risks - not a generic OWASP checklist.
• Full device attack surface. Firmware, hardware interfaces (JTAG/UART/USB), radios (BLE/Wi-Fi/cellular), cloud APIs, mobile companion apps, and clinician web portals - tested as one connected system.
• Independent testers. Our pen-test team does not also engineer your device. FDA reviewers increasingly expect this separation, and we run it as a default.
• Reviewer-ready deliverables. Every finding includes CVSS + FDA rubric severity, exploit narrative, reproduction steps, and remediation guidance mapped to AAMI TIR57 / ANSI/AAMI SW96:2023 hazards.
• Retest included. Fixing findings without a documented retest is a common deficiency trigger. Retest is part of the engagement, not an add-on.
• Timeline aligned to submission. We plan pen testing after design freeze but with enough runway to remediate and retest before eSTAR lock.

If you want a senior tester to scope your next pen test, our Medical Device Penetration Testing service is the entry point.

Frequently asked questions

Does the FDA require an independent penetration test?

Yes, in practice. The February 3, 2026 final premarket cybersecurity guidance expects penetration testing performed by a party independent from the development team, and the reviewer will look for evidence of that independence. Internal QA testing does not satisfy the expectation. The test can be a specialized outside firm or a formally partitioned internal team with documented independence.

How much of the pen test scope should come from the threat model?

All of it. The pen test scope is a direct derivative of the threat model: every high-risk threat entry should map to a test case in the pen test plan, and every pen test finding should map back to a threat model entry. Reviewers spot-check this traceability. Pen tests scoped without reference to the threat model consistently trigger deficiencies for coverage gaps.

What is the difference between vulnerability scanning and penetration testing for FDA purposes?

Vulnerability scanning is automated tooling that identifies known CVEs against a running system. Penetration testing is a scoped, human-driven exercise that attempts to exploit vulnerabilities under realistic attack conditions. The FDA expects both, but they satisfy different obligations: scanning supports postmarket monitoring, penetration testing supports premarket security assurance. Substituting one for the other produces a deficiency.

Do we need a pen test on every release, or only at submission?

Formal pen tests are typically required at initial submission and on material updates (new connectivity, new interfaces, significant architecture changes). Between submissions the manufacturer is expected to maintain continuous vulnerability scanning and to conduct additional penetration testing when the threat landscape or the device changes materially. The February 2026 guidance treats pen testing as a lifecycle activity, not a one-time deliverable.

How long does a defensible medical device pen test take?

Four to eight weeks end to end for a typical Class II connected device: one to two weeks of scoping and lab setup, two to four weeks of active testing, one to two weeks of reporting and remediation validation. Compressed timelines produce shallow findings that will not survive technical screening. Rushing pen testing is the single fastest way to a coverage deficiency.

What findings are most likely to block clearance versus be accepted with mitigations?

Findings that break the safety and effectiveness case (authentication bypass on a therapy-delivering device, arbitrary code execution on a clinical decision path) will typically block clearance until fixed. Findings on non-safety-critical paths (verbose error messages, TLS configuration weaknesses, outdated but non-exploitable libraries) can often be accepted with documented mitigations and a postmarket remediation timeline.

Want a senior tester to scope your next pen test?

Book a free 30-minute strategy session. No sales rep, no obligation. We’ll review your device, recommend the right scope and methodology, and give you a fixed-fee quote within 24 hours.

Related: FDA penetration testing requirements for medical devices - what the Feb 2026 guidance actually requires inside a pen test engagement, what stays separate as dev/CI work, and the 5 required report elements.

Also explore FDA premarket cybersecurity services, SBOM & lifecycle monitoring, and deficiency response support.