FDA & Regulatory
Top FDA Cybersecurity Deficiencies: What 30+ FDA Letters Raised Most
A ranked share of the cybersecurity issues the FDA raised across 30+ Additional Information letters Blue Goat Cyber reviewed.
Published:
Executive summary
We reviewed more than 30 FDA Additional Information letters that Blue Goat Cyber worked directly and measured the share that raised each cybersecurity issue. The letters span software-only devices, AI-enabled devices, cloud and on-premise deployments, capital equipment, wearables, and vital signs monitors. One came from CBER on blood establishment computer software; the rest came from CDRH. The most recent letter cites the February 3, 2026 final premarket cybersecurity guidance directly.
Four areas account for most of what came back: the SBOM, security controls written as principles instead of specifications, cybersecurity labeling, and security testing. The same findings recur across device types and review divisions, which is why a pre-release check against those four areas addresses the areas cited most often.
Quoted phrases below are what reviewers wrote in these letters. FDA guidance is nonbinding, and a reviewer request in one file is not a rule for every device. Treat the findings as a map of where reviewers look, not as a list of legal requirements. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections.
Methodology
- Sample
- More than 30 FDA Additional Information letters, each read in full.
- Time period
- Letters received through August 2026
- Inclusion criteria
- FDA Additional Information letters with cybersecurity content that Blue Goat Cyber worked directly.
- Each issue counted once per letter, regardless of how many times that letter raised it.
- Issues grouped into categories aligned to the February 3, 2026 premarket cybersecurity guidance.
- Limitations
- Percentages describe the letters we reviewed. They are not rates across all FDA submissions.
- The letters come from engagements that chose Blue Goat Cyber and may not represent every FDA submission.
- Categories are our own grouping; the FDA does not publish standard deficiency categories for cybersecurity.
- Anonymization
- Client names, device names, and submission numbers are excluded.
- Findings are reported as percentages across all letters reviewed, never tied to a single submission.
- Reviewer wording is quoted only in short, non-identifying phrases.
Key findings
1. 1. SBOM: 90% of letters.
Rarely a missing SBOM; usually missing data. Reviewers asked for each component's level of support (actively maintained, no longer maintained, or abandoned), end-of-support dates, a machine-readable format such as SPDX or CycloneDX in place of a PDF, NTIA minimum elements such as hashes and dependency relationships, and a per-component vulnerability check against NVD and the CISA KEV catalog. One letter questioned components ten and sixteen years past end of life.
2. 2. Security controls written as principles: 70% of letters, about thirty individual items.
The largest category by raw count; one letter raised it nine times. Reviewers repeatedly wrote that "only a high level description was provided" so the adequacy of the control could not be determined. Examples: passwords named without password rules, TLS 1.2 named without cipher suites, and ECDSA named without the curve or hash. Reviewers looked for a unique requirement ID per control, traced to the test that verified it.
3. 3. Cybersecurity labeling: 70% of letters.
The same missing items recur almost word for word; one letter listed fourteen. Common gaps: ports and interfaces with direction and endpoints, secure configuration and credential reset, how users get authorized updates, behavior under anomalous conditions, backup and restore, log locations and formats for forensics, an SBOM available to users, and end-of-support and decommissioning information. Reviewers asked whether the content actually reaches the customer.
4. 4. Security and penetration testing: 70% of letters.
Reviewers rejected vulnerability scanning offered as penetration testing, a risk-based justification for no penetration test on a wireless, cloud-connected device, and a cloud provider's shared-responsibility model offered in place of application testing. They also flagged scope that left out part of the system, an unaddressed finding the manufacturer's report rated medium, and reports missing tester independence, scope, duration, methods, or results.
5. 5. Cybersecurity risk assessment: 60% of letters.
Usually a method problem, not a missing document: no stated method or acceptance criteria, exploitability levels left undefined, impact written as a system effect instead of patient harm, pre- and post-mitigation levels not both shown, mitigations labeled "proposed," and risk IDs that do not trace to security requirements.
6. 6. Cybersecurity risk management report: 50% of letters.
The report pointed at other documents instead of summarizing their outcomes. Reviewers asked for the conclusions from the threat model, risk assessment, SBOM, vulnerability and anomaly assessments, plus the residual risk conclusion and traceability across all of them.
7. 7. Unresolved anomalies: 50% of letters.
Often misread. Saying there are no unresolved cybersecurity issues did not answer the question; reviewers meant known software defects left in the product. Listing functional bugs without a security impact assessment was the opposite mistake. Each anomaly needs a description, root cause where possible, safety and effectiveness impact, and a rationale for not fixing it.
8. 8. Threat model: 40% of letters.
Incomplete at the edges rather than absent: no stated assumption that the network is hostile, lifecycle phases such as supply chain, update, and decommissioning left out, hospital or cloud infrastructure omitted, AI-specific threats such as data poisoning missing, and threats that never carried into the risk assessment.
9. 9. Security architecture views: 40% of letters.
The guidance recommends global system, multi-patient harm, updatability and patchability, and security use case views, scaled to the device. Teams often supplied one diagram and described the rest in prose. On a multi-tenant cloud platform, a bare statement that the multi-patient harm view did not apply drew a request for supporting risk analysis.
10. 10. Cloud and shared responsibility: 40% of letters.
Using a cloud provider was fine; leaving the split undocumented was not. Reviewers asked for the service model, which party owns each control, supplier agreements and testing evidence, plans for when the cloud is unavailable, and separate treatment of cloud and on-premise configurations.
11. Watch list: likelihood instead of exploitability (30% of letters).
Lower on frequency, but the hardest error to unwind. Reviewers wrote that cybersecurity risk is assessed on exploitability, not probability. Enclosures, screws, firmware passwords, trained staff, and controlled clinical settings offered as controls were challenged. Close behind the top ten, each in 40% of letters: software traceability, draft or blank documents, and the postmarket management plan.
Charts
All charts are free to re-use with attribution to Blue Goat Cyber. Each chart has an embed-friendly URL - see the press kit for the iframe snippet.
Share of reviewed FDA letters that raised each issue
Percentage of the 30+ letters reviewed that raised each category at least once. Not a rate across all submissions.
Source: Blue Goat Cyber review of 30+ FDA Additional Information letters, read in full, 2026. · Unit: % of letters
Cite this report
Blue Goat Cyber. (2026). Top FDA Cybersecurity Deficiencies: What 30+ FDA Letters Raised Most. https://bluegoatcyber.com/research/fda-medical-device-cybersecurity-deficiencies-2026
Sources & references
Primary sources cited in this article. Links open in a new tab.