On this page
Published: · Updated:
Key Takeaways
- EU MDR/IVDR Annex I obligations and FDA Section 524B have different scopes and legal anchors.
- Reusable technical records still need market-specific applicability, evidence mapping, and manufacturer approval.
- The EU regulations do not explicitly name an SBOM as a universal deliverable; Section 524B explicitly requires one for covered cyber-device submissions.
- Independent security testing can strengthen evidence, but neither framework imposes a universal external penetration-test provider rule.
- Medical-device vigilance and FDA reporting assessments remain separate; CRA clocks do not apply to excluded MDR/IVDR products.
How do EU MDR and FDA cybersecurity requirements compare?
EU MDR/IVDR and FDA cybersecurity expectations overlap in technical work but not in every legal obligation. Build controlled, device-specific evidence and map it separately to each applicable framework. Do not assume an FDA-oriented file establishes EU conformity, that all artifacts are universally mandated, or that the CRA's reporting clocks apply to MDR/IVDR devices.
For EU requirement-to-document mapping, use the EU MDR/IVDR evidence crosswalk. This page compares the two market frameworks rather than repeating that technical-file index. MDC Crosswalk is a companion planning resource; primary legislation and agency guidance remain the sources for regulatory claims.
At a glance
| Dimension | EU MDR / IVDR | FDA |
|---|---|---|
| Legal basis | MDR / IVDR general safety and performance requirements and lifecycle duties | Applicable device law, including Section 524B for covered cyber-device submissions |
| Guidance | Nonbinding MDCG 2019-16 Rev.1 | February 3, 2026 final premarket cybersecurity guidance, nonbinding except where citing legal duties |
| Evidence presentation | GSPR mapping and Annex II/III technical documentation | Applicable submission pathway and cybersecurity content; eSTAR where required or used |
| Review route | Conformity assessment; Notified Body involvement depends on class and route | FDA review according to the applicable submission pathway |
| SBOM | Useful component and vulnerability-management evidence; not explicitly named as a universal deliverable in MDR/IVDR | Explicit under Section 524B(b)(3) for covered submissions; guidance explains presentation |
| Security testing | Demonstrate applicable information-security and risk-control requirements; MDCG explains practical testing | Guidance describes security testing and evidence supporting device cybersecurity |
| Postmarket | PMS, corrective action, and vigilance under the applicable MDR/IVDR rules | Vulnerability management plus applicable FDA reporting and correction/removal rules |
Legal scope comes first
EU MDR and IVDR
MDR Annex I 17.2 and IVDR 16.2 require software development and manufacture to the state of the art with lifecycle, risk management, information security, verification, and validation considered. Minimum IT security requirements are addressed in MDR 17.4 and IVDR 16.4. IFU provisions use MDR 23.4(ab) and IVDR 20.4.1(ah).
The manufacturer must justify applicable GSPRs and retain the evidence. The regulations do not turn each recommended threat-model format, SBOM schema, or testing method into a universal named statutory requirement. MDCG guidance explains implementation but is not law.
FDA submissions
Section 524B applies to covered cyber-device marketing submissions through its statutory pathways. It requires a postmarket vulnerability plan, processes and updates/patches under subsection (b)(2), and an SBOM under (b)(3). IDE applications are not enumerated in Section 524B(a), although the FDA guidance addresses cybersecurity evidence for investigational devices.
The February 3, 2026 FDA guidance explains expected evidence. Distinguish a statutory duty from a recommended format or evidence approach. See the pathway differences guide before choosing application content.
Reusable records and market-specific checks
| Record | Reusable work | What still needs separate review |
|---|---|---|
| Architecture and threat model | Interfaces, assets, trust boundaries, threats, and connected-system analysis | Product configurations, operating assumptions, and market-specific presentation |
| Security risk assessment | Threat/control analysis and safety links where relevant | Applicable requirements, manufacturer acceptance criteria, and approvals |
| Component inventory / SBOM | Build-specific component identities and vulnerability follow-up | Required coverage, format, application placement, and local expectations |
| Security test evidence | Test scope, build, findings, remediation, and retests | Requirements covered, independence/expertise rationale, and configuration differences |
| User security information | Supported environment, secure setup, updates, and responsibilities | EU IFU anchors and applicable FDA labeling recommendations |
| Vulnerability-management process | Intake, triage, affected-build identification, corrective work, and communication | Reportability, authorities, deadlines, and regional responsibilities |
There is no substantiated universal percentage of reusable documentation. Reuse depends on the product, configuration, quality of the records, and applicable route. A shared evidence base should not become a claim that one package satisfies every regulator automatically.
Testing and standards: avoid blanket rules
Security testing should address the actual device, connected systems, control requirements, and threat scenarios. Independence and expertise matter, but the FDA does not universally require an external penetration-test provider. MDR/IVDR also do not establish a universal third-party or annual penetration-test rule.
IEC 81001-5-1, ANSI/AAMI SW96, and ISO 14971 have related but different roles. Use the IEC lifecycle evidence table to organize activities, not as proof of complete conformity. Check exact recognition or harmonization status and covered requirements. Do not label one standard categorically more rigorous or claim it automatically exceeds the other market's expectations.
Reporting decisions must remain separate
Products covered by MDR or IVDR are excluded from the CRA under Article 2(2)(a) (MDR) and (b) (IVDR). Do not create a medical-device 24/72/14 reporting schedule using CRA duties. Separately supplied non-device products require their own scope assessment.
| Situation | EU device assessment | FDA assessment |
|---|---|---|
| A vulnerability is identified | Assess affected devices, safety/performance impact, PMS action, and whether vigilance or field safety action criteria are met | Assess device impact, vulnerability management, and applicable reporting/correction obligations |
| Death, serious injury, or another potentially reportable event | Apply MDR Article 87 or IVDR Article 82 criteria and deadlines | Apply the relevant 21 CFR Part 803 reporting criteria and deadlines |
| A security update or field action is planned | Assess whether it is a field safety corrective action and identify notification/communication duties | Assess applicable correction/removal rules, reporting, and submission implications |
| A product is separately in CRA scope | Apply that product's CRA duties separately | Do not treat CRA reporting as satisfying FDA obligations |
Not every vulnerability, foreseeable harm scenario, or patch triggers the same report. Record awareness times, causality information, reportability rationale, recipients, and decisions through the manufacturer's regulatory process. Do not wait for a scheduled review when an applicable reporting clock is running.
MDR versus IVDR
The numbering differs, and IVD risk scenarios may include altered results, specimen/result misassociation, delayed reporting, and downstream treatment consequences. Use the actual intended purpose and architecture rather than assuming confidentiality is the only concern.
MDR clinical evaluation and IVDR performance evaluation also differ. Device classification and PMS reporting must be assessed under the relevant regulation; MDR software Rule 11 is not an IVDR classification rule. The EU evidence crosswalk provides the separate anchors.
Dual-market sequence
- Define product boundaries, configurations, and applicable routes.
- Build controlled threat, risk, component, lifecycle, and test records.
- Map the FDA content to the appropriate pathway and EU evidence to the applicable GSPRs.
- Resolve evidence gaps and retain authorized manufacturer decisions.
- Keep user information consistent with the tested environment.
- Maintain one coordinated operational process with separate regional legal decisions.
Worked evidence example: one record, two markets
| Record | FDA use | EU MDR use | Market-specific check |
|---|---|---|---|
| Threat model | Supports the Section 524B(b)(2) design evidence and eSTAR threat modeling | Supports Annex I 18.8 and IEC 81001-5-1 records | Confirm the threat model reflects EU deployment environments and languages for IFU |
| SBOM | Required for cyber devices under 524B(b)(3) | Supports component management and postmarket surveillance | No EU format is mandated; keep one source and export as needed |
| Penetration test report | Security testing evidence under the FDA guidance | Verification evidence for Annex I 17.2 and 18.8 | Same build identifiers in both files |
| Vulnerability procedure | 524B(b)(1) postmarket plan | Postmarket surveillance and vigilance inputs | Reporting decisions made separately under each law |
How Blue Goat Cyber helps
We support threat modeling, security risk assessment, SBOMs, penetration testing, and cybersecurity documentation mapping. The manufacturer retains QMS ownership, clinical risk decisions, conformity declarations, applications, and reporting responsibilities. See EU MDR cybersecurity support and premarket cybersecurity support.
FAQ
Does the CRA apply to MDR/IVDR products?
No. Article 2(2)(a) (MDR) and (b) (IVDR) exclude products to which MDR or IVDR applies. Separate non-device products need their own assessment.
Can I reuse an FDA threat model in an EU file?
Yes, where it accurately covers the same product and configuration. Reassess applicability, evidence gaps, legal references, and technical-file placement.
Is third-party penetration testing always required?
No. Testing scope, expertise, independence, and evidence must be justified. An external provider is not universally mandated and does not guarantee acceptance.
Which EU guide should I use first?
Use the EU overview for legal context and the evidence crosswalk for a controlled document index.
Sources and primary references
- MDR, Regulation (EU) 2017/745
- IVDR, Regulation (EU) 2017/746
- MDCG 2019-16 Rev.1
- CRA, Regulation (EU) 2024/2847, Article 2(2)(a) and (b)
- 21 USC 360n-2, Section 524B
- The FDA: February 3, 2026 premarket cybersecurity guidance
- 21 CFR Part 803, medical device reporting
- 21 CFR Part 806, corrections and removals
Sources & references
Primary sources cited in this article. Links open in a new tab.
- MDCG guidance- health.ec.europa.eu
- MDR, Regulation (EU) 2017/745- eur-lex.europa.eu
- IVDR, Regulation (EU) 2017/746- eur-lex.europa.eu
- CRA, Regulation (EU) 2024/2847, Article 2(2)(a) and (b)- eur-lex.europa.eu
- The FDA: February 3, 2026 premarket cybersecurity guidance- U.S. FDA
