EU MDR vs FDA Cybersecurity: Side-by-Side Crosswalk

For MedTech teams filing in both markets, this guide compares cybersecurity expectations under EU MDR/IVDR and the FDA's Section 524B framework - what's the same, what's different, and how to build one evidence set that satisfies both.

Last reviewed: July 2026 against the FDA February 2026 final guidance, MDCG 2019-16 Rev.1, Regulation (EU) 2024/2847 (CRA), and the IVDR transitional deadlines.

Community project: A structured side-by-side mapping of every EU MDR / FDA cybersecurity requirement lives at mdccrosswalk.com - a free reference we sponsor as an industry resource. Use this guide for the narrative and decisions; use the crosswalk for the row-by-row mapping.

At a glance - Where the regimes line up and diverge

The headline: same threat model, two presentations. About 90% of the underlying technical evidence is reusable. The 10% that diverges is mostly format, vocabulary, and disclosure cadence.

The legal architecture

EU side

EU medical device cybersecurity is layered:

1. MDR (Regulation 2017/745) and IVDR (Regulation 2017/746) - Annex I, Chapter II, 17 ("Electronic programmable systems") and 14 ("Construction and interaction with their environment"). 17.2 explicitly requires that software-driven devices be designed and manufactured to ensure repeatability, reliability, and performance - and that risks associated with possible interaction between software and the IT environment are eliminated or reduced.
2. MDCG 2019-16 Rev.1 - the Medical Device Coordination Group guidance on cybersecurity. Not legally binding, but Notified Bodies use it as the de facto checklist.
3. EU Cyber Resilience Act (CRA) - Regulation 2024/2847, in force since December 2024, with main obligations applying from December 11, 2027. Article 2(2) excludes products regulated under the MDR or IVDR, so the CRA does not apply to the medical device itself. It can apply to connected products around the device that are not regulated as devices, such as a separately sold wellness app or a general-purpose gateway. See is my product covered by the CRA?
4. EN 18031 series - harmonized standards for the Radio Equipment Directive (RED) Delegated Act on cybersecurity. Applies to internet-connected and radio-connected devices placed on the EU market from August 2025.
5. NIS2 Directive (2022/2555) - applies to healthcare operators (hospitals, large clinics) rather than manufacturers, but creates downstream procurement pressure.

EU compliance dates a MedTech program has to plan around

Plan backwards from these dates. A device that clears the FDA in 2026 but is still on an MDD or IVDD certificate needs its cybersecurity technical documentation rebuilt to MDR/IVDR level before the transitional deadline, not after.

FDA side

The FDA architecture is comparatively flat:

1. Section 524B of the FD&C Act - added by the Consolidated Appropriations Act of 2023. Defines "cyber device," requires cybersecurity information in premarket submissions, and requires postmarket vulnerability management.
2. February 2026 final premarket guidance - Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. The operational standard reviewers apply.
3. Postmarket cybersecurity guidance - 2016, plus the 2023 statutory overlay.
4. 21 CFR Part 820 (QSR / QMSR) - quality system regulation; cybersecurity now sits inside the QMS, not beside it.

Side-by-side: the deliverables

Security risk management

• EU MDR. Risk management under ISO 14971 with cybersecurity risks integrated. IEC 81001-5-1 increasingly cited as the security-lifecycle anchor. AAMI TIR57/SW96 is acceptable but not the default reference.
• FDA. AAMI SW96:2023 is the FDA-recognized consensus standard, with TIR57 as the supporting reference. Security risk must be a separate file from ISO 14971 safety risk and explicitly map to patient-harm scenarios.

Practical implication. Build to AAMI SW96 as the more rigorous standard; map the artifacts to ISO 14971 + IEC 81001-5-1 for the MDR file. The SW96 file satisfies both.

Threat modeling

• EU MDR. Required by MDCG 2019-16, format flexible. STRIDE and TARA both accepted. Architecture views expected.
• FDA. Required, diagram-driven, with multiple architecture views (global system, multi-patient harm, updateability, security use-case).

Practical implication. Build the FDA-style diagram-driven threat model. It exceeds MDR expectations and you can present the same artifact to a Notified Body. See STRIDE threat modeling for medical devices.

SBOM

• EU MDR. Not explicitly required by the regulation, but MDCG 2019-16 expects it. (CRA Annex I makes SBOMs explicit, but only for non-device products in CRA scope.) Format not prescribed.
• FDA. Explicit. CycloneDX or SPDX. Seven NTIA minimum data fields plus dependency relationships, license, and hash. Pair with known-vulnerability assessment and VEX statements.

Practical implication. Ship a CycloneDX or SPDX SBOM with VEX. It satisfies FDA explicitly and exceeds the MDR/CRA expectation. See CycloneDX vs SPDX comparison and VEX document guide.

Penetration testing

• EU MDR. Required by MDCG 2019-16. Third-party is recommended but not mandatory; some Notified Bodies accept internal testing with strong evidence.
• FDA. Third-party penetration testing is required. Web-app pen tests rebadged for the device will be rejected. Signed Letter of Attestation expected.

Practical implication. Default to third-party. It satisfies FDA explicitly and removes any Notified Body argument. See our pen test cost guide.

Update and patch mechanism

• EU MDR. Required by GSPR 17.2 - devices must be designed to maintain safety and performance over their lifetime, which includes the ability to receive security updates. MDCG 2019-16 describes how to show it.
• FDA. Required by Section 524B(b)(2) - devices must be "designed to be updated and patched."

Practical implication. Same engineering requirement: signed firmware, secure OTA channel, integrity protections, customer notification. Document once, present to both regulators.

Vulnerability handling and disclosure

This is where the regimes diverge most sharply.

• EU MDR / CRA. CRA Article 13 requires manufacturers to establish vulnerability handling processes, including coordinated disclosure. CRA Article 14 sets specific notification timelines: 24 hours for an actively-exploited vulnerability or severe incident, 72 hours for an initial assessment, 14 days after a security update is available.
• FDA. Postmarket cybersecurity management plan required by Section 524B(b)(1). Coordinated vulnerability disclosure (CVD) policy expected. CISA / KEV alignment expected. No equivalent 24-hour statutory clock - but reportability under 21 CFR Part 803 (MedWatch) applies when a vulnerability leads to a reportable event.

Practical implication. Build to the CRA cadence - it's the tightest. Document a 24/72/14 notification SLA in your postmarket plan and you exceed FDA expectations automatically. See SBOM vulnerability management for medical devices.

Disclosure & reporting timeline crosswalk

The two regimes use different triggers, clocks, and recipients. The table below maps each event a manufacturer is likely to face to the obligation on both sides of the Atlantic. Treat the strictest cell in each row as the binding constraint for a dual-market program.

Notification recipients. FDA submissions go to CDRH (MedWatch, eMDR); coordinated disclosure runs through CISA and the researcher. CRA reports go to ENISA's single reporting platform plus the national CSIRT of the member state where the manufacturer is established. MDR serious-incident reports go to the competent authority of the affected member state via EUDAMED. Maintain a routing matrix in the postmarket plan - the wrong inbox at hour 20 of a 24-hour window is an effective miss.

Decision points during an active disclosure

1. Hour 0 - awareness. Start the 24-hour CRA clock the moment a credible report of active exploitation or a severe incident reaches the PSIRT inbox. Don't wait for triage to confirm scope; CRA Art. 14 measures awareness, not certainty.
2. Is it "actively exploited"? CRA defines this as evidence of malicious actor compromise. KEV listing, honeypot telemetry, customer-reported exploitation, and PoC code observed in the wild all qualify. Vendor-discovered vulnerabilities without exploitation evidence sit on the Art. 13 process track, not the Art. 14 clock.
3. Is it a "severe incident"? CRA criteria: capable of causing serious disruption, financial loss, or material/non-material damage. For a connected medical device, any safety-relevant compromise meets this bar. Default to "yes" and downgrade later if facts warrant.
4. Does it cross the FDA MDR / MedWatch line? If foreseeable patient harm exists, the 21 CFR 803 clock (5 or 30 days) runs in parallel with CRA. Both reports are required; neither substitutes for the other.
5. Patch readiness vs. disclosure. CRA's 14-day public-disclosure clock starts when the update is available to users, not when development finishes. Synchronize the CVE reservation, VEX statement, customer notice, labeling update, and SBOM refresh as one release event.
6. Coordinated disclosure with the researcher. Both regimes assume a CVD policy is in place. Negotiate the embargo before the clock starts, not during it. The FDA expects a CVD policy aligned with ISO/IEC 29147 and 30111; CRA Art. 13 expects the same substantively.

Build this into the postmarket plan now. A dual-market 24/72/14 SLA, a routing matrix for ENISA / CSIRT / CISA / competent authority / FDA, and a pre-drafted CVE + VEX + customer-notice bundle eliminate the worst failure mode: missing a statutory window because the team was deciding who to notify instead of executing the notification.

Labeling

• EU MDR. GSPR 23.4 requires labeling that supports safe use, including information for IT-related risks. MDCG 2019-16 expands on cybersecurity labeling content.
• FDA. Explicit labeling list - controls, secure configuration, ports/protocols, SBOM pointer, CVD intake, support lifecycle, end-of-support date, operating-environment assumptions.

Practical implication. Build to the FDA list; it covers MDCG 2019-16. Add the CE-specific instructions for use.

Postmarket cybersecurity

• EU MDR. Post-market surveillance (PMS) plan required by Article 83; periodic safety update reports (PSUR) for higher-class devices. Cybersecurity events feed into both. CRA adds the 24/72/14 notification clock.
• FDA. Section 524B(b)(1) postmarket plan, MedWatch reporting, CISA/KEV monitoring, CAPA integration.

Practical implication. One postmarket cybersecurity program that feeds both PMS/PSUR (EU) and the FDA postmarket plan. The CRA notification clock is the binding constraint.

IVDR specifics: where in vitro diagnostics differ

IVD manufacturers often assume the MDR analysis transfers unchanged. Most of it does, but four things differ enough to change the work package.

1. The GSPR numbering moves. IVDR Annex I electronic programmable systems requirements sit at §16 (and §13 for the IT environment), not MDR §17. Notified Bodies expect the cybersecurity evidence indexed to the IVDR numbering. A file cross-referenced to MDR §17.2 gets a question.

2. Class D changes who reviews you. Class D IVDs add EU reference laboratory involvement and a scrutiny procedure. That means more reviewers touching the technical file and a higher likelihood that security control justification gets challenged in detail.

3. Data flows are the risk surface. IVD software typically moves patient results between analyzer, middleware, LIS, and sometimes a cloud analytics tier. The threat model should be built around result integrity and result confidentiality - a silently altered result is the harm scenario, not device unavailability. That maps directly to the FDA's expectation of a multi-patient harm view.

4. FDA-side classification is different too. Many IVDs are reviewed by CDRH's OHT7 and travel through 510(k) or De Novo with an eSTAR structure that differs slightly for IVD versus non-IVD submissions. See eSTAR cybersecurity for IVD vs non-IVD submissions and cybersecurity for IVD devices.

Practical implication. Keep one evidence set, but maintain two GSPR index tables: MDR Annex I §17 and IVDR Annex I §16. It's a mapping exercise, not a second program.

Dual-market build sequence

For teams filing in both markets, the most efficient sequence:

1. Build the FDA-shaped evidence first. It's more prescriptive, so it sets the high-water mark.
2. Map to MDR vocabulary. GSPR 17.2, MDCG 2019-16, IEC 81001-5-1, EN 18031 where applicable.
3. Build the CRA-cadence postmarket program. 24/72/14 notification SLAs cover both markets.
4. Maintain one SBOM, one threat model, one risk file. Format-shift for presentation; never fork the source of truth.
5. Use Q-Subs (FDA) and Notified Body consultations (EU) for novel architectures. Both regulators offer pre-submission feedback; both are dramatically under-used.

Common dual-market failure patterns

1. Fork-then-diverge. Team builds two parallel cybersecurity programs that drift apart. Six months later, the SBOMs disagree. Fix: one source of truth, two presentations.

2. Lowest-common-denominator. Team builds to the easier regime, then scrambles when the stricter one reviews. Fix: build to the strictest requirement on every dimension.

3. Missing the CRA clock. Postmarket plan built before CRA, never updated for the 24/72/14 cadence. Fix: rebuild the postmarket plan to the CRA timeline; it now covers both markets.

4. EN 18031 surprise. Teams discover EN 18031 applies to their wireless-enabled device only at the CE-marking stage. Fix: include EN 18031 conformance in the cybersecurity work package from day one if the device has any radio interface.

FAQ

Is the EU more or less strict than the FDA on cybersecurity?

Different, not strictly more or less. The FDA is more prescriptive on format (SBOM, threat model structure, pen test independence). The EU - especially with CRA in force - is more prescriptive on disclosure timing. A program built to the strictest requirement on each dimension satisfies both.

Does the CRA apply to medical devices?

For most networked medical devices, CRA obligations apply via the MDR (the so-called "presumption of conformity" mechanism), to avoid double regulation. The CRA's substantive requirements - SBOM, vulnerability handling, security updates - become the operational standard regardless.

Do I need a separate Notified Body cybersecurity review?

Cybersecurity is part of the Notified Body's technical documentation review, not a separate process. But Notified Bodies vary in cybersecurity expertise - some delegate to subcontractors. Ask early.

Can I use AAMI SW96 for the MDR submission?

Yes. SW96 is not a CEN/CENELEC harmonized standard, but it's compatible with ISO 14971 + IEC 81001-5-1 and provides more rigorous security-risk methodology. Reference it as a state-of-the-art input alongside the harmonized standards.

What's EN 18031 and do I need it?

EN 18031-1/-2/-3 are the harmonized standards under the Radio Equipment Directive (RED) Delegated Act on cybersecurity. They apply to internet-connected and radio-connected devices placed on the EU market from August 2025. If your medical device has Wi-Fi, Bluetooth, cellular, or other radio interfaces, EN 18031 conformance is part of your CE evidence.

How do FDA Q-Subs map to EU pre-submission feedback?

FDA Q-Sub is a structured program with written feedback or meetings. EU equivalents vary by Notified Body - most offer pre-application meetings, some offer formal pre-assessment. Less standardized, but available.

Where this fits in our content

• FDA Premarket Cybersecurity Submission Checklist - the FDA-side deliverables.
• FDA Pathway Cybersecurity Differences - how the FDA package scales by pathway.
• EU Cyber Resilience Act for Medical Devices - CRA scoping and conformance.
• The MedTech Cybersecurity Standards Decoder - all the standards in one map.
• mdccrosswalk.com - community-sponsored interactive crosswalk.

How Blue Goat Cyber helps

We run dual-market cybersecurity programs for MedTech teams filing in the U.S. and EU: one evidence set, two presentations, one postmarket program.

• A single technical file, mapped twice. The threat model, risk assessment, SBOM, and test reports are authored once, then indexed against the FDA's eSTAR structure and against MDR Annex I GSPR 17 plus the applicable CRA essential requirements, so neither reviewer has to hunt.
• Reconciled risk language. ISO 14971 governs the safety risk file in both markets, but security risk scoring differs in emphasis. We keep one scoring method and document the rationale rather than maintaining two contradictory risk tables.
• Notified body question handling. MDR review is a conversation, not a letter. We prepare the answers to the questions notified bodies actually raise on security: control justification, verification independence, and the maintenance period for updates.
• One postmarket loop. CVD intake, vulnerability triage, and patch release run as a single process instrumented to produce both FDA-style postmarket evidence and the EU's vigilance and reporting artifacts.

See FDA premarket cybersecurity services and EU Cyber Resilience Act services.

Sources & primary references

• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final guidance, February 2026)
• Section 524B of the Federal Food, Drug, and Cosmetic Act
• Regulation (EU) 2017/745 (MDR) and Regulation (EU) 2017/746 (IVDR)
• MDCG 2019-16 Rev.1 - Guidance on Cybersecurity for Medical Devices
• Regulation (EU) 2024/2847 - Cyber Resilience Act
• Commission Delegated Regulation (EU) 2022/30 - RED Delegated Act on cybersecurity
• EN 18031-1, EN 18031-2, EN 18031-3 - harmonized cybersecurity standards under RED
• IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness and security
• AAMI SW96:2023 - Standard for medical device security - Security risk management