Regulatory-aligned penetration testing for medical devices
Penetration testing for a medical device is not the same as penetration testing for a web app or a corporate network. It's exploratory, adaptive, and threat-driven; modeled on adversary behavior, not checklists. The effectiveness of the test is measured by the evidence produced about what the device can be made to do that it shouldn't.
Our methodology was designed by people who helped write the regulatory guidance that defines what reviewers expect. We work alongside your team throughout the engagement, ensuring you're informed and contributing to the process from scoping through submission support.
Penetration testing is a specific discipline
Understanding what it is (and what it is not) helps ensure your engagement produces the evidence that regulators expect.
- It IS threat-drivenScope is developed from the manufacturer's hazard analysis and threat model, prioritizing the clinical effects the manufacturer most needs to investigate.
- It IS adaptivePenetration testing is modeled on adversary behavior, which is standards-defiant by nature. Until adversaries are constrained by checklists, penetration testing shouldn't be either.
- It IS NOT a compliance auditMeasuring against NIST, OWASP, or IEC produces a record of steps taken. Penetration testing produces evidence about what effects can be demonstrated.
- It IS NOT a pass or failFindings are inputs to the manufacturer's risk management process. Whether a finding represents acceptable or unacceptable risk is a clinical and business determination that belongs with the manufacturer.
Coverage areas include the physical device, software and firmware, the network, companion apps, and the cloud
Firmware and embedded systems
Reverse engineering, binary analysis, and identification of hardcoded credentials, cryptographic weaknesses, and authentication bypasses in embedded components.
Wireless protocols
Fuzz testing and protocol analysis across BLE, Wi-Fi, proprietary RF, Zigbee, and TCP/IP communication layers.
Cloud and API infrastructure
Assessment of cloud back-ends, companion apps, and API endpoints that connect to or control the device.
Hardware interfaces
Physical attack surface evaluation including debug ports, JTAG, UART, and removable storage.
Mobile and companion applications
Static and dynamic analysis of iOS and Android apps that interface with the device, including runtime manipulation and local data storage review.
Vulnerability chaining
Mapping the pathways, techniques, and conditions required to produce each finding, ensuring context is accurately described for regulatory review.
A five-step engagement from scope to regulatory support
- 1
Scoping and threat modeling
We identify exposure surfaces aligned to your device architecture, intended use, foreseeable misuse, and existing risk controls. The resulting test plan translates the scoping conversation into a documented agreement on what will be tested, why, and under what conditions. Your team reviews it for scope accuracy before testing begins.
- 2
Exposure surface mapping
We identify the device's input vectors: open ports, active protocols, radio frequencies, API endpoints, physical interfaces, and any other path through which external input reaches the device or its supporting systems.
- 3
Manual expert testing
Testers work through the interfaces, protocols, and components defined in the test plan using targeted manual techniques informed by the priority objectives. The test plan is a starting point, it does not constrain which techniques are applied or in what sequence. When a condition in one area opens a promising path in an adjacent area, the team follows it.
- 4
Reporting, remediation, and retest
We share preliminary results with your technical team to confirm factual accuracy before delivering the final report. The final report passes an independent review for evidentiary sufficiency: is the cause-to-effect chain documented, is it relevant to a genuine hazard or threat, and can each finding be reproduced from the steps as written? When findings require remediation, we provide a post-remediation testing addendum that documents whether each finding has been addressed, with evidence – giving regulators the test-remediate-test cycle they expect.
- 5
Regulatory support
After delivery, we support your team through the regulatory review process. That can include joining calls with reviewers to explain methodology, clarifying findings in written responses, or providing additional documentation to supplement the submission. We represent the testing performed, while your team can speak precisely to risk assessment, remediation decisions, and clinical significance.
Deliverables designed for someone specific to use
Test plan
Documented agreement on scope, objectives, and testing conditions. Referenced in the final report and suitable for inclusion in your quality documentation.
Regular testing updates
Routine updates during the engagement (such as via email, Slack, or Teams): where we are, what we've found, what we're doing next.
Preliminary technical briefing
Results shared within a week of testing completion for your team's factual accuracy review before the final report is compiled.
Cybersecurity test report
The primary deliverable, designed for regulatory scrutiny. Contains executive summary, scope, methodology, analysis, findings, and appendices.
Post-remediation testing addendum
Documents whether prior findings have been addressed, with evidence. Delivered within one week of retesting completion.
Letter of attestation
Provides third parties with evidence that testing was performed by independent experts, along with the disposition of outstanding cyber risks.
Deliverables are matched to the type of engagement and the specific needs of the client. They are designed to pass scrutiny of the intended audience, with output they can use and in language they'll understand.
Designed to be read by parties without full context
We design our deliverables as if they will be read by parties without full context, including regulatory reviewers looking for what is missing or experts retained to challenge the methodology or the conclusions. A finding is a documented behavior or effect in which a specific technique produced a specific condition, with evidence sufficient for an independent party to reproduce it. Every finding documents the methodology used, observed cause and conditions, and the resulting effect. This standard exists because penetration test reports may enter the regulatory record and the Medical Device File. The evidence standards, classification discipline, and writing conventions we follow are designed to produce reports that remain defensible under that level of scrutiny.