Standards & Regulations
A mapping you can check, clause by clause.
The guidance the Regulation leaves out
The MDR states its cybersecurity requirements in a handful of Annex I clauses and says nothing about how to meet them. MDCG 2019-16 is where the method lives. All 29 of its obligations are mapped below, each with the chapter it comes from and the Annex I or Article reference behind it.
Four kinds of work, across all twenty-nine
Some obligations 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.
State of the art, which the guidance never defines
MDCG 2019-16 requires the state of the art and then points at standards and Official Journal listings rather than enumerating controls. Our model folds twelve global standards together to answer that, alongside a bench that includes a former FDA reviewer and three HSCC JSPv2 co-authors.
MDCG 2019-16 cybersecurity guidance
Twenty-nine obligations, 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. Chapter references point to MDCG 2019-16; the Annex I and Article references beside them point into Regulation (EU) 2017/745 itself. The same obligations apply under the IVDR at the section numbers the guidance gives in its Table 1.
MDCG 2019-16 Rev. 1, Guidance on Cybersecurity for medical devices. Endorsed by the Medical Device Coordination Group, December 2019, revised July 2020 (PDF)
17
Secure development & documentation
Process, design controls, and the records a submission needs
8
SBOM & vulnerability management
Component inventory and triage across the device lifetime
6
Cryptography & update integrity
Keys, signing, encryption, and secure updates
6
Expert review
Threat modelling and architecture review by people
All 29 categories are mapped. Some are answered by more than one kind of work, so these figures sum to more than 29.
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 29 of 29 categories
Chapter 1.3, MDR Annex I
Cybersecurity requirements in Annex I
Development & docsMDCG 2019-16 guidance: Cybersecurity requirements listed in Annex I of the Medical Devices Regulations, deal with both pre-market and post-market aspects. These requirements, and their interconnection, are illustrated in Figure 1 and are elaborated in Chapter 2 with the aim to provide a basis for the development of recommendations and guidance for medical device manufacturers (Chapters 3-6 of this document).
Medcrypt solution: Medcrypt works the pre-market and post-market halves as one record, so the Annex I conformity argument and the post-market evidence that has to keep supporting it do not drift apart after CE marking.
Chapter 1.2
Fulfilling the essential requirements
Development & docsMDCG 2019-16 guidance: The primary purpose of this document is to provide manufacturers with guidance on how to fulfil all the relevant essential requirements of Annex I to the MDR and IVDR with regard to cybersecurity. However, and in light of the complexity of medical device supply chains and the role played by different operators in ensuring that devices are protected against unauthorised access and possible cyber threats, additional considerations concerning expectations from actors other than manufacturers are provided.
Medcrypt solution: Medcrypt maps each Annex I cybersecurity clause to the evidence that satisfies it, so the technical file shows conformity clause by clause rather than asserting it in a summary.
Chapter 2.4
Vulnerabilities as reasonably foreseeable misuse
SBOM & vulnerabilitiesMDCG 2019-16 guidance: Due to the complexity of software development, software configuration and interdependencies between software components, cybersecurity vulnerabilities exist in most products. Whether or not a vulnerability will be discovered and if it will be exploited is unknown until it occurs. The general assumption is that any vulnerability which is deemed to be exploitable for a given implementation of software, might be discovered and exploited over time and as such should be regarded as an enabler for reasonably foreseeable misuse.
Medcrypt solution: Medcrypt tracks exploitability rather than raw CVE counts, which is the judgement this clause demands: an exploitable vulnerability becomes foreseeable misuse and has to reach the safety risk file, and one that is not exploitable in the device's configuration does not.
Chapter 2.6
Joint responsibility across stakeholders
Development & docsExpert reviewMDCG 2019-16 guidance: While the MDR and the IVDR provide legal obligations only with regard to manufacturers, however it should be noted that for the provision of secured healthcare services, it is important to recognise the roles and expectations of all stakeholders, such as manufacturers, suppliers, healthcare providers, patients, integrators, operators and regulators. All of these actors share responsibilities for ensuring a secured environment for the benefit of patients' safety.
Medcrypt solution: Medcrypt documents where the manufacturer's security boundary ends and the operator's begins, which is what makes the assumptions in the instructions for use defensible rather than convenient.
Chapter 1.3, MDR Annex I
Cybersecurity requirements in Annex I
Development & docsMDCG 2019-16 guidance: Cybersecurity requirements listed in Annex I of the Medical Devices Regulations, deal with both pre-market and post-market aspects. These requirements, and their interconnection, are illustrated in Figure 1 and are elaborated in Chapter 2 with the aim to provide a basis for the development of recommendations and guidance for medical device manufacturers (Chapters 3-6 of this document).
Medcrypt solution: Medcrypt works the pre-market and post-market halves as one record, so the Annex I conformity argument and the post-market evidence that has to keep supporting it do not drift apart after CE marking.
Chapter 1.2
Fulfilling the essential requirements
Development & docsMDCG 2019-16 guidance: The primary purpose of this document is to provide manufacturers with guidance on how to fulfil all the relevant essential requirements of Annex I to the MDR and IVDR with regard to cybersecurity. However, and in light of the complexity of medical device supply chains and the role played by different operators in ensuring that devices are protected against unauthorised access and possible cyber threats, additional considerations concerning expectations from actors other than manufacturers are provided.
Medcrypt solution: Medcrypt maps each Annex I cybersecurity clause to the evidence that satisfies it, so the technical file shows conformity clause by clause rather than asserting it in a summary.
Chapter 2.4
Vulnerabilities as reasonably foreseeable misuse
SBOM & vulnerabilitiesMDCG 2019-16 guidance: Due to the complexity of software development, software configuration and interdependencies between software components, cybersecurity vulnerabilities exist in most products. Whether or not a vulnerability will be discovered and if it will be exploited is unknown until it occurs. The general assumption is that any vulnerability which is deemed to be exploitable for a given implementation of software, might be discovered and exploited over time and as such should be regarded as an enabler for reasonably foreseeable misuse.
Medcrypt solution: Medcrypt tracks exploitability rather than raw CVE counts, which is the judgement this clause demands: an exploitable vulnerability becomes foreseeable misuse and has to reach the safety risk file, and one that is not exploitable in the device's configuration does not.
Chapter 2.6
Joint responsibility across stakeholders
Development & docsExpert reviewMDCG 2019-16 guidance: While the MDR and the IVDR provide legal obligations only with regard to manufacturers, however it should be noted that for the provision of secured healthcare services, it is important to recognise the roles and expectations of all stakeholders, such as manufacturers, suppliers, healthcare providers, patients, integrators, operators and regulators. All of these actors share responsibilities for ensuring a secured environment for the benefit of patients' safety.
Medcrypt solution: Medcrypt documents where the manufacturer's security boundary ends and the operator's begins, which is what makes the assumptions in the instructions for use defensible rather than convenient.
Chapter 3, MDR Annex I §3
Security across the entire life cycle
Development & docsMDCG 2019-16 guidance: Safety, security and effectiveness are critical aspects in the design of security mechanisms for in vitro diagnostic medical devices and medical devices. Therefore, there is a clear requirement that these aspects need to be considered by the manufacturers from an early stage of development and manufacturing process and throughout the entire life cycle.
Medcrypt solution: Medcrypt implements security across the whole life cycle, covering design, development, release, support and decommission, rather than treating it as a conformity assessment activity.
Chapter 3.1
Defence in depth
Development & docsCryptographyMDCG 2019-16 guidance: Figure 5 illustrates how “secure by design” practices in this document contribute to a “defence in depth” strategy for the product. The “security management” practice is shown on the top circle since it is applied throughout all other practices to ensure that these practices are being followed and managed. The other practices, shown on the bottom circle are applied throughout the development lifecycle, often in an iterative pattern.
Medcrypt solution: Medcrypt layers device-side cryptographic controls beneath the process controls, so a single failure in one layer does not expose the device, which is what the guidance means by depth rather than breadth.
Chapter 3.1
The eight security management practices
Development & docsMDCG 2019-16 guidance: The overall approach for security management for medical devices and software does not differ from the security management of other cyber-physical systems. The following common eight practices define most of the necessary processes that should be in place to establish a “Defense-in-Depth strategy” for the organisation during the product lifecycle.
Medcrypt solution: Medcrypt provides a template and model implementation for all eight practices, folded into an existing quality management system rather than run alongside it as a parallel process.
Chapter 3.1, Practice 2
Specification of security requirements
Development & docsMDCG 2019-16 guidance: The processes specified by this practice are used to identify the security capabilities that are required for appropriate protection of confidentiality, integrity and availability of data, function and services of the medical device along with the specified product security context. Security capabilities can include such items as authentication, authorisation, encryption, auditing and other security capabilities a product needs to include.
Medcrypt solution: Medcrypt supplies design-input templates for every capability the practice names: authentication, authorisation, encryption and auditing. Security requirements enter the design controls as requirements rather than as intentions.
Chapter 3.1, Practice 7
Security update management
CryptographySBOM & vulnerabilitiesMDCG 2019-16 guidance: The processes specified by this practice are used to ensure that security updates and security patches associated with the product are tested for regressions and made available to product users in a timely manner.
Medcrypt solution: Medcrypt signs and verifies software and firmware updates, and tracks the interval from patch availability to field deployment that makes the timeliness claim checkable.
Chapter 3.2, MDR Annex I §3–4
Security risk management
Development & docsMDCG 2019-16 guidance: Risks related to data and systems security are specifically mentioned within the scope of the risk management process, to avoid any misunderstanding that a separate process would be needed to manage security risks related to medical devices. Specific methods and requirements are however used for security risks.
Medcrypt solution: Medcrypt runs security risk management with its own methods inside the existing risk management system, which is the arrangement the guidance describes rather than the parallel file manufacturers often build.
Chapter 3.2, Annex IV
Safety and security risk interaction
Development & docsExpert reviewMDCG 2019-16 guidance: The security risk management process has the same elements as safety risk management process, all documented in a security risk management plan. The process elements are security risk analysis, security risk evaluation, security risk control, evaluation of residual security risk and reporting. When a security risk or control measure could have a possible impact on safety and effectiveness, then it should be included in the safety risk assessment. Similarly, any safety risk control or consideration that might have an impact on security should be included in the security risk analysis.
Medcrypt solution: Medcrypt keeps the traffic between the two files explicit in both directions, so a security control with a safety consequence reaches the safety assessment and a safety control with a security consequence reaches the security analysis.
Chapter 3.3, MDR Annex I §17.2
Security capabilities as risk control measures
CryptographyMDCG 2019-16 guidance: The list of known vulnerabilities and attack vectors is the basis for specifying the security capabilities, depending on the risk management, required for appropriate protection of confidentiality, integrity, availability of data, function and services of the medical device along with the specified product security context. Security capabilities may be determined as suitable risk-control measures. The design and implementation of such capabilities need to comply with the state of the art (see Annex I, sections 17.2 (MDR) or 1, 4, 16.2 (IVDR)) and cover a wide range of technical areas.
Medcrypt solution: Medcrypt delivers the cryptographic capabilities in the guidance's own Table 3: node and person authentication, transmission confidentiality and integrity, and data storage confidentiality. Each is implemented to standardised algorithms rather than configured per project.
Chapter 3.3, MDR Annex I §4
Order of priority for risk control
CryptographyExpert reviewMDCG 2019-16 guidance: Where there is an impact on safety or effectiveness, manufacturers shall select the most appropriate risk control solution, in the following order of priority: a) Eliminate or reduce risks as far as possible through safe design and manufacture; b) Where appropriate, take adequate protection measures, including alarms if necessary, in relation to risks that cannot be eliminated; c) Provide information for safety (warnings/precautions/contra-indications) and, where appropriate, training to users.
Medcrypt solution: Medcrypt puts controls in the device first, so the hierarchy is satisfied at step one rather than discharged by a warning in the instructions for use, which is where a notified body will press.
Chapter 3.4
Threat modelling
Expert reviewMDCG 2019-16 guidance: Threat Modelling techniques are a systematic approach for analysing the security of an item in a structural way such that vulnerabilities can be identified, enumerated, and prioritised, all from a hypothetical attacker's point of view. Threat modelling can be applied to software, devices, systems, networks, distributed systems, business processes, etc. Threat modelling typically employs a systematic approach to identify attack vectors and assets most desired by an attacker.
Medcrypt solution: Delivered as expertise and support, plus an online training programme with live labs so device engineers build the capability in-house rather than renting it indefinitely.
Chapter 3.4
Known vulnerabilities and foreseeable attacks
SBOM & vulnerabilitiesMDCG 2019-16 guidance: An identified vulnerability is typically identified via a Common Vulnerabilities and Exposures (CVE) identifier. A scenario whereby an attacker exploits a known vulnerability may be considered as “foreseeable” with respect to the product's risk management – notably if the intended operational environment or other mitigation controls do not prevent that type of attack.
Medcrypt solution: Medcrypt monitors CVE feeds against the device's own component inventory and scores what it finds, so the foreseeability judgement rests on the device's actual configuration rather than on a published severity alone.
Chapter 3.5, MDR Annex I §1, 2, 3e, 8
Security benefit risk analysis
Development & docsMDCG 2019-16 guidance: Carrying out a Benefit Risk Analysis is an explicit requirement of the Medical Devices Regulations Annex I, sections 1, 2, 3e and 8. It shall be noted that the Benefit Risk Analysis is not executed for every individual security risk. Instead, an overall Benefit Risk Analysis is to be executed based on the intended use and possible safety and performance impact using the safety risk assessment, which includes the security-related hazard categories.
Medcrypt solution: Medcrypt aggregates security-related hazards into the categories the overall benefit risk analysis consumes, so the analysis is executed once at the right altitude rather than repeated per vulnerability.
Chapter 3.6, MDR Annex I §17.4
Minimum IT requirements
Development & docsMDCG 2019-16 guidance: Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. It is the manufacturers' responsibility to determine the minimum requirements for the operating environment as regards IT network characteristics and IT security measures that could not be implemented through the product design.
Medcrypt solution: Medcrypt documents the minimum hardware, network and IT security requirements as a derived output of the device's own risk assessment, so what is asked of the hospital follows from the analysis instead of a generic checklist.
Chapter 3.6
Autonomy of the device in its environment
CryptographyMDCG 2019-16 guidance: The medical device should be as autonomous as possible in terms of IT security and sole reliance on the existence of any IT security requirements on the operating environment should be kept to a minimum and reflect the manufacturer's assumptions on the baseline environment security for the secure operation of the medical device. In accordance with the principle of layered security, IT security measures foreseen for the operating environment in general should not serve the purpose of compensating security controls for medical device vulnerabilities, unless there is sufficient justification.
Medcrypt solution: Medcrypt puts authentication, encryption and update integrity on the device itself, so the security argument does not rest on hospital network controls the manufacturer neither owns nor can verify.
Chapter 3.7, MDR Annex I §17.2
Verification and validation
MDCG 2019-16 guidance: MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing.
Medcrypt solution: Security testing is built into the development process at each stage, covering both that the security requirements were implemented and that the threat mitigations actually hold.
Chapter 3.8
Life cycle security maintenance
SBOM & vulnerabilitiesMDCG 2019-16 guidance: During the support lifetime of the device, the manufacturer should put in place a process to gather post-market information with respect to the security of the device. This process should take into account: Security incidents directly related to medical device software; Security Vulnerabilities that are related to the medical device hardware/software and the 3rd party hardware/software used with the medical device; Changes in the threat landscape, including interoperability aspects.
Medcrypt solution: Medcrypt monitors the device's own components and its third-party dependencies continuously, and produces the evaluation record the guidance expects each finding to receive.
Chapter 4.1, MDR Annex II–III
Technical documentation
Development & docsMDCG 2019-16 guidance: According to Annex II of the Medical Devices Regulations, documentation shall contain information for the demonstration of conformity with the general safety and performance requirements set out in Medical Devices Regulations Annex I. These include security requirements to ensure safety and effectiveness of products against security risks and threats, and shall comprise a justification, validation and verification of the solutions adopted to meet those requirements. In addition, the technical documentation needs to be updated with information raised through the manufacturers post market surveillance system related to handling and remediation of cybersecurity incidents and vulnerabilities.
Medcrypt solution: Medcrypt generates the Annex II and Annex III cybersecurity content as an output of the work rather than as a document written afterwards: the justification, the verification results and the post-market updates.
Chapter 4.2, MDR Annex I §23.4
Instructions for use
Development & docsMDCG 2019-16 guidance: for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. The manufacturer shall provide clear documentation of the device's instructions for use, including IT security features/configurations (if applicable), and clear instructions for the IT security controls related to the operating environment, including product specifications, compatibilities, recommended IT security measures, IT environment configuration.
Medcrypt solution: Medcrypt templates cover the cybersecurity content Annex I §23.4 requires in the instructions for use, including the security configuration options and the deployment steps an operator has to follow.
Chapter 4.2
Software bill of materials
SBOM & vulnerabilitiesMDCG 2019-16 guidance: Often, specific security information is shared through documentation other than the instructions for use, such as instructions for administrators or security operation manuals. Such information may include the following: List of IT security controls included in the medical device; Depending on the type of product, provisions to ensure integrity/validation of software updates and security patches; Technical properties of hardware components; Software Bill of Materials; User roles and respective access privileges/permissions on the device.
Medcrypt solution: Medcrypt manages the SBOM across the device lifetime, covering proprietary components, licensed software, open source and upstream dependencies, and determines when a vulnerability in one of them is actually relevant to the device.
Chapter 4.3
Information to healthcare providers
Development & docsMDCG 2019-16 guidance: Among the information to be provided to healthcare providers regarding the intended use environment, the following can be included (non-exhaustive list): Device instructions for use and product specifications related to recommended cybersecurity controls appropriate for the intended use environment; Description of device features that protect critical functionality, even when the device's cybersecurity has been compromised; Description of backup and restore features and procedures to regain configurations; List of network ports and other interfaces that are expected to receive/send data.
Medcrypt solution: Medcrypt produces the operator-facing security documentation, including the port and interface inventory and the network diagrams, and carries it in the MDS2 form European hospitals ask for.
Chapter 5.1, MDR Art. 83–84
Post-market surveillance system
SBOM & vulnerabilitiesDevelopment & docsMDCG 2019-16 guidance: The manufacturer is required to put in place a post market surveillance (PMS) system and actively keep this PMS up to date in accordance with MDR Art. 83 or IVDR Art. 78. Cybersecurity considerations for medical devices should be part of this PMS system. A PMS system includes actively and regularly collecting user experience from devices on the market (including third party software and hardware components), to review these, and to timely implement necessary corrective action, taking into account the nature and risks in relation to the device.
Medcrypt solution: Medcrypt feeds the PMS system with continuous monitoring of the device's own software and its third-party components, and records the review and corrective action each finding received.
Chapter 5.1
Handling and remediation of incidents
Development & docsSBOM & vulnerabilitiesMDCG 2019-16 guidance: Handling and remediation of cybersecurity incidents and vulnerabilities reported through the post-market surveillance and vigilance systems shall be carried out conforming to the methodologies described in Chapter 3.2 of this guidance, with regards to: Assess the need for reporting serious and non-serious incidents and of carrying-out field safety corrective actions; Enhancing security capabilities; Update the original Security Risk Assessment; Update the Verification and Validation; Update the original Security Benefit Risk Analysis; Update the Technical Documentation.
Medcrypt solution: Medcrypt drives each of the six updates this clause enumerates from one record, so remediating a vulnerability propagates through the risk assessment, the verification and the technical file instead of stopping at the patch.
Chapter 5.2, MDR Art. 87
Vigilance and serious incident reporting
Development & docsExpert reviewMDCG 2019-16 guidance: The manufacturer is responsible for reporting all serious incidents and field safety corrective actions (FSCA) to the CA in accordance with MDR Article 87 or IVDR art 82. Manufacturers are obliged to conduct investigations as soon as they are informed that a serious incident has taken place. As such, a risk assessment of the incident is conducted and if needed, a FSCA will be implemented in order to minimize the risk of the device.
Medcrypt solution: Medcrypt supplies model plans for vulnerability monitoring, patch timelines and coordinated disclosure, so the investigation an Article 87 report depends on starts from a record rather than from scratch.
Chapter 5.2, MDR Art. 88
Trend reporting
SBOM & vulnerabilitiesMDCG 2019-16 guidance: Incidents that have cybersecurity related incident root causes are subject to Trend Reporting under the Medical Devices Regulations. According to trend reporting provisions, manufacturers shall report, by means of the electronic system referred to in Article 92, any statistically significant increase in the frequency or severity of incidents that are not serious incidents or that are expected undesirable side-effects that could have a significant impact on the benefit-risk analysis referred to in Sections 1 and 8 of Annex I.
Medcrypt solution: Medcrypt measures incident frequency and severity over time, which is what makes a statistically significant increase visible before a competent authority asks about it.
Chapter 6.1
Neighbouring EU legislation
CryptographyExpert reviewMDCG 2019-16 guidance: At EU level, the following legislative acts are relevant to the cybersecurity of medical devices or to operators dealing with protecting or processing of personal data stored in medical devices and might apply in parallel to the Medical Devices Regulations: NIS Directive; GDPR (General Data Protection Regulation).
Medcrypt solution: Medcrypt encrypts personal data at rest and in transit and manages the keys behind it, which is the device-side half of what GDPR and the NIS regime expect. The organisational half stays with the manufacturer and the operator.