Receiving an FDA cybersecurity Additional Information Request (AIR) doesn’t mean your submission is dead. It means the clock is ticking, and the next move has to be precise. FDA issues these requests when reviewers find specific, documented gaps in your cybersecurity package, and they expect every gap to be closed in a single, well-structured response. A partial answer, an incomplete document, or a misreading of what the reviewer actually asked often leads to follow-up questions or, worse, a Not Substantially Equivalent determination, and the review clock resumes the moment FDA receives your response, leaving you with whatever days remain.
For a standard 510(k), an AI Request typically arrives around day 58 to 60 of the 90-day review cycle, leaving roughly 26 to 32 days on the clock once your response is received. You also have 180 calendar days to submit a response before the submission is automatically withdrawn. Both constraints together explain why the initial 48 to 72 hours after receiving an AIR deserve careful, deliberate triage, more than almost any other phase in the process.
This article walks you through how to read and triage the request, identify exactly what the FDA needs to see, assemble the right documentation, and structure a response that closes deficiencies cleanly. It also covers what you can do now to reduce the likelihood of this happening on your next submission.
What actually triggers an FDA cybersecurity additional information request
FDA reviewers don’t issue Additional Information Requests arbitrarily. Every deficiency they cite maps to a specific expectation in the agency’s cybersecurity guidance, and understanding that connection is the first step toward fixing it. The June 2025 final guidance (superseding the September 2023 version) formally expanded the definition of “cyber devices” to include any device with embedded firmware or FPGAs, mandated FIPS 140-3 compliant cryptography, and required full disclosure of all communication interfaces. Submissions that cleared review in 2022 are now being evaluated against a meaningfully higher bar.
The most common deficiencies fall into a predictable pattern. Threat models that don’t trace risks through the full system scope, including cloud infrastructure, update mechanisms, and supply chain relationships, consistently draw reviewer attention. SBOMs (Software Bills of Materials) that exist in name only, without machine-readable formatting or component-level vulnerability tracking, are another frequent trigger. Penetration test reports with unresolved low or medium findings and no documented acceptance rationale almost always generate follow-up, even when the findings themselves seem minor. Analyses of common FDA cybersecurity objections can help teams anticipate these recurring issues and prioritize fixes.
Missing controls and weak vulnerability management
Missing security controls from Appendix 1 of the guidance, such as event logging or cryptographic implementation, without a technical justification for their absence is another common pattern. Reviewers in 2025 treat these controls as mandatory unless you can demonstrate why they don’t apply to your device architecture. Weak or absent vulnerability management plans, particularly those that don’t reference sources like CISA’s Known Exploited Vulnerabilities catalog, round out the list of issues that reliably produce an AIR.
How to read and triage your FDA cybersecurity additional information request
The worst thing a team can do after receiving an AIR is immediately start producing documents. The first 48 to 72 hours should be spent understanding exactly what the FDA is asking, not writing responses. Misreading a deficiency and addressing something adjacent to it is one of the most common reasons manufacturers end up in a second round of questions.
FDA’s language in deficiency letters follows recognizable patterns. In the author’s experience interpreting these letters, “inadequate” typically signals that documentation exists but doesn’t go deep enough, while “insufficient” usually points to a required element that’s missing entirely. Knowing the difference shapes how much rework is actually needed. Each cited deficiency also maps to a specific section of the guidance, and identifying those sections tells you the exact standard you’re being held to, which makes the response much easier to scope and write.
Sorting deficiencies into workstreams
Sort deficiencies into categories: documentation gaps (threat model, SBOM, architecture views), testing gaps (pen test scope or unresolved findings), and process gaps (no vulnerability management plan, no QMS integration). You might also encounter a fourth type, scope gaps, where the system boundary itself is defined too narrowly. This triage determines your response timeline and identifies who on the team needs to be involved. Mapping each deficiency to a specific deliverable owner early keeps the response on schedule even when the documentation list is long.
The FDA also allows manufacturers to request a clarification teleconference within 10 calendar days of receiving an AIR. This option makes sense when the deficiency language is ambiguous or when multiple items overlap in ways that make it unclear what evidence would satisfy the reviewer. Prepare your questions in advance, confirm anything discussed in writing afterward, and document what the reviewer agreed would address each item. That written record becomes part of your response strategy. For practical, step-by-step instructions on crafting a compliant reply, consult How to Respond to a 510(k) Cybersecurity Deficiency Letter.
The cybersecurity documentation FDA expects in your response
A successful response isn’t just answering the questions the FDA asked. It’s demonstrating a defensible, traceable cybersecurity program. Reviewers are looking for evidence, not explanations, and the documentation has to show a connected system where risks are identified, mitigations are implemented, and the entire picture links back to your design controls. Refer to FDA’s final cybersecurity guidance for the regulatory expectations that underpin reviewer decisions.
For threat model responses, FDA expects end-to-end system scope that includes cloud infrastructure, update mechanisms, interoperability risks, and supply chain dependencies. Mitigations should trace directly back to design controls, and the risk model itself should follow a nonprobabilistic approach focused on exploitability and impact rather than traditional FMEA-style severity and likelihood ratings. The 2025 guidance is explicit on this point, and responses that still present traditional risk matrices often generate follow-up questions.
SBOM requirements and traceability
SBOM documentation must be machine-readable, formatted in a standard like CycloneDX or SPDX, and include component names, versions, supplier names, unique identifiers, and dependency relationships. Beyond the inventory itself, the FDA expects evidence that known vulnerabilities in listed components have been evaluated and addressed. The SBOM should connect directly to your threat model. Traceability should show how component-level risks map to identified threats, and how those threats link to implemented controls.
Penetration testing expectations
For penetration testing, the test must cover a production-equivalent device, all system elements, and every communication interface. Every finding, including low-severity ones, needs a documented disposition: mitigated, accepted with a written rationale, or deferred with a specific timeline and justification. Responses that leave even minor findings without clear documentation consistently draw follow-up from reviewers.
On the process side, the FDA expects a forward-looking vulnerability management plan with defined patch and update processes, cryptographic signing, rollback protection, and evidence that cybersecurity obligations are embedded in the QMS through process records, not just policy statements.
How to structure and submit your response package
Once the evidence is assembled, how it’s packaged and submitted matters as much as the content itself. A disorganized response that makes reviewers search for answers is a reliable path to a second round of questions. The cover letter does most of the structural work.
The cover letter should open with a concise summary of the deficiencies cited, followed by a table or index that maps each numbered deficiency to the specific section of the response package addressing it. Each entry should include a brief narrative explaining what was added or revised and why it satisfies the reviewer’s concern. Structuring AIR responses this way, building a clear deficiency-to-document trail, allows FDA reviewers to confirm resolution without guessing and reduces the likelihood of cycling through multiple response iterations.
On the submission mechanics side, responses go to the FDA’s Document Control Center via eCopy, and the review clock resumes immediately upon receipt. With only 26 to 32 days typically remaining on a 510(k) review clock after an AIR is issued, a weak or incomplete first response has almost no recovery window. The 180-day response deadline is equally real. Missing it results in automatic withdrawal and a full re-filing, with no extensions available for 510(k) or De Novo submissions. For a broader perspective on how different submission pathways affect cybersecurity expectations, see PMA vs De Novo vs 510(k): Cybersecurity Impact on FDA Submissions. Practical guides to handling additional information requests can also help your team avoid procedural missteps; see this overview of additional information requests.
What to expect after you submit, and what a second round signals
Submitting a complete response doesn’t guarantee immediate clearance, but it does restart the path toward it. After the FDA receives your response, review resumes against the remaining days on the 510(k) clock, typically resulting in a decision within 26 to 32 days for a standard submission. A response that cleanly closes every cited deficiency with traceable evidence substantially reduces the likelihood of another information request. A response that partially addresses deficiencies, or introduces new inconsistencies through mismatched documentation, can trigger a second round.
If the FDA issues a second AIR, it’s usually a signal of one of two things: the first response left gaps in specific evidence, or new inconsistencies surfaced during review of the updated package. Approach a second response differently. Go back to the original deficiency language, audit exactly what was submitted against each item, and identify where the evidence fell short or contradicted other documentation. In some cases, a Q-Submission meeting before submitting again can help clarify what FDA needs to see and prevent a third round. For additional context on the AIR process and expectations, this Additional Information Requests reference can be useful when planning your audit and rework steps.
Reducing the risk of another AI request in future submissions
The best response to an AIR is building a submission that doesn’t generate one. That means integrating cybersecurity into the development lifecycle before the submission window opens, not assembling documentation in the final weeks before filing. A Secure Product Development Framework built early gives your team the documentation backbone that reviewers expect: threat modeling completed during design, an SBOM maintained throughout development and linked to vulnerability management from day one, and penetration testing scoped to production-equivalent hardware rather than development builds. For focused 510(k) preparation checklists, see 510(k) Cybersecurity Requirements Every Maker Must Meet.
QMS records should document the cybersecurity development lifecycle in a way that makes the process auditable. The 2025 guidance reflects a clear shift toward process evidence, reviewers look for documentation showing how cybersecurity was managed throughout development, not just completed artifacts at the end. This is especially true for novel device architectures or devices with complex connectivity profiles where the guidance doesn’t fully address every edge case.
Pre-submission meetings, formally called Q-Submissions, are among the most valuable and underutilized tools in the premarket process. Teams that use pre-subs to align their cybersecurity documentation approach with the FDA arrive at submission with reviewer agreement on scope and methodology. That agreement meaningfully reduces the chance of an AIR, because the documentation strategy was already validated before the formal clock started running.
Getting it right the first time is always the faster path
An FDA cybersecurity Additional Information Request is a solvable problem. It requires speed, precision, and a clear understanding of what reviewers actually need to see. Manufacturers who triage deficiencies carefully, build response packages with full traceability, and submit clean cover letters with deficiency-to-document mapping get back on the path to clearance. Those who guess, rush, or partially address the cited gaps tend to cycle through multiple rounds, burning time and budget with each iteration.
Navigating a complex AIR is significantly easier with a team that has direct experience resolving FDA cybersecurity deficiencies. Blue Goat Cyber works exclusively in medical device cybersecurity, our focus gives us deep familiarity with what reviewers look for, how to structure the evidence, and how to close gaps without introducing new ones. If you’re facing an AIR right now, engaging a specialized team is the most reliable way to protect the remaining review window and move toward clearance with confidence.
Related: Medical Device Cybersecurity: A Complete Lifecycle Guide