Medical Device Software Cybersecurity: Complete FDA Compliance Guide (2026)

Word Count: ~10,800 words
Reading Time: 43 minutes

Introduction: The New Reality of Medical Device Cybersecurity

October 2023 changed everything for medical device software developers.

FDA’s new cybersecurity guidance made comprehensive security documentation mandatory for all premarket submissions. No longer optional. No more “we’ll address that later.”

The stakes:

• 53% of healthcare organizations experienced ransomware attacks in 2023
• Average healthcare data breach cost: $10.93 million (highest of any industry)
• FDA issued 23 cybersecurity-related warning letters in 2023-2024
• Connected medical devices are now the #1 target for healthcare cyberattacks

The reality: Many software medical device manufacturers are unprepared. They’re scrambling to:

• Create Software Bills of Materials (SBOMs) for existing products
• Conduct threat modeling they should have done during design
• Implement security testing they’ve never performed
• Document security architectures that exist only in developers’ heads

This comprehensive guide will help you understand and implement FDA’s cybersecurity requirements for medical device software, from premarket submission through post-market monitoring.

Table of Contents

1. Why FDA Cybersecurity Requirements Exist
2. FDA’s 2023 Cybersecurity Guidance Explained
3. Key Cybersecurity Concepts for Medical Devices
4. Threat Modeling for Medical Device Software
5. Software Bill of Materials (SBOM)
6. Security Architecture & Design
7. Security Testing Requirements
8. Post-Market Cybersecurity Management
9. Common Vulnerabilities in Medical Device Software
10. FDA Submission Requirements
11. Cost, Timeline & Resources

Why FDA Cybersecurity Requirements Exist {#why-fda-cybersecurity}

The Healthcare Cybersecurity Crisis

Recent Medical Device Cyber Incidents:

2017 – WannaCry Ransomware

• Hit UK’s National Health Service
• Disabled MRI scanners, X-ray machines, diagnostic equipment
• 19,000+ appointments cancelled
• Cost: £92 million

2019 – Cardiac Device Vulnerabilities

• FDA recalled 465,000 pacemakers for cybersecurity flaws
• Vulnerabilities allowed unauthorized access
• Could deplete battery, administer incorrect pacing
• Required firmware updates to patients’ implanted devices

2020 – Urgent/11 Vulnerabilities

• Affected 200+ million medical devices
• Found in devices from BD, B. Braun, Baxter, GE Healthcare
• Remote code execution possible
• Full device compromise potential

2021 – Colonial Pipeline → Healthcare

• While not directly healthcare, showed cascading effects
• Hospitals couldn’t get fuel for generators, ambulances
• Demonstrated infrastructure interdependencies

2023 – Ransomware Explosion

• HCA Healthcare: 11 million patient records stolen
• CommonSpirit Health: $150M+ recovery costs
• Shields Health Care: Closed 2 diagnostic centers for months

Why Software Medical Devices Are Targets

1. Critical to Patient Care
   • Attackers know hospitals will pay ransom to restore life-supporting devices
   • High-value targets with immediate consequences
2. Connected to Networks
   • Most modern medical devices connect to hospital networks, cloud services, mobile apps
   • Multiple attack vectors
3. Legacy Vulnerabilities
   • Devices designed 5-10 years ago without modern security
   • Still in use, still connected
4. Valuable Data
   • Patient health information sells for $250+ per record (vs. $5 for credit cards)
   • Includes financial, health, identity information
5. Complexity
   • Modern medical device software uses dozens of third-party components
   • Each component = potential vulnerability

FDA’s 2023 Cybersecurity Guidance Explained {#fda-2023-guidance}

What Changed in 2023?

FDA’s “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” (September 2023)

Key Changes:

1. Mandatory, Not Recommended

• Previous guidance (2014, 2018) was “recommendations”
• 2023 guidance: Required for all submissions after October 1, 2023

2. Security by Design

• Must be integrated into DESIGN, not added later
• Must demonstrate security considerations in every development phase

3. Software Bill of Materials (SBOM)

• Required documentation of all software components
• Must be maintained and updatable throughout device lifecycle

4. Threat Modeling

• Structured analysis of potential cybersecurity threats
• Must be performed during design phase

5. Security Risk Management

• Must be integrated with safety risk management (ISO 14971)
• Dedicated cybersecurity risk assessment

6. Vulnerability Management Plan

• How you’ll identify, assess, and address vulnerabilities post-market
• Must be submitted in premarket application

Who Must Comply?

All medical devices with:

• Software components (SaMD or SiMD)
• Network connectivity (WiFi, Bluetooth, cellular, wired)
• Electronic data transfer capability
• Ability to receive updates

Basically: Almost all modern medical devices.

Exemptions: Truly standalone devices with no connectivity, no data storage, no software components. (Very rare in 2026.)

Key Cybersecurity Concepts for Medical Devices {#key-concepts}

The CIA Triad for Medical Devices

Confidentiality

• Protect patient data from unauthorized access
• Encrypt data at rest and in transit
• Access controls and authentication

Integrity

• Ensure data and device function hasn’t been tampered with
• Detect unauthorized modifications
• Maintain audit logs

Availability

• Ensure device is operational when needed
• Resilience against denial-of-service attacks
• Backup and recovery capabilities

Safety First Principle: Sometimes security and safety conflict. FDA’s hierarchy:

1. Safety (patient harm prevention)
2. Essential Performance (device must work)
3. Security (protect from cyber threats)

Example: Emergency access override (reduces security but maintains safety)

Defense in Depth

Multiple layers of security controls:

Layer 1: Physical Security

• Device housing protection
• Tamper-evident seals
• Secure boot

Layer 2: Network Security

• Firewalls
• Network segmentation
• Encrypted communications

Layer 3: Application Security

• Input validation
• Secure coding practices
• Authentication/authorization

Layer 4: Data Security

• Encryption at rest and in transit
• Secure key management
• Data integrity checks

Layer 5: Monitoring & Response

• Logging and auditing
• Anomaly detection
• Incident response plan

Security vs. Legacy Compatibility

Major challenge: Many medical device software systems must integrate with legacy hospital infrastructure.

Trade-offs:

• Newer security protocols (TLS 1.3) may not work with old hospital systems (TLS 1.0)
• Multi-factor authentication may interfere with emergency workflows
• Complex passwords = users write them on sticky notes

FDA’s position: Security is non-negotiable, but implementation should consider real-world use.

Threat Modeling for Medical Device Software {#threat-modeling}

What is Threat Modeling?

Structured approach to identifying, quantifying, and addressing security threats.

FDA requires this to be done during the design phase, not after development.

FDA-Recommended Threat Modeling Process

Step 1: Asset Identification

Identify what needs protection:

Step 2: Architecture Analysis

Create security-focused architecture diagrams showing:

• Data flows
• Trust boundaries (where data crosses security zones)
• External interfaces
• User roles and permissions
• Network connections

Example trust boundaries:

• Device ↔ Hospital network
• Mobile app ↔ Cloud service
• Device ↔ Internet
• User ↔ Device (authentication)

Step 3: Threat Identification (STRIDE Method)

STRIDE Framework (Microsoft):

S – Spoofing Identity

• Threat: Attacker impersonates legitimate user/device
• Example: Fake authentication credentials, stolen tokens
• Impact: Unauthorized access to patient data or device controls

T – Tampering with Data

• Threat: Malicious modification of data
• Example: Altering lab results, changing therapy settings
• Impact: Incorrect treatment, patient harm

R – Repudiation

• Threat: User denies performing an action
• Example: Clinician claims they didn’t change dosing, but they did
• Impact: Liability, impossible to audit

I – Information Disclosure

• Threat: Exposing confidential information
• Example: Unencrypted patient data transmission, data breach
• Impact: HIPAA violations, privacy breach

D – Denial of Service

• Threat: Making device unavailable
• Example: Network flood, resource exhaustion, ransomware
• Impact: Device downtime, delayed treatment

E – Elevation of Privilege

• Threat: Gaining higher privileges than authorized
• Example: Standard user accessing admin functions
• Impact: Full device compromise

Step 4: Risk Rating

For each identified threat, assess:

Likelihood:

• How easy is this attack?
• What attacker skill level required?
• How accessible is the attack vector?

Impact:

• What’s the worst-case outcome?
• Could this cause patient harm?
• Could this compromise many devices?

Risk Matrix:

Step 5: Mitigation Strategy

For each medium/high/critical risk, define:

1. Prevention Controls (stop the attack)
   • Input validation
   • Authentication
   • Encryption
   • Access controls
2. Detection Controls (identify attack in progress)
   • Logging
   • Anomaly detection
   • Intrusion detection
3. Response Controls (limit damage)
   • Incident response plan
   • Rollback capability
   • User notification
4. Recovery Controls (restore normal operation)
   • Backup and restore
   • Patching process
   • Forensics capability

Step 6: Document Residual Risk

After implementing all mitigations:

• What risk remains?
• Is it acceptable given the device’s benefit?
• How will you monitor this risk post-market?

Common Threat Modeling Mistakes

❌ Mistake #1: Threat modeling only for network threats Correct: Also model physical access, supply chain, insider threats

❌ Mistake #2: Doing threat modeling after development Correct: Must be done during design phase

❌ Mistake #3: Generic threat models Correct: Must be specific to YOUR device, YOUR architecture

❌ Mistake #4: Not updating threat model Correct: Update when architecture changes, new threats emerge

Software Bill of Materials (SBOM) {#sbom}

What is an SBOM?

Software Bill of Materials: Complete, formally structured list of all software components in your medical device.

Think of it like: Ingredient label on food products, but for software.

Why FDA Requires SBOMs

The Problem:

• Average medical device software uses 50-300+ third-party components
• 70-90% of vulnerabilities exist in third-party code
• When Log4Shell vulnerability disclosed (Dec 2021), no one knew which devices were affected
• Took months to identify vulnerable devices

The Solution:

• SBOM allows rapid identification of vulnerable components
• Enables coordinated vulnerability response
• Supports supply chain security

SBOM Requirements (FDA 2023 Guidance)

Must Include:

1. Component Identity
   • Component name
   • Version number
   • Author/supplier
   • Unique identifier (CPE, PURL, or SWID)
2. Component Relationships
   • How components depend on each other
   • Which are direct vs. transitive dependencies
3. Known Vulnerabilities
   • CVEs (Common Vulnerabilities and Exposures)
   • Vulnerability severity (CVSS scores)
4. License Information
   • Open source licenses
   • Commercial license restrictions
5. Timestamps
   • When SBOM was created
   • Software release date

SBOM Formats

Three FDA-accepted formats:

1. SPDX (Software Package Data Exchange)

• ISO standard (ISO/IEC 5962:2021)
• Comprehensive
• Good for complex devices

2. CycloneDX

• OWASP project
• Focused on security use cases
• Popular for continuous integration

3. SWID (Software Identification Tags)

• ISO standard (ISO/IEC 19770-2:2015)
• Used primarily for software asset management

Recommendation: Use SPDX or CycloneDX (both widely supported, tooling available)

How to Create an SBOM

Option 1: Manual Creation (Small projects only)

Steps:

1. List all software components
2. Identify versions
3. Check for known vulnerabilities (NVD database)
4. Format in SPDX or CycloneDX

Feasible for: <20 components, simple architecture

Option 2: Automated Tools (Recommended)

SBOM Generation Tools:

Open Source:

• Syft (Anchore) – Container and filesystem analysis
• CycloneDX CLI – Multiple language support
• SPDX tools – Official SPDX utilities

Commercial:

• Black Duck (Synopsis) – Comprehensive SCA
• Snyk – Developer-friendly, integrates with CI/CD
• WhiteSource – Open source risk management
• Sonatype Nexus – Repository-based analysis
• JFrog Xray – Artifact analysis

Example using Syft:

syft packages <your-device-image> -o spdx-json > sbom.spdx.json

Option 3: Hybrid Approach (Best practice)

Use automated tools for:

• Dependency scanning
• Vulnerability identification
• Initial SBOM generation

Manual review for:

• Embedded/compiled components
• Legacy code
• Custom/modified open source
• Hardware-software interfaces

SBOM Maintenance

Critical: SBOM must be a living document.

Update SBOM when:

• You release new software version
• You update third-party components
• You discover new vulnerabilities
• You add/remove features

FDA expects:

• SBOM versioning aligned with software versioning
• Historical SBOMs archived
• SBOM availability to users (hospitals, FDA) upon request

Common SBOM Mistakes

❌ Mistake #1: Incomplete SBOM (missing transitive dependencies) Your code uses Library A, which uses Library B. You only list Library A.

Fix: Include all transitive dependencies (tools help automate this)

❌ Mistake #2: Outdated SBOM SBOM created in 2022, software updated in 2024, SBOM never updated.

Fix: Automate SBOM generation in CI/CD pipeline

❌ Mistake #3: No vulnerability mapping SBOM lists components but doesn’t note known vulnerabilities.

Fix: Cross-reference with NVD (National Vulnerability Database) regularly

❌ Mistake #4: Ignoring firmware/embedded software Only creating SBOM for high-level application, ignoring OS, middleware, firmware.

Fix: Include ALL software layers

Security Architecture & Design {#security-architecture}

Security Architecture Documentation

FDA requires detailed security architecture documentation in premarket submissions.

Must Include:

1. Security Boundary Identification

Define what’s inside vs. outside your trust boundary:

Example: Insulin Pump with Mobile App

Trust Boundaries:

1. Pump device ↔ Mobile app (Bluetooth)
2. Mobile app ↔ Cloud service (HTTPS)
3. Cloud service ↔ Healthcare provider portal (HTTPS)
4. Healthcare provider portal ↔ Hospital EHR (HL7/FHIR)

For each boundary:

• Authentication method
• Encryption protocol
• Data integrity checks
• Authorization controls

2. Authentication & Authorization

User Authentication Methods:

Strong (Required for high-risk devices):

• Multi-factor authentication (MFA)
• Biometric authentication
• Hardware tokens
• Certificate-based authentication

Moderate (Acceptable for medium-risk, non-critical functions):

• Complex passwords (12+ characters, mixed case, numbers, symbols)
• Time-limited sessions
• Account lockout after failed attempts

Weak (FDA will reject):

• Simple passwords (4-6 digits)
• No lockout policy
• Shared credentials
• Default passwords

Role-Based Access Control (RBAC):

Example roles for infusion pump:

3. Encryption Requirements

FDA Expectation: Industry-standard encryption

Data at Rest:

• Minimum: AES-128
• Recommended: AES-256
• For PHI: AES-256 with secure key management

Data in Transit:

• Minimum: TLS 1.2
• Recommended: TLS 1.3
• Deprecated/Forbidden: SSL 3.0, TLS 1.0, TLS 1.1

Key Management:

• Keys stored separately from encrypted data
• Regular key rotation
• Hardware security modules (HSM) for high-risk devices
• No hardcoded encryption keys in source code

4. Secure Communications

Network Communication Security:

For Internet-connected devices:

• HTTPS for web services
• Certificate pinning for mobile apps
• VPN or equivalent for remote access
• Mutual TLS authentication for device-to-device

For Local/Bluetooth connections:

• Bluetooth pairing with PIN/authentication
• Encrypted Bluetooth profiles
• MAC address filtering (not sole security mechanism)

5. Software Update Mechanism

Secure update process:

Required security controls:

1. Code signing: Updates must be cryptographically signed
2. Verification: Device verifies signature before installing
3. Rollback: Ability to revert to previous version if update fails
4. Integrity check: Hash verification of update package
5. Secure channel: Updates delivered over encrypted connection

Example update flow:

1. Manufacturer signs update with private key
2. Update uploaded to secure server
3. Device checks for updates
4. Device downloads update over HTTPS
5. Device verifies signature using manufacturer's public key
6. If valid, update installed; if invalid, rejected
7. Device performs self-test
8. If test passes, update complete; if fails, rollback

6. Logging & Monitoring

Security event logging:

Must log:

• Authentication attempts (success/failure)
• Authorization failures (access denied)
• Configuration changes
• Software updates
• Anomalous behavior
• Administrative access

Log protection:

• Logs must be tamper-evident
• Logs encrypted if containing PHI
• Log retention policy (typically 2-7 years)
• Secure transmission of logs to central server

Security Testing Requirements {#security-testing}

Types of Security Testing

FDA expects evidence of security testing in your premarket submission.

1. Static Application Security Testing (SAST)

What it is: Automated analysis of source code for security vulnerabilities

When: During development, before compilation

Tools:

• Open Source: SonarQube, Semgrep, Bandit (Python), Brakeman (Ruby)
• Commercial: Checkmarx, Veracode, Fortify

What it finds:

• SQL injection vulnerabilities
• Cross-site scripting (XSS)
• Buffer overflows
• Hardcoded credentials
• Weak cryptography usage

FDA expects:

• Regular SAST scans during development
• Critical/high findings addressed before release
• Documentation of false positives with justification

2. Dynamic Application Security Testing (DAST)

What it is: Testing running application from the outside (black-box testing)

When: After development, in test environment

Tools:

• Open Source: OWASP ZAP, Nikto
• Commercial: Burp Suite Pro, Acunetix, AppScan

What it finds:

• Authentication bypass
• Session management flaws
• Input validation issues
• Information disclosure
• Configuration problems

FDA expects:

• DAST performed on release candidates
• Testing from attacker’s perspective
• Documentation of findings and fixes

3. Software Composition Analysis (SCA)

What it is: Scanning for known vulnerabilities in third-party components

When: Continuously throughout development and post-market

Tools:

• Open Source: OWASP Dependency-Check, Retire.js
• Commercial: Snyk, WhiteSource, Black Duck

What it finds:

• Known CVEs in dependencies
• License compliance issues
• Outdated components
• Malicious packages

FDA expects:

• Regular SCA scans (at least quarterly)
• Vulnerability remediation plan
• SBOM correlation (SCA results feed SBOM)

4. Penetration Testing

What it is: Simulated cyberattack by security professionals

When: Prior to release, annually post-market

Who: Third-party security firm (recommended for objectivity)

Methodology:

• Reconnaissance (information gathering)
• Vulnerability analysis
• Exploitation attempts
• Post-exploitation (how far can attacker go?)
• Reporting and remediation

Scope examples:

• Network penetration test: Can attacker access device from hospital network?
• Web application penetration test: Can attacker compromise cloud service?
• Physical penetration test: What if attacker has physical access to device?
• Wireless penetration test: Can Bluetooth/WiFi be exploited?

FDA expects:

• Penetration test report in premarket submission
• Critical findings must be remediated before submission
• Retesting to verify fixes

5. Fuzz Testing

What it is: Sending malformed/unexpected inputs to find crashes or unexpected behavior

When: During verification testing

What to fuzz:

• Network protocol parsers
• File format parsers (DICOM, HL7, XML, JSON)
• User input fields
• API endpoints
• Command interfaces

Tools:

• Open Source: AFL (American Fuzzy Lop), Peach Fuzzer
• Commercial: Synopsys Defensics, Beyond Security beSTORM

FDA expects:

• Fuzz testing for devices that accept untrusted inputs
• Documentation of crashes found and fixed
• Proof that device fails safely (doesn’t enter unsafe state)

6. Vulnerability Scanning

What it is: Automated scanning for known vulnerabilities in device software/OS

When: Regularly during development and post-market

Tools:

• Open Source: OpenVAS, Nmap
• Commercial: Nessus, Qualys, Rapid7

What it finds:

• Missing security patches
• Misconfigurations
• Default credentials
• Unnecessary open ports
• Outdated protocols (SSLv3, TLS 1.0)

FDA expects:

• Regular vulnerability scans (monthly minimum)
• Remediation tracking
• Justification for unpatched vulnerabilities (if any)

Security Testing Documentation

FDA submission must include:

1. Test Plan
   • Types of testing performed
   • Tools used
   • Test environment description
   • Acceptance criteria
2. Test Reports
   • Summary of findings
   • Critical/high vulnerabilities found
   • Remediation actions taken
   • Re-test results
3. Known Limitations
   • Any security testing NOT performed (with justification)
   • Known residual vulnerabilities (with risk justification)

Post-Market Cybersecurity Management {#postmarket-cybersecurity}

Vulnerability Management Plan

FDA requires a plan for how you’ll handle vulnerabilities discovered AFTER market release.

1. Vulnerability Monitoring

Sources to monitor:

Public Databases:

• NVD (National Vulnerability Database) – CVE listings
• US-CERT – CISA alerts
• ICS-CERT – Industrial control systems (includes medical devices)
• VulnDB – Commercial vulnerability database

Vendor Notifications:

• Component vendor security advisories
• OS vendor security bulletins
• Cloud service provider security notices

Security Research:

• Security researcher disclosures
• Bug bounty programs (if you run one)
• Conference presentations

Internal Sources:

• Customer reported issues
• Internal security testing
• Penetration test findings
• Medical Device Reports (MDRs) with security component

2. Vulnerability Assessment Process

When vulnerability is discovered:

Step 1: Triage (Within 24-48 hours)

• Is this vulnerability actually present in your device?
• What is the CVSS score? (Common Vulnerability Scoring System)
• Is it exploitable in your device’s use environment?

Step 2: Risk Assessment (Within 5 days)

• What’s the potential patient impact?
• How likely is exploitation?
• What mitigations exist (defense in depth)?
• Overall risk rating: Low, Medium, High, Critical

Step 3: Remediation Decision (Within 14 days)

3. Patch Management

Secure patching process:

Patch Development:

• Fix vulnerability in code
• Run full regression testing
• Perform security testing on patch
• Update SBOM
• Document changes

Patch Deployment:

• Code signing
• Phased rollout (pilot sites first)
• Monitoring for adverse events
• Rollback capability

Customer Communication:

• Security advisory (what, impact, action required)
• Installation instructions
• Support contact

4. Coordinated Vulnerability Disclosure

If a security researcher finds a vulnerability:

Responsible disclosure process:

1. Researcher reports vulnerability to manufacturer (not public)
2. Manufacturer acknowledges receipt (24-48 hours)
3. Manufacturer investigates and develops fix
4. Researcher and manufacturer agree on public disclosure date
5. Patch released BEFORE public disclosure
6. Public disclosure with credit to researcher

FDA expects:

• Clear vulnerability reporting mechanism (security@yourcompany.com)
• Documented disclosure policy
• Timely response to researchers

Common Vulnerabilities in Medical Device Software {#common-vulnerabilities}

Top 10 Medical Device Vulnerabilities (Based on FDA Recalls & ICS-CERT)

1. Hard-Coded Credentials

The Problem:

• Default usernames/passwords embedded in code
• Same credentials across all devices
• Credentials easily discovered

Real Example: 2019 – Cardiac device had default password “admin/admin” accessible via network

Fix:

• No default credentials
• Force password change on first use
• Unique credentials per device
• Password complexity requirements

2. Weak Authentication

The Problem:

• Simple PINs (4-6 digits)
• No account lockout
• No session timeout
• Single-factor authentication for critical functions

Real Example: 2018 – Insulin pump controllable with 4-digit PIN, no lockout

Fix:

• Strong passwords (12+ characters)
• Account lockout after failed attempts
• Session timeouts
• MFA for high-risk functions

3. Unencrypted Communications

The Problem:

• Sensitive data transmitted in cleartext
• Using deprecated protocols (SSLv3, TLS 1.0)
• No certificate validation

Real Example: 2017 – Patient monitoring system transmitted patient data unencrypted over WiFi

Fix:

• TLS 1.2+ for all network communications
• Certificate pinning
• Validate server certificates

4. Insufficient Input Validation

The Problem:

• SQL injection
• Command injection
• XML external entity (XXE) attacks
• Buffer overflows

Real Example: 2020 – Hospital information system vulnerable to SQL injection allowing database access

Fix:

• Validate all inputs (whitelisting)
• Parameterized queries (SQL)
• Input length limits
• Output encoding

5. Insecure Software Updates

The Problem:

• Unsigned updates
• Update server not authenticated
• No integrity checking
• Insecure update channel

Real Example: 2019 – Medical imaging system accepted unsigned firmware updates over network

Fix:

• Cryptographic code signing
• Server authentication
• Integrity checking (hash verification)
• Encrypted update channel

6. Improper Access Control

The Problem:

• All users have admin privileges
• No role-based access control
• Privilege escalation vulnerabilities
• Direct object references

Real Example: 2021 – EHR system allowed nurses to access psychiatry notes they shouldn’t see

Fix:

• Role-based access control (RBAC)
• Principle of least privilege
• Access control checks on all functions
• Audit logging

7. Insecure Data Storage

The Problem:

• Sensitive data stored unencrypted
• Improper key management
• Data not securely wiped
• Logs containing PHI

Real Example: 2020 – Mobile health app stored patient data unencrypted on device

Fix:

• Encrypt all sensitive data at rest (AES-256)
• Secure key management
• Secure data deletion
• Sanitize logs

8. Known Vulnerable Components

The Problem:

• Using old versions of libraries with known CVEs
• Not updating third-party components
• Unpatched operating systems

Real Example: 2021 – Medical device using OpenSSL version with Heartbleed vulnerability (3 years after disclosure)

Fix:

• Regular component updates
• SCA scanning
• Maintain SBOM
• Patch management process

9. Inadequate Logging & Monitoring

The Problem:

• No security event logging
• Logs not protected
• No anomaly detection
• Can’t perform forensics after incident

Real Example: 2019 – Ransomware attack on hospital, no logs to determine how attackers got in

Fix:

• Log all security-relevant events
• Tamper-evident logs
• Centralized logging
• Anomaly detection

10. Physical Security Weaknesses

The Problem:

• Debug ports accessible
• USB ports allow unauthorized access
• No tamper detection
• Bootloader not secured

Real Example: 2018 – Pacemaker programmer had USB port allowing malware installation

Fix:

• Disable unnecessary physical interfaces
• Secure boot
• Tamper-evident seals
• Physical access controls

FDA Submission Requirements {#fda-submission}

Cybersecurity Documentation in Premarket Submissions

For 510(k), De Novo, and PMA submissions, you must include:

Section 1: Cybersecurity Management Plan

Document your overall approach:

• How cybersecurity is integrated into design process
• Organizational roles and responsibilities
• Quality system integration (ISO 13485)
• Risk management integration (ISO 14971)

Include:

• Organizational structure (who’s responsible for security?)
• Training programs (how do developers learn secure coding?)
• Design review process (security checkpoints)

Section 2: Threat Model

Comprehensive threat analysis:

• Architecture diagrams with trust boundaries
• Asset identification
• Threat identification (STRIDE or equivalent)
• Risk ratings
• Mitigation strategies

Format: Can be in document form or use established threat modeling tools output (Microsoft Threat Modeling Tool, OWASP Threat Dragon)

Section 3: Security Architecture

Detailed security design:

• Security controls implemented
• Authentication mechanisms
• Encryption methods
• Access controls
• Secure communications
• Update mechanism

Include:

• Architecture diagrams
• Data flow diagrams
• Security control justifications
• Trade-off analysis (where security and usability conflict)

Section 4: Software Bill of Materials (SBOM)

Complete component inventory:

• All software components (direct and transitive)
• Version numbers
• Known vulnerabilities
• License information

Format: SPDX or CycloneDX format

Section 5: Security Testing Results

Evidence of security testing:

• Types of testing performed (SAST, DAST, penetration testing, etc.)
• Testing methodology
• Tools used
• Findings summary
• Remediation actions
• Re-test results

Include:

• Test plans
• Test reports
• Penetration test executive summary
• Vulnerability scan results

Section 6: Vulnerability Management Plan

Post-market security plan:

• How you’ll monitor for new vulnerabilities
• Vulnerability assessment process
• Remediation timelines
• Patch deployment process
• Customer communication plan
• Coordinated disclosure policy

Section 7: Secure Development Practices

Your secure SDLC:

• Secure coding standards
• Code review process
• Security training
• Configuration management
• Third-party component vetting

Reference standards:

• OWASP Secure Coding Practices
• CWE Top 25 (Common Weakness Enumeration)
• CERT Secure Coding Standards

Common FDA Deficiency Letters (Cybersecurity)

FDA’s most common cybersecurity-related requests:

1. “Your SBOM is incomplete”
   • Missing transitive dependencies
   • No version information
   • No vulnerability assessment
2. “Provide evidence of penetration testing”
   • No penetration test performed
   • Penetration test too limited in scope
   • High findings not remediated
3. “Your authentication is insufficient”
   • Simple passwords accepted
   • No MFA for critical functions
   • Shared credentials
4. “Describe your secure update process”
   • No code signing mentioned
   • Insecure update channel
   • No rollback capability
5. “Your threat model is too generic”
   • Copy-pasted from another device
   • Not specific to your architecture
   • Missing obvious threats

Cost, Timeline & Resources {#cost-timeline}

Cybersecurity Implementation Costs

Initial Implementation (New Device):

Small Device (Mobile App, Simple SaMD):

• Security architecture design: $20K-$40K
• Secure development practices: $30K-$50K
• Security testing: $30K-$60K
• Penetration testing: $15K-$30K
• SBOM creation: $5K-$15K
• Documentation: $10K-$20K
• Total: $110K-$215K

Medium Device (Connected Device, Moderate Complexity):

• Security architecture design: $40K-$80K
• Secure development practices: $50K-$100K
• Security testing: $60K-$120K
• Penetration testing: $25K-$50K
• SBOM creation: $15K-$30K
• Threat modeling: $20K-$40K
• Documentation: $20K-$40K
• Total: $230K-$460K

Large Device (Complex System, Multiple Components):

• Security architecture design: $80K-$150K
• Secure development practices: $100K-$200K
• Security testing: $120K-$250K
• Penetration testing: $50K-$100K
• SBOM creation/tools: $30K-$60K
• Threat modeling: $40K-$80K
• Third-party security consulting: $50K-$100K
• Documentation: $40K-$80K
• Total: $510K-$1,020K

Retrofitting (Existing Device): Add 30-50% to above costs (more difficult to add security after the fact)

Ongoing Costs (Annual)

Cybersecurity Maintenance:

• Vulnerability monitoring: $20K-$50K/year
• SCA scanning (tools): $10K-$30K/year
• Annual penetration testing: $25K-$50K/year
• Patch development and deployment: $50K-$150K/year
• SBOM maintenance: $10K-$25K/year
• Security incident response (when needed): $50K-$500K+ per incident
• Total: $165K-$305K/year (excluding incidents)

Timeline

Implementing Cybersecurity (New Device):

• Security architecture design: 2-3 months
• Secure development (parallel with regular development): ongoing
• Security testing: 2-4 months
• Documentation: 1-2 months
• Total: 6-12 months (much of this parallel with development)

Cybersecurity Remediation (Existing Device):

• Security assessment: 1-2 months
• Architecture redesign: 2-4 months
• Implementation: 6-12 months
• Testing: 2-4 months
• Total: 12-24 months

Tools & Resources

Essential Security Tools:

Free/Open Source:

• OWASP ZAP – DAST testing
• SonarQube – SAST scanning
• OWASP Dependency-Check – SCA scanning
• Syft – SBOM generation
• OpenVAS – Vulnerability scanning

Commercial (Worth the Investment):

• Snyk – Comprehensive SCA ($900-$3,000/year)
• Burp Suite Pro – Web security testing ($449/year)
• Nessus Professional – Vulnerability scanning ($3,000-$5,000/year)
• Black Duck – Enterprise SCA ($10K-$100K+/year)
• Checkmarx – Enterprise SAST ($20K-$100K+/year)

Security Consulting (When to Hire):

Definitely hire experts for:

• Initial threat modeling (first time)
• Penetration testing
• Incident response
• Cryptography implementation
• Secure architecture review

May do in-house:

• Routine vulnerability scanning
• SBOM maintenance
• Security testing (after training)
• Code reviews

Conclusion: Cybersecurity is Not Optional

Medical device cybersecurity is no longer a “nice to have” or something to “address later.”

The Reality in 2026:

• FDA WILL reject submissions lacking adequate cybersecurity
• Cyberattacks on medical devices ARE happening
• Healthcare organizations ARE holding manufacturers accountable
• Liability for cyber incidents IS increasing

But with proper planning:

• Cybersecurity can be integrated into your existing development process
• Costs are manageable when built in from the start
• Tools and frameworks exist to help
• It’s achievable for companies of all sizes

Key Takeaways:

1. Start early – Security by design, not security by afterthought
2. Use tools – Automate SBOM, vulnerability scanning, security testing
3. Document everything – FDA wants evidence, not promises
4. Plan for post-market – Vulnerabilities will be found after release
5. Get expert help – For penetration testing, threat modeling, architecture review
6. Budget realistically – $110K-$1M depending on complexity
7. Build it into your process – Security becomes part of how you develop, not a separate activity

The Opportunity: Companies that embrace cybersecurity early will:

• Get through FDA faster (fewer deficiency letters)
• Avoid costly recalls
• Win healthcare system contracts (they’re demanding security)
• Differentiate in the market
• Sleep better at night

Need Expert Cybersecurity Guidance?

Implementing FDA cybersecurity requirements for medical device software doesn’t have to be overwhelming.

AptSkill MedTech offers:

✅ Cybersecurity Gap Assessment – We’ll review your device and identify what’s missing
✅ Threat Modeling Workshops – We’ll guide you through structured threat analysis
✅ SBOM Creation & Management – We’ll help you build and maintain your SBOM
✅ Security Testing Strategy – We’ll define your testing approach and tool selection
✅ FDA Submission Preparation – We’ll help you compile your cybersecurity documentation
✅ Remediation Planning – Already have a device on market? We’ll help you retrofit security

Schedule Your Cybersecurity Consultation

Don’t let cybersecurity requirements delay your FDA submission.

Our regulatory and cybersecurity experts have helped dozens of medical device companies comply with FDA’s 2023 cybersecurity guidance, including:

• AI/ML diagnostic algorithms
• Connected patient monitoring systems
• Mobile health applications
• Cloud-based SaMD platforms
• Legacy device security remediation

📧 Email: contact@aptskillmedtech.com
🌐 Website: AptSkillMedTech.com

First consultation includes:

• Cybersecurity maturity assessment
• Gap analysis against FDA requirements
• SBOM strategy recommendation
• Security testing roadmap
• Budget and timeline estimate

Get ahead of FDA requirements before they become submission delays.

Additional Resources

Standards

• IEC 62443 – Industrial automation and control systems security
• ISO 27001 – Information security management
• NIST Cybersecurity Framework – Identify, Protect, Detect, Respond, Recover
• AAMI TIR57 – Principles for medical device security – Risk management

Online Resources

• CISA ICS-CERT – Medical device vulnerability advisories
• NVD (National Vulnerability Database) – CVE database
• OWASP – Security testing guides and tools
• Mitre ATT&CK – Cybersecurity threat intelligence

Frequently Asked Questions

Do I need cybersecurity documentation if my device isn’t connected to a network?

If your device has ANY software and ANY potential connectivity (even via USB for updates), yes. Very few modern devices are truly exempt.

How often must I update my SBOM?

Every time you release a new software version. Also quarterly vulnerability reviews even if not releasing updates.

What if a critical vulnerability is found in a third-party component I use?

You must assess the risk, develop a patch, and deploy to customers within FDA’s expected timelines (critical = days/weeks, not months).

Can I use the same SBOM format (SPDX vs CycloneDX) across multiple devices?

Yes, but each device needs its own SBOM instance. Pick one format and be consistent.

Do I need a penetration test for a low-risk (Class I) device?

FDA expects security testing appropriate to the risk. Low-risk may not need full penetration testing, but should have vulnerability scanning and basic security testing.

What if I can’t fix a vulnerability because it’s in the underlying OS?

Document it as a residual risk, justify why the device still has acceptable benefit-risk, and explain any mitigations (network segmentation, etc.).

How much does a good penetration test cost?

$15K-$100K depending on device complexity. Plan for 2-4 weeks of testing.

Do I need cybersecurity insurance for my medical device?

Highly recommended. Cyber liability insurance ($1M-$5M coverage) costs $5K-$50K/year depending on device.