Use this checklist after your submission has cleared Refuse-to-Accept and before the FDA lead reviewer opens the substantive cybersecurity review. Technical screening is where most cyber-device deficiencies are written — not at the RTA gate. The artifacts are all present; reviewers are now asking whether each one is technically adequate and whether they tell a consistent story.
This guide walks the eight technical checks the FDA's cybersecurity reviewers run against a Section 524B submission, with the failure mode for each one. It is built around the February 3, 2026 final premarket cybersecurity guidance and the recurring deficiencies our team sees on real 510(k), De Novo, and PMA submissions.
Last reviewed: June 2026 against the FDA final guidance issued February 3, 2026 and Section 524B of the Food, Drug, and Cosmetic Act.
Screening vs. Refuse-to-Accept — what is different
Refuse-to-Accept is administrative: each required artifact is either present in the right format or it is not. Technical screening is substantive: a reviewer with security expertise reads the artifacts and asks whether they make sense together. RTA can be cleared by reformatting a file. Screening deficiencies typically require a new analysis, a re-test, or a redrafted plan.
If you want the upstream check, run our FDA Cybersecurity RTA Prevention Checklist first. The list below assumes you have already passed RTA.
The eight technical screening checks
1. SBOM resolves transitive dependencies and matches the release
What reviewers verify: the component count is plausible for the device, transitive dependencies are present (not just direct), each entry has a resolvable supplier and version, and hashes match the shipped binary.
Common failure: an SBOM generated by hand or from a top-level package.json / requirements.txt, with only direct dependencies and no transitive closure. Reviewers spot this because the component count is unrealistically small (often under 30 for a connected device).
How to pass: generate the SBOM in the build pipeline using a tool that walks dependency graphs — Syft, the CycloneDX Maven/Gradle plugins, cargo cyclonedx, cyclonedx-bom for Python, or language-native equivalents. Verify the SBOM against the release manifest before you submit. See SBOM vulnerability management for medical devices and CycloneDX vs SPDX for medical devices.
2. Vulnerability assessment is current and cross-references KEV and NVD
What reviewers verify: every SBOM component appears in the vulnerability assessment, the assessment cites a date within ~30 days of submission, and known-exploited entries from CISA's KEV catalog are explicitly addressed.
Common failure: the assessment was run once during development and was not refreshed before submission, so reviewers find KEV-listed CVEs that the report does not mention.
How to pass: rerun the assessment within two weeks of the submission date. Cross-reference every High or Critical CVE against KEV. For anything you mark as "not exploitable," provide a VEX statement in OpenVEX or CycloneDX VEX. See VEX documents for medical devices.
3. Threat model enumerates threats at every interface in the architecture views
What reviewers verify: every external interface, wireless protocol, update channel, debug port, and cloud or mobile API shown in the architecture views appears as a threat entry. STRIDE is the most common framework; TARA (ISO/SAE 21434) is accepted when justified for the device class.
Common failure: the threat model and the architecture diagrams were authored by different teams and drift apart. Reviewers find a Bluetooth interface in the diagram with no corresponding STRIDE entries, or a USB-debug port listed in the threat model that does not appear in the diagram.
How to pass: maintain a single traceability matrix that lists every interface from the architecture views down the rows and the STRIDE categories across the columns. Every cell must contain either a threat entry or a justified "not applicable." See STRIDE threat modeling for medical devices and the 12 critical threat modeling gaps.
4. Architecture views are four documents, not one
What reviewers verify: the submission contains the four architecture views the FDA names in the February 2026 guidance — global system view, multi-patient harm view, updateability and patchability view, and security use-case view. Each shows trust boundaries.
Common failure: sponsors submit a single block-diagram and label it "architecture," or submit the four views as a single combined diagram that omits trust boundaries on three of them.
How to pass: treat each view as a standalone deliverable with its own diagram, its own narrative, and its own trust-boundary annotations. The multi-patient harm view in particular is new in 2026 and is frequently missing.
5. Penetration test independence is documented and verifiable
What reviewers verify: the penetration test was performed by an independent third party (not the development team), with a signed attestation of independence, named testers with relevant qualifications, and a methodology section.
Common failure: the report is from a generalist IT-security firm with no medical-device experience, or from the device manufacturer's internal red team without an independence attestation.
How to pass: commission the test from a firm that specializes in medical-device penetration testing. Include a one-page attestation, the testers' qualifications, and a brief firm profile. See our medical device penetration testing guide.
6. Penetration test coverage maps to the threat model
What reviewers verify: each test case in the penetration test report cites the threat-model entry it covers, and every external interface in the threat model has at least one test case.
Common failure: the pen test report is organized by test type (network scan, web app, wireless) with no mapping to the threat model. Reviewers cannot tell whether the BLE pairing flow listed in the threat model was actually tested.
How to pass: add a coverage matrix to the executive summary of the pen test report — rows are threat-model entries, columns are test cases, cells reference the section of the report. Gaps must be justified in writing. See 12 critical findings from real pen tests.
7. Cryptographic inventory is complete and current
What reviewers verify: the submission inventories every cryptographic primitive in use — algorithms, key sizes, key-management mechanisms, random-number sources — and flags any deprecated primitives.
Common failure: the inventory lists "TLS 1.2+" without naming the cipher suites, or lists symmetric algorithms without key-derivation details. SHA-1, MD5, 3DES, RC4, and static-key DH still appear in inventories more often than they should.
How to pass: generate the inventory by inspecting the actual built binaries, not by reading a spec document. Map every primitive to a NIST SP 800-131A status. Replace anything marked "disallowed" before submission.
8. Postmarket cybersecurity plan names sources, SLAs, and a working CVD channel
What reviewers verify: the postmarket plan names monitoring sources (KEV, NVD, vendor advisories, SBOM-driven alerts), triage SLAs by severity, patch-release cadence, customer communication channel, and a coordinated vulnerability disclosure (CVD) intake URL or security.txt that resolves at the time of review.
Common failure: the plan describes process in generic terms ("monitor for vulnerabilities and respond appropriately") without naming sources or SLAs, or it cites a CVD URL that returns 404 when the reviewer clicks it.
How to pass: write the plan in numbered, testable statements. Publish the CVD policy at the URL you cite and confirm it resolves before submission. See VDP and CVD workflows for medical devices and our own coordinated vulnerability disclosure policy.
Pre-screening self-audit (one page)
Run this 5 business days before submission. Every row must be a "yes" supported by evidence.
| # | Check | Evidence | Owner |
|---|---|---|---|
| 1 | SBOM transitive closure | Build pipeline log + tool name | Engineering |
| 2 | Vulnerability assessment date within 30 days | Assessment cover page | Security |
| 3 | Threat-model ↔ architecture traceability matrix | Standalone matrix in submission | Security |
| 4 | Four architecture views, each with trust boundaries | Four diagrams + narratives | Architecture |
| 5 | Penetration test independence attestation | Signed PDF in pen-test report | Third-party tester |
| 6 | Pen-test ↔ threat-model coverage matrix | Section in pen-test executive summary | Third-party tester |
| 7 | Cryptographic inventory mapped to NIST SP 800-131A | Standalone inventory document | Engineering |
| 8 | CVD URL resolves; postmarket SLAs named | Live URL check + plan section reference | Security |
If any row fails, fix it before you submit. Most of these are 24- to 72-hour fixes; reissuing an independent pen test is the only one that typically takes longer.
Common technical-screening deficiencies that escalate
These do not block screening by themselves, but they almost always appear in the deficiency letter when they coexist with one of the eight items above:
- Stale guidance references. Citing the 2023 draft guidance or the 2018 premarket guidance instead of the February 3, 2026 final guidance flags the submission as assembled from an old template.
- Treating "FDA" as a noun without "the." A copy-edit issue that signals weak regulatory review. Write "the FDA expects..." when referring to the agency.
- Architecture views and threat model authored by different teams without reconciliation. Reviewers spot this immediately when interfaces appear in one but not the other.
- Pen test report dated more than six months before submission. Reviewers will ask for a delta test against the as-shipped build.
- Postmarket plan that names "the security team" without an accountable owner. Reviewers want a role (CISO, Director of Product Security) not a department.
What happens when screening writes a deficiency
The lead reviewer issues an Additional Information (AI) request listing each deficiency and citing the guidance section it maps to. The substantive-review clock stops until the sponsor responds. For a 510(k), each AI cycle adds roughly 30 to 60 days to the MDUFA decision date depending on the depth of the rework required.
Respond to every deficiency with: (1) the corrected artifact, (2) a redlined diff against the original where applicable, and (3) an updated traceability matrix showing where the corrected artifact lives in the resubmission. Do not bury fixes in appendices.
When to bring in outside help
Three situations warrant a second-opinion review before screening:
- The SBOM was hand-built or assembled from a scanner. Build-pipeline generation is the only path to a defensible SBOM. If you are not there yet, the fix is upstream of the submission.
- The penetration test was internal or done by a generalist firm. Reviewers recognize the medical-device pen-test market and challenge generalist reports on wireless and update-path coverage.
- The threat model is a list rather than a diagram-driven enumeration. Reviewers expect STRIDE-per-boundary at minimum; list-style threat models almost always draw a deficiency.
Blue Goat Cyber's medical device penetration testing, threat modeling services, and postmarket SBOM and VEX monitoring are built around the eight technical-screening criteria above.
Related guides
- FDA Cybersecurity RTA Prevention Checklist — the acceptance gate that comes before technical screening
- FDA Premarket Cybersecurity Submission Checklist (2026) — the full 15-section package
- FDA Cybersecurity Guidance Summary: 2026 Final Rule — what changed in February 2026
- FDA Cybersecurity Deficiency Response Checklist — what to do when screening writes you up
- 12 Reasons the FDA Rejects Medical Device Cybersecurity Submissions — the patterns behind RTA and screening deficiencies