FDA RTA on Cybersecurity: What It Costs and the 5 Patterns Behind It

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:

• Missing SBOM
• SBOM not in a machine-readable format (SPDX or CycloneDX)
• SBOM missing NTIA Minimum Elements
• Missing Cybersecurity Management Plan
• Threat Model missing one or more required architecture views
• No documented postmarket vulnerability management plan

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.

Why this became a rejection category

Two dates explain most of it. On October 1, 2023, FDA began refusing to accept premarket submissions for cyber devices that do not contain the cybersecurity information required under section 524B of the FD&C Act. On February 3, 2026, it issued the current final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions — which supersedes the June 27, 2025 version and spells out what that content is expected to include, the software bill of materials among it.

Because the gate is documentary, cybersecurity is not where most manufacturers fail for lack of engineering. It is where they fail because the formats are specific, the expectations are recent, and the evidence was assembled after the work instead of alongside it.

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 is how it breaks down:

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

Remediation work at this stage is quoted, not priced. The engagement gets scoped after the deficiency arrives, and what drives the number is how much of the evidence has to be rebuilt rather than reformatted — an SBOM that has to be regenerated from the build system is a different job than one that has to be exported in a machine-readable format. Rerunning a penetration test mid-submission is normally a separate line item, and regulatory consultant time to rewrite the submission narrative is another. Almost none of these vendors publish rates, which is why most teams only find out what an RTA costs at the moment they can least afford to negotiate.

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, produced before submission, is a scheduled task. Produced after a deficiency letter, it is an emergency with an FDA clock attached. The work is identical — only the leverage changes.

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

These five come out of reading FDA's cybersecurity guidance against what it actually asks a reviewer to be able to verify. Each one is a place where the security work can be done and the evidence still fails. If you audit your submission against them before filing, you remove most of the avoidable 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 submissions that hit an RTA on cybersecurity grounds aren't catastrophic failures of engineering. They're avoidable failures of pre-submission audit.