IMDRF's Principles and Practices for Medical Device Cybersecurity, explained

The International Medical Device Regulators Forum was established in 2011 as the successor to the Global Harmonization Task Force (GHTF), a 1992 initiative among the US, EU, Japan, Canada and Australia that lacked a formal governance structure. Per TGA's own description, IMDRF is "a voluntary group of medical device regulators from around the world" — it does not approve or reject any product, and its current Management Committee membership spans Australia, Brazil, Canada, China, the EU, Japan, Russia, Singapore, South Korea and the US, with the World Health Organization as an official observer. IMDRF's working groups produce technical guidance on topics like adverse-event coding, unique device identification, software, and — since 2019 — cybersecurity; none of that guidance has independent legal force in any member jurisdiction. It becomes relevant only to the extent an individual regulator chooses to cite, adopt, or align its own binding rules with it.

Per IMDRF's stated purpose, N60 provides general principles and best practices "to facilitate international regulatory convergence on medical device cybersecurity," covering devices that contain or are composed of software — not only devices with network connectivity. Its structural signature, repeatedly noted by secondary sources that reviewed the final text, is combining premarket and postmarket recommendations inside a single document built around the TPLC concept: a security risk management process meant to identify, evaluate and control cybersecurity risk continuously, from initial device conception through end of support, rather than as a premarket gate followed by a separate postmarket obligation. The premarket section is aimed mainly at manufacturers — security requirements and design, risk management, security testing, labelling, and what to document in a regulatory submission. The postmarket section is broader, addressing manufacturers, regulators and healthcare providers together on information sharing, coordinated vulnerability disclosure, patch and update management, and — a concept N60 introduced and later guidance built on — legacy devices, defined as devices that cannot be reasonably protected against current and future cybersecurity threats through updates. That legacy-device definition, and the broader SBOM concept N60 touches on, were later expanded into IMDRF's own follow-on documents: N70 (legacy medical device cybersecurity, finalized 2023) and N73 (software bill of materials, finalized 2023).

FDA was one of the two agencies (alongside Health Canada) that led the N60 working group, and FDA's own cybersecurity guidance documents cite N60 directly — including, per analyses of FDA's guidance footnotes, sourcing FDA's own "legacy device" definition to IMDRF's N60 text and linking directly to IMDRF's PDF. FDA has described its guidance as "well-aligned" with IMDRF's 2020 document, and both documents share the TPLC framing, even though FDA continues to publish separate premarket and postmarket guidance documents rather than combining them the way N60 does. See FDA premarket cybersecurity for medical devices for the Section 524B statutory duties — SBOM, vulnerability-monitoring plan, patch process — that sit inside FDA's own binding framework, and FDA postmarket cybersecurity for medical devices for FDA's 2016 postmarket guidance that N60's postmarket section parallels structurally. IMDRF alignment does not change what FDA actually requires in a 510(k) or PMA submission; it explains why FDA's vocabulary (legacy devices, TPLC, coordinated disclosure) looks the way it does.

The relationship on the EU side is more indirect. MDCG 2019-16, the EU's own non-binding cybersecurity guidance under MDR/IVDR, does not appear to cite N60's cybersecurity-principles text by name in available summaries of its content. What it does cite is a separate, older IMDRF output — the IMDRF Adverse Event Terminology coding system — routing cybersecurity-related vigilance reports through IMDRF device-problem code A110502 ("Computer System Security Problem," further split into application-security and unauthorized-access sub-codes) and root-cause code C1007 ("Software Security Vulnerability"). That is a narrower, reporting-taxonomy link rather than a substantive endorsement of N60's TPLC framework, but it shows IMDRF's standards infrastructure threaded through EU practice even where N60 itself isn't the direct reference. The EU's binding cybersecurity text remains MDR Annex I, interpreted through MDCG 2019-16 — neither of which IMDRF's guidance can substitute for.

IMDRF sits at the bottom row of this table by design: it has no enforcement mechanism of its own in any jurisdiction. Its function is to give FDA, the European Commission, Health Canada, Japan's PMDA, Australia's TGA and other member regulators a shared technical vocabulary and structural template to draw from when each writes its own binding or guidance text — not to replace any of those texts.