Medical Device Cybersecurity Rules Compared: FDA, EU, Canada and Australia Side by Side

A connected device sold in the United States, the EU, Canada and Australia has to satisfy four regulators that ask for overlapping but differently shaped cybersecurity evidence, and a submission built for one market rarely passes the others unchanged. This page compares the rules a manufacturer meets in each market: section 524B of the US Federal Food, Drug, and Cosmetic Act with the FDA premarket cybersecurity guidance, the EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR) read with MDCG 2019-16, Health Canada's premarket cybersecurity guidance, and the Australian Essential Principles administered by the Therapeutic Goods Administration (TGA). It also places IEC 81001-5-1 where it belongs: not a market rule, but the lifecycle standard that can generate most of the evidence all four ask for. It is written for regulatory affairs leads, product security engineers and quality managers planning one technical file for several markets. Status checked on 14 November 2026 against the official texts listed at the end.

Key takeaways

• Only the US has a cyber-specific statute. Section 524B makes a postmarket vulnerability plan, secure processes, patching and an SBOM legal requirements for any "cyber device"; the EU and Australia reach cybersecurity through general safety and performance requirements, and Canada through guidance attached to licence applications.
• The SBOM is now universal, but its depth differs. The FDA expects a machine-readable SBOM with support level and end-of-support date per component; Health Canada asks for a cybersecurity bill of materials with versions and builds; MDCG 2019-16 recommends an SBOM as supporting documentation.
• Postmarket clocks come from vigilance law, not cyber law. In the EU a serious incident caused by a vulnerability is reported under MDR Article 87 within 15 days, or 2 days for a serious public health threat; the FDA instead asks for a justified patch cycle and out-of-cycle fixes for critical vulnerabilities.
• IEC 81001-5-1 is the common denominator. The FDA names it as one acceptable secure product development framework, and it covers the lifecycle activities the other three regulators expect, so building to it once reduces rework.
• Design for the strictest market, then subtract. An FDA-ready file (threat model, architecture views, test reports, SBOM, management plan) covers most of what the EU, Canada and Australia ask for; the reverse is rarely true.

Regulations and frameworks at a glance

Markets are listed by strength of legal basis, then the standard; the order is not a ranking.

For depth on each regime see the FDA Medical Device Cybersecurity Guide, the EU MDR Cybersecurity and MDCG 2019-16 Guide and the IEC 81001-5-1 Guide.

Scope: which devices each rule catches

Scope is where the four markets differ most, and where multi-market teams most often get caught out.

• United States: 524B applies to a "cyber device", which has three limbs: it includes software validated, installed or authorised by the sponsor, it can connect to the internet, and it has technological characteristics that could be vulnerable to cybersecurity threats. The 2026 guidance reads "software" to include firmware and programmable logic, and reads "ability to connect" broadly: intended or not, wired, wireless or brief. Its examples include Wi-Fi, cellular, Bluetooth and BLE, magnetic inductive links, and USB, Ethernet and serial ports. In practice very few powered devices with software fall outside it.
• European Union: no separate definition. The Annex I requirements apply to devices that incorporate electronic programmable systems and to software that is a device. MDCG 2019-16 adds interoperability and connection requirements (14.1, 14.2(d), 14.5) and lay-person use (22.1) to the cyber-relevant list, with IVDR equivalents in sections 16, 20 and 13.
• Canada: the cybersecurity strategy expectation covers all software-containing devices from Class I to IV, in vitro diagnostic or not, but the guidance asks for the documented evidence in licence applications for Class III and IV devices. Class IV adds a device-specific quality plan and full test reports.
• Australia: Essential Principle 12.1 covers programmed or programmable devices and software that is a device. Clause 12.1(5) is the cybersecurity hook. Clause 13B, which requires the current version and build number to be accessible to users, applied to new applications from 25 August 2020 and, under the transitional rules, to existing kinds of software devices from 1 November 2024.

Premarket evidence compared

The table maps each evidence item to what each regulator asks for. "Expected" means the document names it as content of a submission or technical file; "recommended" means the guidance suggests it.

For SBOM content and formats see the SBOM Guide, and for the security risk file see the AAMI TIR57 and SW96 Medical Device Risk Guide, which the FDA guidance cites for security risk management reports.

Postmarket duties and reporting clocks

A vulnerability found after launch triggers different machinery in each market. The cyber rule sets the expectation; the vigilance or recall rule sets the clock.

Design point: build one vulnerability intake and triage process that records an awareness timestamp and a safety assessment for every finding, because the EU clock starts at awareness and the FDA asks whether any uncontrolled-risk vulnerabilities were remediated since the last authorisation. The PSIRT Guide and the ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide cover the process itself.

Each regime in practice

United States: FDA and section 524B

• Threat model: multi-patient harm through networked devices and unpatched third-party software. The Multi-Patient Harm view exists because one compromised server or update channel can reach every device in the field.
• Structure: a statute with four duties, a guidance that turns them into documents, and the Quality Management System Regulation (21 CFR Part 820, which incorporates ISO 13485:2016) as the process anchor.
• Failure modes: an SBOM without support status, architecture views missing the update path, penetration testing by the design team, labelling that tells users nothing they can act on, and modifications filed without reassessing cybersecurity. The guidance treats changes to authentication, encryption, connectivity or update mechanisms as needing full documentation.
• Decision criterion: if the device meets the three cyber device limbs, plan the full documentation set; there is no lighter path by risk class.

European Union: MDR, IVDR and MDCG 2019-16

• Threat model: unauthorised access that affects safety or performance, and dependencies on the hospital IT environment. MDCG 2019-16 prefers "joint responsibility" between manufacturer, integrator, operator and user, while leaving the manufacturer's legal duties intact.
• Structure: binding Annex I requirements, a notified body that interprets them, and MDCG guidance that most notified bodies follow. The minimum IT requirements in 17.4 force the manufacturer to state what the operating environment must provide, and the device should not depend on that environment for its core security unless justified.
• Failure modes: minimum IT requirements written as a generic list, security risk kept separate from the ISO 14971 file, and vigilance procedures that do not treat an exploited vulnerability as a potential serious incident.
• Decision criterion: the notified body is the audience; align the technical file structure with Annex I section numbers so each requirement points to its evidence.

Canada: Health Canada premarket guidance

• Threat model: device compromise through known vulnerabilities and third-party components, managed within ISO 14971 safety risk.
• Structure: guidance that tells the reviewer what to expect under sections 32(3) and 32(4); section 35(1) lets Health Canada ask for more during screening or review. It cites AAMI TIR57:2016, UL 2900-1 and 2900-2-1, IEC 80001-1:2010 and NIST SP 800-30 Rev. 1, and predates IEC 81001-5-1.
• Failure modes: missing traceability matrix, Class IV files with summaries instead of full reports, and no marketing history of cybersecurity problems and recalls.
• Decision criterion: work out the class first. For Class III and IV, reuse the FDA package and add the traceability matrix and a declaration of conformity for any recognised standards applied.

Australia: Essential Principles 12.1 and 13B

• Threat model: unauthorised access, influence or manipulation of software and programmable devices.
• Structure: short, principle-based legal text, with the sponsor showing conformity through its technical documentation and declaration. Best practice is not defined in the regulation, so internationally recognised standards are the practical way to show it.
• Failure modes: treating the principle-based text as light-touch, and software devices that do not show the version and build number to users as clause 13B requires.
• Decision criterion: map the FDA or EU evidence to EP 12.1 and confirm the 13B display in the user interface; check the TGA's current guidance for industry before submission.

Where IEC 81001-5-1 fits

IEC 81001-5-1 is not a market rule, so it cannot be "complied with" instead of a regulation. It is the process that produces the threat model, security requirements, verification evidence, third-party component records and maintenance procedures every regime above asks for. The FDA names it as one acceptable SPDF framework. In the EU, using it to show state of the art does not depend on harmonisation; only the legal presumption of conformity does, so check the current list under Implementing Decision (EU) 2021/1182 (most recently amended on 9 November 2026). For product companies that also sell industrial products, the IEC 62443-4-1 and 4-2 Secure Product Development Guide covers the alternative framework the FDA names.

Worked scenario: one infusion pump, four markets

A manufacturer plans to launch a Wi-Fi connected infusion pump with a cloud dosing library service in all four markets within 12 months.

1. Classify and scope: the pump is a cyber device in the US (software, Wi-Fi, vulnerable characteristics). Elsewhere its higher risk class means a notified body in the EU and the full Canadian evidence pack.
2. Build once to IEC 81001-5-1: run the threat model across pump, dosing library server and update service; score risks by exploitability; feed safety impacts into the ISO 14971 file.
3. Produce the FDA set: four architecture views, a machine-readable SBOM with support dates, independent penetration test report, labelling and a cybersecurity management plan with justified patch cycles.
4. Derive the EU file: map the same evidence to Annex I 17.2, 17.4, 18.8 and 23.4(ab); write specific minimum IT requirements (network segmentation, supported Wi-Fi security modes, server hardening) for hospitals; attach the SBOM and an MDS2 form.
5. Derive the Canadian file: add a traceability matrix from risks to tests, include the full test reports, list standards with declarations of conformity, and record any cybersecurity-related marketing history.
6. Derive the Australian evidence: map to EP 12.1, confirm the version and build number appear in the pump's information screen (13B), and check the TGA guidance current at submission.
7. Run one postmarket process: one intake, awareness timestamps, a safety assessment per vulnerability, and market-specific reporting decisions, with the EU 15, 10 and 2 day clocks built into the workflow.

Choosing a strategy: decision guidance

Detection and measurement

• Submission first-pass rate: share of submissions per market accepted without a cybersecurity deficiency or additional information request.
• SBOM completeness: share of components with supplier, version, support level and end-of-support date populated.
• Time to patch: median days from vulnerability awareness to update availability, split by critical and non-critical (the FDA guidance itself suggests tracking percentage patched and time to patch).
• Vigilance timeliness: share of EU reportable events filed within the Article 87 deadline.

Common failure patterns

• Four separate files: separate threat models per market drift apart, so one vulnerability is assessed four ways.
• Narrow connectivity reading: assuming a device without Wi-Fi is outside 524B, when the FDA reads USB, serial and inductive links as connectivity.
• No awareness timestamp: vulnerability tickets that do not record when the manufacturer became aware, which makes the EU vigilance clock impossible to prove.
• Static SBOM: an SBOM generated for the submission and never refreshed, so end-of-support components go unnoticed until a reviewer or customer asks.

Framework mapping

Practitioner checklist

• Confirm for each device whether it meets all three 524B cyber device limbs, reading connectivity as broadly as the FDA guidance does.
• Adopt one secure development framework (IEC 81001-5-1 or ANSI/ISA 62443-4-1) and record it in the quality system.
• Maintain one threat model and security risk file linked to the ISO 14971 safety file, scored by exploitability.
• Generate a machine-readable SBOM with support level and end-of-support dates and refresh it with every release.
• Commission independent penetration testing and keep full reports for Canadian Class IV and FDA files.
• Write specific minimum IT requirements and residual risk statements for EU instructions for use.
• Run one vulnerability intake that records awareness time and safety impact, with EU Article 87 clocks built in.

Standards and references

• Cornell LII: 21 U.S. Code 360n-2, Ensuring cybersecurity of devices
• FDA: Cybersecurity in Medical Devices, Quality Management System Considerations and Content of Premarket Submissions
• European Commission: MDCG 2019-16 rev. 1, Guidance on Cybersecurity for Medical Devices
• EUR-Lex: Regulation (EU) 2017/745 on medical devices
• Health Canada: Pre-market Requirements for Medical Device Cybersecurity
• Federal Register of Legislation: Therapeutic Goods Legislation Amendment (2019 Measures No. 1) Regulations 2019
• Federal Register of Legislation: Therapeutic Goods (Medical Devices) Regulations 2002
• European Commission: Harmonised standards for medical devices

This guide summarises medical device cybersecurity requirements in the United States, the EU, Canada and Australia as of 14 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Healthcare Cyber Regulation Map · FDA Medical Device Cybersecurity Guide · EU MDR Cybersecurity and MDCG 2019-16 Guide · IEC 81001-5-1 Guide · Product Security Laws Map