FDA Cybersecurity

You don't know what you don't know.

You are still building the device and want cybersecurity support during design and implementation.

Your software is nearly complete and you need submission-ready cybersecurity documentation, testing, and risk controls.

You submitted to FDA and received an AINN letter with cybersecurity deficiencies.

For the Support engagement, we help you produce the cybersecurity artifacts typically needed for 510(k), De Novo, and PMA submissions. The documents are organized so they can be uploaded directly into the latest eSTAR template.

We align the content to FDA’s current cybersecurity expectations, using these guidance documents as key references:

• 2026 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 deliverable:

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 Metrics Report

Addresses plan for on-going cybersecurity metrics.

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.

Pricing depends on your device, submission type, and scope. Contact us for a custom quote.

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 assist your engineers in setting 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 in the long term.

We can handle the testing on your behalf or we can guide your engineering team through the cybersecurity testing process. FDA requires four categories of cybersecurity testing:

• 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 provide pen testing ourselves. We also have several more specialized pen-testing partners whom we’ve vetted and used on multiple FDA-submissions. 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 for performing software updates

Yes. We’ve done enough submissions that we’re confident we understand what FDA will require to get your submission cleared or approved.

That being said, FDA’s expectations are continuing to evolve. Strategies that we’ve seen work previously have stopped working in new submissions. However, depending on the offer you choose, we will guarantee that you won’t pay anything extra for our support addressing any requests for additional information the FDA identifies.