FDA 524B Cybersecurity Evidence Checklist — What Reviewers Actually Want (2026)

The technical artifacts FDA reviewers actually want — and the gaps that get submissions Refuse-to-Accept'd.

Since October 2023, FDA can Refuse to Accept any premarket submission for a "cyber device" that's missing cybersecurity content — and under the current final guidance, cyber deficiencies are now one of the top reasons submissions stall across 510(k), PMA, De Novo, HDE, and PDP. Most teams have a cybersecurity plan. Far fewer have the evidence that makes the plan credible to a reviewer. This checklist is organized around the artifacts you must be able to hand over — not just the paperwork. If you can't check a box with something you could give a reviewer today, that's a likely RTA finding.

A. Threat modeling & security risk management

System-wide threat model (device, interfaces, comms, cloud/companion apps) using a recognized method (e.g., STRIDE).the model stops at the device and ignores interfaces, network, and the update path.

Security risk assessment linking each threat → risk → mitigating control, traceable to design inputs.security risk folded into the safety risk file with no security-specific analysis or traceability.

Security-appropriate risk scoring (e.g., CVSS + exploitability + clinical impact), distinct from safety severity.safety-only severity is used, so exploitability is never actually assessed.

B. Software Bill of Materials (SBOM)

Machine-readable SBOM (SPDX or CycloneDX) covering commercial, open-source, and off-the-shelf components.a static PDF/spreadsheet, or missing transitive dependencies.

Support status + end-of-life / end-of-support dates per component.no EOL data, so reviewers can't judge long-term maintainability.

Vulnerability assessment of SBOM components (known CVEs) with a safety/security rationale for anything unresolved.SBOM present, but no linked vuln analysis or justification for open CVEs.

C. Security architecture

Architecture views showing trust boundaries, data flows, and interfaces (global-system, multi-patient-harm, update/patch, and security use-case views).a single block diagram that never shows trust boundaries or the update path.

Interface analysis — every external/comms interface and its protections.undocumented debug/maintenance interfaces (UART / JTAG / hidden services) — a classic reviewer finding.

D. Security testing evidence ⟵ where submissions are actually won or lost

Security requirements testing — evidence each security requirement is met (not just stated).requirements are written, never verified.

Threat-mitigation testing — proof each control from the threat model actually works.controls "designed in" but never tested.

Vulnerability testing — abuse/misuse cases, malformed-input/fuzz testing, static & dynamic analysis, with tools and results.a raw scanner report with no triage — or no fuzzing at all.

Independent penetration test with a real report: scope, methods, tester independence, findings, severities, remediation & residual risk.a "pen test" that's really just a vuln scan, or a report with no scope/independence.

Firmware / runtime / protocol analysis appropriate to the device: secure boot, key & credential handling, comms security, memory protections.black-box testing only — no firmware-level evidence, which is exactly where the real vulnerabilities live.

E. Postmarket monitoring & vulnerability management

Postmarket monitoring plan — how you find new vulnerabilities in your device and its components across its lifecycle, with an owner.a policy statement with no operational process behind it.

Coordinated Vulnerability Disclosure (CVD) process (ISO/IEC 29147 & 30111) with an intake path researchers can actually use.no public disclosure channel — so a researcher's first "report" is a public tweet.

Patch/update plan — scheduled cadence + out-of-cycle timelines for critical vulns, plus how updates are delivered and validated.no committed timelines and no evidence the update mechanism works.

F. Security labeling & documentation

Security labeling for users/operators — hardening guidance, network/port info, backup/restore, EOL.no security labeling, or it's buried and non-actionable.

Cybersecurity summary tying all of the above together and mapping it to the 524B elements for the reviewer.the artifacts exist but are scattered, so the reviewer can't map them to the requirements.

Evidence traceability — every claim in the cyber section backed by a named artifact a reviewer can request.claims in the summary that no artifact actually supports.

How to use this: if you can confidently check every box with an artifact you could hand a reviewer today, you're submission-ready on cybersecurity. Every unchecked box is a likely RTA finding — cheaper to fix before you file than after. (Your checks save in this browser; print this page for your submission binder.)

Where the hard boxes get checked

Sections A–D — threat modeling, SBOM vulnerability analysis, and especially the security testing and firmware / runtime / protocol evidence — are the ones consultants can't produce and scanners can't fake. That's what VivaSecuris does: we're the technical evidence layer under your regulatory plan, generating the artifacts FDA reviewers accept — on your 524B clock. Subcontract or white-label to your regulatory partner; one product line first.

Request a scoping call

Current to FDA's final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (2025 final, updated 2026) and FD&C Act §524B. This is technical guidance to help you assemble evidence — not legal or regulatory advice. Verify against the current FDA guidance for your specific submission.
© 2026 VivaSecuris · vivasecuris.com