.png){kind=logo}
In June 2026, the Medical Device Innovation Consortium (MDIC) released Validating Medical Device Cybersecurity Through Penetration Testing, a best-practices white paper produced by its Cybersecurity Working Group. FDA's premarket cybersecurity guidance tells manufacturers to include penetration testing in their submissions, but it does not spell out how to plan, resource, or document that testing. This document is the industry filling in those operational details.
If your team is preparing a 510(k), De Novo, or PMA for a connected device or Software as a Medical Device, this is a practical reference worth reading before you write your cybersecurity test plan. Below is what the paper says and what it means for developers.
The Core Reframe: Verification Versus Validation
The most useful idea in the document is a distinction that teams often blur. Security verification confirms that the controls you specified were implemented correctly. Penetration testing is a validation activity: it exposes the device to a skilled tester using the same tactics, techniques, and procedures a real attacker would use, to determine whether those controls actually hold up under real-world conditions.
The paper places penetration testing inside the Secure Product Development Framework (SPDF) as a post-development verification and validation step. It is careful to define what penetration testing is not. It is not an audit against a standard, not a comprehensive search for every possible issue, not a rigorous verification of security requirements, and not an evergreen result, since new vulnerabilities and techniques appear constantly. A penetration test builds confidence that an attacker focused on your device would find it hard to exploit and would likely move on to an easier target. It does not prove the device cannot be breached, because proving that negative is impossible.
The Five-Step Penetration Testing Lifecycle
The paper organizes the work into five sequential steps. Each one carries decisions that affect the quality and the regulatory usefulness of the result.
1. Scope the test
Scoping defines what the test will cover and how much device information the tester receives. Good scoping starts from the system architecture, the components (hardware, firmware, software, mobile apps, web apps, APIs), and the data sensitivity each component handles. Prior threat modeling and architectural analysis feed directly into this step. The paper highlights several inputs: established methodologies such as OWASP ASVS, the OWASP Top Ten, MITRE ATT&CK, MITRE EMB3D, and PTES; attack surface analysis; threat intelligence on the specific tactics attackers use against similar devices; intended use characteristics; and the real use environment, including connections to hospital EHR systems and exposure to ransomware on hospital networks. A recurring caution: do not use intended use or a narrow architecture assumption to shrink the scope unnecessarily.
2. Resource the testers
Penetration testing is a specialized discipline, and testing medical devices in their use environment is more specialized still. The paper advises vetting suppliers carefully through redacted sample reports, the qualifications of individual testers, and experience with regulated devices whose reports have been accepted by regulators. Expertise should match the device, covering cloud, wireless, web, mobile, firmware, and hardware as needed. The independence point is important and frequently misunderstood. IEC 81001-5-1 requires penetration testing to be performed by an "independent department or organization." Third-party testers are one way to achieve that, but the real requirement is sufficient independence from the development team, which larger organizations can sometimes meet with an internal team.
3. Execute the test
Execution depends heavily on the assessment approach. The paper frames this as Open Box (white box) versus Closed Box (black box) testing. In Open Box testing, the tester receives threat models, architecture documents, SBOMs, known vulnerabilities, and even source code. It yields more comprehensive coverage, fewer false positives, and faster discovery of business-logic and post-exploitation flaws, at the cost of realism. In Closed Box testing, the tester starts with minimal information, mirroring a real external attacker, which is more realistic but slower and more prone to false negatives in a time-boxed engagement. Many programs benefit from a mixed approach, especially for mature devices that have already been tested Open Box. Timing matters too: testing should happen on a production-equivalent build with security features in place, late enough to be meaningful but early enough to fix what is found.
4. Disposition the findings
Once the report is delivered, each finding moves through the organization's risk process, with responses of acceptance, avoidance, sharing or transfer, or mitigation, all documented in the Design History File. The paper stresses assessing findings in context (the same technical vulnerability can mean very different things in two devices), focusing on the level of access gained and the controls bypassed rather than only the specific effect the tester demonstrated, and translating the tester's ratings into the manufacturer's own QMS risk-rating system. This is also where penetration testing intersects with regulation across jurisdictions, including FDA premarket expectations, IMDRF N60, the EU MDR and MDCG 2019-16, and IEC 81001-5-1.
5. Communicate the results
Finally, results are communicated to regulators and to customers. FDA's premarket cybersecurity guidance is specific about what a penetration test report should contain: the independence and technical expertise of the testers, the scope, the duration, the testing methods, and the results, findings, and observations. If a third party performed the testing, FDA asks for the original third-party report, not a summary.
What FDA and Other Regulators Expect
The paper maps penetration testing to concrete regulatory references, which is where it becomes immediately useful for submission planning. FDA's guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, calls for penetration testing among its cybersecurity testing documentation and expects manufacturers to characterize findings and provide rationales for any not implemented or deferred. IMDRF N60 asks for technical security analyses and a traceability matrix between security risks, controls, and the testing that verifies them. The EU MDR requires verification and validation evidence in technical documentation, and MDCG 2019-16 names penetration testing as a primary validation method. IEC 81001-5-1, required in Japan and recognized elsewhere including the US, sets the independence expectations summarized above.
The Pitfalls the Paper Calls Out
Section 3 lists common mistakes, and several are worth internalizing because they show up repeatedly in real programs.
A vulnerability scan report is not a penetration test report. Scanners such as Nessus identify known vulnerabilities but do not demonstrate exploitability or impact. A bug bounty program does not replace penetration testing either, because you cannot control tester qualifications, time invested, or coverage. Penetration testing should not be used to cover security requirements verification, and verification testing should not be used to cover penetration testing, since the two answer different questions. Reports that only list what broke, without describing the techniques the device resisted, give a misleading picture of security posture. Testing should not run against production environments or real patient data. And testing should not be limited to unauthorized users; a patient with valid credentials attempting to reach another patient's data is exactly the kind of misuse worth simulating.
What This Means for Device Developers
This is not FDA guidance and it does not change any requirement. It is an industry consensus document, co-authored with FDA participants, that tells you how experienced product security teams approach a task FDA already expects. A few takeaways for product, quality, and regulatory leaders.
Treat penetration testing as validation, and plan it that way. Run your security requirements verification first, with your normal software verification team, so the penetration test is not catching basic implementation failures late in the process.
Build independence into your plan. Decide early whether you will use a third party or a sufficiently independent internal team, and be ready to defend that independence to a reviewer.
Start resourcing early. Qualified testers are in high demand and book out, and specialized skills such as embedded hardware or BLE testing are scarcer still. Late testing compresses your remediation window and raises costs.
Write the report for a reviewer. Capture the independence and expertise of testers, scope, duration, methods, and findings, and keep the original third-party report. Document disposition and traceability in the DHF.
Do not let scoping become a way to hide risk. Intended use and architecture assumptions inform scope, but FDA and the paper both warn against using them to narrow testing inappropriately.
The Bigger Picture
Medical device cybersecurity expectations have matured quickly, and the gap between "FDA wants penetration testing" and "here is how to actually do it well" has been a real source of friction for manufacturers. This MDIC paper, like the MITRE work published earlier in 2026, is the ecosystem closing that gap with practical, consensus guidance. For developers, aligning your cybersecurity validation approach with this thinking now is the cheapest way to avoid surprises during review.
For related reading, see our breakdown of MITRE's April 2026 medical device cybersecurity papers.
How Cosm Can Help
Cosm specializes in FDA regulatory and quality strategy for medical devices and Software as a Medical Device. If you are scoping cybersecurity testing for a premarket submission, building a penetration testing program, or deciding how to document and disposition findings in your DHF, contact us or visit www.cosmhq.com to discuss how we can support your submission strategy.
Disclaimer - https://www.cosmhq.com/disclaimer
