The goal of this publication is to help you in the development of your device with a focus on a very hot topic: Cybersecurity.  With the content of this publication, you will be able to understand how Cybersecurity (also called software security) can impact your process of development and the design of your device.


For introduction content, refer to the Parts previously published.

Evaluate Security Risk Levels

Software security scoring scheme

To quantify your security risks and prioritize their handling, you need to apply a clear security scoring scheme.

The Common Vulnerability Scoring System (CVSS), a standard commissioned by US National Infrastructure Advisory Council (NIAC) in 2005 and maintained by the International Forum for Incident Response and Security Teams (FIRST), has been developed and made publicly available as well as an associated calculator allowing you to simply quantify the level of risk associated with the identified vulnerabilities (Common Vulnerability Scoring System Version 3.0 Calculator (

Another calculator is provided by NIST and provide a more user-friendly interface and visual graphics.

Another usable scoring system is DREAD, simpler than CVSS but providing less detailed image of the exact nature of the vulnerability and risk.

These scoring systems and calculators can be used to quantify the initial level of risk of each identified vulnerability and its level after mitigation(s) (Chapter 6.4). The level of effort you put in minimizing each risk will depend on its initial score. To do so, you shall define rules as illustrated in the next figure, that will give you a systematic approach to the treatment of your identified vulnerabilities.

Figure 1. Security risk levels and associated actions.

Quantify security risk levels associated with identified threats

Based on the identified threats and the selected software security scoring scheme, you can now quantify the risk level associated to each threat and therefore prioritize their handling. You will therefore obtain threats of different levels and the next steps will depend on their risk level.

Debiotech recommends defining the following rules:

For medium and low-level threats, you should reduce risk as reasonably practicable while it is mandatory for higher threat levels. If no risk control measure is defined for a given threat a rationale must be provided to explain why this threat cannot be reduced further with reasonably acceptable efforts. In some case, some critical and high threat levels might impact the critical performance of your device and they could be accepted as they are if the ratio benefits/risks remain largely in favor of the patient. In this case a clear and detailed rationale must be provided.

Identify Security Risk Control Measures

To control the security risks associated with your system, you must develop security risk control measures, also often called mitigations. Those mitigations can be of many different types and their impact on the software security risk levels depends on their characteristics.

Usually, external risk control measures are highly recommended as they allow to minimize the risks associated to your system without impact it directly. An example of an external risk control measures could be that your system shall be stored in a room only accessible to authorized persons. Those mitigations can be very robust and relatively easy to put in place.

Hardware related risk control measures are also usually highly appreciated for the level of security they bring. For example, to protect sensitive data, you can record them on a secured and a dedicated memory (trust platform), only accessible through a dedicated communication port and using encryption and authentication. Also, secure boot loader is often required for medical devices with a high-risk class.  

Typical software related risks control measures include the use of strong passwords, double identifications, and use of privileges to manipulate data in the devices. Other usual security risk control measures, more hidden to the users, are the use of encrypted data transmission and the check of the authenticity of the product code. Note that robust encryption technics shall be used. They are listed in NIST FIPS 140-2 Appendix A.

Figure 2. Threat identification and mitigation example

Implement Risk Control Measures

Once software security risk control measures are identified and their impact evaluated, it is now time to implement them. This can represent a significant amount of work. It is highly recommended to use existing and robust libraries for standard technics as authentication and encryption. However, this might add new libraries and therefore new vulnerabilities to your system. In the case those security risks might be associated with critical safety risks, this will impact the software risk class associated to this library. This can induce a complex situation where the library you used must be compliant with class B or class C software classification according to IEC 62304, which is rarely, if not never, the case.

Debiotech recommends:

  • Using non software risk control measures as much as possible to reduce software security or safety risks.

Clearly separating code dedicated to security feature from those for safety or performance features. 


Rémi Charrier
Business Development Director

João Budzinski
R&D Director

Laurent Colloud
Software Project Manager

Gilles Forconi
Software Quality Manager

Next steps

Debiotech is glad to have the opportunity to share its knowledge with innovative companies from the MedTech industry. Your feedbacks on this publication are welcome and will be used to update it or to create new publications on topics you care about.

Continue your education on medical device development by:

Debiotech would be proud to be your partner and support you with:

  • Medical device design & development services:
    • Software: Digital Health, Firmware, Embedded, SaMD
    • Electronics: Design, Verification and Validation
    • Mechanics: Design for micro-fabrication & fluidics systems
    • Supply chain development and optimization
  • Support in medical innovation management:
    • Market analysis and segmentation
    • IP management
    • Business plan consolidation
    • Partnership development