On this page
Published: · Updated:
Key Takeaways
- Health Canada uses a four-class system (I through IV) that does not map one-to-one with FDA Class I/II/III.
- In vitro diagnostic devices are classified on their own ladder under the Part 2 Schedule 1 rules, and the cybersecurity evidence bar scales with that class.
- Pre-market cybersecurity evidence is required for Class II, III, and IV devices that include software or connectivity.
- The 2019 cybersecurity guidance covers risk management, SBOM, secure design, verification, and postmarket plans.
- Class II is an attestation-weighted route; Class III and IV licence applications get a real technical review of the cybersecurity file.
- MDSAP certification and foreign review reports shorten the assessment but never replace the Canadian classification rationale, labeling, or postmarket plan.
- Postmarket vigilance and mandatory problem reporting under Section 59 apply to cybersecurity incidents.
Health Canada reviews cybersecurity evidence as part of Class II to IV medical device licence applications under its pre-market cybersecurity guidance, with MDEL holders carrying distribution and reporting obligations. Most of an FDA Section 524B package carries over, but the classification rationale, risk documentation, labeling, and postmarket reporting must be mapped to the Medical Devices Regulations (SOR/98-282) and to Section 59 mandatory problem reporting.
Health Canada has aligned its medical device cybersecurity expectations with the broader international model used by the FDA, IMDRF, and the EU MDR. Manufacturers that already produce a Section 524B premarket cybersecurity package can reuse most of it, but Health Canada has its own classification model, a separate classification ladder for in vitro diagnostic devices, its own licensing pathway, and its own postmarket obligations. This post explains what the Medical Device Licence application requires for cybersecurity in 2026, how the evidence bar changes by class, how far foreign review reports and MDSAP certificates carry you, and where Canadian-specific obligations apply.
Why this matters
Health Canada is one of the most common second-market regulators for US-cleared medical devices. The Medical Devices Regulations (SOR/98-282) and the 2019 guidance "Pre-market Requirements for Medical Device Cybersecurity" set out the cybersecurity content expected in a Medical Device Licence application. The guidance aligns with IMDRF principles and references IEC 81001-5-1, AAMI TIR57 / ANSI/AAMI SW96:2023, and ISO 14971. Independent of any FDA work, manufacturers must produce cybersecurity risk management, an SBOM, secure design evidence, verification results, and a postmarket plan that fits Canadian vigilance reporting under Section 59 of the regulations. Skipping the mapping work and submitting an unmodified FDA package is a common cause of MDL review questions, particularly around the postmarket plan, the labeling, and the device classification justification.
Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA Cybersecurity resources for medical devices; FDA Cybersecurity in Medical Devices FAQs (Section 524B).
How Health Canada Classifies Medical Devices
Four Classes, Not Three
Health Canada classifies medical devices into Classes I, II, III, and IV by increasing risk. Class I devices are licence-exempt (the manufacturer needs an MDEL, the establishment licence) but Class II, III, and IV devices require a Medical Device Licence. Most connected devices that fall in FDA Class II land in Health Canada Class II or III; many implantables and life-sustaining devices land in Class IV.
The Cybersecurity Trigger
The 2019 cybersecurity guidance applies to Class II, III, and IV devices that contain software or that connect to other devices or networks. The depth of the cybersecurity package scales with the class and the connectivity profile, similar to how the FDA scales by the Section 524B definition and the device's attack surface.
How Health Canada Classifies IVD Devices
In vitro diagnostic devices (IVDDs) are classified in Canada on their own ladder, under the Part 2 rules in Schedule 1 of the Medical Devices Regulations, rather than under the Part 1 rules used for other devices. The class number looks the same (I through IV) but the reasoning is different: it turns on the consequence of a wrong result, not on invasiveness or duration of contact. Software that interprets specimen results inherits that framing, which changes what a threat model has to argue.
Decision Criteria
Work through these questions in order to place an IVDD:
- Is the product an IVDD at all? Reagents, calibrators, control materials, analyzers, and software intended to examine specimens taken from the body to provide diagnostic information are IVDDs. Software that only stores, routes, or displays results without interpreting them is generally regulated on the Part 1 ladder as software as a medical device.
- Who uses it? Near-patient and self-testing devices classify higher than the same assay run in a laboratory by a trained operator, because there is no professional filter between the result and the decision.
- What is the consequence of a wrong result for the individual? A false result that drives a life-threatening treatment decision, a missed serious diagnosis, or a transfusion error pushes the device up the ladder.
- What is the consequence at population scale? Detection of transmissible agents and screening of blood, tissue, and organ donations sit at the top of the scheme.
- Is it manufactured in-house by a laboratory? In-house IVDDs sit under a distinct oversight framework rather than the standard licensing route, with different evidence expectations.
The practical result:
| IVDD class | Risk framing | Typical examples | Licence expectation |
|---|---|---|---|
| Class I IVDD | Low individual and public health risk | Specimen receptacles, general culture media, general laboratory instruments | Licence-exempt, MDEL only |
| Class II IVDD | Moderate individual risk, low public health risk | Pregnancy self-tests, urinalysis analyzers, clinical chemistry assays | Licence application with attested evidence |
| Class III IVDD | High individual risk, moderate public health risk | Companion diagnostics, cancer markers, infectious disease staging assays | Full technical review of safety, effectiveness, and cybersecurity evidence |
| Class IV IVDD | High public health risk | Donor screening for HIV, HBV, HCV, blood grouping (ABO, Rh) | Full technical review plus heightened scrutiny of result integrity controls |
How IVDD Class Changes Cybersecurity Obligations
The six pre-market content areas apply to every connected IVDD, but the depth scales:
- Class I and II IVDD. A documented security risk assessment traced to ISO 14971, an SBOM for bundled and embedded software, secure configuration labeling, and a postmarket monitoring plan. Penetration testing is expected wherever the analyzer or middleware touches a network.
- Class III IVDD. Everything above plus a formal threat model that treats result integrity, quality-control bypass, and LIS or middleware interoperability as first-class harm scenarios, security architecture views, and verification evidence proportionate to a full technical review.
- Class IV IVDD. The Class III content plus population-scale harm analysis in the risk file (for example, a manipulated donor-screening result propagating into the blood supply), explicit controls over result transmission integrity, and a postmarket plan with defined vulnerability triage timelines across long installed lifetimes.
The recurring failure is a threat model that reasons only about device availability and uptime. For an IVDD the patient harm flows through a wrong result reaching a clinician, so integrity and authenticity of the result, not availability of the analyzer, is the harm axis a reviewer wants to see analyzed.
The Pre-market Cybersecurity Requirements
Six Content Areas
Health Canada's 2019 guidance lists six pre-market cybersecurity content areas: secure design, risk management, verification and validation testing, an SBOM, labeling for secure use, and a plan for managing postmarket cybersecurity risks.
The MDL application must include each of these explicitly, even when the manufacturer is using US, EU, or IMDRF documentation.
How the Content Maps to Standards
The guidance references IEC 81001-5-1 for security activities in the software lifecycle, AAMI TIR57 / ANSI/AAMI SW96:2023 for security risk management, and ISO 14971 for overall risk management. These are the same anchor standards the FDA points to, which is why the technical content set overlaps so heavily. The mapping in the application package matters: Health Canada reviewers expect to see the standards-to-evidence trace, not just an assertion of compliance.
Licence Evidence Routes by Class
Classification tells you the risk tier. The licence route tells you how much of the cybersecurity file a reviewer actually reads before a licence issues. Manufacturers who get the class right and the route wrong still end up in an additional information request.
| Class | Licence route | Depth of review | Cybersecurity evidence a reviewer expects |
|---|---|---|---|
| Class I | No licence, MDEL for the establishment | None pre-market | Evidence held internally, produced on inspection or complaint |
| Class II | Licence application with manufacturer attestations and a QMS certificate | Administrative and attestation-weighted | Security risk assessment, SBOM, secure use labeling, postmarket plan, all citable on request |
| Class III | Licence application with a summary of studies and technical evidence | Substantive technical review | Threat model, secure design rationale, SBOM with VEX, verification and penetration testing summaries, postmarket cybersecurity plan |
| Class IV | Licence application with full safety and effectiveness evidence and a risk assessment | Deepest technical review | Class III content plus explicit patient-harm linkage in the ISO 14971 file, architecture views, and control-level verification evidence |
| Class II IVDD | Licence application with attested evidence | Attestation-weighted | Risk assessment, SBOM, labeling, postmarket monitoring plan |
| Class III and IV IVDD | Licence application with full evidence | Substantive to deep review | Result integrity threat model, LIS and middleware interface analysis, testing evidence, transmission integrity controls |
What This Means in Practice
Three route-driven behaviors are worth planning for.
Class II is attested, not unexamined. The lighter pre-market review does not lower the evidence bar, it defers when the evidence is read. A complaint, a recall, or an MDSAP audit will surface a thin risk file, and by then the device is on the market.
Class III and IV files get read line by line. Cybersecurity gaps that survived a notified body review or an FDA clearance can surface here, most often as a threat model that is not traceable back into the ISO 14971 risk management file.
Security changes can be licence-amendment triggers. Adding an update mechanism, changing the authentication architecture, or altering the network interface can be a significant change requiring a licence amendment before the change reaches the Canadian market. Build that trigger into change control rather than discovering it during a postmarket update.
Relying on MDSAP and Foreign Review Reports
Canada is the jurisdiction where MDSAP is mandatory: a Class II, III, or IV licence requires a valid MDSAP certificate issued by a recognized auditing organization. That certificate carries the quality system, and by extension the software lifecycle and security risk management procedures that IEC 81001-5-1 and ANSI/AAMI SW96:2023 sit inside. Health Canada also accepts foreign review information as supporting evidence in a licence application. Both are reliance mechanisms, not recognition mechanisms: the decision stays with Health Canada.
What Reliance Can and Cannot Do
- Can support: the security risk assessment, threat model, secure design rationale, SBOM, verification and penetration testing evidence, and the process evidence behind the software lifecycle.
- Cannot replace: the Canadian classification rationale, the labeling in both official languages where required, the Section 59 postmarket plan, and the licence application content itself.
- Does not transfer automatically: conditions, restrictions, or postmarket commitments imposed by a foreign regulator. Disclose them and let Health Canada decide whether equivalent conditions apply.
See also: IMDRF Cybersecurity Guidance Explained, TGA Medical Device Cybersecurity, and MDSAP for Medical Device Compliance.
An MDSAP certificate demonstrates that your processes conform. It does not demonstrate that this device's cybersecurity evidence is complete. Those are separate arguments, and the licence application has to make the second one.
Practical Guidance for Citing Foreign Evidence
- Confirm the foreign report covers the same device, same intended use, and same manufacturing sites as the Canadian application.
- Cite the decision document by name, date, and reference number, and attach it rather than summarizing it.
- Provide a crosswalk table from the foreign content structure (Section 524B slots, or EU GSPR 17 and Annex I) to the six Canadian content areas.
- Flag every delta: differences in configuration, connectivity, bundled software versions, or accessories between the foreign-approved device and the Canadian one.
- Refresh the SBOM to the version shipping in Canada, not the version submitted abroad.
- Restate the postmarket plan against Section 59 timelines and decision criteria rather than 21 CFR Part 803.
- Disclose any foreign conditions of approval, field actions, or cybersecurity-related recalls tied to the device.
How an FDA Section 524B Package Maps to an MDL
Direct Reuse
| Section 524B / Feb 3, 2026 guidance | Health Canada equivalent |
|---|---|
| Threat model and security risk assessment | Risk management content area |
| SBOM with VEX | SBOM content area |
| Security architecture views | Secure design content area |
| Security testing, including pen testing | Verification and validation testing |
| Labeling for secure use | Labeling for secure use |
| Postmarket cybersecurity management plan | Plan for managing postmarket cybersecurity risks |
What Needs Adaptation
The postmarket plan needs to reference Health Canada's mandatory problem reporting requirements under Section 59 of the Medical Devices Regulations, not the FDA's 21 CFR Part 803 MDR pathway. The labeling needs to satisfy Canadian language and content requirements. The classification rationale needs to reflect the Health Canada classification rules, which are based on the IMDRF risk classification model and differ from the FDA approach.
Postmarket and MDEL Obligations
Section 59 Mandatory Problem Reporting
Manufacturers and importers must report incidents to Health Canada that result in or could result in death or serious deterioration in health. Cybersecurity incidents that meet that criterion are reportable. The postmarket plan must describe the decision criteria, the timeline, and the owner.
MDEL and Importer Responsibilities
The Medical Device Establishment Licence (MDEL) is held by importers, distributors, and Class I manufacturers. MDEL holders share responsibility for postmarket vigilance, including cybersecurity incidents that surface through customer channels. The IR plan and CVD policy referenced in the MDL submission should make these handoffs explicit.
Common Gaps in Canadian Cybersecurity Submissions
The most frequent gaps in Health Canada cybersecurity submissions are an FDA postmarket plan dropped in without Section 59 mapping, a classification rationale that uses FDA Class II/III language instead of the Canadian Class II/III/IV rules, an IVDD placed on the Part 1 ladder by mistake, and labeling that does not meet Canadian content or language requirements. Reviewers also look for the SBOM format and freshness; submissions that include an SBOM generated years before the application date draw questions about the postmarket monitoring process.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.
How Blue Goat Approaches Health Canada Submissions
We treat Health Canada submissions as a content-mapping and adaptation exercise rather than a from-scratch rewrite when the manufacturer already has a Section 524B package. The cybersecurity package keeps the same threat model, SBOM, architecture views, and verification evidence, with adaptations for the Canadian classification rationale, Section 59 postmarket reporting, and labeling content. Our team holds CISSP, OSCP, and prior military red-team credentials, and our submission work is grounded in IEC 81001-5-1, AAMI TIR57 / ANSI/AAMI SW96:2023, ISO 14971, and the FDA February 3, 2026 final premarket cybersecurity guidance. If the regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our international medical device cybersecurity services or compare regimes on the EU MDR vs FDA cybersecurity guide.
If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity support.
Related reading: CE Marking Medical Devices: What EU MDR Actually Requires.
FAQ
Does Health Canada require an SBOM?
Yes. The 2019 pre-market cybersecurity guidance lists SBOM as one of the six required content areas for Class II, III, and IV devices with software or connectivity. The format is not prescribed but CycloneDX and SPDX are the common choices, mirroring international practice.
Is the FDA Section 524B package sufficient for an MDL?
The technical content is largely reusable, but the postmarket plan, classification rationale, and labeling need Canadian-specific adaptation. Submitting an unmodified FDA package is the most frequent cause of reviewer questions on cybersecurity content.
What is Section 59 of the Medical Devices Regulations?
Section 59 establishes mandatory problem reporting obligations for manufacturers and importers. Incidents that result in or could result in death or serious deterioration in health must be reported to Health Canada within defined timelines. Cybersecurity incidents that meet the threshold are reportable.
How does Health Canada classification differ from FDA classification?
Health Canada uses four classes (I through IV) based on IMDRF risk classification rules. FDA uses three classes (I, II, III) under 21 CFR Part 860. The two systems are not interchangeable: a device that is FDA Class II may be Health Canada Class II, III, or IV depending on the rules that apply.
Does the MDEL require its own cybersecurity content?
The MDEL is an establishment licence held by importers, distributors, and Class I manufacturers. It does not require a cybersecurity submission, but MDEL holders share postmarket vigilance responsibilities under Section 59, including for cybersecurity incidents.
How are IVD devices classified differently in Canada?
IVD devices are classified under the Part 2 rules in Schedule 1 of the Medical Devices Regulations, based on the consequence of a wrong result for the individual and for the population, rather than on invasiveness. Class III and IV IVDDs receive a full technical review, so the cybersecurity file has to argue result integrity and LIS interface security, not just device availability.
Does a valid MDSAP certificate cover our cybersecurity evidence?
No. MDSAP is mandatory for Class II, III, and IV licences and demonstrates that your quality system and software lifecycle processes conform. The device-specific cybersecurity evidence, threat model, SBOM, testing results, and postmarket plan still have to appear in the licence application.
Can we cite our FDA clearance instead of resubmitting the evidence?
Foreign review information is accepted as supporting evidence, but it is a reliance pathway rather than recognition. You still owe the Canadian classification rationale, bilingual labeling where required, a Section 59 postmarket plan, and a crosswalk from the Section 524B content to the six Canadian content areas.
Does changing a security control require a licence amendment?
Often, yes. Adding an update mechanism, changing the authentication architecture, or altering the network interface can constitute a significant change requiring an amendment before the change reaches the Canadian market. Treat security architecture changes as a change-control trigger.
Ready to bring your device to the Canadian market?
If you have an FDA-cleared connected device and need a Health Canada MDL with a cybersecurity package that maps cleanly from your Section 524B content, we can help. If the regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber. Christian has led international medical device cybersecurity programs across FDA, Health Canada, and EU MDR pathways and previously commanded military red-team operations. Read more at christian-espinosa.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
