The EU made cybersecurity an explicit requirement for medical devices when the MDR started to apply on 26 May 2021, and for in vitro diagnostics with the IVDR on 26 May 2022. In the US, section 524B of the FD&C Act has required cybersecurity information in premarket submissions for "cyber devices" since 29 March 2023. In February 2026, FDA reissued its premarket cybersecurity guidance and tied it to the Quality Management System Regulation.
Both regions ask for much of the same evidence, but they ask for it in different ways. This article compares the legal basis, what each side expects, and how one secure development process can serve both markets.
The legal basis on each side
| EU | US | |
|---|---|---|
| Law | MDR Annex I, Sections 17.2, 17.4 and 18.8; IVDR Annex I, Sections 16.2 and 16.4 | FD&C Act section 524B, for cyber devices |
| Guidance | MDCG 2019-16 Rev.1, nonbinding | Premarket cybersecurity guidance, February 2026, nonbinding |
| Style | General safety and performance requirements; the manufacturer chooses how to show conformity | Specific items that must be in the submission |
| Who reviews | Notified body, for devices that need one | FDA, in the 510(k), PMA, De Novo, PDP or HDE review |
Sources: MDR; IVDR; FD&C Act; MDCG 2019-16 Rev.1; FDA.
In our view, the US route is the harder one to document, because section 524B turns parts of the security work into named submission items. The EU route is not easier, though. It leaves more to the manufacturer's own justification, and that justification has to hold up in front of the notified body.
EU: what the MDR and IVDR require
The MDR does not use the word "cybersecurity" as a separate chapter. The requirements sit in Annex I:
| MDR Annex I | Requirement | IVDR Annex I |
|---|---|---|
| 17.2 | Software developed and manufactured according to the state of the art, taking into account the development life cycle, risk management including information security, verification and validation | 16.2 |
| 17.4 | Manufacturers set out minimum requirements for hardware, IT network characteristics and IT security measures, including protection against unauthorised access, needed to run the software as intended | 16.4 |
| 18.8 | Devices designed and manufactured to protect, as far as possible, against unauthorised access that could hamper the device from functioning as intended | No equivalent listed in MDCG 2019-16 |
| 23.4(ab) | Instructions for use include those minimum hardware, IT network and IT security requirements | 20.4.1(ah) |
Sources: MDR and IVDR Annex I; MDCG 2019-16 Rev.1, Table 1.
MDCG 2019-16 Rev.1 explains how to meet these requirements: security risk management, security by design, verification, information for users and post-market vulnerability handling. It is guidance, not law. Notified bodies use it as a reference point when they review the technical documentation.
In our view, the technical file should show a traceable line from identified threats to design decisions, test results and the information in the IFU. A stand-alone penetration test report with no link to the risk file is weak evidence.
US: what section 524B requires
Under section 524B(c), a cyber device includes software validated, installed or authorised by the sponsor, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. For such a device, the submission must include:
| Provision | Requirement |
|---|---|
| 524B(b)(1) | A plan to monitor, identify and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure |
| 524B(b)(2) | Processes that provide a reasonable assurance that the device and related systems are cybersecure, including updates and patches |
| 524B(b)(3) | A software bill of materials (SBOM), including commercial, open-source and off-the-shelf components |
| 524B(b)(4) | Any other requirements FDA sets by regulation |
Source: FD&C Act section 524B.
The February 2026 guidance supersedes the June 2025 version. It explains what FDA expects as evidence, such as threat modelling, architecture views, security testing and a machine-readable SBOM, and links this work to design controls under the QMSR. Our article on the FDA cybersecurity guidance covers the guidance in detail.
Where the two compare
| Topic | EU (MDR/IVDR) | US (section 524B) |
|---|---|---|
| Secure development | Required through Annex I 17.2, according to the state of the art | Required through 524B(b)(2) processes; FDA recommends a secure product development framework |
| SBOM | Not named in Annex I; MDCG 2019-16 Rev.1 lists it among security information that may be shared with users, such as in administrator documentation | Required for cyber devices under 524B(b)(3) |
| Vulnerability handling after release | Part of post-market surveillance and vigilance (MDR Articles 83 to 92) | Postmarket plan required under 524B(b)(1) |
| Updates and patches | Assessed as changes under the QMS and, where relevant, notified to the notified body | Processes for updates and patches required under 524B(b)(2) |
| User information | IFU requirements in MDR Annex I 23.4(ab) and IVDR Annex I 20.4.1(ah) | Cybersecurity labelling recommended in the FDA guidance |
Sources: MDR; IVDR; MDCG 2019-16 Rev.1; FD&C Act section 524B; FDA guidance, February 2026.
One process for both markets
The underlying work is the same in both regions. In our view, a manufacturer should run one secure life cycle and package the evidence twice: once for the EU technical documentation and once for the US submission.
IEC 81001-5-1 is the usual framework for security activities in health software. FDA names it as an example of a secure product development framework. It is not a harmonised standard under the MDR, so in the EU it supports a state of the art argument rather than giving a presumption of conformity. It builds on the software life cycle in IEC 62304.
Security risk management should run alongside ISO 14971 safety risk management, with clear links where a security event can lead to a hazard. In our view, the two should not be merged into one worksheet, because a threat and a hazard are assessed in different ways.
After release, a reported vulnerability should enter the same process as a complaint. Under the MDR, the manufacturer then decides whether it is a serious incident or needs a field safety corrective action. Under section 524B, the postmarket plan sets out how the vulnerability is triaged, fixed and disclosed.
Other EU and audit frameworks
Cyber Resilience Act: Article 2(2) of Regulation (EU) 2024/2847 excludes products to which the MDR or IVDR apply. Software around the device that is not itself a device may still fall under the CRA. Our article on the CRA and health software covers this.
AI Act: for high-risk AI systems, Article 15 of Regulation (EU) 2024/1689 requires accuracy, robustness and cybersecurity.
MDSAP: the audit approach MDSAP AU P0002.011, revision date 3 August 2026, adds US FDA device cybersecurity requirements to the Design and Development tasks. Our article on MDSAP explains the programme.
A hypothetical example
Hypothetical example: a company based outside the EU develops a cloud-hosted SaMD that analyses images and shows results to patients through a mobile app. It plans to sell in the EU and the US.
EU requirements: Annex I 17.2, 17.4 and 18.8 apply. The technical file shows the threat model, the security requirements, the test results and the IT requirements stated in the IFU.
US requirements: the app includes software and connects to the internet, so it is a cyber device. The submission includes the postmarket vulnerability plan, the update processes and an SBOM covering the app and the cloud components.
Shared evidence: one threat model, one set of security requirements and one test strategy feed both files.
EU representation: as a non-EU manufacturer, it also needs an EU authorised representative, who must verify under Article 11 of the MDR that the technical documentation has been drawn up. MedQAIR's Digital AR service covers that role.
Conclusion
The EU and the US ask for the same substance: secure development, security risk management, testing, user information and vulnerability handling after release. The EU states this as general requirements in Annex I, with MDCG 2019-16 as guidance. The US makes the vulnerability plan, update processes and SBOM mandatory items in the submission.
In our view, build one security life cycle into the QMS from the start of development, and keep the SBOM and vulnerability records current after release. Then both files are a matter of packaging, not rework.
If you need help with cybersecurity for your device, our cybersecurity and privacy team can help, or contact MedQAIR.
Frequently asked questions
Where are the cybersecurity requirements in the MDR?
In Annex I, mainly Sections 17.2, 17.4 and 18.8, and the IFU requirement in Section 23.4(ab). For IVDs, the IVDR equivalents are Annex I Sections 16.2, 16.4 and 20.4.1(ah).
Is MDCG 2019-16 binding?
No. It is guidance that explains how to meet the Annex I requirements. Notified bodies use it as a reference.
What is a cyber device under section 524B?
A device that includes software validated, installed or authorised by the sponsor, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats.
Is an SBOM required in the EU?
The MDR does not name it. MDCG 2019-16 Rev.1 lists the SBOM among security information that may be shared with users. In the US, it is mandatory for cyber devices under section 524B(b)(3).
Does the Cyber Resilience Act apply to medical devices?
Not to products covered by the MDR or IVDR, which Article 2(2) of the CRA excludes. Related software that is not a device may still be in scope.
