FDA Cybersecurity Deficiency Letter Examples & Solutions

Analyze real-world FDA cybersecurity deficiency letter examples. Learn how to address RTA and AI deficiency requests for 510(k) and PMA submissions.

This guide is written for medical device manufacturers navigating FDA cybersecurity deficiency letter examples. It is built from real submissions, FDA correspondence, and the standards reviewers actually cite. Use it as a working reference: read straight through, jump to the section that matches your current gap, or hand it to your engineering and regulatory leads as a checklist.

Introduction to FDA Cybersecurity Deficiencies

A cybersecurity deficiency is any point in FDA review where a reviewer determines your submission does not provide reasonable assurance of cybersecurity, and it can surface at two very different stages: acceptance review (resulting in a refuse-to-accept, or RTA, hold) or substantive review (resulting in an additional information, or AI, request, also called a Major deficiency letter). Understanding which stage a given deficiency pattern belongs to matters because the remedy, and the timeline pressure, is different in each case. This guide works through the deficiency categories we see most often across cleared submissions and deficiency responses, with the goal of helping you catch the same issues before an FDA reviewer does.

The Shift Since Section 524B of the FD&C Act

Before Section 524B took effect for submissions received on or after March 29, 2023, cybersecurity gaps were handled almost exclusively as AI requests during substantive review, since the FDA lacked explicit statutory authority to refuse a submission outright for missing cyber content. Since 524B, the FDA can and does issue RTA holds for cyber devices that lack required 524B(b) content, which means a cybersecurity gap can now stop a submission before it is ever substantively reviewed. This has raised the stakes on getting the cybersecurity section complete and internally consistent before the initial filing, since an RTA hold effectively restarts your review clock rather than pausing it.

RTA (Refuse to Accept) vs. Substantive Interaction Deficiencies

An RTA hold happens during the administrative acceptance review, typically within 15 days of filing, and is based on a checklist: either the required cyber device artifact is present in some recognizable form or it is not. A substantive interaction deficiency (an AI request or Major deficiency letter) happens later, once a reviewer has actually evaluated the content, and addresses whether the artifact that is present is adequate, for example whether the threat model is complete or the penetration testing scope matches the device's actual attack surface. RTA deficiencies are usually the faster, cheaper problem to fix because they are almost always about missing structure; substantive deficiencies are slower because they require you to demonstrate the content itself is technically sound, which sometimes means generating new evidence rather than just reformatting existing evidence.

Common Cybersecurity Deficiency Categories

Across the deficiency patterns we track, three categories account for a disproportionate share of both RTA holds and AI requests: SBOM completeness, threat modeling depth, and requirement traceability.

Example 1: Software Bill of Materials (SBOM) Gaps

The most common SBOM deficiency is a bill of materials delivered as a static document (PDF or spreadsheet) rather than a machine-readable format such as CycloneDX 1.5+ or SPDX 2.3+, which prevents the reviewer from cross-referencing components against vulnerability databases. A close second is an SBOM missing dependency relationships or unique component identifiers, both NTIA minimum elements, which makes it impossible to determine whether a listed component version is actually the one shipping in the device. A well-formed deficiency response replaces the SBOM entirely with a build-pipeline-generated, machine-readable version and includes a short narrative explaining how the SBOM will be kept current post-clearance.

Example 2: Incomplete Threat Modeling (STRIDE/TARA)

Reviewers frequently flag threat models that were clearly adapted from a generic template rather than built against the device's actual architecture, evidenced by threats that don't correspond to any interface the device actually has, or interfaces the device does have that appear nowhere in the model. A second common pattern is a threat model that identifies threats but does not trace each one to a specific mitigation or an explicit residual risk decision, leaving the reviewer unable to confirm the threat was actually addressed. Fixing this deficiency typically requires rebuilding the model around the device's real data flow diagram and explicitly linking every identified threat to either a control or a documented risk acceptance.

Example 3: Lack of Traceability in Security Requirements

This deficiency shows up when a submission's security requirements, architecture, test cases, and risk assessment exist as separate documents that don't reference each other, so a reviewer cannot confirm that a given requirement was actually tested or that a given risk was actually mitigated by a specific control. The fix is a traceability matrix, sometimes required explicitly in an AI letter, that maps each security requirement to its design control, its verification test, and its corresponding risk management entry. Manufacturers who build this matrix as they develop the artifacts, rather than reconstructing it retroactively for a deficiency response, consistently produce cleaner, faster responses.

Detailed Analysis: Deficiency Letter Examples

The deficiency patterns below reflect language and structure typical of what we see in actual FDA correspondence, generalized to avoid identifying any specific submission.

Sample Deficiency: Insufficient Penetration Testing Coverage

A typical deficiency reads along the lines of: "The submitted penetration testing report does not address all interfaces identified in the cybersecurity risk assessment; please provide testing results for the Bluetooth Low Energy interface or justify its exclusion from testing scope." This pattern occurs when the pen test scope was defined before the threat model was finalized, so new interfaces or attack surfaces identified later in development never made it into the test plan. The fix requires either executing additional testing against the missed interface or providing a documented, risk-based justification for exclusion, such as the interface being physically inaccessible in the deployed configuration. To see how recently cleared submissions in your product code structure penetration-test coverage, search the FDA 510(k), De Novo, and PMA databases using your product code.

Sample Deficiency: Vulnerability Management Postmarket Plans

A representative deficiency states: "The vulnerability monitoring plan does not specify a defined process, cadence, or responsible party for triaging newly disclosed vulnerabilities in third-party components identified in the SBOM." This happens when the postmarket section describes an intent ("the manufacturer will monitor for vulnerabilities") rather than an operating process with a named tool or feed, a triage cadence, and an escalation path tied to severity. Responding well means naming the actual monitoring mechanism (for example, a specific CVE feed matched against the SBOM on a defined schedule) and the internal role accountable for triage decisions. For devices with planned cybersecurity control updates (e.g., scheduled cryptographic migrations or model refreshes), a Predetermined Change Control Plan pre-authorizes those changes and reduces the postmarket evidence burden.

Sample Deficiency: Unverified Third-Party Software (SOUP) Security

This deficiency typically reads: "Please provide evidence of security evaluation for third-party and off-the-shelf software components, including any known vulnerabilities and corresponding mitigations." It arises when a manufacturer treats software of unknown provenance (SOUP) as covered simply by listing it in the SBOM, without a corresponding vulnerability check or a VEX statement addressing known CVEs in that component. The fix is a documented SOUP evaluation showing the version used, known vulnerabilities as of the evaluation date, an exploitability assessment for the device's actual deployment context, and a mitigation or acceptance decision for anything not remediated.

How to Respond to a Deficiency Letter (AIs)

A strong deficiency response addresses every item the FDA raised individually, in the order the letter raised them, with a direct answer followed by the supporting evidence, rather than a narrative rebuttal that requires the reviewer to hunt for the specific answer.

The 'Stop the Clock' Impact on Timeline

An AI request or Major deficiency letter stops the FDA's review clock until the manufacturer responds; the clock does not resume until the response is received and logged. For a 510(k), the sponsor generally has 180 days to respond to a Major deficiency letter before the submission is considered withdrawn, though best practice is to respond as quickly as the evidence can be credibly generated, since a rushed response that generates a second round of AI questions costs more total time than a slower, complete first response. Sponsors should treat the response deadline as a ceiling, not a target.

Structuring Your Response and Objective Evidence

Structure the response as a point-by-point table: the FDA's question, a direct answer, and a reference to the specific new or revised evidence (document name and section) that supports it. Avoid restating the original submission's content as if it already answered the question; if the reviewer asked the question, the original content was, by definition, insufficient to answer it. Include a redline or summary of what changed in each revised document so the reviewer can quickly locate the delta rather than re-reading the entire artifact.

Avoiding Deficiencies: The SPDF Approach

The most durable way to reduce deficiency risk is to build cybersecurity evidence inside a real Secure Product Development Framework as development happens, so the SBOM, threat model, architecture, and test plan are generated as connected outputs of one process rather than reconstructed for the submission after the fact. Manufacturers who treat the cybersecurity section as a parallel workstream from the start of development, with the same design-control rigor as safety requirements, consistently produce submissions with fewer and less severe deficiencies. Before filing, run the FDA database mining workflow to calibrate SBOM depth, threat-model methodology, and pen-test scope against what reviewers in your product code have actually accepted.

How Blue Goat Cyber Approaches FDA cybersecurity deficiency letter examples

We treat FDA cybersecurity deficiency letter examples as a regulated engineering workstream, not a one-time document drop. Every engagement is led by senior medical-device security engineers who have shipped 250+ FDA cybersecurity submissions across 510(k), De Novo, PMA, and EU MDR pathways. Here is how we run it end to end:

• Scoping against your device profile. We baseline connectivity, interfaces, data flows, and intended use before we touch a template - because reviewer expectations for a Class II wearable are not the same as a networked hospital platform.
• Standards mapping in writing. Every deliverable is traced to the February 2026 FDA premarket cybersecurity guidance, AAMI SW96, AAMI TIR57 / TIR97, IEC 81001-5-1, and ISO 14971 - with the citation in the artifact itself so reviewers do not have to guess.
• Evidence generated inside your QMS. Threat models, SBOMs, security risk assessments, and test reports are versioned under design controls so the traceability from requirement → test → residual risk holds up under audit.
• Independent testing where it counts. Penetration testing and vulnerability analysis are executed by a testing team that does not also write the design - the separation FDA reviewers increasingly expect on cyber devices.
• Deficiency-ready posture. We anticipate the RTA, AI-letter, and Major deficiency patterns FDA has issued over the past 24 months and pre-empt them in the initial submission, cutting the odds of a second review cycle.
• Postmarket handoff, not abandonment. Every premarket package leaves you with a working postmarket monitoring plan, CVD process, and update cadence so the evidence you shipped stays defensible after clearance.

If you want that treatment applied to your FDA cybersecurity deficiency letter examples package, our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements are the two most common entry points.

Frequently asked questions

How do I respond to an FDA cybersecurity deficiency letter?

Read every item as a discrete question and respond to each one individually, in order, with a direct answer followed by a reference to the specific new or revised document and section that provides the supporting evidence. Do not simply resubmit or restate the original content, since the reviewer already determined it was insufficient; provide genuinely new or corrected evidence, such as a rebuilt threat model, an expanded penetration test, or a completed traceability matrix. Include a summary of changes so the reviewer can quickly find what is different from the original submission. If the deficiency reveals a systemic gap, such as an SPDF that never actually connected threat modeling to testing, address the systemic issue, not just the specific example the FDA happened to cite.

What are the most common reasons for FDA cybersecurity holds?

The most frequent causes are a non-machine-readable or incomplete SBOM, a threat model that reads as generic rather than device-specific, penetration testing scope that does not cover all interfaces identified in the risk assessment, and missing traceability between security requirements, design controls, and test evidence. RTA holds specifically tend to be structural, an entire required artifact is missing or unrecognizable, while AI requests tend to be about adequacy, the artifact exists but does not hold up to scrutiny. Both categories trace back to the same root cause in most cases: cybersecurity documentation assembled after development rather than generated as part of it.

Does a deficiency letter mean my 510(k) will be rejected?

No. A deficiency letter, whether an RTA hold or an AI/Major deficiency request, is a request for correction or additional information, not a denial. The submission can still be cleared once the identified gaps are adequately addressed within the response window. What it does mean is that your review timeline has been extended, since the FDA's review clock stops until you respond, so the practical cost is time and, if the response requires new testing, additional engineering effort, not an automatic negative outcome.

What does the FDA require for SBOM in a deficiency response?

The FDA expects a corrected, machine-readable SBOM in CycloneDX 1.5+ or SPDX 2.3+ format containing all NTIA minimum elements: supplier, component name, version, dependency relationships, unique identifiers, author of the SBOM data, and timestamp. If the original deficiency cited known vulnerabilities in listed components, the response should also include a VEX statement or equivalent exploitability assessment addressing each cited vulnerability specifically, not a general statement that the components are "monitored." A response that simply adds missing fields to the existing static document without moving to a machine-readable format typically does not fully resolve an SBOM-format deficiency.

How much time do I have to answer FDA cybersecurity AIs?

FDA gives sponsors 180 days to respond to a Major deficiency / AI letter (15 days for an RTA hold). Plan for two iteration cycles; teams that ship a clean response in one round are the ones with a working SPDF. Because the review clock is stopped during this window, there is no advantage to waiting until close to the deadline; a faster, complete response gets your device back into active review sooner, while a rushed response that misses part of the request simply generates a second deficiency cycle on the same 180-day structure.

Where this fits in the cluster

This page sits downstream of our pillar resources on FDA cybersecurity deficiency letter examples. If you arrived here from a different starting point, these are the most useful adjacent pages:

• FDA Cybersecurity Deficiency Response
• 12 Reasons the FDA Rejects Medical Device Cybersecurity Submissions
• FDA Cybersecurity Deficiency Letter Response Checklist
• The SPDF Playbook for FDA-Ready Medical Devices

Related from Blue Goat Cyber

• FDA Premarket Cybersecurity Services
• Medical Device Threat Modeling
• FDA-Compliant SBOM Services
• Medical Device Penetration Testing
• 12 Critical Threat Modeling Gaps in Medical Device Submissions

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. U.S. Food and Drug Administration (FDA)
• Postmarket Management of Cybersecurity in Medical Devices. U.S. Food and Drug Administration (FDA)
• Secure Software Development Framework (SSDF) Version 1.1. NIST
• Principles and Practices for Medical Device Cybersecurity. International Medical Device Regulators Forum (IMDRF)

Talk to a regulatory cybersecurity team

If you are working through FDA cybersecurity deficiency letter examples and want a second pair of eyes on your submission package, we ship cybersecurity deliverables for medical device manufacturers across 510(k), De Novo, PMA, and EU MDR pathways. Book a discovery session and we will walk your evidence with you.

Related precedent-research reading

• How to Navigate the FDA 510(k), De Novo, and PMA Databases for Cybersecurity. The three premarket databases and what each one exposes about cleared cybersecurity content.
• Mining FDA Databases for Medical Device Cybersecurity Precedent. A five-step workflow that turns 510(k), De Novo, PMA, MAUDE, and FOIA reads into a submission-ready evidence baseline.