What Actually Gets Medical Device Cybersecurity Submissions Rejected
Since October 2023, FDA has had the authority to refuse a 510(k) outright if the cybersecurity documentation isn't there. Not delay it. Refuse to even review it. FDA tightened the requirements further with its June 2025 final guidance update, and heading into 2026, the same gaps keep showing up in submissions. We looked at what's actually driving those rejections, and the pattern is consistent across the industry.
The gap isn't awareness. It's execution.
Nearly every medtech team knows cybersecurity documentation is now mandatory. The problem shows up once they try to produce it.
A 2024 industry survey found that 72% of manufacturers struggle to produce a compliant SBOM, mainly because of how deep third-party and open-source dependencies run in a typical device stack. That's not a niche problem — an SBOM is one of 12 required cybersecurity documents in every eSTAR submission, and it's been a hard requirement since the 2023 guidance took effect.
Penetration testing tells a similar story. Recent data puts the failure rate for initial pen tests at 65%, and roughly 30% of 2024 submissions were flagged for inadequate testing documentation specifically. In parallel, about a quarter of 2024 submissions were delayed over insufficient cybersecurity testing evidence overall.
Why this keeps happening
None of this is really a testing problem. It's a documentation and process problem that shows up at testing time.
Threat modeling, SBOMs, and vulnerability monitoring only produce submission-ready evidence when they're built into the development lifecycle from early on — tied to IEC 62304 and structured against frameworks like STRIDE. Bolted on right before submission, they read exactly like what they are: reconstructed after the fact, not maintained throughout.
Scope creep between predicate and subject device adds another failure mode. Reviewers have pushed back on submissions where a new device introduced remote connectivity the predicate never had, and the sponsor's threat model and architecture docs weren't updated to reflect it. Substantial equivalence doesn't cover a wider attack surface.
Submissions that stall vs. submissions that clear
SBOM — generated once, right before filing → maintained continuously in SPDX/CycloneDX, updated every release
Threat model — generic template, not tied to the real architecture → STRIDE/MITRE ATT&CK-based, matched to the current build
Pen testing — done late, findings undocumented or unresolved → scheduled into the lifecycle, findings tracked to closure
Predicate comparison — assumes substantial equivalence covers new connectivity → explicitly re-assesses threat model when scope changes
Vulnerability monitoring — no defined process post-market → live CVE monitoring tied to the SBOM, with a response workflow
That's the difference between a submission that confirms the reviewer's confidence and one that opens a new round of questions.
Where to start
If none of this exists yet for your device, the fastest way to find out where you actually stand is a structured gap assessment against FDA's 2023/2025 cybersecurity guidance and MDCG 2019-16 — before a reviewer, notified body, or procurement team finds the gap for you.
Thaumatec's Cybersecurity Baseline Assessment covers exactly this: SBOM setup, STRIDE threat modeling, CVE monitoring, and a risk-ranked remediation roadmap, fixed price, 3–8 weeks depending on device class.
[See scope and pricing by class →] Or skip straight to a conversation: [book a 30-min call →]