510(k) Cybersecurity Deficiencies That Trigger FDA Holds

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?.

Cybersecurity has become one of the leading reasons 510(k) submissions stall during FDA review. Since Section 524B of the FD&C Act made cybersecurity documentation mandatory for "cyber devices," reviewers evaluate submissions against explicit documentation expectations laid out in Section 524B and the FDA's February 2026 Final Premarket Cybersecurity Guidance - not a general impression. The same four deficiency categories appear across submissions repeatedly: incomplete SBOMs, underdeveloped threat models, penetration testing with coverage gaps, and SPDF evidence that asserts rather than proves. These aren't edge cases. They're documented patterns seen across the industry.

Key Takeaways

• Incomplete SBOMs lead to FDA holds.
• Undertaking threat models trigger deficiencies.
• Penetration testing must cover all attack surfaces.
• SPDF evidence requires specific documentation.
• Traceability links components, threats, and controls.
• FDA guidance aligns with 524B requirements.

Table of Contents

• Key Takeaways
• What the FDA Now Requires and How Deficiencies Actually Happen
• SBOM Gaps That Draw Immediate FDA Scrutiny
• Threat Model Documentation FDA Reviewers Flag as Insufficient
• Penetration Testing Reports That Don't Clear the Bar
• Weak SPDF Evidence and Security Documentation Gaps
• A Pre-Submission Checklist to Close Every Gap Before Filing
• The Bottom Line on Preventing 510(k) Cybersecurity Deficiencies

Why this matters

Unaddressed 510(k) cybersecurity deficiencies translate directly into significant market delays and revenue loss. The FDA, armed with its February 3, 2026 'Cybersecurity in Medical Devices' Final Guidance, now mandates rigorous documentation for "cyber devices." This guidance, combined with Section 524B of the FD&C Act, elevates cybersecurity from a recommendation to a critical compliance requirement. Device manufacturers must demonstrate adherence to principles outlined in standards like AAMI SW96, IEC 81001-5-1, and ISO 14971. Failure to provide granular, auditable evidence for areas such as software bill of materials (SBOMs), defensible threat modeling, and thorough penetration testing results in critical review holds. Each hold prolongs time to market, impacts competitive positioning, and necessitates costly remediation cycles. Proactive identification and rectification of these common deficiencies before submission are essential to ensure a smooth, timely regulatory approval process.

What the FDA Now Requires and How Deficiencies Actually Happen

The Shift Section 524B Created for 510(k) Submissions

Before Section 524B took effect, cybersecurity documentation was guidance-recommended but not submission-critical. That changed. The FDA now treats missing or inadequate cybersecurity evidence the same way it treats missing clinical data: a reason to hold the review or issue a deficiency letter. The February 2026 Final Premarket Cybersecurity Guidance codified specific expectations around SBOMs, threat modeling, security testing, and postmarket vulnerability management. Submissions that ignore this shift face immediate scrutiny during review.

What Triggers a Refusal to Accept Versus an Interactive Review

The FDA's response depends on how incomplete the submission is. Missing core elements entirely - no SBOM or no postmarket vulnerability plan, for example - can trigger a Refusal to Accept during the threshold review phase. More commonly, submissions clear initial screening but generate deficiency letters during substantive review when documentation exists but is too generic, untraced to device-specific risks, or lacks verification evidence. The difference matters because deficiency letters allow response, while an RTA resets the clock entirely. Understanding which category your submission falls into shapes the urgency and type of remediation needed.

SBOM Gaps That Draw Immediate FDA Scrutiny

What an Incomplete SBOM Looks Like to a Reviewer

The most common SBOM failure isn't absence; it's incompleteness. Reviewers flag SBOMs that list top-level components but omit transitive dependencies, leave out version numbers, or fail to identify commercial off-the-shelf and open-source components separately. An SBOM that can't support vulnerability monitoring is functionally useless to the FDA, even if a file was technically included in the submission. Missing end-of-support status for components and no linkage to the vulnerability management plan are two specific gaps that repeatedly generate deficiency letter language.

Reviewers commonly cite that "the submitted SBOM is incomplete or not sufficiently detailed" or that "the SBOM lacks required information such as supplier name, component name, version, unique identifier, and dependency relationship." These aren't vague concerns. Reviewers check against a specific content standard aligned with NTIA minimum elements and the FDA's February 2026 guidance. For context on the kinds of objections reviewers raise, see analyses of common FDA objection patterns identified across deficiency letters.

How to Build an SBOM That Satisfies FDA Traceability Requirements

A submission-ready SBOM includes component name, version, supplier, dependency relationships covering both direct and transitive components, unique identifiers such as CPEs or package URLs, and known support status for each component. Format matters: the FDA expects machine-readable output, typically SPDX or CycloneDX, consistent with NTIA minimum element recommendations. More importantly, the SBOM must tie directly to the risk assessment and vulnerability monitoring process described elsewhere in the submission. Reviewers follow the audit trail from component inventory to residual risk, and any break in that linked evidence path generates a question.

Threat Model Documentation FDA Reviewers Flag as Insufficient

The Specific Elements Missing From Most Threat Models

Thin threat models follow a template without connecting to the actual device. The FDA flags threat models that list generic threat categories, skip architectural diagrams showing real data flows and interfaces, and fail to trace identified threats through to specific mitigations. Risk analyses that don't address patient safety impact, treat threat modeling as a one-time exercise rather than a design-phase process, or use a methodology without documenting the rationale for choosing it are consistent deficiency triggers. The threat model should read like a device-specific investigation, not a completed form.

What a Submission-Ready Threat Model Actually Contains

A compliant threat model documents the scope, methodology rationale, assumptions, security asset inventory, connection and data flow inventory, and expected threat sources, consistent with frameworks such as AAMI TIR57 and ANSI/AAMI SW96. Architectural diagrams that include the software update path belong in a separate, digestible section rather than buried in a single dense clause. The model provides a full analysis of primary threats with implemented mitigations and shows traceability from each identified threat to a cybersecurity risk and from that risk to a specific control. Cross-functional participation - engineering, quality, and clinical - also matters because it signals that patient safety impact was considered alongside technical exploitability.

Penetration Testing Reports That Don't Clear the Bar

Why Scope and Methodology Matter More Than the Findings

The FDA doesn't just want to see a penetration test report. It wants evidence the test was rigorous enough to be meaningful. Submissions that include pen test reports without documenting tester independence, scope boundaries, duration, and methods used draw deficiency questions regardless of what the findings show. A clean report from a test that only covered the web interface of a device with Bluetooth, RF, firmware, and cloud components doesn't give the FDA what it needs. Scope gaps are treated as evidence gaps, and reviewers will ask about every attack surface the threat model identified but the test didn't cover.

How to Structure Penetration Testing Evidence FDA Won't Question

See also: When to Hire a Device Security Consultant vs. Build In-House, Letter to File vs New 510(k) for Cybersecurity Changes, and Special vs Traditional 510(k) for Cybersecurity Changes.

A complete premarket pen test report covers all relevant attack surfaces: hardware interfaces, firmware, wireless protocols including BLE and RF, mobile applications, APIs, and connected cloud environments. It documents tester credentials and independence, testing duration, specific methodologies applied, all findings including informational observations, and remediation status for each finding. The report must tie back to the device threat model so reviewers can confirm the test addressed the attack vectors that threat modeling identified. Any untested attack surface appearing in the threat model is a direct path to a deficiency letter.

Weak SPDF Evidence and Security Documentation Gaps

What "We Follow Secure Development Practices" Doesn't Prove

Vague SPDF claims are among the most consistent sources of cybersecurity deficiencies in 510(k) submissions. Asserting that the device was developed using a secure product development framework - without documentation showing specific controls, review points, and verification activities at each lifecycle phase - gives the FDA nothing to evaluate. Submissions that describe security outcomes without showing the process that produced them leave reviewers with no way to assess whether the approach was systematic or incidental. Authentication design, encryption implementation, logging and monitoring, and hardening decisions all require documented evidence, not assertions.

Specific Controls FDA Expects to See Documented and Verified

SPDF documentation needs to show that security requirements were defined, implemented, and tested, consistent with expectations in the FDA's February 2026 premarket cybersecurity guidance and applicable AAMI standards. This includes role-based access control definitions with testing evidence, encryption applied to data in transit and at rest with justification, audit logging for security-relevant events with retention and alerting procedures, device hardening standards with verification, and a coordinated vulnerability disclosure process with defined timelines and ownership. Each control should connect back to a threat in the threat model and forward to a test result in the verification and validation evidence. That documentation thread is what reviewers follow, and submissions that break it at any point generate questions.

A Pre-Submission Checklist to Close Every Gap Before Filing

The Traceability Chain FDA Reviewers Follow

The FDA traces a path through the submission: from the SBOM through the threat model, from identified threats to implemented controls, and from controls to test evidence and the postmarket monitoring plan. Any break in that chain generates a question. Before filing, verify that every component in the SBOM appears in the vulnerability assessment and that every attack surface in the threat model was covered in penetration testing.

Use this checklist as a final review gate before submission - and see our FDA cybersecurity deficiency response checklist for the full breakdown:

• SBOM in SPDX or CycloneDX format with direct and transitive dependencies, version numbers, unique identifiers, and end-of-support status for each component
• Threat model with device-specific architectural diagrams, methodology rationale, cross-functional participation, and traced mitigations for every identified threat
• Penetration test report covering all attack surfaces identified in the threat model, with documented tester independence, scope, duration, methodology, and remediation status
• SPDF documentation with specific controls, lifecycle phase verification activities, and evidence tied to security requirements
• Postmarket vulnerability management plan with defined timelines, roles, escalation criteria, and coordinated disclosure procedures
• Traceability matrix connecting SBOM components to vulnerability assessment, threats to controls, and controls to test evidence

When to Bring in Outside Help Before You File

If your team has already received a cybersecurity deficiency letter - see our analysis of real FDA cybersecurity deficiency letter examples - or if the submission package hasn't been reviewed against the February 2026 Final Premarket Cybersecurity Guidance, the risk of a hold is high. Firms that specialize exclusively in FDA-aligned medical device cybersecurity understand the documentation patterns that produce cleared submissions versus those that generate letters. Generic IT security firms retrofit enterprise frameworks to MedTech contexts, and the result is documentation that misses the device-specific requirements reviewers prioritize. For straightforward answers to common premarket cybersecurity questions, reviewers often refer sponsors to the FDA's own cybersecurity FAQs.

The Bottom Line on Preventing 510(k) Cybersecurity Deficiencies

The most common cybersecurity deficiencies in 510(k) submissions share one trait: they're predictable. Incomplete SBOMs, threat models that don't connect to device-specific risks, penetration tests that miss whole attack surfaces, and SPDF evidence that describes outcomes rather than proving them - these are the gaps reviewers find most often, and they're all fixable before filing. The remediation path for each is well-established, the FDA's expectations are explicit, and the documentation thread reviewers follow is knowable in advance. For a deeper look at why submissions are rejected, see our analysis of 12 reasons the FDA rejects medical device cybersecurity submissions.

Submitting with gaps isn't a risk worth taking when the alternative is a cleared submission on the first review cycle. If you want an expert assessment of your submission package against the FDA's current cybersecurity requirements before you file, contact Blue Goat Cyber. We'll identify the gaps and give you a clear path to close them before you file.

FAQ

What are the most common cybersecurity deficiencies in 510(k) submissions?

Four patterns dominate: incomplete SBOMs (missing transitive dependencies, missing supplier-of-supplier components, no VEX), thin threat models (no STRIDE or PASTA mapping, no link to test cases), penetration test reports that are mostly scanner output, and weak SPDF evidence that does not show how security activities ran across the development lifecycle. Closing those four gaps prevents the majority of deficiency letters.

What makes an SBOM acceptable to FDA reviewers?

Machine-readable (SPDX or CycloneDX), complete down to transitive dependencies, paired with a VEX that explains exploitability for each known vulnerability, and accompanied by an operational plan showing how it will be regenerated and monitored after release. SBOMs delivered as PDF or Excel snapshots almost always get flagged.

How detailed does the threat model need to be?

Detailed enough that every external interface, trust boundary, and data flow is enumerated; every identified threat has a mitigation; and every mitigation maps to a test case in the security testing package. Threat models that stop at a diagram and a list of generic threats are the most common source of 'expand the threat model' deficiency letters.

Why do penetration test reports get rejected?

Three reasons: (1) scope too narrow - testing the web app but not the device interfaces, (2) methodology that is automated scanning rebranded as pen testing with no exploitation or chaining, (3) findings that do not connect back to the threat model. Reports written for compliance theater rarely survive review.

What SPDF evidence does the FDA actually expect to see?

Evidence that secure development activities ran throughout the lifecycle: requirements with security ACs, design reviews with security input, secure coding standards with enforcement evidence, code review records, testing records (SAST, SCA, DAST, fuzz, pen test), vulnerability handling procedures, and supplier cybersecurity controls. A retroactive SPDF binder assembled at submission time is usually detectable.

How long does it take to close cybersecurity deficiencies after a Hold letter?

Typically 30-90 days of focused work, but the clock penalty on the overall submission can be 3-6 months because each Hold letter restarts a review cycle. The cost of fixing deficiencies after a Hold is usually 3-5x the cost of producing clearance-ready evidence before filing.

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.

How Blue Goat approaches this

Our approach to 510(k) cybersecurity focuses on preventing deficiencies before they arise, aligning documentation with current FDA mandates. We assist medical device manufacturers in developing precise SBOMs, conducting detailed threat modeling, and performing targeted penetration tests with clear coverage justification. Our team, comprised of CISSP and OSCP certified experts, including ex-military red team personnel, develops cybersecurity evidence packages that meet the stringent requirements of the FDA for secure product development frameworks (SPDFs). We specialize in crafting documentation that proactively addresses common agency concerns. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. We aim to secure your device and accelerate its path to market. Learn more at: /services/fda-premarket-cybersecurity-services