cybersecurity
in
medical
devices
quality
management
system
considerations
and
content
of
premarket
submissions
guidance
for
industry
and
food
and
drug
administration
staff
document
issued
on
february
this
document
supersedes
cybersecurity
in
medical
devices
quality
system
considerations
and
content
of
premarket
submissions
issued
june
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
industry
biologics
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
office
of
communication
outreach
and
development
ocod
center
for
biologics
evaluation
and
research
cber
food
and
drug
administration
by
calling
or
by
email
industry
biologics
fda
hhs
gov
or
from
the
internet
at
https
www
fda
gov
vaccines-blood-biologics
guidance-compliance-regulatoryinformation-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
management
system
regulation
qmsr
a
secure
product
development
framework
spdf
may
be
one
way
to
satisfy
the
qmsr
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
vii
cyber
devices
a
who
is
required
to
comply
with
section
524b
of
the
fd
c
act
b
devices
subject
to
section
524b
of
the
fd
c
act
c
documentation
recommendations
to
comply
with
section
524b
of
the
fd
c
act
plans
and
procedures
section
524b
b
design
develop
and
maintain
processes
and
procedures
to
provide
a
reasonable
assurance
of
cybersecurity
section
524b
b
d
e
software
bill
of
materials
sbom
section
524b
b
modifications
changes
that
may
impact
cybersecurity
changes
unlikely
to
impact
cybersecurity
reasonable
assurance
of
cybersecurity
of
cyber
devices
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
management
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
devicerelated
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
cyber
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
incidents
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
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
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
is
applicable
to
devices
with
cybersecurity
considerations
including
but
not
limited
to
devices
that
include
a
device
software
function1
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
furthermore
this
guidance
applies
to
all
types
of
devices
within
the
meaning
of
section
h
of
the
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
product2
such
as
drug-device
and
biologic-device
combination
products
when
the
for
the
purposes
of
this
guidance
device
software
function
means
a
software
function
that
meets
the
definition
of
a
device
in
section
h
of
the
federal
food
drug
and
cosmetic
act
fd
c
act
for
the
purposes
of
this
guidance
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
multiple
function
device
products
policy
and
considerations
cfr
e
device
constituent
part
presents
cybersecurity
considerations
including
but
not
limited
to
devices
that
include
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
interested
parties
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
wannacry5
ransomware6
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
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
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
for
more
information
on
the
wannacry
ransomware
attack
see
indicators
associated
with
wannacry
ransomware
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
ransomware
for
more
information
see
fda's
cybersecurity
webpage
for
more
information
see
fda's
sweyntooth
cybersecurity
vulnerabilities
may
affect
certain
medical
devices
fda
safety
communication
for
more
information
on
the
german
hospital
ransomware
attack
see
the
untold
story
of
a
cyberattack
a
hospital
and
a
dying
woman
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
reduces
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
fda
issued
a
final
rule11
amending
the
device
current
good
manufacturing
practice
cgmp
requirements
of
the
quality
system
qs
regulation
under
cfr
to
align
more
closely
with
the
international
consensus
standard
for
quality
management
systems
qms
for
medical
devices
used
by
many
other
regulatory
authorities
around
the
world
this
revised
part
is
referred
to
as
the
quality
management
system
regulation
qmsr
the
qmsr
incorporates
by
reference
the
edition
of
iso
by
incorporating
iso
by
reference
we
are
explicitly
requiring
current
internationally
recognized
regulatory
expectations
for
qms
for
devices
subject
to
fda's
jurisdiction
of
particular
note
for
this
guidance
iso
incorporated
into
the
qmsr
by
reference
incorporates
risk
management
throughout
its
requirements
the
recommendations
contained
in
this
guidance
are
intended
to
supplement
fda's
postmarket
cybersecurity
guidance
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
in
march
see
appendix
terminology
see
fr
this
final
rule
took
effect
on
february
and
amends
the
majority
of
the
requirements
previously
in
cfr
part
part
and
incorporates
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
the
final
rule
the
requirements
in
iso
are
when
taken
in
totality
substantially
similar
to
the
requirements
of
the
previous
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
all
references
to
iso
in
this
guidance
are
to
iso
medical
devices
quality
management
systems
requirements
for
regulatory
purposes
see
fr
at
additionally
section
of
the
food
and
drug
omnibus
reform
act
of
fdora
enacted
on
december
added
section
524b
ensuring
cybersecurity
of
medical
devices
to
the
fd
c
act
effective
march
with
respect
to
premarket
submissions
for
cyber
devices
section
524b
a
provides
that
sponsors
must
include
information
to
ensure
the
device
meets
the
cybersecurity
requirements
under
section
524b
b
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
is
required
to
submit
information
to
ensure
that
cyber
devices
meet
the
cybersecurity
requirements
under
section
524b
b
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
see
section
vii
b
for
more
information
on
the
term
cyber
device
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
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
management
system
regulation
qmsr
device
manufacturers
must
establish
and
follow
quality
management
systems
to
help
ensure
that
their
products
consistently
meet
applicable
requirements
and
specifications
the
quality
management
systems
requirements
are
found
in
the
qmsr
in
cfr
part
which
incorporates
by
reference
iso
depending
on
the
device
qms
requirements
may
be
relevant
at
the
premarket
stage
postmarket
stage
or
both
while
section
524b
b
of
the
fd
c
act
authorizes
fda
to
promulgate
additional
cybersecurity
requirements
via
regulation
fda
is
not
required
to
promulgate
a
regulation
to
elaborate
on
the
new
requirements
specified
in
section
524b
of
the
fd
c
act
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
in
the
postmarket
context
design
and
development
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
qmsr
including
but
not
limited
to
complaint
handling
iso
subclause
and
cfr
a
quality
audit
subclause
analysis
of
data
and
improvement
subclauses
and
software
validation
subclause
risk
management
subclause
and
servicing
subclause
and
cfr
b
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
ongoing
requirements
of
the
qmsr
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
qmsr
compliance
can
also
be
used
to
show
how
a
sponsor
or
manufacturer
is
addressing
cybersecurity
considerations
relevant
to
a
device
for
example
cfr
c
requires
that
for
all
classes
of
devices
automated
with
software
a
manufacturer
must
comply
with
the
requirements
in
design
and
development
clause
and
its
subclauses
of
iso
as
part
of
design
and
development
d
esign
and
development
validation
shall
be
performed
in
accordance
with
planned
and
documented
arrangements
to
ensure
that
the
resulting
product
is
capable
of
meeting
the
requirements
for
the
specified
application
or
intended
use
subclause
design
and
development
validation
includes
validation
of
device
software
in
addition
subclause
of
iso
specifies
that
the
organization
shall
document
one
or
more
processes
for
risk
management
in
product
realization
as
part
of
the
software
validation
required
by
subclause
and
risk
management
including
the
requirements
of
subclause
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
discussed
in
iso
regarding
design
and
development
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
qmsr
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
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
recommendations
in
this
guidance
are
not
intended
to
suggest
that
fda
will
evaluate
an
applicant's
compliance
with
the
qmsr
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
qmsr
compliance
and
explain
how
the
qmsr
can
be
leveraged
to
demonstrate
these
performance
outputs
references
to
clauses
and
subclauses
in
this
guidance
are
to
clauses
and
subclauses
of
iso
unless
otherwise
specified
see
subclause
of
iso
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
management
system
at
large
using
an
spdf
is
one
approach
to
help
ensure
that
the
qmsr
is
met
because
of
its
benefits
in
helping
comply
with
the
qmsr
and
cybersecurity
fda
encourages
manufacturers
to
use
an
spdf
but
other
approaches
might
also
satisfy
the
qmsr
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
ai
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
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
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
for
more
information
on
reasonably
foreseeable
misuse
see
the
imdrf
final
guidance
principles
and
practices
for
medical
device
cybersecurity
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
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
and
development
activities
should
result
submitters
should
consider
including
in
premarket
submissions
to
fda
documentation
generated
from
those
design
and
development
activities
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
including
but
not
limited
to
cyber
devices
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
of
the
fd
c
act
relating
to
ensuring
device
cybersecurity
is
considered
a
prohibited
act
under
section
q
of
the
fd
c
act
this
guidance
recommends
cybersecurity
information
be
included
in
submissions
based
on
cybersecurity
risks
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
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
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
of
the
fd
c
act
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
as
previously
discussed
section
524b
of
the
fd
c
act
requires
the
submission
of
certain
documentation
for
cyber
devices
see
section
vii
of
this
guidance
for
more
information
on
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
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
qmsr
including
iso
to
support
secure
product
development
and
maintenance
to
preserve
flexibility
for
manufacturers
manufacturers
may
use
other
existing
frameworks
that
satisfy
the
qmsr
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
jsp2
and
iec
frameworks
from
other
sectors
may
also
comply
with
the
qmsr
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
qmsr
and
the
documentation
fda
recommends
manufacturers
provide
for
review
as
part
of
premarket
submissions
these
recommendations
may
be
helpful
for
manufacturers
of
cyber
devices
that
must
design
develop
and
maintain
processes
and
procedures
to
provide
a
reasonable
assurance
that
the
device
and
related
systems
are
cybersecure
pursuant
to
section
524b
b
of
the
fd
c
act
see
section
vii
c
the
information
in
these
sections
does
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
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
see
the
medical
device
and
health
it
joint
security
plan
version
jsp2
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
jsp2
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
management
system
addressed
throughout
the
tplc
the
quality
management
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
and
ansi
aami
sw96
detail
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
qmsr
and
iso
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
iso
as
incorporated
by
reference
in
the
qmsr
that
may
be
relevant
in
this
context
include
but
are
not
limited
to
design
and
development
subclause
of
iso
production
processes
subclause
and
improvement
including
corrective
actions
and
preventive
actions
subclause
to
ensure
both
safety
and
security
risks
are
adequately
addressed
for
completeness
in
performing
risk
management
under
subclause
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
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
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
ansi
aami
sw96
standard
for
medical
device
security
security
risk
management
for
device
manufacturers
https
doi
org
ch1
describes
specific
requirements
for
managing
security
related
risk
across
the
total
product
life
cycle
utilizing
the
risk
management
framework
defined
by
iso
medical
devices
applications
of
risk
management
to
medical
devices
see
cfr
part
risk
assessment
and
be
assessed
for
additional
control
measures
or
risk
transfer31
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
reach
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
and
ansi
aami
sw96
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
aami
tir57
and
ansi
aami
sw96
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
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
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
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
and
ansi
aami
sw96
standard
for
medical
device
security
security
risk
management
for
device
manufacturers
https
doi
org
ch1
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
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
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
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
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
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
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
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
cisa's
known
exploited
vulnerabilities
catalog
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
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
interoperability
considerations
interoperability
is
an
important
consideration
when
assessing
the
cybersecurity
of
the
end-to-end
medical
device
system
as
identified
in
fda's
guidance
design
considerations
and
pre-market
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
fda's
guidance
multiple
function
device
products
policy
and
considerations
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
ensure
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
fda's
guidance
off-the-shelf
ots
software
use
in
medical
devices
medical
devices
commonly
include
third-party
software
components
including
off-the-shelf
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
and
development
under
subclause
of
iso
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
subclause
of
iso
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
and
development
files
required
by
subclause
and
medical
device
file
required
by
subclause
this
documentation
demonstrates
the
device's
overall
compliance
with
the
qmsr
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
the
use
of
component
in
this
guidance
is
consistent
with
the
definition
in
cfr
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
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
thirdparty
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
subclause
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
for
additional
information
see
the
department
of
commerce
national
telecommunications
and
information
administration's
multi-stakeholder
process
for
software
transparency
available
on
the
following
website
ntia
software
component
transparency
design
and
development
files
and
subclause
medical
device
file
of
iso
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
and
section
vii
c
of
this
guidance
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
document
off-the-shelf
ots
software
use
in
medical
devices
describes
information
that
should
be
provided
in
premarket
submissions
for
software
components
for
which
a
manufacturer
cannot
claim
complete
software
lifecycle
control
in
addition
to
the
information
recommended
in
that
guidance
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
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
anomaly
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
subclause
of
iso
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
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
cybersecurity
risk
assessment
can
be
used
to
quickly
identify
vulnerability
impacts
once
a
device
is
released
and
when
appropriate
to
support
timely
improvement
through
corrective
actions
and
preventive
actions
described
in
subclause
of
iso
examples
of
sw91
defect
classification
mapped
to
cwe
can
be
found
in
annex
d
of
aami
sw91
classification
of
defects
in
health
software
for
additional
information
on
cwe
categories
see
cwe
common
weakness
enumeration
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
qmsr
at
a
minimum
fda
recommends
tracking
the
following
measures
and
metrics
or
those
that
provide
equivalent
information
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
process42
includes
both
high-level
definitions
of
the
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
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
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
subclause
of
iso
requires
manufacturers
to
document
procedures
for
design
and
development
under
subclause
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
maintained
and
updated
as
design
and
development
progresses
subclause
under
subclause
a
manufacturer
must
determine
and
maintain
inputs
related
to
product
requirements
to
ensure
that
the
design
requirements
relating
to
a
device
are
appropriate
and
address
the
intended
use
of
the
device
under
subclause
design
and
development
outputs
must
be
in
a
form
suitable
for
verification
against
the
design
and
development
inputs
and
records
must
be
maintained
subclause
also
states
that
design
and
development
outputs
shall
contain
or
make
reference
to
product
acceptance
criteria
and
shall
ensure
that
those
design
outputs
that
are
essential
for
its
safe
and
proper
use
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
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
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
disruptions
hazards
and
threats
for
additional
information
see
nist
vol
rev
https
doi
org
nist
sp
800-160v1r1
views
are
discussed
in
more
detail
in
the
following
subsections
and
appendix
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
and
development
inputs
for
cybersecurity
controls
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
riskbased
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
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
version
jsp2
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
and
development
activities
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
and
development
are
discussed
in
the
security
architecture
views
section
below
security
architecture
views
in
addition
to
the
design
and
development
requirements
subclause
of
iso
requires
that
manufacturers
establish
and
maintain
procedures
for
implementing
improvement
including
corrective
action
and
preventive
action
the
requirements
under
subclause
for
analyzing
quality
data
to
identify
existing
and
potential
causes
of
quality
problems
are
used
to
determine
the
need
for
improvement
under
subclause
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
for
more
information
see
fda's
guidance
requests
for
feedback
and
meetings
for
medical
device
submissions
the
q-submission
program
see
subclause
of
iso
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
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
and
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
nondevice
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
and
development
activities
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
subclause
of
iso
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
subclause
a
manufacturer
must
establish
and
maintain
procedures
for
validating
its
device
design
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
described
in
ansi
isa
and
manufacturers
should
provide
details
and
evidence47
of
the
following
testing
and
analyses
abuse
or
misuse
cases
malformed
and
unexpected
inputs
robustness
fuzz
testing
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
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
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
cybersecurity
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
manufacturers
of
cyber
devices
should
consider
the
recommendations
in
this
section
as
they
design
develop
and
maintain
processes
and
procedures
to
provide
a
reasonable
assurance
that
the
device
and
related
systems
are
cybersecure
section
524b
b
of
the
fd
c
act
see
section
vii
c
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
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
health
software
and
health
it
systems
safety
effectiveness
and
security
part
security
activities
in
the
product
life
cycle
additional
standards
may
also
meet
or
partially
meet
the
testing
recommendations
outlined
in
this
section
users
often
manage
security
risks
in
medical
device
systems
by
an
end
user
or
within
a
larger
risk
management
framework
like
the
nist
csf
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
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
see
fda's
guidance
applying
human
factors
and
usability
engineering
to
medical
devices
for
more
information
regarding
fda's
policy
on
labeling
changes
and
submission
requirements
manufacturers
can
use
the
search
for
fda
guidance
documents
tool
to
identify
relevant
guidance
documents
for
their
product
and
submission
type
see
iec
tr
application
of
risk
management
for
it-networks
incorporating
medical
devices
the
relevant
parts
covering
communication
of
medical
device
security
needs
risks
and
controls
iec
tr
application
of
risk
management
for
it-networks
incorporating
medical
devices
the
relevant
parts
covering
standards
for
establishing
the
security
capabilities
identified
in
iec
and
iec
tr
application
of
risk
management
for
it-networks
incorporating
medical
devices
the
relevant
parts
covering
use
of
security
assurance
cases
to
demonstrate
confidence
in
iec
tr
security
capabilities
for
further
labeling
information
for
compliance
with
these
standards
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
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
userconfigurable
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
preestablished
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
version
jsp2
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
the
relevant
parties
the
vulnerabilities
that
are
identified
after
releasing
the
device
in
accordance
with
subclause
and
subclause
of
iso
and
cfr
part
as
appropriate
this
plan
can
also
support
security
risk
management
processes
that
are
described
throughout
the
qmsr
and
iso
as
incorporated
by
reference
in
the
qmsr
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
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
and
section
vii
c
of
this
guidance
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's
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
vii
cyber
devices
this
section
identifies
the
cybersecurity
information
fda
considers
to
generally
be
necessary
to
support
obligations
under
section
524b
of
the
fd
c
act
for
cyber
devices
this
section
provides
recommendations
specifically
for
cyber
devices
manufacturers
of
cyber
devices
should
also
consider
the
recommendations
throughout
this
guidance
to
help
meet
their
obligations
under
section
524b
a
who
is
required
to
comply
with
section
524b
of
the
fd
c
act
under
section
524b
a
of
the
fd
c
act
a
person
including
a
manufacturer
who
submits
a
premarket
application
or
submission
under
any
of
the
following
pathways
k
pma
pdp
de
novo
or
hde56
for
a
device
that
meets
the
definition
of
a
cyber
device
as
defined
in
section
524b
c
is
required
to
include
such
information
as
fda
may
require
to
ensure
that
the
cyber
device
meets
the
cybersecurity
requirements
under
section
524b
b
b
devices
subject
to
section
524b
of
the
fd
c
act
section
524b
of
the
fd
c
act
and
its
requirements
apply
to
cyber
devices
section
524b
c
defines
a
cyber
device
as
a
device
that
meets
all
of
the
following
criteria
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
informed
in
part
by
the
definitions
recognized
by
nist
for
the
term
software
fda
considers
a
cyber
device
to
include
devices
that
are
or
contain
software
including
software
that
is
firmware
or
programmable
logic
fda
also
considers
the
ability
to
connect
to
the
internet
to
include
devices
that
are
able
to
connect
to
the
internet
whether
intentionally
or
unintentionally
through
any
means
including
at
any
point
identified
in
the
evaluation
of
the
threat
surface58
of
the
device
and
the
environment
of
use
it
is
well-demonstrated
that
if
a
device
has
the
ability
to
connect
to
the
internet
it
is
possible
that
it
can
be
connected
to
the
internet
regardless
of
whether
such
connectivity
was
intended
by
the
device
sponsor
section
524b
a
of
the
fd
c
act
places
obligations
on
the
person
who
submits
a
specific
type
of
device
marketing
application
section
524b
b
of
the
fd
c
act
places
obligations
on
a
sponsor
for
the
purposes
of
this
guidance
we
assume
that
the
manufacturer
is
the
entity
submitting
the
application
and
use
the
term
accordingly
throughout
the
guidance
in
lieu
of
the
term
person
or
sponsor
however
if
another
person
submits
the
application
or
submission
enumerated
under
section
524b
a
of
the
fd
c
act
to
the
agency
that
person
should
follow
the
guidance
for
manufacturers
herein
whatever
person
submits
the
application
for
a
cyber
device
is
subject
to
the
requirements
of
section
524b
for
the
purposes
of
this
guidance
k
refers
to
the
original
special
and
abbreviated
k
submissions
for
the
purposes
of
this
guidance
pma
refers
to
the
original
pma
and
supplement
pmas
for
the
purposes
of
this
guidance
hde
refers
to
the
original
hde
and
supplement
hdes
nist
defines
a
programmable
logic
controller
plc
as
a
solid-state
control
system
that
has
a
userprogrammable
memory
for
storing
instructions
for
the
purpose
of
implementing
specific
functions
such
as
i
o
control
logic
timing
counting
three
mode
pid
control
communication
arithmetic
and
data
and
file
processing
a
plc
is
therefore
a
combination
of
two
components
the
hardware
controller
and
the
user-programmable
memory
or
programmable
logic
that
instructs
the
hardware
controller
to
execute
specified
functions
nist
defines
software
as
among
other
things
computer
programs
and
data
stored
in
hardware
typically
in
read
only
memory
or
programmable
read-only
memory
programmable
logic
is
therefore
a
specific
type
of
computer
program
and
or
data
stored
on
hardware
and
is
thus
a
type
of
software
see
the
nist
computer
security
resource
center
glossary
for
more
information
on
nist's
definitions
of
these
terms
for
the
purposes
of
this
guidance
threat
surface
is
synonymous
with
the
term
attack
surface
however
fda
uses
the
term
threat
surface
rather
than
attack
surface
because
cyber
threats
need
not
necessarily
be
an
attack
to
pose
a
risk
to
a
medical
device
and
its
related
system
for
more
information
see
wannacry
ransomware
encrypted
hospital
medical
devices
and
indicators
associated
with
wannacry
ransomware
update
i
fda
considers
devices
that
include
any
of
the
following
features
to
have
the
ability
to
connect
to
the
internet
the
list
below
is
illustrative
not
exhaustive
network
server
or
cloud
service
provider
connections
radio-frequency
communications
e
g
wi-fi
cellular
bluetooth
bluetooth
low
energy
magnetic
inductive
communications
and
hardware
connectors
capable
of
connecting
to
the
internet
e
g
usb
ethernet
serial
port
c
documentation
recommendations
to
comply
with
section
524b
of
the
fd
c
act
for
applicable
premarket
submission
types
manufacturers
must
provide
documentation
to
comply
with
the
requirements
under
section
524b
of
the
fd
c
act
recommendations
regarding
the
documentation
to
support
each
of
the
requirements
are
discussed
in
the
sections
below
plans
and
procedures
section
524b
b
section
524b
b
of
the
fd
c
act
requires
manufacturers
of
cyber
devices
to
submit
to
fda
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
in
their
premarket
submissions
we
recommend
that
the
plan
contain
the
information
recommended
for
the
cybersecurity
management
plan
described
in
section
vi
b
in
particular
such
a
plan
should
address
the
items
discussed
below
first
fda
considers
that
coordinated
vulnerability
disclosure
cvd
and
related
procedures
as
required
in
section
524b
b
of
the
fd
c
act
could
include
coordinated
disclosure
of
vulnerabilities
and
exploits
identified
by
external
entities
including
third-party
software
suppliers
and
researchers
disclosure
of
vulnerabilities
and
exploits
identified
by
the
manufacturer
of
cyber
devices
and
manufacturer
procedures
to
carry
out
disclosures
of
the
vulnerabilities
and
exploits
as
identified
above
for
example
magnetic
inductive
communication
allows
wireless
data
transmission
between
an
implantable
medical
device
and
an
external
programmer
a
transmitter
coil
in
the
external
programmer
sends
data
by
modulating
magnetic
fields
which
then
induces
an
electrical
current
in
the
receiver
coil
of
the
implantable
medical
device
the
induced
current
carries
encoded
data
which
allows
communication
between
the
external
programmer
and
the
implantable
medical
device
for
example
a
device
may
need
to
be
serviced
via
a
usb
connection
while
the
connection
may
be
brief
the
ability
to
connect
is
present
and
the
device
is
therefore
considered
to
have
the
ability
to
connect
to
the
internet
for
the
purposes
of
this
guidance
manufacturer
procedures
to
carry
out
disclosures
of
the
vulnerabilities
and
exploits
may
include
procedures
to
inform
device
users
customers
patients
and
other
relevant
healthcare
parties
second
plans
required
by
section
524b
b
of
the
fd
c
act
should
also
describe
the
timeline
with
associated
justifications
to
develop
and
release
required
updates
and
patches
section
524b
b
a
of
the
fd
c
act
requires
manufacturers
of
cyber
devices
to
make
available
updates
and
patches63
to
the
device
and
related
systems64
for
known
unacceptable
vulnerabilities
with
these
updates
and
patches
made
available
on
a
reasonably
justified
regular
cycle
a
known
unacceptable
vulnerability
in
section
524b
b
a
contrasts
with
a
critical
vulnerability
that
could
cause
uncontrolled
risks
in
section
524b
b
b
a
known
unacceptable
vulnerability
could
include
a
vulnerability
that
could
not
cause
uncontrolled
risks
a
vulnerability
that
is
not
currently
known
to
cause
uncontrolled
risks
or
a
vulnerability
that
could
present
controlled
risk
as
described
in
fda's
postmarket
cybersecurity
guidance
updates
and
or
patches
to
address
these
vulnerabilities
may
be
intended
to
maintain
the
supportability
of
software
generally
software
should
be
regularly
updated
to
maintain
the
supportability
of
the
software
for
examples
of
vulnerabilities
associated
with
controlled
risk
see
the
postmarket
cybersecurity
guidance
updates
and
patches
to
address
these
types
of
vulnerabilities
are
not
to
reduce
uncontrolled
risk
and
therefore
not
to
reduce
a
risk
to
health
or
to
correct
a
violation
of
the
fd
c
act
see
below
for
more
information
on
section
524b
b
b
of
the
fd
c
act
section
524b
b
b
of
the
fd
c
act
requires
manufacturers
of
cyber
devices
to
make
available
updates
and
patches
to
the
device
and
related
systems
to
address
as
soon
as
possible
out
of
cycle
critical
vulnerabilities
that
could
cause
uncontrolled
risks
in
general
this
includes
vulnerabilities
that
could
cause
uncontrolled
risks
as
described
in
fda's
postmarket
cybersecurity
guidance
for
examples
of
vulnerabilities
associated
with
uncontrolled
risks
see
the
postmarket
cybersecurity
guidance
an
update
is
defined
by
nist
as
a
patch
upgrade
or
other
modification
to
code
that
corrects
security
and
or
functionality
problems
in
software
see
nist
computer
security
resource
center
glossary
patches
are
defined
by
cisa
as
software
and
operating
system
os
updates
that
address
security
vulnerabilities
within
a
program
or
product
see
understanding
patches
and
software
updates
we
consider
an
update
or
patch
that
would
satisfy
the
requirements
under
section
524b
b
a
b
for
updates
or
patches
as
an
action
that
modifies
device
code
to
address
a
cyber
risk
for
the
purposes
of
this
guidance
we
refer
to
the
evaluation
of
related
systems
to
the
extent
needed
to
determine
that
the
device
as
it
interacts
with
related
systems
remains
cybersecure
related
systems
are
further
described
in
section
vii
c
below
the
justification
for
the
regular
cycle
should
typically
be
included
in
the
cybersecurity
management
plan
the
length
of
the
regular
cycle
may
vary
depending
on
numerous
factors
for
the
particular
device
one
of
the
primary
factors
that
may
influence
the
length
of
the
cycle
is
risk
for
example
an
interconnected
thermometer
whose
functionality
is
limited
to
taking
and
reporting
patient
temperature
may
have
lower
risk
of
harm
if
exploited
than
an
interconnected
surgery
robot
whose
risk
of
harm
may
be
significantly
higher
at
the
same
time
exploitation
of
a
seemingly
lower-risk
device
may
provide
opportunities
to
affect
other
devices
within
the
environment
of
use
leading
to
significantly
greater
risk
of
harm
if
these
other
devices
or
the
larger
environment
are
exploited
or
disrupted
manufacturers
should
fully
consider
the
risks
to
and
from
their
devices
within
the
larger
context
s
of
the
environment
s
in
which
they
will
be
intended
to
operate
and
design
and
deploy
regular
update
cycles
that
provide
a
reasonable
assurance
of
cybersecurity
for
example
a
manufacturer
may
make
updates
outside
of
the
planned
reasonably
justified
regular
cycle
to
remediate
an
uncontrolled
risk
third
we
recommend
that
manufacturers
of
cyber
devices
anticipate
and
make
appropriate
updates
to
these
plans
as
well
as
to
the
processes
and
procedures
discussed
in
section
vii
c
below
as
new
information
becomes
available
such
as
when
new
risks
threats
vulnerabilities
assets
or
adverse
impacts
are
discovered
throughout
the
total
product
lifecycle
to
support
such
efforts
manufacturers
should
also
create
or
update
appropriate
documentation
e
g
threat
modeling
cybersecurity
risk
assessment
and
maintain
it
throughout
the
device
lifecycle
doing
so
will
allow
manufacturers
to
quickly
identify
vulnerability
impacts
once
a
device
is
released
and
could
also
help
satisfy
the
patching
requirements
of
section
524b
b
a
b
of
the
fd
c
act
the
required
plans
as
well
as
the
processes
and
procedures
discussed
in
section
vii
c
below
also
should
as
appropriate
account
for
any
differences
in
the
risk
management
for
fielded
devices
e
g
differences
between
marketed
devices
and
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
the
differing
software
configurations
of
the
device
vulnerabilities
should
be
assessed
for
any
differing
impacts
for
all
fielded
versions
to
ensure
patient
risks
are
being
accurately
assessed
design
develop
and
maintain
processes
and
procedures
to
provide
a
reasonable
assurance
of
cybersecurity
section
524b
b
manufacturers
of
cyber
devices
must
design
develop
and
maintain
processes
and
procedures
to
provide
a
reasonable
assurance
that
the
device
and
related
systems
are
cybersecure
section
524b
b
of
the
fd
c
act
fda
considers
related
systems
to
include
among
other
things
manufacturer-controlled
elements
such
as
other
devices
software
that
performs
other
functions
as
described
in
fda's
guidance
multiple
function
device
products
policy
and
considerations
software
firmware
update
servers
and
connections
to
healthcare
facility
networks
in
the
design
development
and
maintenance
of
a
cyber
device
manufacturers
should
consider
the
cybersecurity
risks
of
related
systems
to
the
cyber
device
and
implement
appropriate
security
controls
to
mitigate
those
risks
the
documentation
recommendations
identified
in
this
guidance
and
summarized
in
appendix
should
be
considered
and
used
to
demonstrate
reasonable
assurance
that
the
device
and
related
systems
are
cybersecure
as
required
by
section
524b
b
software
bill
of
materials
sbom
section
524b
b
section
524b
b
of
the
fd
c
act
requires
manufacturers
of
cyber
devices
to
provide
an
sbom
including
commercial
open-source
and
off-the-shelf
software
components
to
assist
with
complying
with
this
requirement
we
recommend
that
a
cyber
device
provide
sboms
that
contain
the
information
recommended
in
section
v
a
b
see
section
524b
b
of
the
fd
c
act
see
section
524b
b
of
the
fd
c
act
see
section
524b
b
of
the
fd
c
act
see
section
524b
b
of
the
fd
c
act
d
modifications
as
previously
stated
the
requirements
under
section
524b
of
the
fd
c
act
apply
to
a
manufacturer
who
submits
an
application
or
submission
under
any
of
the
following
pathways
k
pma
pdp
de
novo
or
hde
for
a
device
that
meets
the
definition
of
a
cyber
device
therefore
a
manufacturer
required
to
submit
an
application
or
submission
under
one
of
the
enumerated
pathways
for
a
device
modification
would
also
need
to
comply
with
the
requirements
in
section
524b
of
the
fd
c
act
in
keeping
with
least
burdensome
principles
the
information
we
recommend
that
manufacturers
of
cyber
devices
provide
will
generally
differ
based
on
the
type
of
change
and
whether
such
change
impacts
the
cybersecurity
of
the
device
overall
we
recommend
that
manufacturers
use
the
recommendations
below
to
determine
the
information
fda
recommends
manufacturers
of
cyber
devices
provide
to
demonstrate
they
have
met
the
new
requirements
under
section
524b
when
submitting
a
premarket
submission
for
a
device
modification
changes
that
may
impact
cybersecurity
in
general
changes
that
may
impact
cybersecurity
and
may
require
premarket
submission
could
include
changes
to
authentication
or
encryption
algorithms
new
connectivity
features
or
changing
software
update
process
mechanisms
for
these
types
of
changes
see
section
vii
c
for
required
and
recommended
documentation
to
be
included
with
each
premarket
submission
see
section
524b
of
the
fd
c
act
changes
unlikely
to
impact
cybersecurity
in
general
changes
unlikely
to
impact
cybersecurity
could
include
changes
in
materials
sterilization
method
changes
or
a
change
to
an
algorithm
without
change
to
architecture
software
structure
connectivity
for
these
types
of
changes
fda
recommends
that
manufacturers
of
cyber
devices
provide
the
following
information
to
meet
their
premarket
submission
requirements
in
section
524b
of
the
fd
c
act
524b
b
if
not
previously
provided
manufacturers
must
provide
a
plan
as
described
in
section
524b
b
of
the
fd
c
act
we
recommend
that
it
contain
the
information
as
described
in
section
vii
c
above
if
a
plan
described
in
section
vii
c
above
was
previously
provided
the
manufacturer
should
provide
a
reference
to
the
prior
submission
and
a
summary
of
any
changes
to
the
plan
for
more
information
on
when
to
submit
an
application
for
a
device
modification
see
other
fda
guidances
including
deciding
when
to
submit
a
k
for
a
software
change
to
an
existing
device
and
modifications
to
devices
subject
to
premarket
approval
pma
the
pma
supplement
decision-making
process
for
more
information
on
fda's
least
burdensome
provisions
see
fda's
guidance
the
least
burdensome
provisions
concept
and
principles
524b
b
instead
of
the
full
documentation
described
as
required
or
recommended
in
section
vii
c
above
manufacturers
may
provide
the
following
information
o
description
of
whether
there
are
currently
any
critical
vulnerabilities
that
could
cause
uncontrolled
risks
o
description
of
whether
any
vulnerabilities
with
uncontrolled
risk
were
remediated
in
the
device
since
the
last
authorization
if
so
manufacturers
should
describe
how
remediation
was
performed
following
the
recommendations
in
fda's
postmarket
cybersecurity
guidance
524b
b
section
524b
b
of
the
fd
c
act
requires
manufacturers
of
cyber
devices
to
provide
an
sbom
including
commercial
open-source
and
off-the-shelf
software
components
to
assist
with
complying
with
this
requirement
we
recommend
that
a
manufacturer
of
a
cyber
device
provide
an
sbom
that
contains
the
information
recommended
in
section
v
a
b
above
in
general
in
its
cybersecurity
review
fda
intends
to
focus
substantive
review
on
modifications
to
cybersecurity
controls
or
modifications
that
are
likely
to
affect
cybersecurity
however
regardless
of
the
type
of
change
being
proposed
to
the
device
in
the
premarket
submission
fda
intends
to
take
into
account
known
cybersecurity
concerns
that
are
applicable
to
such
device
when
conducting
its
premarket
reviews
and
in
determining
whether
the
device
has
a
reasonable
assurance
of
cybersecurity
e
reasonable
assurance
of
cybersecurity
of
cyber
devices
section
c
of
fdora
provides
that
nothing
in
section
524b
of
the
fd
c
act
shall
be
construed
to
affect
the
secretary's
authority
related
to
ensuring
that
there
is
a
reasonable
assurance
of
the
safety
and
effectiveness
of
devices
which
may
include
ensuring
that
there
is
a
reasonable
assurance
of
the
cybersecurity
of
certain
cyber
devices
fda
interprets
this
provision
to
mean
that
a
reasonable
assurance
of
cybersecurity
can
be
part
of
fda's
determination
of
a
device's
safety
and
effectiveness
moreover
a
determination
that
there
is
a
reasonable
assurance
of
cybersecurity
is
relevant
to
the
various
premarket
pathways
and
authorization
under
them
specifically
fda's
review
of
a
k
pma
pdp
de
novo
and
hde
with
the
exponential
growth
of
interconnected
devices
on
the
market
over
the
past
few
years
see
section
i
ensuring
cybersecurity
has
become
essential
to
fda's
ability
to
protect
the
public
health
and
provide
reasonable
assurance
of
safety
and
effectiveness
of
devices
when
evaluating
a
k
submission
fda
considers
changes
to
the
environment
of
use
e
g
changes
in
technology
the
subject
device
will
interact
with
or
operate
within
and
any
new
risks
section
524b
b
b
of
the
fd
c
act
requires
manufacturers
to
make
available
postmarket
updates
and
patches
to
the
cyber
device
and
related
systems
to
address
as
soon
as
possible
out
of
cycle
critical
vulnerabilities
that
could
cause
uncontrolled
risks
among
other
requirements
see
section
vii
c
for
more
information
on
critical
vulnerabilities
that
could
cause
uncontrolled
risks
or
vulnerabilities
the
device
will
be
exposed
to
new
risks
or
vulnerabilities
in
the
technological
characteristics
compared
to
the
predicate
device
submission
e
g
changes
to
level
of
support
for
component
software
vulnerabilities
in
communication
protocols
or
technology
used
by
the
subject
device
and
how
the
subject
device
design
and
or
performance
testing
e
g
see
the
cybersecurity
testing
recommendations
in
section
v
c
address
these
new
risks
or
vulnerabilities
for
example
if
in
reviewing
the
k
for
an
alarm
for
a
central
nursing
station
software
fda
identifies
that
the
device
has
increased
risks
compared
to
its
predicate
because
it
does
not
have
the
necessary
encryption
to
protect
against
a
recently
identified
cyber
threat
fda
may
ask
for
additional
performance
data
e
g
see
the
documentation
recommendations
in
section
v
if
the
data
provided
is
inadequate
fda
would
likely
make
a
determination
that
the
new
device
is
not
substantially
equivalent
nse
to
the
predicate
device
because
this
threat
if
exploited
could
negatively
impact
the
safety
and
effectiveness
of
the
device
because
alarm
accuracy
is
essential
for
healthcare
providers
to
effectively
monitor
the
health
of
patients
in
a
hospital
for
more
information
about
current
review
practices
for
k
submission
see
fda's
guidance
the
k
program
evaluating
substantial
equivalence
in
premarket
notifications
k
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
information75
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
reverseengineered
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
strong76
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
privileges77
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
aami
tir57
or
ansi
aami
sw96
and
associated
supporting
justification
and
as
evidenced
through
security
testing
for
example
a
medical
device
programmer
that
is
capable
of
nearfield
communications
nfc
could
have
elevated
privileges
that
are
granted
based
on
a
signal
of
intent78
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
the
nist
computer
security
resource
center
glossary
defines
least
privilege
as
a
security
principle
that
a
system
should
restrict
the
access
privileges
of
users
or
processes
acting
on
behalf
of
users
to
the
minimum
necessary
to
accomplish
assigned
tasks
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
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
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
see
nist
fips
security
requirements
for
cryptographic
modules
https
doi
org
nist
fips
products
and
should
be
avoided
as
part
of
the
key
generation
process
e
g
publickey
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
cyber
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
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
for
more
information
regarding
udi
see
fda's
webpage
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
https
doi
org
nist
sp
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
confidentiality82
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
ensure
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
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
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
see
the
summary
of
the
hipaa
security
rule
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
aami
tir57
or
ansi
aami
sw96
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
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
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
forensic
evidence
capture
is
a
necessary
part
of
digital
forensics
nist
sp
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
https
doi
org
nist
sp
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
an
sbom
in
a
machine
readable
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
jitter
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
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
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
server
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
ensured
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
management84
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
timestamping
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
fda's
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
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
as
mentioned
previously
the
submission
documentation
recommendations
in
this
guidance
are
intended
to
help
manufacturers
meet
their
obligations
for
cyber
devices
under
section
524b
of
the
fd
c
act
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
cybersecurity
risk
management
report
guidance
section
s
sections
v
vi
b
ide
submission
could
be
helpful
to
submit
but
not
specifically
recommended
type
of
premarket
submission
documentation
threat
model
may
include
architecture
views
guidance
section
s
sections
v
a
v
a
v
a
v
a
v
b
appendix
appendix
sections
v
a
v
a
v
a
v
a
v
a
sections
v
a
vi
a
section
v
a
ide
submission
section
v
a
could
be
helpful
to
submit
but
not
specifically
recommended
could
be
helpful
to
submit
but
not
specifically
recommended
measures
and
metrics
sections
v
a
v
a
v
a
v
a
v
a
v
a
v
a
v
b
v
b
v
c
vi
a
section
v
a
architecture
views
section
v
b
cybersecurity
risk
assessment
sbom
vulnerability
assessment
and
software
support
unresolved
anomalies
assessment
traceability
requirements
sections
v
b
appendix
architecture
views
may
be
included
in
threat
model
sections
v
a
v
b
appendix
appendix
testing
section
v
c
could
be
helpful
to
submit
but
not
specifically
recommended
see
architecture
view
recommendations
could
be
helpful
to
submit
but
not
specifically
recommended
recommended
could
be
helpful
to
submit
but
not
specifically
recommended
could
be
helpful
to
submit
but
not
specifically
recommended
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
recommended
global
multi-patient
and
updateability
patchability
views
security
use
case
views
for
functionality
with
safety
risks
could
be
helpful
to
submit
but
not
specifically
recommended
type
of
premarket
submission
documentation
labeling
guidance
section
s
section
vi
a
cybersecurity
management
plans
section
vi
b
ide
submission
recommended
informed
consent
form
to
include
cybersecurity
risks
general
cybersecurity
labeling
connectivity
and
associated
general
cybersecurity
risks
updateability
process
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
definition
is
adapted
from
ansi
isa
definition
is
adapted
from
nist
computer
security
resource
center
glossary
definition
is
adapted
from
nist
sp
security
and
privacy
controls
for
federal
information
systems
and
organizations
https
doi
org
nist
sp
800-53r5
definition
is
adapted
from
cnssi
committee
on
national
security
systems
cnss
glossary
definition
is
adapted
from
iso
iec
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
controlled
risk
when
there
is
sufficiently
low
acceptable
residual
risk
of
patient
harm
due
to
a
device's
particular
cybersecurity
vulnerability
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
definition
is
adapted
from
nist
sp
800-53a
assessing
security
and
privacy
controls
in
federal
information
systems
and
organizations
https
doi
org
nist
sp
800-53ar5
definition
is
adapted
from
iso
iec
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
https
doi
org
nist
sp
definition
is
adapted
from
nist
sp
security
and
privacy
controls
for
federal
information
systems
and
organizations
https
doi
org
nist
sp
800-53r5
definition
is
adapted
from
cnssi
cnss
glossary
definition
is
adapted
from
iso
iec
information
technology
security
techniques
guidelines
for
cybersecurity
definition
is
adapted
from
medical
device
and
health
it
joint
security
plan
version
jsp2
denial
of
service
prevention
or
impairment
to
the
authorized
use
of
the
information
system
resources
or
services
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
disposal
needs
e
g
per
an
agreement
per
organizational
policy
or
for
environmental
legal
safety
or
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
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
least
privilege
a
security
principle
that
a
system
should
restrict
the
access
privileges
of
users
or
processes
acting
on
behalf
of
users
to
the
minimum
necessary
to
accomplish
assigned
tasks
lifecycle
all
phases
in
the
life
of
a
medical
device
from
initial
conception
to
final
decommissioning
and
disposal
definition
is
adapted
from
nist
computer
security
resource
center
glossary
definition
is
adapted
from
iso
iec
ieee
systems
and
software
engineering
software
life
cycle
processes
definition
is
cited
from
nist
sp
guide
to
operational
technology
ot
security
https
doi
org
nist
sp
800-82r3
definition
is
adapted
from
the
common
vulnerability
scoring
system
cvss
specification
document
definition
is
adapted
from
nistir
cybersecurity
framework
manufacturing
profile
https
doi
org
nist
ir
definition
is
adapted
from
nist
computer
security
resource
center
glossary
definition
is
adapted
from
aami
tir
principles
for
medical
device
security
risk
management
definition
is
adapted
from
nist
computer
security
resource
center
glossary
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
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
quality
of
service
necessary
level
of
measurable
performance
in
a
data
communications
system
or
other
service
which
may
include
throughput
bandwidth
transit
delay
latency
error
rates
priority
security
packet
loss
packet
jitter
etc
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
sections
iv
and
v
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
definition
is
adapted
from
nist
computer
security
resource
center
glossary
definition
is
adapted
from
nist
sp
guidelines
on
electronic
mail
security
https
doi
org
nist
sp
800-45ver2
patient
harm
from
cybersecurity
risks
is
discussed
at
length
throughout
this
guidance
and
the
postmarket
cybersecurity
guidance
definition
is
adapted
from
cnssi
national
information
assurance
ia
glossary
definition
is
adapted
from
iso
medical
devices
application
of
risk
management
to
medical
devices
definition
is
cited
from
nist
computer
security
resource
center
glossary
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
qmsr
and
labeling
regulations
as
cybersecurity
continues
to
evolve
fda
continues
to
align
its
terminology
to
reflect
best
practices
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
securityrelevant
elements
and
the
behavior
and
interactions
between
the
security-relevant
elements
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
offthe-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
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
definition
is
adapted
from
nist
computer
security
resource
center
glossary
definition
is
cited
from
nist
sp
recommendation
for
key
derivation
using
pseudorandom
functions
https
doi
org
nist
sp
definition
is
adapted
from
ntia's
framing
software
component
transparency
establishing
a
common
software
bill
of
materials
sbom
definition
is
adapted
from
iso
iec
ieee
systems
and
software
engineering
software
life
cycle
processes
https
doi
org
ieeestd
definition
is
adapted
from
nist
sp
security
and
privacy
controls
for
federal
information
systems
and
organizations
https
doi
org
nist
sp
800-53r5
definition
is
adapted
from
cnssi
cnss
glossary
threat
surface
the
set
of
points
on
the
boundary
of
a
system
a
system
element
or
an
environment
where
a
cyber
threat
can
try
to
enter
cause
an
effect
on
or
extract
data
from
that
system
system
element
or
environment
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
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
adapted
from
nist
computer
security
resource
center
glossary
definition
is
adapted
from
nist
sp
introduction
to
public
key
technology
and
the
federal
pki
infrastructure
https
doi
org
nist
sp
definition
is
consistent
with
the
premarket
software
guidance
even
though
we
use
the
terms
differently
definition
is
cited
from
imdrf
guidance
principles
and
practices
for
medical
device
cybersecurity
definition
is
adapted
from
the
common
vulnerability
scoring
system
cvss
specification
document
guidance
history
revisions
to
final
guidance
date
february
description
revisions
issued
under
level
guidance
procedures
cfr
g
including
revisions
to
align
with
the
amendments
to
cfr
the
quality
management
system
regulation
qmsr
this
guidance
supersedes
the
final
guidance
titled
cybersecurity
in
medical
devices
quality
system
considerations
and
content
of
premarket
submissions
and
published
june
level
final
guidance
june
see
notice
of
availability
for
more
information
this
guidance
supersedes
the
final
guidance
titled
cybersecurity
in
medical
devices
quality
system
considerations
and
content
of
premarket
submissions
and
published
september
reissued
as
level
draft
march
see
notice
of
availability
for
guidance
more
information
this
table
was
implemented
beginning
june
and
previous
guidance
history
may
not
be
captured
in
totality
the
notice
of
availability
is
accessible
via
the
search
for
fda
guidance
documents
webpage
