FDA Cybersecurity Deficiency Letter Examples & Solutions

Manufacturers who have been through an FDA cybersecurity review cycle already know the letters are not vague. They cite specific missing elements against specific sections of the February 3, 2026 premarket cybersecurity guidance and against ANSI/AAMI SW96:2023. This guide walks through the deficiency categories we see most often, what the underlying request usually looks like, and how to build a response that survives a second look instead of triggering a third.

RTA holds versus AI requests versus Major deficiencies

Before responding to anything, know which mechanism you are in, because the clock and the required action differ.

An RTA hold is the cheapest to fix and the most avoidable, because it means a required artifact was not present in a recognizable, machine-readable form. See our comparison of deficiency letter types and RTA prevention checklist for the specifics.

Common cybersecurity deficiency categories

SBOM gaps

The most frequent citation. Reviewers do not just check for the presence of an SBOM; they check whether it is machine-readable, whether it includes the NTIA minimum elements, and whether the component versions match the firmware build under review. A typical deficiency reads something like: "The SBOM provided does not include unique identifiers (PURL or CPE) for [n] components, precluding verification of the vulnerability monitoring claim in Section [x]." The fix is not a cover letter explaining your intent; it is a regenerated SBOM with the missing identifiers, tied to the exact build version in the submission. See our SBOM for medical devices guide and CPE vs. PURL guide.

Incomplete threat modeling

Reviewers increasingly ask for evidence that a threat model covered every trust boundary, not just the obvious network interface. A common deficiency: "The threat model does not address the service port or the intra-device communication bus as a trust boundary." Another common pattern is a threat model that identifies threats but does not trace each one to a specific mitigation and a specific test that verifies the mitigation. Closing this requires extending the model's scope, typically using STRIDE, and adding the traceability matrix linking threat to mitigation to test result.

Lack of traceability in security requirements

This shows up as a reviewer asking you to "demonstrate the connection between the identified risk, the corresponding mitigation, and the verification activity." It is a documentation and design-control problem more than a technical one: the underlying engineering work may be sound, but it lives in three different documents that do not reference each other. The fix is a single traceability table, maintained inside your design history file, that a reviewer can follow end to end without cross-referencing multiple PDFs.

Insufficient penetration testing coverage

Deficiencies here typically cite scope, not quality: a test report that covers the mobile app but not the device firmware, or one that used only automated scanning without manual exploit verification. The February 2026 guidance expects vulnerability chaining, boundary analysis, and closed-box testing methodology described explicitly in the report. See our penetration testing for medical devices guide for what a compliant scope looks like.

Postmarket vulnerability management gaps

A common deficiency: "The vulnerability monitoring plan does not identify the specific sources monitored or the triage timeline." Reviewers want to see an operating process, meaning a named coordinated vulnerability disclosure policy at a live URL, a stated triage SLA, and evidence the process has already run at least once, not a description of a process you intend to stand up after clearance.

Unverified third-party software (SOUP) security

For components sourced from suppliers, deficiencies often ask how the manufacturer verified the security posture of software it did not write. A supplier attestation alone is rarely sufficient; reviewers increasingly want to see the supplier's SBOM merged into yours, with a documented process for what happens when the supplier stops patching a component.

How to respond to a deficiency letter

Structure your response around the requirement, not the letter's wording

Organize the response document by the specific 524B or SPDF requirement the deficiency cites, state the gap the FDA identified, present the new or corrected evidence, and close with the residual risk statement if any remains. Reviewers read responses fastest when the structure mirrors the requirement they are checking against, rather than a narrative that restates the whole submission.

Lead with objective evidence, not explanation

The most common reason a response triggers a second AI request is that it explains why the gap is not a problem instead of closing it with new evidence. If a reviewer flagged a missing test, the response needs the test report, not a paragraph arguing the test was unnecessary. Save the rationale for cases where you are genuinely disputing the applicability of a requirement, and even then, back it with a documented risk-based justification in your security risk management file.

Understand the "stop the clock" impact

An AI request or Major deficiency letter pauses the FDA review clock until you respond. For a 510(k), you have 180 days to respond before the submission is considered withdrawn, but every day you take is a day added to your actual time to clearance, not a day recovered. Teams that respond within two to three weeks with a complete package consistently clear faster than teams that use the full 180 days to gather evidence they should have generated the first time. See our FDA cybersecurity review timeline post for how these delays stack up against MDUFA goal dates.

Version everything inside your QMS

Every artifact you add in a deficiency response should be a controlled, versioned document inside your quality management system, cross-referenced to the requirement it satisfies. Submitting evidence that lives outside your design controls creates an audit gap that can resurface in a later 483 observation even after clearance.

Avoiding deficiencies: build the SPDF before you submit

Every deficiency category above traces back to a gap in the underlying Secure Product Development Framework, not to a documentation oversight. The manufacturers who submit clean packages are the ones who built the SBOM generation pipeline, the threat model, and the vulnerability monitoring process during development, so the submission package is a snapshot of work that already exists rather than a reconstruction under deadline pressure. Our SPDF playbook walks through building that process from the start of a program.

How Blue Goat Cyber approaches deficiency responses

We treat a deficiency letter as a scoping document, not a setback. The first step is mapping every cited gap to the specific requirement in the February 2026 guidance or ANSI/AAMI SW96:2023 it references, so the response addresses the actual reviewer concern rather than a plausible-sounding restatement of it. From there we generate the missing objective evidence, whether that is a regenerated SBOM with correct identifiers, an extended threat model, or a penetration test covering the flagged scope, and we version it inside your QMS so the traceability holds up if a reviewer asks a follow-up question. Where a submission has already gone through one unsuccessful round, we run a full gap assessment against all three 524B(b) requirements before responding, because a second AI request usually means the first response addressed the letter's wording rather than the underlying gap. This work is available through our FDA Cybersecurity Deficiency Response service, and manufacturers who want to avoid the cycle altogether typically start with FDA Premarket Cybersecurity Services before their initial submission.

FAQ

What is the most common FDA cybersecurity deficiency?

Incomplete or non-machine-readable SBOMs are the single most common citation, followed by threat models that are not traced to test evidence and postmarket vulnerability plans that describe an intended process rather than an operating one. All three are traceable to gaps in the underlying SPDF rather than to submission writing quality.

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

For a 510(k), you generally have 180 days to respond to a Major deficiency or AI letter before the submission is considered withdrawn; an RTA hold has a shorter administrative timeline tied to resubmission. In practice, the fastest-clearing responses go back within two to three weeks with a complete evidentiary package rather than using the full statutory window.

Does a deficiency letter mean my submission will be rejected?

No. A deficiency letter is a request for more information or corrected evidence, not a rejection. Submissions routinely clear after one or two rounds of deficiency response. What increases the odds of an outright rejection is responding with narrative explanation instead of the specific objective evidence the letter requested.

Can I dispute an FDA cybersecurity deficiency instead of fixing it?

Yes, in limited cases, if you can show the requirement does not apply to your device or that an alternative approach provides equivalent assurance, documented in your security risk management file. This is a higher bar than simply disagreeing with the reviewer, and it works far better when the alternative approach was already planned into your SPDF rather than improvised in the response.

What is the difference between an RTA hold and an AI request for cybersecurity?

An RTA hold happens before substantive review even begins, when a required element is missing outright, most often the SBOM or the cybersecurity management plan. An AI request happens during substantive review, when an element is present but the reviewer needs clarification or supplemental evidence. RTA holds are entirely avoidable with a completeness check before filing.

Do cybersecurity deficiencies affect PMA submissions differently than 510(k)s?

The underlying 524B(b) requirements are the same, but PMA review typically applies more scrutiny to the security risk management file and penetration test scope given the higher device class. Deficiency letters on PMA submissions more often cite depth of evidence rather than absence of an artifact. See our PMA cybersecurity requirements guide for pathway-specific detail.

Related guides

• FDA 524B Cybersecurity Requirements Explained
• FDA Deficiency Letter vs. RTA vs. Hold Letter
• FDA Cybersecurity RTA Prevention Checklist
• FDA Cybersecurity Deficiency Response Checklist
• How to Respond to an FDA Cybersecurity AI Request

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• Refuse to Accept Policy for Cyber Devices and Related Systems (FDA)
• ANSI/AAMI SW96:2023, Medical Device Security

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.