IMDRF Cybersecurity Guidance Explained

The International Medical Device Regulators Forum (IMDRF) is a voluntary group of medical device regulators that publishes consensus documents its members then adopt in their own frameworks. For cybersecurity, that matters more than it sounds: the six-content-area structure you see in the FDA's February 3, 2026 final premarket cybersecurity guidance, in the TGA's cyber security guidance for industry, and in Health Canada's pre-market cybersecurity guidance is recognizably the same structure, because all three trace back to IMDRF work. This post explains which IMDRF documents actually govern cybersecurity content, how each regulator implements them, and how to build a submission package designed from the start to be reused.

Why this matters

Manufacturers rarely stop at one market. A device cleared in the US typically follows with Health Canada, the TGA, and the EU within eighteen months. If the cybersecurity evidence was written as an FDA artifact rather than as a device artifact, each of those follow-on submissions turns into a rewrite, and every rewrite is a chance for the versions to drift apart. When a reviewer in one jurisdiction reads a threat model that contradicts the SBOM filed in another, the question that comes back is not a formatting question.

The opposite is also true and is the reason IMDRF is worth understanding. Because the underlying content areas converge, a package built to the IMDRF structure can serve four markets with a mapping document per market rather than four separate evidence sets. The work is in knowing exactly where the convergence stops.

What IMDRF Is, and What It Is Not

IMDRF was established in 2011 as the successor to the Global Harmonization Task Force. Its members are regulators: the US FDA, Health Canada, the European Commission, Japan's MHLW and PMDA, Australia's TGA, Brazil's ANVISA, China's NMPA, South Korea's MFDS, Singapore's HSA, the UK's MHRA, and others, with affiliate and observer bodies including the WHO.

Two properties define what IMDRF documents can do for you:

• They are non-binding. No manufacturer is ever inspected against IMDRF N60. You are inspected against the regulation that adopted its content.
• They are the shared vocabulary. When the TGA guidance and the Health Canada guidance both expect "a plan for managing postmarket cybersecurity risks," that phrasing is not a coincidence.

The practical consequence: cite IMDRF in your rationale to explain why your structure looks the way it does, but never cite it in place of the jurisdiction's own requirement. A submission that argues "this satisfies IMDRF N60" without mapping to the local regulation is the fastest way to an information request.

The IMDRF Cybersecurity Documents That Matter

N60 is the one to read first. If you can trace every artifact in your package to an N60 principle, you will find that the FDA, TGA, and Health Canada content areas are each a re-cut of the same material.

How Each Regulator Implements IMDRF Cybersecurity Content

The pattern is consistent. The technical content converges; the container, the classification logic, and the postmarket reporting obligations do not.

What Harmonizes and What Does Not

Harmonizes well, reuse directly:

• Security risk assessment and threat model, when built to ISO 14971 with AAMI TIR57 / ANSI/AAMI SW96:2023 security risk methodology
• Security architecture views and secure design rationale
• SBOM content, when generated to the N73 minimum elements in CycloneDX or SPDX
• Verification and penetration testing evidence
• Software lifecycle process evidence under IEC 81001-5-1 and IEC 62304

Does not harmonize, rewrite per market:

• Classification rationale. FDA Class II is not Health Canada Class II and is not TGA Class IIa. Each application needs its own class argument under its own rules.
• Labeling. Content, format, and language obligations differ. Canada has bilingual requirements; Australia has its own instructions-for-use expectations; the FDA expects specific cybersecurity labeling elements.
• Route and certification. MDSAP is mandatory in Canada, optional elsewhere. The TGA runs a comparable overseas regulator framework. The EU runs notified bodies. None of these substitute for each other.
• Incident reporting. 21 CFR Part 803 in the US, Section 59 in Canada, URPTG and TGA reporting in Australia, MDR vigilance in the EU. Timelines and thresholds differ.
• Statutory hooks. Section 524B has no equivalent elsewhere. Do not write a package that assumes it does.

Building One Package That Travels

See also: Health Canada Cybersecurity Requirements, TGA Medical Device Cybersecurity, and MDSAP for Medical Device Compliance.

Work through these steps in order:

1. Write the evidence to the IMDRF N60 content model, not to a submission template. Threat model, security risk assessment, architecture views, SBOM, verification results, labeling content, postmarket plan.
2. Generate the SBOM to the N73 minimum elements in a machine-readable format, with a documented regeneration trigger tied to each release.
3. Keep one master risk file. Every jurisdiction traces to the same ISO 14971 file. Divergent risk files are how contradictions reach reviewers.
4. Write a per-market mapping document. A short table from your artifact names to that regulator's content areas. This is the deliverable most manufacturers skip and most reviewers ask for.
5. Write the classification rationale fresh per market. Never carry the FDA class argument into a Canadian or Australian application.
6. Fork only the postmarket plan. Keep one plan with a jurisdiction annex covering reporting thresholds, timelines, and the named responsible party for each market.
7. Version everything together. When the threat model changes, every downstream market file gets a change record, even if the change is "no impact."

Legacy Devices and the N70 Problem

N70 is the document manufacturers discover late. It defines lifecycle stages for a device already in the field: supported, limited support, and end of support, with an expectation that the manufacturer communicates transitions and shares responsibility for residual risk with the operating healthcare organization.

This matters because the fleet is the exposure. A device cleared before cybersecurity expectations tightened is still deployed, still connected, and still yours until you formally define its support status. N70 gives you the structure to say so: publish the end-of-support date, state what security maintenance continues and what stops, and document the compensating controls a hospital is expected to apply. Regulators increasingly expect that communication to exist, and hospital procurement teams read it during renewal decisions.

The practical move is to treat the support-status statement as a controlled document alongside the postmarket cybersecurity plan rather than as marketing communication.

How Blue Goat Approaches Multi-Market Cybersecurity Packages

We build the evidence set once, to the IMDRF content model, and then write the per-market mapping layer. The threat model, SBOM, architecture views, and verification evidence stay singular and version-controlled; the classification rationale, labeling, and postmarket annexes are written per jurisdiction. Our team holds CISSP, OSCP, and prior military red-team credentials, and the work is grounded in IEC 81001-5-1, AAMI TIR57 / ANSI/AAMI SW96:2023, ISO 14971, and the FDA February 3, 2026 final premarket guidance. See our medical device cybersecurity services, or compare specific regimes in the TGA guide, the Health Canada guide, and the EU MDR vs FDA comparison.

If a regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

FAQ

Is IMDRF guidance mandatory?

No. IMDRF is a forum of regulators, not a regulator. Its documents are non-binding consensus guidance. They become enforceable only through the national regulation or guidance that adopts them, such as the FDA's Feb 3, 2026 guidance, Health Canada's pre-market cybersecurity guidance, or the TGA's cyber security guidance for industry.

Which IMDRF document covers medical device cybersecurity?

Three do. N60 covers general principles and practices for medical device cybersecurity across the total product lifecycle, N70 covers legacy devices and end-of-support, and N73 covers SBOM principles and practices. N60 is the one that shaped the premarket content areas used by the FDA, the TGA, and Health Canada.

Can we submit the same cybersecurity package to the FDA, Health Canada, and the TGA?

The technical evidence is largely reusable: threat model, security risk assessment, architecture views, SBOM, and verification results. What must be written per market is the classification rationale, the labeling, the postmarket plan against local reporting rules, and a mapping document showing how the evidence satisfies that jurisdiction's content areas.

Does IMDRF define device classification?

IMDRF inherited and maintains a risk-based classification model that several members implement directly. Health Canada's four-class system and the TGA's classification rules both derive from it, which is why neither maps cleanly onto the FDA's three-class system under 21 CFR Part 860.

What is IMDRF N73 and how does it differ from FDA SBOM expectations?

N73 sets out SBOM minimum elements, generation and maintenance practices, and how manufacturers should distribute SBOMs to operators. The FDA's expectations under Section 524B are compatible but more prescriptive about submission format and about pairing the SBOM with vulnerability assessment and VEX content. An SBOM built to N73 will generally satisfy the FDA with additional support-level and end-of-support fields.

How does MDSAP relate to IMDRF?

MDSAP grew out of IMDRF work on a single audit model and is now run by participating regulators including the FDA, Health Canada, the TGA, ANVISA, and Japan's MHLW and PMDA. It audits the quality management system, so it covers the processes behind your security lifecycle, not the device-specific cybersecurity evidence in any given submission.

Related reading

• MDSAP for Medical Devices
• TGA Medical Device Cybersecurity
• Health Canada Medical Device Cybersecurity