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 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.
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.
Frequently asked questions
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 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