One test campaign, two evidence packs: EU and US together

Why the work is the same

Strip the two regimes back to what they ask a tester to do and the overlap is close to complete. MDCG 2019-16 rev.1 chapter 3.7 names security feature testing, fuzz testing, vulnerability scanning and penetration testing as the methods of security verification and validation, and adds secure code analysis and open-source component scanning. Section V.C of the FDA guidance of 3 February 2026 asks for security requirements testing, threat mitigation testing, vulnerability testing described in ANSI/ISA 62443-4-1, and penetration testing.

Two lists, one activity set. What differs is the amount of writing each regime wants around it, and one substantive rule about who holds the pen.

The economics follow. A campaign against a connected device is dominated by setup: obtaining units and spares, standing up a representative backend environment, extracting and analysing firmware, building the tooling for a proprietary protocol. That cost is paid once. Running the same campaign twice for two regulators pays it twice and produces two reports that a careful reviewer would expect to say the same thing.

The one real difference: independence

The MDR says nothing about who performs security testing. Annex I point 17.2 requires verification and validation in accordance with the state of the art; Annex II section 6 requires the results and critical analyses of all verification and validation tests; MDCG 2019-16 chapter 3.7 names the methods. None of them addresses the tester.

The FDA does, in a paragraph that is worth reading twice. Manufacturers “should indicate in the test reports by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices”, and “in some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups, such that vulnerabilities or other issues revealed during testing are appropriately addressed”. Where a third party is used, “manufacturers should provide the original third-party report”.

The corollary matters for report design. If a third party performs the work, the FDA wants their document, not yours. Keeping that same document in the EU technical file, rather than a summary written afterwards by the regulatory team, means one artifact answers both reviewers and there is no second version to keep in sync.

The comparison, line by line

The same evidence, filed two ways

Evidence	EU · notified body	US · FDA 524B
Penetration test report	MDCG §3.7 names it as a method; §4.1 files the methods and results in the Annex II documentation	“Penetration test reports should be provided”, with five named elements
Tester independence	Not addressed in the MDR or MDCG 2019-16	First named report element; third parties may be necessary; the original third-party report must be provided
Scope, duration, methods, results	Covered generically by Annex II section 6: results and critical analyses of all verification and validation tests	Named individually as four of the five report elements
Threat model and architecture	Security risk management under MDCG §3.2 and §3.4, integrated with the device risk process	Four view types: global system, multi-patient harm, updateability and patchability, security use cases
SBOM	Not an Annex I requirement; component control sits inside the state-of-the-art argument	Statutory under 524B(b)(3): commercial, open-source and off-the-shelf, machine-readable, with support status
Detailed vulnerability testing	Fuzz testing, vulnerability scanning, secure code analysis and open-source scanning named in §3.7	Enumerated against ANSI/ISA 62443-4-1, from abuse cases to binary composition analysis
Operating environment	MDR 17.4 minimum IT requirements, with the MDCG §3.6 rule against compensating for device weaknesses	Carried in the security use case views and the labeling
Post-release cadence	Significant change plus post-market surveillance: “The technical documentation shall be updated accordingly” (Art. 83(3))	“At regular intervals commensurate with the risk (e.g., annually)”
Deferred findings	Handled through the security risk assessment and residual risk justification	Assessment of every finding, with rationale and a release plan for anything deferred

Scoping the single campaign

Scope from the strictest input available, which is usually the FDA architecture views, and check the result against the EU security risk assessment. The views already state what the manufacturer believes the boundaries are, and the guidance scales them with connectivity: a device with one hardware connection needs a single view of each type, while “networking, wireless connections, cloud, and/or commercial operating systems” push the count up and multiply the security use case views.

• Fix the build. One firmware version, one companion application version, one backend release. Every later document refers to that triple.
• List the interfaces. Radio, wired network, service and debug, removable media, and the backend APIs. Each becomes a scope line with an inclusion or an exclusion and a reason.
• List the roles. Patient, clinician, service technician, administrator, and, in a multi-tenant backend, a second tenant. Authorization findings only surface when a second identity exists.
• Take the supported configurations from the labelling. Annex II section 6.1(b) requires the software verification and validation information to address every hardware configuration and operating system identified in the information you supply, so the labelling sets the matrix.
• Bring the risk file. MDCG §3.2 keeps security risk management inside the device risk process; the controls it selected are what the campaign has to exercise, and the capability list in Table 3 is a useful completeness check.
• Decide the backend boundary explicitly. The FDA treats manufacturer-controlled elements, including software and firmware update servers and connections to healthcare facility networks, as related systems under 524B(b)(2).

A scope built this way is the same document a notified body reads and a reviewer reads. It is also the document that stops a campaign quietly turning into a web application test of the clinician portal because that was the easiest thing to reach.

Sequencing so the report can be filed

Order is what separates a campaign that produces filing evidence from one that produces a to-do list.

• Run the campaign against a release candidate rather than a shipped build, so remediation is still cheap and the tested artefact becomes the released artefact.
• Remediate, then retest the fixes as a distinct phase with its own record. A retest note appended to the original report keeps one document and one date.
• Feed every finding, fixed or not, back into the security risk assessment. In the EU that is how a test becomes verification of a control; in the US it is the “assessment of any findings” the guidance asks for.
• Freeze the report. From that point the version number of the report belongs to the version number of the build.
• File the methods and results under Annex II section 6, keep the original report intact for the submission, and record the retest trigger in the post-market surveillance plan.

Running the test after the design freeze but before the submission is the narrow window where both regimes are served by the same work. Testing too early gives a report against a build nobody ships; testing after submission gives a report that arrives as a deficiency response.

Two packs from one report

The reporting split is mechanical once the campaign is done. Nothing needs rewriting; the same content is referenced from two places.

Where each artifact from one campaign is filed

Artifact	EU technical documentation	US premarket submission
Test report, unedited	Annex II section 6, as the methods and results of security testing referenced by MDCG §4.1	Provided as the original third-party report
Scope and configuration matrix	Annex II section 6.1(b), covering the configurations named in the labelling	Scope of testing element, aligned with the architecture views
Findings assessment and residual risk	Security risk management file, feeding the benefit-risk determination	Assessment of findings, with rationales and a release plan for deferrals
Minimum IT requirements	Instructions for use, under MDR 23.4(ab) or IVDR 20.4.1(ah)	Labeling and the security use case views
SBOM	Supplier and component control inside the state-of-the-art argument	Statutory element under 524B(b)(3)
Retest schedule	Post-market surveillance plan, triggered by change and surveillance data	Cybersecurity management plan, with the justified interval

What a shared report has to contain

Write the report to the FDA element list and the EU requirement is met on the way past. Five elements are named in section V.C: independence and technical expertise of testers, scope of testing, duration of testing, testing methods employed, and test results, findings and observations. Footnote 47 adds that tool details may include the name, version information and any settings or configuration options.

Two additions make the same document work in the EU file. The first is traceability back to the security risk controls the test exercised, because a notified body is filing the report as verification of those controls rather than as a standalone assessment. The second is an explicit statement of the configurations covered, matched to the ones the instructions for use claim, so a reviewer can see that section 6.1(b) is satisfied without reconstructing the mapping.

The documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies undertaken to demonstrate conformity of the device with the requirements of this Regulation and in particular the applicable general safety and performance requirements.Regulation (EU) 2017/745, Annex II, section 6

The cadence that keeps both files current

After release the two regimes ask for the same thing on different triggers. The FDA expects testing “at regular intervals commensurate with the risk (e.g., annually)”. The MDR has no interval, but Article 83(3) ends with “The technical documentation shall be updated accordingly”, and MDCG 2019-16 §4.1 requires the documentation to be kept updated with information from post-market surveillance about the handling and remediation of cybersecurity incidents and vulnerabilities.

An annual campaign satisfies both, provided the EU side also has an event trigger. Practically that means writing two rules into the post-market surveillance plan: a scheduled campaign each year, and an unscheduled one when a defined event occurs. Reasonable events are a change to authentication, encryption, connectivity or the update mechanism, which is the FDA’s own list of modifications that may impact cybersecurity; a published vulnerability in a component your SBOM says you ship; and a field report of an exposed interface.

Tying the schedule to the submission calendar is a false economy. A device released in March and submitted in November will have a report that is eight months old at review, which is fine, and a report that is twenty months old at the next modification, which is not.

What this does not merge

Two things stay separate, and pretending otherwise creates a gap.

• The SBOM. It is a statutory US requirement under 524B(b)(3) with prescribed content, and it is not an Annex I requirement at all. It is produced by the build pipeline, not by the test, though the test should use it. Merging it into the test deliverable makes it stale the moment the next release ships.
• The architecture views. The four FDA view types are a US artifact. The EU equivalent is the security risk management output under MDCG §3.2 and §3.4, which is organised differently and lives inside the device risk file. Building the views is worth doing regardless, because they are the best scoping input a tester can be handed, but they do not replace the EU risk documentation.

One further caution. The Cyber Resilience Act does not create a third pack for a device: Article 2(2) of Regulation (EU) 2024/2847 excludes products covered by Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Where a manufacturer also sells non-device products, those are in CRA scope on their own terms and need their own treatment.

A minimal working plan

• Build the four FDA architecture views, even if the US submission is a year away. They cost a week and they scope everything else.
• Freeze a release candidate and hand the tester the views, the risk assessment, the labelling and real accounts in every role.
• Commission the campaign at the independence level the FDA guidance contemplates, from a team with no role in the design of the device under test.
• Remediate, retest, and freeze the report with the five elements on its front pages and traceability to the risk controls in its body.
• File the report unedited in both places, and file the derived assessments where each regime expects them.
• Write both retest triggers into the post-market surveillance plan and the cybersecurity management plan, with the same date.

Six steps, one engagement, two files that agree with each other. The failure mode this avoids is not a compliance failure but a credibility one: two reports about the same device, written months apart, that a reviewer can put side by side.