FDA Cybersecurity Remediation

The following documents cover FDA cybersecurity requirements for 510(k), De Novo, and PMA submissions. The documents are organized so they can be uploaded directly into the latest eSTAR template.

The documents will comply with all three of FDA’s current cybersecurity guidance:

• 2023 FDA Guidance - Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
• 2016 FDA Guidance - Postmarket Management of Cybersecurity in Medical Devices
• 2005 FDA Guidance - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software

See below for summary descriptions of each of the documents:

Security Architecture Views

Visual diagrams of system components, data flows, connections, and trust boundaries. Includes Global System View, Multi-Patient Harm View (if applicable), Use Case Views, and Updateability View.

Cybersecurity Controls (Draft/Final)

Proposed and final security controls addressing FDA's 8 risk control categories to mitigate identified risks.

Initial draft provided in Phase 1 for software team implementation.

Cybersecurity Management Plan

Plan for managing cybersecurity risks throughout product lifecycle, including development, vulnerability handling, and monitoring.

Cybersecurity Measures and Metrics

Indicators tracking security control effectiveness (e.g., vulnerability count, patch response time).

For new devices, outlines planned metrics only.

Threat Model

STRIDE analysis of threat actors, assets, and attack vectors, showing potential vulnerabilities and safety impacts.

Security Risk Assessment

Risk evaluation showing traceability between vulnerabilities, controls, and residual risks.

Cybersecurity Labeling

User documentation covering security responsibilities, diagrams, updates, and anomaly reporting.

Software Bill of Materials (SBOM)

List of all software components and third-party libraries used in the device.

Software Level of Support and End of Support

Support duration and end-of-life plans for each SBOM component.

Vulnerability Assessment

Review of vulnerabilities found in SBOM scan.

Assessment of Unresolved Security Anomalies

Open security issues with impact analysis and mitigation plans.

Cybersecurity Testing Report

Summary of all security testing activities and results.

Penetration Testing Report

Third-party pen-test findings and recommendations with FDA-aligned analysis.

Security Risk Management Report

Final summary of all security activities providing submission-ready overview.

It varies quite a bit based on:

• The type of submission (IDE, 510(k), De Novo, or PMA—each increases in costs)
• The type of device and the safety risks involved (higher risk is higher costs)
• The state of the existing software (the more complete it is, the cheaper our service will be to complete)

A typical SaMD 510(k) is typically $40k to $70k.

Our guided option is billed at an hourly rate, as it really depends on how much support your team requires. It typically involves a couple hours/week of Partner time ($400/hour) along with one of our trained engineers doing most of the work at a lower rate.

Unless your medical device was designed with security in mind, it's likely that some software changes will be required. Our process is tailored to pinpoint these necessary changes swiftly so your engineers can start working on them. In some instances, we can also provide software engineering support.

Yes! Please review our case studies for a sampling of our past projects. If you don’t see anything relevant, please reach out as only a small number of our projects have case studies.

Yes! We can work your team team to develop a threat model over a sequence of collaborative meetings. As part of threat modeling we’ll develop a set of security architecture views that comply with FDA’s expectations. We’ll guide the team through identifying external connections, assets, threat actors, and threats. Our threat modeling typically uses STRIDE combined with other threat modeling methodologies as is appropriate.

Our threat modeling approach considers the full end-to-end system, including “other functions”.

Yes! We can guide the Client’s team through writing an appropriate Security Risk Management Plan, including an appropriate means of assessing security risks.

We can then guide the team through a security risk assessment, using the threat modeling as an input. We’ll work with the team to trace security risks to safety risks. We’ll also help identify relevant cybersecurity controls (see the next section) and help ensure there is proper cybersecurity traceability.

Yes! We’ll work with the team to identify appropriate security risk controls against the FDA guidance. FDA typically requires at minimum one or two controls from each control category:

• authentication
• authorization
• cryptography
• integrity
• confidentiality
• detection
• resiliency & recovery
• updates.

We’ll work with you to identify the most useful controls that add the minimum necessary software development cost. We also understand what controls FDA expects for different types of devices.

In most cases, yes, although this is at an additional cost. For most clients, it is more cost effective to have their own team implement the software controls.

We can usually produce an FDA-compliant SBOM with minimal input from your engineers.

Alternatively, we can your engineers set up tools to automatically generate an SBOM as part of their automated build procedures (e.g., using a GitHub Action that produces the SBOM as a build artifact). This second approach takes longer in the short term, but is more efficient long term.

We can guide your engineering team through the cybersecurity testing process.

• Requirements Testing: Typically handled through standard Design Controls, however, we can help draft Design Verification Protocols for verification of the Design Control requirements.
• Vulnerability Testing: We can help select an appropriate vulnerability testing tool and incorporate it into the development workflow. This typically includes analyzing third-party packages for vulnerabilities along with static code analysis.
• Fuzz Testing: We can help identify appropriate interfaces to fuzz test, define the scope, and can even help implement fuzz testing.
• Penetration Testing: We can help select an appropriate pen testing vendor and can facilitate communication with the vendor to ensure they provide records that meet the FDA guidance.

We can compile all of these records into tests that are appropriate for the 510(k) submission.

We can work with your team to draft the cybersecurity sections of the IFU based on our understanding of the device and previous submissions. This includes:

• Instructions related to the user’s security responsibilities
• Security diagrams
• SBOM access
• Software update notification
• Security anomaly reporting and detection
• Backup and restore functionality

No, we can’t make such a guarantee.

FDA’s expectations are continuing to evolve. Strategies that we’ve seen work previously have stopped working in new submissions. Most teams also can’t implement everything in the guidance (and FDA doesn’t expect you to). We therefore will try to find the right amount of effort required for your device. Sometimes we will undershoot.

However, we can guarantee that you won’t pay anything extra for our support addressing any requests for additional information the FDA identifies.