Standards & Regulations
A mapping you can check, clause by clause.
Both halves of the guidance, not just the submission
Health Canada asks for two different things: a cybersecurity strategy every device from Class I to Class IV should have, and specific content inside a Class III or Class IV licence application. All 26 expectations are mapped below, each with the section it comes from.
Four kinds of work, across all twenty-six
Some expectations are answered by process and documentation, some by SBOM and vulnerability management, some by cryptography and update integrity, and some by expert review that genuinely takes a person rather than a tool. The mapping tags each one with what it needs.
Built on the standards the guidance cites
Health Canada points manufacturers at AAMI TIR57, ISO 14971, and IEC 62304 rather than writing its own control set. Those are the standards our model already folds together, alongside a bench that includes former FDA reviewers and HSCC JSPv2 co-authors.
Health Canada pre-market cybersecurity guidance
Twenty-six expectations, and what answers each.
Grouped as the guidance groups them and ordered as it orders them, so you can read this alongside your own copy. Sections 2.1 and 2.2 apply to every device class; Section 2.3 applies to Class III and Class IV licence and amendment applications.
Guidance Document: Pre-market Requirements for Medical Device Cybersecurity. Adopted 17 June 2019, effective 26 June 2019 (PDF)
16
Secure development & documentation
Process, design controls, and the records a submission needs
7
SBOM & vulnerability management
Component inventory and triage across the device lifetime
4
Cryptography & update integrity
Keys, signing, encryption, and secure updates
6
Expert review
Threat modelling and architecture review by people
All 26 categories are mapped. Some are answered by more than one kind of work, so these figures sum to more than 26.
Find your clause
Every category, its section reference, and what answers it. Select one to read the guidance’s own words and our response beside it.
Showing 26 of 26 categories
Section 2
A strategy for the device's cybersecurity risk
Development & docsHealth Canada guidance: Additionally, a manufacturer must have a strategy to address the cybersecurity risk of a medical device (Class I to Class IV) that runs software code.
Medcrypt solution: Medcrypt supplies the strategy as an implemented process rather than a policy document: secure design, risk management, verification and validation, and the monitoring plan, each with the records behind it.
Appendix A
Cybersecurity risk management framework
Development & docsExpert reviewHealth Canada guidance: Manufacturers should consider the NIST “Framework for Improving Critical Infrastructure Cybersecurity” as a blueprint of best practices to guide their cybersecurity activities, including those related to risk management. Health Canada has identified the following five core functions of the framework relate specifically to medical device design controls.
Medcrypt solution: Medcrypt maps device work onto the five NIST functions Health Canada names (identify, protect, detect, respond, recover), so the framework claim in an application is backed by evidence per function.
Section 2
A strategy for the device's cybersecurity risk
Development & docsHealth Canada guidance: Additionally, a manufacturer must have a strategy to address the cybersecurity risk of a medical device (Class I to Class IV) that runs software code.
Medcrypt solution: Medcrypt supplies the strategy as an implemented process rather than a policy document: secure design, risk management, verification and validation, and the monitoring plan, each with the records behind it.
Appendix A
Cybersecurity risk management framework
Development & docsExpert reviewHealth Canada guidance: Manufacturers should consider the NIST “Framework for Improving Critical Infrastructure Cybersecurity” as a blueprint of best practices to guide their cybersecurity activities, including those related to risk management. Health Canada has identified the following five core functions of the framework relate specifically to medical device design controls.
Medcrypt solution: Medcrypt maps device work onto the five NIST functions Health Canada names (identify, protect, detect, respond, recover), so the framework claim in an application is backed by evidence per function.
Section 2.1.1
Cybersecurity considered early in the life-cycle
Development & docsHealth Canada guidance: Manufacturers should consider cybersecurity early in the product life‐cycle when design requirements are being developed. This includes cybersecurity risks and controls when making design choices; and design choices that maximize device cybersecurity while not excessively affecting other safety‐related aspects of the medical device (e.g., usability).
Medcrypt solution: Medcrypt puts security requirements into the design inputs at specification time, which is the point the guidance names, rather than assessing a finished design.
Section 2.1.1
Design inputs cross-referenced to cybersecurity hazards
Development & docsHealth Canada guidance: Design inputs captured in a requirement specification should include those related to cybersecurity. Where applicable, these cybersecurity requirements should be cross‐referenced to specific device cybersecurity hazards if the requirements are mitigations to identified hazards.
Medcrypt solution: Medcrypt maintains the link from each security requirement back to the hazard it mitigates, which is what makes the traceability matrix in Section 2.3.5.3 a by-product rather than a separate exercise.
Table 1
Secure communications
CryptographyExpert reviewHealth Canada guidance: The manufacturer should consider how the device would interface with other devices or networks. Interfaces may include hardwired connections and/or wireless communications. For each type of interface, the manufacturer should determine the method the device will use to communicate with users (e.g., patients or healthcare professionals), other medical devices/sensors or healthcare systems.
Medcrypt solution: Medcrypt secures the device's interfaces with authenticated, encrypted communication, and expert review evaluates whether the controls beneath each protocol are sufficient.
Table 1
Data integrity and confidentiality
CryptographyHealth Canada guidance: The manufacturer should consider how data transfer to and from the device is secured to prevent unauthorized modification and disruption. Manufacturers should determine how the devices/systems will authenticate each other. The manufacturer should consider if data that is stored on or transferred to or from the device requires some level of encryption.
Medcrypt solution: Medcrypt encrypts data at rest and in transit and handles the keys behind it through managed public key infrastructure, including the mutual authentication between devices the guidance asks about.
Table 1
User access
CryptographyHealth Canada guidance: The manufacturer should consider user access controls that validate who can use the device. There may also be a requirement for authorization that grants privileges to different classes of users. Examples of authentication or access authorization include passwords, hardware keys or biometrics.
Medcrypt solution: Medcrypt provides cryptographic identity for users and devices and signs configuration on a least-privilege basis, so the privilege classes the guidance describes are enforced rather than documented.
Table 1
Software maintenance
CryptographySBOM & vulnerabilitiesHealth Canada guidance: The manufacturer should consider how the software will be updated to secure the device against newly discovered cybersecurity threats. The manufacturer should consider how operating system software, third‐party software (e.g., libraries) or open source software will be updated or controlled.
Medcrypt solution: Medcrypt signs and verifies firmware and software updates, and tracks the third-party and open-source components so a maintenance claim can name what is actually being maintained.
Table 1
Hardware or physical design
Expert reviewHealth Canada guidance: The manufacturer should consider controls to prevent an unauthorized person from making physical and software changes to the device in order to bypass security controls (e.g., disable a USB port to prevent unauthorized access via USB key).
Medcrypt solution: Hardware tamper paths are a design review question rather than a software one, so this is answered by architecture review with the engineering team.
Table 1
Reliability and availability
Development & docsHealth Canada guidance: The manufacturer should consider design controls that will allow the device to detect, resist, respond and recover from cybersecurity attacks.
Medcrypt solution: Medcrypt carries design-for-resiliency principles, so critical functionality is protected when part of the system is compromised.
Section 2.1.2
Device-specific risk management
Development & docsHealth Canada guidance: Risk management is required for a medical device throughout its life‐cycle. Manufacturers should incorporate medical device cybersecurity into each device's risk management process, and should develop and maintain an organizational framework for managing cybersecurity risks.
Medcrypt solution: Medcrypt provides the risk management framework at both levels the guidance asks for: the per-device process and the organizational framework above it.
Section 2.1.2, Appendix B
Security risk management run parallel to ISO 14971 safety
Development & docsExpert reviewHealth Canada guidance: Health Canada recommends that device‐specific cybersecurity risk management processes be conducted in parallel to the safety risk management process described in ISO 14971. This parallel process is outlined in Figure 2 and is necessary because of the relationship between safety and security.
Medcrypt solution: Medcrypt runs the security risk assessment as its own process alongside the ISO 14971 safety file, and carries the interactions between them: where a security control creates a safety hazard, and the reverse.
Section 2.1.2
Recommended risk management standards
Development & docsHealth Canada guidance: Health Canada recommends the following standards to assist manufacturers conduct their cybersecurity risk management processes in parallel, and potentially iteratively, with their current established risk management process. AAMI TIR57:2016 – Principles for medical device security – Risk management; ANSI/CAN/UL 2900‐1:2017 – Standard for Software Security Network‐Connectable Products, Part 1: General Requirements.
Medcrypt solution: The model folds twelve global standards into one, TIR57 and UL 2900 among them, so a Canadian application and an FDA submission draw on the same underlying risk work.
Section 2.1.3
Verification and validation testing
Development & docsHealth Canada guidance: All cybersecurity risk control measures should be successfully verified and validated against design specifications and/or design requirements. Manufacturers should be able to trace all verification and validation activities back to design specifications and/or design requirements.
Medcrypt solution: Security testing sits inside the development process at each stage, covering both that a control was implemented and that the mitigation it was chosen for actually holds.
Section 2.1.3, Table 2
Types of cybersecurity testing
SBOM & vulnerabilitiesExpert reviewHealth Canada guidance: Known Vulnerability Testing: Software code is tested against a database of known vulnerabilities such as the National Vulnerability Database. Malformed Input Testing (i.e., FUZZ testing): The device is subjected to massive amounts of malformed (invalid or unexpected inputs) to observe if the device will behave in an unorthodox manner or if it will “crash”. Structured Penetration Testing: This type of testing requires a cybersecurity expert who is familiar with hacking techniques.
Medcrypt solution: Known-vulnerability testing runs continuously against the component inventory; fuzzing and structured penetration testing are delivered by the security team as engagements.
Section 2.2
Plan for monitoring and responding to emerging risks
Development & docsSBOM & vulnerabilitiesHealth Canada guidance: In their pre‐market licence application manufacturers should demonstrate a plan for ongoing monitoring of and response to emerging cybersecurity threats to their device. This plan should apply throughout the expected service life.
Medcrypt solution: Medcrypt supplies model plans covering the four things this section names: post-market vigilance, patching, vulnerability disclosure and information sharing. It also produces the evidence that the plan is being followed.
Section 2.2
Assessing exploitability of a vulnerability
SBOM & vulnerabilitiesHealth Canada guidance: As part of the post‐market vigilance strategy, manufacturers should have a process for assessing the exploitability of a cybersecurity vulnerability. While these approaches are acceptable, manufacturers should consider using a cybersecurity vulnerability assessment tool or similar scoring system for rating vulnerabilities and determining the need and urgency of the response.
Medcrypt solution: Medcrypt determines whether a vulnerability is actually reachable in the device and scores it, which is what turns a feed of CVEs into the urgency decision this section asks for.
Section 2.3.1
Cybersecurity bill of materials
SBOM & vulnerabilitiesHealth Canada guidance: The cybersecurity BOM which lists all third‐party or open source software components that are included in the medical device software. The version and build of the components should be included in the BOM.
Medcrypt solution: Medcrypt manages the bill of materials down to component version and build, and keeps it current across the device's life rather than producing it once for the application.
Section 2.3.1
Labelling and user documentation
Development & docsHealth Canada guidance: In cases where a risk assessment has determined that further risk controls are necessary, the cybersecurity BOM should include any instructions or information related to: The operation of the device that is intended to reduce or eliminate the cybersecurity risk. Features that protect critical functionality of the device, even during a cybersecurity incident. Backup and restore features. End of life information. How the device will update its software. The intended IT environment the product should be deployed in.
Medcrypt solution: Medcrypt templates cover the customer-facing documentation this list calls for, including the hardening guidance and end-of-support dates that operators need during an incident.
Section 2.3.2
Marketing history
SBOM & vulnerabilitiesHealth Canada guidance: This section should include a summary of reported problems and details of any recalls associated with cybersecurity incidents (e.g., a recall to address vulnerability discovered in a device).
Medcrypt solution: The vulnerability and remediation record provides the history this section asks for, with the dates and dispositions already attached.
Section 2.3.3
Risk assessment and risk management report
Development & docsHealth Canada guidance: Licence applications for both Class III and Class IV devices should include: a cybersecurity risk analysis; a cybersecurity risk management report. The report should also include the risk reduction measures adopted to satisfy safety and effectiveness requirements as described in section 2.1.2 of this guidance document.
Medcrypt solution: Medcrypt produces both deliverables as outputs of the risk process rather than as documents written afterwards, including the risk reduction measures and their justification.
Section 2.3.4
Device-specific quality plan
Development & docsHealth Canada guidance: Manufacturers are required to submit a quality plan for a Class IV licence application. The quality plan should demonstrate that a cybersecurity framework is part of the quality standards for the medical device.
Medcrypt solution: Medcrypt provides a template and model implementation for folding cybersecurity into the quality system, which is the demonstration this plan has to make.
Section 2.3.5.1
Standards applied and Declaration of Conformity
Development & docsHealth Canada guidance: A list of all standards applied, in whole or in part, with respect to cybersecurity in the design and manufacture of the device should be included. Evidence that the proposed device is safe and effective should accompany a Declaration of Conformity for standards recognized by Health Canada.
Medcrypt solution: The standards mapping shows which standards were applied and where, which is the list this section asks for and the basis for the conformity declaration.
Section 2.3.5.2
Cybersecurity testing evidence
Expert reviewHealth Canada guidance: Cybersecurity testing evidence should be provided and include: For Class III and Class IV devices a detailed summary of testing that was conducted to verify and validate the security of the device. For Class IV devices, reports showing evidence of cybersecurity testing.
Medcrypt solution: Testing produces both artefacts the guidance distinguishes: the summary a Class III application needs, and the underlying reports a Class IV application must also show.
Section 2.3.5.3
Traceability matrix
Development & docsHealth Canada guidance: A traceability matrix should be included that maps all identified cybersecurity risks to: Requirement specification(s) (i.e., design inputs); Design specification(s) (i.e., design outputs); Design verification and validation test(s).
Medcrypt solution: Medcrypt maintains the hazard-to-requirement-to-test trace as the work happens, so the matrix is generated from the record instead of reconstructed at filing time.
Section 2.3.5.4
Maintenance plan
Development & docsSBOM & vulnerabilitiesHealth Canada guidance: A summary of the device's maintenance plan should be included. The summary should describe the post‐market process(es) by which the manufacturer intends to ensure the continued safety and effectiveness of the device throughout its life‐cycle. As described in Section 2.2 of this guidance document, these planned processes may include: post‐market vigilance, patching, vulnerability disclosure policies and information sharing.
Medcrypt solution: The monitoring plan from Section 2.2 is what this summary is drawn from, so the commitment in the application and the process actually running after approval are the same thing.