cybersecurity
in
medical
devices
quality
system
considerations
and
content
of
premarket
submissions
guidance
for
industry
and
food
and
drug
administration
staff
document
issued
on
september
the
draft
of
this
document
was
issued
on
april
this
document
supersedes
content
of
premarket
submissions
for
management
of
cybersecurity
in
medical
devices
issued
october
for
questions
about
this
document
regarding
cdrh-regulated
devices
contact
cybermed
fda
hhs
gov
for
questions
about
this
document
regarding
cber-regulated
devices
contact
the
office
of
communication
outreach
and
development
ocod
at
or
or
by
email
at
ocod
fda
hhs
gov
u
s
department
of
health
and
human
services
food
and
drug
administration
center
for
devices
and
radiological
health
center
for
biologics
evaluation
and
research
preface
public
comment
you
may
submit
electronic
comments
and
suggestions
at
any
time
for
agency
consideration
to
https
www
regulations
gov
submit
written
comments
to
the
dockets
management
staff
food
and
drug
administration
fishers
lane
room
hfa-305
rockville
md
identify
all
comments
with
the
docket
number
fda-2021-d-1158
comments
may
not
be
acted
upon
by
the
agency
until
the
document
is
next
revised
or
updated
additional
copies
cdrh
additional
copies
are
available
from
the
internet
you
may
also
send
an
email
request
to
cdrh-guidance
fda
hhs
gov
to
receive
a
copy
of
the
guidance
please
include
the
document
number
gui00001825
and
complete
title
of
the
guidance
in
the
request
cber
additional
copies
are
available
from
the
center
for
biologics
evaluation
and
research
cber
office
of
communication
outreach
and
development
ocod
new
hampshire
ave
wo71
room
silver
spring
md
or
by
calling
or
by
email
ocod
fda
hhs
gov
or
from
the
internet
at
https
www
fda
gov
vaccines-blood-biologics
guidance-compliance-regulatory-information
biologics
biologics-guidances
table
of
contents
i
introduction
ii
scope
iii
background
iv
general
principles
a
cybersecurity
is
part
of
device
safety
and
the
quality
system
regulation
a
secure
product
development
framework
spdf
may
be
one
way
to
satisfy
the
qs
regulation
b
designing
for
security
c
transparency
d
submission
documentation
v
using
an
spdf
to
manage
cybersecurity
risks
a
security
risk
management
threat
modeling
cybersecurity
risk
assessment
interoperability
considerations
third-party
software
components
security
assessment
of
unresolved
anomalies
tplc
security
risk
management
b
security
architecture
implementation
of
security
controls
security
architecture
views
c
cybersecurity
testing
vi
cybersecurity
transparency
a
labeling
recommendations
for
devices
with
cybersecurity
risks
b
cybersecurity
management
plans
appendix
security
control
categories
and
associated
recommendations
authentication
authorization
cryptography
code
data
and
execution
integrity
confidentiality
event
detection
and
logging
resiliency
and
recovery
firmware
and
software
updates
appendix
submission
documentation
for
security
architecture
flows
a
diagrams
b
information
details
for
an
architecture
view
appendix
submission
documentation
for
investigational
device
exemptions
appendix
general
premarket
submission
documentation
elements
and
scaling
with
risk
appendix
terminology
cybersecurity
in
medical
devices
quality
system
considerations
and
content
of
premarket
submissions
guidance
for
industry
and
food
and
drug
administration
staff
this
guidance
represents
the
current
thinking
of
the
food
and
drug
administration
fda
or
agency
on
this
topic
it
does
not
establish
any
rights
for
any
person
and
is
not
binding
on
fda
or
the
public
you
can
use
an
alternative
approach
if
it
satisfies
the
requirements
of
the
applicable
statutes
and
regulations
to
discuss
an
alternative
approach
contact
the
fda
staff
or
office
responsible
for
this
guidance
as
listed
on
the
title
page
i
introduction
with
the
increasing
integration
of
wireless
internet
and
network-connected
capabilities
portable
media
e
g
usb
or
cd
and
the
frequent
electronic
exchange
of
medical
device
related
health
information
and
other
information
the
need
for
robust
cybersecurity
controls
to
ensure
medical
device
safety
and
effectiveness
has
become
more
important
in
addition
cybersecurity
threats
to
the
healthcare
sector
have
become
more
frequent
and
more
severe
carrying
increased
potential
for
clinical
impact
cybersecurity
incidents
have
rendered
medical
devices
and
hospital
networks
inoperable
disrupting
the
delivery
of
patient
care
across
healthcare
facilities
in
the
u
s
and
globally
such
cyber
attacks
and
exploits
may
lead
to
patient
harm
as
a
result
of
clinical
hazards
such
as
delay
in
diagnoses
and
or
treatment
increased
connectivity
has
resulted
in
individual
devices
operating
as
single
elements
of
larger
medical
device
systems
these
systems
can
include
healthcare
facility
networks
other
devices
and
software
update
servers
among
other
interconnected
components
consequently
without
adequate
cybersecurity
considerations
across
all
aspects
of
these
systems
a
cybersecurity
threat
can
compromise
the
safety
and
or
effectiveness
of
a
device
by
compromising
the
functionality
of
any
asset
in
the
system
as
a
result
ensuring
device
safety
and
effectiveness
includes
adequate
device
cybersecurity
as
well
as
its
security
as
part
of
the
larger
system
for
the
current
edition
of
the
fda-recognized
consensus
standard
s
referenced
in
this
document
see
the
fda
recognized
consensus
standards
database
for
more
information
available
at
https
www
accessdata
fda
gov
scripts
cdrh
cfdocs
cfstandards
search
cfm
regarding
use
of
consensus
standards
in
regulatory
submissions
please
refer
to
the
fda
guidance
titled
appropriate
use
of
voluntary
consensus
standards
in
premarket
submissions
for
medical
devices
and
standards
development
and
the
use
of
standards
in
regulatory
submissions
reviewed
in
the
center
for
biologics
evaluation
and
research
for
applications
currently
pending
with
fda
at
the
time
of
initial
publication
of
this
guidance
as
well
as
those
submitted
after
initial
publication
of
this
guidance
fda
intends
to
work
collaboratively
with
manufacturers
of
such
premarket
submissions
as
part
of
the
fda
review
process
in
general
fda's
guidance
documents
do
not
establish
legally
enforceable
responsibilities
instead
guidances
describe
the
agency's
current
thinking
on
a
topic
and
should
be
viewed
only
as
recommendations
unless
specific
regulatory
or
statutory
requirements
are
cited
the
use
of
the
word
should
in
agency
guidances
means
that
something
is
suggested
or
recommended
but
not
required
ii
scope
this
guidance
document
is
applicable
to
devices
with
cybersecurity
considerations
including
but
not
limited
to
devices
that
have
a
device
software
function4
or
that
contain
software
including
firmware
or
programmable
logic
the
guidance
is
not
limited
to
devices
that
are
network-enabled
or
contain
other
connected
capabilities
this
guidance
describes
recommendations
regarding
the
cybersecurity
information
to
be
submitted
for
devices
under
the
following
premarket
submission
types
when
submitted
to
the
center
for
devices
and
radiological
health
cdrh
or
the
center
for
biologics
evaluation
and
research
cber
premarket
notification
k
submissions
de
novo
requests
premarket
approval
applications
pmas
and
pma
supplements
product
development
protocols
pdps
investigational
device
exemption
ide
submissions
humanitarian
device
exemption
hde
submissions
biologics
license
application
bla
submissions
and
investigational
new
drug
ind
submissions
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
appropriate-use
voluntary-consensus-standards-premarket-submissions-medical-devices
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
standards-development
and-use-standards-regulatory-submissions-reviewed-center-biologics-evaluation
for
the
purposes
of
this
guidance
device
software
function
means
software
function
that
meets
the
device
definition
in
section
h
of
the
federal
food
drug
and
cosmetic
act
fd
c
act
the
term
function
is
a
distinct
purpose
of
the
product
which
could
be
the
intended
use
or
a
subset
of
the
intended
use
of
the
product
for
more
information
see
fda's
guidance
content
of
premarket
submissions
for
device
software
functions
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
content-premarket-submissions
device-software-functions
this
guidance
applies
to
all
types
of
devices
within
the
meaning
of
section
h
of
the
federal
food
drug
and
cosmetic
act
fd
c
act
including
devices
that
meet
the
definition
of
a
biological
product
under
section
of
the
public
health
service
act
whether
or
not
they
require
a
premarket
submission
therefore
the
recommendations
in
this
guidance
also
apply
to
devices
for
which
a
premarket
submission
is
not
required
e
g
for
k
exempt
devices
this
guidance
also
applies
to
cyber
devices
as
defined
in
section
524b
of
the
fd
c
act
which
are
a
subset
of
devices
generally
the
recommendations
in
this
guidance
apply
to
the
device
constituent
part
of
a
combination
product5
such
as
drug-device
and
biologic-device
combination
products
when
the
device
constituent
part
presents
cybersecurity
considerations
including
but
not
limited
to
devices
that
that
have
a
device
software
function
or
that
contain
software
including
firmware
or
programmable
logic
for
more
information
contact
the
fda
review
division
that
will
have
the
lead
review
for
the
combination
product
as
ide
submissions
have
a
different
benefit-risk
threshold
and
are
not
marketing
authorizations
specific
recommendations
for
ide
submission
documentation
are
provided
in
appendix
additionally
appendix
contains
terminology
used
throughout
the
guidance
iii
background
fda
recognizes
that
medical
device
cybersecurity
is
a
shared
responsibility
among
stakeholders
throughout
the
use
environment
of
the
medical
device
system
including
healthcare
facilities
patients
healthcare
providers
and
manufacturers
of
medical
devices
for
the
purposes
of
this
guidance
the
term
medical
device
system
includes
the
device
and
systems
such
as
healthcare
facility
networks
other
devices
and
software
update
servers
to
which
it
is
connected
events
across
the
healthcare
sector
have
stressed
the
importance
of
cybersecurity
to
patient
safety
the
wannacry8
ransomware9
affected
hospital
systems
and
medical
devices
across
the
globe
vulnerabilities
identified
in
commonly
used
third-party
components
like
urgent
and
sweyntooth
have
led
to
potential
safety
concerns
across
a
broad
range
of
devices
that
are
cfr
e
cfr
this
guidance
has
been
prepared
by
cdrh
and
cber
in
consultation
with
the
center
for
drug
evaluation
and
research
cder
and
the
office
of
combination
products
ocp
additional
information
on
the
wannacry
ransomware
attack
is
available
at
https
h-isac
org
may-16-2017
wannacry-update
for
the
purposes
of
this
guidance
we
consider
ransomware
an
ever-evolving
form
of
malware
designed
to
encrypt
files
on
a
device
rendering
any
files
and
the
systems
that
rely
on
them
unusable
this
definition
is
cited
from
the
cybersecurity
infrastructure
security
agency's
cisa's
webpage
https
www
cisa
gov
stopransomware
ransomware-101
for
more
information
see
fda's
cybersecurity
webpage
available
at
https
www
fda
gov
medical
devices
digital-health-center-excellence
cybersecurity
the
fda
safety
communication
on
the
sweyntooth
vulnerabilities
is
available
at
https
public4
pagefreezer
com
browse
fda
08-02-2023t11
https
www
fda
gov
medical-devices
safety
communications
sweyntooth-cybersecurity-vulnerabilities-may-affect-certain-medical-devices-fda-safety
communication
used
in
various
clinical
specialties
in
a
ransomware
attack
on
a
german
hospital
highlighted
the
potential
impacts
due
to
delayed
patient
care
when
a
cybersecurity
attack
forced
patients
to
be
diverted
to
another
hospital
fda
issued
a
final
cybersecurity
guidance
addressing
premarket
expectations
in
content
of
premarket
submissions
for
management
of
cybersecurity
in
medical
devices
and
the
complementary
guidance
postmarket
management
of
cybersecurity
in
medical
devices
hereafter
referred
to
as
the
postmarket
cybersecurity
guidance
in
however
the
rapidly
evolving
landscape
an
increased
understanding
of
emerging
threats
and
the
need
for
capable
deployment
of
mitigations
throughout
the
total
product
lifecycle
tplc
warrants
an
updated
iterative
approach
to
device
cybersecurity
the
changes
since
the
guidance
are
intended
to
further
emphasize
the
importance
of
ensuring
that
devices
are
designed
securely
are
designed
to
be
capable
of
mitigating
emerging
cybersecurity
risks
throughout
the
tplc
and
to
more
clearly
outline
fda's
recommendations
for
premarket
submission
information
to
address
cybersecurity
concerns
one
way
these
tplc
considerations
for
devices
can
be
achieved
is
through
the
implementation
and
adoption
of
a
secure
product
development
framework
spdf
an
spdf
as
described
in
this
guidance
is
a
set
of
processes
that
reduce
the
number
and
severity
of
vulnerabilities
in
products
throughout
the
device
lifecycle
examples
of
such
frameworks
exist
in
many
sectors
including
the
medical
device
sector
risk
management
for
device
manufacturers
is
the
essential
systematic
practice
of
identifying
analyzing
evaluating
controlling
and
monitoring
risk
throughout
the
product
lifecycle
to
ensure
that
the
devices
they
manufacture
are
safe
and
effective
the
quality
system
qs
regulation
in
cfr
part
explicitly
addresses
risk
management
activities
in
cfr
g
although
fda
is
currently
in
the
process
of
rulemaking15
to
revise
the
qs
regulation
including
cfr
g
should
fda
finalize
the
rule
as
proposed
the
concept
of
risk
management
as
described
in
cfr
g
would
remain
the
recommendations
contained
in
this
guidance
document
are
intended
to
supplement
fda's
postmarket
cybersecurity
guidance
cybersecurity
for
networked
medical
devices
containing
additional
information
on
the
german
hospital
ransomware
attack
is
available
at
https
www
wired
co
uk
article
ransomware-hospital-death-germany
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
postmarket
management-cybersecurity-medical-devices
see
appendix
terminology
on
february
fda
issued
a
proposed
rule
to
amend
the
device
qs
regulation
cfr
part
to
align
more
closely
with
international
consensus
standards
for
devices
fr
available
at
https
www
federalregister
gov
documents
medical-devices-quality-system-regulation
amendments
specifically
fda
proposed
to
withdraw
the
majority
of
the
current
requirements
in
part
and
instead
incorporate
by
reference
the
edition
of
the
international
organization
for
standardization
iso
medical
devices
quality
management
systems
requirements
for
regulatory
purposes
in
part
as
stated
in
that
proposed
rule
the
requirements
in
iso
are
when
taken
in
totality
substantially
similar
to
the
requirements
of
the
current
part
providing
a
similar
level
of
assurance
in
a
firm's
quality
management
system
and
ability
to
consistently
manufacture
devices
that
are
safe
and
effective
and
otherwise
in
compliance
with
the
fd
c
act
fda
intends
to
finalize
this
proposed
rule
expeditiously
when
the
final
rule
takes
effect
fda
will
also
update
the
references
to
provisions
in
cfr
part
in
this
guidance
to
be
consistent
with
that
rule
off-the-shelf
ots
software
and
content
of
premarket
submissions
for
device
software
functions
hereafter
referred
to
as
the
premarket
software
guidance
this
guidance
replaces
the
final
guidance
content
of
premarket
submissions
for
management
of
cybersecurity
in
medical
devices
the
recommendations
in
this
guidance
also
generally
align
with
or
expand
upon
the
recommendations
in
the
pre-market
considerations
for
medical
device
cybersecurity
section
of
the
international
medical
device
regulators
forum
imdrf
final
guidance
principles
and
practices
for
medical
device
cybersecurity
issued
march
additionally
section
of
the
consolidated
appropriations
act
enacted
on
december
added
section
524b
ensuring
cybersecurity
of
medical
devices
to
the
fd
c
act
under
section
524b
a
of
the
fd
c
act
a
person
who
submits
a
k
pma
pdp
de
novo
or
hde
for
a
device
that
meets
the
definition
of
a
cyber
device
as
defined
under
section
524b
c
of
the
fd
c
act
is
required
to
submit
information
to
ensure
that
cyber
devices
meet
the
cybersecurity
requirements
under
section
524b
b
of
the
fd
c
act
section
524b
c
of
the
fd
c
act
defines
cyber
device
as
a
device
that
includes
software
validated
installed
or
authorized
by
the
sponsor
as
a
device
or
in
a
device
has
the
ability
to
connect
to
the
internet
and
contains
any
such
technological
characteristics
validated
installed
or
authorized
by
the
sponsor
that
could
be
vulnerable
to
cybersecurity
threats
the
recommendations
in
this
guidance
are
intended
to
help
manufacturers
meet
their
obligations
under
section
524b
of
the
fd
c
act
iv
general
principles
this
section
provides
general
principles
for
device
cybersecurity
relevant
to
device
manufacturers
the
principles
in
this
guidance
document
are
important
to
the
improvement
of
device
cybersecurity
and
when
followed
are
expected
to
have
a
positive
impact
on
the
safety
and
effectiveness
of
the
device
the
recommendations
in
this
guidance
cover
all
relevant
cybersecurity
considerations
that
may
affect
device
safety
and
effectiveness
including
but
not
limited
to
software
hardware
and
firmware
a
cybersecurity
is
part
of
device
safety
and
the
quality
system
regulation
device
manufacturers
must
establish
and
follow
quality
systems
to
help
ensure
that
their
products
consistently
meet
applicable
requirements
and
specifications
the
quality
systems
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
cybersecurity
networked-medical-devices-containing-shelf-ots-software
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
guidance-content
premarket-submissions-software-contained-medical-devices
available
at
http
www
imdrf
org
docs
imdrf
final
technical
imdrf-tech-200318-pp-mdc-n60
pdf
in
addition
to
the
cybersecurity
requirements
set
forth
in
section
524b
b
of
the
fd
c
act
section
524b
b
of
the
fd
c
act
requires
cyber
device
manufacturers
to
comply
with
any
other
such
requirements
fda
sets
forth
in
regulations
to
demonstrate
reasonable
assurance
that
the
device
and
related
systems
are
cybersecure
requirements
are
found
in
the
qs
regulation
in
cfr
part
depending
on
the
device
qs
requirements
may
be
relevant
at
the
premarket
stage
postmarket
stage
or
both
in
the
premarket
context
in
order
to
demonstrate
a
reasonable
assurance
of
safety
and
effectiveness
for
certain
devices
with
cybersecurity
risks
documentation
outputs
related
to
the
requirements
of
the
qs
regulation
may
be
one
source
of
documentation
to
include
as
part
of
the
premarket
submission
this
guidance
is
intended
to
explain
how
such
documentation
that
may
be
relevant
for
qs
regulation
compliance
can
also
be
used
to
show
how
a
sponsor
or
manufacturer
is
addressing
cybersecurity
considerations
relevant
to
a
device
for
example
cfr
a
requires
that
for
all
classes
of
devices
automated
with
software
a
manufacturer
must
establish
and
maintain
procedures
to
control
the
design
of
the
device
in
order
to
ensure
that
specified
design
requirements
are
met
design
controls
as
part
of
design
controls
a
manufacturer
must
establish
and
maintain
procedures
for
validating
the
device
design
which
shall
include
software
validation
and
risk
analysis
where
appropriate
cfr
g
as
part
of
the
software
validation
and
risk
analysis
required
by
cfr
g
software
device
manufacturers
may
need
to
establish
cybersecurity
risk
management
and
validation
processes
where
appropriate
see
also
fda's
guidance
titled
content
of
premarket
submissions
for
device
software
functions
software
validation
and
risk
management
are
key
elements
of
cybersecurity
analyses
and
demonstrating
whether
a
device
has
a
reasonable
assurance
of
safety
and
effectiveness
fda
requires
manufacturers
to
implement
development
processes
that
account
for
and
address
software
risks
throughout
the
design
and
development
process
as
part
of
design
controls
as
discussed
in
fda's
regulations
regarding
design
control
which
may
include
cybersecurity
considerations
for
example
these
processes
should
address
the
identification
of
security
risks
the
design
requirements
for
how
the
risks
will
be
controlled
and
the
evidence
that
the
controls
function
as
designed
and
are
effective
in
their
environment
of
use
for
ensuring
adequate
security
a
secure
product
development
framework
spdf
may
be
one
way
to
satisfy
the
qs
regulation
cybersecurity
threats
have
the
potential
to
exploit
one
or
more
vulnerabilities
that
could
lead
to
patient
harm
the
greater
the
number
of
vulnerabilities
that
exist
and
or
are
identified
over
time
in
the
postmarket
context
design
controls
may
also
be
important
to
ensure
medical
device
cybersecurity
and
maintain
medical
device
safety
and
effectiveness
fda
recommends
that
device
manufacturers
implement
comprehensive
cybersecurity
risk
management
programs
and
documentation
consistent
with
the
qs
regulation
including
but
not
limited
to
complaint
handling
cfr
quality
audit
cfr
corrective
and
preventive
action
cfr
software
validation
and
risk
analysis
cfr
g
and
servicing
cfr
the
recommendations
in
this
guidance
are
not
intended
to
suggest
that
fda
will
evaluate
an
applicant's
compliance
with
the
qs
regulation
as
part
of
its
premarket
submission
under
section
k
of
the
fd
c
act
in
our
determination
of
a
device's
substantial
equivalence
as
this
is
not
a
requirement
for
such
decision
under
section
i
of
the
fd
c
act
this
guidance
is
intended
to
explain
how
fda
evaluates
the
performance
of
device
cybersecurity
and
the
cybersecurity
outputs
of
activities
that
are
part
and
parcel
of
qs
regulation
compliance
and
explain
how
the
qs
regulation
can
be
leveraged
to
demonstrate
these
performance
outputs
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
guidance-content
premarket-submissions-software-contained-medical-devices
see
cfr
in
a
system
in
which
a
device
operates
the
easier
a
threat
can
compromise
the
safety
and
effectiveness
of
the
medical
device
an
spdf
is
a
set
of
processes
that
help
identify
and
reduce
the
number
and
severity
of
vulnerabilities
in
products
an
spdf
encompasses
all
aspects
of
a
product's
lifecycle
including
design
development
release
support
and
decommission
additionally
using
spdf
processes
during
device
design
may
prevent
the
need
to
re-engineer
the
device
when
connectivity-based
features
are
added
after
marketing
and
distribution
or
when
vulnerabilities
resulting
in
uncontrolled
risks
are
discovered
an
spdf
can
be
integrated
with
existing
processes
for
product
and
software
development
risk
management
and
the
quality
system
at
large
using
an
spdf
is
one
approach
to
help
ensure
that
the
qs
regulation
is
met
because
of
its
benefits
in
helping
comply
with
the
qs
regulation
and
cybersecurity
fda
encourages
manufacturers
to
use
an
spdf
but
other
approaches
might
also
satisfy
the
qs
regulation
b
designing
for
security
when
reviewing
premarket
submissions
fda
intends
to
assess
device
cybersecurity
based
on
a
number
of
factors
including
but
not
limited
to
the
device's
ability
to
provide
and
implement
the
security
objectives
below
throughout
the
device
architecture
the
security
objectives
below
generally
may
apply
broadly
to
devices
within
the
scope
of
this
guidance
including
but
not
limited
to
devices
containing
artificial
intelligence
and
machine
learning
ai
ml
and
cloud
based
services
security
objectives
authenticity
which
includes
integrity
authorization
availability
confidentiality
and
secure
and
timely
updatability
and
patchability
premarket
submissions
should
include
information
that
describes
how
the
above
security
objectives
are
addressed
by
and
integrated
into
the
device
design
the
extent
to
which
security
requirements
architecture
supply
chain
and
implementation
are
needed
to
meet
these
objectives
will
depend
on
but
may
not
be
limited
to
the
device's
intended
use
indications
for
use
and
reasonably
foreseeable
misuse
the
presence
and
functionality
of
its
electronic
data
interfaces
its
intended
and
actual
environment
of
use
the
risks
presented
by
cybersecurity
vulnerabilities
the
exploitability
of
the
vulnerabilities
and
the
risk
of
patient
harm
due
to
vulnerability
exploitation
manufacturers
may
not
be
able
to
account
for
all
potential
environments
of
use
but
should
consider
the
range
of
use
environments
and
ensure
the
risks
are
identified
and
controlled
for
the
worst-case
environments
of
use
e
g
least
secure
expected
network
configuration
s
spdf
processes
aim
to
reduce
the
number
and
severity
of
vulnerabilities
and
thereby
reduce
the
exploitability
of
a
medical
device
system
and
the
associated
risk
of
patient
harm
because
exploitation
of
known
vulnerabilities
or
weak
cybersecurity
controls
should
be
considered
reasonably
foreseeable
failure
modes
for
medical
device
systems
these
factors
should
be
addressed
in
the
device
design
one
of
the
key
benefits
of
using
an
spdf
is
that
a
medical
device
system
is
more
likely
to
be
secure
by
design
such
that
the
device
is
designed
from
the
outset
to
be
secure
within
its
system
and
or
network
of
use
throughout
the
device
lifecycle
c
transparency
a
lack
of
cybersecurity
information
such
as
information
necessary
to
integrate
the
device
into
the
use
environment
as
well
as
information
needed
by
users
to
maintain
the
medical
device
system's
cybersecurity
over
the
device
lifecycle
has
the
potential
to
affect
the
safety
and
effectiveness
of
a
device
in
order
to
address
these
concerns
it
is
important
for
device
users
to
have
access
to
information
pertaining
to
the
device's
cybersecurity
controls
potential
risks
to
the
medical
device
system
and
other
relevant
information
for
example
a
failure
to
disclose
all
of
the
communication
interfaces
or
third-party
software
could
fail
to
convey
potential
sources
of
risks
insufficient
information
pertaining
to
whether
a
device
has
known
but
not
disclosed
cybersecurity
vulnerabilities
or
risks
may
be
relevant
to
determining
whether
a
device's
safety
or
effectiveness
could
be
degraded
and
or
labeling
that
does
not
include
sufficient
information
to
explain
how
to
securely
configure
or
update
the
device
may
limit
the
ability
of
end
users
to
appropriately
manage
and
protect
the
medical
device
system
this
information
and
other
relevant
information
are
important
in
helping
users
understand
a
medical
device
system's
resilience
to
cybersecurity
threats
the
threats
that
it
may
be
exposed
to
and
how
those
threats
may
be
prevented
or
mitigated
without
it
cybersecurity
risks
could
be
undisclosed
inappropriately
identified
or
inappropriately
responded
to
among
other
potential
impacts
which
could
lead
to
compromises
in
device
safety
and
effectiveness
fda
believes
that
the
cybersecurity
information
discussed
in
this
guidance
is
important
for
the
safe
and
effective
use
of
devices
and
should
be
included
in
device
labeling
as
discussed
below
in
section
vi
d
submission
documentation
device
cybersecurity
design
and
documentation
are
expected
to
scale
with
the
cybersecurity
risk
of
that
device
manufacturers
should
take
into
account
the
larger
system
in
which
the
device
may
be
used
for
example
a
cybersecurity
risk
assessment
performed
on
a
simple
non-connected
thermometer
may
conclude
that
the
risks
are
limited
and
therefore
such
a
device
needs
only
a
limited
security
architecture
i
e
addressing
only
device
hardware
and
software
and
few
security
controls
based
on
the
technical
characteristics
and
design
of
the
device
however
if
a
for
more
information
on
reasonably
foreseeable
misuse
see
the
imdrf
final
guidance
principles
and
practices
for
medical
device
cybersecurity
available
at
http
www
imdrf
org
docs
imdrf
final
technical
imdrf-tech-200318
pp-mdc-n60
pdf
thermometer
is
used
in
a
safety-critical
control
loop
or
is
connected
to
networks
or
other
devices
then
the
cybersecurity
risks
for
the
device
are
considered
to
be
greater
and
more
substantial
design
controls
should
result
submitters
should
consider
including
in
premarket
submissions
to
fda
documentation
generation
from
those
design
controls
used
during
the
development
of
a
device
with
cybersecurity
risks
as
a
way
to
demonstrate
reasonable
assurance
of
safety
and
effectiveness
this
guidance
identifies
the
cybersecurity
information
fda
recommends
to
help
support
a
premarket
submission
for
devices
within
the
scope
of
this
guidance
as
cybersecurity
is
part
of
device
safety
and
effectiveness
cybersecurity
controls
established
during
premarket
development
should
also
take
into
consideration
the
intended
and
actual
use
environment
see
section
iv
b
cybersecurity
risks
evolve
over
time
and
as
a
result
the
effectiveness
of
cybersecurity
controls
may
degrade
as
new
risks
threats
and
attack
methods
emerge
in
the
k
context
fda
evaluates
the
cybersecurity
information
submitted
and
the
protections
the
cybersecurity
controls
provide
in
demonstrating
substantial
equivalence
see
section
i
of
the
fd
c
act
and
cfr
b
ii
b
in
addition
inadequate
cybersecurity
information
in
the
device
labeling
may
cause
a
device
to
be
misbranded
under
section
f
of
the
fd
c
act
if
its
labeling
does
not
bear
adequate
directions
for
use
or
under
section
j
of
the
fd
c
act
because
it
is
dangerous
to
health
when
used
in
the
manner
recommended
or
suggested
in
the
labeling
among
other
possible
violations
for
cyber
devices
failure
to
comply
with
any
requirement
under
section
524b
b
relating
to
ensuring
device
cybersecurity
is
considered
a
prohibited
act
under
section
q
of
the
fd
c
act
the
cybersecurity
information
being
recommended
to
be
included
in
submissions
as
detailed
in
this
guidance
is
based
on
risks
due
to
cybersecurity
not
on
any
other
criteria
or
level
of
risk
concern
established
in
a
separate
fda
guidance
e
g
the
risk-based
approach
in
the
premarket
software
guidance
to
help
determine
a
device's
documentation
level
for
example
a
device
that
is
determined
to
have
a
greater
software
risk
may
only
have
a
small
cybersecurity
risk
due
to
how
the
device
is
designed
likewise
a
device
with
a
smaller
software
risk
may
have
a
significant
cybersecurity
risk
therefore
the
recommendations
in
this
guidance
regarding
information
to
be
submitted
to
the
fda
are
intended
to
address
the
cybersecurity
risk
as
assessed
by
the
cybersecurity
risk
assessment
during
development
of
a
device
and
are
expected
to
scale
based
on
the
cybersecurity
risk
the
premarket
submission
documentation
recommendations
throughout
this
guidance
apply
to
all
premarket
submissions
and
are
intended
to
be
used
to
support
fda's
assessment
of
a
device's
safety
and
effectiveness
as
previously
discussed
section
524b
of
the
fd
c
act
requires
the
submission
of
certain
documentation
for
cyber
devices
for
more
information
regarding
the
substantial
equivalence
review
standard
please
refer
to
fda's
guidance
the
k
program
evaluating
substantial
equivalence
in
premarket
notifications
k
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
510k-program-evaluating-substantial
equivalence-premarket-notifications-510k
for
cyber
devices
some
of
the
information
recommended
in
this
guidance
may
help
manufacturers
meet
their
obligations
for
what
is
required
to
be
in
premarket
submissions
under
section
524b
v
using
an
spdf
to
manage
cybersecurity
risks
the
documentation
recommended
in
this
guidance
is
based
on
fda's
experience
evaluating
the
safety
and
effectiveness
of
devices
with
cybersecurity
vulnerabilities
however
sponsors
may
use
alternative
approaches
and
provide
different
documentation
so
long
as
their
approach
and
documentation
satisfy
premarket
submission
requirements
in
applicable
statutory
provisions
and
regulations
the
increasingly
interconnected
nature
of
medical
devices
has
demonstrated
the
importance
of
addressing
cybersecurity
risks
associated
with
device
connectivity
in
device
design
because
of
the
effects
on
safety
and
effectiveness
cybersecurity
risks
to
the
medical
device
or
to
the
larger
medical
device
system
can
be
reasonably
controlled
through
using
an
spdf
the
primary
goal
of
using
an
spdf
is
to
manufacture
and
maintain
safe
and
effective
devices
from
a
security
standpoint
these
are
also
trustworthy
and
resilient
devices
these
devices
can
then
be
managed
e
g
installed
configured
updated
review
of
device
logs
through
the
device
design
and
associated
labeling
by
the
device
manufacturers
and
or
users
e
g
patients
healthcare
facilities
for
healthcare
facilities
these
devices
can
also
be
managed
within
their
own
cybersecurity
risk
management
frameworks
such
as
the
national
institute
of
standards
and
technology
nist
framework
for
improving
critical
infrastructure
cybersecurity
generally
referred
to
as
the
nist
cybersecurity
framework
or
nist
csf
fda
recommends
that
manufacturers
use
device
design
processes
such
as
those
described
in
the
qs
regulation
to
support
secure
product
development
and
maintenance
to
preserve
flexibility
for
manufacturers
manufacturers
may
use
other
existing
frameworks
that
satisfy
the
qs
regulation
and
align
with
fda's
recommendations
for
using
an
spdf
possible
frameworks
to
consider
include
but
are
not
limited
to
the
medical
device-specific
framework
that
can
be
found
in
the
medical
device
and
health
it
joint
security
plan
jsp
and
iec
frameworks
from
other
sectors
may
also
comply
with
the
qs
regulations
like
the
framework
provided
in
ansi
isa
security
for
industrial
automation
and
control
systems
part
product
security
development
life-cycle
requirements
the
following
subsections
provide
recommendations
for
using
spdf
processes
that
fda
believes
provide
important
considerations
for
the
development
of
devices
that
are
safe
and
effective
how
these
processes
can
complement
the
qs
regulation
and
the
documentation
fda
recommends
manufacturers
provide
for
review
as
part
of
premarket
submissions
the
addressing
cybersecurity
risks
is
in
addition
to
addressing
other
risks
including
software
biocompatibility
sterilization
and
electromagnetic
compatibility
among
others
for
more
information
please
see
the
nist
cybersecurity
framework
available
at
https
www
nist
gov
cyberframework
medical
device
and
health
it
joint
security
plan
jsp
is
available
at
https
healthsectorcouncil
org
the-joint
security-plan
ansi
isa-62443-4-1
security
for
industrial
automation
and
control
systems
part
product
security
development
life-cycle
requirements
outlines
a
secure
product
development
lifecycle
similar
to
that
of
the
jsp
information
in
these
sections
do
not
represent
a
complete
spdf
for
more
information
on
spdfs
see
earlier
in
section
v
in
addition
fda
does
not
recommend
that
manufacturers
discontinue
existing
effective
processes
a
security
risk
management
to
fully
account
for
cybersecurity
risks
in
medical
device
systems
the
safety
and
security
risks
of
each
device
should
be
assessed
within
the
context
of
the
larger
system
in
which
the
device
operates
in
the
context
of
cybersecurity
security
risk
management
processes
are
critical
because
given
the
evolving
nature
of
cybersecurity
threats
and
risks
no
device
is
or
can
be
completely
secure
security
risk
management
should
be
an
integrated
part
of
a
manufacturer's
entire
quality
system
addressed
throughout
the
tplc
the
quality
system
processes
entail
the
technical
personnel
and
management
practices
among
others
that
manufacturers
use
to
manage
potential
risks
to
their
devices
and
ensure
that
their
devices
are
and
once
on
the
market
remain
safe
and
effective
which
includes
security
performing
security
risk
management
is
distinct
from
performing
safety
risk
management
as
described
in
iso
the
distinction
in
the
performance
of
these
processes
is
due
to
the
fact
that
in
the
security
context
versus
the
safety
context
the
scope
of
possible
harm
and
the
risk
assessment
factors
may
be
different
also
while
safety
risk
management
focuses
on
physical
injury
damage
to
property
or
the
environment
or
delay
and
or
denial
of
care
due
to
device
or
system
unavailability
security
risk
management
may
include
risks
that
can
result
in
indirect
or
direct
patient
harm
additionally
risks
that
are
outside
of
fda's
assessment
of
safety
and
effectiveness
such
as
those
related
to
business
or
reputational
risks
may
also
exist
the
scope
and
objective
of
a
security
risk
management
process
in
conjunction
with
other
spdf
processes
e
g
security
testing
is
to
expose
how
threats
through
vulnerabilities
can
manifest
patient
harm
and
other
potential
risks
these
processes
should
also
ensure
that
risk
control
measures
for
one
type
of
risk
assessment
do
not
inadvertently
introduce
new
risks
in
the
other
for
example
aami
tir57
details
how
the
security
and
safety
risk
management
processes
should
interface
to
ensure
all
risks
are
adequately
assessed
fda
recommends
that
security
risk
management
processes
as
detailed
in
the
qs
regulation
be
established
or
incorporated
into
those
that
already
exist
and
should
address
the
manufacturer's
design
manufacturing
and
distribution
processes
as
well
as
updates
across
the
tplc
the
processes
in
the
qs
regulation
which
may
be
relevant
in
this
context
include
but
are
not
limited
to
design
controls
cfr
validation
of
production
processes
cfr
and
corrective
and
preventive
actions
cfr
to
ensure
both
safety
and
security
risks
are
adequately
addressed
for
completeness
in
performing
risk
analyses
under
cfr
g
fda
recommends
that
device
manufacturers
conduct
both
a
safety
risk
assessment
and
a
separate
accompanying
security
risk
assessment
to
ensure
a
more
comprehensive
identification
and
management
of
patient
safety
risks
the
tplc
processes
include
design
and
development
manufacturing
postmarket
monitoring
delivering
device
software
and
firmware
updates
and
servicing
among
others
aami
tir57
principles
for
medical
device
security
risk
management
describes
the
security
risk
management
process
and
how
the
security
risk
management
process
should
have
links
into
the
safety
risk
management
process
and
vice
versa
cfr
a
device
should
be
designed
to
eliminate
or
mitigate
known
vulnerabilities
for
marketed
devices
if
comprehensive
design
mitigations
are
not
possible
compensating
controls
should
be
considered
for
all
devices
when
any
known
vulnerabilities
are
only
partially
mitigated
or
unmitigated
by
the
device
design
they
should
be
assessed
as
reasonably
foreseeable
risks
in
the
risk
assessment
and
be
assessed
for
additional
control
measures
or
risk
transfer35
to
the
user
operator
or
if
necessary
the
patient
risk
transfer
if
appropriate
should
only
occur
when
all
relevant
risk
information
is
known
assessed
and
appropriately
communicated
to
users
and
includes
risks
inherited
from
the
supply
chain
as
well
as
how
risk
transfer
will
be
handled
when
the
device
or
manufacturer-controlled
assets
of
the
medical
device
system
reaches
end
of
support
and
end
of
life
and
whether
or
how
the
user
is
able
to
take
on
that
role
e
g
if
the
user
may
be
a
patient
to
document
the
security
risk
management
activities
for
a
medical
device
system
fda
recommends
that
manufacturers
generate
a
security
risk
management
plan
and
report
such
as
that
described
in
aami
tir57
manufacturers
should
include
their
security
risk
management
reports
including
the
outputs
of
their
security
risk
management
processes
in
their
premarket
submissions
to
help
demonstrate
the
safety
and
effectiveness
of
the
device
a
security
risk
management
report
such
as
that
described
in
that
in
aami
tir57
should
be
sufficient
to
support
the
security
risk
management
process
aspect
of
demonstrating
a
reasonable
assurance
of
safety
and
effectiveness
such
report
should
include
the
documentation
elements
for
the
system
threat
modeling
cybersecurity
risk
assessment
software
bill
of
materials
sbom
component
support
information
vulnerability
assessments
and
unresolved
anomaly
assessment
s
described
in
the
sections
below
in
the
subsections
below
we
discuss
fda's
recommendations
regarding
the
scope
and
or
content
of
specific
security
risk
management
documentation
elements
in
addition
to
containing
the
documentation
elements
listed
above
the
security
risk
management
report
should
summarize
the
risk
evaluation
methods
and
processes
detail
the
residual
risk
conclusion
from
the
security
risk
assessment
detail
the
risk
mitigation
activities
undertaken
as
part
of
a
manufacturer's
risk
management
processes
and
provide
traceability
between
the
threat
model
cybersecurity
risk
assessment
sbom
and
testing
documentation
as
discussed
later
in
this
guidance
as
well
as
other
relevant
cybersecurity
risk
management
documentation
for
the
purposes
of
this
guidance
we
consider
risk
transfer
to
include
actions
taken
to
manage
risk
that
shifts
some
or
all
of
the
risk
to
another
user
asset
system
network
or
geographic
area
this
definition
is
adapted
from
the
dhs
risk
lexicon
available
at
https
www
cisa
gov
resources-tools
resources
dhs-risk-lexicon
details
on
the
content
for
security
risk
management
plans
and
reports
beyond
those
specifically
identified
can
be
found
in
aami
tir57
principles
for
medical
device
security
risk
management
while
security
architecture
is
likely
captured
as
a
component
of
the
security
risk
management
process
it
is
discussed
separately
for
the
purposes
of
this
guidance
due
to
the
level
of
detail
recommended
to
be
provided
by
manufacturers
in
order
to
facilitate
fda
review
of
the
safety
and
effectiveness
of
the
device
threat
modeling
threat
modeling
includes
a
process
for
identifying
security
objectives
risks
and
vulnerabilities
across
the
medical
device
system
and
then
defining
countermeasures
to
prevent
mitigate
monitor
or
respond
to
the
effects
of
threats
to
the
medical
device
system
throughout
its
lifecycle
it
is
foundational
for
optimizing
system
product
network
application
and
connection
security
when
applied
appropriately
and
comprehensively
with
respect
to
security
risk
management
and
in
order
to
identify
appropriate
security
risks
and
controls
for
the
medical
device
system
fda
recommends
that
threat
modeling
be
performed
to
inform
and
support
the
risk
analysis
activities
as
part
of
the
risk
assessment
fda
recommends
threat
modeling
be
performed
throughout
the
design
process
and
be
inclusive
of
all
medical
device
system
elements
the
threat
model
should
identify
medical
device
system
risks
and
mitigations
as
well
as
inform
the
pre
and
post-mitigation
risks
considered
as
part
of
the
cybersecurity
risk
assessment
state
any
assumptions
about
the
medical
device
system
or
environment
of
use
e
g
hospital
networks
are
inherently
hostile
therefore
manufacturers
are
recommended
to
assume
that
an
adversary
controls
the
network
with
the
ability
to
alter
drop
and
replay
packets
and
capture
cybersecurity
risks
introduced
through
the
supply
chain
manufacturing
deployment
interoperation
with
other
devices
maintenance
update
activities
and
decommission
activities
that
might
otherwise
be
overlooked
in
a
traditional
safety
risk
assessment
process
fda
recommends
that
premarket
submissions
include
threat
modeling
documentation
to
demonstrate
how
the
medical
device
system
has
been
analyzed
to
identify
potential
security
risks
that
could
impact
safety
and
effectiveness
there
are
a
number
of
methodologies
and
or
combinations
of
methods
for
threat
modeling
that
manufacturers
may
choose
to
use
rationale
for
the
methodology
ies
selected
should
be
provided
with
the
threat
modeling
documentation
additional
recommendations
on
how
threat
modeling
documentation
should
be
submitted
to
fda
are
discussed
in
section
v
b
below
threat
modeling
activities
can
be
performed
and
or
reviewed
during
design
reviews
fda
recommends
that
threat
modeling
documentation
include
sufficient
information
on
threat
modeling
activities
performed
by
the
manufacturer
to
assess
and
review
the
security
features
built
into
the
device
such
that
they
holistically
evaluate
the
device
and
the
system
in
which
the
device
operates
for
the
safety
and
effectiveness
of
the
device
the
mdic
mitre
playbook
for
threat
modeling
medical
devices
is
an
educational
resource
that
discusses
the
threat
modeling
process
different
threat
modeling
techniques
and
provides
fictional
medical
device
examples
the
playbook
is
available
at
https
www
mitre
org
news-insights
publication
playbook-threat-modeling-medical-devices
cybersecurity
risk
assessment
as
a
part
of
security
risk
management
security
risks
and
controls
should
be
assessed
for
residual
risks
as
part
of
a
cybersecurity
risk
assessment
effective
security
risk
assessments
address
the
fact
that
cybersecurity-related
failures
can
occur
either
intentionally
or
unintentionally
accordingly
cybersecurity
risks
are
difficult
to
predict
meaning
that
it
is
not
possible
to
assess
and
quantify
the
likelihood
of
an
incident
occurring
based
on
historical
data
or
modeling
also
known
as
a
probabilistic
manner
this
non-probabilistic
approach
is
not
the
fundamental
approach
performed
in
safety
risk
management
under
iso
and
further
underscores
why
safety
and
security
risk
management
are
distinct
but
connected
processes
instead
security
risk
assessment
processes
focus
on
exploitability
or
the
ability
to
exploit
vulnerabilities
present
within
a
device
and
or
system
fda
recommends
that
manufacturers
assess
identified
risks
according
to
the
level
of
risk
posed
from
the
device
and
the
system
in
which
it
operates
additional
discussion
on
exploitability
assessments
for
the
security
risk
assessment
can
be
found
in
the
fda's
postmarket
cybersecurity
guidance
the
premarket
assessment
of
exploitability
of
a
cybersecurity
risk
may
be
different
from
the
exploitability
assessment
of
a
vulnerability
discovered
postmarket
for
example
some
of
the
exploitability
factors
discussed
in
the
postmarket
cybersecurity
guidance
e
g
exploit
code
maturity
remediation
level
report
confidence
may
not
be
applicable
to
unreleased
software
in
these
instances
a
premarket
exploitability
assessment
could
either
assume
a
worst
case
assessment
and
implement
appropriate
controls
or
provide
a
justification
for
a
reasonable
exploitability
assessment
of
the
risk
throughout
the
tplc
and
how
the
risk
is
controlled
acceptance
criteria
for
cybersecurity
risks
should
carefully
consider
the
tplc
of
the
medical
device
system
as
it
might
be
more
difficult
to
mitigate
cybersecurity
issues
once
the
device
is
marketed
as
discussed
above
in
sections
iv
b
and
v
a
known
vulnerabilities
should
be
assessed
as
reasonably
foreseeable
risks
the
cybersecurity
risk
assessment
for
vulnerabilities
identified
during
cybersecurity
testing
should
also
consider
the
tplc
of
the
device
as
the
exploitability
of
the
vulnerability
is
likely
to
increase
over
the
device
lifecycle
if
a
vulnerability
scan
or
penetration
tester
for
example
was
able
to
exploit
a
vulnerability
the
ability
of
a
threat
actor
to
exploit
that
vulnerability
is
likely
to
increase
over
the
device
lifecycle
furthermore
vulnerabilities
identified
in
cybersecurity
and
infrastructure
security
agency
cisa
known
exploited
vulnerabilities
catalog40
should
be
designed
out
of
the
device
as
they
are
already
being
exploited
and
expose
the
medical
device
system
and
users
to
the
risk
fda
recommends
that
the
cybersecurity
risk
assessment
provided
in
premarket
submissions
should
capture
the
risks
and
controls
identified
from
the
threat
model
the
methods
used
for
scoring
the
risk
pre
and
post-mitigation
and
the
associated
acceptance
criteria
as
well
as
the
method
for
transferring
security
risks
into
the
safety
risk
assessment
process
should
also
be
provided
as
part
of
the
premarket
submission
these
factors
of
exploitability
are
from
the
common
vulnerability
scoring
system
cvss
version
as
identified
in
the
postmarket
cybersecurity
guidance
available
at
https
www
fda
gov
regulatory
information
search-fda-guidance-documents
postmarket-management-cybersecurity-medical-devices
additional
information
on
cvss
is
available
at
https
www
first
org
cvss
available
at
https
www
cisa
gov
known-exploited-vulnerabilities-catalog
interoperability
considerations
interoperability
is
an
important
consideration
when
assessing
the
cybersecurity
of
the
end-to-end
medical
device
system
as
identified
in
the
fda
guidance
design
considerations
and
premarket
submission
recommendations
for
interoperable
medical
devices
hereafter
referred
to
as
the
interoperability
guidance
interoperable
medical
devices
have
the
ability
to
exchange
and
use
information
through
an
electronic
interface
with
another
medical
or
nonmedical
product
system
or
device
as
part
of
a
medical
device
system
a
device
may
have
cybersecurity
considerations
from
interoperable
functionality
including
but
not
limited
to
interfaces
with
other
medical
devices
and
accessories
other
functions
as
identified
in
the
fda's
guidance
multiple
function
device
products
policy
and
considerations
interoperability
with
healthcare
infrastructure
e
g
network
electronic
medical
records
medical
imaging
systems
and
general
purpose
computing
platforms
while
cybersecurity
controls
may
increase
the
complexity
of
interfaces
to
allow
for
interoperability
when
properly
implemented
the
cybersecurity
controls
can
help
assure
that
these
capabilities
remain
safe
and
effective
cybersecurity
controls
should
be
used
as
a
means
to
allow
for
the
safe
and
effective
exchange
and
use
of
information
additionally
cybersecurity
controls
should
not
be
intended
to
prohibit
a
user
from
accessing
their
device
data
when
common
technology
and
communication
protocols
are
used
to
enable
interoperability
e
g
bluetooth
bluetooth
low
energy
network
protocols
device
manufacturers
should
assess
whether
added
security
controls
beneath
such
communication
are
needed
to
ensure
the
safety
and
effectiveness
of
the
device
e
g
added
security
controls
beneath
bluetooth
low
energy
to
protect
against
risks
if
vulnerabilities
in
the
bluetooth
low
energy
protocol
or
supporting
technology
are
discovered
in
addition
to
the
recommendations
in
the
interoperability
guidance
manufacturers
should
consider
the
appropriate
cybersecurity
risks
and
controls
associated
with
the
interoperability
capabilities
and
document
these
considerations
as
recommended
throughout
this
guidance
third-party
software
components
as
discussed
in
the
fda
guidances
off-the-shelf
ots
software
use
in
medical
devices
and
cybersecurity
for
networked
medical
devices
containing
off-the-shelf
ots
software
medical
devices
commonly
include
third-party
software
components
including
off-the-shelf
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
design-considerations
and-pre-market-submission-recommendations-interoperable-medical-devices
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
multiple-function
device-products-policy-and-considerations
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
shelf-software-use
medical-devices
the
use
of
component
in
this
guidance
is
consistent
with
the
definition
in
cfr
and
open
source
software
when
these
components
are
incorporated
security
risks
of
the
software
components
should
become
factors
of
the
overall
medical
device
system
risk
management
processes
and
documentation
as
part
of
demonstrating
compliance
with
design
controls
under
cfr
g
and
to
support
supply
chain
risk
management
processes
all
software
including
those
developed
by
the
device
manufacturer
proprietary
software
or
obtained
from
third
parties
should
be
assessed
for
cybersecurity
risk
device
manufacturers
should
document
all
software
components
of
a
device
and
address
or
otherwise
mitigate
risks
associated
with
these
software
components
in
addition
under
cfr
a
manufacturer
must
put
in
place
processes
and
controls
to
ensure
that
its
suppliers
conform
to
the
manufacturer's
requirements
such
information
is
documented
in
the
design
history
file
required
by
cfr
j
and
device
master
record
required
by
cfr
this
documentation
demonstrates
the
device's
overall
compliance
with
the
qs
regulation
as
well
as
that
the
third-party
components
meet
specifications
established
for
the
device
security
risk
assessments
that
include
analyses
and
considerations
of
cybersecurity
risks
that
may
exist
in
or
be
introduced
by
third-party
software
and
the
software
supply
chain
may
help
demonstrate
that
manufacturers
have
adequately
ensured
such
compliance
and
documented
such
history
software
is
updated
over
time
to
provide
additional
features
address
security
concerns
and
otherwise
be
maintained
these
changes
may
introduce
new
considerations
or
risks
that
must
be
accounted
for
as
part
of
risk
management
as
a
result
device
manufacturers
should
establish
and
maintain
custodial
control
of
device
source
code
the
original
copy
of
the
software
throughout
the
lifecycle
of
a
device
as
part
of
configuration
management
this
may
be
accomplished
through
different
methods
such
as
source
code
escrow
or
source
code
backups
among
others
manufacturers
may
not
have
control
of
source
code
due
to
licensing
restrictions
terms
of
supplier
agreements
or
other
challenges
while
source
code
is
not
required
to
be
provided
in
premarket
submissions
manufacturers
should
include
plans
for
how
third-party
software
components
could
be
updated
or
replaced
if
support
ends
or
other
software
issues
arise
in
premarket
submissions
the
device
manufacturer
should
also
provide
users
with
whatever
information
they
may
need
in
the
device
labeling
to
allow
them
to
manage
risks
associated
with
the
software
components
including
known
vulnerabilities
configuration
specifications
and
other
relevant
security
and
risk
management
considerations
one
tool
to
help
manage
supply
chain
risk
as
well
as
clearly
identify
and
track
the
software
incorporated
into
a
device
is
an
sbom
as
described
below
while
some
suppliers
may
not
grant
access
to
source
code
manufacturers
may
consider
adding
to
their
purchasing
controls
acquisition
of
the
source
code
should
the
purchased
software
reach
end
of
support
or
end
of
life
from
the
supplier
earlier
than
the
intended
end
of
support
or
end
of
life
of
the
medical
device
source
code
escrow
involves
depositing
a
copy
of
a
relevant
piece
of
software's
source
code
and
related
technical
components
and
documentation
with
an
independent
third
party
escrow
agent
source
code
backup
involves
storing
and
updating
as
needed
a
separate
copy
of
the
source
code
a
software
bill
of
materials
sbom
an
sbom
can
aid
in
the
management
of
cybersecurity
risks
that
exist
throughout
the
software
stack
a
robust
sbom
includes
both
the
device
manufacturer-developed
components
and
third
party
components
including
purchased
licensed
software
and
open-source
software
and
the
upstream
software
dependencies
that
are
required
depended
upon
by
proprietary
purchased
licensed
and
open-source
software
an
sbom
helps
facilitate
risk
management
processes
by
providing
a
mechanism
to
identify
devices
and
the
systems
in
which
they
operate
that
might
be
affected
by
vulnerabilities
in
the
software
components
both
during
development
when
software
is
being
chosen
as
a
component
and
after
it
has
been
placed
into
the
market
throughout
all
other
phases
of
a
product's
life
because
vulnerability
management
is
a
critical
part
of
a
device's
security
risk
management
processes
an
sbom
or
an
equivalent
capability
should
be
maintained
as
part
of
the
device's
configuration
management
be
regularly
updated
to
reflect
any
changes
to
the
software
in
marketed
devices
and
should
support
documentation
such
as
the
types
detailed
in
cfr
j
design
history
file
and
device
master
record
to
assist
fda's
assessment
of
the
device
risks
and
associated
impacts
on
safety
and
effectiveness
related
to
cybersecurity
fda
recommends
that
premarket
submissions
include
sbom
documentation
as
outlined
below
for
cyber
devices
an
sbom
is
required
see
section
524b
b
of
the
fd
c
act
sboms
can
also
be
an
important
tool
for
transparency
with
users
of
potential
risks
as
part
of
labeling
as
addressed
later
in
section
vi
b
documentation
supporting
software
bill
of
materials
fda's
guidance
documents
off-the-shelf
ots
software
use
in
medical
devices
and
cybersecurity
for
networked
medical
devices
containing
off-the-shelf
ots
software
describe
information
that
should
be
provided
in
premarket
submissions
for
software
components
for
which
a
manufacturer
cannot
claim
complete
control
of
the
software
lifecycle
in
addition
to
the
information
recommended
in
those
guidances
manufacturers
should
provide
machine
readable
sboms
consistent
with
the
minimum
elements
also
referred
to
as
baseline
attributes
identified
in
the
october
national
telecommunications
and
information
administration
ntia
multistakeholder
process
on
software
component
transparency
document
framing
software
component
transparency
establishing
a
common
software
bill
of
materials
sbom
in
addition
to
the
minimum
elements
identified
by
ntia
for
each
software
component
contained
within
the
sbom
manufacturers
should
include
in
the
premarket
submission
for
additional
information
see
the
department
of
commerce
national
telecommunications
and
information
administration's
multi-stakeholder
process
for
software
transparency
available
at
https
www
ntia
doc
gov
softwaretransparency
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
shelf-software-use
medical-devices
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
cybersecurity
networked-medical-devices-containing-shelf-ots-software
available
at
https
ntia
gov
sites
default
files
publications
ntia
sbom
framing
2nd
edition
pdf
cisa
will
be
providing
future
updates
to
this
document
the
software
level
of
support
provided
through
monitoring
and
maintenance
from
the
software
component
manufacturer
e
g
the
software
is
actively
maintained
no
longer
maintained
abandoned
and
the
software
component's
end-of-support
date
when
provided
manufacturers
may
choose
to
provide
these
additional
elements
as
part
of
the
sbom
or
they
may
provide
it
separately
such
as
in
an
addendum
industry-accepted
formats
of
sboms
are
encouraged
if
a
manufacturer
is
unable
to
provide
the
sbom
information
to
fda
the
manufacturer
should
provide
a
justification
for
why
the
information
cannot
be
included
in
the
premarket
submission
as
part
of
the
premarket
submission
manufacturers
should
also
identify
all
known
vulnerabilities
associated
with
the
device
and
the
software
components
including
those
identified
in
cisa's
known
exploited
vulnerabilities
catalog
for
each
known
vulnerability
manufacturers
should
describe
how
the
vulnerabilities
were
discovered
to
demonstrate
whether
the
assessment
methods
were
sufficiently
robust
for
components
with
known
vulnerabilities
device
manufacturers
should
provide
in
premarket
submissions
a
safety
and
security
risk
assessment
of
each
known
vulnerability
including
device
and
system
impacts
and
details
of
applicable
safety
and
security
risk
controls
to
address
the
vulnerability
if
risk
controls
include
compensating
controls
those
should
be
described
in
an
appropriate
level
of
detail
for
additional
information
and
discussion
regarding
proprietary
and
third-party
components
see
section
v
b
security
architecture
views
below
security
assessment
of
unresolved
anomalies
fda's
premarket
software
guidance
recommends
that
device
manufacturers
provide
a
list
of
software
anomalies
that
exist
in
a
product
at
the
time
of
submission
for
each
of
these
anomalies
fda
recommends
that
device
manufacturers
conduct
an
evaluation
of
the
anomaly's
impact
on
the
device's
safety
and
effectiveness
and
consult
the
premarket
software
guidance
to
assess
the
associated
documentation
recommended
for
inclusion
in
such
device's
premarket
submission
some
anomalies
discovered
during
development
or
testing
may
have
security
implications
and
may
also
be
considered
vulnerabilities
as
a
part
of
ensuring
a
complete
security
risk
assessment
under
cfr
part
g
the
assessment
for
impacts
to
safety
and
effectiveness
may
include
an
assessment
for
the
potential
security
impacts
of
anomalies
the
assessment
should
also
include
consideration
of
any
present
common
weakness
enumeration
cwe
categories
available
at
https
www
cisa
gov
known-exploited-vulnerabilities-catalog
examples
of
sw91
defect
classification
mapped
to
cwe
can
be
found
in
annex
d
of
aami
sw91
classification
of
defects
in
health
software
additional
information
on
cwe
categories
can
be
found
at
https
cwe
mitre
org
for
example
a
clinical
user
may
inadvertently
reveal
the
presence
of
a
previously
unknown
software
anomaly
during
normal
use
where
the
impact
of
the
anomaly
might
occur
sporadically
and
be
assessed
to
be
acceptable
from
a
software
risk
perspective
conversely
a
threat
might
seek
out
these
types
of
anomalies
and
identify
means
to
exploit
them
in
order
to
manifest
the
anomaly's
impact
continuously
which
could
significantly
impact
the
acceptability
of
the
risk
when
compared
to
an
anomaly
assessment
that
didn't
include
security
considerations
the
criteria
and
rationales
for
addressing
the
resulting
anomalies
with
security
impacts
should
be
provided
as
part
of
documentation
in
the
premarket
submission
tplc
security
risk
management
cybersecurity
risks
may
continue
to
be
identified
throughout
the
device's
tplc
manufacturers
should
ensure
they
have
appropriate
resources
to
identify
assess
and
mitigate
cybersecurity
vulnerabilities
as
they
are
identified
throughout
the
supported
device
lifecycle
as
part
of
using
an
spdf
manufacturers
should
update
their
security
risk
management
documentation
as
new
information
becomes
available
such
as
when
new
threats
vulnerabilities
assets
or
adverse
impacts
are
discovered
during
development
and
after
the
device
is
released
when
maintained
throughout
the
device
lifecycle
this
documentation
e
g
threat
modeling
can
be
used
to
quickly
identify
vulnerability
impacts
once
a
device
is
released
and
when
appropriate
to
support
timely
corrective
and
preventive
action
activities
described
in
cfr
over
the
service
life
of
a
device
fda
recommends
that
the
risk
management
documentation
account
for
any
differences
in
the
risk
management
for
fielded
devices
e
g
marketed
devices
or
devices
no
longer
marketed
but
still
in
use
for
example
if
an
update
is
not
applied
automatically
for
all
fielded
devices
then
there
will
likely
be
different
risk
profiles
for
differing
software
configurations
of
the
device
fda
recommends
that
vulnerabilities
be
assessed
for
any
differing
impacts
for
all
fielded
versions
to
ensure
patient
risks
are
being
accurately
assessed
additional
information
as
to
whether
a
new
premarket
submission
e
g
pma
pma
supplement
or
k
or
cfr
part
reporting
is
needed
based
on
postmarket
vulnerabilities
and
general
postmarket
cybersecurity
risk
management
is
discussed
in
the
postmarket
cybersecurity
guidance
to
demonstrate
the
effectiveness
of
a
manufacturer's
processes
fda
recommends
that
a
manufacturer
track
and
record
the
measures
and
metrics
below
and
provide
them
in
premarket
submissions
and
pma
annual
reports
cfr
when
available
selecting
appropriate
measures
and
metrics
for
the
processes
that
define
an
spdf
is
important
to
ensure
that
device
design
appropriately
addresses
cybersecurity
in
compliance
with
the
qs
regulation
at
a
minimum
fda
recommends
tracking
the
following
measures
and
metrics
or
those
that
provide
equivalent
information
the
measures
and
metrics
provided
are
examples
alternative
or
additional
measures
and
metrics
may
also
be
considered
and
reported
if
a
manufacturer
has
not
marketed
prior
versions
or
the
premarket
submission
does
not
pertain
to
a
marketed
product
e
g
pma
supplement
fda
acknowledges
that
these
measures
and
metrics
might
not
be
available
but
recommends
that
manufacturers
include
these
as
part
of
their
risk
management
plan
and
spdf
processes
percentage
of
identified
vulnerabilities
that
are
updated
or
patched
defect
density
duration
from
vulnerability
identification
to
when
it
is
updated
or
patched
and
duration
from
when
an
update
or
patch
is
available
to
complete
implementation
in
devices
deployed
in
the
field
to
the
extent
known
averages
of
the
above
measures
should
be
provided
if
multiple
vulnerabilities
are
identified
and
addressed
these
averages
may
be
provided
over
multiple
time
frames
based
on
volume
or
in
response
to
process
or
procedure
changes
to
increase
efficiencies
of
these
measures
over
time
b
security
architecture
manufacturers
are
responsible
for
identifying
cybersecurity
risks
in
their
devices
and
the
systems
in
which
they
expect
those
devices
to
operate
and
implementing
the
appropriate
controls
to
mitigate
those
risks
these
risks
may
include
those
introduced
by
device
reliance
on
hospital
networks
cloud
infrastructure
or
other
functions
as
defined
in
fda's
guidance
multiple
function
device
products
policy
and
considerations
for
example
a
security
architecture
like
a
system
architecture
defines
the
system
and
all
end-to-end
connections
into
and
or
out
of
the
system
a
security
architecture
definition
process55
includes
both
high-level
definitions
of
the
devices
and
or
systems
that
interact
and
detailed
information
on
the
implementations
for
how
those
interactions
occur
and
are
secured
it
contains
information
that
demonstrates
that
the
risks
considered
during
the
risk
management
process
are
adequately
controlled
which
in
turn
supports
the
demonstration
of
the
safety
and
effectiveness
of
the
medical
device
system
under
cfr
b
a
manufacturer
must
establish
and
maintain
plans
that
describe
or
reference
the
design
and
development
activities
and
define
responsibility
for
implementation
such
plans
must
be
reviewed
updated
and
approved
as
design
and
development
evolves
cfr
b
under
cfr
c
a
manufacturer
must
establish
and
maintain
procedures
to
ensure
that
the
design
requirements
relating
to
a
device
are
appropriate
and
address
the
intended
use
of
the
device
including
the
needs
of
the
user
and
patient
under
cfr
d
a
manufacturer
must
establish
and
maintain
procedures
for
defining
and
documenting
design
output
in
terms
that
allow
an
adequate
evaluation
of
conformance
to
design
input
requirements
cfr
d
also
states
that
design
output
procedures
shall
contain
or
make
reference
to
acceptance
criteria
and
shall
ensure
that
those
design
outputs
that
are
essential
for
the
proper
functioning
of
the
device
are
identified
fda
recommends
that
these
plans
and
procedures
include
design
processes
design
requirements
and
acceptance
criteria
for
the
security
architecture
of
the
device
such
that
they
holistically
address
the
cybersecurity
considerations
for
the
device
and
the
system
in
which
the
device
operates
fda
recommends
that
all
medical
devices
provide
and
enforce
the
security
objectives
in
section
iv
above
but
recognizes
that
implementations
to
address
the
security
objectives
may
vary
nist
vol
rev
engineering
trustworthy
secure
systems
states
that
security
architecture
definition
process
generates
a
set
of
representative
security
views
of
the
system
architecture
to
inform
the
selection
of
an
appropriate
security
architecture
the
process
also
ascertains
vulnerability
and
susceptibility
to
disruptions
hazards
and
threats
nist
vol
rev
is
available
at
https
csrc
nist
gov
pubs
sp
v1
r1
final
fda
recommends
that
premarket
submissions
include
documentation
on
the
security
architecture
the
objective
in
providing
security
architecture
information
in
premarket
submissions
is
to
provide
to
the
fda
the
security
context
and
trust-boundaries
of
the
medical
device
system
in
terms
of
the
interfaces
interconnections
and
interactions
that
the
medical
device
system
has
with
external
entities
the
details
of
these
elements
enable
the
identification
of
the
parts
of
the
medical
device
system
in
or
through
which
incidents
might
occur
these
details
help
to
provide
a
sufficient
understanding
of
the
system
such
that
fda
can
evaluate
adequacy
of
the
architecture
itself
as
it
relates
to
safety
and
effectiveness
manufacturers
should
analyze
the
entire
system
to
understand
the
full
environment
and
context
in
which
the
device
is
expected
to
operate
the
security
architecture
should
include
a
consideration
of
system-level
risks
including
but
not
limited
to
risks
related
to
the
supply
chain
e
g
to
ensure
the
device
remains
free
of
malware
or
vulnerabilities
inherited
from
upstream
dependencies
such
as
third-party
software
among
others
design
production
and
deployment
i
e
into
a
connected
networked
environment
fda
recommends
that
this
architecture
information
take
the
form
of
views
and
that
these
views
be
provided
during
premarket
submissions
to
demonstrate
safety
and
effectiveness
if
the
documentation
identified
in
this
section
already
exists
in
other
risk
management
documentation
fda
does
not
expect
manufacturers
to
separate
out
this
information
into
new
document
s
such
documentation
can
be
provided
and
the
submission
can
reference
the
relevant
sections
below
fda
outlines
the
recommended
security
controls
and
ways
to
document
the
resultant
security
architecture
in
premarket
submissions
through
specific
security
architecture
views
implementation
of
security
controls
fda
considers
the
way
in
which
a
device
addresses
cybersecurity
risks
and
the
way
in
which
the
device
responds
when
exposed
to
cybersecurity
threats
as
functions
of
the
device
design
effective
cybersecurity
relies
upon
security
being
built
in
to
a
device
and
not
bolted
on
after
the
device
is
designed
fda
recommends
that
device
manufacturers
design
processes
include
design
inputs
for
cybersecurity
controls
under
cfr
c
a
manufacturer
must
establish
and
maintain
procedures
to
ensure
that
the
design
requirements
relating
to
a
device
are
appropriate
and
address
the
intended
use
of
the
device
including
the
needs
of
the
user
and
patient
under
cfr
d
a
manufacturer
must
establish
and
maintain
procedures
for
defining
and
documenting
design
output
in
terms
that
allow
an
adequate
evaluation
of
conformance
to
design
input
requirements
these
output
procedures
shall
contain
or
make
reference
to
acceptance
criteria
and
shall
ensure
that
those
design
outputs
that
are
essential
for
the
proper
functioning
of
the
device
are
identified
views
are
discussed
in
more
detail
in
the
following
subsections
and
appendix
there
are
useful
frameworks
to
use
in
the
generation
of
these
design
inputs
including
the
owasp
security
by
design
principles
aami
isa-62443-4-1
as
well
as
medical
device
specific
frameworks
including
the
hippocratic
oath
for
connected
medical
devices
building
code
for
medical
device
software
security
and
iec
for
a
specific
implementation
of
the
owasp
security
by
design
principles
see
the
medical
device
and
health
it
joint
security
plan
jsp
available
at
https
healthsectorcouncil
org
the-joint-security-plan
fda
recommends
that
these
procedures
include
design
requirements
and
acceptance
criteria
for
the
security
features
built
into
the
device
such
that
they
holistically
address
the
cybersecurity
considerations
for
the
device
and
the
system
in
which
the
device
operates
security
controls
allow
manufacturers
to
achieve
the
security
objectives
outlined
in
section
iv
and
are
an
integral
part
of
an
spdf
fda
recommends
that
an
adequate
set
of
security
controls
should
include
but
not
necessarily
be
limited
to
controls
from
the
following
categories
authentication
authorization
cryptography
code
data
and
execution
integrity
confidentiality
event
detection
and
logging
resiliency
and
recovery
and
updatability
and
patchability
for
each
of
the
security
control
categories
above
specific
control
recommendations
and
implementation
guidance
to
avoid
common
pitfalls
are
detailed
in
appendix
implementation
of
security
controls
should
be
applied
across
the
system
architecture
using
risk
based
determinations
associated
with
the
subject
connections
and
devices
without
adequate
security
controls
across
the
medical
device
system
which
include
management
technical
and
operational
controls
there
is
no
reasonable
assurance
of
safety
and
effectiveness
additionally
deficiencies
in
the
design
of
selected
security
controls
or
the
implementation
of
those
controls
can
have
dramatic
impacts
on
a
device's
ability
to
demonstrate
or
maintain
its
safety
and
effectiveness
fda
recommends
the
requirements
and
acceptance
criteria
for
each
of
the
above
categories
be
provided
in
premarket
submissions
to
demonstrate
safety
and
effectiveness
manufacturers
should
submit
documentation
in
their
premarket
submissions
demonstrating
that
the
security
controls
for
the
categories
above
and
further
detailed
in
the
recommendations
in
appendix
have
been
implemented
and
been
tested
in
order
to
validate
that
they
were
effectively
implemented
for
more
information
on
cybersecurity
testing
see
section
v
c
below
manufacturers
may
include
the
demonstration
of
security
controls
that
are
comparable
or
in
addition
to
those
described
in
appendix
in
their
premarket
submissions
if
using
alternate
controls
that
are
not
described
in
this
document
manufacturers
should
provide
documentation
and
tracing
of
specific
design
features
and
security
controls
to
the
associated
risks
in
order
to
demonstrate
that
they
provide
appropriate
levels
of
safety
and
effectiveness
as
cybersecurity
design
controls
are
established
early
in
the
development
phase
fda
recommends
that
device
manufacturers
utilize
the
fda
q-submission
process
to
discuss
design
considerations
for
cybersecurity
risk
management
throughout
the
device
lifecycle
with
the
agency
additional
information
on
premarket
documentation
recommendations
for
design
controls
are
discussed
in
the
security
architecture
views
section
below
security
architecture
views
in
addition
to
the
design
control
requirements
cfr
requires
that
manufacturers
establish
and
maintain
procedures
for
implementing
corrective
and
preventive
action
which
must
include
among
other
things
requirements
for
analyzing
quality
data
to
identify
existing
and
potential
causes
of
quality
problems
fda
recommends
that
manufacturers
develop
and
maintain
security
architecture
view
documentation
as
a
part
of
the
process
for
the
design
development
and
maintenance
of
the
medical
device
system
if
corrective
and
preventive
actions
are
identified
these
views
can
be
used
to
help
identify
impacted
functionality
and
solutions
that
address
the
risks
fda
recommends
that
premarket
submissions
include
the
architecture
views
described
in
this
section
these
architecture
views
can
contribute
to
the
demonstration
of
safety
and
effectiveness
in
premarket
submissions
by
illustrating
how
the
controls
to
address
cybersecurity
risks
have
been
applied
to
the
medical
device
system
the
security
architecture
may
be
expressed
at
different
levels
of
abstraction
and
with
different
scopes
or
views
the
number
and
extent
of
the
architecture
views
provided
in
the
submission
depends
on
the
attack
surface
s
identified
through
threat
modeling
and
risk
assessments
for
the
medical
device
system
these
views
can
therefore
be
an
effective
way
to
provide
threat
modeling
information
to
fda
and
will
naturally
scale
the
documentation
provided
with
the
cybersecurity
risk
of
the
device
fda
recommends
providing
at
minimum
the
following
types
of
views
in
premarket
submissions
global
system
view
multi-patient
harm
view
updateability
patchability
view
and
security
use
case
view
s
documenting
these
views
in
premarket
submissions
should
include
both
diagrams
and
explanatory
text
these
diagrams
and
explanatory
text
should
contain
sufficient
details
to
permit
an
understanding
of
how
the
assets
within
the
medical
device
system
function
holistically
within
the
associated
implementation
details
for
the
security
architecture
views
manufacturers
should
for
more
information
see
fda's
guidance
request
for
feedback
on
medical
device
submissions
the
q
submission
program
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance
documents
requests-feedback-and-meetings-medical-device-submissions-q-submission-program
see
cfr
architecture
view
is
defined
by
nist
vol
rev
as
a
work
product
expressing
the
architecture
of
a
system
from
the
perspective
of
specific
system
concerns
nist
vol
rev
is
available
at
https
csrc
nist
gov
pubs
sp
v1
r1
final
follow
the
recommendations
outlined
in
appendix
when
determining
the
level
of
detail
to
include
in
premarket
submissions
these
security
architecture
views
should
identify
security-relevant
medical
device
system
elements
and
their
interfaces
define
security
context
domains
boundaries
critical
user
roles
and
external
interfaces
of
the
medical
device
system
align
the
architecture
with
a
the
medical
device
system
security
objectives
and
requirements
b
security
design
characteristics
in
order
to
address
the
identified
threats
and
establish
traceability
of
architecture
elements
to
user
and
medical
device
system
security
requirements
such
traceability
should
exist
throughout
the
cybersecurity
risk
management
documentation
if
a
particular
view
sufficiently
captures
the
risks
of
another
view
identified
above
we
do
not
expect
manufacturers
to
duplicate
documentation
similarly
if
threat
modeling
documentation
sufficiently
captures
the
view
we
do
not
expect
manufacturers
to
duplicate
documentation
additionally
if
one
of
the
views
listed
above
is
not
appropriate
manufacturers
should
instead
provide
an
explanation
for
why
the
view
is
not
included
in
the
premarket
submission
the
extent
of
these
security
views
in
a
premarket
submission
is
expected
to
scale
based
on
the
architecture
and
potential
cybersecurity
risk
posed
to
the
device
for
example
medical
device
systems
with
network
and
or
cloud
access
would
be
expected
to
have
more
security
use
case
views
than
a
medical
device
system
that
has
only
a
usb
interface
a
global
system
view
a
global
system
view
should
describe
the
overall
medical
device
system
including
the
device
itself
and
all
internal
and
external
connections
for
interconnected
and
networked
devices
this
view
should
identify
all
interconnected
elements
including
any
software
update
infrastructure
s
healthcare
facility
network
impacts
intermediary
connections
or
devices
cloud
connections
patient
home
network
impact
depending
on
the
complexity
of
the
medical
device
system
it
may
not
be
feasible
to
include
all
data
flow
specifics
in
a
singular
global
system
view
additional
views
can
be
provided
that
detail
the
communication
specifics
as
recommended
in
appendix
and
do
not
need
to
be
duplicated
if
captured
in
one
of
the
other
types
of
views
detailed
below
b
multi-patient
harm
view
when
devices
are
capable
of
connecting
wired
or
wirelessly
to
another
medical
or
non-medical
product
to
a
network
or
to
the
internet
there
is
the
possibility
that
multiple
devices
can
be
compromised
simultaneously
because
of
that
connectivity
if
a
device
is
compromised
or
if
a
non-device
function
i
e
any
function
that
does
not
fall
within
section
h
of
the
fd
c
act
that
could
impact
the
device
function
is
compromised
the
device
may
introduce
a
safety
risk
to
patients
through
security
risk
this
may
change
the
device's
functionality
for
example
a
non
device
function
could
be
hacked
to
perform
a
device
function
and
ultimately
harm
patients
depending
on
the
device
risk
and
use
environment
a
multiple-device
compromise
may
have
severe
impacts
for
multiple
patients
either
through
impact
to
the
device
itself
and
or
to
healthcare
facility
operations
e
g
multiparameter
bedside
monitors
all
restarting
at
once
leaving
all
monitors
connected
to
the
same
network
no
longer
monitoring
patient
vitals
and
staffing
levels
not
able
to
monitor
all
patient
vitals
fda
recommends
that
manufacturers
address
how
their
device
s
and
the
system
s
in
which
they
operate
defend
against
and
or
respond
to
attacks
with
the
potential
to
harm
multiple
patients
in
a
multi-patient
harm
view
this
view
should
include
the
information
recommended
in
appendix
these
risks
once
identified
may
also
need
to
be
assessed
differently
in
the
accompanying
cybersecurity
risk
assessment
due
to
the
different
nature
of
the
risk
c
updatability
and
patchability
view
with
the
need
to
provide
timely
reliable
updates
to
devices
in
order
to
address
emerging
cybersecurity
risks
throughout
the
tplc
of
the
device
fda
recommends
manufacturers
provide
an
updateability
and
patchability
view
this
view
should
describe
the
end-to-end
process
that
permits
software
updates
and
patches
to
be
provided
i
e
deployed
to
the
device
and
should
include
detailed
information
as
recommended
in
appendix
for
example
if
a
device
manufacturer
intends
to
push
software
from
a
software
update
server
to
an
in-clinic
cardiac
implant
programmer
end-to-end
means
the
path
from
the
update
server
to
the
in-clinic
programmer
that
programs
the
implanted
device
the
software
update
path
will
likely
include
traversing
technology
that
the
device
manufacturer
does
not
control
and
therefore
the
device
design
should
provide
for
the
protection
of
the
end-to-end
path
and
take
into
account
any
additional
cybersecurity
risk
created
or
posed
by
those
non-manufacturer-controlled
technologies
d
security
use
case
views
in
addition
to
the
views
identified
above
security
use
case
views
should
also
be
provided
security
use
cases
should
be
included
for
all
medical
device
system
functionality
through
which
a
security
compromise
could
impact
the
safety
or
effectiveness
of
the
device
these
security
use
cases
should
cover
various
operational
states
of
elements
in
the
medical
device
system
e
g
power
on
standby
transition
states
and
assess
clinical
functionality
states
of
the
medical
device
system
e
g
programming
alarming
delivering
therapy
send
receive
data
reporting
diagnostic
results
the
number
of
security
use
cases
that
should
be
assessed
will
scale
with
the
cybersecurity
complexity
and
risk
of
the
device
each
view
should
include
detailed
information
as
recommended
in
appendix
for
use
cases
identified
that
share
the
same
security
assessment
the
associated
diagrams
and
explanatory
text
can
describe
the
multiple
use
cases
covered
by
the
view
in
lieu
of
providing
duplicative
information
in
multiple
places
for
example
programming
commands
and
sending
receiving
device
data
may
share
the
same
communication
protocol
and
therefore
may
not
exhibit
differences
between
the
security
views
for
both
scenarios
despite
having
different
clinical
risk
assessments
c
cybersecurity
testing
as
with
other
areas
of
product
development
testing
is
used
to
demonstrate
the
effectiveness
of
design
controls
while
software
development
and
cybersecurity
are
closely
related
disciplines
cybersecurity
controls
require
testing
beyond
standard
software
verification
and
validation
activities
to
demonstrate
the
effectiveness
of
the
controls
in
a
proper
security
context
to
therefore
demonstrate
that
the
device
has
a
reasonable
assurance
of
safety
and
effectiveness
under
cfr
f
a
manufacturer
must
establish
and
maintain
procedures
for
verifying
the
device
design
such
verification
shall
confirm
that
the
design
output
meets
the
design
input
requirements
under
cfr
g
a
manufacturer
must
establish
and
maintain
procedures
for
validating
its
device
design
such
design
validation
shall
include
software
validation
and
risk
analysis
where
appropriate
fda
recommends
verification
and
validation
include
sufficient
testing
performed
by
the
manufacturer
on
the
cybersecurity
of
the
medical
device
system
through
which
the
manufacturer
verifies
and
validates
their
inputs
and
outputs
as
appropriate
security
testing
documentation
and
any
associated
reports
or
assessments
should
be
submitted
in
the
premarket
submission
fda
recommends
that
the
following
types
of
testing
among
others
be
considered
for
inclusion
in
the
submission
security
requirements
manufacturers
should
provide
evidence
that
each
design
input
requirement
was
implemented
successfully
manufacturers
should
provide
evidence
of
their
boundary
analysis
and
rationale
for
their
boundary
assumptions
threat
mitigation
manufacturers
should
provide
details
and
evidence
of
testing
that
demonstrates
effective
risk
control
measures
according
to
the
threat
models
provided
in
the
global
system
multi-patient
harm
updatability
and
patchability
and
security
use
case
views
manufacturers
should
ensure
the
adequacy
of
each
cybersecurity
risk
control
e
g
security
effectiveness
in
enforcing
the
specified
security
policy
performance
for
maximum
traffic
conditions
stability
and
reliability
as
appropriate
vulnerability
testing
such
as
section
of
ansi
isa
and
manufacturers
should
provide
details
and
evidence61
of
the
following
testing
and
analyses
abuse
or
misuse
cases
malformed
and
unexpected
inputs
robustness
fuzz
testing
for
any
testing
tools
or
software
used
the
details
provided
may
include
but
may
not
be
limited
to
the
name
of
the
tool
version
information
as
applicable
and
any
settings
or
configuration
options
for
the
tools
used
attack
surface
analysis
vulnerability
chaining
closed
box
testing
of
known
vulnerability
scanning
software
composition
analysis
of
binary
executable
files
and
static
and
dynamic
code
analysis
including
testing
for
credentials
that
are
hardcoded
default
easily
guessed
and
easily
compromised
penetration
testing
the
testing
should
identify
and
characterize
security-related
issues
via
tests
that
focus
on
discovering
and
exploiting
security
vulnerabilities
in
the
product
penetration
test
reports
should
be
provided
and
include
the
following
elements
independence
and
technical
expertise
of
testers
scope
of
testing
duration
of
testing
testing
methods
employed
and
test
results
findings
and
observations
device
manufacturers
should
indicate
in
the
test
reports
by
whom
the
testing
was
performed
e
g
independent
internal
testers
external
testers
and
what
level
of
independence
those
responsible
for
testing
devices
have
from
the
developers
responsible
for
designing
devices
in
some
cases
it
may
be
necessary
to
use
third
parties
to
ensure
an
appropriate
level
of
independence
between
the
two
groups
such
that
vulnerabilities
or
other
issues
revealed
during
testing
are
appropriately
addressed
for
any
third-party
test
reports
manufacturers
should
provide
the
original
third-party
report
for
all
testing
manufacturers
should
provide
their
assessment
of
any
findings
including
rationales
for
not
implementing
or
deferring
any
findings
to
future
releases
as
discussed
in
sections
v
a
and
v
a
above
vulnerabilities
and
anomalies
identified
during
testing
should
be
assessed
for
their
security
impacts
as
part
of
the
security
risk
management
process
in
non-security
software
testing
a
benefit
analysis
of
a
discovered
defect
may
lead
to
the
conclusion
that
an
anomaly
does
not
need
to
be
fixed
as
its
impact
on
medical
device
system
functionality
may
be
small
or
unlikely
conversely
in
security
testing
the
exploitability
of
an
anomaly
may
necessitate
that
it
is
mitigated
because
of
the
greater
and
different
type
of
harm
that
it
could
facilitate
for
issues
that
will
be
addressed
in
future
releases
i
e
remediation
deferred
for
a
future
software
release
because
current
risk
was
assessed
to
be
acceptable
the
premarket
submission
should
contain
plans
for
those
releases
such
plans
should
include
the
vulnerabilities
that
future
software
releases
will
address
anticipated
timelines
for
release
whether
devices
released
in
the
interim
will
receive
those
updates
and
how
long
it
will
take
the
update
to
reach
the
devices
there
are
numerous
authoritative
resources
for
outlining
security
testing
that
may
partially
fulfill
the
testing
outlined
above
fda
recommends
that
cybersecurity
testing
should
occur
throughout
the
spdf
security
testing
early
in
development
can
ensure
that
security
issues
are
addressed
prior
to
impacting
release
timelines
and
can
prevent
the
need
to
redesign
or
re-engineer
the
device
after
release
cybersecurity
testing
should
be
performed
at
regular
intervals
commensurate
with
the
risk
e
g
annually
to
ensure
that
potential
vulnerabilities
are
identified
and
able
to
be
addressed
prior
to
their
ability
to
be
exploited
vi
cybersecurity
transparency
in
order
for
users
to
manage
security
risks
in
medical
device
systems
either
by
an
end
user
or
within
a
larger
risk
management
framework
like
the
nist
csf
transparency
is
critical
to
ensure
safe
and
effective
use
and
integration
of
devices
and
systems
this
transparency
can
be
conveyed
through
both
device
labeling
and
the
establishment
of
manufacturer
vulnerability
management
plans
however
different
types
of
users
e
g
manufacturers
servicers
patients
will
have
different
abilities
to
take
on
a
mitigation
role
and
the
need
for
actions
to
ensure
continued
cybersecurity
should
be
appropriate
for
the
type
of
user
a
labeling
recommendations
for
devices
with
cybersecurity
risks
fda
regulates
device
labeling
in
several
ways
for
example
section
f
of
the
fd
c
act
requires
that
labeling
include
adequate
directions
for
use
under
section
a
of
the
fd
c
act
a
medical
device
is
deemed
misbranded
if
its
labeling
is
false
or
misleading
in
any
particular
for
devices
with
cybersecurity
risks
informing
users
of
relevant
security
information
may
be
an
effective
way
to
comply
with
labeling
requirements
relating
to
such
risks
fda
also
believes
that
informing
users
of
security
information
through
labeling
may
be
an
important
part
of
design
and
development
activities
to
help
mitigate
cybersecurity
risks
and
help
ensure
the
continued
safety
and
effectiveness
of
the
device
therefore
when
drafting
labeling
for
inclusion
in
a
premarket
submission
a
manufacturer
should
consider
all
applicable
labeling
requirements
and
how
informing
users
through
labeling
may
be
an
effective
way
to
manage
cybersecurity
risks
and
or
to
ensure
the
safe
and
effective
use
of
the
device
any
risks
transferred
to
the
user
should
be
detailed
and
considered
for
inclusion
as
tasks
during
usability
testing
e
g
human
factors
testing
to
ensure
that
the
type
of
user
has
the
capability
to
take
appropriate
actions
to
manage
those
risks
the
following
standards
may
partially
meet
the
security
testing
recommendations
ansi
ul
software
cybersecurity
for
network-connectable
products
ansi
isa
security
for
industrial
automation
and
control
systems
part
product
security
development
life-cycle
requirements
in
addition
to
iec
additional
standards
may
also
meet
or
partially
meet
the
testing
recommendations
outlined
in
this
section
see
fda's
guidance
applying
human
factors
and
usability
engineering
to
medical
devices
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
applying-human-factors-and-usability
engineering-medical-devices
the
recommendations
below
aim
to
communicate
to
users
the
relevant
device
security
information
that
may
enable
their
own
ongoing
security
posture
thereby
helping
ensure
a
device
remains
safe
and
effective
throughout
its
lifecycle
the
depth
of
detail
the
exact
location
in
the
labeling
for
specific
types
of
information
e
g
operator's
manual
security
implementation
guide
and
the
method
to
provide
this
information
should
account
for
the
intended
user
of
the
information
instructions
to
manage
cybersecurity
risks
should
be
understandable
to
the
intended
audience
which
might
include
patients
or
caregivers
with
limited
technical
knowledge
the
manufacturer
may
wish
to
employ
methods
to
ensure
certain
information
is
available
only
to
the
user
and
if
it
does
so
through
an
online
portal
should
ensure
that
users
have
up-to-date
links
that
contain
accurate
information
the
following
are
examples
of
information
that
may
be
included
in
labeling
to
communicate
relevant
security
information
to
users
device
instructions
and
product
specifications
related
to
recommended
cybersecurity
controls
appropriate
for
the
intended
use
environment
e
g
anti-malware
software
use
of
a
firewall
password
requirements
sufficiently
detailed
diagrams
for
users
that
allow
recommended
cybersecurity
controls
to
be
implemented
a
list
of
network
ports
and
other
interfaces
that
are
expected
to
receive
and
or
send
data
this
list
should
include
a
description
of
port
functionality
and
indicate
whether
the
ports
are
incoming
outgoing
or
both
along
with
approved
destination
end-points
specific
guidance
to
users
regarding
supporting
infrastructure
requirements
so
that
the
device
can
operate
as
intended
e
g
minimum
networking
requirements
supported
encryption
interfaces
where
appropriate
such
guidance
should
include
technical
instructions
to
permit
secure
network
deployment
and
servicing
and
instructions
for
users
on
how
to
respond
upon
detection
of
a
cybersecurity
vulnerability
or
incident
an
sbom
as
specified
in
section
v
a
or
in
accordance
with
an
industry
accepted
format
to
effectively
manage
their
assets
to
understand
the
potential
impact
of
identified
vulnerabilities
to
the
medical
device
system
and
to
deploy
countermeasures
to
maintain
the
device's
safety
and
effectiveness
manufacturers
should
provide
or
make
available
sbom
information
to
users
on
a
continuous
basis
if
an
online
portal
is
used
manufacturers
should
ensure
that
users
have
up-to-date
links
that
contain
accurate
information
the
sbom
should
be
in
a
machine-readable
format
a
description
of
systematic
procedures
for
users
to
download
version-identifiable
manufacturer-authorized
software
and
firmware
including
a
description
of
how
users
will
know
when
software
is
available
a
description
of
how
the
design
enables
the
device
to
respond
when
anomalous
conditions
are
detected
i
e
security
events
this
should
include
notification
to
the
user
and
logging
of
relevant
information
security
event
types
could
be
configuration
changes
for
more
information
regarding
fda's
policy
on
labeling
changes
and
submission
requirements
manufacturers
can
use
the
fda
guidance
search
tool
to
identify
relevant
guidance
documents
for
their
product
and
submission
type
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
see
iec
tr
and
iec
tr
and
iec
tr
for
further
labeling
information
for
compliance
with
these
standards
network
anomalies
login
attempts
or
anomalous
traffic
e
g
send
requests
to
unknown
entities
a
high-level
description
of
the
device
features
that
protect
critical
functionality
e
g
backup
mode
disabling
ports
communications
a
description
of
backup
and
restore
features
and
procedures
to
restore
authenticated
configurations
a
description
of
methods
for
retention
and
recovery
of
device
configuration
by
an
authenticated
authorized
user
a
description
of
the
secure
configuration
of
shipped
devices
instructions
for
user
configurable
changes
and
identification
of
user-configurable
changes
that
could
increase
security
risk
for
the
medical
device
system
secure
configurations
may
include
end
point
protections
such
as
anti-malware
firewall
firewall
rules
allow
lists
deny
lists
security
event
parameters
logging
parameters
and
physical
security
detection
and
resetting
of
credentials
among
others
where
appropriate
for
the
intended
use
environment
a
description
of
how
forensic
evidence
is
captured
including
but
not
limited
to
any
log
files
kept
for
a
security
event
log
file
descriptions
should
include
how
where
and
in
what
format
the
log
file
is
located
stored
recycled
archived
and
how
it
could
be
consumed
by
automated
analysis
software
e
g
intrusion
detection
system
ids
or
security
information
and
event
management
siem
information
if
known
or
anticipated
concerning
device
cybersecurity
including
components
end
of
support
and
end
of
life
at
the
end
of
support
a
manufacturer
may
no
longer
be
able
to
reasonably
provide
security
patches
or
software
updates
if
the
device
remains
in
service
following
the
end
of
support
the
manufacturer
should
have
a
pre
established
and
pre-communicated
process
for
transferring
the
risks
highlighting
that
the
cybersecurity
risks
for
end-users
can
be
expected
to
increase
over
time
information
on
securely
decommissioning
devices
by
sanitizing
the
product
of
sensitive
confidential
and
proprietary
data
and
software
a
revision-controlled
manufacturer
disclosure
statement
for
medical
device
security
mds2
and
customer
security
documentation
as
outlined
in
the
medical
device
and
health
it
joint
security
plan
jsp
may
address
a
number
of
the
above
recommendations
b
cybersecurity
management
plans
recognizing
that
cybersecurity
risks
evolve
as
technology
evolves
throughout
a
device's
tplc
fda
recommends
that
manufacturers
establish
a
plan
for
how
they
will
identify
and
communicate
to
users
vulnerabilities
that
are
identified
after
releasing
the
device
in
accordance
with
the
cfr
this
plan
can
also
support
security
risk
management
processes
that
are
described
throughout
the
qs
regulation
fda
recommends
that
manufacturers
submit
their
cybersecurity
management
plans
as
part
of
their
premarket
submissions
so
that
fda
can
assess
whether
the
manufacturer
has
sufficiently
the
manufacturer
disclosure
statement
for
medical
device
security
is
available
at
https
www
nema
org
standards
view
manufacturer-disclosure-statement-for-medical-device-security
available
at
https
healthsectorcouncil
org
the-joint-security-plan
addressed
how
to
maintain
the
safety
and
effectiveness
of
the
device
after
marketing
authorization
is
achieved
for
cyber
devices
a
plan
to
monitor
identify
and
address
as
appropriate
in
a
reasonable
time
postmarket
cybersecurity
vulnerabilities
and
exploits
including
coordinated
vulnerability
disclosure
and
related
procedures
is
required
see
section
524b
b
of
the
fd
c
act
cybersecurity
management
plans
should
include
the
following
elements
personnel
responsible
sources
methods
and
frequency
for
monitoring
and
identifying
vulnerabilities
e
g
researchers
nist
national
vulnerability
database
nist
nvd
third-party
software
manufacturers
identify
and
address
vulnerabilities
identified
in
cisa
known
exploited
vulnerabilities
catalog
periodic
security
testing
timeline
to
develop
and
release
patches
update
processes
patching
capability
i
e
rate
at
which
update
can
be
delivered
to
devices
description
of
their
coordinated
vulnerability
disclosure
process
and
description
of
how
the
manufacturer
intends
to
communicate
forthcoming
remediations
patches
and
updates
to
customers
additional
recommendations
on
coordinated
vulnerability
disclosure
plans
may
be
found
in
fda's
postmarket
cybersecurity
guidance
available
at
https
www
cisa
gov
known-exploited-vulnerabilities-catalog
appendix
security
control
categories
and
associated
recommendations
the
following
sections
provide
detailed
descriptions
of
each
of
the
security
control
categories
introduced
in
section
v
b
as
well
as
specific
recommendations
for
security
controls
and
their
implementation
to
avoid
common
pitfalls
authentication
there
are
generally
two
types
of
authentication
controls
information
and
entities
and
a
properly-secured
system
is
able
to
prove
the
existence
of
both
authentication
of
information69
exists
where
the
device
and
the
system
in
which
it
operates
are
able
to
prove
that
information
originated
at
a
known
and
trusted
source
and
that
the
information
has
not
been
altered
in
transit
between
the
original
source
and
the
point
at
which
authenticity
is
verified
it
is
important
to
note
that
while
authenticity
implies
that
data
is
accurate
and
has
been
safeguarded
from
unauthorized
user
modification
i
e
integrity
integrity
alone
does
not
provide
assurance
that
the
data
is
real
and
came
from
a
trusted
source
therefore
for
the
purposes
of
this
guidance
authentication
is
discussed
as
a
larger
security
objective
over
integrity
authentication
of
entities
exists
where
a
device
and
the
system
in
which
it
operates
is
able
to
prove
the
identity
of
an
endpoint
whether
hardware
and
or
software
from
which
it
is
sending
and
or
receiving
information
or
authorized
user
operator
at
that
endpoint
as
part
of
normal
operations
within
a
secure
system
devices
should
verify
the
authenticity
of
information
from
external
entities
as
well
as
prove
the
authenticity
of
information
that
they
generate
a
medical
device
system
that
appropriately
accounts
for
authenticity
can
evaluate
and
ensure
authenticity
for
information
at
rest
stored
information
in
transit
transmitted
entity
authentication
of
communication
endpoints
whether
those
endpoints
consist
of
software
or
hardware
software
binaries
integrity
of
the
execution
state
of
currently
running
software
and
any
other
appropriate
parts
of
the
medical
device
system
where
a
manufacturer's
threat
model
and
or
risk
analyses
reveal
the
need
for
it
on
a
technical
level
the
strength
of
a
device's
authentication
scheme
is
defined
by
the
amount
of
effort
including
time
that
an
unauthorized
party
would
need
to
expend
to
identify
the
decomposition
of
the
authentication
scheme
for
example
this
could
be
the
time
and
resources
necessary
to
determine
the
correct
output
of
a
cryptographic
function
from
which
a
cryptographically-based
authentication
scheme
is
built
and
which
an
unauthorized
party
could
use
to
bypass
the
authentication
scheme
and
gain
access
to
the
medical
device
system
for
the
purposes
of
this
control
information
includes
the
software
firmware
itself
as
well
as
input
and
output
data
when
choosing
an
authentication
scheme
manufacturers
should
keep
in
mind
the
following
generally
applicable
characteristics
of
different
types
of
schemes
implicit
authentication
schemes
based
solely
on
non-cryptographic
interfaces
handshakes
and
or
protocols
are
inherently
weak
because
once
they
are
reverse
engineered
an
unauthorized
user
can
easily
emulate
the
correct
behavior
and
appear
to
be
authorized
cryptographic
authentication
protocols
are
generally
superior
but
they
need
careful
design
choices
and
implementation
practices
to
achieve
their
full
strength
in
addition
these
schemes
are
still
limited
by
the
confidentiality
of
the
cryptographic
keys
needed
to
interact
with
the
scheme
and
by
the
integrity
of
the
devices
that
hold
or
otherwise
leverage
those
keys
for
more
information
on
cryptography
see
appendix
subsection
c
below
therefore
for
device
operations
where
non-authenticated
behavior
could
lead
to
harm
devices
should
implement
additional
non-routine
signals
of
intent
based
on
physical
actions
such
as
a
momentary
switch
to
authorize
the
command
session
the
following
list
provides
additional
recommendations
for
the
implementation
of
authentication
schemes
use
cryptographically
strong70
authentication
where
the
authentication
functionality
resides
on
the
device
to
authenticate
personnel
messages
commands
updates
and
as
applicable
all
other
communication
pathways
hardware-based
security
solutions
should
be
considered
and
employed
when
possible
authenticate
external
connections
at
a
frequency
commensurate
with
the
associated
risks
for
example
if
a
device
connects
to
an
offsite
server
then
the
device
and
the
server
should
mutually
authenticate
each
session
and
limit
the
duration
of
the
session
even
if
the
connection
is
initiated
over
one
or
more
existing
trusted
channels
use
appropriate
user
authentication
e
g
multi-factor
authentication
to
permit
privileged
device
access
to
system
administrators
service
technicians
or
maintenance
personnel
among
others
as
needed
require
authentication
and
authorization
in
certain
instances
before
permitting
software
or
firmware
updates
including
those
updates
affecting
the
operating
system
applications
and
anti-malware
functionality
strengthen
password
protections
do
not
use
passwords
that
are
hardcoded
default
easily
guessed
or
easily
compromised
e
g
passwords
that
are
the
same
for
each
device
unchangeable
can
persist
as
default
difficult
to
change
and
or
vulnerable
to
public
disclosure
implement
anti-replay
measures
in
critical
communications
such
as
potentially
harmful
commands
this
can
be
accomplished
with
the
use
of
several
methods
including
the
use
of
cryptographic
nonces
an
arbitrary
number
used
only
once
in
a
cryptographic
communication
see
the
definition
of
security
strength
in
appendix
terminology
provide
mechanisms
for
verifying
the
authenticity
of
information
originating
from
the
device
such
as
telemetry
this
is
especially
important
for
data
that
if
spoofed
or
otherwise
modified
could
result
in
patient
harm
such
as
the
link
between
a
clinician
programmer
or
monitoring
device
and
an
implanted
device
like
a
pacemaker
defibrillator
or
neurostimulator
or
the
link
between
a
continuous
glucose
monitor
system
and
an
automated
insulin
pump
do
not
rely
on
cyclic
redundancy
checks
crcs
as
security
controls
crcs
do
not
provide
integrity
or
authentication
protections
in
a
security
environment
while
crcs
are
an
error
detecting
code
and
provide
integrity
protection
against
environmental
factors
e
g
noise
or
emc
they
do
not
provide
protections
against
an
intentional
or
malicious
actor
and
consider
how
the
device
and
or
system
should
respond
in
event
of
authentication
failure
s
authorization
for
the
purposes
of
this
guidance
authorization
is
the
right
or
a
permission
that
is
granted
to
a
system
entity
e
g
a
device
server
or
software
function
to
access
a
system
resource
more
specifically
as
a
defensive
measure
an
authorization
scheme
enforces
privileges
i
e
rights
associated
with
authenticated
sessions
identities
and
or
roles
these
privileges
either
permit
allowed
behavior
or
refuse
disallowed
behavior
in
order
to
ensure
that
system
resources
are
only
accessed
in
accepted
ways
by
accepted
parties
within
an
adequately
designed
authorization
scheme
the
principle
of
least
privileges71
should
be
applied
to
users
system
functions
and
others
to
only
allow
those
entities
the
levels
of
system
access
necessary
to
perform
a
specific
function
for
example
in
a
situation
in
which
a
malicious
actor
has
gained
access
to
a
credential
associated
with
patient
privileges
that
malicious
actor
should
not
be
able
to
access
device
resources
or
functionality
reserved
for
the
manufacturer
or
for
the
healthcare
provider
such
as
device
maintenance
routines
or
the
ability
to
change
medication
dosage
amounts
while
authentication
schemes
based
on
cryptographically
proven
designs
are
generally
considered
more
robust
and
are
therefore
preferred
meaningful
authorization
checks
can
be
performed
based
on
other
compelling
evidence
e
g
benefit
risk
assessment
in
accordance
with
section
of
aami
tir57
and
associated
supporting
justification
and
as
evidenced
through
security
testing
for
example
a
medical
device
programmer
that
is
capable
of
near-field
communications
nfc
could
have
elevated
privileges
that
are
granted
based
on
a
signal
of
intent72
over
nfc
that
cannot
physically
be
produced
by
another
unauthorized
device
over
radio-frequency
rf
e
g
a
home
monitor
the
following
list
provides
recommended
design
implementations
for
an
authorization
scheme
cnssi
defines
least
privilege
as
the
principle
that
a
security
architecture
should
be
designed
so
that
each
entity
e
g
user
asset
is
granted
the
minimum
system
resources
and
authorizations
that
the
entity
needs
to
perform
its
function
for
the
purposes
of
this
guidance
signal
of
intent
is
specific
to
the
implementation
of
nfc
communications
limit
authorized
access
to
devices
through
the
authentication
of
users
e
g
user
id
and
password
smartcard
biometric
certificates
or
other
appropriate
authentication
method
use
automatic
timed
methods
to
terminate
sessions
within
the
medical
device
system
where
appropriate
for
the
use
environment
employ
an
authorization
model
that
incorporates
the
principle
of
least
privileges
by
differentiating
privileges
based
on
the
user
role
e
g
caregiver
patient
healthcare
provider
system
administrator
or
device
functions
and
design
devices
to
deny
by
default
i
e
that
which
is
not
expressly
permitted
by
a
device
is
denied
by
default
for
example
the
device
should
generally
reject
all
unauthorized
connections
e
g
incoming
tcp
usb
bluetooth
serial
connections
ignoring
requests
is
one
form
of
denying
authorization
cryptography
cryptographic
algorithms
and
protocols
are
recommended
to
be
implemented
to
achieve
the
secure
by
design
objectives
outlined
in
section
iv
while
high-quality
standardized
cryptographic
algorithms
and
protocols
are
readily
available
several
commercial
products
that
include
cryptographic
protections
have
been
shown
to
have
exploitable
vulnerabilities
due
to
improper
configurations
and
or
implementations
while
other
sections
of
this
guidance
reference
cryptographic
controls
the
following
recommendations
are
specifically
related
to
the
selection
and
implementation
of
the
underlying
cryptographic
scheme
used
by
a
device
and
the
larger
system
in
which
it
operates
select
industry-standard
cryptographic
algorithms
and
protocols
and
select
appropriate
key
generation
distribution
management
and
protection
as
well
as
robust
nonce
mechanisms
use
current
nist
recommended
standards
for
cryptography
e
g
fips
nist
suite
b74
or
equivalent-strength
cryptographic
protection
that
are
expected
to
be
considered
cryptographically
strong
throughout
the
service
life
of
the
device
manufacturers
should
not
implement
cryptographic
algorithms
that
have
been
deprecated
or
disallowed
in
applicable
standards
or
best
practices
e
g
nist
sp
800-131a
transitioning
the
use
of
cryptographic
algorithms
and
key
lengths
implementation
of
algorithms
with
a
status
of
legacy
use
should
be
discussed
with
fda
during
a
pre-submission
meeting
design
a
system
architecture
and
implement
security
controls
to
prevent
a
situation
where
the
full
compromise
of
any
single
device
can
result
in
the
ability
to
reveal
keys
for
other
devices
for
example
avoid
using
master-keys
stored
on
device
or
key
derivation
algorithms
based
solely
on
device
identifiers
or
other
readily
discoverable
information
nist
fips
cryptographic
module
validation
program
available
at
https
csrc
nist
gov
projects
cryptographic-module-validation-program
fips-140-2
nist
fips
suite
b
available
at
https
csrc
nist
gov
csrc
media
projects
cryptographic-module
validation-program
documents
security-policies
140sp2851
pdf
for
example
avoid
using
device
serial
numbers
as
keys
or
as
part
of
keys
device
serial
numbers
may
be
disclosed
by
patients
seeking
additional
information
on
their
device
or
might
be
disclosed
during
a
device
recall
to
identify
affected
products
and
should
be
avoided
as
part
of
the
key
generation
process
e
g
public
key
cryptography
can
be
employed
to
help
meet
this
objective
implement
cryptographic
protocols
that
permit
negotiated
parameters
versions
such
that
the
most
recent
secure
configurations
are
used
unless
otherwise
necessary
do
not
allow
downgrades
or
version
rollbacks
unless
absolutely
necessary
for
safety
reasons
and
log
and
document
the
event
downgrades
can
allow
attackers
to
exploit
prior
less
protected
versions
and
should
be
avoided
code
data
and
execution
integrity
many
cybersecurity
incidents
are
caused
at
their
root
by
the
violation
of
some
form
of
device
integrity
this
includes
the
violation
of
stored
code
stored
and
operational
data
or
execution
state
the
following
recommendations
are
provided
to
address
each
of
these
categories
code
integrity
hardware-based
security
solutions
should
be
considered
and
employed
when
possible
authenticate
firmware
and
software
verify
authentication
tags
e
g
signatures
message
authentication
codes
macs
of
software
firmware
content
version
numbers
and
other
metadata
the
version
numbers
intended
to
be
installed
should
themselves
be
signed
or
have
macs
devices
should
be
electronically
and
visibly
identifiable
e
g
unique
device
identifier
udi
model
number
serial
number
allow
installation
of
cryptographically
authenticated
firmware
and
software
updates
and
do
not
allow
installation
where
such
cryptographic
authentication
either
is
absent
or
fails
use
cryptographically
signed
updates
to
help
prevent
any
unauthorized
reductions
in
the
level
of
protection
downgrade
or
rollback
attacks
by
ensuring
that
the
new
update
represents
an
authorized
version
change
one
possible
approach
for
authorized
downgrades
would
be
to
sign
new
metadata
for
downgrade
requests
which
by
definition
only
happen
in
exceptional
circumstances
ensure
that
the
authenticity
of
software
firmware
and
configuration
are
validated
prior
to
execution
e
g
allow-listing
based
on
digital
signatures
disable
or
otherwise
restrict
unauthorized
access
to
all
test
and
debug
ports
e
g
jtag
uart
prior
to
delivering
products
and
employ
tamper
evident
seals
on
device
enclosures
and
their
sensitive
communication
ports
to
help
verify
physical
integrity
for
more
information
regarding
udi
see
fda's
webpage
https
www
fda
gov
medical-devices
unique-device
identification-system-udi-system
udi-rule-guidances-training-and-other-resources
for
the
purposes
of
this
guidance
allow-list
means
a
list
of
discrete
entities
such
as
hosts
or
applications
that
are
known
to
be
benign
and
are
approved
for
use
within
an
organization
and
or
information
system
this
term
is
leveraged
from
the
definition
of
whitelist
in
nist
sp
available
at
https
csrc
nist
gov
pubs
sp
upd1
final
data
integrity
verify
the
integrity
of
all
incoming
data
ensuring
that
it
is
not
modified
in
transit
or
at
rest
cryptographic
authentication
schemes
verify
data
integrity
but
do
not
verify
data
validity
therefore
the
integrity
of
all
incoming
data
should
be
verified
to
ensure
that
it
is
not
modified
in
transit
or
at
rest
validate
that
all
data
originating
from
external
sources
is
well-formed
and
compliant
with
the
expected
protocol
or
specification
additionally
as
appropriate
validate
data
ranges
to
ensure
they
fall
within
safe
limits
and
protect
the
integrity
of
data
necessary
to
ensure
the
safety
and
effectiveness
of
the
device
e
g
critical
configuration
settings
such
as
energy
output
execution
integrity
use
industry-accepted
best
practices
to
maintain
and
verify
integrity
of
code
while
it
is
being
executed
on
the
device
for
example
host-based
intrusion
detection
prevention
systems
hids
hips
can
be
used
to
accomplish
this
goal
and
carefully
design
and
review
all
code
that
handles
the
parsing
of
external
data
using
automated
e
g
static
and
dynamic
analyses
and
manual
i
e
code
review
methods
confidentiality
manufacturers
should
ensure
support
for
the
confidentiality77
of
any
all
data
whose
disclosure
could
lead
to
patient
harm
e
g
through
the
unauthorized
use
of
otherwise
valid
credentials
lack
of
encryption
loss
of
confidentiality
of
credentials
could
be
used
by
a
threat-actor
to
effect
multi-patient
harm
lack
of
encryption
to
protect
sensitive
information
and
or
data
at
rest
and
in
transit
can
expose
this
information
to
misuse
that
can
lead
to
patient
harm
for
example
confidentiality
is
required
in
the
handling
and
storage
of
cryptographic
keys
used
for
authentication
because
disclosure
could
lead
to
unauthorized
use
abuse
of
device
functionality
the
proper
implementation
of
authorization
and
authentication
schemes
as
described
in
sections
a
and
b
of
this
appendix
will
generally
assure
confidentiality
however
manufacturers
should
evaluate
and
assess
whether
this
is
the
case
during
their
threat
modeling
and
other
risk
management
activities
and
make
any
appropriate
changes
to
their
medical
device
systems
to
ensure
appropriate
confidentiality
controls
are
in
place
event
detection
and
logging
event
detection
and
logging
are
critical
capabilities
that
should
be
present
in
a
device
and
the
larger
system
in
which
it
operates
in
order
to
ensure
that
suspected
and
successful
attempts
to
compromise
a
medical
device
may
be
identified
and
tracked
these
event
detection
capabilities
for
the
purposes
of
this
guidance
loss
of
confidential
health
information
is
generally
not
considered
to
be
a
direct
impact
on
safety
and
effectiveness
although
protecting
the
confidentiality
of
phi
is
beyond
the
scope
of
this
document
it
should
be
noted
that
manufacturers
and
other
entities
depending
on
the
facts
and
circumstances
may
be
obligated
to
protect
the
confidentiality
integrity
and
availability
of
phi
throughout
the
product
lifecycle
in
accordance
with
applicable
federal
and
state
laws
including
the
health
insurance
portability
and
accountability
act
hipaa
for
more
information
on
hipaa
please
visit
https
www
hhs
gov
hipaa
for-professionals
security
laws
regulations
index
html
and
logs
should
include
storage
capabilities
if
possible
so
that
forensic
discovery
may
later
be
performed
while
many
of
the
following
recommendations
are
tailored
for
workstations
the
concepts
presented
below
also
apply
to
embedded
computing
devices
manufacturers
should
consider
the
following
for
all
devices
implement
design
features
that
allow
for
security
compromises
and
suspected
compromise
attempts
to
be
detected
recognized
logged
timed
and
acted
upon
during
normal
use
acting
upon
security
events
should
consider
the
benefit
risk
assessment
in
accordance
with
section
of
aami
tir57
in
determining
whether
it
is
appropriate
to
affect
standard
device
functionality
during
a
security
event
ensure
the
design
enables
forensic
evidence
capture
the
design
should
include
mechanisms
to
securely
create
and
store
log
files
off
the
device
to
track
security
events
documentation
should
include
how
and
where
log
files
are
located
stored
recycled
archived
and
how
they
could
be
consumed
by
automated
analysis
software
e
g
intrusion
detection
system
ids
examples
of
security
events
include
but
are
not
limited
to
configuration
changes
network
anomalies
login
attempts
and
anomalous
traffic
e
g
sending
requests
to
unknown
entities
design
devices
such
that
the
potential
impact
of
vulnerabilities
is
limited
by
specifying
a
secure
configuration
secure
configurations
may
include
endpoint
protections
such
as
anti-malware
firewall
firewall
rules
allow-listing
defining
security
event
parameters
logging
parameters
physical
security
detection
and
or
hids
hips
design
devices
such
that
they
may
integrate
and
or
leverage
antivirus
anti-malware
protection
capabilities
these
capabilities
may
vary
depending
on
the
type
of
device
and
the
software
and
hardware
components
it
contains
for
devices
that
leverage
windows
operating
system
antivirus
anti-malware
is
recommended
on
the
device
manufacturers
are
recommended
to
qualify
multiple
options
to
support
user
preferences
for
different
options
especially
if
the
device
is
used
in
healthcare
facility
environments
for
devices
that
leverage
other
commercial
operating
systems
e
g
ubuntu
unix
linux
apple
android
antivirus
anti-malware
may
be
recommended
based
on
the
environment
and
associated
risks
of
the
device
different
operating
systems
will
likely
follow
a
case-by-case
determination
based
on
network
exposure
and
risk
for
devices
that
leverage
embedded
operating
systems
e
g
real-time
operating
systems
windows
embedded
antivirus
malware
detection
protection
software
is
generally
not
needed
unless
a
particular
risk
or
threat
is
identified
that
would
not
be
addressed
by
other
expected
security
controls
forensic
evidence
capture
is
a
necessary
part
of
digital
forensics
nist
sp
available
at
https
nvlpubs
nist
gov
nistpubs
legacy
sp
nistspecialpublication800-86
pdf
defines
digital
forensics
as
the
application
of
science
to
the
identification
collection
examination
and
analysis
of
data
while
preserving
the
integrity
of
the
information
and
maintaining
a
strict
chain
of
custody
for
the
data
design
devices
to
enable
software
configuration
management
and
permit
tracking
and
control
of
software
changes
to
be
electronically
obtainable
i
e
machine
readable
by
authorized
users
design
devices
to
facilitate
the
performance
of
variant
analyses
such
that
the
same
vulnerabilities
can
be
identified
across
device
models
and
product
lines
design
devices
to
notify
users
when
malfunctions
or
anomalous
device
behavior
including
those
potentially
related
to
a
cybersecurity
breach
are
detected
consider
designing
devices
such
that
they
are
able
to
produce
a
sbom
in
a
machine
readable79
format
resiliency
and
recovery
devices
should
be
designed
to
be
resilient
to
possible
cyber
incident
scenarios
also
known
as
cyber-resiliency
and
maintain
availability
cyber-resiliency
capabilities
are
important
for
medical
devices
because
they
provide
a
safety
margin
against
unknown
future
vulnerabilities
the
following
recommendations
are
intended
to
help
designers
achieve
cyber-resiliency
implement
features
that
protect
critical
functionality
and
data
even
when
the
device
has
been
partially
compromised
for
example
process
isolation
virtualization
techniques
and
hardware-backed
trusted
execution
environments
all
provide
mechanisms
to
potentially
contain
the
impact
of
a
successful
exploitation
of
a
device
design
devices
to
provide
methods
for
retention
and
recovery
of
trusted
default
device
configuration
by
an
authenticated
authorized
user
design
devices
to
specify
the
level
of
resilience
or
independent
ability
to
function
that
any
component
of
the
medical
device
system
possesses
when
its
communication
capabilities
with
the
rest
of
the
medical
device
system
are
disrupted
including
disruption
of
significant
duration
design
devices
to
be
resilient
to
possible
cyber
incident
scenarios
such
as
network
outages
denial
of
service
excessive
bandwidth
usage
by
other
products
disrupted
quality
of
service
qos
and
or
excessive
jitter82
i
e
a
variation
in
the
delay
of
received
packets
design
devices
to
be
resilient
to
possible
noise
items
e
g
scanning
firmware
and
software
updates
devices
should
be
capable
of
being
updated
in
a
secure
and
timely
manner
to
maintain
safety
and
effectiveness
throughout
the
product's
lifecycle
despite
best
efforts
undiscovered
exploitable
vulnerabilities
may
exist
in
devices
after
they
are
marketed
this
is
especially
true
over
the
recommendation
from
the
health
care
industry
and
cybersecurity
task
force
hcic
tf
report
on
improving
cybersecurity
in
the
health
care
industry
available
at
https
www
phe
gov
preparedness
planning
cybertf
documents
report2017
pdf
denial
of
service
is
an
attack
that
prevents
or
impairs
the
authorized
use
of
the
information
system
resources
or
services
from
cnssi
committee
on
national
security
systems
cnss
glossary
from
nist
computer
security
resource
center
glossary
available
at
https
csrc
nist
gov
glossary
term
jitter
device's
service
life
as
threats
evolve
over
time
and
exploit
methods
change
and
become
more
sophisticated
fda
recommends
that
manufacturers
should
not
only
build
in
the
ability
for
devices
to
be
updated
but
that
manufacturers
also
plan
for
the
rapid
testing
evaluation
and
patching
of
devices
deployed
in
the
field
the
following
recommendations
can
help
to
achieve
this
design
devices
to
anticipate
the
need
for
software
and
firmware
patches
and
updates
to
address
future
cybersecurity
vulnerabilities
this
will
likely
necessitate
the
need
for
additional
storage
space
and
processing
resources
consider
update
process
reliability
and
how
update
process
works
in
event
of
communication
interruption
or
failure
this
should
include
both
considerations
for
hardware
impacts
timing
specifics
of
interruptions
and
which
phase
of
the
update
process
the
interruption
or
failure
occurs
consider
cybersecurity
patches
and
updates
that
are
independent
of
regular
feature
update
cycles
implement
processes
technologies
security
architectures
and
exercises
to
facilitate
the
rapid
verification
validation
and
distribution
of
patches
and
updates
preserve
and
maintain
full
build
environments
and
virtual
machines
regression
test
suites
engineering
development
kits
emulators
debuggers
and
other
related
tools
that
were
used
to
develop
and
test
the
original
product
to
ensure
updates
and
patches
may
be
applied
safely
and
in
a
timely
manner
maintain
necessary
third-party
licenses
throughout
the
supported
lifespan
of
the
device
develop
contingency
plans
for
the
possibility
that
a
third-party
company
goes
out
of
business
or
stops
supporting
a
licensed
product
modular
designs
should
be
considered
such
that
third-party
solutions
could
be
readily
replaced
implement
a
secure
process
and
mechanism
for
providing
validated
software
updates
and
patches
for
users
appendix
submission
documentation
for
security
architecture
flows
in
premarket
submissions
fda
recommends
that
manufacturers
provide
detailed
information
for
the
views
identified
in
section
v
b
methods
for
providing
the
views
and
the
recommendations
for
the
level
of
detail
to
provide
are
discussed
in
the
sections
below
in
addition
to
diagrams
and
explanatory
text
call-flow
views
can
be
provided
to
convey
some
of
the
information
details
expected
to
be
addressed
in
the
architecture
views
a
diagrams
fda
recommends
that
manufacturers
provide
diagrams
to
help
describe
the
medical
device
system
architecture
interfaces
communication
protocols
threats
and
cybersecurity
controls
used
throughout
the
system
different
diagramming
methods
can
be
used
to
describe
the
architecture
including
data
flow
diagrams
state
diagrams
swim-lane
diagrams
and
call-flow
diagrams
among
others
architecture
views
should
include
diagram
s
with
explanatory
text
that
describes
the
sequence
of
process
or
protocol
steps
in
explicit
detail
for
an
associated
use
case
architecture
views
should
provide
specific
protocol
details
of
the
communication
pathways
between
parts
of
the
medical
device
system
to
include
authentication
or
authorization
procedures
and
session
management
techniques
these
views
should
be
sufficiently
detailed
such
that
engineers
and
reviewers
should
be
able
to
logically
and
easily
follow
data
code
and
commands
from
any
asset
e
g
a
manufacturer
server
to
any
other
associated
asset
e
g
a
medical
device
while
possibly
crossing
intermediate
assets
e
g
application
the
diagrams
may
also
include
items
from
the
information
details
identified
below
for
the
architecture
views
identified
in
section
v
b
if
the
information
is
better
represented
or
conveyed
through
a
diagram
than
explanatory
text
alone
b
information
details
for
an
architecture
view
for
each
view
described
in
section
v
b
manufacturers
should
provide
a
system-level
description
and
analysis
inclusive
of
end-to-end
security
analyses
of
all
the
communications
in
the
medical
device
system
regardless
of
intended
use
this
should
include
detailed
diagrams
and
traces
for
all
communication
paths
as
described
below
security-relevant
analysis
requires
the
ability
to
construct
and
follow
a
detailed
trace
for
important
communication
paths
which
describes
how
data
code
and
commands
are
protected
between
any
two
assets
in
the
medical
device
system
this
analysis
can
also
help
identify
the
software
that
should
be
included
in
the
sbom
for
each
device
the
fda
recommends
that
security
architecture
views
should
consider
the
following
examples
of
information
for
inclusion
detailed
diagrams
and
supporting
explanatory
text
that
identify
all
medical
device
system
assets
including
but
not
limited
to
device
hardware
itself
including
assessments
for
any
commercial
platforms
applications
hardware
and
or
other
supporting
assets
that
directly
interact
with
the
targeted
device
such
as
configuration
installation
upgrade
and
data
transfer
applications
healthcare
facility-operated
assets
communications
networking
assets
and
manufacturer-controlled
assets
including
any
servers
that
interact
with
external
entities
e
g
a
service
that
collects
and
redistributes
device
data
or
a
firmware
update
server
for
every
communication
path
that
exists
between
any
two
assets
in
the
security
use
case
view
and
or
explanatory
text
including
indirect
connections
when
there
is
at
least
one
intermediate
asset
e
g
an
app
the
following
details
should
be
provided
a
list
of
the
communication
interfaces
and
paths
including
communication
paths
e
g
between
two
assets
through
an
intermediary
and
any
unused
interfaces
an
indication
of
whether
the
path
is
used
for
data
code
and
or
commands
and
type
of
data
information
code
being
transferred
protocol
name
s
version
number
s
and
ports
channels
frequencies
detailed
descriptions
of
the
primary
and
all
available
functionality
for
each
medical
device
system
asset
including
assessment
of
any
functionality
that
is
built
in
but
not
currently
used
or
enabled
e
g
dormant
application
functionality
or
ports
including
assurance
that
this
functionality
cannot
be
activated
and
or
misused
access
control
models
or
features
if
any
for
every
asset
such
as
privileges
user
accounts
groups
passwords
users
roles
and
levels
of
responsibility
if
they
interact
with
the
assets
and
communication
channels
any
handoff
sequences
from
one
communication
path
to
another
e
g
from
asset
to
asset
network
to
network
or
bluetooth
to
wi-fi
and
how
the
data
code
and
or
commands
are
secured
protected
during
handoff
i
e
how
is
their
integrity
authenticity
assured
explanations
of
intended
behavior
in
unusual
erroneous
unexpected
circumstances
e
g
termination
of
a
connection
in
the
middle
of
a
data
transfer
authentication
mechanism
if
any
including
the
algorithm
name
version
if
available
strength
indicators
e
g
key
bit
length
number
of
computational
rounds
and
mode
of
operation
if
applicable
descriptions
of
the
cryptographic
method
used
and
the
type
and
level
of
cryptographic
key
usage
and
their
style
of
use
throughout
the
medical
device
system
e
g
one-time
use
key
length
the
standard
employed
symmetric
or
otherwise
descriptions
should
also
include
details
of
cryptographic
protection
for
firmware
and
software
updates
detailed
analyses
by
cryptography
experts
if
a
cryptography
algorithm
is
proprietary
or
a
proprietary
modification
of
a
standard
algorithm
for
each
authenticator
created
a
list
of
where
it
is
verified
and
how
verification
credentials
e
g
certificates
asymmetric
keys
or
shared
keys
are
distributed
to
both
endpoints
a
precise
detailed
list
of
how
each
type
of
credential
e
g
password
key
is
generated
stored
configured
transferred
and
maintained
including
both
manufacturer
and
healthcare
facility-controlled
assets
e
g
key
management
and
public
key
infrastructure
pki
identity
management83
if
any
including
how
identities
are
managed
transferred
and
configured
e
g
from
manufacturer
to
programmer
and
from
programmer
to
device
if
communication
sessions
are
used
or
supported
a
detailed
explanation
of
how
sessions
are
established
maintained
and
broken
down
including
but
not
limited
to
assurances
of
security
properties
such
as
uniqueness
unpredictability
time
stamping
and
verification
of
session
identifiers
include
any
security
configuration
settings
and
their
default
values
precise
links
between
diagram
elements
or
explanatory
text
associated
hazards
and
controls
and
testing
explanations
or
links
to
the
evidence
that
may
be
used
to
justify
security
claims
and
any
assumptions
and
traceability
of
the
asset
to
the
sbom
component
described
in
section
v
b
above
for
proprietary
and
third-party
code
when
appropriate
for
the
purposes
of
this
guidance
identity
management
means
the
process
that
governs
the
authentication
and
authorization
of
users
to
devices
and
assets
appendix
submission
documentation
for
investigational
device
exemptions
fda
understands
the
need
to
balance
innovation
and
security
in
designs
especially
during
clinical
trials
in
order
to
ensure
security
is
addressed
early
in
the
device
design
fda
has
identified
a
subset
of
the
documentation
recommended
throughout
this
guidance
to
submit
with
ide
applications
under
cfr
manufacturers
must
provide
an
investigational
plan
as
a
part
of
their
ide
application
for
investigational
devices
within
the
scope
of
this
guidance
fda
recommends
that
this
investigational
plan
include
information
on
the
cybersecurity
of
the
subject
device
specifically
fda
recommends
the
following
documentation
be
included
as
part
of
ide
applications
inclusion
of
cybersecurity
risks
as
part
of
informed
consent
form
cfr
a
and
cfr
g
global
multi-patient
and
updateability
patchability
views
cfr
c
d
security
use
case
views
for
functionality
with
safety
risks
e
g
implant
programming
cfr
c
d
software
bill
of
materials
cfr
c
d
and
general
labeling
connectivity
and
associated
general
cybersecurity
risks
updateability
process
cfr
f
fda
intends
to
review
this
information
in
the
context
of
the
overall
benefit-risk
assessment
of
investigational
devices
as
outlined
in
the
guidance
factors
to
consider
when
making
benefit
risk
determinations
for
medical
device
investigational
device
exemptions
therefore
approval
of
an
ide
based
on
the
documentation
recommended
above
does
not
preclude
the
possibility
of
future
cybersecurity
questions
or
concerns
being
raised
during
review
of
a
subsequent
marketing
application
this
is
in
part
due
to
the
understanding
that
design
changes
may
be
needed
and
the
temporal
nature
of
cybersecurity
cybersecurity
improvements
will
likely
be
needed
between
the
time
of
clinical
trials
and
when
the
device
is
submitted
for
marketing
authorization
e
g
operating
system
no
longer
supported
or
nearing
end
of
support
third-party
software
updates
available
at
https
www
fda
gov
regulatory-information
search-fda-guidance-documents
factors-consider-when
making-benefit-risk-determinations-medical-device-investigational-device
appendix
general
premarket
submission
documentation
elements
and
scaling
with
risk
as
stated
in
section
iv
d
and
throughout
the
guidance
device
cybersecurity
design
and
documentation
are
expected
to
scale
with
the
cybersecurity
risk
of
that
device
while
documentation
breadth
is
expected
to
scale
each
type
of
documentation
identified
throughout
the
guidance
is
recommended
for
all
premarket
submissions
for
devices
with
potential
cybersecurity
risks
table
below
summarizes
the
specific
documentation
elements
identified
throughout
the
guidance
for
premarket
submissions
the
associated
sections
of
the
guidance
for
the
document
and
whether
the
documentation
is
recommended
for
ide
submissions
while
documentation
elements
are
identified
for
the
security
risk
management
report
manufacturers
can
provide
the
documentation
elements
in
a
way
that
is
consistent
with
their
existing
documentation
processes
this
table
is
not
intended
to
serve
as
merely
a
deliverable
checklist
as
the
processes
outlined
throughout
the
guidance
are
intended
to
help
align
generation
of
these
documents
and
their
resultant
content
with
fda's
recommendations
this
table
represents
one
possible
way
to
organize
the
recommended
information
the
below
documentation
will
naturally
scale
with
the
level
of
cybersecurity
risk
this
will
be
most
evident
in
the
breadth
of
the
threat
modeling
and
architecture
views
documentation
for
example
a
device
with
either
only
one
hardware
connection
e
g
usb
port
or
a
samd
product
with
limited
other
software
dependencies
and
connectivity
will
likely
only
need
to
have
single
architecture
view
for
each
of
the
global
system
multi-patient
harm
and
updateability
patchability
views
the
security
use
case
view
s
will
likely
be
limited
to
a
smaller
subset
of
unique
views
to
address
the
available
connectivity
and
software
for
a
device
with
greater
complexities
such
as
but
not
limited
to
networking
wireless
connections
cloud
and
or
commercial
operating
systems
multiple
architecture
views
may
be
needed
for
the
multi-patient
harm
and
updateability
patchability
views
as
there
may
be
multiple
ways
to
cause
multi-patient
harm
or
update
elements
of
the
device
additionally
many
security
use
case
views
will
likely
be
needed
to
convey
the
various
unique
security
and
clinical
use
cases
throughout
the
architecture
table
recommended
premarket
submission
documentation
type
of
premarket
submission
documentation
guidance
section
s
ide
submission
cybersecurity
risk
management
report
sections
v
vi
b
could
be
helpful
to
submit
but
not
specifically
recommended
threat
model
may
include
architecture
views
sections
v
a
v
a
v
a
v
a
v
b
appendix
appendix
could
be
helpful
to
submit
but
not
specifically
recommended
see
architecture
view
recommendations
type
of
premarket
submission
documentation
guidance
section
s
ide
submission
cybersecurity
risk
assessment
sections
v
a
v
a
v
a
v
a
v
a
could
be
helpful
to
submit
but
not
specifically
recommended
sbom
sections
v
a
vi
a
recommended
vulnerability
assessment
and
software
support
section
v
a
could
be
helpful
to
submit
but
not
specifically
recommended
unresolved
anomalies
assessment
section
v
a
could
be
helpful
to
submit
but
not
specifically
recommended
traceability
sections
v
a
v
a
v
a
v
a
v
a
v
a
v
a
v
b
v
b
v
c
vi
a
could
be
helpful
to
submit
but
not
specifically
recommended
measures
and
metrics
section
v
a
could
be
helpful
to
submit
but
not
specifically
recommended
architecture
views
section
v
b
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
requirements
sections
v
b
appendix
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
architecture
views
may
be
included
in
threat
model
sections
v
a
v
b
appendix
appendix
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
testing
section
v
c
could
be
helpful
to
submit
but
not
specifically
recommended
labeling
section
vi
a
recommended
informed
consent
form
to
include
cybersecurity
risks
type
of
premarket
submission
documentation
guidance
section
s
ide
submission
general
cybersecurity
labeling
connectivity
and
associated
general
cybersecurity
risks
updateability
process
cybersecurity
management
plans
section
vi
b
could
be
helpful
to
submit
but
not
specifically
recommended
for
the
purposes
of
this
table
recommended
refers
to
the
elements
of
an
ide
submission
fda
discusses
in
appendix
of
this
document
could
be
helpful
to
submit
but
not
specifically
recommended
refers
to
additional
elements
that
could
be
helpful
to
fda
if
submitted
but
are
not
specifically
recommended
in
appendix
if
a
device-specific
guidance
contains
additional
or
different
recommendations
to
those
in
this
table
the
device-specific
recommendations
should
be
followed
if
a
manufacturer
is
unsure
they
should
utilize
the
fda
q-submission
process
appendix
terminology
the
terminology
listed
here
are
for
the
purposes
of
this
guidance
and
are
intended
for
use
in
the
context
of
assessing
medical
device
cybersecurity
these
terms
are
not
intended
to
be
applied
in
any
context
beyond
this
guidance
anomaly
any
condition
that
deviates
from
the
expected
behavior
based
on
user
needs
requirements
specifications
design
documents
or
standards
asset
anything
that
has
value
to
an
individual
or
an
organization
attack
surface
analysis
evaluation
of
attack
surface
to
determine
all
avenues
of
ingress
and
egress
to
and
from
a
system
including
common
vulnerabilities
and
exposed
ports
and
services
authentication
the
act
of
verifying
the
identity
of
a
user
process
or
device
as
a
prerequisite
to
allowing
access
to
the
device
its
data
information
or
systems
or
provision
of
assurance
that
a
claimed
characteristic
of
an
entity
is
correct
authenticity
information
hardware
or
software
having
the
property
of
being
genuine
and
being
able
to
be
verified
and
trusted
confidence
that
the
contents
of
a
message
originate
from
the
expected
party
and
has
not
been
modified
during
transmission
or
storage
authorization
the
right
or
a
permission
that
is
granted
to
a
system
entity
to
access
a
system
resource
availability
the
property
of
data
information
and
information
systems
to
be
accessible
and
usable
on
a
timely
basis
in
the
expected
manner
i
e
the
assurance
that
information
will
be
available
when
needed
boundary
analysis
the
process
of
uniquely
assigning
information
resources
to
an
information
system
which
defines
the
security
boundary
for
that
system
closed
box
testing
a
method
of
software
testing
that
examines
the
functionality
of
an
application
without
peering
into
its
internal
structures
of
workings
definition
is
adapted
from
iso
iec
information
technology
security
techniques
guidelines
for
cybersecurity
clause
definition
is
adapted
from
ansi
isa
definition
is
adapted
from
nist
fips
minimum
security
requirements
for
federal
information
and
information
systems
and
from
iso
iec
e
information
technology
security
techniques
time
stamping
services
part
mechanisms
producing
independent
tokens
clause
definition
is
adapted
from
nist
sp
security
and
privacy
controls
for
federal
information
systems
and
organizations
definition
is
adapted
from
cnssi
committee
on
national
security
systems
cnss
glossary
definition
is
adapted
from
iso
iec
clause
and
cnssi
cnss
glossary
definition
is
adapted
from
nist
special
publication
revision
guide
for
developing
security
plans
for
federal
information
systems
definition
is
adapted
from
cnssi
cnss
glossary
compensating
controls
a
safeguard
or
countermeasure
deployed
in
lieu
of
or
in
the
absence
of
controls
designed
in
by
a
device
manufacturer
these
controls
are
external
to
the
device
design
configurable
in
the
field
employed
by
a
user
and
provide
supplementary
or
comparable
cyber
protection
for
a
medical
device
confidentiality
the
property
of
data
information
or
system
structures
to
be
accessible
only
to
authorized
persons
and
entities
and
are
processed
at
authorized
times
and
in
the
authorized
manner
thereby
helping
ensure
data
and
system
security
confidentiality
provides
the
assurance
that
no
unauthorized
users
i
e
only
trusted
users
have
access
to
the
data
information
or
system
structures
configuration
the
possible
conditions
parameters
and
specifications
with
which
a
device
or
system
component
can
be
described
or
arranged
configuration
management
a
collection
of
activities
focused
on
establishing
and
maintaining
the
integrity
of
information
technology
products
and
information
systems
through
control
of
processes
for
initializing
changing
and
monitoring
the
configurations
of
those
products
and
systems
throughout
the
system
development
lifecycle
cryptography
the
discipline
that
embodies
the
principles
means
and
methods
for
providing
information
security
including
confidentiality
data
integrity
non-repudiation
and
authenticity
cybersecurity
the
process
of
preventing
unauthorized
access
modification
misuse
or
denial
of
use
or
the
unauthorized
use
of
information
that
is
stored
accessed
or
transferred
from
a
medical
device
to
an
external
recipient
decommission
a
process
in
the
disposition
process
that
includes
proper
identification
authorization
for
disposition
and
sanitization
of
the
equipment
as
well
as
removal
of
patient
health
information
phi
or
software
or
both
decryption
is
the
cryptographic
transformation
of
encrypted
data
called
ciphertext
into
non-encrypted
form
called
plaintext
disposal
a
process
to
end
the
existence
of
a
system
asset
or
system
for
a
specified
intended
use
appropriately
handle
replaced
or
retired
assets
and
to
properly
attend
to
identified
critical
definition
is
adapted
from
nist
special
publication
assessing
security
and
privacy
controls
in
federal
information
systems
and
organizations
nist
sp
800-53a
rev
definition
is
adapted
from
iso
iec
clause
property
that
information
is
not
made
available
or
disclosed
to
unauthorized
individuals
entities
or
processes
definition
is
adapted
from
nist
sp
guide
for
security-focused
configuration
management
of
information
systems
definition
is
adapted
from
nist
sp
rev
definition
is
adapted
from
cnssi
cnss
glossary
definition
is
adapted
from
iso
iec
clause
definition
is
adapted
from
medical
device
and
health
it
joint
security
plan
jsp
definition
is
cited
from
nist
sp
guide
to
industrial
control
systems
ics
security
disposal
needs
e
g
per
an
agreement
per
organizational
policy
or
for
environmental
legal
safety
security
aspects
encryption
is
the
cryptographic
transformation
of
data
called
plaintext
into
a
form
called
ciphertext
that
conceals
the
data's
original
meaning
to
prevent
it
from
being
known
or
used
end
of
support
a
point
beyond
which
the
product
manufacturer
ceases
to
provide
support
which
may
include
cybersecurity
support
for
a
product
or
service
exploitability
the
feasibility
or
ease
and
technical
means
by
which
the
vulnerability
can
be
exploited
by
a
threat
firmware
software
program
or
set
of
instructions
programmed
on
the
flash
read-only
memory
rom
of
a
hardware
device
it
provides
the
necessary
instructions
for
how
the
device
communicates
with
the
other
computer
hardware
fuzz
testing
process
of
creating
malformed
or
unexpected
data
or
call
sequences
to
be
consumed
by
the
entity
under
test
to
verify
that
they
are
handled
appropriately
hardening
a
process
intended
to
eliminate
a
means
of
attack
by
patching
vulnerabilities
and
turning
off
nonessential
services
hardening
when
applied
to
computing
is
the
practice
of
reducing
a
system's
vulnerability
by
reducing
its
attack
surface
hardening
may
involve
a
reduction
in
attack
vectors
by
culling
the
pathways
or
vectors
attackers
would
use
e
g
patching
vulnerabilities
and
turning
off
nonessential
services
hardware
the
material
physical
components
of
an
information
system
integrity
the
property
of
data
information
and
software
to
be
accurate
and
complete
and
have
not
been
improperly
or
maliciously
modified
lifecycle
all
phases
in
the
life
of
a
medical
device
from
initial
conception
to
final
decommissioning
and
disposal
malware
software
or
firmware
intended
to
perform
an
unauthorized
process
that
will
have
adverse
impact
on
the
confidentiality
integrity
or
availability
of
an
information
system
definition
is
adapted
from
disposal
process
purpose
iso
iec
ieee
e
definition
is
cited
from
nist
sp
guide
to
ics
security
definition
is
adapted
from
the
common
vulnerability
scoring
system
cvss
specification
document
v3
definition
is
adapted
from
nistir
https
nvlpubs
nist
gov
nistpubs
ir
nist
ir
pdf
definition
is
cited
from
ansi
isa
definition
is
cited
from
nist
sp
definition
is
cited
from
cnssi
cnss
glossary
definition
is
adapted
from
aami
tir
clause
definition
is
cited
from
ansi
aami
iso
medical
devices
application
of
risk
management
to
medical
devices
definition
is
cited
from
nist
sp
rev
patch
a
repair
job
for
a
piece
of
programming
also
known
as
a
fix
a
patch
is
the
immediate
solution
to
an
identified
problem
that
is
provided
to
users
the
patch
is
not
necessarily
the
best
solution
for
the
problem
and
the
product
developers
often
find
a
better
solution
to
provide
when
they
package
the
product
for
its
next
release
a
patch
is
usually
developed
and
distributed
as
a
replacement
for
or
an
insertion
in
compiled
code
that
is
in
a
binary
file
or
object
module
in
many
operating
systems
a
special
program
is
provided
to
manage
and
track
the
installation
of
patches
patient
harm
injury
or
damage
to
the
health
of
patients
including
death
programmable
logic
hardware
that
has
undefined
function
at
the
time
of
manufacture
and
must
be
programmed
with
software
to
function
e
g
field-programmable
gate
array
reasonably
foreseeable
misuse
use
of
a
product
or
system
in
a
way
not
intended
by
the
manufacturer
but
which
can
result
from
readily
predictable
human
behavior
resilience
the
ability
of
an
information
system
to
continue
to
i
operate
under
adverse
conditions
or
stress
even
if
in
a
degraded
or
debilitated
state
while
maintaining
essential
operational
capabilities
and
ii
recover
to
an
effective
operational
posture
in
a
time
frame
consistent
with
mission
needs
secure
product
development
framework
spdf
a
set
of
processes
that
reduce
the
number
and
severity
of
vulnerabilities
in
products
additional
information
about
an
spdf
and
its
implementation
is
discussed
in
section
iv
c
and
throughout
the
guidance
security
architecture
a
set
of
physical
and
logical
security-relevant
representations
i
e
views
of
system
architecture
that
conveys
information
about
how
the
system
is
partitioned
into
security
domains
and
makes
use
of
security-relevant
elements
to
enforce
security
policies
within
and
between
security
domains
based
on
how
data
and
information
must
be
protected
the
security
architecture
reflects
security
domains
the
placement
of
security-relevant
elements
within
the
security
domains
the
interconnections
and
trust
relationships
between
the
security
relevant
elements
and
the
behavior
and
interactions
between
the
security-relevant
elements
definition
is
adapted
from
nist
sp
version
patient
harm
from
cybersecurity
risks
is
discussed
at
length
throughout
this
guidance
and
the
fda
guidance
postmarket
management
of
cybersecurity
in
medical
devices
available
at
https
www
fda
gov
regulatory
information
search-fda-guidance-documents
postmarket-management-cybersecurity-medical-devices
definition
is
adapted
from
iso
definition
is
cited
from
nistsp
rev
definition
of
information
system
resilience
the
term
secure
product
development
framework
was
developed
for
the
purposes
of
this
guidance
to
help
reflect
and
encompass
the
concepts
related
to
secure
development
lifecycles
and
frameworks
while
the
term
spdf
is
new
the
concepts
around
secure
product
development
and
risk
management
are
not
new
and
align
with
expectations
in
the
quality
system
and
labeling
regulations
as
cybersecurity
continues
to
evolve
fda
continues
to
align
its
terminology
to
reflect
best
practices
definition
is
cited
from
nist
800-160v1
systems
security
engineering
security
strength
a
measure
of
the
computational
complexity
associated
with
recovering
certain
secret
and
or
security-critical
information
concerning
a
given
cryptographic
algorithm
from
known
data
e
g
plaintext
ciphertext
pairs
for
a
given
encryption
algorithm
throughout
this
guidance
strong
and
other
iterations
of
this
term
may
be
used
that
apply
to
this
definition
security
risk
management
a
process
or
processes
that
evaluates
and
controls
threat-based
risks
for
security
risk
management
this
includes
an
evaluation
of
the
impact
of
exploitation
on
the
device's
safety
and
effectiveness
the
exploitability
and
the
severity
of
patient
harm
if
exploited
software
bill
of
materials
sbom
a
formal
inventory
of
software
components
and
dependencies
information
about
those
components
and
their
hierarchical
relationships
the
software
components
in
an
sbom
include
but
are
not
limited
to
commercial
open
source
off
the-shelf
and
custom
software
components
see
section
v
a
for
a
more
complete
description
of
an
sbom
system
the
combination
of
interacting
elements
or
assets
organized
to
achieve
one
or
more
function
threat
threat
is
any
circumstance
or
event
with
the
potential
to
adversely
impact
the
device
organizational
operations
including
mission
functions
image
or
reputation
organizational
assets
individuals
or
other
organizations
through
an
information
system
via
unauthorized
access
destruction
disclosure
modification
of
information
and
or
denial
of
service
threats
exercise
vulnerabilities
which
may
impact
the
safety
or
effectiveness
of
the
device
threat
modeling
a
methodology
for
optimizing
system
product
network
application
and
connection
security
by
identifying
objectives
and
vulnerabilities
and
then
defining
countermeasures
to
prevent
or
mitigate
the
effects
of
threats
to
the
system
trustworthy
device
a
medical
device
that
is
reasonably
secure
from
cybersecurity
intrusion
and
misuse
provides
a
reasonable
level
of
availability
and
reliability
is
reasonably
suited
to
performing
its
intended
functions
and
adheres
to
generally
accepted
security
procedures
to
support
correct
operation
uncontrolled
risk
when
there
is
unacceptable
residual
risk
of
patient
harm
due
to
inadequate
compensating
controls
and
risk
mitigations
definition
is
cited
from
nist
sp
definition
is
adapted
from
ntia's
framing
software
component
transparency
establishing
a
common
software
bill
of
materials
sbom
available
at
https
www
ntia
gov
files
ntia
publications
ntia
sbom
framing
2nd
edition
pdf
definition
is
adapted
from
iso
iec
ieee
definition
is
adapted
from
nist
sp
definition
is
adapted
from
cnssi
cnss
glossary
definition
is
adapted
from
nist
sp
introduction
to
public
key
technology
and
the
federal
pki
infrastructure
unresolved
anomaly
a
defect
that
still
resides
in
the
software
because
a
sponsor
deemed
it
appropriate
not
to
correct
or
fix
the
anomaly
according
to
a
risk-based
rationale
about
its
impact
to
the
device's
safety
and
effectiveness
updatability
and
patchability
the
ease
and
timeliness
with
which
a
device
and
related
assets
can
be
changed
for
any
reason
e
g
feature
update
security
patch
hardware
replacement
update
corrective
preventative
adaptive
or
perfective
modifications
made
to
software
of
a
medical
device
vulnerability
a
weakness
in
an
information
system
system
security
procedure
s
internal
control
s
human
behavior
or
implementation
that
could
be
exploited
vulnerability
chaining
the
sequential
exploit
of
multiple
vulnerabilities
in
order
to
attack
to
attack
a
system
where
one
or
more
exploits
at
the
end
of
the
chain
require
the
successful
completion
of
prior
exploits
in
order
to
be
exploited
definition
is
consistent
with
the
premarket
software
guidance
available
at
https
www
fda
gov
regulatory
information
search-fda-guidance-documents
guidance-content-premarket-submissions-software-contained-medical
devices
even
though
we
use
the
terms
differently
definition
is
cited
from
imdrf
guidance
principles
and
practices
for
medical
device
cybersecurity
available
at
http
www
imdrf
org
docs
imdrf
final
technical
imdrf-tech-200318-pp-mdc-n60
pdf
definition
is
adapted
from
the
common
vulnerability
scoring
system
cvss
specification
document
v3
