FDA Cybersecurity RTA Prevention Checklist: Avoid Refuse-to-Accept Holds

Use this checklist before you submit a 510(k), De Novo, or PMA for a cyber device. Each row maps to a specific Refuse-to-Accept (RTA) trigger the FDA cites under Section 524B of the FD&C Act and the FDA's February 3, 2026 final premarket cybersecurity guidance. An RTA hold adds 15 to 30 days at minimum and forces a resubmission with a new acknowledgment date, the easiest deadline to miss is the one you create yourself.

The FDA's Refuse-to-Accept screen is administrative: a reviewer checks whether each required artifact is present and in the right form, not whether it is correct. Most RTA holds we see are not because a sponsor lacked the evidence, they are because the evidence was attached as a PDF instead of CycloneDX, was missing a signed attestation page, or did not exist as a standalone deliverable. This guide is the pre-flight check.

Last reviewed: June 2026 against the FDA final guidance issued February 3, 2026 and Section 524B of the Food, Drug, and Cosmetic Act.

What an RTA hold actually is

Under 21 CFR 807.87 and the FDA's RTA policy for 510(k)s (and equivalent screens for De Novo and PMA), the agency performs an acceptance review within 15 calendar days of receipt. If any required element is absent or non-conforming, the submission is placed on hold and the sponsor is notified by email. The clock does not start until the deficient items are supplied and the FDA accepts the submission for substantive review.

For cyber devices, defined in Section 524B(c) as devices with software, internet connectivity, and technological characteristics vulnerable to cybersecurity threats, the RTA checklist now includes a dedicated cybersecurity block. Missing one cybersecurity artifact is enough to trigger the hold even when the rest of the submission is complete.

The six cybersecurity RTA triggers

1. Missing or unjustified cyber-device determination

Trigger: The cover letter does not state whether the device meets the Section 524B(c) definition of a "cyber device," or states "no" without a defensible rationale.

How to clear it: Include a one-page Cyber Device Determination memo in the submission. State the determination explicitly ("This device meets the definition of a cyber device under Section 524B(c)" or "...does not meet the definition for the following reasons..."). If the answer is "no," reviewers will challenge it when the device has Wi-Fi, Bluetooth, cellular, USB, removable media, or any cloud or mobile-app companion. See our FDA Section 524B requirements explainer.

2. SBOM that is not machine-readable

Trigger: The Software Bill of Materials is attached as a PDF, a Word table, or an Excel sheet instead of a machine-readable format. PDFs and screenshots fail the screen automatically.

How to clear it: Submit the SBOM as a standalone file in CycloneDX (JSON or XML) or SPDX (JSON, YAML, or tag-value) format. Include the seven NTIA minimum data fields plus dependency relationships, license, and component hash. Pair the SBOM with a known-vulnerability assessment that cross-references CISA's KEV catalog and the NVD, and provide VEX statements in OpenVEX or CycloneDX VEX for every CVE the assessment marks as unaffected. See CycloneDX vs SPDX for medical devices and the VEX document guide.

3. Threat model with no diagram, no boundaries, or no coverage of wireless and update paths

Trigger: The threat model is a bulleted list of risks, omits a data-flow diagram, or does not enumerate threats at every external interface and trust boundary.

How to clear it: Provide a diagram-driven threat model, STRIDE per data-flow boundary is the format reviewers expect most often; TARA (ISO/SAE 21434 style) is acceptable when justified for the architecture. At minimum, enumerate threats for: external network interfaces, every wireless protocol (Wi-Fi, Bluetooth, BLE, cellular, NFC, proprietary RF), the update and patch mechanism, debug and service interfaces (JTAG, UART, USB-debug), cloud and mobile APIs, and any AI/ML model endpoints. See STRIDE threat modeling for medical devices and the 12 critical threat modeling gaps we see in real submissions.

4. Missing system and security architecture views

Trigger: A single architecture diagram is provided where the guidance asks for multiple views.

How to clear it: Provide the four architecture views the FDA names in the February 2026 guidance: (1) global system view, (2) multi-patient harm view, (3) updateability and patchability view, and (4) security use-case view. Each view must show trust boundaries and the security controls that enforce them. Reviewers compare these views against the threat model to confirm every boundary in the diagrams appears in the threat enumeration.

5. No independent penetration test report, or one that does not cover all interfaces

Trigger: The submission contains internal security testing only, a vendor "scan report" instead of a penetration test, or a penetration test that omits one of the protocol families called out in the threat model.

How to clear it: Include a penetration test report from an independent third party (not the development team), with a signed attestation of independence and a methodology section that maps test cases to the threat model. Coverage must include every external interface and protocol: wireless radios, physical ports, update channels, cloud and mobile APIs, and any debug or service interface. Attach the tester's CV summary or firm qualifications. See our medical device penetration testing guide and the 12 critical findings from real pen tests.

6. No postmarket cybersecurity management plan or CVD process

Trigger: The submission discusses premarket controls but does not describe how the manufacturer will monitor, triage, and remediate vulnerabilities after clearance, or does not name a coordinated vulnerability disclosure (CVD) intake channel.

How to clear it: Include a standalone postmarket cybersecurity management plan that names: the monitoring sources (KEV, NVD, vendor advisories, SBOM-driven alerts), the triage SLA, the patch-release cadence, the customer communication channel, and the CVD intake URL or security.txt location. The plan must reference a published coordinated vulnerability disclosure policy that researchers can actually use. See VDP and CVD workflows for medical devices.

Pre-submission RTA self-audit (one page)

Run this checklist 10 business days before you ship the eCopy. Every row must be a "yes."

#	Artifact	Format check	Independence check	Cross-reference check
1	Cyber-device determination memo	Standalone PDF in cover materials	N/A	Matches device description
2	SBOM	CycloneDX or SPDX, machine-readable	Generated by build pipeline, not hand-edited	Component count matches release manifest
3	Known-vulnerability assessment + VEX	Standalone document; VEX in OpenVEX or CycloneDX VEX	Reviewed by security team, not dev	Every SBOM component appears in the assessment
4	Threat model	Diagram + enumeration; STRIDE or TARA	Reviewed outside the dev team	Every interface in the architecture views appears
5	Architecture views (4)	Separate diagrams for global, multi-patient, updateability, security use-case	N/A	Trust boundaries match threat model
6	Penetration test report	Standalone PDF with signed attestation	Independent third party	Test cases map to threat model entries
7	Postmarket cybersecurity plan	Standalone document	Named accountable owner	CVD URL resolves and security.txt is published

If any row fails, fix it before you submit. The 10-day window is enough to regenerate an SBOM, write a VEX statement, or publish a CVD policy, it is not enough to commission an independent penetration test.

Common "soft" deficiencies that escalate to RTA

These are not technically RTA triggers, but reviewers escalate them to a hold when they appear alongside any of the six items above:

• Unsigned attestations. Penetration test independence statements, SDLC conformance attestations, and cryptographic inventories all need a wet or digital signature with a name and title.
• Outdated guidance references. Citing the 2023 draft guidance or the 2018 premarket guidance instead of the February 3, 2026 final guidance signals the submission was assembled from a stale template. Update every reference.
• "FDA" used as a noun without "the." A copy-edit issue, but it makes reviewers question whether the document was reviewed by anyone with regulatory experience. Write "the FDA expects..." not "FDA expects..." when referring to the agency.
• Missing traceability between threat model and pen test. The pen test report should cite the threat model entry it covers. Reviewers ask for this explicitly when it is missing.

What happens after an RTA hold

The FDA sends an email naming the deficient items. Sponsors have an unlimited window to respond, but the original acknowledgment date is voided, when you resubmit, a new 15-day acceptance review starts. For a 510(k) on a 90-day MDUFA goal, a single RTA hold typically pushes clearance by 30 to 45 days because the substantive-review clock restarts.

If the hold cites a cybersecurity artifact, the response must include the corrected artifact and an updated traceability matrix showing where in the resubmission the artifact lives. Do not bury a regenerated SBOM in an appendix, call it out in the response cover letter.

When to bring in outside help

Most RTA holds on cybersecurity are caused by format or independence problems, not by missing engineering work. Two situations warrant an outside reviewer before submission:

1. You generated the SBOM by hand or from a scanner report. Hand-built SBOMs almost always miss transitive dependencies and fail the NTIA minimum-elements check. A build-time generator (Syft, CycloneDX Maven/Gradle plugins, language-native tooling) is the right answer.
2. The penetration test was done by the development team or by a generalist IT-security firm. Reviewers know the medical-device pen-test market and recognize firms that specialize in 510(k)-grade testing. A generalist report frequently gets challenged on coverage of wireless and update paths.

If either applies, get a second opinion before you submit. Blue Goat Cyber's medical device penetration testing and SBOM management services are built around the RTA criteria above.

How Blue Goat Cyber approaches RTA prevention

We run a pre-submission RTA screen against the six triggers above and the eSTAR cybersecurity subform in a single two-week engagement. You send us your current package; we return a triaged list of every element the FDA is likely to hold on, plus the specific document changes to close each one. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Track record: 250+ FDA submissions cleared, zero cybersecurity-driven rejections.

For teams still building the package, we author the threat model, SBOM, and premarket cybersecurity deliverables end-to-end.

Frequently asked questions

What is an RTA hold and how is it different from a deficiency letter?

Refuse to Accept (RTA) is an administrative screen the FDA runs within 15 calendar days of receiving a 510(k), before technical review starts. If the submission is missing required elements the FDA cites RTA and the review clock does not start. A deficiency letter (AI letter) is issued later in the substantive review cycle. RTA holds are faster to trigger and easier to prevent because the checklist is prescriptive.

Which single missing artifact triggers RTA most often on cybersecurity?

The SBOM. Under Section 524B(b)(3) an SBOM is required for every cyber device submission, and the eSTAR cybersecurity subform has a specific slot for it. Submissions that attach a vendor questionnaire or a dependency list instead of a machine-readable SBOM in CycloneDX or SPDX format get held. The February 3, 2026 final guidance is explicit about this.

Does the RTA screen apply to De Novo and PMA submissions?

The formal RTA checklist is 510(k)-specific, but the analogous acceptance screens for De Novo (Acceptance Review) and PMA (Filing Review) apply the same cybersecurity expectations. In practice, cybersecurity gaps that would trigger a 510(k) RTA will trigger equivalent holds on De Novo and PMA. Treat the RTA checklist as universal for cyber devices regardless of pathway.

How quickly can we respond to an RTA hold?

You have 180 days to respond before the submission is withdrawn. Most cybersecurity RTA holds can be resolved in 4-8 weeks if the underlying evidence exists and just needs to be assembled to the guidance format. Rebuilds where an artifact never existed (threat model, pen test) take 10-14 weeks. Missing that window forces a full resubmission and a new user fee.

Is the eSTAR cybersecurity subform mandatory?

Yes, for any 510(k) whose device meets the Section 524B(c) definition of a cyber device. The eSTAR template gates submission on the presence of the cybersecurity subform fields, so an incomplete subform is a mechanical RTA trigger, not a discretionary one. Reviewers cannot waive it.

Can outside legal or regulatory counsel prevent RTA cybersecurity holds?

Not directly. RTA cybersecurity screens turn on the presence and quality of technical artifacts (threat model, SBOM, security architecture, pen test), not on regulatory strategy. Counsel is essential for classification and predicate selection, but the artifacts still have to be built to the guidance and standards. A cybersecurity-fluent technical partner is what changes the RTA outcome.

Related guides

• FDA Premarket Cybersecurity Submission Checklist (2026), the full 15-section package, of which RTA covers the first acceptance gate
• FDA Cybersecurity Guidance Summary: 2026 Final Rule, what changed in February 2026
• FDA Section 524B Cybersecurity Requirements, the statutory basis
• FDA Cybersecurity Deficiency Response Checklist, for substantive-review deficiencies after RTA passes
• 12 Reasons the FDA Rejects Medical Device Cybersecurity Submissions, the patterns behind RTA and substantive deficiencies

References

Primary sources cited or relied on in this guide:

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
• Section 524B of the FD&C Act (Consolidated Appropriations Act, 2023, §3305), U.S. Congress
• eSTAR Program (FDA), U.S. FDA
• ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI
• NTIA/NIST, The Minimum Elements For a Software Bill of Materials (SBOM), NTIA / U.S. Dept. of Commerce