What Triggers FDA Cybersecurity Deficiencies for Devices

Part of our FDA cybersecurity deficiency, RTA, and hold-letter response series. For the full overview, start with FDA Deficiency Letter vs RTA vs Hold Letter: What's the Difference?.

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.

Key Takeaways

• Most FDA deficiencies relate to documentation, not device insecurity.
• Section 524B mandates strong cybersecurity documentation for devices.
• Common gaps: incomplete SBOMs, threat modeling, architecture views.
• Technical issues: pen test on wrong builds, weak authentication, encryption.
• Post-market: missing vulnerability policies, unrealistic patch plans.
• Pre-submission audits prevent costly delays and deficiency letters.

Table of Contents

• Key Takeaways
• Why FDA Cybersecurity Deficiencies Are Mostly a Documentation Failure
• What Causes the FDA to Issue a Cybersecurity Deficiency: Common Documentation Triggers
• Technical Testing Failures That Stall Clearance
• Post-Market Planning Failures the FDA Consistently Catches
• A Pre-Submission Self-Audit to Catch These Gaps First
• How to Respond Effectively When a Deficiency Letter Has Already Arrived
• Start with the Audit, Not the Fix

Why this matters

Understanding the triggers for FDA cybersecurity deficiencies is critical because these can significantly delay market clearance, increase development costs, and harm a manufacturer's reputation. Since March 2023, Section 524B of the FD&C Act has mandated cybersecurity documentation as an enforceable requirement, shifting it from recommended guidance to a 'Refuse to Accept' risk if documentation is missing or inadequate. The FDA's 'Cybersecurity in Medical Devices' Final Guidance dated February 3, 2026, explicitly outlines expectations for securing devices throughout their lifecycle.

Manufacturers must demonstrate adherence to security best practices through detailed documentation, aligning with standards like IEC 81001-5-1, ISO 14971, and AAMI TIR57. Failure to do so, even if the device itself is secure, results in deficiencies because reviewers evaluate submissions based on the evidence provided. This situation underscores the importance of a meticulously prepared submission that anticipates FDA scrutiny, ensuring all cybersecurity aspects, from design to post-market surveillance, are clearly articulated and supported.

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

See also: De Novo Cybersecurity Requirements: What the FDA Expects, PMA Supplement vs Real-Time vs 30-Day Notice for Cybersecurity Changes, and FDA Penetration Testing Requirements for Medical Devices.

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.

How Blue Goat approaches this

Blue Goat Cyber's methodology for FDA pre-market submissions centers on proactive identification and remediation of potential cybersecurity deficiencies. Our team, comprised of certified experts (CISSP, OSCP) with ex-military red team experience, conducts thorough audits of your documentation and proposed security controls against the FDA's 'Cybersecurity in Medical Devices' Final Guidance dated February 3, 2026, and other relevant standards.

We specialize in constructing clear, traceable security narratives that address every facet of the FDA's requirements, from detailed SBOMs and threat modeling to architecture views, technical testing results, and post-market plans. Our goal is to ensure your submission is complete and compliant the first time. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our services at FDA Premarket Cybersecurity Services.

FAQ

What is Section 524B and why is it important for medical devices?

Section 524B of the FD&C Act, effective March 2023, now legally mandates cybersecurity requirements for medical devices. This means compliance is no longer just guidance; it's enforceable, and non-compliance can lead to Refuse to Accept actions during submission reviews.

Does the FDA test my medical device hardware for cybersecurity?

No, the FDA reviewers primarily work from your submitted documentation package, not the physical device. Your submission must provide a complete, traceable security narrative from identified threats to implemented controls and verified outcomes.

What elements are critical for a compliant Software Bill of Materials (SBOM)?

A compliant SBOM must be machine-readable (SPDX or CycloneDX), include all NTIA minimum elements (supplier, component, version, etc.), and provide support lifecycle metadata. It must also link to traceable vulnerability assessments for known CVEs.

Why does the FDA flag threat modeling documentation?

The FDA flags threat modeling when it lacks defined assets, specific attack surfaces, concrete threat scenarios, and direct traceability from each threat to demonstrated mitigations and testing results. It should be the backbone of your risk management, not a standalone document.

How can I avoid penetration testing deficiencies?

Ensure penetration testing is conducted on a final, production-equivalent device. Address every finding; if a risk is accepted, provide explicit acceptance criteria and documented justification in your submission. Do not submit a report with open, undiscussed findings.

What post-market plans does the FDA expect for cybersecurity?

The FDA expects a credible vulnerability disclosure policy, realistic and specific patching and update plans, and defined processes for continuous post-market surveillance. These demonstrate ongoing security management throughout the device's lifecycle.

Related: Medical Device Cybersecurity: A Complete Lifecycle Guide

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.