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: May 2026 against the FDA February 2026 final guidance, MDCG 2019-16 Rev.1, and the EU Cyber Resilience Act.
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.
TL;DR - Where the regimes line up and diverge
| Dimension | EU MDR / IVDR | FDA |
|---|---|---|
| Legal anchor | MDR Article 5 + Annex I §17 (GSPR) | Section 524B of FD&C Act |
| Operational guidance | MDCG 2019-16 Rev.1 | February 2026 final premarket guidance |
| Reviewer | Notified Body (technical documentation review) | FDA reviewer (eSTAR Section 14) |
| SBOM mandate | Implicit via GSPR + CRA; explicit under CRA Annex I | Explicit; CycloneDX or SPDX |
| Threat modeling | Required; format flexible | Required; diagram-driven |
| Pen testing | Required; not always third-party | Required; independent third party |
| Update/patch design | Required by GSPR 17.2 | Required by §524B(b)(2) |
| Vulnerability handling | MDCG 2019-16 + CRA Article 13/14 | §524B(b)(1) postmarket |
| Disclosure cadence | CRA: 24h actively-exploited / 72h vulnerability / 14d update | FDA: as part of postmarket; CISA/KEV alignment |
| Standards anchor | IEC 81001-5-1, EN 18031 (for radio), IEC 62443 | AAMI SW96, IEC 81001-5-1, NIST SSDF |
| Failure consequence | Notified Body refusal to issue CE mark | RTA hold / deficiency letter |
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:
- 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.
- 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.
- EU Cyber Resilience Act (CRA) - Regulation 2024/2847, in force since December 2024, with main obligations applying from December 11, 2027. For most networked medical devices, CRA obligations apply via the MDR (avoiding double regulation), but the CRA's substantive requirements - SBOM, vulnerability handling, security updates - become the operational standard.
- 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.
- NIS2 Directive (2022/2555) - applies to healthcare operators (hospitals, large clinics) rather than manufacturers, but creates downstream procurement pressure.
FDA side
The FDA architecture is comparatively flat:
- 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.
- February 2026 final premarket guidance - Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. The operational standard reviewers apply.
- Postmarket cybersecurity guidance - 2016, plus the 2023 statutory overlay.
- 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 and CRA Annex I makes it explicit for products in 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. CRA Article 13 codifies the obligation.
- 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.
| Trigger event | FDA (Section 524B + 21 CFR 803 + 2026 guidance) | EU (CRA Article 14 + MDR Article 87 + MDCG 2019-16) | Binding constraint |
|---|---|---|---|
| Actively-exploited vulnerability discovered in a fielded device | Notify CISA via coordinated disclosure; update postmarket plan; assess MedWatch reportability under 21 CFR §803.50 (30-day) or 803.53 (5-day) if patient harm is foreseeable | Early warning to ENISA + national CSIRT within 24 hours of awareness (CRA Art. 14(1)) | EU 24h clock starts first; assume same-day notification |
| Severe incident affecting device security or availability | MDR (Medical Device Report) within 30 days; 5-day report if remedial action required | Incident notification to ENISA + CSIRT within 24 hours, full notification within 72 hours (CRA Art. 14(2)) | EU 24h/72h |
| Initial vulnerability assessment complete (root cause, scope, exploitability) | Document in postmarket file; no fixed external clock; feeds CAPA | 72 hours from initial awareness for full notification with corrective/mitigating measures | EU 72h |
| Security update / patch released to users | Customer notification via CVD policy; SBOM/VEX refreshed; labeling updated | 14 days after the update is made available: public disclosure with CVE, severity, and mitigations (CRA Art. 14(3)) | EU 14d (forces public CVE) |
| Vulnerability discovered but not yet exploited, no incident | Track in postmarket plan; coordinate via CVD; KEV/NVD monitoring | Handle under CRA Art. 13 vulnerability-handling process; no 24h trigger unless exploitation or severe incident occurs | Both: process-driven, no statutory clock |
| Vulnerability leads to death or serious injury | MDR within 30 days (21 CFR §803.50); 5-day report if action to prevent unreasonable risk is required (803.53) | MDR Article 87: serious incident report to competent authority immediately, not later than 15 days (2 days if serious public health threat, 10 days if death/unanticipated serious deterioration) | EU 2-15 days; FDA 5-30 days - both apply in parallel |
| End-of-support / end-of-life for a cyber device | Disclose end-of-support date in labeling (FDA 2026 guidance VI); postmarket plan addresses legacy posture | CRA expectations on support period (typically 5+ years); PMS plan documents legacy strategy | Both: label the date, plan the wind-down |
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Dual-market build sequence
For teams filing in both markets, the most efficient sequence:
- Build the FDA-shaped evidence first. It's more prescriptive, so it sets the high-water mark.
- Map to MDR vocabulary. GSPR 17.2, MDCG 2019-16, IEC 81001-5-1, EN 18031 where applicable.
- Build the CRA-cadence postmarket program. 24/72/14 notification SLAs cover both markets.
- Maintain one SBOM, one threat model, one risk file. Format-shift for presentation; never fork the source of truth.
- 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. 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