The document outlines the essential cybersecurity requirements for medical devices as mandated by the FDA, emphasizing a secure product development framework and the need for thorough risk assessment and threat modeling. It discusses compliance with various standards, the importance of software bills of materials (SBOMs), and specific cybersecurity testing protocols that manufacturers must follow. The document also highlights the evolving nature of regulatory authority and enforcement concerning cybersecurity in medical devices since the FDA's first guidance in 2014.

1. Cybersecurity in
Medical Devices
Practical Advice
for FDA’s 510(k)
Requirements

2. About Us
2
Trustonic Secure Platform 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.

3. Speaker Introductions
3
Chief Strategy and
Innovations Officer for
Secure Platform
Founder & CEO
Director of Medical
Programs &
Cybersecurity

4. Agenda
• Why is the FDA requiring cybersecurity - How did we get here?
• Secure Product Development Framework (SPDF) – What is it?
• Threat Modeling and Risk Assessment – Consider Likelihood and Impact.
• Security Controls FDA Will Be Looking For – From Authentication to Updateability
• Cybersecurity Testing – What is the FDA asking for?
• Standards, Standards, Standards – Overview of the many to choose from
• SBOMs – What are they?
• Pulling it All Together – A single page view of the process and evidence created
• Deliverable for the FDA – What do you need to submit for cybersecurity.
4

5. Why The FDA Asked for Cybersecurity Statutory Authority
5
5
Cyber threats can, have, and do pose patient safety risks to the healthcare sector
A Slide from Jessica Wilkerson of the FDA

6. FDA Has Legal Mandate to Enforce Cybersecurity
How Did We Get Here
6
Oct 2014 April 2022 Dec 2022 March 2023 September 2023 Today
October 2014
Cybersecurity in Medical Devices
1) FDA’s first guidance for cybersecurity in
medical devices
December 29 - 2022
Protecting & Transforming Cyber Healthcare Act
(PATCH) – Part of Omnibus Bill
Section 524b added to FD&C Act
4) FDA given statutory power to enforce
cybersecurity in med devices
April 2022 (draft)
Cybersecurity in Medical Devices:
Premarket Submissions
3) Basis for 2023 Final Version
March 2023
FDA releases: Refuse to Accept
Policy for Cyber
5) Industry put on notice that the
FDA is serious
September 2023 (Final)
From the FDA: Cybersecurity in Medical
Devices
6) Final version in preparation for
enforcement in October
Today
7) Enforced!
FDA is sending
rejection letters!
December 2016
Postmarket Management
of Cybersecurity in Medical
Device
2) Vulnerability Monitoring
and Remediation
Dec
2016

7. Requirements
Management SBOM
Features Dev. Code Quality
CI / CD Pre-Production
Testing Post-Production Supporting End of Life
Competence
Development
Threat Modeling
Risk Assessment
Implement
cybersecurity features
Static analysis, MISRA
C, etc..
Generation
CWE/CVE check
Validation
Pentesting
Code Signing
Release / Delivery
Key Management
Locking Hardware
Vulnerability
Monitoring
Incident Response
Software Updates
Diagnostic Tools
Secure
Decommissioning
Software Development Lifecycle
Security Development Lifecycle
Legend
7
Secure Product Development Framework (SPDF)
Based on IEC 81001-5-1

8. Architecture
System
Item Definition
Risk Management
Threat Modeling
SW HW
Requirements
Designs
Network Diagrams
Create DFD
Perform STRIDE
Create Threat Models
List
of
Threats
List of
Mitigations
QA / V&V
Validate Mitigations, Threat Model, and
Mitigations against Threat Model
8
Threat Assessment and Risk Analysis
Feasibility and Impact
Attack
Feasibility
Rating
Prioritize
Threats
(Risk
Assessment)
Impact
Rating
Address
Risk
Accept
Risk
Transfer
Risk
Ignore
Risk
Mitigate
Risk
Manage
Risk
Illegal!
Fix It!
Needs a Claim
Needs a Sharing
Claim

9. Security by Design & Defense in Depth
“Security by design”
9
security.gov.uk
“Defend in Depth”
Create layered controls across a service
so it’s harder for attackers to fully
compromise the system if a single control
fails or is overcome.
• Process orientated approach to security, seen across
regions and industries
• Written from the perspective of organizations sourcing and
applying security technologies (not building them)
• Regulators are expecting a professional approach to
security needs

10. • Secure data transfer to/from the device
• Use encryption when appropriate
• Limit access to trusted users
• Differentiate privileges based on role
• Use secure authentication methods
Authentication
Authorization
Confidentiality
Cryptography
Cryptography
Event Detection
and Logging
Resiliency and
Recovery
Updatability
Patchability
(& SBOMs)
FDA CONTROL CATEGORIES
Appendix-1 of the Guidance
10
• Restrict updates to authenticated code
• Generate SBOMs and provide version
identification for firmware
• Protect critical functionality, even when
security has been affected
• Recovery of device configuration by
authorized user
• Authenticate firmware before execution
• Restrict firmware updates to
authenticated code
• Detect and log security events
• Provide notifications of security events to
enable mitigation
Code, Data
Execution
Integrity

11. Example: Risk Mitigation Using FDA Controls
11
Device
Software Updates
Command/Control Patient Data?
Performance/Logs
App
OS/Platform
TEE
Anomoly
Detection
Secure Boot
VPN
Attacks on Cloud Infrastructure
Social Attack on Operator
…
Network sniffing
Insecure Networks
WiFi Password Loss
Attacks on application code
Attacks on common OS code
Unpatched CVEs
Active Risk Mitigation
Software Update
Secure Boot
Threat
Modelling
Passive Risk Mitigation
Reduce Scope
Do you need to record/send PII?
Can you remove unnecessary features?
Defence in depth:
E.g. TLS over VPN over Secure WiFI
Network protection? (E.g. VPN)
Monitoring (E.g. AnCyR)
TEE (Secure storage/crypto)

12. VERIFY DEVICE DESIGN
21 CFR 820.30(f), a manufacturer must establish and maintain procedures for
verifying the device design.
VALIDATE DEVICE DESIGN (a.k.a Threat Mitigation)
CFR 820.30(g), a manufacturer must establish and maintain procedures for
validating its device design.
VULNERABILITY TESTING
Testing against know vulnerabilities. Techniques often used include fuzzing,
scanning, robustness across the attack surface
TEST
TEST
TEST
(*) Cybersecurity in Medical Devices: Quality System
Considerations and Content of Premarket Submissions
PENETRATION TESTING
Performed by independent testers (i.e., not involved in the design) using
approaches that adversaries (i.e., hackers) would use.
TEST
What the FDA Says About Testing
A Mix of Quality and Security Requirements
12
Cybersecurity testing is needed
along with functional testing
“Certification” is not yet a requirement,
but may be the easiest way to prove
testing is sufficient
SESIP is an upcoming approach
for cybersecurity certification & testing

13. PERSPECTIVE: Regulations, Guidance, Standards
21 CFR 820
Quality System Regulation
ISO 13485
Quality Management System
IEC 62304 Software
Development Lifecycle Process
FDA Sept. 2023
Cybersecurity
Guidance
ISO 81001 5-1 Health Software IT Security
ISA 62443 Security for industrial automation and
control systems
ISO 14971 Application of risk
management to medical devices
TIR57 Principles for medical device security - Risk
management
NIST Cybersecurity Framework NIST CSF - NIST800-
30 Risk assessment
UL 2900 1-1 UL Standard for Safety Software
Cybersecurity for Network-Connectable Products
TIR97 Principles for medical device security – Post-
market risk management for device manufacturers
PATCH Act (524b)
MEDICAL DEVICE PILLARS CYBERSECURITY RECENT
AAMI SW96
13

14. PERSPECTIVE: SBOMs
What’s in my product?
14
xkcd.com
SOFTWARE BILL OF MATERIALS
A list of all open source and
third-party components
in your product
Intent:
Awareness
Vulnerabilities
Remediation
Application:
Standardized format
Automated scanning
NVD -National databases
**BUT, (very) Incomplete
- Packages
- Vulnerabilities
- Mitigations

15. M
Cybersecurity Process
Secure Product Development Framework (SPDF)
15
Design Controls
Design Inputs
1. Req1
2. Req2
3. Req3
Design outputs
1. Spec1
2. Spec2
3. Spec3
Binaries
Verification Tests
1. Test1
2. Test2
3. Test3
Mitigations
1. Mitigation1
2. Mitigation2
3. Mitigation3
Threat Assessment
1. Threat1
2. Threat2
3. Threat3
Security
Architecture
Architecture Diagrams
Component Analysis
Connectivity
definitions Use Case
Views
Code
Known
Abnormalities
(test failures)
Static
Software
Code
Analysis
Source
SCA
Binary
SCA
SBOM
Triage &
Justifications
Vulnerability
Report
Penetration
Testing
Post Market
Vulnerability
Management Plan
Customer
Transparency Plan
Additional Cyber Testing
- Malformed Input
- Fuzz testing
- Vulnerability chaining
Cybersecurity
Assessment
Security Risk
Management
Report
(Annual)
Security Risk
Management Plan
Security Risk Test
Plan
SPDF
composition
Mitigations
Published
Vulnerabilities

16. Cybersecurity Deliverables
16
Deliverables
Security Risk System Description
Plans
Risk Management Plan
Risk Test Plan
Vulnerability Management Plan
Customer Transparency Plan
Assessment
Threat Model
Asset List
Risk Assessment
Security Architecture
Architecture views
Global, Multi-Patient, Updatability, Use Case
Post Production file
SBOM (Software Bill of Materials)
CVE Assessment
Security Risk Management Report
Security Requirements
Security Specifications
SCA Analysis
Additional efforts
Field Monitoring
Incident Reporting
SBOM updates
Design History File
Verification &
Validation
Security Risk Management File
Security Risk
Management Plan
Security Testing Results
• Security Requirements Testing
• Threat Mitigation Testing
• Vulnerability testing
• Penetration testing
Security Risk
System Description
Vulnerability
Management Plan
Security Risk
Test Plan
Post Production Information File
• CVEAssessment
• Field Monitoring
• Cybersecurity Metrics
• Incident Reporting
Design Inputs
Design Outputs
Source Code
Binaries
Security Requirements
Security Specifications
Code Analysis
( SCA / BCA)
Security Risk
Assessment
• Analysis
• Evaluation
• Control
• Residual Risk
Security Risk
Management Report
Summarizes:
• Threat model
• Third party software components
• Security assessment of unresolved anomalies
• Testing summary
Security
Architecture
• GlobalSystem View
• Multi-Patient Harm View
• Updatability View
• Security Use case View(s)
Asset List
Threat Model
SBOM
Customer
Transparency Plan

17. Attempts to Simplify
17
Design History File
Verification &
Validation
Security Risk Management File
Security Risk
Management Plan
Security Testing Results
• Security Requirements Testing
• Threat Mitigation Testing
• Vulnerability testing
• Penetration testing
Security Risk
System Description
Vulnerability
Management Plan
Security Risk
Test Plan
Post Production Information File
• CVEAssessment
• Field Monitoring
• Cybersecurity Metrics
• Incident Reporting
Design Inputs
Design Outputs
Source Code
Binaries
Security Requirements
Security Specifications
Code Analysis
( SCA / BCA)
Security Risk
Assessment
• Analysis
• Evaluation
• Control
• Residual Risk
Security Risk
Management Report
Summarizes:
• Threat model
• Third party software components
• Security assessment of unresolved anomalies
• Testing summary
Security
Architecture
• GlobalSystem View
• Multi-Patient Harm View
• Updatability View
• Security Use case View(s)
Asset List
Threat Model
SBOM
Customer
Transparency Plan
Can we reduce cybersecurity to a couple of
standards and a static process?
Can't we just lock all the
doors and call it a day?
But the FDA wants,..
• Manufacturer vigilance
• Responsible parties
• Deep expertise
• Process transparency
• Defined plans
Encryption
- Cryptographic co-processors (HSM and TPM)
- PKI encryption/authentication
- Cryptographic key management, schemes, tunneling
- Hashes/salting
Authentication
- User accounts / management
- Role based permissions
- Two-factor authentication
Software integrity
- Software update / roll-back
- Root-of-trust (CA)
- Secure boot
Isolation
- Segmented processing zones
- Network isolation
- Distributed processing
Hardening
- I/O line hardening / processor fusing
- OS hardening (ports, processes)
- Processor protections
- Clock anomaly detection
- Memory execution restrictions
- Memory read/write/erase ranges
Services
- Firewall
- Whitelist processes
- Watchdog controlled applications
- Security logging
- Post market monitoring
User Interface
- Data validation / range checking
Protected data
- PII/PHI protections and deidentification

18. Vote on Future Webinars
18
1. SPDF – Follow a cybersecurity process
2. Threat modeling and risk assessment – Evaluate Risk
3. Security by design & defense in depth – FDA’s Security control
categories
4. Trusted Execution Environment and IDS – Integrity, Resiliency,
Confidentiality, Detection
5. Cyber-testing – What the FDA expects
6. Post Market Requirements – Fixing Vulnerabilities: SBOM –
Updates - Monitoring
7. Bolting On Security – Is there anything that can be done if I already
have a design
8. Cybersecurity documentation for eSTAR submission

19. 19
Thank You
Thank You