CyberMed
← All articles

FDA Cybersecurity Requirements for Medical Devices with Software

Published Updated Jose Bohorquez, PhDEditorial policy

What FDA actually expects in the cybersecurity package for a software-based medical device, mapped to where each artifact lives in your submission.

FDA's premarket cybersecurity guidance (February 2026) expects a cybersecurity package for any medical device that contains software, whether or not it connects to a network. In practice that means a set of artifacts in your eSTAR submission, including a threat model, a cybersecurity risk assessment scored on exploitability, a machine-readable SBOM, a cybersecurity testing report, and a cybersecurity management plan that covers post-market patching. Each artifact has to trace back to specific threats and controls, and the work continues after clearance.

The most common conversation I have with a first-time submitter starts the same way: "Our device isn't connected to anything. The FDA cybersecurity stuff doesn't apply to us, right?"

It does. FDA's premarket cybersecurity guidance (February 2026) applies to any medical device that contains software, firmware, or programmable logic, connected or not. A standalone analyzer with a USB port, a wearable that only pairs with a phone, even a device whose only "network" is a service-mode interface a tech plugs into once a year: they all need a cybersecurity package. If the device can connect to the internet, Section 524B of the FD&C Act adds statutory requirements on top. See our Section 524B guide.

So if you have software, here is what reviewers expect to see in your submission, and roughly when in development each piece should get built.

What cybersecurity documents does FDA expect?

Appendix 4 Table 1 of the guidance organizes the package as six documentation types broken into fourteen elements. Different reviewers organize them differently, but the set is stable. The table below is the map I give clients during the first scoping call. Our book chapter on understanding eSTAR requirements walks through each document in detail.

Artifact When you build it Where it lives in the submission Common reviewer pushback
Security Architecture Views Architecture phase Cybersecurity section, alongside threat model Missing trust boundaries; views don't match the system architecture in the software DHF
Threat Model Architecture phase Cybersecurity risk management Threats not tied to specific assets or data flows; no rationale for what was scoped out
Cybersecurity Risk Assessment Architecture phase, updated through V&V Cybersecurity risk management Probability-based scoring instead of exploitability; no acceptance criteria
Cybersecurity Controls Architecture phase Cybersecurity controls section Controls listed without traceability back to threats they mitigate
Cybersecurity Management Plan Architecture phase Cybersecurity section Plan is a template with no specifics about this device
Safety & Security Assessment of Vulnerabilities Through V&V Cybersecurity risk management No mechanism to escalate cyber risks with safety impact into ISO 14971
Software Bill of Materials (SBOM) Implementation phase, maintained post-market Software documentation + cybersecurity section Missing transitive dependencies; no machine-readable format
Assessment of Unresolved Anomalies (cyber-relevant) After V&V Software documentation + cybersecurity section Cyber implications of open anomalies not analyzed
Cybersecurity Testing Report After V&V Cybersecurity testing Penetration test scope unclear; no traceability to controls being tested
Software Level of Support Implementation phase Cybersecurity section, with the SBOM or as an addendum Support status and end-of-support dates for third-party components not stated
Cybersecurity Metrics After V&V Cybersecurity section Metrics defined but no baseline or threshold
Security Risk Management Report Final, before submission Cybersecurity section Report doesn't roll up the assessments above into a single summary
Cybersecurity Labeling Final Labeling Missing or vague guidance for the user on secure configuration

If you can produce every row of that table and a reviewer can trace each one back to a specific threat and a specific control, you're in good shape. Most deficiency letters I've seen on cybersecurity trace back to a missing or weak entry in one or two specific rows. Where a reviewer finds one, the result is an Additional Information (AI) request.

How CyberMed splits the work into two phases

These artifacts don't all get built at the same time. Trying to write a Cybersecurity Testing Report before the threat model is locked is wasted effort. The test scope will change. So we split engagements into two phases that mirror development.

Phase 1: security architecture

This is where the foundation gets set. The decisions you make here determine whether the rest of the submission is defensible or a scramble.

  • System architecture and security views. Identify every component, interface, data flow, and trust boundary. The security views are not a separate diagram. They're the system architecture with the security-relevant elements called out. Components, network surfaces, authentication points, data at rest, data in transit.
  • Threat modeling. Map attack surfaces. Identify threat actors and what they could plausibly want. Document attack scenarios against the trust boundaries from the security views. The output is a list of threats traceable back to specific elements of the architecture.
  • Risk evaluation. Score each threat. This is where FDA's guidance diverges most sharply from ISO 14971 thinking. Cybersecurity risk is scored on exploitability, not probability. I cover this in detail in the risk assessment guide.
  • Controls selection. For every threat above the acceptance threshold, select controls that mitigate it. Controls can be technical (signed firmware, mutual TLS) or administrative (a documented patch cadence). Document the rationale for each control selection.
  • Security management plan. Roles, responsibilities, processes, and incident response. Avoid the template trap. Reviewers can tell when this is generic versus when it reflects how your team actually operates.

Phase 2: design, development, and verification

With the architecture locked, this phase is about building, testing, and producing evidence.

  • Implementation. Develop the software using the secure coding practices implied by your selected controls. Track which controls are implemented where so you can produce the trace later.
  • SBOM generation and analysis. Generate the SBOM (CycloneDX or SPDX, machine-readable). Cross-reference every component against known vulnerability databases. Document anomalies with their cyber implications.
  • Cybersecurity testing. Vulnerability scanning, fuzz testing on input interfaces, penetration testing on accessible surfaces. The Cybersecurity Testing Report should trace back to specific controls being verified, not be a generic vulnerability scan output.
  • Residual risk. Risks that remain after controls are implemented need to be documented and accepted with rationale. "Acceptable because we ran a pen test" is not rationale. "Acceptable because the residual risk score is below our defined threshold of X and the control was verified by Y" is.

Post-market is not optional

A common misconception is that the cybersecurity work ends at clearance. It doesn't. FDA expects an ongoing program:

  • Monitor for new vulnerabilities affecting your SBOM components.
  • Patch on a documented cadence. The Cybersecurity Management Plan should specify what that cadence is and how patches are validated before deployment.
  • Track and report incidents per the post-market guidance.
  • Update the SBOM and the safety and security assessment when components or controls change materially.

If your business model can't sustain post-market cybersecurity work, that's a sign the product isn't ready to be on the market yet. Reviewers look for this in the Cybersecurity Management Plan. Our book chapter on the post-market security landscape covers what that ongoing program involves.

What we see at submission time

The single most common pattern I've seen at submission time is a complete cybersecurity package that fails traceability. The threat model exists, the controls exist, the test report exists. But a reviewer can't draw a line from a threat in the model to a control in the controls list to a test case in the report. That's the cybersecurity equivalent of failing a design-controls audit: not a missing document, but a broken chain.

The fix is mechanical but tedious: every threat gets a unique ID; every control references the threats it mitigates; every test case references the controls it verifies. Build the traceability matrix early and update it as the architecture changes. Submitting without it is the fastest way to invite an Additional Information request.

Where to go next

If you're scoping a submission, the fastest way to gauge where you stand is the FDA 524B Cybersecurity Readiness Assessment. It takes a few minutes and gives you a tier and a gap report.

If you already know you need help building the package, the 30-day CyberSprint covers the full cybersecurity package on a fixed timeline. For a deeper look at the risk-assessment piece specifically, read the 12 essential FDA cybersecurity risk assessment rules.

This post is a framework, not legal or regulatory advice. The specific cybersecurity expectations for your device depend on its risk class, intended use, connectivity, and the FDA pathway you're pursuing. Talk to a regulatory professional who knows your product.

Need help with FDA cybersecurity documentation? See our FDA cybersecurity documentation service or email us at info@cybermed.ai.

Sources

Frequently asked questions

›Do FDA cybersecurity requirements apply to devices that aren't connected to a network?

Yes. FDA's premarket cybersecurity guidance (February 2026) applies to any medical device that contains software, firmware, or programmable logic, connected or not. A standalone analyzer with a USB port or a device with a once-a-year service-mode interface still needs a cybersecurity package. The Section 524B statutory requirements apply only to cyber devices, which have the ability to connect to the internet.

›What cybersecurity documents does FDA expect in a 510(k) submission?

Appendix 4 Table 1 of the February 2026 guidance lists six documentation types broken into fourteen elements: a Cybersecurity Risk Management Report (threat model, risk assessment, SBOM, vulnerability assessment and software support, unresolved anomalies, traceability), Measures and Metrics, Architecture Views with security requirements, Testing, Labeling, and Cybersecurity Management Plans.

›What format does FDA expect for the SBOM?

A machine-readable SBOM consistent with the NTIA minimum elements, plus the level of support and end-of-support date for each component. FDA names no format; CycloneDX and SPDX are the common choices. Common reviewer pushback includes missing transitive dependencies and SBOMs that aren't machine-readable.

›Does FDA cybersecurity work end after clearance?

No. FDA expects an ongoing post-market program: monitoring for new vulnerabilities affecting SBOM components, patching on a documented cadence, tracking and reporting incidents, and updating the SBOM and security assessments when components or controls change materially.

›Why do cybersecurity submissions get deficiency letters even when all the documents exist?

The most common failure is broken traceability. The threat model, controls list, and test report all exist, but a reviewer can't draw a line from a specific threat to the control that mitigates it to the test case that verifies it. Every threat needs a unique ID that carries through the whole package.