Understanding what causes the FDA to issue a cybersecurity deficiency for medical devices starts with one uncomfortable truth: most deficiencies have nothing to do with a bad device. The device might be perfectly secure. The submission just didn’t prove it. FDA reviewers work from documentation, not hardware they test themselves. If your submission doesn’t tell a complete, traceable security story, from identified threats to implemented controls to verified outcomes, the deficiency letter follows. That’s how this works.
The stakes are real. A cybersecurity deficiency can delay clearance by months, cost hundreds of thousands in rework, and in serious cases, force a complete resubmission. Section 524B of the FD&C Act, which took effect in March 2023, moved cybersecurity from guidance recommendations to enforceable mandates. Deficiency rates climbed after that shift. eSTAR submissions now face Technical Screening holds when cybersecurity documentation is missing. What used to be best practice is now a Refuse to Accept risk.
The sections below break down the specific triggers that generate deficiency letters, what FDA reviewers flag, why they flag it, and what you can do about each one before the letter arrives.
Why FDA Cybersecurity Deficiencies Are Mostly a Documentation Failure
Reviewers work from your documentation package. If that package doesn’t connect threats to controls to testing results in a traceable, coherent way, they have no choice but to ask for more. The burden of proof sits entirely with the manufacturer. That’s not a criticism of the process; it’s how regulatory review works, and device makers who treat cybersecurity documentation as secondary pay for it later.
Section 524B changed the enforcement landscape in a meaningful way. Before 2023, FDA cybersecurity guidance carried significant weight but wasn’t directly tied to submission acceptance. Now it is. Submissions for cyber devices, defined as devices that include software validated by the sponsor, can connect to the internet, and have characteristics vulnerable to cybersecurity threats, must demonstrate compliance with Section 524B requirements or face RTA action. The October 2023 eSTAR enforcement rollout made this concrete. Missing cybersecurity documentation now stops submissions at Technical Screening, not just during substantive review.
What Causes the FDA to Issue a Cybersecurity Deficiency: Common Documentation Triggers
Software Bill of Materials are among the most consistent deficiency triggers in current submissions. The Software Bill of Materials is mandatory under Section 524B, and FDA expectations go well beyond a component list. Reviewers cross-reference SBOMs against vulnerability databases like the NVD. Your SBOM must be machine-readable, formatted in SPDX or CycloneDX, and include all NTIA minimum elements: supplier name, component name, version, unique identifier, dependency relationship, SBOM author, and timestamp. It also needs support lifecycle metadata, including end-of-support dates, and traceable vulnerability assessments for known CVEs. A high-level spreadsheet won’t clear this bar.
Threat Modeling Gaps
Threat modeling is another major documentation failure that draws deficiencies. Reviewers expect defined assets, specific attack surfaces, concrete threat scenarios, and direct traceability from each threat to mitigations and testing results. Submissions that include a data flow diagram without connecting it to the risk assessment consistently draw additional information requests. The threat model isn’t decorative. It’s supposed to function as the backbone of your cybersecurity risk management file, not a one-time deliverable that gets filed and forgotten.
Architecture Documentation Shortfalls
Architecture documentation is a third consistent gap in 510(k) cybersecurity requirements. The FDA expects multiple views, including a Multi-Patient Harm View and an Updateability and Patchability View. These aren’t optional formatting preferences. If your architecture documentation doesn’t show how security controls are implemented at the design level, the submission signals that cybersecurity was retrofitted rather than built in. That signal tends to generate scrutiny across the entire cybersecurity section of the submission.
Technical Testing Failures That Stall Clearance
Penetration testing deficiencies come down to one persistent mistake: testing on the wrong build. FDA guidance is clear that pen testing must be conducted on a final, production-equivalent device, not a prototype, not a pre-release version. Every finding must be addressed. If a low or medium risk is accepted rather than remediated, the submission needs explicit acceptance criteria and documented justification. Submitting a pen test report with open findings and no disposition is one of the fastest ways to generate a deficiency letter. Reviewers aren’t looking for a clean bill of health; they’re looking for evidence that findings were taken seriously and handled systematically.
Authentication and Access Control
Authentication and access control documentation is another consistent source of deficiencies. Per FDA guidance, reviewers look for layered authentication models that differentiate user roles: caregiver, administrator, service technician. Single-layer authentication with no role-based access controls, or submissions that fail to document how the device handles unauthorized access attempts, draw additional information requests. The documentation needs to be specific, not descriptive. “The device uses strong authentication” is not a sufficient answer.
Encryption and Key Management
Encryption gaps complete the technical testing picture. Inadequate key management documentation, unprotected data transfers, and failure to demonstrate that sensitive data, including commands, credentials, and patient information, is protected both in transit and at rest are all flagged. High-level statements about encryption without implementation details and verification evidence don’t satisfy reviewers. They need to see what was implemented and how it was confirmed to work.
Post-Market Planning Failures the FDA Consistently Catches
A cybersecurity deficiency isn’t always about the device at launch. The FDA expects lifecycle proof. Submissions that lack a credible vulnerability disclosure policy are flagged consistently. The policy needs to include a contact point for reporting vulnerabilities, a defined response process, and integration with the manufacturer’s MDR obligations. Labeling must also disclose the expected security update support lifetime and connectivity details. Referencing a policy without providing specifics doesn’t satisfy this requirement.
Patching and Update Plans
Patching and update plans are another common failure point. Reviewers evaluate whether the device can actually be updated in the field and whether the manufacturer has a realistic plan for doing so. Plans that don’t specify update timelines, don’t differentiate between routine and emergency patches, or fail to address devices in remote or resource-limited environments don’t hold up. The plan needs to be specific and operationally credible, not aspirational.
Post-market surveillance processes must show active monitoring, not reactive response. The FDA wants evidence that manufacturers will continuously monitor for new vulnerabilities in deployed devices. Submissions that lack defined processes for monitoring, assessing, and communicating post-market risks leave reviewers without confidence that device safety will be maintained through the product lifecycle. This is where many submissions fall short: premarket documentation is solid, but the forward-looking plan is thin.
A Pre-Submission Self-Audit to Catch These Gaps First
Before you submit, run through this documentation audit. Is the SBOM complete, machine-readable, and current? Does the threat model trace directly to the risk assessment and to testing results? Are all required architecture views included? Is the cybersecurity risk management file traceable end-to-end from identified threats through implemented controls to verified outcomes? Are all labeling requirements met, including support lifetime and vulnerability reporting contact information? These are the same questions an FDA reviewer will ask. Answering them before submission is cheaper than answering them after.
On the technical side, verify that penetration testing was performed on a production-equivalent build, that all findings are resolved or explicitly accepted with documented justification, and that authentication, encryption, and access control documentation is specific rather than descriptive. Confirm that no known vulnerabilities in your SBOM components are unaddressed, even low-severity ones. Unaddressed CVEs in a submitted SBOM are a direct deficiency trigger.
For most device makers, especially those navigating a first 510(k) or working with a new FDA reviewer, an independent pre-submission cybersecurity review is the most reliable way to surface these gaps before the FDA does. That’s exactly the work Blue Goat Cyber does: reviewing submissions against current FDA guidance to identify the specific documentation and testing gaps that generate deficiency letters. Companies that complete this step consistently avoid the costly delays that come from reactive fixes after a letter arrives.
How to Respond Effectively When a Deficiency Letter Has Already Arrived
FDA Additional Information letters give manufacturers 180 calendar days to respond via resubmission. Use that window carefully. If any of the deficiency language is unclear or seems misaligned with prior FDA feedback, file a Submission Issue Request through the Q-Submission process before reworking your documentation. FDA responds to SIRs within 21 days. Clarifying the scope of a deficiency before you respond saves significant time compared to submitting a response that misses the point.
A complete deficiency response package includes: revised and traceable risk documentation, an updated SBOM with current CVE assessments, a revised threat model if the original was deficient, complete penetration testing results on a current production-equivalent device, and documented post-market plans that address the specific gaps the reviewer identified. Reference the A Guide to FDA’s Cybersecurity Documentation Requirements throughout your response to anchor every element to current standards. Partial fixes that address one section without resolving root cause across the full submission typically generate another round of deficiencies, which extends your timeline by another 180-day cycle.
When manufacturers are already in the review cycle and need to build a complete evidence package quickly, having a team with deep FDA submission experience makes the difference between a clean response and a second deficiency letter. Blue Goat Cyber’s deficiency response support is built for exactly this scenario, with a track record across hundreds of medical device submissions.
Start with the Audit, Not the Fix
Knowing what causes the FDA to issue a cybersecurity deficiency for medical devices makes the solution straightforward: audit before you submit. The same gaps appear across submissions, incomplete SBOMs, disconnected threat models, unresolved testing findings, and post-market plans that don’t hold up to scrutiny. None of these are unavoidable. They’re all catchable in a pre-submission review, and they’re all fixable with the right documentation and evidence.
The manufacturers who clear fastest treat their submission the way an FDA reviewer would before it reaches one. That means tracing every claim back to evidence, resolving every finding, and building a post-market plan that’s operationally credible. The device might be genuinely secure. The goal is to prove it on paper with the same rigor used to build it.