8 FDA Cybersecurity Deficiencies, Ranked From Real Letters

Most lists of "common FDA cybersecurity deficiencies" are opinion. This one is a count. It comes from our September 23, 2026 MTEC webinar, What the FDA Actually Wrote, where Christian Espinosa walked through the eight findings that recur in real deficiency letters, what the FDA wrote, why it happened, and the artifact that closes each one.

A note on the data before the ranking. The percentages are the share of ten letters Blue Goat Cyber reviewed in full that raised each issue. That is a small sample, so 90% means nine of ten letters, not 90% of all submissions industry-wide. The letters span software-only devices, AI-enabled devices, cloud and on-premise deployments, capital equipment, wearables, and vital signs monitors, reviewed by both CDRH and CBER. Client names, device names, and submission numbers are excluded. The same eight findings, in roughly this order, recur across the 30+ FDA cybersecurity letters Christian has reviewed over his career, but that broader set was not formally counted.

Why this matters

Under Section 524B of the FD&C Act, the FDA can refuse to accept a cyber device submission that lacks required cybersecurity content, and reviewers apply the February 3, 2026 final premarket cybersecurity guidance to everything that gets through. An Additional Information letter pauses the review clock and gives you 180 days to respond. Every one of the findings below can be caught before submission, which is far cheaper than answering it under a deadline.

The ranking

Want to see the reviewer wording behind each row? Read the anonymized letter excerpts, grouped by finding.

1. SBOM

What the FDA wrote (pattern): the SBOM does not carry the data the FDA asked for. An SBOM is rarely missing outright.

Root cause: support-status tiers missing, end-of-support dates missing or undated, a format that is not machine-readable (a PDF SBOM does not satisfy the requirement), NTIA minimum elements missing, and no per-component vulnerability mapping to NVD or the CISA Known Exploited Vulnerabilities catalog. One letter named components 10 and 16 years past end-of-life, with CVSS scores of 7.5 and 7.8 and no compensating-control justification.

The artifact that closes it: a machine-readable SBOM (SPDX or CycloneDX) with support status per component, dated end-of-support, NTIA minimum elements, and a per-component vulnerability assessment against NVD and CISA KEV.

The third row is the point. A good SBOM names the gap. A blank cell, or an SBOM that omits the module entirely, is what draws the finding. See our SBOM guidance for FDA submissions for more.

2. Security controls written as principles

What the FDA wrote (pattern): only a high-level description was provided, so the adequacy of the control cannot be determined.

Root cause: controls stated as goals rather than specifications. Passwords required but no password policy. TLS 1.2 named but not the cipher suites. ECDSA cited but not the curve or hash. One letter raised this finding nine separate times against nine controls in a single submission, making it the largest category by raw count of individual findings.

The artifact that closes it: every control gets a unique requirement ID written at specification level, traced to the test case that verified it. "The device authenticates users" cannot be tested. SEC-AUTH-014, verified by TC-SEC-014-03 with pass/fail evidence, can. Our guide to security requirements testing covers the traceability chain.

3. Cybersecurity labeling

What the FDA wrote (pattern): the labeling plan is not labeling. Does the content actually reach the customer?

Root cause: a near-identical list of missing elements recurs across letters: network ports and interfaces, secure configuration of shipped devices, update notification, behavior under anomalous conditions, backup and restore, forensic evidence capture, a machine-readable SBOM for users, and end-of-life or decommissioning. One letter listed fourteen missing labeling elements for a single device.

The artifact that closes it: a labeling checklist mapped one to one against the FDA's expected elements and verified against the customer-facing document itself, not the submission narrative describing it.

4. Security and penetration testing

What the FDA wrote (pattern): vulnerability scanning is not a substitute for penetration testing. A scan identifies known vulnerabilities; a penetration test demonstrates impact.

Root cause: scope gaps, risk-based justifications for skipping testing altogether, and no independence between testers and the design team. One letter cited a local agent bridging a browser to physical scales and label printers that had been left out of scope entirely.

The artifact that closes it: a full-system penetration test report covering tester independence and expertise, scope, duration, methods, and results. See our FDA penetration testing service.

5. Cybersecurity risk assessment

What the FDA wrote (pattern): no stated methodology or acceptance criteria, and impact written as a system effect rather than patient harm.

See also: FDA IDE Cybersecurity Requirements: 2026, SBOM Diffing & CVE Correlation Postmarket, and FDA Cybersecurity Major vs Minor.

Root cause: exploitability claimed without defining it against attack vector, complexity, privileges, and user interaction; risk IDs that do not match across tables; no trace from a risk to a requirement ID. One letter singled out "full system control" rated as Medium impact.

The artifact that closes it: a documented methodology (CVSS with AAMI TIR57 or ANSI/AAMI SW96), matched risk IDs, pre- and post-mitigation levels, and a cross-reference against NVD and CISA KEV. In our method, exploitability is scored once and feeds two matrices: security impact on the SW96 side and severity of patient harm on the ISO 14971 side. Only threats that could affect patient safety carry into the ISO 14971 risk management file.

6. Cybersecurity risk management report

What the FDA wrote (pattern): the report points at other documents instead of standing on its own.

Root cause: summarizing the scope of each supporting document instead of its outcome and residual risk conclusion. Several letters found no security risk process running parallel to the safety risk process at all.

The artifact that closes it: one report that states the risk evaluation methods, the residual risk conclusion, and the mitigations actually performed, traced across the threat model, risk assessment, SBOM, and testing.

7. Unresolved anomalies

What the FDA wrote (pattern): answering that there are no unresolved cybersecurity issues is not responsive. The FDA means known software defects deliberately left in the product.

Root cause: teams misread the question, or list functional bugs with no security-impact assessment, assessed in isolation from the risk management file.

The artifact that closes it: an anomaly-by-anomaly write-up: description, how it was found, root cause, impact on safety and effectiveness, and a risk-based rationale for not fixing it.

8. Threat model

What the FDA wrote (pattern): the assumption that the network is hostile is not stated.

Root cause: supply chain, decommissioning, and end-to-end infrastructure left out. For AI-enabled devices, data poisoning, model inversion, and model evasion were consistently missing. Threat models are usually incomplete at the edges, rarely absent.

The artifact that closes it: a threat model that states the hostile-network assumption, covers the full lifecycle, names AI-specific threats where relevant, and carries pre- and post-mitigation scores into the risk assessment. See our threat modeling service.

Five checks before you submit

1. Gate the SBOM before it ships. No package ships without three-tier support status, a dated end-of-support for each component, a machine-readable format, the NTIA minimum elements, and a per-component vulnerability assessment against NVD and CISA KEV.
2. Treat labeling as a checklist, not prose. The same missing-element list recurs almost word for word across letters. Map it one to one against the customer-facing document instead of describing it in narrative form.
3. Trace every control to a test case. Every control gets a unique requirement identifier, traceable to the test case that verified it, before the independent reviewer gate.
4. Confirm full-system penetration test scope. Include bridging components and local agents, and make sure the report has all five required elements: independence, scope, duration, methods, and results and findings.
5. Search for likelihood language before release. Search every submission for "likelihood," "probability," and "unlikely." The FDA assesses cybersecurity risk on exploitability, not likelihood.

Or run our free FDA readiness check first.

How Blue Goat approaches this

We build each of these artifacts as one traceable set: threat model to risk assessment to requirement IDs to test cases to labeling. Our team has supported 275+ FDA submissions, and if the FDA sends a cybersecurity deficiency on work we delivered, we help resolve it at no extra cost. If you already have a letter, our deficiency letter triage tool sorts each finding by type and urgency. Nothing here guarantees an FDA outcome; the FDA makes its own determinations.

FAQ

How many letters is this ranking based on?

Ten FDA cybersecurity Additional Information letters that Blue Goat Cyber reviewed in full. Percentages are the share of those ten letters raising each issue, not a statistic about all submissions. The same pattern recurs across 30+ letters Christian Espinosa has reviewed over his career, though that larger set was not formally counted.

What is the most common FDA cybersecurity deficiency?

In our sample, SBOM gaps, raised in nine of ten letters. The SBOM is rarely missing. Instead it lacks support status, end-of-support dates, a machine-readable format, NTIA minimum elements, or per-component vulnerability checks against NVD and CISA KEV.

Is a vulnerability scan enough for the FDA?

No. Letters in our sample stated directly that vulnerability scanning is not a substitute for penetration testing. A scan finds known vulnerabilities; a penetration test shows whether they can be exploited and what the impact is, across the full system scope.

What does the FDA mean by unresolved anomalies?

Known software defects deliberately left in the released product. Answering that there are no unresolved cybersecurity issues is not responsive. Each anomaly needs a description, how it was found, root cause, safety and effectiveness impact, and a risk-based rationale for leaving it.

How long do I have to respond to an FDA deficiency letter?

For a 510(k), an Additional Information letter typically gives 180 days to respond, and the review clock stays paused until you do. If you miss the deadline, the FDA can consider the submission withdrawn. Plan your response in the first week.

Got a deficiency letter now?

Book a discovery call or start with the free deficiency letter triage tool. We sign a mutual NDA first.