5 Steps for FDA-Compliant Cybersecurity Risk Assessments

Modern medical devices are more connected than ever, which improves healthcare but also increases cybersecurity risks. The FDA requires manufacturers to follow a structured process to address these vulnerabilities. This guide breaks down the five essential steps for conducting an FDA-compliant cybersecurity risk assessment:

1. Establish a Cybersecurity Risk Management Framework
   • Integrate cybersecurity into your Quality Management System (QMS).
   • Use a Secure Product Development Framework (SPDF) aligned with ISO 13485 standards.
   • Define risk acceptance criteria and ensure traceability of all risks and controls.
2. Perform Threat Modeling and Asset Identification
   • Identify critical assets and map system architecture.
   • Conduct structured threat modeling (e.g., S.T.R.I.D.E.) to pinpoint vulnerabilities.
   • Document outputs like Data Flow Diagrams (DFDs) and attack surface analyses for FDA submissions.
3. Analyze and Evaluate Cybersecurity Risks
   • Map threats to hazardous situations affecting patient safety.
   • Score risks based on severity and exploitability, not historical probability.
   • Compare risks against predefined acceptance thresholds.
4. Implement and Verify Risk Controls
   • Apply technical, procedural, physical, and system-level controls.
   • Incorporate a Software Bill of Materials (SBOM) for component-level risk tracking.
   • Validate controls with methods like penetration testing and vulnerability scanning.
5. Determine Residual Risk and Monitor Postmarket
   • Assess remaining risks after mitigation and document them clearly.
   • Set up a plan for continuous monitoring and updates throughout the device's lifecycle.
   • Address vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) Catalog.

This framework ensures your devices meet FDA cybersecurity requirements while protecting patient safety and data integrity.

Webinar: Master Medical Device Cybersecurity: Avoid FDA Delays

sbb-itb-535baee

Step 1: Establish a Cybersecurity Risk Management Framework

Creating a framework for identifying, evaluating, and managing critical medical device security risks is essential for navigating the lifecycle of a device. Without a structured approach, risk assessments can become inconsistent, difficult to justify during FDA reviews, and nearly impossible to replicate.

Define Governance, Scope, and Documentation

To align with FDA requirements, you need to integrate cybersecurity risk management into your Quality Management System (QMS). Starting February 2, 2026, the FDA's updated Quality Management System Regulation (QMSR) will incorporate ISO 13485:2016. This means cybersecurity documentation must flow through controlled QMS processes rather than being added as an afterthought during submission ^[2].

The FDA recommends employing a Secure Product Development Framework (SPDF) as the foundation for the lifecycle structure, explicitly mapped to ISO 13485 clauses. Cybersecurity must be embedded into your design and development processes:

SPDF Phase	ISO 13485 Process Link
Security Planning	Design planning (7.3.2) + Risk management (7.1)
Threat Modeling	Design inputs (7.3.3)
Secure Design/Coding	Design development (7.3.4) + Production controls (7.5)
Security Testing	Design verification (7.3.6) + Design validation (7.3.7)
Vulnerability Response	Corrective action (8.5.2)

Your Security Risk Management Plan should clearly define the device's boundaries, the systems it connects to, and the scope of the assessment. It should also establish how cybersecurity risks impacting patient safety will be formally integrated into your ISO 14971 safety risk process. Bidirectional traceability is critical - every identified threat must link to a specific risk entry and a corresponding control.

"The rules of the game have changed. Manufacturers that treat cybersecurity as a documentation exercise rather than a design discipline are receiving multi-page deficiency letters that delay market authorization." - Naomi Schwartz, VP of Regulatory Strategy, Medcrypt ^[2]

Once governance is in place, the next step is to define clear, actionable criteria for risk acceptance.

Set Risk Acceptance and Evaluation Criteria

Defining what constitutes "acceptable risk" is a key requirement for FDA compliance. This involves setting specific thresholds and documenting them. Both the FDA and ANSI/AAMI SW96:2023 emphasize this point:

"Management shall define and document criteria for security risk acceptability." - ANSI/AAMI SW96:2023 ^[1]

Categorize risks into levels such as Low, Medium, High, and Critical, and tie specific actions to each category. These thresholds should evolve over time to account for advancements in threat actor capabilities. For vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog, the FDA expects these risks to be entirely eliminated. Simply classifying them as "unlikely" is not acceptable ^[1].

Use Tools to Support Workflow and Documentation

Manually documenting threat models, risk registers, and QMS records can lead to inconsistencies and increase the risk of noncompliance. Platforms like Censinet RiskOps™ are designed to streamline the risk management process. These tools help maintain an audit-ready framework, centralize risk tracking, and support collaborative governance. For both healthcare organizations and device manufacturers, such platforms simplify documentation, ensure traceability, and keep the framework organized and defensible throughout the assessment process.

Step 2: Perform Threat Modeling and Asset Identification

Now that you’ve established your governance framework and risk acceptance criteria, it’s time to dive into identifying what needs protection and the threats that could jeopardize it. This step transforms general security concerns into a detailed, actionable understanding of your device’s risk landscape. Let’s break down how to pinpoint assets, model potential threats, and prepare documentation for FDA submissions.

Identify Assets and Map System Architecture

Start by identifying all security-critical assets and mapping out your system’s architecture. Use your existing software architecture diagrams as a foundation, then create Data Flow Diagrams (DFDs). These diagrams illustrate how data moves between components over time, helping you uncover potential vulnerabilities.

Once your DFDs are ready, define your security use cases and compile a comprehensive inventory of assets, including patient data, essential device functions, authentication mechanisms, and external interfaces.

Pay close attention to trust boundaries - where data crosses from one security zone to another, such as between your device and an electronic health record (EHR) system. These boundaries are especially vulnerable and must be carefully documented. The FDA requires you to assess your device’s risks within the broader healthcare ecosystem, considering connections to medical imaging systems, shared authentication methods, and network segmentation practices ^[1].

Conduct Structured Threat Modeling

With your asset inventory and system architecture in hand, it’s time to apply the S.T.R.I.D.E. methodology - a structured approach to identifying threats. The acronym stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege ^[3]. Using this framework ensures your team evaluates threats systematically, which is essential for FDA review.

Cybersecurity threat modeling differs from traditional safety risk assessments because it zeroes in on exploitability - the likelihood that a vulnerability can be exploited:

"Security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system." - FDA Guidance ^[1]

Your analysis must address both intentional attacks and unintentional failures like misconfigurations or human errors. The FDA expects you to assume the worst-case scenario for exploitability unless you can provide strong technical evidence to justify a lower risk rating.

Document Outputs for FDA Submissions

Once your threat modeling is complete, you’ll need to compile several key documents for your FDA submission package:

Deliverable	Key Content	FDA Purpose
Threat Modeling Report	DFDs, asset inventory, S.T.R.I.D.E. analysis, security use cases	Outlines risks and supports pre- and post-mitigation evaluations
Attack Surface Analysis	Details on trust boundaries, interfaces, and network segmentation	Shows awareness of potential exposure points
Master Traceability Matrix	Links Threat ID → Risk ID → SBOM Component → Test Case ID	Helps FDA reviewers trace your security approach end-to-end [4]

Each threat scenario must directly connect to a corresponding risk entry to ensure traceability for FDA reviewers ^[1]. Use a clear numbering system, such as TH-001 for threats and RA-001 for risk assessments, to make navigation straightforward ^[4].

Finally, cross-check your components against CISA’s Known Exploited Vulnerabilities (KEV) Catalog. The FDA mandates that vulnerabilities listed in the KEV Catalog must be eliminated from your device design - not just noted and accepted ^[1]. Ignoring this step or treating these vulnerabilities as minor risks could lead to a deficiency letter.

Step 3: Analyze and Evaluate Cybersecurity Risks

Now that you’ve completed the asset inventory and threat modeling, it’s time to translate those identified threats into clinical risks. This phase builds on the threat model, helping you craft mitigation strategies and determine the appropriate responses to cybersecurity challenges.

Translate Threats into Hazardous Situations

Not every cybersecurity threat directly impacts patient safety. The goal here is to map each identified threat to a specific device malfunction or operational issue that could harm patients or disrupt care. Generally, cybersecurity-related hazardous situations fall into four main categories: loss of device functionality, incorrect device operation, unauthorized access to or corruption of patient data, and disruption of critical device features ^[1]. If a threat aligns with any of these outcomes, it should be incorporated into your safety risk management process under ISO 14971 for clinical impact analysis.

A real-world example highlights the importance of this step. In January 2025, the FDA issued a safety communication regarding the Contec CMS8000 and Epsimed MN-120 patient monitors. The warning highlighted cybersecurity vulnerabilities that could allow unauthorized users to access or alter vital sign data - such as temperature, heartbeat, and blood pressure readings. Such alterations could mislead clinicians into making incorrect treatment decisions ^[5]. This underscores the connection between cybersecurity gaps and patient safety risks.

Estimate Severity and Exploitability

Once hazards are defined, the next step is to assess their potential impact and exploitability. Unlike traditional safety risk management under ISO 14971, where probability is a key factor, cybersecurity risks are evaluated based on exploitability. The FDA emphasizes this distinction:

"Cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data." - FDA 2025 Premarket Cybersecurity Guidance ^[1]

Instead of historical data, risks are scored based on technical factors such as remote versus local attack vectors, attack complexity, privilege requirements, and user interaction. When in doubt, assume the worst-case exploitability unless strong technical evidence supports a lower score. The Common Vulnerability Scoring System (CVSS) provides a useful framework for this evaluation, but it should be tailored to fit the clinical context of your device. Vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) Catalog, for instance, should be treated as foreseeable risks that demand proactive design changes rather than simply being scored and accepted.

Severity is determined by the potential clinical impact. For example, a vulnerability in an insulin pump that could lead to incorrect dosing carries far greater severity than one that exposes non-critical metadata. These severity scores feed into your safety risk file, laying the groundwork for the control measures in Step 4.

Evaluate Risks Against Acceptance Criteria

After scoring the risks for exploitability and severity, compare them against the acceptance thresholds defined earlier in Step 1. This process documents each risk’s status and determines whether it is acceptable as-is, requires additional controls, or demands mitigation. As stated:

"Management shall define and document criteria for security risk acceptability." - ANSI/AAMI SW96:2023 ^[1]

A four-tier framework can help structure this evaluation:

Risk Level	Acceptance Status	Required Action
Low	Acceptable	Standard monitoring and TPLC tracking
Medium	Acceptable with Controls	Enhanced monitoring and documented rationale
High	Requires Mitigation	Additional technical or procedural controls needed
Critical	Unacceptable	Significant risk reduction or mandatory design changes

Time is another critical factor. A risk deemed acceptable at launch might not remain so as threat actor capabilities evolve and exploitation tools become more sophisticated. For example, a Medium risk today could escalate to a High risk in the future ^[1]. To address this, establish dynamic acceptance thresholds that tighten over the device’s Total Product Life Cycle (TPLC).

Every decision - whether to accept, mitigate, or reject a risk - must be thoroughly documented. This documentation should include clear reasoning and be linked to your traceability matrix. It’s crucial not only for internal tracking but also because FDA reviewers will examine it closely during the premarket review process. These records directly inform the control implementation and verification steps covered in Step 4.

Step 4: Implement and Verify Cybersecurity Risk Controls

Once you've scored and documented your risks, the next step is to put controls in place to reduce those risks. This process builds on the analysis from Step 3, turning your findings into actionable measures.

Select and Apply Technical and Procedural Controls

Risk controls can take various forms: technical, procedural, physical, and system-level measures. Here's a breakdown:

• Technical controls: These include essentials like strong encryption, input validation, robust authentication, and fail-safe defaults.
• Procedural controls: These focus on the human element, such as user training, proper configuration management, and maintenance protocols to reduce errors.
• Physical controls: These safeguard against unauthorized access to hardware or device interfaces.
• System-level controls: Measures like network segmentation and trust boundaries help limit an intruder's ability to move laterally if a component is compromised.

When deciding which controls to implement, focus on factors like attack complexity, access type (remote or local), and privilege levels required. It's especially important to address vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog. The FDA expects manufacturers to eliminate these vulnerabilities entirely rather than just document and accept them ^[1].

Integrate SBOM for Component Risk Management

After choosing the right controls, managing component-level risks becomes critical. This is where a Software Bill of Materials (SBOM) comes into play. Think of the SBOM as an inventory of every third-party and open-source component in your device. Without it, you might miss emerging vulnerabilities.

An SBOM allows you to quickly compare your components against the National Vulnerability Database (NVD) and CISA's KEV Catalog to assess your exposure. The FDA emphasizes:

"Known vulnerabilities should be assessed as reasonably foreseeable risks." ^[1]

This isn't something you can ignore. Automate SBOM scanning where possible, and set up a rapid-response plan to address newly identified vulnerabilities. Also, evaluate your vendors based on how quickly they release patches - this can significantly impact your risk profile. Keep in mind, SBOM management isn't a one-time task; it's a Total Product Life Cycle (TPLC) activity. As attack tools evolve, components that were once safe might become vulnerable.

Verify and Validate Risk Control Effectiveness

Putting controls in place is only half the battle - you need to prove they work. The FDA requires post-mitigation scoring to show that your controls have measurably reduced risk. This involves structured testing ^[1].

Testing Method	Purpose	Risk Type Addressed
Penetration Testing	Simulates real-world attacks to uncover weaknesses	Intentional malicious attacks
Vulnerability Scanning	Identifies known flaws using NVD/KEV data	Foreseeable risks
Error Injection	Tests system response to unexpected inputs	Unintentional failures
Human Factors Testing	Ensures usability and minimizes human errors	Human error/configuration mistakes
Code Review	Detects logic flaws and insecure coding practices	Technical vulnerabilities

Feed the results of these tests into your traceability matrix to clearly connect threats, risks, and controls. This traceability is crucial for FDA premarket reviews and for maintaining a strong risk file if questions arise later.

Using integrated risk management platforms like Censinet RiskOps™ (https://censinet.com) can simplify this process. These tools can automate testing, documentation, and continuous monitoring, saving time and effort.

Under 21 CFR Part 820.30(g), managing cybersecurity vulnerabilities is a required part of software validation and risk analysis ^[1].

Step 5: Determine Residual Risk and Operationalize Compliance

This step involves assessing the remaining risks after mitigation, documenting them for FDA review, and creating a system for continuous compliance.

Determine and Document Residual Risk

Residual risk refers to what remains after applying risk controls. Unlike traditional safety risks, the FDA emphasizes exploitability over historical probability ^[1].

After implementing controls like network segmentation, mTLS, or encryption, recalculate the CVSS environmental score using the FDA-qualified rubric. This recalibration incorporates healthcare-specific factors and helps guide both technical solutions and clinical risk strategies.

Conduct a clinical impact assessment for each residual risk to evaluate its effect on patients. The table below outlines clinical impact levels:

Clinical Impact Level	Description	Example
No Impact	No effect on device function or patient data	Exposure of error logging endpoint
Moderate	Delayed diagnosis or treatment initiation	Network DoS delaying image transfer
High	Credible pathway to patient injury	Unauthorized parameter modification
Critical	Multi-patient harm or death	Vulnerable library in dose calculation

Devices with a CVSS score of 7.0 or higher - or components listed in CISA's KEV Catalog - should not be released without a fix or clinical approval. A 2026 analysis of FDA deficiency letters revealed that even low or medium risks can trigger flags if mitigation or acceptance criteria are not clearly documented ^[6].

If mitigating residual risks requires user action, these instructions must be included in the IFU (Instructions for Use). The next step is preparing documentation that communicates these assessments effectively to the FDA.

Prepare FDA-Ready Risk Management Documentation

Your submission should include a Security Risk Management Report and a Security Assessment of Unresolved Anomalies table, as specified in FDA guidance. This table is distinct from your general software defect log ^[6].

Each row in the anomalies table should include:

• CVSS base and temporal scores
• Exploitability assessment informed by current threat intelligence
• Clinical impact rating
• Any compensating controls applied
• VEX status linked back to the SBOM component
• Justification for the release decision ^[6]

Every entry must be traceable - from the initial threat model to the risk assessment and into the table. Missing links in this chain are a common reason for FDA deficiency letters. Interestingly, a "clean" anomalies table with no entries can raise red flags. FDA reviewers may see this as a sign of incomplete analysis. A table with a few well-documented, low-risk anomalies is often viewed as more credible ^[6].

Using tools like Censinet RiskOps™ can simplify this process by ensuring traceability between threat models, risk files, SBOMs, and the unresolved anomalies table - reducing manual work for FDA submissions.

Once your documentation is finalized, focus on setting up systems for monitoring and addressing future risks.

Set Up Postmarket Monitoring and Updates

The FDA mandates a Cybersecurity Management Plan to monitor, identify, and address vulnerabilities throughout the device's lifecycle ^[1][6]. Unresolved anomalies with remote vectors or CVSS scores of 4.0 or higher should remain under active monitoring ^[6]. Your postmarket process should include:

• Regularly scanning the NVD and CISA's KEV Catalog for new vulnerabilities linked to your SBOM components.
• Updating exploitability assessments using threat intelligence that is no more than 90 days old ^[6].
• Maintaining a coordinated disclosure process for users to report unexpected device behavior.

Risk acceptance criteria must adapt as attacker capabilities evolve. This aligns with the FDA's Total Product Life Cycle (TPLC) principle, which stresses the importance of revisiting acceptance thresholds regularly - not just when new vulnerabilities emerge. Build periodic reviews into your Cybersecurity Management Plan to stay ahead of potential threats.

Conclusion: Building a Repeatable FDA-Compliant Risk Assessment Process

Key Takeaways from the Five-Step Framework

This framework is designed to create a structured, repeatable process for managing risk that aligns with FDA requirements. It begins with establishing governance and risk criteria, progresses through threat modeling and risk analysis, incorporates control implementation and verification, and concludes with documenting residual risks and ongoing postmarket monitoring. The result? A process that can withstand FDA scrutiny, not just during submission but throughout the entire lifecycle of the device.

A central element of this framework is its focus on exploitability-based scoring, as emphasized by the FDA:

"Security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system." ^[1]

This approach reshapes how risks are scored, how acceptance decisions are justified, and how teams respond to new vulnerabilities. It’s not a static process - risk acceptance criteria need to evolve over time. For instance, what might be acceptable at launch could become inadequate as threat actors grow more sophisticated and attack tools become more accessible. The FDA underscores this point:

"Acceptance criteria for cybersecurity risks should carefully consider the TPLC of the medical device system." ^[1]

By embedding this adaptability into your framework from the beginning, you can avoid the pitfalls of retrofitting later. This proactive approach transforms compliance from a one-time effort into a sustainable, ongoing process. It also lays the groundwork for leveraging technology to maintain continuous risk management.

Using Technology to Support Continuous Improvement

Technology is a crucial ally in maintaining compliance over time. While the step-by-step framework provides the foundation, tools and platforms ensure that oversight and adaptation remain consistent. Managing FDA compliance manually across multiple products is not practical - especially when considering the effort required to maintain traceability matrices that connect threat models to risk files. Without proper tools, these critical processes can easily fall by the wayside between product cycles.

Censinet RiskOps™ is an example of a platform designed to address these challenges. It offers end-to-end traceability, simplifies third-party and enterprise risk assessments, and helps both healthcare delivery organizations and medical device vendors stay in line with FDA requirements. For teams juggling multiple device lines or navigating complex supply chains, having structured, continuous oversight ensures that compliance doesn’t turn into a last-minute scramble before submission.

FAQs

What does the FDA expect in an SPDF tied to ISO 13485?

The FDA now anticipates manufacturers to include a Software Bill of Materials (SBOM), integrate cybersecurity measures into their Quality Management System (QMS) in line with ISO 13485:2016, and establish strong risk management practices. Essential components of these expectations include:

• Threat modeling to identify potential vulnerabilities.
• Validation activities to ensure system security and functionality.
• Traceability matrices for tracking requirements and their implementation.
• Vulnerability management plans to address and mitigate risks effectively.
• Comprehensive documentation that aligns with both ISO 13485 and the Secure Product Development Framework (SPDF).

These measures aim to ensure a safer and more secure development process for medical devices.

How do I score cybersecurity risk using exploitability vs probability?

Scoring cybersecurity risks by focusing on exploitability rather than just probability shifts the emphasis to how easily a vulnerability can be exploited. The FDA suggests prioritizing factors like remote access, known vulnerabilities, or the ability to bypass security controls. This method aligns more closely with actual threats, helping organizations address the most pressing risks and take targeted mitigation steps for a stronger, more practical risk assessment.

What should I monitor postmarket for KEV and SBOM issues?

To ensure both cybersecurity compliance and patient safety, it's essential to keep a close eye on Known Exploited Vulnerabilities (KEVs) and maintain an up-to-date Software Bill of Materials (SBOM). Monitoring KEV databases allows you to track vulnerabilities and assess their potential impact on medical devices.

An updated SBOM plays a critical role in identifying affected components, enabling quicker deployment of patches to mitigate risks. Automated tools, such as Censinet RiskOps™, can simplify the process, helping you stay aligned with FDA postmarket cybersecurity requirements while ensuring efficient monitoring and response.

Related Blog Posts

• Best Practices for FDA IoT Cybersecurity Compliance
• How FDA Cybersecurity Guidance Impacts HDOs
• How Penetration Testing Supports FDA Compliance
• Checklist for Pre-Market Medical Device Cybersecurity