If you file a medical device submission with a weak threat model, a mismatched SBOM, or a postmarket plan that your team can’t run day to day, FDA may stop the process before review starts.

Here’s the short version: I see the same three problems driving many cybersecurity setbacks in premarket submissions. Teams leave security work too late, their evidence doesn’t line up across design, testing, and risk files, and they fail to connect cyber issues to patient harm. That now affects more than FDA review. It also affects hospital buying decisions, with 56% of healthcare buyers rejecting a device over security concerns and 35% refusing to consider a device without an SBOM.

If I were preparing a filing today, I’d focus on four things first:

  • Start threat modeling early - during architecture work, not after design freeze
  • Keep one traceable chain from threat → control → test → result
  • Generate the SBOM in the build pipeline so it matches the shipped product
  • Write a postmarket plan your team can actually run, with named roles, timelines, and customer notice steps

A few facts shape the stakes:

  • Since October 2023, FDA has used Refuse to Accept (RTA) authority for missing cybersecurity records
  • As of February 2, 2026, FDA guidance lines up with QMSR and ISO 13485:2016
  • In early 2026, 24% of healthcare groups reported a medical-device-related attack or exploited flaw
  • Of those, 80% said patient care saw a moderate or major effect
  • The average U.S. healthcare breach cost reached $10.22 million in 2026

My takeaway: cybersecurity records now need to work in engineering, quality, regulatory review, and hospital procurement at the same time.

The rest of this piece explains where submissions tend to fail, what FDA keeps looking for, and what I’d fix before filing.

Medical Device Cybersecurity: Key Stats & Submission Risks 2026

Medical Device Cybersecurity: Key Stats & Submission Risks 2026

What Is Required for an FDA Premarket Cyber Submission? | Ep. 47

FDA

Threat Modeling Patterns in Recent Submissions

Threat modeling works best when it creates a clear security chain: each threat ties to a control, each control ties to a test, and each test ties to a documented result [1].

Methods and Artifacts That Align With FDA Expectations

The strongest recent submissions built threat modeling into the design record instead of parking it in a separate security appendix. That matters because reviewers can then follow security decisions in the same place as the rest of the product design.

The best-aligned submissions include security architecture views with annotated data-flow diagrams, trust boundaries, and asset inventories. Together, these artifacts show system boundaries and interfaces [1].

Reviewers are looking for a direct line from threat to control, control to test, and test to result [1].

Artifact quality gets better when threat modeling starts early enough to shape the architecture. In plain terms, it needs to begin during architecture work, before design freeze, while data flows are still changing [1].

Common Threat Modeling Gaps in Reviewed Materials

The same reviews point to a few common medical device security risks: missing interfaces, missing lifecycle scope, and weak safety linkage.

One repeat issue is incomplete interface coverage. That includes dormant wireless modules and unused ports that still exist in the product and can still matter [1]. Recent submissions also leave out support and end-of-life phases, even though SPDF requires them [2].

The weakest submissions don’t connect cybersecurity threats to patient safety and effectiveness. A strong Security Risk Management Report should tie together the threat model, misuse scenarios, controls, and the rationale for residual risk [1].

Risk Mitigation Controls and Submission Evidence

Once threats are mapped, reviewers want proof that each control is there in three places: the build, the test record, and the update process.

Security Architecture, SBOMs, and Testing Documentation

Good submissions don’t just talk about security. They show it.

Under Section 524B, FDA reviewers expect a postmarket vulnerability plan, proof of secure-by-design processes, and a machine-readable Software Bill of Materials (SBOM). Security architecture evidence should also include annotated data-flow diagrams, trust boundaries, asset inventories, and clearly defined defensive layers.

One of the most common weak spots is the SBOM. Teams often pull together component lists by hand right before filing. That sounds fine on paper, but it tends to fall apart in practice. Manual SBOMs often miss transitive dependencies, and they can drift away from the build that actually ships. The practical answer is simple: generate the SBOM inside the automated build pipeline so it matches the shipped product.

Testing records run into a similar problem. Automated vulnerability scans, by themselves, do not show reasonable assurance. Reviewers expect risk-based testing tied to the device’s attack surface and risk profile. That usually means a mix of static analysis, dynamic analysis, fuzzing, vulnerability scans, and penetration testing.

Update mechanisms are another place where submissions often come up short. FDA expects evidence of signed, authenticated updates, rollback protection, and staged deployment. A broad patch-delivery write-up isn’t enough.

Traceability From Threat to Control to Verification

The strongest submissions keep one auditable chain from threat to control to residual-risk rationale. If those links are missing, or scattered across separate documents, reviewers can’t easily confirm that a given threat was actually mitigated.

The table below shows where recent submissions most often lose that chain.

Documentation element What FDA expects Observed submission pattern Common gap Practical lesson
SBOM Machine-readable inventory with versions, suppliers, and transitive dependencies Manually assembled spreadsheets or static lists Missing transitive dependencies; deviates from the shipped build Automate generation within the build pipeline
Testing Evidence Risk-based; includes adversarial testing Basic automated vulnerability scan reports Scans don't demonstrate how a device holds up against actual attack methods Combine scans with documented, independent penetration testing
Update Mechanism Signed/authenticated delivery with rollback protection Generic patch-delivery description No evidence of integrity checks or protection against failed updates Document the cryptographic methods used to sign updates
Postmarket Plan Operational procedures for monitoring and 30-day customer notification Aspirational policy statements or high-level goals Lacks specific communication channels, assigned roles, and timelines Write the plan you can actually run; define specific roles, channels, and timelines

A traceability matrix is one of the most useful ways to fix these gaps. It forces each identified threat to map to a test result, so the security story is visible in one place. That matters because reviewers shouldn’t have to stitch the evidence together from a stack of separate files.

These evidence gaps are the same problems that lead to repeated review deficiencies.

Common Deficiencies and Lessons From Recent Reviews

Deficiencies That Repeatedly Slow or Weaken Submissions

A few review patterns keep showing up, and they tend to cause the same kinds of delays.

Most weak submissions fall into five common failure modes.

The biggest problem is security documentation added late, after design freeze. At that point, it often no longer matches the actual architecture. Threats, controls, and verification drift apart, and the whole story stops making sense. Since October 1, 2023, the FDA can issue a Refuse to Accept (RTA) letter before the review clock even starts if cybersecurity details are missing or inadequate [1].

Five deficiencies appear again and again:

  • Incomplete SBOMs that don't match the shipped build
  • Unsupported software components with no documented vulnerability tracking or patch history
  • Testing limited to automated scans
  • Non-operational postmarket plans
  • Missing linkage between cybersecurity findings and clinical impact, which keeps reviewers from judging residual risk against patient safety

The good news is that each of these problems has a process fix.

That last issue matters a lot. In early 2026, 24% of healthcare organizations reported an attack or exploited vulnerability involving a medical device, and 80% of those said it had a moderate or significant impact on patient care [1]. If a submission can't show how a security gap could affect patient safety, reviewers - and clinicians - are left guessing.

What Manufacturers Should Change Before Filing

Start threat modeling at the whiteboard stage, before design freeze, when data flows and trust boundaries are still in motion. That timing makes a big difference. Architecture-led threat modeling gives you evidence tied to the device as it's being designed, linked to actual design choices, and much easier to trace into controls and test results.

The SBOM and testing issues also have plain, workable fixes. Generate the SBOM inside the build pipeline so it reflects the software that actually ships, not a last-minute snapshot pulled together right before filing. And don't stop at vulnerability scans. Add independent penetration testing based on the device's actual attack surface.

Cybersecurity now sits inside design controls and CAPA, which means the same body of evidence needs to support both engineering and regulatory review.

That pushes manufacturers toward a simple filing rule: line up the evidence once, then use it across engineering, risk, and regulatory review.

These submission patterns affect more than FDA review timelines. They now shape how hospitals buy medical devices.

As of April 2026, 56% of healthcare buyers have rejected a medical device due to security concerns, up from 46% in 2025 [1]. And 35% of purchasing decision-makers won't consider a device that lacks an SBOM [1]. That changes cybersecurity from a filing issue into a purchasing issue.

In plain terms, the same proof used for FDA review now helps decide whether a vendor gets approved. 84% of healthcare organizations now include specific cybersecurity requirements in their vendor RFPs [1]. So if submission documents are weak, market access can take a hit. Manufacturers now need evidence that works in both settings: FDA review and hospital sourcing.

That puts pressure on internal teams to work from the same set of records. Product, security, quality, and regulatory groups need one traceable evidence set, not scattered files and last-minute patchwork. If one team says one thing and another team shows a different document, buyers notice.

For HDOs that are sizing up device risk, the need is just as clear. Buyers need standardized, comparable evidence so they can judge security posture the same way across devices before anything is purchased or deployed. Without that, procurement turns into guesswork.

Conclusion: Core Lessons From Recent Submissions

Submission discipline now affects both regulatory results and market access. With average U.S. healthcare breach costs at $10.22 million in 2026 [1], asking for submission-quality evidence during procurement isn't just due diligence - it's a patient safety decision.

FAQs

What should a complete threat model include?

A complete threat model for medical device premarket submissions should use a structured method, such as STRIDE or attack trees, to map key assets, trust boundaries, and likely attack paths.

That means spelling out what needs protection, where data moves, and where an attacker could slip in.

A strong submission usually includes:

  • Asset identification
  • Data flow diagrams
  • Clear system boundaries

It should also connect threats and vulnerabilities to specific controls and mitigations in the traceability matrix. In plain English, reviewers should be able to follow the line from risk to control without guessing.

The documentation should also reflect the device’s risk level and potential patient harm. A device that could affect therapy, diagnosis, or patient safety needs a threat model that matches those stakes.

How can manufacturers prove an SBOM matches the shipped device?

Manufacturers should automate SBOM generation inside the CI/CD pipeline so the file matches the exact shipped build, not an old snapshot.

The SBOM needs to include all components, including transitive dependencies. It should also include build metadata, such as the source code Git hash and a generation timestamp that lines up with the build date.

Before submission, validate the SBOM structure with SPDX or CycloneDX validators.

Why is linking cybersecurity risk to patient harm so important?

Because cybersecurity vulnerabilities aren't just technical problems - they can directly affect how a device works and, in turn, patient safety. When security controls fail, the result can be unauthorized changes, delayed results, or corrupted clinical data.

Tying those risks to specific harms, like overdose, underdose, or therapy interruption, shows a clear grasp of device safety. It also helps meet FDA requirements across the device lifecycle.

Related Blog Posts