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:
- 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.
- 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.
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