# FDA and CISA cybersecurity requirements for medical devices

{% hint style="warning" %}
**IMPORTANT:** This topic was last updated following the June 2025 major FDA guidance update. Although Medcrypt attempts to keep this up-to-date, you should always check the latest guidances.
{% endhint %}

> "The future of cybersecurity is not in building higher walls but in building smarter systems that can adapt and learn from each new challenge".
>
> -Dan Schulman, CEO of Paypal

## Major FDA updates (June 2025)

**Critical changes you need to know:**

* **New expanded "cyber device" definition** - devices meeting [all three criteria](#what-defines-a-cyber-device-now) now qualify
* **Secure Product Development Framework (SPDF) strongly encouraged** for all submissions
* **Enhanced documentation requirements** for eSTAR submissions
* **"Security by design" now legally required** under 21 CFR Part 820

### **Applicability and timing**

* **For devices submitted before March 29, 2023:** The cybersecurity requirements do not apply to applications submitted before this date.
* **For previously authorized devices:** If you're making changes that require premarket review, the cybersecurity requirements apply to the new submission.

{% hint style="danger" %}
**Important exceptions:**

* **Class III devices or changes requiring new 510(k):** Almost all changes must be reviewed, and unreported changes must still be documented annually
* **Post-market requirements still apply:** You're still required under 21 CFR 820 and 806 (corrections/removals) to manage post-market cybersecurity issues per the post-market guidance
  {% endhint %}

***

## FDA risk mitigation overview

{% hint style="warning" %}
This is not intended to be an exhaustive list. We recommend that you consult FDA resources to plan and implement risk mitigation strategies.&#x20;
{% endhint %}

According to the FDA's latest guidance, you must now demonstrate **"reasonable assurance of cybersecurity"** through:

### Core requirements (updated June 2025):

1. **Secure Product Development Framework (SPDF)** integrated into your quality management system
2. Strategy for identifying, monitoring, and addressing cybersecurity vulnerabilities and exploits
3. Plan for coordinated vulnerability disclosure and incident response protocols
4. Plan for post-market updates and patches on both regular and emergency cycles
5. **Software Bill of Materials (SBOM)** for all commercial, open-source, and off-the-shelf components

## CISA cyber incident reporting requirements

### **Timeline**

* **Final Rule:** Expected October 2025
* **Implementation:** 2026
* **Applies to:** 316K+ entities including hospitals and medical device manufacturers

### **Reporting deadlines**

* **Major cyber incidents:** Report to CISA within **72 hours**
* **Ransomware payments:** Report to CISA within **24 hours**
* **Affected entities:** Critical infrastructure including healthcare facilities and device manufacturers

### **What you need to prepare NOW**

1. Determine if you're a "covered entity" under CIRCIA
2. Establish incident response procedures with these tight timelines
3. Set up reporting capabilities through CISA's new portal
4. Train your team on rapid incident identification and reporting

> "The pace of technological change requires us to rethink our strategies for security, and embrace a proactive, not reactive, mindset."
>
> -Bruce Schnier

***

## What defines a cyber device now?

{% hint style="success" %}
**Key takeaway:** If you didn't specifically design your device to NOT be connected, FDA assumes it CAN be connected.
{% endhint %}

The FDA now considers a device a "cyber device" if it meets the following three criteria:

1. **Contains software** (validated, installed, or authorized by sponsor)
2. **Has ability to connect to internet** (intentionally OR unintentionally)
3. **Contains technological characteristics** that could be vulnerable to cybersecurity threats

#### **⚠️ Critical change:**

**ANY** of these interfaces now make your device "connectable" unless you can prove otherwise:

* USB ports, Ethernet connections, serial ports
* Wi-Fi, Bluetooth, Bluetooth Low Energy, cellular
* RF communications, cloud connections
* Any hardware connector capable of internet connectivity

## **New mandatory requirements for cyber devices**

### **1. Secure Product Development Framework (SPDF)**

* Must be integrated into your quality management system
* Covers entire Total Product Lifecycle (TPLC)
* Requires "security by design" from first line of code
* Must demonstrate cybersecurity design controls under 21 CFR Part 820

### **2. Required documentation**

Your submission must include comprehensive cybersecurity documentation scaling with your device's risk level:

**Core documents:**

* Cybersecurity risk assessment and management plan
* Threat modeling analysis
* SPDF implementation evidence
* SBOM (following NTIA minimal requirements)
* Vulnerability monitoring and management plan
* Penetration testing reports
* Security architecture documentation

### **3. Five critical security objectives**

Your device must address:

1. **Authenticity:** Verify device/user identity
2. **Authorization:** Control access appropriately
3. **Availability:** Maintain device functionality
4. **Confidentiality:** Protect sensitive data
5. **Secure updatability:** Enable safe patches/updates

## **What does a medical device encompass?**

> "The definition of a medical device encompasses not only capital equipment, but also surgical instruments, patient monitoring, and even software. The breadth and variety of the field, combined with the critical importance of med devices to life and safety, requires a deliberate, focused approach to cybersecurity to ensure that they are resilient throughout their lifecycle."\
> —Nancy Brainerd (CISSP/CIPP), Senior Director of Product Security

**Medical device scope includes:**

* Capital medical equipment
* Surgical instruments with electronic components
* Patient monitoring devices
* Medical software applications
* Connected diagnostic equipment
* Any device with software components and connectivity potential

***

## **FDA requirements deep dive**

### **Post-market cybersecurity vulnerabilities and exploits**

**Section 524B(b)(1)** of the FD\&C Act requires that you provide 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.

### **Update and patch requirements**

* **Known acceptable vulnerabilities:** **Section 524B(b)(2) and 524B(b)(2)(A)** requires that you make available postmarket updates and patches to the device and related systems to address these, on a reasonably justified regular schedule.
* **Critical vulnerabilities that could cause uncontrolled risks:** **Section 524B(b)(2) and 524B(b)(2)(B)** requires that you make available postmarket updates and patches to the device and related systems to address these, as soon as possible out of cycle.
* Must demonstrate capability for both routine and emergency patching throughout the device lifecycle.

### **Documentation standards**

The 2025 guidance emphasizes **risk-based documentation,** thus your submission depth must match your device's cybersecurity risk level, not arbitrary documentation requirements.

***

## **Industry best practices & common pitfalls**

> "The pace of technological change requires us to rethink our strategies for security, and embrace a proactive, not reactive, mindset."\
> —Bruce Schneier

### **🚫 Common risks that lead to FDA rejection**

1. **Using proprietary authentication:**  FDA prefers widely-tested, standard methods
2. **Shared keys across devices:** Each device needs unique cryptographic keys
3. **Unprotected NFC/RFID interfaces:** Can create unexpected vulnerabilities
4. **Missing channel authentication:** Communications must be signed and encrypted
5. **Inadequate threat modeling:** Must cover your specific device and use environment

### **✅ What FDA Wants to See**

* **Comprehensive threat modeling** using recognized frameworks
* **Evidence of security testing** including penetration testing
* **Clear vulnerability management process** with timelines
* **User security information** in device labeling
* **Participation in Information Sharing and Analysis Organization (ISAO)**

***

## **Device labeling requirements**

Your cybersecurity program must address labeling including:

### **User instructions**

* Recommended cybersecurity controls for intended use environment
* Security controls users interact with (passwords, updates, etc.)
* Configuration requirements (firewall recommendations, etc.)

### **Technical documentation**

* Manufacturer Disclosure Statement for Medical Device Security (MDS2)
* Complete SBOM: SBOM must be complete and all required documentation prepared for regulatory submission. While the FDA recommends SBOMs be provided to customers for transparency, this creates additional attack surface exposure that your company must carefully weigh.&#x20;
* Logging capabilities and forensic log capture instructions

## **Creating your updated cybersecurity strategy**

#### **Immediate action items:**

1. **Review the June 2025 FDA guidance:** Download from FDA.gov
2. **Assess if you're a "cyber device"** under expanded definition.
3. **Implement SPDF** into your quality management system.
4. **Prepare for CISA reporting:** Establish incident response procedures.
5. **Update documentation** to meet 12-document requirement for eSTAR submission

#### **Key standards to reference:**

* **AAMI SW96** (now recognized by FDA)
* **ISO 14971** (safety risk management)
* **AAMI TIR 57** (security risk management)
* **IEC 81001-5-1** (health software security)

#### **Technology considerations:**

* Choose widely-tested encryption algorithms
* Implement proper key management with unique device keys
* Plan for secure update mechanisms
* Design with hardware resource constraints in mind
* Ensure audit logging capabilities
* **SBOM disclosure trade-offs:** Balance FDA's transparency recommendations against increased attack surface exposure from revealing component details to potential threat actors.

***

## **Resources and next steps**

**June 2025 FDA Guidance:**

#### **Official FDA resources:**

* **June 2025 guidance (PDF):** <https://www.fda.gov/media/173516/download>
* **Guidance page:** <https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions>
* **FDA Cybersecurity FAQs:** <https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs>
* **FDA Cybersecurity main page:** <https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity>

#### **CISA resources:**

* **CIRCIA Information:** <https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia>
* **CISA Services portal:** For incident reporting when requirements take effect

#### **Industry tools:**

* **MITRE Medical Device Playbooks:** Incident response and threat modeling guidance (<https://www.mitre.org/news-insights/publication/medical-device-cybersecurity-regional-incident-preparedness-and-response> - playbook PDF must be downloaded from site)
* **MedISAO:** Information sharing organization for medical device cybersecurity (<https://www.medisao.com/>)

***

## **Key takeaways**

{% hint style="success" %}
**Bottom line:** Cybersecurity is now inseparable from device safety and effectiveness. The FDA's 2025 guidance makes this a central pillar of medical device compliance requiring proactive, lifecycle-integrated security management.
{% endhint %}

* **The cybersecurity landscape has fundamentally shifted:** This is no longer optional compliance but a core safety requirement.
* **"Security by design" is now law:** Integrate SPDF into your development process immediately.
* **CISA reporting is coming fast:** Prepare your incident response procedures now.
* **Documentation requirements have expanded significantly:** Budget time and resources accordingly.
* **Device connectivity definitions are much broader:** Assume your device is "connectable" unless you can prove otherwise.
