FDA Cybersecurity Technical Screening Checklist (2026)

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.

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:

1. 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.
2. 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.
3. 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.

How Blue Goat Cyber Approaches Technical Screening Readiness

Technical screening is the second gate after RTA - and increasingly the one that catches submissions FDA used to let through. We build every package to pass it on the first review. Here is how.

• Pre-submission technical screen. Before you lock eSTAR we run the same checks technical reviewers run: traceability from threat model to test, SBOM completeness, security control coverage, postmarket commitments.
• Traceability matrix as a deliverable. Every requirement maps to a design control, a test, and a residual-risk decision - the single artifact that most efficiently closes the technical screener's questions.
• AAMI SW96 + IEC 81001-5-1 alignment. The two standards technical screeners cite most often are explicit in every deliverable.
• Deficiency-pattern coverage. We check against the RTA, AI-letter, and Major patterns FDA has issued in the past 24 months and close them pre-submission.
• Q-Sub when the gap is real. If pre-submission screening flags a substantive uncertainty, we scope a Q-Sub rather than gambling on interpretation.
• Senior engineers on every review. The person running the technical screen is the person who would defend the submission if a deficiency arrived.

Our FDA Premarket Cybersecurity Services engagement is the standard entry point.

Frequently asked questions

What is FDA technical screening, and how is it different from RTA?

Technical screening is the substantive review step that follows RTA acceptance. Where RTA is a checkbox screen for the presence of required artifacts, technical screening evaluates whether the artifacts are internally consistent, traceable, and grounded in recognized standards. A submission can pass RTA and still be held at technical screening if the threat model, SBOM, and pen test do not align.

Which check fails most often at technical screening?

Traceability between the threat model and the SBOM. Reviewers open the threat model, pick a specific threat, and try to trace it to (a) a mitigating control, (b) a component in the SBOM, and (c) an entry in the pen test report. When any of those three references break, the check fails. Rebuilding traceability after the fact is almost always slower than building it in.

Does the FDA's technical screening use AI or automated tooling?

The FDA has not disclosed specific tooling, but reviewers increasingly rely on structured data extraction (SBOM parsing, CVD policy URL checks, MDS2 field validation). Assume any structured field in your submission will be programmatically checked against expected format. Free-text narrative sections still need human review, but format compliance is fast to verify and fast to fail.

How long does technical screening take?

Two to six weeks for a well-authored submission, longer if the reviewer needs to open the interactive review. Cybersecurity screening runs in parallel with the other technical disciplines (software, biocompatibility, EMC) so a hold on cybersecurity does not necessarily block the rest of the review, but it does block clearance.

Can we ask the reviewer what they will check before submitting?

You can request a Pre-Submission (Q-Sub) meeting and use it to walk your cybersecurity approach and ask targeted questions. Reviewers will not preview their exact screening checklist, but they will confirm whether your intended standards, SBOM format, and postmarket plan structure are acceptable. For high-risk or novel devices this is a worthwhile investment.

What technical screening changes should we expect in 2026?

The February 3, 2026 final guidance sharpens expectations around SBOM currency, vulnerability disclosure evidence, and postmarket monitoring KPIs. Expect screeners to look for versioned postmarket plans, live CVD intake channels (not just a policy), and explicit references to ANSI/AAMI SW96:2023 and IEC 81001-5-1. Submissions built to the September 2023 final (or the June 2025 interim final) without a refresh commonly get held.

Related guides

• FDA Cybersecurity RTA Prevention Checklist, the acceptance gate that comes before technical screening
• FDA Premarket Cybersecurity Submission Checklist (2026), the full 18-deliverable package
• FDA cybersecurity guidance, 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

References

Primary sources cited or relied on in this guide:

• eSTAR Program (FDA), U.S. FDA
• 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
• 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