FDA Cybersecurity RTA Prevention Checklist

Use this checklist before submitting a cyber device. The six categories below combine statutory obligations, guidance recommendations, and Blue Goat packaging preferences, not six universal RTA triggers.

Traditional RTA review checks acceptance criteria. eSTAR submissions instead undergo technical screening before substantive review. Content adequacy is assessed during substantive review; PDF format, a missing Blue Goat attestation, or combined attachments is not by itself an automatic refusal criterion.

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. Missing SBOM or unclear component information

Statute vs. format: Section 524B(b)(3) requires an SBOM. Machine-readable presentation is recommended; PDF-only presentation is not an automatic statutory failure.

How to clear it: Submit the SBOM as a standalone file in a recommended machine-readable format, such as CycloneDX or SPDX 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 optionally 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 a Blue Goat best practice, not a prescribed FDA method; 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

Recommended evidence: Document risk-appropriate penetration testing, coverage, and tester independence. Independence does not require an outside vendor; qualified internal testers independent of design can provide it.

How to clear it: Include a penetration test report with documented independence from device design; an outside firm and signed attestation are Blue Goat preferences, not blanket FDA requirements 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."

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 "FDA guidance recommends..." not "FDA guidance recommends..." 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 identifies the missing items. For a 510(k), submit a complete response within 180 calendar days of the hold notification or the submission is considered withdrawn. Follow the notification and applicable rules for other pathways. eSTAR technical-screening responses and traditional RTA responses use the applicable submission process; do not assume that a new submission number or acknowledgment date is required.

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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Track record: 275+ FDA submissions supported, zero cybersecurity rejections. Past results do not guarantee an FDA outcome.

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?

Section 524B(b)(3) requires an SBOM for covered cyber-device submissions. Machine-readable presentation is recommended, with CycloneDX and SPDX common choices. No supported ranking establishes it as the most frequent missing artifact.

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 can cause a technical-screening hold. Follow current template instructions and applicable exemptions.

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 18-deliverable package, of which RTA covers the first acceptance gate
• FDA cybersecurity guidance, 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

Where to go next

• FDA Cybersecurity Technical Screening Checklist - the eSTAR completeness check before substantive review.
• How to Prepare 510(k) Cybersecurity Documentation Before You Submit, the end-to-end preparation plan.
• eSTAR Cybersecurity Checklist - walk the cybersecurity attachment contents before you lock the eSTAR.

References

Primary sources cited or relied on in this guide:

• Cybersecurity in Medical Devices: Quality Management 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