Define what needs testing, the evidence you will receive, and the time your engineering team needs for fixes. We scope testing around your threat model, device version, and patient-safety risks, with a fixed fee agreed before work begins.
The short answer
Medical device penetration testing examines the attack paths across your device and its connected ecosystem. The agreed scope can include hardware, firmware, wireless, mobile apps, APIs, and cloud services. You receive a Test Plan, Test Cases, and Test Report with threat-model traceability and retest evidence. Choose standalone testing when your other cybersecurity documentation is in place, or the FDA Premarket Cybersecurity Package when you need the broader documentation and testing engagement. Scope, access, deliverables, and dates are agreed before testing.
275+ FDA submissions supported, zero cybersecurity rejections.
Trusted by leading MedTech companies
The scope of a connected-device test
We agree the device version, interfaces, test environment, access, and rules of engagement before work begins. Your threat model and cybersecurity hazard analysis determine the attack paths we test, not an asset count alone.
Firmware · stored keys · debug ports
Secure boot & signed updates
Bluetooth · Wi-Fi · pairing
Authentication & replay resistance
Local data · sessions · commands
Authorization & secure storage
APIs · accounts · update delivery
Access control & tenant isolation
Hardware and debug ports, firmware and update paths, BLE and Wi-Fi, companion mobile apps, APIs, web portals, and cloud services. Clinical protocols such as DICOM, HL7, and FHIR are included when relevant to your device and agreed scope.
Penetration testing includes dynamic, adversarial testing and the Test Plan, Test Cases, and Test Report. SAST, software composition analysis, SBOM work, and threat-model rework are scoped separately or bundled explicitly. This is security testing, not general software testing.
Unlimited retests until every finding with uncontrolled risk is closed. Risk disposition remains a documented manufacturer decision.
"Blue Goat Cyber's depth of expertise was impressive. We had no in-house cybersecurity experience, and their team guided us through every step of the FDA process. The penetration testing and SBOM testing were thorough and gave us complete confidence."
The FDA's February 3, 2026 guidance describes security requirement verification, threat mitigation verification, vulnerability testing, and penetration testing. We agree the applicable checks for your device and record exclusions. SAST, software composition analysis, and SBOM work are separate unless explicitly bundled.
The full stack a connected medical device exposes, from the clinician portal down to the implant firmware. Every layer is in scope when it matters to patient safety or regulatory submission.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
Your project manager coordinates access, testing, reporting, and engineering handoffs. The schedule separates our testing work from your remediation work.
We assign your project manager and confirm the scope, dates, device build, contacts, and rules of engagement.
We set up a private Slack channel and secure document shares.
We review the IFU, architecture, threat model, and cybersecurity hazard analysis. A light review is part of scoping; missing documentation or deeper rework is quoted separately.
We confirm device shipping or on-site arrangements, representative non-clinical units, test accounts, and environment access.
We run the agreed Test Plan against the identified device version and connected components.
You receive a tear sheet so engineering can begin remediation before the full report is complete.
We deliver the Test Plan, Test Cases, and Test Report with findings, reproduction evidence, and threat-model traceability.
Your engineers implement fixes. We retest and update the evidence, with unlimited retests until every finding with uncontrolled risk is closed. Risk disposition remains your documented decision.
A simple device starts at about $15,000, with a reasonable turnaround and no travel. You receive a fixed-fee quote within 24 hours of the scoping call. The quote identifies device versions, interfaces, deliverables, assumptions, and retest coverage.
Fixed fee after scoping
A defined surface or evidence gap. The report states exclusions; a targeted test does not represent coverage of an entire connected device.
Fixed fee after scoping
Testing across the device and the connected components identified by your threat model.
Fixed fee after scoping
The FDA Premarket Cybersecurity Package adds the agreed documentation and security activities beyond penetration testing.
SAST, software composition analysis, SBOM work, and threat-model rework are separate unless explicitly bundled. Changes to the agreed device versions or interfaces require a scope review.
How much does medical device penetration testing cost? Full breakdown
Every medical device penetration testing engagement produces evidence aligned to the regulatory and consensus standards FDA reviewers and notified bodies expect to see, traceable, complete, and ready to drop into your ISO 13485 quality system.
Recommends risk-based cybersecurity evidence, including threat modeling, architecture views, and testing. An SPDF is encouraged, not mandatory; Section 524B separately establishes statutory duties for covered cyber devices.
The consensus standard for medical device security risk management, asset, threat, vulnerability, likelihood, severity, and residual risk acceptability.
Foundational risk management standard. Cybersecurity risk is tied directly to patient-safety risk in the 14971 file.
Industrial-strength secure-development-lifecycle requirements applied to connected medical devices.
Reference methodology for planning, executing, and reporting security testing.
Recalls, CISA ICS-MA advisories, and disclosed research that shape what reviewers ask about, and what this engagement is built to cover.
Conexus RF protocol lacked encryption and authentication, allowing nearby attackers to read or modify implant communications. Drove industry-wide expectations on telemetry confidentiality and integrity.
Multiple advisories spanning auth bypass, hard-coded credentials, and improper input validation. Reinforced reviewer scrutiny of in-hospital network-exposed devices.
Improper auth between monitor and cloud allowed certain monitor functions to be impersonated. Demonstrates why home-monitor + cloud must be tested together, not separately.
Wi-Fi credential persistence and improper access control. Drove the FDA's continued focus on credential lifecycle and decommissioning in hospital-deployed devices.
Imaging device, PACS, or viewer? Answer these and get a one-page scoping sheet for your DICOM security test. Takes about two minutes.
Which DICOM services does it expose?
Pick everything the device answers on its DICOM port.
Which transfer syntaxes does it support?
What role does it play on the imaging network?
What sits in front of the DICOM port?
What test environment can you give us?
Please don't enter confidential details here.
We'll email you a link to book a free discovery call; the fixed-fee proposal follows the call. Want to try the protocol yourself first? Download the DICOM seed corpus and read the DICOM fuzzing guide.
Testing for a hospital, health system, or connected health product? See our healthcare penetration testing overview for how scope differs for healthcare organizations and medical device makers. For what the FDA expects around testing, read FDA cybersecurity requirements for medical devices.
Secure your Wi-Fi and wireless attack surface.
View Wireless Penetration TestingOne package for applicable FDA cybersecurity documentation, threat modeling, SBOMs, testing, and submission support.
View FDA Premarket Cybersecurity PackageGot an FDA hold or AI letter? We close cybersecurity deficiencies fast.
View FDA Deficiency ResponseSee how this service applies to your specific MedTech segment.
Curated reading for teams working on medical device penetration testing - grouped by format so you can jump to what you need.
Long-form reference reading, architecture, frameworks, and end-to-end how-tos.
Shorter posts on the specific gotchas, deficiencies, and reviewer expectations we see most.
Pressure-test the work yourself before you scope an engagement. No signup, results are yours to keep.
Define what needs testing, the evidence you will receive, and the time your engineering team needs for fixes. We scope testing around your threat model, device version, and patient-safety risks, with a fixed fee agreed before work begins.
You receive the Test Plan, Test Cases, and Test Report. Together they connect scope, execution, findings, and retests. A letter of attestation is not needed for FDA penetration testing.
Before testing
The agreed device build, environment, attack paths, methods, tools, schedule, rules of engagement, and tester independence. Scope is anchored to your threat model.
During execution
Test identifiers link threat scenarios and security requirements to methods, expected and actual results, and findings. Coverage and limitations remain visible.
Results and retests
Tester independence and expertise, scope, duration, methods, findings, reproduction evidence, remediation guidance, patient-harm context, and retest status. Unresolved findings and manufacturer risk disposition remain documented.
Your engineers implement fixes. We provide unlimited retests until every finding with uncontrolled risk is closed, within the agreed device versions and interfaces. Risk disposition and any residual-risk acceptance remain your documented decisions.
Choose based on the evidence you already have and the work still needed. Penetration testing is a defined security activity, not a complete premarket cybersecurity submission by itself.
For teams with a threat model, cybersecurity hazard analysis, and the other documentation in place, or teams closing a specific testing gap.
For teams that need the broader cybersecurity documentation and testing engagement coordinated together.
This is cybersecurity testing, not general software testing or software validation. Testing evidence does not establish regulatory acceptance.
We agree dates after reviewing the device, scope, and available inputs. A testing schedule must leave room for your engineers to fix findings and for us to retest. There is no universal completion window for every device.
Traceability
A CVSS score says how easy an attack is. It doesn't say whether a patient could be hurt. We link every finding to your threat model and hazard analysis, so its risk is rated in terms of patient harm and FDA reviewers can follow the chain from threat to fix.
Names the threats and attack paths. Each test case traces back to a threat.
Threat: an attacker nearby sends commands over Bluetooth without pairing.
Names what could hurt a patient if the device misbehaves (ISO 14971).
Hazard: the device delivers the wrong therapy setting.
What we proved during testing, tied to the threat it came from.
Finding: therapy settings can be changed over Bluetooth without authentication.
How easy the attack is, scored with CVSS.
Low skill needed, attacker must be within Bluetooth range.
Exploitability combined with the linked hazard's severity. This rating, not CVSS alone, sets priority.
Rated high: a wrong therapy setting can harm the patient.
The fix is verified in a retest, and the full chain goes into your FDA report.
Pairing and command authentication added, retest passes.
The example lines show an illustrative case, not a specific client engagement.
For medical devices, both Blue Goat and the FDA recommend white-box testing. Reviewers expect testers to leverage source, firmware, and threat models, black-box alone routinely leads to deficiencies.
| Capability | Black-box | Gray-box | White-box |
|---|---|---|---|
| Source code access | |||
| Firmware / binaries | |||
| Threat model & architecture | |||
| Authenticated test paths | |||
| Deep logic + business-flow flaws | |||
| Aligned with FDA expectations | |||
| Scope coverage per test-day |
Premarket guidance and consensus standards both expect testers to leverage source code, design artifacts, and threat models, not just an external view of the device.
Calls for security testing that demonstrates device resilience using design documentation, threat models, and source-level analysis, not black-box probing alone.
Requires sponsors to provide reasonable assurance that the device and related systems are cybersecure, which reviewers read as evidence-backed, white-box-informed testing.
Frames security testing as an output of threat modeling and architecture analysis. That is white-box by definition.
Postmarket monitoring and vulnerability handling assume testers have access to internals, the same access white-box pen testing uses premarket.
