Section 524B of the FD&C Act, plus the premarket cybersecurity guidance issued February 3, 2026
In force. Refuse-to-Accept applies to cyber devices without a compliant package.
- What triggers it
- Any “cyber device”: software-containing, internet-capable, and vulnerable to a cybersecurity threat. Connectivity as light as Bluetooth pairing or a USB sync port pulls you in.
- Evidence expected
- Secure Product Development Framework (SPDF) evidence, threat model (STRIDE with data flow diagrams), security risk assessment, architecture views, penetration test report, and traceability from threat to control to verification.
- SBOM
- Machine-readable SBOM required at submission. CycloneDX or SPDX, with component support dates and known-vulnerability status.
- Postmarket duty
- Plan for monitoring, identifying, and addressing postmarket vulnerabilities, including a disclosure process and patch cadence commitments.
Where teams trip: The SBOM and the threat model must agree. Reviewers routinely issue deficiencies when a component in the SBOM never appears in the threat model or the vulnerability analysis.
European Union
Notified Bodies under MDR/IVDR, plus market surveillance authorities
MDR 2017/745 Annex I (GSPR 17.2, 17.4, 18.8) and IVDR 2017/746, read with MDCG 2019-16 Rev.1
In force since MDR application; enforced through Notified Body technical file review.
- What triggers it
- All software-containing devices. There is no separate “cyber device” test: security is a general safety and performance requirement for every class.
- Evidence expected
- Security requirements traced into the technical documentation, IT security risk management aligned with ISO 14971, minimum IT environment stated in the IFU, and verification evidence for the state of the art.
- SBOM
- Not named in MDR text, but MDCG 2019-16 expects a component inventory. In practice Notified Bodies now ask for an SBOM, and the CRA makes one mandatory.
- Postmarket duty
- Post-market surveillance and vigilance under Articles 83-88. Security incidents that affect safety are reportable serious incidents.
Where teams trip: MDR asks you to justify security decisions against the “state of the art,” which moves. A 2023 justification with no refresh is a common nonconformity.
European Union
European Commission / national market surveillance
Cyber Resilience Act (Regulation (EU) 2024/2847)
Entered into force December 2024. Reporting obligations apply from September 11, 2026; full obligations from December 11, 2027.
- What triggers it
- Products with digital elements placed on the EU market. Devices already certified under MDR/IVDR are largely carved out of the conformity route, but connected accessories, apps, cloud components, and non-device companion products often are not.
- Evidence expected
- Essential cybersecurity requirements in Annex I, secure-by-default configuration, vulnerability handling processes, and technical documentation covering the support period.
- SBOM
- Explicitly required. SBOM covering at minimum the top-level dependencies, retained for the support period.
- Postmarket duty
- 24-hour early warning to ENISA for actively exploited vulnerabilities and severe incidents, then a 72-hour notification and a final report.
Where teams trip: MedTech companies assume the MDR carve-out covers everything they ship. The patient-facing mobile app or the clinician web portal frequently falls under the CRA on its own.
China
NMPA (National Medical Products Administration)
Guideline for Medical Device Cybersecurity Registration Review (2022 revision), with the medical device software guideline
In force. Applies to registration and to significant change filings.
- What triggers it
- Devices with network connectivity or data exchange interfaces, including standalone software. Electronic data exchange, remote access, and user access control each trigger dedicated sections.
- Evidence expected
- A cybersecurity description document covering the network security capability, a risk assessment, verification records, and an explicit statement of the operating environment.
- SBOM
- A software component list is required, including off-the-shelf and open-source components with versions.
- Postmarket duty
- Update and patch plans must be described at registration, and significant security changes may require a change filing before deployment.
Where teams trip: Documentation must be in Chinese and align with the registration testing report. Translating a US submission verbatim is the fastest way to a supplemental request.
UK MDR 2002 (as amended), with the post-market surveillance statutory instrument in force from June 2025 and the future core regulations
Transitional. UKCA and CE routes both operate while the new framework phases in.
- What triggers it
- All software-containing devices marketed in Great Britain. Northern Ireland continues to follow EU MDR.
- Evidence expected
- Largely aligned with MDR expectations today: security in the risk file, state-of-the-art justification, and IFU disclosure of the intended IT environment.
- SBOM
- Not mandated by name; expected in practice where a device carries third-party software.
- Postmarket duty
- Strengthened PMS obligations, including trend reporting and periodic safety update reports for higher-risk devices.
Where teams trip: Teams treat GB as “EU minus paperwork.” The PMS timelines differ, and vigilance reporting goes to MHRA directly.
Pre-market Requirements for Medical Device Cybersecurity guidance
In force for Class II-IV licence applications.
- What triggers it
- Devices with software that can connect to a network or exchange data.
- Evidence expected
- Risk management aligned with ISO 14971, a security architecture description, verification and validation evidence, and a description of the cybersecurity risk controls.
- SBOM
- A list of software components, including off-the-shelf and open-source software, with version and support information.
- Postmarket duty
- Plans for patching and for communicating vulnerabilities to users, plus mandatory problem reporting.
Where teams trip: Health Canada accepts much of an FDA package, but wants the risk file to be traceable to ISO 14971 rather than to FDA guidance language.
MHLW notifications adopting IMDRF cybersecurity principles into the PMD Act framework
In force. Cybersecurity documentation is expected in Shonin/Ninsho applications.
- What triggers it
- Programme medical devices and connected hardware devices.
- Evidence expected
- IMDRF-aligned documentation: risk management, security requirements, verification, and labelling of the intended environment.
- SBOM
- SBOM expected in line with the IMDRF principles and legacy device guidance.
- Postmarket duty
- Ongoing vulnerability monitoring and reporting to the marketing authorisation holder's safety system.
Where teams trip: Japan leans hardest on the IMDRF wording. Structuring the package around IMDRF section names reduces review friction more than any translation effort.
Medical device cyber security guidance for industry and for users
In force, tied to the Essential Principles.
- What triggers it
- All software-containing and connected devices in the ARTG.
- Evidence expected
- Essential Principles 12.1 and 13 evidence, a cybersecurity risk assessment, and a statement of the operating environment and residual risks.
- SBOM
- Recommended, and requested during application audits for higher-risk devices.
- Postmarket duty
- Total product lifecycle expectations: monitoring, patching, and adverse event reporting where security affects safety.
Where teams trip: The TGA guidance mirrors FDA and IMDRF closely, so the same package usually works. Where it fails is labelling: Australia expects a plain-language security statement for users.
