Picture a Series B medtech company. Eighteen months of engineering. A novel connected device, Class II, with cybersecurity features the team is genuinely proud of. The Regulatory Affairs Director files the 510(k) submission on a Friday. Champagne in the office. Monday she's back at her desk, opening the FDA eSTAR portal to check on intake status.

Two weeks later, the email arrives: Refuse to Accept. The SBOM is non-compliant with the NTIA Minimum Elements. The submission is sent back without ever being substantively reviewed. The clock that's already been ticking — investor expectations, competitor product launches, runway burn — keeps ticking. Now with an extra three to six months added.

This scenario isn't hypothetical. It's the most common outcome of the most common failure mode in medical device cybersecurity submissions in 2024-2025. And it's almost always preventable.

What an RTA actually is

An RTA — Refuse to Accept — is a decision FDA makes during the Technical Screening period that runs the first 15 calendar days after a 510(k) is submitted. It's different from a Hold Letter (which comes during substantive review and asks for clarifications) and from an outright denial (which comes at the end of review).

An RTA means: we haven't even started reviewing your submission, and we're sending it back because it's incomplete.

For cybersecurity, the most common RTA triggers since October 2023 have been:

None of these failures are about whether your device is actually secure. They're about whether you documented it the way FDA wants to see it documented. That distinction matters, because it tells you exactly where to focus.

The 15% number

Industry reporting from cybersecurity consultancies and regulatory affairs publications in 2024 and 2025 converges on a roughly 15% RTA rate for 510(k) submissions where the trigger is cybersecurity-related, since FDA began enforcing SBOM requirements on October 1, 2023.

Some adjacent numbers from the same period are worth knowing:

By the numbers

25% of 510(k) submissions in 2024 were delayed due to insufficient cybersecurity testing evidence.

30% were flagged for inadequate penetration testing documentation.

72% of medical device manufacturers report struggling to produce a fully compliant SBOM.

65% of medical devices fail their first penetration test.

What's striking about these numbers in aggregate is the implication: cybersecurity is not the area where most manufacturers fail because the engineering is hard. It's the area where most fail because the documentation gates are unfamiliar, the formats are specific, and the standards (SBOM machine-readability, postmarket monitoring plans, threat model views) are recent.

What an RTA actually costs

The financial cost of an RTA is rarely a single number. It compounds across several dimensions, and it varies enormously by company stage. Here's the breakdown that emerges from conversations with regulatory affairs leads at medtech startups:

Time

Best case: an RTA on documentation issues only takes 4-8 weeks to remediate and resubmit. Realistic case: 3-6 months. Worst case: if the RTA reveals deeper engineering or design control gaps, it can run 9-12 months as the team rebuilds underlying documentation systems before the submission can be cleanly resubmitted.

Direct costs

Emergency cybersecurity consulting engagements in 2025 ran $30K-$150K depending on scope. Penetration tests rerun mid-submission run $25K-$75K. Legal and regulatory consultant time often adds another $20K-$50K. A typical "fix the RTA" engagement at a Series A-B medtech runs $50K-$200K all-in.

Opportunity costs

This is where the real damage lives, and it's the hardest to quantify cleanly. A six-month delay on FDA clearance can mean: missing a competitor's market entry window, losing a strategic partnership conditional on clearance timing, losing a hospital pilot that was waiting on regulatory clearance, missing an investor milestone that triggers next-round terms. For a Series B medtech with a $200K monthly burn, six months is $1.2M of runway burned without proportional progress.

The same documentation work, completed before submission, costs ten percent of what it costs to fix mid-RTA. The economics of compliance always favor doing it once, properly.

Team and credibility costs

Less quantifiable but real. An RTA on the first 510(k) submission can erode internal team confidence and external investor confidence in regulatory leadership. The "we know how to navigate FDA" credibility takes longer to rebuild than the documentation itself.

The 5 patterns that explain almost every cyber RTA

Across the conversations we've had with regulatory affairs leaders preparing or recovering from cyber-related RTAs, the same patterns appear repeatedly. If you can audit your submission against these five before filing, you've eliminated the vast majority of cyber RTA risk.

1. SBOM that exists but isn't machine-readable

The single most common RTA trigger since October 2023. Many teams produce an SBOM as a PDF table or spreadsheet, assuming FDA wants "a list of software components." FDA wants a machine-readable file (SPDX or CycloneDX format) that meets NTIA Minimum Elements, including: supplier name, component name, version, unique identifiers, dependency relationships, author of SBOM data, and timestamp. A spreadsheet is not an SBOM.

2. Threat Model missing required architecture views

The FDA Cybersecurity Guidance explicitly identifies four architecture views required for cyber devices: Global System, Multi-Patient Harm, Updateability and Patchability, and Security Use Case. A Threat Model that addresses only the Global System view — common in submissions adapted from older internal documents — will trigger a request for clarification or, increasingly, an RTA.

3. Cybersecurity Management Plan with no postmarket detail

Section 524B requires a documented postmarket cybersecurity plan as part of the premarket submission. Plans that focus on premarket activities (testing, documentation, risk management) but skip or thinly cover postmarket activities (vulnerability monitoring, coordinated vulnerability disclosure, patch coordination, end-of-support communication) fail Technical Screening because the statutory requirement is unambiguous.

4. Pen test scope mismatch

The pen test report shows version 2.3 of the device firmware. The submission references version 2.5. Or the pen test was done on the cloud component only, when the device has both firmware and cloud components in scope. Or the pen test predates the most recent security architecture changes documented elsewhere in the submission. These mismatches are quickly caught in Technical Screening and routinely trigger RTAs.

5. SBOM components not mapped to known vulnerabilities

The SBOM lists 47 components. But there's no accompanying analysis of whether any of those components have known CVEs (Common Vulnerabilities and Exposures) at the time of submission. FDA expects manufacturers to demonstrate awareness of the vulnerability landscape for their software supply chain — not just to list components, but to show they've been checked against vulnerability databases and that any relevant CVEs are addressed or mitigated.

The pre-submission checklist

If you're 4-8 weeks from filing a cyber device submission, here's the minimal self-audit to run before the eSTAR upload:

  1. Is your SBOM in SPDX or CycloneDX format, machine-readable, and meeting all 7 NTIA Minimum Elements?
  2. Does your Threat Model contain all four required architecture views?
  3. Does your Cybersecurity Management Plan have a dedicated postmarket section with concrete commitments on vulnerability monitoring, CVD, and patch coordination?
  4. Does your pen test report scope and version exactly match what's described elsewhere in the submission?
  5. Have you mapped your SBOM components against the NVD or another vulnerability database, and documented any CVEs and their mitigations?
  6. Is every cyber requirement traced to a specific FDA Cybersecurity Guidance section (Feb 3, 2026 version) in your cross-reference table?
  7. Has someone outside the team that drafted the documents read them end-to-end with fresh eyes, specifically looking for internal inconsistencies?

The last one matters more than people think. Most RTAs are caught by FDA reviewers who've seen the same patterns hundreds of times. They're not finding hidden flaws; they're finding things the submitting team had stopped seeing because they'd been staring at the documents too long.

The hard truth

Most cyber RTAs are not the result of bad engineering. They're the result of submitting documentation that hasn't been audited against the specific, narrow technical standards FDA enforces during Technical Screening. The engineering work is usually fine. The documentation discipline isn't.

This is, in some ways, good news. It means that the difference between an accepted submission and an RTA is rarely a months-long engineering rework. It's usually a few weeks of focused documentation review and remediation, done before submission rather than after.

The economics favor doing it once, properly, before filing. They always have. The 15% of submissions that hit RTAs in 2024-2025 weren't catastrophic failures of engineering. They were avoidable failures of pre-submission audit.