Navigating the 2026 FDA Cybersecurity Landscape: Lessons from the "Top Deficiencies"
For medical device manufacturers, 2025 was a watershed year. The FDA’s transition from guidance-driven "recommendations" to enforceable statutory mandate under Section 524B of the Food, Drug and Cosmetics (FD&C) Act has fundamentally changed the premarket submission hurdle.
As we move into 2026, the "honeymoon phase" of the FDA cybersecurity guidance is over. Recent data reveals a clear pattern in why submissions are hitting regulatory roadblocks. If you are a Product Security Officer or a Regulatory Affairs Lead, your focus shouldn't just be on completing the documentation, but on the sufficiency of the evidence.
Reviewing and analyzing actual FDA deficiencies, here the top trends we are seeing, and how to stay ahead of them.
1. Penetration Testing: Moving Beyond "Check-the-Box"
The most significant trend in recent deficiencies is insufficient penetration testing. The FDA is no longer satisfied with the mere presence of a report. Instead, we see increasing scrutiny of the findings in a report, including assessing disposition and resolution of findings.
The Deficiency: Submissions are being flagged for having "unresolved findings"—even those labeled as "Low" or "Medium" risk—without a documented mitigation, acceptance criteria, or "by-design" justification.
The Fix: * Sufficiency is Key: Your penetration test must be performed on the final, production-equivalent version of the device. It should cover all system elements, not just the regulated ones.
- Mitigation: Every finding in your Pen Test report should be considered as a newly identified risk that should be managed through existing risk assessment processes. If a vulnerability isn't fixed, you must provide an explanation and justification of why the residual risk is acceptable.
- Retesting: If you mitigated a High-risk finding, the FDA expects to see evidence of a retest to verify the fix worked. (Share your original and re-test reports with FDA to demonstrate this lifecycle coverage.)
2. The SBOM Evolution: The "Disclosure Challenge"
We’ve moved past the "What is an SBOM?" phase into the "Is your SBOM actually useful?" phase.
The Deficiency: Incomplete Software Bills of Materials that miss baseline elements like End of Support (EOS) dates. More critically, the FDA is now cross-referencing SBOMs against public vulnerability databases (NVD/GitHub Advisories). If a reviewer finds a known CVE (Common Vulnerabilities and Exposures) applicable to a component in your SBOM that you haven't disclosed or addressed in your risk assessment, it raises concerns.
The Fix:
- Machine-Readability: Your SBOM must be in a standard format (like CycloneDX or SPDX).
- SBOM that covers the required elements from the CISA Framing Document plus level of support and EOS target dates.
- Total Transparency: Do not "filter" your SBOM before submission. If the FDA identifies a vulnerability in your supply chain that you missed, it calls your entire Secure Product Development Framework (SPDF) into question.
- VEX is Your Friend: Use a Vulnerability Exploitability eXchange (VEX) document to tell the FDA which CVEs in your SBOM don't actually impact your device. This prevents reviewers from chasing ghosts and speeds up your approval.
3. Premarket Guidance Appendix 1: Your New North Star
Many manufacturers are still treating Appendix 1 of the Premarket Guidance as a suggestion. In 2026, the FDA is treating it as a mandatory checklist.
The Deficiency: Missing one or more core controls—such as Event Detection and Logging, or Cryptographic Implementation—without a robust technical justification.
The Fix:
- Audit Against the 8 Categories: Ensure your design history file (DHF) explicitly addresses: Authentication, Authorization, Cryptography, Code/Data Integrity, Confidentiality, Event Detection/Logging, Resiliency, and Updatability.
- Refined Communication: Use precise language in your submission to explain how these controls are implemented at the architectural level.
4. Cybersecurity Labeling (Section VI.A)
Security is now a core component of the "Instructions for Use" (IFU).
The Deficiency: Labeling that fails to provide the end-user (usually a hospital IT admin, clinical engineer, or a clinician) with the information needed to securely configure and operate the device.
The Fix:
- Transparency: Disclose all connectivity interfaces (Bluetooth, Wi-Fi, etc.), even those disabled by default.
- Configurability: If your device is user-configurable, clearly enumerate options and demonstrate consequences for lower security options that can be selected. If not user-configurable, make your user aware of the secure-by-design approach you took to give them confidence in their usage.
- The "Support Life" Statement: Clearly state the expected support lifetime for security patches. If a hospital knows you’ll stop patching in five years, they can plan their risk management accordingly.
The Bottom Line
In 2026, the FDA is looking for a Secure Product Development Framework (SPDF) that is "built-in," not "bolted-on." They want to see a cohesive story where your Threat Model identifies a risk, your Security Architecture mitigates it, and your Testing proves the mitigation works.
