Blog Post

The Medical Device Submission That Never Gets Reviewed

September 24, 2026

Table of Contents

A cyber risk model prices what happens after something goes wrong. Attack, incident, cost. For a medical device manufacturer there is a loss that occurs before anything goes wrong at all, and it arrives at the front desk of a regulator.

‍

Where required cybersecurity documentation is missing from a premarket submission, the submission can be refused at intake rather than reviewed and returned with comments. Nothing was attacked. The cost is delay to market.

‍

What Is the Refusal Gate?

‍

An administrative check that happens before substantive review begins, and its arithmetic is the reason the cost is larger than a remediation estimate suggests.

‍

A submission is screened for completeness within fifteen calendar days of receipt. Accepted, the substantive review clock starts the following day. Held, the clock does not start at all, and when the sponsor supplies the missing content a fresh fifteen-day screening cycle runs on the corrections before substantive review can begin.

‍

Which Makes the Delay Compound

‍

The exposure is not the remediation effort. It is fifteen days of screening, plus however long the missing artifact takes to produce, plus another fifteen days of screening, before the review anybody cared about starts. A documentation shortfall that takes three weeks to fix has consumed something closer to seven.

‍

What Has to Be in the Submission?

‍

Three statutory deliverables, and the third is where refusals concentrate.

‍

Component inventory listing tracked packages with their categories, severity counts and the specific vulnerabilities recorded against each
A component record covering transitive dependencies rather than top-level packages is the difference between an artifact that passes screening and one that does not.

A plan for monitoring and addressing postmarket vulnerabilities. A secure product development framework demonstrating how security was built in. Then a machine-readable software bill of materials covering commercial, open-source and off-the-shelf components.

‍

Why Does the Component Record Fail Most Often?

‍

Because completeness is judged at depth rather than at the top level. A record listing the packages the team chose deliberately and omitting what those packages themselves depend on is incomplete in a way that is straightforward for a reviewer to spot. The requirement is unambiguous and the artifact is generated from the build rather than reconstructed afterward, which makes this among the more avoidable causes of a hold and among the more common. What a component inventory does and does not establish applies to the artifact itself.

‍

Which Devices Are Covered?

‍

More than manufacturers expect, since the definition turns on characteristics rather than on device class.

‍

A device qualifies where it includes software the sponsor validated, installed or authorized, is capable of connecting to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. The definition reaches cloud-based software functioning as a device and a wireless infusion pump alike, and the requirement applies across the major submission pathways regardless of risk classification.

‍

Which Removes the Usual Scoping Assumption

‍

A lower-risk device following a shorter pathway is not outside this. Manufacturers accustomed to scaling documentation effort by class find that the cybersecurity content does not scale the same way, and treating it as optional for a lower-class submission is a route to a hold.

‍

Did the Requirement Expire?

‍

No, and this is worth being precise about because the record is easy to misread.

‍

Exceedance curve showing the likelihood of annual loss exceeding successive percentages of revenue with the average marked
Expressing exposure against revenue is the useful frame where the loss is a delay to a product launch rather than an incident cost.

The statutory authority to refuse a submission lacking the required cybersecurity information sits in the amended act and does not expire. What expired was a transition policy from 2023, under which the agency stated it generally intended not to refuse submissions on those grounds before 1 October 2023 and would instead work collaboratively through the interactive and deficiency review process. The forbearance ended and the authority remained.

‍

Which Matters for the Exposure Estimate

‍

An organization reading that a policy lapsed and concluding the refusal risk went with it has understated the exposure to zero. The statutory requirements are the binding part, and the guidance interpreting them is treated by reviewers as the working standard, which is a different position from either being binding or being optional.

‍

How Should the Loss Be Modeled?

‍

As delayed revenue rather than as remediation cost, and the two differ by an order of magnitude.

‍

The remediation cost is engineering time to produce a missing artifact, which is modest and easy to estimate. The delay cost is the product not being on the market for the compounded screening period plus the fix, valued at whatever the launch was expected to earn in that window, plus any effect on a competitive position where a rival cleared first.

‍

What Makes the Second Term Estimable?

‍

The delay is bounded by a published process rather than by an unknown. Fifteen days, plus the fix, plus fifteen days is a computable interval once the fix duration is estimated, so the severity side of this scenario is unusually tractable compared with most cyber loss modeling, and cyber risk quantification built on a known process interval is a stronger figure than one built on an assumed outage.

‍

Where Does the European Requirement Sit?

‍

Inside the general safety and performance requirements rather than in a separate cybersecurity provision, which changes how it surfaces.

‍

Device regulation in Europe embeds software and security expectations within the essential requirements a device must satisfy for conformity, so the failure mode is a conformity assessment finding rather than an intake refusal. Different mechanism, same category of loss, since both convert a documentation shortfall into market access, and approval gating market access is the same structure in a neighboring sector.

‍

Two Records Rather Than One

‍

A manufacturer selling into both markets faces overlapping content requirements assessed by different bodies through different processes. The underlying artifacts largely serve both and the submissions do not, which is the evidence portability problem appearing in a device context, and normalizing one control set across frameworks is the general treatment.

‍

Who Owns the Cybersecurity Section?

‍

Regulatory affairs assembles the submission and security produces the content, and the two work on different calendars, which is where the shortfall originates.

‍

Regulatory affairs knows the submission date and the pathway and treats the cybersecurity section as one exhibit among many. Security owns the artifacts and is frequently told about the submission weeks before it files, by which point a component record generated from the build is available and a development framework evidenced across the project lifecycle is not. The framework requirement looks backward at how the device was built, so it cannot be produced late by definition.

‍

Which Artifact Cannot Be Produced Late?

‍

The development framework evidence, because it documents decisions made during design. A component record can be generated in an afternoon and a postmarket plan written in a week, while evidence that security requirements were defined, threats modeled and testing performed at the right stages either accumulated during development or did not exist, and records that survive an audit have the same property.

‍

What Is the Fix?

‍

Treating the submission date as a project milestone from the start rather than a regulatory event at the end. A device program that knows at kickoff which artifacts the submission requires accumulates them as byproducts, and one that discovers the list during submission preparation is reconstructing history, which where a program breaks down identifies as the evidence rather than the control.

‍

What Should Be Established Before the Next Submission?

‍

Four things, and the first is a build-process question rather than a regulatory one.

‍

Whether the component record is generated from the build and covers transitive dependencies, since a manually assembled top-level list is the most common cause of a hold. Whether the postmarket vulnerability plan exists as a document rather than as an intention. Whether the development framework can be evidenced rather than described. Then what a fifteen-plus-fix-plus-fifteen delay would cost for the specific product, since that figure is what justifies the effort.

‍

The Loss Arrives Before the Incident

‍

A submission missing required cybersecurity content can be refused at intake, so the cost is delay to market with no attack anywhere in the chain. The delay compounds, since screening runs fifteen days, a hold stops the substantive clock entirely, and supplying the missing content starts a fresh fifteen-day cycle before review begins. The component record is where refusals concentrate, because completeness is judged at dependency depth and the artifact should be generated rather than assembled. The definition of a covered device turns on characteristics rather than class, so a lower-risk pathway offers no relief. The statutory authority also did not expire when the 2023 transition policy did. Kovrr's cyber risk quantification models this as delayed revenue over a computable interval rather than as remediation effort.

‍

To see market access delay modeled as a loss category alongside conventional cyber scenarios, book a demo with our risk experts.

Tomer Shoolman

Product Manager

Device Submission FAQs

Speak to an Expert

What is the refusal gate on a premarket submission?

What cybersecurity content must a submission contain?

Why does the component record fail most often?

Which devices are covered?

Did the cybersecurity requirement expire?

How should this loss be modeled?