8 Mandatory Security Control Categories for Successful Submissions

Cybersecurity in Medical Device:
Practical Advice for FDA 510(k)
Eight Security Control
Categories Specified by
the FDA

About Us
2
Trustonic provides a certified solution for the storage and management of security or
privacy sensitive data. This can be used to protect cryptographic keys and patient
information ensuring devices use best in class security. It can also be used to provide
defense in depth to protect other systems, such as secure communications or
intrusion detection, and enable secure manufacture and tracking of devices
throughout their lifecycle.
BG Networks equips embedded engineers and penetration testers with easy-to-
use software automation tools to streamline cybersecurity tasks including
hardening, detection, and testing. BG Networks automation tools are designed to
help with adherence to regulations from the FDA, NIST, ISO, and the EU.
ICS supports our customers with software development, User experience design,
platform and regulatory support to build next generation products. We provide a
number of services focused on the medtech space including human factors
engineering with a 62366 compliant process, hazard and risk analysis, 62304
compliant software development, and platform support including cybersecurity.
Cybersecurity
Services
Cyber-Testing
&
Detection
Trusted
Execution
Environments

Speaker Introductions
Colin Duggan
Founder & CEO
Milton Yarberry
Director of Medical Programs
& Cybersecurity
Richard Hayton
Chief Strategy & Innovation
Officer for Secure Platform

Cybersecurity in Medical Devices: Practical Advice for FDA’s 510(k)
Requirements Webinar Series
4
On Demand Practical Advice for FDA’s 510(k) Requirements
https://www.ics.com/webinar-demand-practical-advice-fdas-510k-requirements
On Demand A Deep Dive into Secure Product Development Frameworks (SPDF)
https://resources.ics.com/webinar/secure-product-development-frameworks
On Demand Secure-by-Design - Using Hardware and Software Protection for FDA Compliance
https://resources.ics.com/webinar/secure-by-design-hardware-software-protection
On Demand - Threat modeling and risk assessment – First step in risk management
https://resources.ics.com/webinar/threat-modeling-risk-assessment
On-Demand – Medical Device Cyber Testing
https://resources.ics.com/webinar/medical-device-cyber-testing

Cybersecurity Deep Dive – Sign Up During This Webinar
Review & Report on 8 Cybersecurity Control Categories
Meet with our experts for a working session based on your medical device
• We’ll review how the security control categories apply to your medical device
• We’ll provide a report after based on our discussion and type of your medical device
• It will save you time getting ready for a FDA submission or MDR assessment
• We can also review and provide patient monitor the Threat and Risk analysis we did for the patient
monitoring example
Sign up on Calendly, at the link below, for a 30-minute session
• Here is the link and we’ll put it in the chat
• https://calendly.com/integratedcomputersolutions/8-security-controls

Questions For Us And A Question For You
Questions for us:
• Put your questions in the Q&A
• For questions we don’t get to, we’ll write answers and make them available after
A question for you:
What has been or do you expect to be the most challenging part of cybersecurity for a 510(k) submission?
6
POLL QUESTION RESPONSES (please respond now - may choose more than one)
a. Limited cybersecurity personnel
b. Understanding of FDA expectations for cybersecurity for 510(k) submission
c. First time creating this information
d. Did not consider security from the beginning and trying to bolt-on
e. Correct implementation of cybersecurity
f. Schedule limitations
g. Scaling challenges (i.e., making a large fleet of devices secure)
h. Providing and maintaining a long-term security process after submission

Agenda
• Introduction to our Real-World Example : Patient Monitor
• CISA Warning on a Patient Monitor
• Introduction to the FDA’s 8 Cybersecurity Categories
• Review of Each of the 8 Categories and Underlying Security Principals
• Application of the 8 Categories to Our Example
• How to Integrate the 8 Categories With Your SPDF & Into an FDA 510(k) Submission
7

Example – Patient Monitor
Central Monitoring
System
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
WIFI

Device (Main Board)
9
Assets for Cybersecurity Consideration
Patient Health Information data stored in
patient monitor
Patient Health Information transmitted
Real time monitoring data
User interface
Alarm settings and thresholds
Security event logs
Passwords for authentication for login via
user interface stored in the patient monitor
X.509 certificate
ARM Processor
Flash memory
Wifi interface
Ethernet interface
3G cellular interface
Main firmware
Embedded Linux operating system
HL7 protocol software stack
Mbed TLS software stack
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
3
8
1
2
3
1
2
5
6
7
4
5
6
7
9
10
11
12
13
9 10
11
12
13
14
15
16
17
14
15
16 17
4
8
Primary
Data
Secondary
Data
Hardware
Software
Example – Patient Monitor
Adding software and Information Assets
Based on these assets, we performed a threat and risk analysis, to
determine the security controls needed

Chose Patient Monitor Example Given the Recent CISA Warning
• Two CWEs
• CWE – 912 Hidden Functionality
• CVE-2025-0626
• CWE – 359 Exposure of Private Personal Information
• CVE-2025-0683
10
CISA recommended mitigation : disable networking features: Ethernet, Wifi, cellular
If you require the networks features, the device could be unusable

Introduction to FDA’s 8 Cybersecurity Control Categories
A. Authentication
B. Authorization
C. Cryptography
D. Code, Data, and Execution Integrity
E. Confidentiality
F. Event Detection and Logging
G. Resiliency and recovery
H. Firmware and Software Updates
11
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions

A: Authentication – what document says
• Authentication of information.. Originated at a known and trusted source
• Authentication of entities … prove the identity of an endpoint*
• This may include the user/operator but primarily is about the device/server identity
• Six sub-categories outlined:
• Information at rest (stored)
• Information in transit (transmitted)
• Entity authentication of communication endpoints
• Software Binaries
• Integrity of software
• “Other” where threat model reveals need for it
• Guidance
• Avoid “implicit” (non-cryptographic) means because they can be reverse engineered at scale
• However non-routine signals of intent give additional protection against attack (e.g. hold down reset
button) whilst applying a signed software update.
12

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
A: Authentication Controls On Patient Monitor
Patient Info
At
Rest
Binaries
User Auth [Other]
In Transit
Entity
Auth
Entity Auth? In Transit?
Software
Integrity
Authentication of PHI and real
time monitoring data at rest
Authentication of PHI and
real time monitoring data in
transit
Authentication alarm
and threshold settings
Authentication
of security logs
Passwords for user
authentication
Authentication of central
monitoring station by
patient monitor and vice
versa
At Rest
User Auth [Other]
In Transit
Entity Auth

A: Authentication – Choose & extend a “platform”
• Your chosen system should offer
• Robust storage (e.g. encrypted/isolated) to meet “Information at rest” requirements
• Including keys inherent in system security, such as related to boot.
• Standard communications security (TLS/DTLS) using supported libraries for “Information in transit”
• Try and avoid hand rolled communications if possible and show a support plan for any 3rd party/OSS software used.
• Strong device identity and/or client and server certificates for Entity authentication
• Remember certificates need to be deployed/refreshed. If servers are customer-specific this is much more complex than a single
universal cloud.
• Secure boot and signed software binaries (for integrity of software)
• Secure boot is (almost) universal, but think about management of keys to sign new binaries and issues like rollback
• Take care with your threat model.
• There are likely other areas that should be covered. A security focused platform will help meet them.
• Guidance
• Use cryptographically strong authentication, on device, to authenticate [everything remote]
• Verify the authenticity of information from the device. “Attestation++”
• Hardware based security solutions should be considered and employed when possible
• Frequency of auth / anti reply / no hardcoded passwords / …
14

B: Authorization
• “Permission [rights] granted to a system entity to access a system resource”
• Permit/deny rights to ensure resource are only accessed in acceptable ways by accepted parties
• Although this definition is broad, guidance is written in terms of user authorization.
• Use Least Privilege
• I.e. each user/sub-system should only have the rights it requires [and only when required]
• Can use any “compelling evidence”
• May be cryptographically checked identity (c.f. authentication)
• May be based on time/physical access etc.
• [But be wary of assuming that proprietary protocols cannot be tampered with]
• Guidance
• Limit access through authentication of users (password/smartcard/biometrics/certificates/…)
• End sessions based on timeout (to avoid attackers reusing authorized connections)
• Different permissions for different types of user (roles)
• Deny by default
15

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
B: Authorization Controls On Patient Monitor
16
Administrator authorization
over the network for device
configuration
SE Linux Role Based Access
Control for Alarm, threshold settings
& data access
Authorization to access security logs
(remote and/or locally)
Authorization levels for user types:
caregiver, patient, healthcare
provider, system administrator
(Local and Remote)
Authentication: Who [or what] is
attempting an action.
[More generally is the person/component/data
what they purport to be]
Authorization: Are they allowed to!
Admin
Admin
Least Privilege
Admin
Least Privilege
Admin
Admin
Admin
Admin
Admin

C: Cryptography
• “Several commercial products that include cryptographic protections have been shown to
have exploitable vulnerabilities due to improper configuration and/or implementations
• Choose supported cryptographic providers [over lifetime of product]. You may need multiple for different parts of system
• Take care with configuration [especially configuration updates]
• Select industry standard algorithms and protocols
• And select appropriate key generation, distribution, management and protection as well as robust nonce mechanisms.
• NIST recommended standards or equivalent
• Do not use deprecated algorithms or key lengths (or allow them to be used)
• Design a system architecture and security controls to prevent the situation where the
full compromise of any single device can result in the ability to reveal keys for other devices
• AVOID master [symmetric/private] keys or key derivation based on discoverable information
• Think about abnormal situations such as device recall or reverse engineering
• Enable negotiation in protocols so that the most recent configuration is used
• Avoid the ability for an attacker to negotiate use of weaker cryptography
• Do not allow downgrades or rollbacks [unless absolutely necessary]
17

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
C: Cryptography Controls On Patient Monitor
18
Secure
Comms
You [probably] won’t be using
cryptography directly – unless you
are directly implementing ‘secure’
algorithms [which is hard to do right]
Key advice is to use standard
technology of “appropriate” security
• E.g. TLS libraries, HSMs, TEEs
• Ensure it is appropriately
configured
• Ensure it is kept up to date
Future Proof
• Quantum-Safe is not a
requirement yet
• FIPS not required
• Think about future deprecation
• SHA1, short key lengths,…
• Updates will be required
Secure
Storage
Rollback
Secure
Comms
Secure
Comms

D: Code, Data and Execution Integrity
• Code Integrity
• Hardware based security solutions should be considered and employed when possible. E.g. TEE/SE/HSM/TPM
• Authenticate firmware and software
• Signatures / MACs for content + version numbers
• Signed/MAC for manifest of software to be installed (ensures versions are appropriate)
• Devices should have unique device identifiers (model/serial etc.)
• Do not allow update when signatures cannot be validated (!)
• Avoid downgrades – if they are necessary, make them explicit (e.g. signed metadata from version X->Y)
• Validate prior to executing any code
• Disable or restrict access to test/debug ports (e.g. JTAG, UART) (not documenting doesn’t count!)
• Employ tamper evident seals (ideally detectable by software)
• Data Integrity
• Verify integrity of all incoming data (=> authentication of data in transit)
• Validate data from external sources is well formed and within safe limits (don’t just rely on crypto)
• Protect the integrity of data necessary for correct operation [e.g. keys/parameters]
• [integrity of data generated and stored on device]
• Execution Integrity
• Use industry best practices to maintain and verify integrity of code during execution. E.g. IDPS
• Carefully design and review code that parses external data using automated and manual methods.
19

Secure
OS
Secure
Subroutine
Secure
Flash
HSE
Isolate security sensitive code/keys/data/peripherals from less sensitive ones
Flash
What is a ‘Hardware based security soln’
20
App Code
Crypto Lib
Operating
System
Keys
Data
Sensor
Actuator
Networks
Flash
App Code
Crypto Lib
Operating
System
Keys
Data
Sensor
Actuator
Networks
Flash
App
Code
Crypto Lib
Operating
System
Keys
Data
Sensor
Actuator
Networks
Crypto
No (separate) hardware security
Attacks on OS or Library code may
reveal keys/data or misuse
actuators or networks
Hardware key storage / Crypto
Separate ‘chip’ but may be in same
package as CPU/MPU
Hardware isolated compute
Typically runs on same CPU/MPU
Can be used to protect data,
comms, code and peripherals
GlobalPlatform TEE (CPU)
[Arm] PSA (MCU)
HSM / SE / HSE / …

E: Confidentiality
• Ensure support for the confidentiality of any/all data whose disclosure could lead to patient harm.
• Focus is on Keys & Credentials that might allow device or other systems to be abused
• Concerns over “multi-patient harm” if one attack can have broad implications
• For example: Stealing master keys used by many devices,
• Don’t just focus on your device - think of what additional keys your device requires that might be stored elsewhere
• Guidance doesn’t really touch on patient data
• But it is obvious that “leaking” patient data could lead to patient harm via violations of the patient’s expectation of privacy,
so it is recommended that confidentiality of patient data is also considered.
21

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
E: Confidentiality
Encrypt
PHI
Hashing or
secure storage of
user passwords
Secure Storage
of Data
Encryption Keys
Possible
encryption of
patient data
Encrypt
Data in Transit
• Cryptographic keys and sensitive data
should be securely stored in transit and at
rest
• Use secure algorithms when transmitting
sensitive data
• Storing data securely at rest can be more
difficult, but it can be done using secure
boot, TPMs, and/or disk encryption
• Use threat model to determine specific
strategies for which security storage
approaches should be used

F: Event Detection and Logging
• To identify and track attempts at compromise (i.e., cyber-attacks, anomalous behavior)
• Detection approaches include antivirus, Intrusion Detection Software (IDS), honey pots
• Notify users and administrators, as quickly as possible, when anomalous behaviour is detected.
• Logs should be stored for examination in the future and protected against tampering
• Events/data logged can include
• Login attempts
• Configuration changes
• Network anomalies
• Software updates
• Modification of code
• Operations that fail to complete
• Timing of operations (e.g., boot time)
23

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
F: Event Detection and Logging
Tamper
Protection for
Secure Logs
Intrusion
Detection
Systems
• Event detection and logging at the
medical/embedded device is
complemented by network logging and
firewalls
• Intrusion Detection System (IDS) software,
such as BG Networks AnCyRr® are
optimized for embedded processors and
microcontrollers with low MIPS and
memory overhead
• Events detected, can be stored or sent as
an alert over the network – AnCyR for
example has the ability to report to SIEMs
Loging of Users
(patient,
caregiver, admin)
Firewall to detect
unusual network
activity

G: Resilience and Recovery
• Devices should be resilient to “cyber incident scenarios” – can continue to operate under duress.
• Add features to protect critical functionality, even when the device has been partially compromised
• An example of an isolation mechanism is a “Trusted Execution Environments”
• Add features that support trusted default device configuration that is authenticated
• An example: secure reset : Rebooting authenticated code (with hardware root of trust) brings compromised device to secure state
• Design devices to specify the level of resilience during disruption
• Design to be resilient to network outage, scanning, QoS degradation , excessive bandwidth, etc..
25

Device (Main Board)
Realtime Data
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display Screen
Display Data
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Patient Info
Alarm Settings
Security Event Logs
Passwords
X.509 Certificate
Patient Info
G: Resilience and Recovery
Trusted
Execution
Environment for
Process Isolation
If Network goes down device
continues to function by
storing data locally for
inspection at a later time
Secure boot with a
hardware root of trust to
reset back to
authenticated code and a
configurations
Critical functions
continue to
operate even if
some are
compromised
Timely software updates to
recover and close
vulnerabilities quickly
• A combination of software (Kinibi from
Trustonic) and hardware (ARM Trust Zone)
create an isolated environment: Trusted
Execution Environment (TEE)
• The TEE will continue to be protected even
if the main OS is compromised.
• A TEE can be used to securely reboot the
device and bring it back to a secure state

Firmware and Software Updates
27
Software Update is a PRIMARY requirement of
524B
• Submit a Plan with 510K
• Doesn’t mandate how to perform the
update
• Not a forced update,.. "Make available"
• Risk-based urgency: "reasonable amount of
time" to "as soon as possible"
• Responsiveness is contra to industry norms
of infrequent updates
524B “Ensuring Cybersecurity of Devices.”
(b) The sponsor of an application or submission described in subsection (a)
shall-
(1) submit to the Secretary 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;
(2) design, develop, and maintain processes and procedures to
provide a reasonable assurance that the device and related systems
are cybersecure, and make available postmarket updates and patches
to the device and related systems to address—
(A) on a reasonably justified regular cycle, known unacceptable
vulnerabilities; and
(B) as soon as possible out of cycle, critical vulnerabilities that
could cause uncontrolled risks;
(3) provide to the Secretary a software bill of materials, including
commercial, open-source, and off-the-shelf software components; and
(4) comply with such other requirements as the Secretary may require
through regulation to demonstrate reasonable assurance that the
device and related systems are cybersecure.

Firmware and Software Updates – Readiness Considerations
28
• Multiple versions deployed in the field
• Security Portal as a common solution: for updates, and security labelling
• Automated updates
• Rigid update process. Well tested before initial release
• Multi-processor update with roll-back in the event of failure
• Processing head-room on device, or facilities for legacy devices
• Battery check
• Preserve and maintain full build environments, regression test suites, development kits, emulators, debuggers.
Patches? (test configuration, locked down device, bandwidth, capable of update)

Automated Software Updates
29
• Manager (Update Process)
• Customer consent
• Multiple versions
• Saturate network
• Coordination with peripherals
 Pre-determined sequence
• Support features
 A/B partitions
 Switching bootloader key
• Invalidating keys

Automated Software Updates
30
• Manager (Update Process)
• Customer consent
• Multiple versions
• Saturate network
• Coordination with peripherals
 Pre-determined sequence
• Support features
 A/B partitions
 Switching bootloader key
• Invalidating keys
• Roll-back in the event of failure

Firmware and Software Update Controls On Patient Monitor
31
• Biggest issue - "Reverse-Backdoor" (code insertion
with admin priv.)
• Mounts NFS drive at IP address in China and copies/downloads
co de/binaries to the monitor
• Sends PHI data
• Vulnerable to man-in-the-middle attacks
• Suspicious but ostensibly a software update mechanism, or
debug code
• But no customer notice or agreement
• Minimally demonstrates, no design controls, no code analysis,
pentesting failure
Contec Health Device
Device (Main Board)
CPU
Flash &
RAM
3G
Eth.
WiFi
Sensors
Temperature
Data
SpO2 Data
Blood
Pressure Data
Respiratory
Data
ECG
Data
LCD Display
Screen
Central
Monitor
Application Logic
HL7
Embedded Linux
Firmware
TLS
Configuration
Firmware
Update
OS Update
Library
Update
Application
Update
Config
Update

How to integrate the 8 categories with your SPDF
SPDF is like SDLC for cybersecurity
o Development
 Planning
 Requirements
 Architecture
 Design
 Test – 4 types
 Release
o Maintenance
 Change management
o Risk Management
 Assessment --> Controls
o CAPA/SPRP
32
1. Authentication controls
2. Authorization controls
3. Cryptography controls
4. Code, Data and Execution Integrity controls
5. Confidentiality Controls
6. Event detection and logging controls
7. Resiliency and recovery controls
8. Firmware and software update controls

Where 8 Control Categories Appear in 510(k) Submission
33
This is as close as FDA comes to
prescribing solutions
Forces documented consideration:
Justify where Controls don't apply
• Air-gapped systems (no network)
• Systems without users
(Authorization)
• No PHI (Confidentiality)

Speakers
Colin Duggan
Founder & CEO
Milton Yarberry
Director of
Medical Programs &
Cybersecurity
Richard Hayton
Chief Strategy and Innovations
Officer for Secure Platform

8 Mandatory Security Control Categories for Successful Submissions

More Related Content

Similar to 8 Mandatory Security Control Categories for Successful Submissions (20)

More from ICS (20)

Recently uploaded (20)

8 Mandatory Security Control Categories for Successful Submissions