Medical Device Pen Testing: FDA vs EU MDR 2026

Published July 10, 2026

Read the pillar guide: For the fundamentals of medical device penetration testing including scope, methodology, and FDA report elements, see Penetration Testing for Medical Devices. This post is the FDA vs EU MDR comparison companion.

At-a-glance comparison

Why this matters

Dual-market manufacturers usually do not need two penetration tests simply because they have two submission destinations. They need a test scope that covers the device system, evidence that demonstrates what happened, and references that let each reviewer find it.

We separate those tasks early. First, establish the attack surfaces and security requirements. Then test them. Only then does the submission format become useful. Starting with a report template and filling it with scanner output gets the order wrong.

The FDA's final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Feb 3, 2026), names penetration testing in §V.C and specifies five report elements. The EU MDR, Regulation (EU) 2017/745, does not name penetration testing. Its expectations come through Annex I §17.2 and §17.4, MDCG 2019-16, and standards such as EN IEC 81001-5-1:2022.

Both approaches require evidence beyond a security claim. In the FDA letters we reviewed for our September 2026 MTEC webinar, one letter challenged nine different controls because the descriptions stayed at the principle level. Naming TLS 1.2 without cipher suites, or ECDSA without the curve and hash function, leaves the reviewer unable to assess the implementation. A penetration test needs that same specificity: which control, which configuration, which test, and which result.

What the FDA prescribes: the five report elements

Section V.C of the February 3, 2026 guidance sets out the report expectations. For a "cyber device" under Section 524B(c) of the FD&C Act, manufacturers preparing a 510(k), De Novo, PMA, PDP, or HDE should make these five elements easy to locate:

1. Testers' independence and technical expertise. Name the testers, document their credentials and relevant experience, and explain their separation from the development team.
2. Scope. Identify tested interfaces, excluded interfaces, and the rationale for exclusions. Trace the scope to the threat model.
3. Duration. Record the actual testing effort, including tester-days by phase, rather than only the engagement's calendar dates.
4. Methods. Name the frameworks and tools used, such as OWASP MASTG, PTES, or NIST SP 800-115. Explain the techniques applied to each interface.
5. Results. Include findings, severity ratings, reproduction steps, supporting evidence, retest status, and the final residual risk statement.

Scope is where we look first. In the FDA letters reviewed for our September 23, 2026 MTEC webinar, testing deficiencies included omitted bridging components or local agents, missing tester independence, and attempts to substitute vulnerability scanning for penetration testing. A scan identifies known vulnerabilities. A penetration test investigates whether an attack path works and what it allows an attacker to do.

Missing report elements can lead to an Additional Information request. Their presence alone does not establish that the testing was adequate. For the report structure, see our FDA penetration testing requirements guide.

How EU MDR reaches penetration testing

The MDR does not use the term "penetration test." We trace the testing obligation through three sources:

• Annex I §17.2 requires software devices to be developed and manufactured according to the state of the art, including lifecycle processes, risk management, and measures to ensure IT security.
• Annex I §17.4 requires manufacturers to set out minimum requirements for hardware, IT network characteristics, and IT security measures.
• MDCG 2019-16 §3.7 addresses verification of security requirements and testing of controls without prescribing one penetration testing report format.

Notified bodies use EN IEC 81001-5-1:2022, harmonised under the MDR through OJ 2024/1878, to assess supporting lifecycle evidence. Clause 5.7 addresses security testing, including vulnerability testing. The associated process standard, ANSI/ISA IEC 62443-4-1, includes Vulnerability Testing under SVV-3 and Penetration Testing under SVV-4.

The practical difference is the route to the evidence. For the FDA, we organize the report around explicit report elements. For the MDR, we also show how the testing supports the applicable security requirements and lifecycle activities. Neither route is satisfied by a list of tools with no results tied to the device.

Independence: documented third-party vs graded

The FDA expects evidence that the testers are separate from development. That can mean a third party or an internal team with documented organizational separation. We would not treat a vendor logo as proof of independence, or assume an internal team cannot qualify. The report needs names, qualifications, roles, and the separation statement.

EN IEC 81001-5-1 and IEC 62443-4-1 address independence by practice. Internal teams can meet the role-separation expectations when they are independent of the design and implementation under test. Notified bodies may accept internal red teams on that basis, including the separation defined for SVV-3.

For a dual-market report, document the arrangement once and map it to both expectations. State who designed the controls, who tested them, and how the testing function was separated. This is the part teams skip when they assume "third-party test" explains everything.

Where the evidence lives in each submission

For the FDA, place the penetration test report in the eSTAR cybersecurity attachment, identified here as STED §5.4 in eSTAR v7. The reviewer should be able to open the report and find all five elements without searching unrelated documents. Supporting references are useful; making the reviewer reconstruct the report is not.

For the MDR, reference the same report from the relevant technical documentation:

• Annex II §6.1, the verification and validation section.
• The ISO 14971 risk management file, including security risk work under AAMI TIR57 / ANSI/AAMI SW96:2023 or the emerging ISO 14971 amendment.
• The IEC 62304 software lifecycle documentation, cross-referenced to IEC 81001-5-1 clause 5.7 evidence.

We provide security testing evidence for those records, not the manufacturer's overall verification and validation activities.

Keep the report identifier, revision, tested software version, and finding identifiers consistent across references. The report does not need a European rewrite. It needs a usable table of references and evidence that matches the submitted device configuration.

Applicability triggers: cyber device vs any device with software

Section 524B(c) defines a cyber device through three criteria:

1. It includes software validated, installed, or authorized by the sponsor.
2. It can connect to the internet.
3. It contains technological characteristics that could be vulnerable to cybersecurity threats.

See also: FDA Penetration Testing Requirements, FDA Pen Test Requirements: Timing, Scope and Recency, and DAST vs Penetration Testing for FDA Submissions.

A device must meet all three for Section 524B to apply. Falling outside that definition does not remove the FDA's broader cybersecurity expectations, including those relevant to IDEs and other non-cyber devices.

The MDR has no equivalent cyber-device gate. Annex I §17.2 applies to devices incorporating electronic programmable systems and to software that is itself a device.

That difference matters for a standalone device with a wired serial port and no network stack. If it has no ability to connect to the internet, it falls outside Section 524B but remains within MDR §17.2. We check the complete connection path before making that determination. A lack of Wi-Fi or cellular hardware on the device does not, by itself, establish a lack of internet connectivity.

One report, both regimes: the mapping approach

We recommend three steps for a dual-market evidence package:

1. Use the FDA's five-element report structure. Document independence, scope, duration, methods, and results. Confirm that the tested interfaces match the threat model.
2. Add an "MDR/IEC 81001-5-1 Mapping" annex. Cross-reference specific report sections and test evidence to Annex I §17.2, §17.4, MDCG 2019-16 §3.7, and EN IEC 81001-5-1 clause 5.7.
3. Reference the controlled report from the EU records. Link it to the ISO 14971 risk management file and the IEC 62304 / 81001-5-1 lifecycle documentation.

The mapping must point to evidence, not just headings.

On a Class II wearable we tested, firmware updates arrived over BLE from a companion app. The bootloader checked a CRC but did not verify a cryptographic signature. We replayed a captured firmware image with a one-byte modification; the device installed it and rebooted into the modified firmware.

That finding is useful to either reviewer because it demonstrates an attack, not merely a suspected weakness. The recommended remediation was ECDSA P-256 signature verification before commit, a public key stored in a write-protected region, and a monotonic version counter for anti-rollback. The report package included reproduction evidence, patient-safety impact, ISO 14971 traceability, a CVSS v4.0 score, and a retest plan. A remediation recommendation is not evidence that the fix passed.

The mapping annex lets each reviewer follow that chain from requirement to finding to remediation status. It does not guarantee acceptance or eliminate the need for further testing if the scope was incomplete.

Side-by-side comparison

The FDA entry above refers to guidance, not regulatory text. Keep that distinction clear when documenting the basis for a requirement.

How Blue Goat approaches this

We test against the threat model, not a generic checklist. Our scope follows the device's interfaces and trust boundaries, including wireless links, companion applications, firmware update paths, and connected infrastructure where applicable.

Our reports connect findings to reproduction steps, security and patient-safety impact, risk ratings, recommended remediation, and the device's risk file. We distinguish an initial result from a retest result so the manufacturer can see what remains open.

For dual-market planning, we recommend the FDA's five-element structure with an MDR mapping annex. We also review whether the underlying evidence supports the references. Reformatting an incomplete test does not make it suitable for a second market.

See our medical device penetration testing services and the EU Cyber Resilience Act for medical devices service page. Scope, deliverables, retesting, and any deficiency-response support should be agreed for the engagement rather than assumed.

FAQ

Are FDA and EU MDR penetration testing requirements the same?

No. The FDA specifies five report elements in its Feb 3, 2026 guidance §V.C. The EU MDR does not name penetration testing directly. Its testing expectations come through Annex I §17.2, §17.4, MDCG 2019-16 §3.7, and EN IEC 81001-5-1:2022 clause 5.7. We can reuse evidence, but the submission references and regulatory basis differ.

Can one penetration test report serve both an FDA submission and an EU MDR technical file?

Yes, if the scope and evidence address both sets of expectations. We recommend the FDA's five-element structure plus an annex mapping report sections to Annex I §17.2/§17.4, MDCG 2019-16 §3.7, and EN IEC 81001-5-1 clause 5.7. A report prepared only around MDR references may need more detail to meet FDA report expectations.

Does the EU MDR require an independent third-party tester?

Not explicitly. EN IEC 81001-5-1 and ANSI/ISA IEC 62443-4-1 allow practice-specific, graded independence. Internal teams can qualify when they meet the relevant separation from design and implementation, including SVV-3 role-separation expectations. The FDA likewise allows an internal team when organizational separation is documented; an external tester is not the only option.

Where does the penetration test report go in an eSTAR submission?

Place it in the cybersecurity attachment, identified as STED §5.4 in eSTAR v7 for the Feb 2026 guidance. Keep the five report elements together and use precise references for supporting evidence. We avoid making a reviewer search several files to establish scope, independence, or results.

Is my device inside scope for FDA cybersecurity requirements if it has no network connection?

Not under Section 524B if it genuinely cannot connect to the internet and therefore fails the cyber-device definition. Check indirect connection paths before reaching that conclusion. Non-cyber devices can still face general cybersecurity expectations from the FDA. Under the EU MDR, Annex I §17.2 applies to software and programmable electronic systems regardless of internet connectivity.

What standards do notified bodies cite for EU pen testing evidence?

Notified bodies use EN IEC 81001-5-1:2022, harmonised under the MDR through OJ 2024/1878. Clause 5.7 addresses security testing. The associated ANSI/ISA IEC 62443-4-1 practices include SVV-3 for vulnerability testing and SVV-4 for penetration testing. MDCG 2019-16 §3.7 provides guidance on security verification and testing.

Final thoughts

Do not commission separate "US" and "EU" tests just to produce different covers. Start with one scope that reflects the device system and its threat model. Document the FDA's five report elements, then map the evidence into the MDR technical file.

Separate engagements can duplicate cost and leave conflicting findings or remediation statuses to reconcile. One controlled report avoids that duplication when the testing actually covers both needs. If an interface was omitted or a fix was never retested, address the evidence gap before working on the crosswalk.

Need a gap check? Use our Medical Device Pen Test Requirements gap check to discuss your report and submission needs, including Section 524B, the Feb 2026 guidance, EN IEC 81001-5-1, and MDCG 2019-16. Confirm the review scope, turnaround, and fees before proceeding.

Related reading: FDA penetration testing requirements for medical devices, EU MDR vs FDA cybersecurity crosswalk, IEC 81001-5-1 security risk assessment guide, Penetration testing for medical devices guide, and DAST vs penetration testing for FDA medical devices.