Software as a Medical Device
Second Edition
75 Regulatory Affairs Professionals Society
after patching or after configuration changes to the oper-
ating system, supporting software, and/or infrastructure?
If yes, how can the user validate that the software is still
functioning as intended?
• Next to maintenance/patches, who will be responsible for
validating the operating system and supporting software
upgrades to ensure compatibility with newer versions?
• Is there a need for data backups, redundant systems, and
so on? If so, who is responsible?
Manufacturers should identify the technical and/or organi-
zational dependencies and measures, supported by a security
risk assessment, and clearly document these. Manufacturers
should clearly identify in customer-facing documentation
which security features their product provides and which
security controls the deployer needs to implement to establish
a shared security responsibility between the operator and the
manufacturer. That information should be part of user-facing
documentation and is often also explicitly required from a
regulatory perspective, such as in the EU through the general
safety and performance requirements in the EU MDR8
Annex 1, articles 17.4 and 23.4 (ab), and in the EU IVDR9
Annex 1, articles 16.4 and 20.4 (ah), and further expressed in
detail in the Medical Device Coordinators Group 2019–16
guidance on cybersecurity for medical devices10 (Chapter 3.6,
Minimum IT requirements).
Security Risk Management
Manufacturers must perform security risk management,
which involves the following aspects related to a SaMD:
• Software development
• Software manufacturing (build and release)
• Management of the software/service (including software
installation and updates)
• Management of the platform (operating system and
supporting software)
• Management of the infrastructure (network and data
centers)
ISO 14971:2019 deals with risk management for medical
devices, including software as a medical device and in vitro
diagnostic medical devices. In this standard, the term safety is
defined as freedom from unacceptable risk (ISO 14971:2019,
3.26), and this risk is not restricted to any specific risk areas.
Therefore, safety encompasses freedom from unacceptable
risks related to security, or more specifically, freedom from
unacceptable risks arising from security breaches. All risks
are related to possible harm, which is defined broadly in ISO
14971:2019, 3.3. The broad concept of risk, explicitly includ-
ing security risks, is explained several times and is stated in
Annex A as follows:
The process described in ISO 14971 can be applied to
hazards and risks associated with the medical device. Risks
related to data and systems security are specifically mentioned
in the scope, to avoid any misunderstanding that a separate
process would be needed to manage security risks related
to medical devices. This does not preclude the possibility of
developing specific standards, in which specific methods and
requirements are provided for the assessment and control of
security risks.
The International Medical Device Regulators Forum
(IMDRF) document, Software as a medical device: Possible
framework for risk categorization and corresponding consid-
erations,11 defines several considerations for manufacturers
in Chapter 9.3 when identifying implications for the safety
and performance of SaMD. The document points out that
there can be vulnerabilities in software components, but also
design flaws in access controls and infrastructure, unprotected
interfaces, and ways to bypass security controls (backdoors).
Security must not only address safety and performance, but
also data protection and issues that could be exploited as a
stepping stone to attack other systems within the user’s infra-
structure. Risk assessment should focus on the system view,
which expands beyond the SaMD to understand risks from
and to other connected devices. Threat modeling can help
identify these weaknesses.
Security by Design
Security risk management is addressed through the secu-
rity-by-design process activities, also known as a secure
software development framework. These activities typically
have the following elements:
• Product security plan document(s) should be created,
in which the cybersecurity management activities that
must be executed during the total product lifecycle are
described. This plan ensures that budget and resources
are allocated to continuous efforts, such as monitoring,
testing, and vulnerability handling, and that product
updates, upgrades, and end-of-life planning are in place.
• Elicit requirements to assess which security requirements
must be implemented to satisfy the manufacturer and
end-user regulatory requirements, contractual obliga-
tions, and any security risks that are identified.
• Security risk assessments must be conducted at every
development stage, from very early stages to the end of
support. Security risk assessment is based on the out-
put of threat modeling and takes further input from
various sources, including documents created through
continuous security testing. Traceability to the safety
risk management is key. The AAMI SW96 Standard for
Medical Device Security–Security Risk Management for
Device Manufacturers12 can provide further guidance.
• Secure design ensures that products are secure on every
interface, applying least privileged and defense-in-depth
approaches, utilizing secure components and design
patterns, and so on.
• Secure implementation practices include secure cod-
ing, validating all inputs, correct error handling, static
and dynamic code analysis, and a review of the secu-
rity implementation and its traceability to the design
requirements.
• Verification and validation that the product meets the
security requirements with the agreed-upon level of
Second Edition
75 Regulatory Affairs Professionals Society
after patching or after configuration changes to the oper-
ating system, supporting software, and/or infrastructure?
If yes, how can the user validate that the software is still
functioning as intended?
• Next to maintenance/patches, who will be responsible for
validating the operating system and supporting software
upgrades to ensure compatibility with newer versions?
• Is there a need for data backups, redundant systems, and
so on? If so, who is responsible?
Manufacturers should identify the technical and/or organi-
zational dependencies and measures, supported by a security
risk assessment, and clearly document these. Manufacturers
should clearly identify in customer-facing documentation
which security features their product provides and which
security controls the deployer needs to implement to establish
a shared security responsibility between the operator and the
manufacturer. That information should be part of user-facing
documentation and is often also explicitly required from a
regulatory perspective, such as in the EU through the general
safety and performance requirements in the EU MDR8
Annex 1, articles 17.4 and 23.4 (ab), and in the EU IVDR9
Annex 1, articles 16.4 and 20.4 (ah), and further expressed in
detail in the Medical Device Coordinators Group 2019–16
guidance on cybersecurity for medical devices10 (Chapter 3.6,
Minimum IT requirements).
Security Risk Management
Manufacturers must perform security risk management,
which involves the following aspects related to a SaMD:
• Software development
• Software manufacturing (build and release)
• Management of the software/service (including software
installation and updates)
• Management of the platform (operating system and
supporting software)
• Management of the infrastructure (network and data
centers)
ISO 14971:2019 deals with risk management for medical
devices, including software as a medical device and in vitro
diagnostic medical devices. In this standard, the term safety is
defined as freedom from unacceptable risk (ISO 14971:2019,
3.26), and this risk is not restricted to any specific risk areas.
Therefore, safety encompasses freedom from unacceptable
risks related to security, or more specifically, freedom from
unacceptable risks arising from security breaches. All risks
are related to possible harm, which is defined broadly in ISO
14971:2019, 3.3. The broad concept of risk, explicitly includ-
ing security risks, is explained several times and is stated in
Annex A as follows:
The process described in ISO 14971 can be applied to
hazards and risks associated with the medical device. Risks
related to data and systems security are specifically mentioned
in the scope, to avoid any misunderstanding that a separate
process would be needed to manage security risks related
to medical devices. This does not preclude the possibility of
developing specific standards, in which specific methods and
requirements are provided for the assessment and control of
security risks.
The International Medical Device Regulators Forum
(IMDRF) document, Software as a medical device: Possible
framework for risk categorization and corresponding consid-
erations,11 defines several considerations for manufacturers
in Chapter 9.3 when identifying implications for the safety
and performance of SaMD. The document points out that
there can be vulnerabilities in software components, but also
design flaws in access controls and infrastructure, unprotected
interfaces, and ways to bypass security controls (backdoors).
Security must not only address safety and performance, but
also data protection and issues that could be exploited as a
stepping stone to attack other systems within the user’s infra-
structure. Risk assessment should focus on the system view,
which expands beyond the SaMD to understand risks from
and to other connected devices. Threat modeling can help
identify these weaknesses.
Security by Design
Security risk management is addressed through the secu-
rity-by-design process activities, also known as a secure
software development framework. These activities typically
have the following elements:
• Product security plan document(s) should be created,
in which the cybersecurity management activities that
must be executed during the total product lifecycle are
described. This plan ensures that budget and resources
are allocated to continuous efforts, such as monitoring,
testing, and vulnerability handling, and that product
updates, upgrades, and end-of-life planning are in place.
• Elicit requirements to assess which security requirements
must be implemented to satisfy the manufacturer and
end-user regulatory requirements, contractual obliga-
tions, and any security risks that are identified.
• Security risk assessments must be conducted at every
development stage, from very early stages to the end of
support. Security risk assessment is based on the out-
put of threat modeling and takes further input from
various sources, including documents created through
continuous security testing. Traceability to the safety
risk management is key. The AAMI SW96 Standard for
Medical Device Security–Security Risk Management for
Device Manufacturers12 can provide further guidance.
• Secure design ensures that products are secure on every
interface, applying least privileged and defense-in-depth
approaches, utilizing secure components and design
patterns, and so on.
• Secure implementation practices include secure cod-
ing, validating all inputs, correct error handling, static
and dynamic code analysis, and a review of the secu-
rity implementation and its traceability to the design
requirements.
• Verification and validation that the product meets the
security requirements with the agreed-upon level of