FDA Cybersecurity Premarket Submission Deficiencies: 12 Common Rejection Reasons and How to Fix Them (2026)

Why Cybersecurity Is Now the Number One Hold on Premarket Clearance

Since Section 524B of the FD&C Act took effect on March 29, 2023, the FDA has had explicit statutory authority to refuse to accept any premarket submission for a cyber device that fails to meet cybersecurity requirements. An Additional Information (AI) letter citing cybersecurity deficiencies adds 8 to 12 weeks to a clearance timeline. In some cases, the delays are longer. The Refuse to Accept (RTA) authority means submissions can be rejected before they even reach a substantive reviewer.

The patterns are now well established. Analysis of actual FDA deficiency letters across the 510(k), De Novo, and PMA pathways reveals that the same twelve issues appear repeatedly. Blue Goat Cyber, which reports having supported over 250 premarket submissions with zero rejections, has published a detailed taxonomy of these recurring deficiencies. Medcrypt, analyzing actual FDA feedback in early 2026, independently confirmed overlapping trends. The Intertek regulatory team has noted that submissions rarely fail because security controls are absent -- they fail because cybersecurity is treated as documentation rather than as a safety system.

This guide walks through each of the twelve most common deficiencies, explains exactly what triggers them, and provides concrete fixes aligned to the current regulatory framework. Every recommendation is traceable to FDA's February 3, 2026 final guidance and the statutory requirements of Section 524B.

The Regulatory Framework You Must Understand

Before examining specific deficiencies, it is essential to understand the three regulatory layers that govern cybersecurity in premarket submissions in 2026.

Section 524B of the FD&C Act -- The Statutory Mandate

Section 524B was enacted through the Food and Drug Omnibus Reform Act (FDORA) on December 29, 2022, and took effect on March 29, 2023. It applies to "cyber devices" -- defined as devices that (1) include software validated, installed, or authorized by the sponsor, (2) have the ability to connect to the internet, and (3) contain technological characteristics vulnerable to cybersecurity threats.

The definition of "ability to connect" is deliberately broad. FDA is explicit: if a device has the technical capability to connect to the internet through any means at any point, it qualifies. This includes Wi-Fi, Bluetooth, USB ports, Ethernet, serial ports, and NFC. Even if the manufacturer never intended internet connectivity, the existence of the physical capability brings the device into scope.

For cyber devices, Section 524B(b) requires manufacturers to:

• Maintain a plan for managing vulnerabilities and exploits throughout the product lifecycle [Section 524B(b)(1)]
• Design, develop, and maintain processes and procedures that provide reasonable assurance the device and related systems are cybersecure [Section 524B(b)(2)]
• Provide a Software Bill of Materials (SBOM) for commercial, open-source, and off-the-shelf software components [Section 524B(b)(3)]

Noncompliance with Section 524B(b) is a prohibited act under Section 301(q) of the FD&C Act. This is not a guidance recommendation; it is law.

FDA February 3, 2026 Final Guidance

On February 3, 2026 -- one day after the QMSR took effect -- the FDA issued the updated final guidance: "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions." This version supersedes the June 27, 2025 final guidance.

The primary substantive change was replacing references to the Quality System Regulation (QSR, 21 CFR 820) with the new Quality Management System Regulation (QMSR, amended 21 CFR Part 820). The core cybersecurity expectations -- SBOM, threat modeling, security risk assessment, penetration testing, architecture views, labeling, and post-market monitoring -- remain unchanged. The guidance now explicitly expects cybersecurity processes to be generated from controlled quality management system processes under the QMSR framework.

QMSR and ISO 13485:2016 Alignment

The Quality Management System Regulation took effect on February 2, 2026, and incorporates ISO 13485:2016 by reference. For cybersecurity, this means:

• Threat models must be traceable to ISO 13485 Clause 7.3 design controls
• Security validation must be anchored in Clause 7.3.7
• Vulnerability handling must sit within Clause 8.5 improvement processes
• The Secure Product Development Framework (SPDF) must be structurally within the quality system

If your cybersecurity framework cannot be traced to these QMS processes, it is structurally outside the quality system -- a deficiency FDA can identify during inspection.

RTA Enforcement Authority

Since October 2023, the FDA has exercised Refuse to Accept authority under Section 524B. Submissions missing required cybersecurity documentation are rejected at the intake stage, before substantive review begins. The first person reviewing a submission performs a "technical review" to verify that all required documents are present and appear correct. Failing this initial check means rejection before the actual reviewer ever sees the file.

The 12 Most Common Deficiencies -- And How to Fix Each One

The following deficiencies are ordered by frequency and severity, based on published analysis from Blue Goat Cyber, Medcrypt, and other firms that have tracked patterns across hundreds of FDA submission cycles.

Deficiency 1: Incomplete or Improperly Formatted SBOM

What reviewers see: The submission includes a high-level component list but is missing transitive dependencies, version pins, supplier identifiers, or uses a non-standard format. Excel spreadsheets, CSV files, and flat text files are submitted instead of machine-readable formats.

Why it is flagged: Section 524B(b)(3) makes the SBOM a statutory requirement for cyber devices. FDA requires a machine-readable SBOM that supports vulnerability monitoring across the entire device lifecycle. The guidance specifies that SBOMs should follow NTIA minimum elements and be in a recognized standard format. Reviewers will issue a deficiency if they cannot trace third-party components or evaluate known vulnerabilities.

FDA reviewers now cross-reference submitted SBOMs against public vulnerability databases, including the National Vulnerability Database (NVD) and GitHub Advisories. If a reviewer finds a known CVE in your SBOM that you have not addressed in your risk assessment, it raises concerns about the maturity of your entire Secure Product Development Framework.

Required SBOM elements:

How to fix it:

• Generate the SBOM in CycloneDX or SPDX format (typically JSON) directly from your build pipeline. Do not manually create SBOMs.
• Include all transitive dependencies, exact versions, suppliers, and license data.
• Do not filter or sanitize the SBOM before submission. Total transparency is expected.
• Use a Vulnerability Exploitability eXchange (VEX) document to explain which CVEs in your SBOM do not impact your device. This prevents reviewers from chasing vulnerabilities that are not exploitable in your specific configuration and accelerates the review.
• Document the SBOM maintenance process: how it is regenerated on each release and how vulnerabilities are tracked against it post-market.

Deficiency 2: Cybersecurity Risk Assessments Using Probability or Likelihood Scoring

What reviewers see: The security risk assessment uses probability of occurrence or likelihood-based scoring matrices, similar to what would appear in an ISO 14971 safety risk analysis.

Why it is flagged: FDA explicitly prohibits using probability-based scoring for security risks. The guidance states:

"Cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling (also known as a 'probabilistic manner')."

This non-probabilistic approach is fundamentally different from safety risk management under ISO 14971. Security risk assessment must focus on exploitability -- the ability to exploit vulnerabilities present within a device and system -- not on the statistical probability that an attack will occur.

Security risk management must be separate from safety risk management (ISO 14971), though the two must be connected. Cybersecurity risks must be evaluated through the lens of patient safety, but the scoring methodology must be different.

How to fix it:

• Remove any probability of occurrence, likelihood, or probability of harm columns from your security risk scoring rubrics.
• Adopt an exploitability-based scoring methodology. Factors should include: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope, and impact.
• Reference AAMI SW96 (Standard for Security Risk Management in Medical Devices) for the security-specific risk framework.
• Map each cybersecurity risk to a corresponding hazard and harm in the ISO 14971 file to demonstrate the safety connection, but keep the scoring methodologies distinct.
• Document how exploitability is translated into a risk level and how residual risk is evaluated post-controls.

Deficiency 3: Threat Models Not Traced to Patient Safety

What reviewers see: The threat model is generic, lacks data flow diagrams with trust boundaries, or does not connect identified threats to security controls and patient harm scenarios. A STRIDE table without context or traceability rarely passes review.

Why it is flagged: FDA expects threat modeling that explicitly links assets, threats, vulnerabilities, and controls to patient safety risk. Generic "data sent/received" models are insufficient. The guidance requires security use-case views for clinical states including programming, alarming, standby, diagnostics, therapy delivery, and maintenance.

Multi-patient harm scenarios must be included in the security architecture views. A threat model that addresses only individual patient scenarios does not meet expectations for networked devices that could affect multiple patients simultaneously.

How to fix it:

• Build data flow diagrams that show every interface, trust boundary, and external entity.
• Use a recognized methodology (STRIDE, PASTA, or Attack Tree) and tie each threat to a specific control or documented risk acceptance.
• Create security use-case views for each clinical operating state of the device.
• Include multi-patient harm scenarios where the device operates in a networked clinical environment.
• Cross-reference every threat with the Security Risk Assessment and the ISO 14971 risk file.
• Align the threat model to AAMI TIR57 (Principles for Medical Device Security Risk Management).

Deficiency 4: Weak Security Risk Control Mitigations or Unsupported Assumptions

What reviewers see: The submission relies on weak justifications for security controls instead of implementing cryptographic or architectural solutions. Common examples include claiming a device is "air-gapped" when USB ports exist, relying on "security through obscurity," or using deprecated cryptographic algorithms without a migration plan.

Why it is flagged: FDA expects strong, technically justified security controls. Claiming a device is isolated from network threats while it has physical connectivity interfaces (USB, serial, Bluetooth) is not a defensible position. Security controls must use strong cryptographic primitives and be justified against modern standards.

How to fix it:

• Replace assumption-based justifications with implemented and verified controls.
• Use strong, current cryptographic algorithms and protocols. Document algorithm selection, key sizes, and protocols against NIST/FIPS guidance.
• Describe key generation, storage, rotation, and destruction procedures.
• Plan for crypto-agility: document how the device will transition away from deprecated algorithms during its supported lifetime.
• If a control cannot be implemented for a legitimate technical reason, provide a documented compensating control and risk acceptance rationale, not an assumption.

Deficiency 5: SBOM Not Connected to Threat Model or Risk Assessment

What reviewers see: The SBOM is provided as a standalone artifact with no linkage to the threat model, security risk assessment, or vulnerability management process.

Why it is flagged: Third-party components, end-of-life libraries, supplier constraints, and known vulnerabilities must be linked to threat scenarios. An SBOM that exists in isolation does not demonstrate that the manufacturer is using it operationally to manage risk. The 2026 guidance positions the SBOM clearly within supplier oversight and configuration management under the QMSR.

How to fix it:

Each SBOM component should be tied to:

• 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 -- not just as a submission artifact.

Deficiency 6: Inadequate Penetration Testing

What reviewers see: The penetration test report covers only the web interface, uses automated scanning exclusively, was performed by a generalist firm without medical-device context, or contains unresolved findings without documented disposition.

Why it is flagged: The most significant trend in recent FDA deficiencies is insufficient penetration testing. FDA expects testing that exercises every interface -- wireless, USB, BLE, cellular, cloud APIs, and service ports. Generic external penetration tests do not satisfy this expectation. Submissions are being flagged for having unresolved findings, even those labeled as "Low" or "Medium" risk, without documented mitigation, acceptance criteria, or by-design justification.

FDA is no longer satisfied with the mere presence of a penetration test report. Reviewers scrutinize the findings, assess the disposition and resolution of each finding, and expect evidence that the testing was meaningful.

How to fix it:

• Perform penetration testing on the final, production-equivalent version of the device.
• Scope testing across all device interfaces and the supporting cloud or back-end ecosystem.
• Combine manual testing with automated tools. Pure automated scans are insufficient.
• Engage testers with documented medical-device experience who receive your threat model, SBOM, and architecture views before testing begins.
• Every finding must be treated as a newly identified risk managed through existing risk assessment processes.
• For high-risk findings that are mitigated, provide evidence of retesting to verify the fix.
• If a vulnerability is not fixed, document the explanation and justification for why residual risk is acceptable.

Deficiency 7: Missing Appendix 1 Controls

What reviewers see: The submission does not address one or more of the eight core security control categories outlined in Appendix 1 of the Premarket Guidance, or addresses them without robust technical justification.

Why it is flagged: In 2026, the FDA is treating Appendix 1 as a de facto mandatory checklist. Missing any core control without a documented, technically sound justification triggers a deficiency.

The eight required control categories:

How to fix it:

• Audit your Design History File (DHF) against all eight categories. Ensure each is explicitly addressed.
• Document how each control is implemented at the architectural level. Use precise language -- vague statements of compliance are insufficient.
• For any control not implemented, provide a robust technical justification with compensating controls and risk acceptance rationale.
• Ensure Appendix 1 controls are traceable to the threat model and security risk assessment.

Deficiency 8: No Coordinated Vulnerability Disclosure (CVD) Plan

What reviewers see: The submission lacks a published process for security researchers to report vulnerabilities, or there is no internal SLA for triage and remediation.

Why it is flagged: FDA explicitly calls out coordinated vulnerability disclosure as a required element of post-market cybersecurity. Section 524B(b)(1) requires a plan for managing vulnerabilities and exploits. The absence of a documented CVD program is one of the most common post-market deficiencies.

How to fix it:

• Publish a CVD policy with a designated security contact, defined scope, and response SLAs.
• Define the internal triage workflow tied to risk severity and patch release cadence.
• Reference ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling Processes) in your submission documentation.
• Include the CVD policy as a submission artifact, not just a website link.

Deficiency 9: Inadequate Cybersecurity Labeling

What reviewers see: User-facing documentation is missing required cybersecurity transparency elements: SBOM access instructions, end-of-support dates, network requirements, hardening guidance, or supported configuration details.

Why it is flagged: Cybersecurity labeling is now an explicit submission element per FDA's February 3, 2026 guidance (Section VI.A). Reviewers check that users -- typically hospital IT administrators, clinical engineers, and clinicians -- have the information needed to securely configure, operate, and maintain the device. FDA has warned that inadequate cybersecurity information in device labeling may cause it to be misbranded under Section 502(f) of the FD&C Act. Misbranded devices can be pulled from the market.

How to fix it:

• Include a dedicated cybersecurity section in the Instructions for Use (IFU) and labeling.
• Disclose all connectivity interfaces, including those disabled by default (Bluetooth, Wi-Fi, serial, USB).
• Document supported configurations, open ports, protocols, and required network infrastructure.
• Provide instructions for obtaining the current SBOM and reporting vulnerabilities.
• Clearly state the expected support lifetime for security patches. This enables healthcare facilities to plan their own risk management.
• If the device is user-configurable, enumerate options and demonstrate consequences for lower-security configurations.

Deficiency 10: Update Mechanism Not Validated End-to-End

What reviewers see: The device can be updated, but there is no validated process demonstrating authenticity verification, integrity checks, rollback capability, and failure handling for updates in the field.

Why it is flagged: Updateability is both a required architecture view and a core post-market control. An unvalidated update path is one of the fastest routes to a deficiency letter. FDA expects manufacturers to document the complete change-controlled workflow for security patches.

How to fix it:

• Validate the update mechanism end-to-end: digital signature verification, integrity checks, atomic install, and rollback capability.
• Document the update workflow for users and clinical environments, including OTA, service tool, or CDN delivery mechanisms.
• Describe how updates are tested, signed, distributed, and validated in the field.
• Test the update path as part of system verification, including failure cases (power loss during update, corrupted package, version mismatch).
• Document rollback procedures for failed updates.

Deficiency 11: Overall Lack of Documentation Clarity and Organization

What reviewers see: The cybersecurity documentation is disorganized, inconsistent across artifacts, or lacks the clarity needed for efficient review. Cross-references between documents are broken or missing.

Why it is flagged: The first person reviewing your submission performs a technical review -- they are not the actual substantive reviewer. Their job is to verify that all required documents are present and appear correct. Failing this initial review means rejection before the substantive reviewer ever sees the file. Disorganized, inconsistent, or unclear documentation triggers rejection at this stage. When the threat model references controls that the architecture views do not depict, or the SBOM components do not appear in the risk assessment, reviewers lose confidence in the overall submission.

How to fix it:

• Create a traceability matrix tying every cybersecurity artifact to design controls and the quality management system.
• Ensure consistency across all documents: the threat model, SBOM, security risk assessment, architecture views, penetration test report, and labeling should tell a single coherent story.
• Use the FDA's eSTAR template structure where applicable.
• Ensure cross-references between documents are accurate and bidirectional.
• Have an independent reviewer (not the author) perform a completeness check before submission.

Deficiency 12: SPDF Not Integrated into the Quality System

What reviewers see: The Secure Product Development Framework exists as a standalone document set prepared for submission purposes, with no evidence of integration into the manufacturer's quality management system.

Why it is flagged: The February 2026 guidance reinforces that the SPDF must be structurally within the quality system. FDA checks during inspection whether cybersecurity is embedded in QMS processes. A static SBOM prepared only for submission, threat models created after design freeze, and security testing performed as an afterthought all signal that the SPDF is a compliance artifact rather than an operational process.

The 2026 guidance aligns with ISO 13485, meaning cybersecurity activities should be traceable to design controls (Clause 7.3), design verification (Clause 7.3.7), and improvement processes (Clause 8.5). If your threat model cannot be traced to design input requirements, or if your security validation is not anchored in the design verification plan, the SPDF is structurally outside the quality system.

How to fix it:

• Map every SPDF activity (security requirements, threat modeling, secure coding, security testing, vulnerability management) to a design control output within your QMS.
• Provide objective evidence at each phase: review records, test results, training logs.
• Include a written SPDF policy that QMS auditors can trace through design controls, verification, and CAPA.
• Maintain the SBOM as a living document within configuration management, not as a one-time submission artifact.
• Ensure cybersecurity processes survive organizational changes by embedding them in controlled procedures.

Pre-Submission Readiness Checklist

Before submitting, use this checklist as a go/no-go gate. If any item is unchecked, you have a known gap that FDA is likely to flag.

Timeline reality check: For a moderate-complexity Class II connected device, a complete cybersecurity package typically requires 10 to 14 weeks of focused work when done correctly the first time. Rework after an AI letter adds an additional 8 to 12 weeks.

The Pre-Submission Strategy

Consider using the FDA's Pre-Submission (Pre-Sub) program to get feedback on your cybersecurity documentation before the formal submission. A Pre-Sub allows you to present your threat model, SBOM approach, and security architecture to FDA reviewers and receive written feedback on whether your approach is likely to be sufficient. This is especially valuable for first-time submissions, novel device categories, or devices with complex connectivity architectures. The feedback is non-binding but highly informative and can prevent deficiencies before they occur.

Post-Market Obligations: The Submission Is Just the Beginning

Clearing the premarket hurdle is necessary but not sufficient. Section 524B imposes ongoing obligations throughout the lifecycle of a cyber device. FDA evaluates premarket and post-market cybersecurity together. Without a credible post-market plan, premarket controls do not stand on their own.

Key post-market activities that FDA expects to see operationalized:

The SBOM is a living document, not a submission artifact. A static SBOM prepared for a 510(k) that goes stale six months later does not satisfy FDA's lifecycle model. The February 2026 guidance positions the SBOM clearly within supplier oversight and configuration management, meaning it must be maintained operationally within the quality system.

Key Standards Reference Table

Final Recommendations

The manufacturers who succeed in clearing FDA cybersecurity review in 2026 share common traits:

They treat cybersecurity as a safety system, not a documentation exercise. Threat models are traced to patient harm. Risk assessments use the right methodology. Penetration testing demonstrates actual security posture, not checkbox compliance.

They embed cybersecurity into their quality system from the start. The SPDF is not a post-hoc documentation package. Security requirements are design inputs. Threat modeling occurs during design, not after. Security testing is part of design verification.

They maintain the SBOM as operational intelligence. The SBOM is a living document used for continuous vulnerability monitoring, supplier management, and configuration control. It is not generated once for submission and forgotten.

They use the pre-submission process strategically. Rather than guessing what FDA expects, they present their approach and get written feedback before the formal submission. This front-loads the risk and reduces the probability of an AI letter.

They close the loop on every finding. Every penetration test finding has a documented disposition. Every SBOM vulnerability is addressed or explained in a VEX. Every threat is traced to a control or an accepted risk. Reviewers see a coherent, self-consistent package where each artifact supports and cross-references the others.

The regulatory framework is now stable. After multiple iterations -- 2014, 2023, 2025, and 2026 -- the core expectations are well-established. The February 2026 update was primarily a structural alignment with QMSR, not a substantive expansion of requirements. Manufacturers who build security in from day one, operationalize it within their quality system, and document it with the depth and consistency FDA expects will find the premarket process predictable and manageable. Those who continue to treat cybersecurity as a last-minute documentation exercise will face the same twelve deficiencies, the same AI letters, and the same avoidable delays.