Software as a Medical Device
Second Edition
79 Regulatory Affairs Professionals Society
what information for appropriate actions and the transfer of
responsibilities.
As stated above, the actual implementation might differ,
depending on how the manufacturer deploys the SaMD. For
example, suppose an SaMD is an SaaS solution operated
by the manufacturer. In that case, it may not be necessary
to inform the user about every patch that is installed on the
cloud infrastructure. In contrast, if the user needs to patch the
on-premise or hybrid SaMD, it may be necessary to inform
the user of validated and/or conflicting patches or about tem-
porary mitigations that stakeholders should be taking into
consideration until a permanent solution is available.
Informing stakeholders also includes reporting security
risks, as required by various laws and regulations, contrac-
tual obligations, or other specific needs, such as informing a
supplier or open-source community of issues discovered in
their software component, or providing input to an ISAC
or CERT for sharing information with the healthcare
community.
The FDA postmarket guidance provides further guidance
on monitoring and vulnerability handling.26
Total Product Lifecycle
It is not sufficient to monitor only for security vulnerabil-
ities to manage security during the entire SaMD lifecycle.
Changes in the threat landscape can also occur, such as new
methods of attacking systems and infrastructures, broken
protocols, or compromised cryptography. Ransomware attacks
have been one of the biggest changes in the hospital’s threat
landscape in recent years.
Furthermore, software may become obsolete if the
original manufacturer or the open-source community no
longer supports a component or a specific version. Therefore,
to avoid obsolescence issues, the SaMD manufacturer should
promptly validate patches, version upgrades, and replace-
ments of any software components, the operating system,
and supporting software. Mitigation measures should include
any security risks that cannot be mitigated by patches or
incompatibility issues that impact safety and performance.
Furthermore, patches, updates, and upgrades can cause an
increased security risk because specific security measures
designed into the SaMD, platform, or infrastructure are no
longer effective.
When the security of a SaMD can no longer be guaran-
teed, the manufacturer should declare the SaMD as legacy, as
explained in the IMDRF guide on Principles and practices
for the cybersecurity of legacy medical devices.27
As stated earlier, the manufacturer should be aware and
consider security evaluations for multiple versions and combi-
nations potentially in use on the market. An active approach
to limit the number of supported versions in the field could
reduce the amount of effort required.
Shared Responsibility
Managing security involves a combination of technical and
organizational measures implemented by all parties involved
at the various levels, including components, systems, and
network infrastructure. As such, there is rarely a single
organization entirely responsible for everything, from the
manufacturer developing the SaMD to the clinical user using
a hospital-managed workstation to access or run the software.
A SaMD can be developed securely by the manufac-
turer. Still, if the user is responsible for the platform on
which the software runs, and that platform does not receive
the necessary operating system and application hardening,
such as access controls and endpoint protection software, the
probability of a successful attack increases. If the network
infrastructure is not secure and the SaMD is unintention-
ally exposed to the internet while the manufacturer did not
design it for that purpose, there is yet again an increased
probability of an attack. The healthcare delivery organization
and manufacturing staff need to understand how to address
security risks, such as malicious emails that could compromise
the network or software running on it. Both organizations
have specific roles for ensuring secure operations.
Risk transfer is not the intended outcome of shared
responsibility. A manufacturer cannot claim that the SaMD’s
security is not their responsibility, as the user needs to ensure
a secure network. The manufacturer, the healthcare delivery
organization, and any other third party involved must play
their respective roles in the defense-in-depth strategy. The
SaMD must be secure in itself the operating system and
support software must be secure independently the network
infrastructure must be secure and the staff must be made
aware of security risks and maintain good security hygiene. A
defense is effective only if security is adequately established at
all layers and implemented by all stakeholders. ISO 81001-1
provides the principles and concepts for healthcare, including
the roles and responsibilities of all stakeholders.28
Every organization in the supply chain must conduct
due diligence to ensure that it only uses and integrates secure
systems, services, and components. This due diligence applies
to the healthcare delivery organization, as well as to its
suppliers and the suppliers of those suppliers. At any stage in
the supply chain, security vulnerabilities can be introduced
intentionally, unintentionally, or even maliciously.
To support shared responsibility and address supply
chain security, manufacturers should be transparent about
the security capabilities of their products and services. These
capabilities need to be documented in the instructions for use,
administrative guides, security white papers, and other deliv-
erables. The Manufacturer disclosure statement for Medical
Device Security (MDS2) is regarded as an important tool to
provide security-relevant information to the healthcare deliv-
ery organization.29 The use of the MDS2 is also supported by
regulatory guidances and healthcare procurement guides.
Standards
Many standards address security. The selection depends on
the intended use, intended operational use environment,
deployment choices, such as software-only product, on-prem-
ise solution, off-premise solution (cloud), market access
Second Edition
79 Regulatory Affairs Professionals Society
what information for appropriate actions and the transfer of
responsibilities.
As stated above, the actual implementation might differ,
depending on how the manufacturer deploys the SaMD. For
example, suppose an SaMD is an SaaS solution operated
by the manufacturer. In that case, it may not be necessary
to inform the user about every patch that is installed on the
cloud infrastructure. In contrast, if the user needs to patch the
on-premise or hybrid SaMD, it may be necessary to inform
the user of validated and/or conflicting patches or about tem-
porary mitigations that stakeholders should be taking into
consideration until a permanent solution is available.
Informing stakeholders also includes reporting security
risks, as required by various laws and regulations, contrac-
tual obligations, or other specific needs, such as informing a
supplier or open-source community of issues discovered in
their software component, or providing input to an ISAC
or CERT for sharing information with the healthcare
community.
The FDA postmarket guidance provides further guidance
on monitoring and vulnerability handling.26
Total Product Lifecycle
It is not sufficient to monitor only for security vulnerabil-
ities to manage security during the entire SaMD lifecycle.
Changes in the threat landscape can also occur, such as new
methods of attacking systems and infrastructures, broken
protocols, or compromised cryptography. Ransomware attacks
have been one of the biggest changes in the hospital’s threat
landscape in recent years.
Furthermore, software may become obsolete if the
original manufacturer or the open-source community no
longer supports a component or a specific version. Therefore,
to avoid obsolescence issues, the SaMD manufacturer should
promptly validate patches, version upgrades, and replace-
ments of any software components, the operating system,
and supporting software. Mitigation measures should include
any security risks that cannot be mitigated by patches or
incompatibility issues that impact safety and performance.
Furthermore, patches, updates, and upgrades can cause an
increased security risk because specific security measures
designed into the SaMD, platform, or infrastructure are no
longer effective.
When the security of a SaMD can no longer be guaran-
teed, the manufacturer should declare the SaMD as legacy, as
explained in the IMDRF guide on Principles and practices
for the cybersecurity of legacy medical devices.27
As stated earlier, the manufacturer should be aware and
consider security evaluations for multiple versions and combi-
nations potentially in use on the market. An active approach
to limit the number of supported versions in the field could
reduce the amount of effort required.
Shared Responsibility
Managing security involves a combination of technical and
organizational measures implemented by all parties involved
at the various levels, including components, systems, and
network infrastructure. As such, there is rarely a single
organization entirely responsible for everything, from the
manufacturer developing the SaMD to the clinical user using
a hospital-managed workstation to access or run the software.
A SaMD can be developed securely by the manufac-
turer. Still, if the user is responsible for the platform on
which the software runs, and that platform does not receive
the necessary operating system and application hardening,
such as access controls and endpoint protection software, the
probability of a successful attack increases. If the network
infrastructure is not secure and the SaMD is unintention-
ally exposed to the internet while the manufacturer did not
design it for that purpose, there is yet again an increased
probability of an attack. The healthcare delivery organization
and manufacturing staff need to understand how to address
security risks, such as malicious emails that could compromise
the network or software running on it. Both organizations
have specific roles for ensuring secure operations.
Risk transfer is not the intended outcome of shared
responsibility. A manufacturer cannot claim that the SaMD’s
security is not their responsibility, as the user needs to ensure
a secure network. The manufacturer, the healthcare delivery
organization, and any other third party involved must play
their respective roles in the defense-in-depth strategy. The
SaMD must be secure in itself the operating system and
support software must be secure independently the network
infrastructure must be secure and the staff must be made
aware of security risks and maintain good security hygiene. A
defense is effective only if security is adequately established at
all layers and implemented by all stakeholders. ISO 81001-1
provides the principles and concepts for healthcare, including
the roles and responsibilities of all stakeholders.28
Every organization in the supply chain must conduct
due diligence to ensure that it only uses and integrates secure
systems, services, and components. This due diligence applies
to the healthcare delivery organization, as well as to its
suppliers and the suppliers of those suppliers. At any stage in
the supply chain, security vulnerabilities can be introduced
intentionally, unintentionally, or even maliciously.
To support shared responsibility and address supply
chain security, manufacturers should be transparent about
the security capabilities of their products and services. These
capabilities need to be documented in the instructions for use,
administrative guides, security white papers, and other deliv-
erables. The Manufacturer disclosure statement for Medical
Device Security (MDS2) is regarded as an important tool to
provide security-relevant information to the healthcare deliv-
ery organization.29 The use of the MDS2 is also supported by
regulatory guidances and healthcare procurement guides.
Standards
Many standards address security. The selection depends on
the intended use, intended operational use environment,
deployment choices, such as software-only product, on-prem-
ise solution, off-premise solution (cloud), market access