CyberMed
← All articles

5 reasons FDA will refuse your 510(k) application due to cybersecurity deficiencies

Published Updated Jose Bohorquez, PhDEditorial policy

Five cybersecurity gaps that stall a 510(k) under Section 524B and FDA's February 2026 guidance, from a missing threat model to an SBOM with no support data.

FDA can and does stall 510(k) submissions over cybersecurity. Since March 29, 2023, Section 524B of the FD&C Act has required cybersecurity information in every 510(k) for a cyber device, and FDA's February 3, 2026 premarket cybersecurity guidance spells out what that information should look like. The five gaps below are the ones that turn a routine review into a screening hold, an Additional Information (AI) request, or a not substantially equivalent (NSE) decision.

How a 510(k) fails on cybersecurity

There are three ways cybersecurity stops a 510(k).

  • Incomplete at screening. Section 524B(a) says a person who submits a 510(k) for a cyber device is required to include the information FDA needs to ensure the device meets the 524B(b) requirements. If the plan, the process evidence, or the SBOM is missing, the submission is incomplete before substantive review starts. Our Section 524B guide covers how screening handles this.
  • Additional Information request. The documents exist but a reviewer can't follow them. The threat model is generic, the risk scores are probabilities, the views don't match the architecture. The review clock stops while you answer.
  • Not substantially equivalent. Section VII.E of the guidance gives the example of a central-station alarm that lacks the encryption needed against a known threat. If the data provided is inadequate, FDA says it "would likely make a determination that the new device is not substantially equivalent."

The old Refuse to Accept policy for cyber devices from 2023 is gone. What remains is the statute, the guidance, and the eSTAR's Cybersecurity section, which won't let you skip the attachments.

Who this applies to

Section 524B(c) defines a cyber device as one that meets three tests: it includes software, it "has the ability to connect to the internet," and it contains technological characteristics that could be vulnerable to cybersecurity threats.

FDA reads "ability to connect" broadly in Section VII.B. The illustrative list includes network, server, or cloud connections; radio-frequency communications such as Wi-Fi, cellular, Bluetooth, and Bluetooth Low Energy; magnetic inductive communications; and hardware connectors such as USB, ethernet, and serial ports. A footnote adds that a device serviced over a brief USB connection still has the ability to connect.

Two scopes matter here. The guidance's recommendations apply to any device with software, firmware, or programmable logic, connected or not. The Section 524B requirements apply only to cyber devices. If your device has software and any port or radio, assume both apply.

What the statute requires

Section 524B(b) has four parts. The guidance walks through the first three in Section VII.C.

  1. A postmarket plan, 524B(b)(1): "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures."
  2. Processes and procedures, 524B(b)(2): the sponsor must "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure." This includes making patches available on a reasonably justified regular cycle, 524B(b)(2)(A), and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks, 524B(b)(2)(B).
  3. An SBOM, 524B(b)(3): a software bill of materials "including commercial, open-source, and off-the-shelf software components."
  4. Anything FDA adds by regulation, 524B(b)(4). FDA has not issued such a regulation and the guidance notes it isn't required to.

The guidance adds one more consequence in Section IV.D. For cyber devices, failure to comply with any requirement under 524B(b)(2) is a prohibited act under section 301(q) of the FD&C Act.

Everything else in the guidance is a recommendation about how to show you've met those obligations. In practice, reviewers use those recommendations to judge whether the submission provides a reasonable assurance of cybersecurity. That's where the five reasons come from.

Reason 1: No threat model, or a generic one

Section V.A.1 of the guidance asks for threat modeling documentation that shows how the medical device system was analyzed for security risks that could affect safety and effectiveness. The threat model should identify risks and mitigations, state assumptions about the environment of use, and capture risks from the supply chain, manufacturing, deployment, interoperation, maintenance, updates, and decommissioning.

The guidance also asks for the rationale behind the methodology you chose.

What draws an AI request is a threat model copied from a template. The threats aren't tied to your assets or data flows. Nothing explains what was scoped out or why. The reviewer can't tell whether the hospital network was treated as hostile, which the guidance recommends you assume.

Fix: build the model from your architecture, assign every threat a unique ID, and carry that ID into the risk assessment and the test report. Our post on threat modeling for cloud-connected devices shows the method.

Reason 2: A risk assessment scored on probability

This is the deficiency that catches teams with strong ISO 14971 habits. Section V.A.2 states that cybersecurity risks can't be assessed and quantified by likelihood based on historical data. Instead, "security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system."

The guidance asks the premarket risk assessment to:

  • Capture the risks and controls identified in the threat model.
  • Score each risk before and after mitigation, with the methods and acceptance criteria stated.
  • Describe how security risks transfer into the safety risk assessment.
  • Either assume worst-case exploitability or justify a lower rating across the total product lifecycle.
  • Treat known vulnerabilities as reasonably foreseeable risks, and design out anything in CISA's Known Exploited Vulnerabilities catalog.

A probability-times-severity table with "cyber" in the title fails every one of those points. For scoring, FDA's postmarket guidance points to CVSS, and the MITRE rubric adapts it for devices. The risk assessment rules post covers the full checklist.

Reason 3: No security architecture views

Section V.B.2 recommends, at minimum, four architecture views in the submission: a Global System View, a Multi-Patient Harm View, an Updatability and Patchability View, and Security Use Case Views. Each needs diagrams and explanatory text at the level of detail in Appendix 2, and if a view doesn't apply, the guidance asks for an explanation of why it's omitted.

The views do real work. They show trust boundaries, every external interface, and where each control sits. The guidance says they're also an effective way to deliver threat-modeling information, and the number of views scales with the attack surface.

Submissions that lack views, or that submit a single block diagram labeled "architecture," force the reviewer to reconstruct the system from prose. That's an AI request. See the architecture security view for how to build each one.

Reason 4: An SBOM with no support information

An SBOM is the one artifact that is both statutory and specific. Section 524B(b)(3) requires it. Section V.A.4(b) says what FDA expects in it: a machine-readable SBOM consistent with the NTIA's October 2021 minimum elements, plus two fields FDA adds for every component:

  • The level of support from the component's maintainer (actively maintained, no longer maintained, abandoned).
  • The component's end-of-support date.

Those two fields can live in the SBOM or in an addendum. The submission should also identify all known vulnerabilities in the device and its components, including any in CISA's Known Exploited Vulnerabilities catalog, describe how each was discovered, and give a safety and security risk assessment and the risk controls for each.

The common failure is an SBOM generated by a build tool and attached as is. Transitive dependencies are missing. Support status and end-of-support dates are absent. No vulnerability assessment accompanies it. The statutory box is checked and the reviewer still has nothing to evaluate. Our SBOM requirements guide covers each field.

Reason 5: No cybersecurity management plan

Section 524B(b)(1) requires the postmarket plan, and Section VI.B lists what FDA expects it to contain:

  • Personnel responsible.
  • Sources, methods, and frequency for monitoring and identifying vulnerabilities.
  • How you identify and address vulnerabilities in CISA's Known Exploited Vulnerabilities catalog.
  • Periodic security testing.
  • Timeline to develop and release patches.
  • Update processes and patching capability.
  • A description of your coordinated vulnerability disclosure process.
  • How you'll communicate remediations, patches, and updates to customers.

Section VII.C.1 adds that the plan should describe, with justification, the timelines for the regular patch cycle under 524B(b)(2)(A) and for out-of-cycle patches under 524B(b)(2)(B). It should also account for fielded devices on different software versions.

A plan that says "we will monitor for vulnerabilities and patch as needed" doesn't meet this. It has no sources, no frequency, no timeline, and no CVD process. Our book chapter on building a vulnerability monitoring program covers what a real program looks like. The statute asks for updates to be made available; it doesn't mandate over-the-air delivery, but your plan has to say how patches reach devices.

What ties the five together

Appendix 4 Table 1 of the guidance organizes all of this into six documentation types: Cybersecurity Risk Management Report, Measures and Metrics, Architecture Views, Testing, Labeling, and Cybersecurity Management Plans. The report is where the threat model, risk assessment, SBOM, vulnerability assessment, unresolved anomalies, and traceability live.

Traceability is the thread. Section V.A asks the report to "provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation." A submission that has all five artifacts but no shared identifiers across them still reads as five disconnected documents. Our book section on common eSTAR submission pitfalls walks through the failure modes.

Before you submit

Run this check against your eSTAR Cybersecurity section:

  1. Does the threat model name your assets and interfaces, and does every threat have an ID?
  2. Does the risk assessment score exploitability, state acceptance criteria, and reference the threat IDs?
  3. Are all four architecture views present, or is each omission explained?
  4. Does the SBOM carry support level and end-of-support date per component, with a vulnerability assessment attached?
  5. Does the management plan name people, sources, frequencies, patch timelines, and a CVD process?

If any answer is no, fix it before FDA asks. The guidance also recommends using the Q-Submission process to discuss cybersecurity design early, which is cheaper than an AI request.

Need help with the cybersecurity section of your 510(k)? See our FDA cybersecurity documentation service or email us at info@cybermed.ai.

Sources

Frequently asked questions

›Can FDA refuse a 510(k) for cybersecurity reasons?

Yes. For a cyber device, Section 524B(a) of the FD&C Act requires the submission to include cybersecurity information. A submission that lacks it is incomplete and can be held at screening. A submission that has the documents but can't show a reasonable assurance of cybersecurity draws an Additional Information request, and FDA's February 2026 guidance says inadequate data can lead to a not substantially equivalent decision.

›What is a cyber device under Section 524B?

A device that includes software, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. FDA reads 'ability to connect' broadly. Wi-Fi, Bluetooth, cellular, USB, ethernet, and serial ports all count, even if the connection is only used for servicing.

›What does Section 524B(b) require a sponsor to submit?

Three things: a plan to monitor, identify, and address postmarket vulnerabilities including coordinated vulnerability disclosure; processes and procedures that provide a reasonable assurance the device and related systems are cybersecure, including making patches available on a regular cycle and out of cycle for critical vulnerabilities; and a software bill of materials covering commercial, open-source, and off-the-shelf components. A fourth clause lets FDA add requirements by regulation.

›Does the guidance apply if my device never connects to the internet?

The February 2026 guidance's recommendations apply to any device with software, firmware, or programmable logic, connected or not. The Section 524B statutory requirements apply only to cyber devices, which must have the ability to connect to the internet.

›What is the most common cybersecurity deficiency in a 510(k)?

In our experience, a risk assessment that scores threats on probability instead of exploitability, and a package whose threat model, controls, and tests don't share identifiers. FDA's guidance asks for exploitability-based scoring and for traceability across the threat model, risk assessment, SBOM, and testing.