If your medical device is a cyber device, FDA cybersecurity planning is now a filing issue, a design issue, and a postmarket issue all at once. Since March 29, 2023, submissions have needed Section 524B cybersecurity information. And since October 1, 2023, missing or inaccurate eSTAR cybersecurity content can put a 510(k) on technical screening hold.

Here’s the short version: if I were building this plan, I’d make sure it does 6 jobs from the start:

  • Confirm scope: decide whether the product meets the FDA’s cyber device definition
  • Map the system: list software, interfaces, cloud services, apps, and deployment settings
  • Tie cyber risk to patient harm: connect exploitability to ISO 14971 safety risk
  • Define controls and proof: link each threat to a control and each control to a test
  • Prepare submission records: keep SBOM, threat model, test reports, labeling, and risk files ready for eSTAR
  • Plan after launch: monitor CVEs, triage reports, patch issues, and feed findings back into the QMS

A few facts stand out:

  • FDA expects cybersecurity to sit inside the QMS, not in a separate side process
  • The SBOM should be machine-readable, such as CycloneDX or SPDX
  • Reviewers may expect items like threat models, architecture diagrams, risk reports, pen test results, labeling, and a postmarket vulnerability plan
  • For postmarket work, many teams use time targets like 4 hours for initial review of a critical issue and 30 days for patch development

If I had to reduce the whole article to one line, it would be this: build one traceable chain from threat -> control -> test -> record -> submission -> postmarket action.

That’s what FDA reviewers, quality teams, and security teams all need to see.

FDA Medical Device Cybersecurity Compliance: Lifecycle Process at a Glance

FDA Medical Device Cybersecurity Compliance: Lifecycle Process at a Glance

Cybersecurity for Medical Devices – FDA 510(k) Cyberecurity Compliance | In-Focus

1. Define Scope, Standards, and Required Artifacts

Once the device is confirmed as in scope, the next job is simple to state but harder to do well: spell out the standards, documents, and proof FDA reviewers will expect in a premarket submission that can hold up under review.

Inventory Devices, Software Components, and Deployment Environments

For each in-scope cyber device, map the full technical footprint. That includes every hardware interface, such as USB, Ethernet, serial ports, and inductive communications, plus each wireless protocol, including Wi-Fi, Bluetooth, BLE, and cellular. It also includes every software layer: firmware, operating system, third-party libraries, open-source components, APIs, and cloud dependencies [4][1].

Split hospital and home deployments into separate records. That matters because PHI, telemetry, credentials, and clinical functions can cross trust boundaries in different ways depending on the setting [4]. Removable media and scheduled maintenance connections should also appear clearly in the architecture and data-flow diagrams [1].

In plain terms, you’re drawing the actual edge of the system, not the edge you wish you had. If a field technician plugs into it, if a cloud service touches it, or if data moves across a boundary, it belongs on the map.

Once that technical boundary is clear, connect those assets to the development framework and control standard.

Align the Plan with SPDF and Recognized Standards

FDA points to a Secure Product Development Framework (SPDF) as the lifecycle approach to use, and it should sit inside the organization’s ISO 13485 quality system, not beside it as a separate track [5]. In practice, that means mapping SPDF work to ISO 13485 design planning, risk management, verification, validation, release, feedback, and corrective action.

For standards, base the plan on IEC 81001-5-1 or JSP2 (Joint Security Plan). Cybersecurity risk management should also tie into ISO 14971, since cyber risk has to be handled alongside safety risk [5].

"The rules of the game have changed. The landscape now is to design controls in, period. The FDA's cybersecurity authority is no longer based solely on risk assessments. It's based on statute, and statute says you must prove secure by design." - Naomi Schwartz, VP of Regulatory Strategy, Medcrypt [3]

That structure should shape the evidence package the FDA will review.

List the Core Documents FDA Reviewers Expect

FDA reviewers expect a defined set of artifacts. The main ones include:

  • A cybersecurity risk management report that connects technical exploitability, using CVSS scoring, to patient safety impact under ISO 14971 [2]
  • Threat modeling outputs and data flow diagrams that show trust boundaries and attack surfaces [2]
  • A Software Bill of Materials (SBOM) that covers all proprietary, third-party, and open-source components [1][3]
  • Security architecture diagrams, with views for update paths, patchability, and multi-patient risk [2]
  • Security test evidence from fuzzing, static and dynamic code analysis, and penetration testing [1][4]
  • Cybersecurity labeling with instructions for secure configuration, user responsibilities, and update procedures [1][4]
  • A post-market vulnerability management plan that covers coordinated disclosure and patching procedures [1][2]

One detail is easy to miss: the SBOM shouldn’t be treated like a one-time file created right before submission. Generate it continuously in CI/CD so it reflects the current software state [2].

2. Build the Plan Around Risk, Security Controls, and Verification

Run Threat Modeling and Safety-Linked Risk Assessment

Using the inventory and standards from Section 1, turn them into threats, controls, and tests. Frameworks like STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege - and MITRE ATT&CK give you a structured way to spot attack surfaces and trust boundaries across the device, companion app, and cloud layers.

The big point here is simple: assess the device in the environment where it will actually run, not as a standalone box on a bench. In practice, that means thinking about what happens if a Wi-Fi router on a hospital network gets compromised, or if a home health monitor is left unsecured and then used as a stepping stone into your device.

Prioritize threats by combining exploitability with patient harm severity under ISO 14971. Put the deepest analysis on threats that could plausibly lead to serious or catastrophic patient harm, and document that ranking clearly in the risk management file.

This is the point where the plan stops being abstract. Threats turn into controls. Controls turn into verification evidence.

Define Security Requirements and Architecture Controls

Every threat you identify needs a matching control. And each control needs three things: a unique identifier, a testable statement, and a clear implementation point. Keep a control catalog that maps each threat ID to a control ID and test case ID. FDA reviewers want traceability from threat to control to test.

Use the highest-risk findings to set required controls and test coverage. A simple mapping looks like this:

Control Category Example Controls Threat Addressed (STRIDE) Verification Method
Authentication Multi-factor authentication, unique device credentials Spoofing Penetration testing, functional testing
Authorization Role-based access control (RBAC), least privilege Elevation of Privilege Static code analysis, manual code review
Cryptography ECDSA P-256 for update signing, AES-256 for data-at-rest Tampering, Information Disclosure Cryptographic validation, fuzz testing
Integrity Secure boot, hardware root of trust Tampering Boot sequence verification, signature checks
Availability Rate limiting, network segmentation, firewalls Denial of Service Stress testing, network traffic analysis
Audit/Logging Immutable security logs, time synchronization Repudiation Log analysis, forensic simulation

FDA also expects multiple architecture views in the submission: a global system view that shows trust boundaries, an updateability view that covers end-to-end secure patching, and a multi-patient harm view that shows controls stopping lateral movement across a clinical network [2].

Build the SBOM and Plan Security Testing

FDA requires the SBOM in a machine-readable format such as CycloneDX or SPDX [6]. One practical move is to wire a tool like Syft into the CI/CD pipeline so the SBOM updates automatically with every build. If a build introduces critical vulnerabilities, fail it. No hand-waving, no “we’ll fix it later.”

You also need to triage components against vulnerability data. Use Vulnerability Exploitability eXchange (VEX) documents to show which flagged CVEs actually affect the device and which are "not_affected" because of how the code is compiled or deployed [2]. That distinction matters. It shows you did real triage instead of dumping scan output into a file.

Each test report should map back to the control it verifies. FDA expects an unredacted third-party penetration test report, along with a remediation plan for every finding [2][4]. Threat ID, control ID, and test case ID should connect directly so a reviewer can follow the thread without guessing.

Then feed those control-to-test links into the design records and the submission file.

3. Embed Cybersecurity into the QMS and Premarket Submission

Once you’ve defined controls and verification, the next move is to bake them into the QMS and the submission record. Don’t leave cybersecurity sitting in a separate security folder. Under the FDA's QMSR, cybersecurity risk management belongs inside the quality system.

Set up two-way traceability from the threat all the way through the requirement, control, test, result, and DHF. That link should be clear in the Design History File (DHF), software lifecycle records, and risk management file. Use ISO 14971 for safety risk and AAMI TIR57 for the security-to-safety interface.

These records also become the package FDA reviews during submission.

Assemble Cybersecurity Content for FDA Submissions

FDA premarket submissions - whether 510(k), De Novo, or PMA - must go through the eSTAR system. That system includes a dedicated cybersecurity section with 11 specific attachment categories [7]. If attachments are missing or incomplete, the submission can be placed on technical screening hold [7].

Assign each eSTAR deliverable to an owner early in development, not at the last minute. Waiting until submission time to backfill documents is a common way teams slip past a filing deadline. Here’s how key artifacts usually map from the QMS into eSTAR:

Document QMS Location
Threat Model Design History File (DHF)
Cybersecurity Risk Assessment Risk Management File
SBOM Software Lifecycle Records
Security Test Reports Design Verification Records
Cybersecurity Labeling Device Labeling / Instructions for Use
Cybersecurity Management Plan Postmarket Surveillance Plan

If no anomalies remain, eSTAR still requires a statement confirming that point and documenting the security impact assessment [7].

After the submission set is defined, keep every artifact in sync through controlled workflows.

Use Centralized Workflows for Documentation and Oversight

Use centralized document control so engineering, quality, regulatory, and postmarket teams all work from one source of truth. Each cybersecurity artifact should be version-controlled and tied to the submission section it supports. This matters even more now that FDA investigators use the Compliance Program Manual (#7382.850), in effect since February 2, 2026, as a structured enforcement guide during QMS inspections [4]. When an investigator asks for a record, you want to hand over a direct link, not send people digging through folders.

That same control structure sets the baseline for postmarket monitoring and change control.

4. Maintain Compliance Through Postmarket Monitoring and Change Control

Use the postmarket plan from the previous section to keep watch for vulnerabilities, sort incoming reports, and manage software changes after release.

Monitor Vulnerabilities and Triage Reports Continuously

Clearance is the beginning of postmarket control, not the end. Section 524B of the FD&C Act requires manufacturers of cyber devices to maintain a formal plan to monitor, identify, and resolve postmarket vulnerabilities promptly[9].

Your monitoring program should pull signals from more than one place. That usually includes the National Vulnerability Database (NVD), the CISA Known Exploited Vulnerabilities (KEV) catalog, H-ISAC advisories, vendor PSIRTs, internal penetration test feedback, and customer complaints[9]. Once you have a finding, map it to the SBOM so you can see which components are affected and which configurations may be at risk.

It also helps to make reporting easy for outside parties. Publish a public intake channel such as security@company.com or security.txt for Coordinated Vulnerability Disclosure[9].

Prioritize Remediation, Updates, and Regulatory Decisions

Triage should be risk-based. In plain English, that means combining CVSS with clinical impact to decide how fast the team needs to act[9]. The table below shows common FDA-aligned response targets for Critical and High findings[9]:

Vulnerability Risk Level Initial Assessment SLA Patch Development SLA Patch Deployment SLA
Critical (CVSS ≥ 9.0, active exploit) 4 hours 30 days 60 days
High (CVSS 7.0–8.9, safety impact) 24 hours 90 days 120 days

Medium and Low findings should go into the next major release cycle. Low-severity issues should be resolved within the annual update at a minimum.

After triage, pick the right path: patch, mitigation, or regulatory escalation. A software patch is usually the first choice. But if a patch can't ship right away, a temporary compensating control can lower exposure while the fix is being built. Every remediation decision also needs a regulatory check. Does the change fit inside your current 21 CFR 820.30 change control process, or does it trigger a new premarket submission? If your device has an FDA-authorized Predetermined Change Control Plan (PCCP), some cybersecurity updates may ship without a new 510(k)[4].

"A vulnerability that would be a one-hour hotfix in SaaS is a multi-month change-controlled event tied to 21 CFR Part 820 and ISO 14971." - Christian Espinosa, Founder & CEO, Blue Goat Cyber [8]

If a cybersecurity event may affect patient safety, assess MedWatch reporting under 21 CFR 803 and test that decision path in tabletop exercises[8].

Feed Postmarket Findings Back into the SPDF

Each postmarket finding should flow back into the risk file, SBOM, VEX, and change-control records. This is where postmarket work stops being a one-off task and becomes part of the SPDF. The table below shows how common postmarket events map to evaluation steps, documentation outputs, and communication actions[9]:

Postmarket Event Required Evaluation Steps Documentation Outputs Communication Needs
New CVE Identified Correlate with SBOM; assess exploitability via CVSS; determine patient safety impact. Updated Risk Analysis; VEX Document; SBOM update. Internal engineering alert; Security researcher acknowledgment (if CVD).
Security Incident / Exploit Activate Emergency Response Team; conduct root cause analysis; identify clinical impact. Incident Report; CAPA file; DHF update. FDA (MDR reporting if safety-related); customer safety alert (within 24 hours).
Third-Party Component Update Regression testing; security verification of new version; impact on existing controls. Change Control record; Updated Traceability Matrix; Verification Test Report. Customer release notes; updated administrative guidance.
Customer Security Complaint Triage via Complaint Handling system; verify vulnerability; assess systemic risk. Complaint record; CAPA (if systemic); Risk Management File update. Direct customer response; Coordinated industry sharing (H-ISAC).
End-of-Life (EOL) Component Assess the risk of unpatchable components. EOL Migration Plan; Risk Acceptance File. Customer notification (minimum 90 days).

Two KPIs for healthcare cybersecurity can help show prompt response to FDA: Mean Time to Triage (MTTT), with a target of ≤ 5 days for Critical and High findings, and Mean Time to Patch (MTTP), with a target of ≤ 30 days for Critical vulnerabilities and ≤ 90 days for High vulnerabilities[8]. Track both over time to show steady response performance.

Conclusion: A Repeatable Process for FDA-Compliant Cybersecurity Planning

Postmarket monitoring closes the loop. But it only works when the earlier steps were built into the same lifecycle process from the start. FDA cybersecurity compliance isn't a one-and-done paperwork task. It's a lifecycle process: classify, design, verify, submit, and monitor.

What connects every phase is traceability. Each threat you identify should link to a specific control. That control should link to a verification test. And that test should link to documented results. That's the evidence FDA reviews. In plain English, traceability is the thread running through the whole process.

The table below shows how each phase fits into a repeatable compliance workflow.

Lifecycle Phase Key Repeatable Step Primary Evidence
Pre-Design Device Classification Device Classification Record
Design Threat Modeling Data Flow Diagrams (DFDs) & STRIDE Analysis
Development Risk Management Security Risk Management File (CVSS + ISO 14971)
Verification Security Testing Penetration Test & Fuzzing Reports
Submission Submission Package Traceability Matrix & SBOM
Postmarket Postmarket Monitoring Vulnerability Management Plan & VEX

Section 524B makes cybersecurity an explicit, auditable part of a device's safety and effectiveness [1]. Manufacturers that treat cybersecurity as a lifecycle discipline, instead of a one-time submission task, are in a much better position to stay compliant as vulnerabilities change.

FAQs

Does my device qualify as a cyber device?

Under Section 524B(c) of the FD&C Act, a device counts as a cyber device if it:

  • includes software validated, installed, or authorized by the sponsor
  • can connect to the internet
  • has technological characteristics that could be vulnerable to cybersecurity threats

Examples include networked diagnostics, monitors, and cloud-connected accessories. If you're unsure, you may contact the FDA directly.

What documents do I need for FDA cybersecurity review?

For FDA cybersecurity review for Section 524B cyber devices, include a premarket cybersecurity package with:

  • a threat model and risk assessment
  • traceability from threats and risks to security requirements and controls
  • security architecture diagrams and cybersecurity labeling
  • a machine-readable SBOM
  • a vulnerability management plan, testing evidence, and a postmarket management plan

How should we handle vulnerabilities after launch?

After launch, manufacturers need a postmarket program to monitor, spot, and fix vulnerabilities. Keep an accurate, up-to-date SBOM and connect it to automated threat intelligence feeds.

When a vulnerability is found, assess whether the risk is controlled or uncontrolled. If the risk is uncontrolled, notify customers within 30 days, share interim mitigations, and remediate critical issues within 60 days.

Document all activities in your Quality Management System, including coordinated vulnerability disclosure.

Related Blog Posts