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.
- Health Canada's 2019 pre-market cybersecurity guidance addresses relevant Class II, III, and IV licence applications; consult its scope and section 2.3 to determine applicable evidence.
- The guidance describes cybersecurity strategy, monitoring and response, and class-dependent licence-application information; do not treat an FDA-style SBOM checklist as a universal Canadian requirement.
- Application information and review depth vary by device class and applicable pathway; use current Health Canada licensing requirements rather than assuming a fixed cybersecurity review route.
- 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's 2019 pre-market cybersecurity guidance describes cybersecurity information for relevant Class II to IV licence applications. Map the device's classification, application evidence, labeling, and postmarket obligations to the Canadian Medical Devices Regulations; Section 59 and 60 set the criteria and timelines for 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. Health Canada's 2019 guidance describes secure design, device-specific risk management, verification and validation, and monitoring and response. Later standards such as IEC 81001-5-1:2021 and ANSI/AAMI SW96:2023 may be used as justified supporting frameworks; they are not references in the original 2019 guidance. Independent of any FDA work, manufacturers should document cybersecurity risk management, software components, secure design, testing, and a maintenance plan, with submitted content scaled to the application class 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 Guidance Scope
Use the scope described in Health Canada's 2019 pre-market cybersecurity guidance to determine whether it applies to a device and its licence application. Do not substitute Section 524B's statutory cyber-device test or assume that software or network connectivity alone creates an identical Canadian trigger. The evidence to include should be mapped to the guidance and the applicable application requirements.
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
Health Canada's 2019 guidance discusses risk management and cybersecurity evidence but predates IEC 81001-5-1:2021 and ANSI/AAMI SW96:2023; those later standards are not references in the original guidance. Manufacturers may use relevant standards as supporting frameworks, while determining applicable requirements from the Canadian guidance and regulations. Do not assume identical standards references or evidence expectations across Health Canada and FDA pathways.
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 optional 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.
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
See also: IMDRF Cybersecurity Guidance Explained, TGA Medical Device Cybersecurity, and MDSAP for Medical Device Compliance.
| Section 524B / Feb 3, 2026 guidance | Health Canada equivalent |
|---|---|
| Threat model and security risk assessment | Risk management content area |
| SBOM with optional 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
An MDEL applies to specified establishments, including importers and distributors, subject to regulatory exceptions. Mandatory problem-reporting duties under sections 59 and 60 apply to manufacturers and importers as specified by those provisions; holding an MDEL alone does not make every distributor a section 59 reporter. Establishments should route safety and cybersecurity complaints to the responsible manufacturer or importer and follow their applicable regulatory duties.
Common Gaps in Canadian Cybersecurity Submissions
When adapting a foreign cybersecurity package for Canada, check that the device classification, application information, labeling, and postmarket procedures match applicable Canadian requirements. Health Canada's guidance and the Medical Devices Regulations, not an asserted ranking of common review gaps, should determine what evidence and reporting obligations apply.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.
Pen Testing for Canadian Manufacturers
Canadian manufacturers do not need a Canadian testing firm, and they do not need to fly a test team in for most of the work. What matters to a Health Canada reviewer is the evidence: what was tested, how, what was found, and how each finding was resolved.
What Health Canada Expects from Security Testing
- Testing is part of verification and validation. Health Canada's 2019 guidance lists verification and validation testing as one of the six content areas. Penetration testing is the part of that evidence that shows the controls in your secure design hold up against a real attacker.
- Depth follows the licence class. For Class II, keep the test report on file and ready to produce on request. For Class III and IV, expect a reviewer to read the test summary, so it should trace each finding back to the threat model and the ISO 14971 risk file.
- Test what ships in Canada. Test the hardware, firmware, software versions, and accessories that match the Canadian licence application. If the Canadian configuration differs from the one tested for the FDA, flag the difference and either retest or justify why the earlier results still apply.
- Close the loop. Show how each finding was fixed, retested, or accepted with a documented rationale. Accepting the remaining risk is the manufacturer's decision, not the tester's.
How Remote Testing Works
- Cloud, web, mobile, and API components are tested remotely over the internet, against a test or staging environment you provide.
- Devices usually ship to our lab. We agree on the number of units, accounts, tools, and any test fixtures during the logistics step, before testing starts. Plan for customs paperwork and shipping time when sending units from Canada to the United States.
- On-site testing is available when a device cannot ship, for example a large installed system or one tied to hospital infrastructure. Travel adds to the cost, so we confirm it during scoping.
- One test, two markets. A pen test scoped for an FDA Section 524B submission can also support the Canadian licence application, as long as it covers the Canadian configuration. Scoping both markets at once avoids paying for a second round.
Pen testing for a simple device starts at about $15,000, with a fixed fee after a scoping call. See medical device penetration testing for how an engagement runs.
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 FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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 FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. 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.