12 Reasons the FDA Rejects Cybersecurity Submissions

A practical, ungated guide to the most common cybersecurity deficiencies in 510(k), De Novo, and PMA submissions - what triggers each one, and exactly how to fix it before you submit.

Why cybersecurity evidence matters in premarket review

Since Section 524B of the FD&C Act took effect, the FDA has the explicit authority to refuse to accept any premarket submission for a cyber device that doesn’t meet cybersecurity requirements. With the FDA’s Feb 3, 2026 final guidance now in force, and the Quality Management System Regulation (QMSR, 21 CFR Part 820) incorporating ISO 13485:2016 effective February 2, 2026, submissions that would have sailed through three years ago are now routinely held for cyber deficiencies - and an AI letter on cybersecurity can add months to your clearance timeline.

The patterns are predictable. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. In our FDA premarket cybersecurity work, we see the same twelve issues come up again and again. This guide walks through each one: what reviewers see, why it’s flagged, and exactly how to fix it before you submit.

How to use this guide

• Read each reason as a self-assessment: do you have the artifact, and is it at the depth the FDA expects?
• Use the checklist at the end to score your submission readiness.
• Where you find a gap, the fix list is concrete enough to start work on Monday.

What the FDA flags - and how to fix it before you submit

These are practical deficiency patterns, not a published ranking of the FDA’s requests. Remediation and review time depend on the specific evidence gaps and submission pathway.

1. Incomplete or shallow Software Bill of Materials (SBOM)

Category: SBOM / Third-Party Components

👁 What reviewers see

Submission includes a high-level component list but is missing transitive dependencies, version pins, supplier identifiers, or a recognized format ( SPDX/ CycloneDX).

Why it’s flagged

Section 524B requires an SBOM for covered cyber device submissions; the FDA recommends machine-readable formats. A SBOM that supports vulnerability monitoring across the entire device lifecycle - not a static spreadsheet snapshot. Reviewers will issue a deficiency if they can’t trace third-party components or evaluate known vulnerabilities.

How to fix it

• Generate the SBOM in CycloneDX or SPDX format directly from your build pipeline.
• Include all transitive dependencies, exact versions, suppliers, and license data.
• Document the SBOM maintenance process: how it’s regenerated on each release and how vulnerabilities are tracked against it post-market.

2. Threat model not aligned to AAMI TIR57 (now supplemented by ANSI/AAMI SW96:2023) or FDA expectations

Category: Threat Modeling

👁 What reviewers see

Threat model is generic, lacks data flow diagrams with trust boundaries, or doesn't connect identified threats to security controls and risk acceptance.

Why it's flagged

The FDA expects threat modeling that explicitly links assets, threats, vulnerabilities, and controls to patient safety risk. A STRIDE table without context or traceability rarely passes review.

How to fix it

The full STRIDE-aligned fix pattern lives in our 12 Critical Threat Modeling Gaps guide - work through the 12 gaps and the Gap × STRIDE Coverage Matrix before submission, then cross-reference each threat with your Security Risk Assessment and ISO 14971 risk file.

3. Security Risk Assessment not integrated with ISO 14971

Category: Risk Management

👁 What reviewers see

Cybersecurity risks are tracked in a separate document with no link to the device’s safety risk management file.

Why it’s flagged

the FDA’s premarket guidance is explicit: cybersecurity risk must be evaluated through the lens of patient safety. A standalone security risk register doesn’t demonstrate that link.

How to fix it

• Map each cybersecurity risk to a corresponding hazard and harm in the ISO 14971 file.
• Document how exploitability is scored and combined with the ISO 14971 severity of harm, in place of probability.
• Show the residual risk evaluation post-controls in both files consistently.

4. Secure Product Development Framework (SPDF) gaps

Category: SPDF / QMS

👁 What reviewers see

Design controls don’t show evidence of security activities at each phase: requirements, design, implementation, verification, release.

Why it’s flagged

Section 524B and the FDA’s Feb 3, 2026 final cybersecurity guidance expect a documented SPDF that integrates with the QMSR (21 CFR Part 820 / ISO 13485:2016). Missing artifacts at any phase signal an immature process.

How to fix it

• Map every SPDF activity (requirements, threat modeling, secure coding, testing, vulnerability management) to a design control output.
• Provide objective evidence: review records, test results, training logs.
• Include a written SPDF policy that QMS auditors can trace.

5. Penetration testing scoped too narrowly or with the wrong methodology

Category: Penetration Testing

👁 What reviewers see

Pen test report covers only the web interface, uses automated scanning only, or was performed by a generalist firm without medical-device context.

Why it’s flagged

The FDA expects testing that exercises every interface (wireless, USB, BLE, cellular, cloud, service ports) using a methodology appropriate to a medical device’s threat model.

How to fix it

• Scope pen testing across all device interfaces and the supporting cloud/back-end ecosystem.
• Combine manual testing with automated tools; pure scans are insufficient.
• Engage testers with documented medical-device experience and provide them the threat model.

6. Missing coordinated vulnerability disclosure plan

Category: Post-Market / CVD

👁 What reviewers see

No published process for security researchers to report vulnerabilities, or no internal SLA for triage and remediation.

Why it’s flagged

FDA explicitly calls out coordinated vulnerability disclosure (CVD) as a required element of post-market cybersecurity. The absence of a documented program is a common deficiency.

How to fix it

• Publish a CVD policy with a security contact, scope, and response SLAs.
• Define internal triage workflow tied to risk and patch release cadence.
• Reference ISO/IEC 29147 and 30111 in your submission documentation.

7. Inadequate post-market cybersecurity monitoring plan

Category: Post-Market Surveillance

👁 What reviewers see

Submission covers premarket controls but is silent on how vulnerabilities will be monitored, evaluated, and patched after clearance.

Why it’s flagged

The FDA evaluates premarket and post-market cybersecurity together. Without a credible monitoring and patch plan, the premarket controls don’t stand on their own.

How to fix it

• Document continuous monitoring sources ( NVD, vendor advisories, CISA, ISAC feeds).
• Define risk-based remediation timelines and customer communication plans.
• Show how the SBOM is used operationally to detect new vulnerabilities.

8. Cybersecurity labeling deficiencies

Category: Labeling / Documentation

👁 What reviewers see

User-facing documentation is missing required cybersecurity transparency: SBOM access, end-of-support dates, network requirements, hardening guidance.

Why it’s flagged

Cybersecurity labeling is now an explicit submission element per the FDA’s Feb 3, 2026 guidance. Reviewers check that users and IT departments have what they need to operate the device safely.

How to fix it

• Include a dedicated cybersecurity section in IFU/labeling.
• Document supported configurations, ports, protocols, and end-of-support dates.
• Provide instructions for obtaining the SBOM and reporting vulnerabilities.

Want a second set of eyes before you submit?

We scope a fixed-fee gap analysis around your device and existing evidence.

Talk to an expert

9. No documented SBOM lifecycle or maintenance plan

Category: SBOM / Post-Market

👁 What reviewers see

An SBOM is provided, but there’s no explanation of how it will be updated, validated, and shared across the product’s supported lifetime.

Why it’s flagged

An SBOM that’s accurate at submission but stale six months later doesn’t satisfy the FDA’s intent. The lifecycle plan is just as important as the artifact itself.

How to fix it

• Describe how the SBOM is regenerated on every build and every release.
• Document validation steps and the team accountable for accuracy.
• Define how customers can request the current SBOM post-market.

10. Architecture views missing required detail

Category: Security Architecture

👁 What reviewers see

Submission lacks global system view, multi-patient harm view, updateability view, or doesn’t show data flows and trust boundaries clearly.

Why it’s flagged

the FDA’s Feb 3, 2026 final cybersecurity guidance (Appendix 2) is specific about the security architecture views required. Submissions that include only a single block diagram are routinely flagged.

How to fix it

The architecture-view requirements (global system, multi-patient harm, updateability) and how each one ties back to a STRIDE threat are covered in detail in the 12 Critical Threat Modeling Gaps guide - gaps 1, 4, and 5 specifically. Make sure every diagram annotates trust boundaries, data classifications, and authentication points, and stays consistent with your threat model.

11. Cryptographic controls not justified or documented

Category: Cryptography

👁 What reviewers see

Algorithms, key sizes, and key management are mentioned but not justified against modern standards; deprecated algorithms still in use.

Why it’s flagged

Reviewers expect a written cryptographic rationale: why each algorithm was chosen, where keys live, how they rotate, and how the design will age over the device’s lifetime.

How to fix it

• Document algorithms, key sizes, and protocols against NIST/FIPS guidance.
• Describe key generation, storage, rotation, and destruction.
• Plan for crypto-agility: how the device will move off deprecated algorithms in the field.

12. Update and patch mechanism not validated end-to-end

Category: Update / Patch Management

👁 What reviewers see

The device can be updated, but there’s no validated process showing authenticity, integrity, rollback, and failure handling for updates in the field.

Why it’s flagged

Updateability is a required architecture view and a core post-market control. An unvalidated update path is one of the fastest ways to a deficiency letter.

How to fix it

• Validate the update mechanism: signature verification, integrity checks, atomic install, rollback.
• Document the update workflow for users and clinical environments.
• Test the update path as part of system verification, including failure cases.

Pre-Submission Readiness Checklist

If you can’t check all twelve, you have known gaps that the FDA is likely to flag. Use this as a go/no-go before you hit submit.

1. CycloneDX or SPDX SBOM with transitive dependencies and lifecycle plan

2. Threat model with data flow diagrams, trust boundaries, and STRIDE/PASTA analysis

3. Security Risk Assessment integrated with ISO 14971 risk file

4. Documented SPDF with evidence at each design control phase

5. Penetration test report covering all interfaces, performed with medical-device context

6. Coordinated Vulnerability Disclosure (CVD) policy and intake process

7. Post-market cybersecurity monitoring and patch plan

8. Cybersecurity labeling: SBOM access, supported configs, end-of-support, hardening

9. All required architecture views (global, multi-patient harm, updateability)

10. Cryptographic rationale with key management and crypto-agility

11. Validated update mechanism with signature, integrity, and rollback testing

12. Traceability matrix tying every cyber artifact to design controls and the QMS

Timeline Reality Check

Plan the work from your evidence gaps rather than a generic duration. Scope, device access, engineering availability, testing findings, remediation, and review cycles determine the schedule.

Agree milestones after reviewing those inputs. An AI request can extend a submission schedule, but there is no universal delay or guaranteed completion time.

How Blue Goat Cyber approaches these gaps

The twelve gaps above are the same gaps we clean up when a team asks us to run a pre-submission pressure test. Our process is deliberately narrow: we do not audit your QMS, we do not rewrite your regulatory strategy, we do not sell training. We take your current cybersecurity package, map it against the twelve failure patterns above and the eight pillars in the SPDF Playbook, and hand back a prioritized fix list on an agreed schedule.

For teams that want us to close the gaps end-to-end, we author the threat model, SBOM package, and security risk assessment, and we defend the package through submission. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Track record: 275+ FDA submissions supported, zero cybersecurity rejections.

Frequently asked questions

Which of the twelve reasons is the FDA citing most often in 2026?

The FDA does not publish a ranking establishing which cybersecurity deficiency is most common. Threat model traceability, component inventories, security testing, and postmarket plans are important evidence areas to assess against the February 3, 2026 guidance.

What is the RTA hold rate for cybersecurity now?

The FDA does not publish an isolated cybersecurity refusal rate. eSTAR submissions undergo technical screening and then substantive review, not the traditional RTA checklist. Documentation gaps may prompt screening deficiencies or AI requests, depending on the issue.

How long does it take to fix a cybersecurity deficiency after an AI letter?

Timing depends on whether existing evidence can be reused, whether testing or redesign is needed, and how quickly the manufacturer can approve changes. Scope the response from the actual letter and applicable pathway deadlines; no generic duration applies to every deficiency.

Can we appeal a cybersecurity deficiency instead of responding?

Discuss the specific concern with the review team and your regulatory lead. Applicable clarification, supervisory review, or appeal procedures depend on the pathway and decision. Whether to seek clarification, address a deficiency, or pursue a formal appeal depends on the facts; guidance recommendations are nonbinding, and no appeal outcome is guaranteed.

Does hiring a Big Four consultant reduce the odds of rejection?

Not measurably. FDA reviewers evaluate the artifacts, not the firm that authored them. The teams that clear cleanly are the ones whose cybersecurity leads have shipped multiple 510(k)s and know which sentence in the guidance the reviewer will cite. A generic security consulting firm without medical device submission history will typically produce work that reads like enterprise IT security, which reviewers flag.

What is the single highest-value fix if we only have two weeks before submission?

Rebuild the threat model so every threat traces to a specific control, and every control traces to a specific test artifact. That one thread (threat, control, evidence) is what most reviewers spot-check first. If that thread is defensible, downstream deficiencies drop sharply. If it is broken, the reviewer will read the rest of the package skeptically no matter how thorough it is.

When to bring in a specialist partner

You don’t need outside help for every submission. You probably do if any of these are true:

• This is your team’s first 510(k), De Novo, or PMA with cybersecurity in scope.

• You’ve received an AI letter or technical-screening deficiency citing cybersecurity.

• Your engineering team owns security alongside firmware and has limited bandwidth.

• Your launch date is fixed and a cyber deficiency would slip revenue.

• You need a defensible threat model and pen test from practitioners with relevant medical-device cybersecurity experience.

275+ FDA submissions supported, zero cybersecurity rejections

Want a senior expert to pressure-test your cyber package?

Book a free 30-minute strategy session. No sales rep, no obligation. We’ll review where you are, flag the gaps the FDA is most likely to hit, and give you a fixed-fee quote within 24-hours.

Explore our FDA premarket cybersecurity services, SBOM & lifecycle monitoring, threat modeling, penetration testing, and deficiency response programs.

Where to go next

• FDA Cybersecurity Technical Screening Checklist - screen your package before the reviewer does.
• FDA Deficiency Letter Triage - classify each deficiency and plan the response order.