Global regulatory map

Medical device cybersecurity guidelines, market by market.

Eight regulators, one comparison. What triggers the requirement, what evidence each authority reads, whether an SBOM is mandatory, and what you owe after launch.

Direct answer

Medical device cybersecurity requirements have converged on the same engineering evidence worldwide (a security risk assessment traced to ISO 14971, a documented threat model, a machine-readable SBOM, and a postmarket vulnerability process) but they diverge on legal instrument, submission format, and reporting clocks. Build one evidence base, then add a thin jurisdiction wrapper for each market rather than running parallel programs.

Jurisdictions Where they converge Build once, file everywhere FAQ

Eight regulators

What each authority actually asks for

Current as of July 2026. Where a regime is still phasing in, the status line gives the date that matters.

United States

FDA (CDRH)

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: SBOM required at submission (statutory). Machine-readable formats such as CycloneDX or SPDX are recommended, 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.

United Kingdom

MHRA

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.

Canada

Health Canada

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.

Japan

PMDA / MHLW

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.

Australia

TGA

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.

Where they converge

Four things every regulator now expects

Threat modeling is now table stakes

The FDA, Health Canada, the TGA, and PMDA all expect a documented, method-driven threat model. STRIDE with data flow diagrams is the default because reviewers can follow it. Build it once and reuse it everywhere.

SBOM is converging on machine-readable

The FDA mandates it, the CRA mandates it, NMPA and Health Canada want component lists, and Notified Bodies increasingly ask. One CycloneDX SBOM with support dates and VEX satisfies most of the world.

Postmarket is where the regimes diverge

Reporting clocks differ sharply: the CRA wants a 24-hour early warning to ENISA, the FDA works through the existing MDR/vigilance channels, and NMPA may require a change filing before you ship a fix.

Everything traces back to ISO 14971

Security risk has to land in the safety risk file. ANSI/AAMI SW96:2023 is the bridge, and it is recognized or referenced in most of the regimes above.

Build once, file everywhere

Six artifacts that carry across markets

This is the sequencing we use with clients planning a multi-market launch. Each artifact is authored once and annotated per jurisdiction.

Cybersecurity artifacts and the regulators that accept them
Artifact	Accepted by	How to keep it portable
Security risk assessment (ISO 14971 + ANSI/AAMI SW96)	FDA, EU MDR, Health Canada, TGA, PMDA, NMPA	The single most portable artifact. Keep the hazard analysis method-neutral and add jurisdiction annexes.
STRIDE threat model with data flow diagrams	FDA, Health Canada, TGA, PMDA; supports MDR state-of-the-art justification	Keep trust boundaries and assets stable across releases so the model is auditable over time.
CycloneDX SBOM with support dates and VEX	FDA, CRA, NMPA, Health Canada	Generate it in CI, not by hand. A stale SBOM is worse than a thin one.
Penetration test report	FDA, EU MDR (state of the art), TGA	Scope it to the interfaces in the threat model, and include the retest of every remediated finding.
Coordinated vulnerability disclosure policy	FDA, CRA, MDR postmarket, TGA	Publish it publicly. The CRA reporting clock starts whether or not you have a process.
Postmarket monitoring and patch plan	Every regime on this page	Jurisdiction-specific timelines belong in an appendix table, not scattered through the narrative.

FAQ

Common questions about global requirements

Are medical device cybersecurity requirements the same worldwide?

No. The underlying engineering expectations have converged around IMDRF principles, threat modeling, and SBOM, but the legal instruments, the submission format, and the postmarket reporting clocks differ. The FDA enforces Section 524B at acceptance review, the EU splits obligations between MDR and the Cyber Resilience Act, and NMPA reviews a Chinese-language cybersecurity description at registration.

Does an FDA cybersecurity package satisfy EU MDR?

Partially. The risk assessment, threat model, SBOM, and test evidence transfer well. What does not transfer is the framing: MDR wants the security argument expressed against the General Safety and Performance Requirements and justified against the state of the art, and it wants the intended IT environment in the instructions for use.

Does the Cyber Resilience Act apply to medical devices?

Devices certified under MDR or IVDR are largely exempt from the CRA conformity route, but the exemption is narrower than most teams assume. Companion mobile apps, clinician portals, cloud services, and accessories that are not themselves regulated devices can fall under the CRA directly, with reporting obligations from September 11, 2026.

What does NMPA require that the FDA does not?

A standalone cybersecurity description document in Chinese that matches the registration testing report, an explicit statement of the operating environment, and a change filing when a security update materially alters the registered software.

Which artifact should we build first for a multi-market launch?

The security risk assessment traced to ISO 14971, then the STRIDE threat model. Every regime on this page consumes both, and they drive the scope of the SBOM work and the penetration test.

Go deeper

Secure your device before it reaches patients.

30-minute strategy session. No cost, no commitment - just answers from people who've supported 275+ FDA submissions, with zero cybersecurity rejections.

Book strategy session Explore services

Medical device cybersecurity guidelines, market by market.

What each authority actually asks for

United States

European Union

European Union

China

United Kingdom

Canada

Japan

Australia

Four things every regulator now expects

Threat modeling is now table stakes

SBOM is converging on machine-readable

Postmarket is where the regimes diverge

Everything traces back to ISO 14971

Six artifacts that carry across markets

Common questions about global requirements

Are medical device cybersecurity requirements the same worldwide?

Does an FDA cybersecurity package satisfy EU MDR?

Does the Cyber Resilience Act apply to medical devices?

What does NMPA require that the FDA does not?

Which artifact should we build first for a multi-market launch?

Related reading

EU MDR vs FDA cybersecurity

FDA pathways and device classes

STRIDE threat modeling

FDA SBOM requirements

Regulatory tracker

All resources

Secure your device before it reaches patients.