Last reviewed: May 1, 2026
Use this checklist to assemble a 510(k), De Novo, or PMA cybersecurity package that survives the Refuse-to-Accept (RTA) screen and the substantive review under Section 524B of the FD&C Act and the FDA's February 2026 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.
The 15 items below are the deliverables FDA reviewers look for, in the order they are usually evaluated. Each section names the controlling standard, the artifact your reviewer expects to see, and the most common deficiency we see when sponsors skip a step.
Last reviewed: May 2026 against the FDA final guidance issued February 26, 2026 and Section 524B of the Food, Drug, and Cosmetic Act.
1. Cyber Device Determination
Document whether the device meets the Section 524B(c) definition of a "cyber device": it includes software validated, installed, or authorized by the sponsor; has the ability to connect to the internet; and contains technological characteristics that could be vulnerable to cybersecurity threats. If yes, the full Section 524B package applies. If no, document the rationale — reviewers will challenge a "no" if the device has Wi-Fi, Bluetooth, USB, cellular, or cloud connectivity.
2. Security Risk Management File (AAMI SW96 / TIR57)
Provide a security risk file aligned to AAMI SW96:2023 (FDA-recognized) with TIR57 as the supporting reference. Reviewers want a risk file that is separate from ISO 14971 safety risk and that explicitly maps security risks to patient-harm scenarios. See our TIR57 vs TIR97 vs SW96 comparison for which standard to anchor on.
3. Threat Model (STRIDE, TARA, or equivalent)
A diagram-driven threat model is required, not a bullet list. STRIDE per data-flow boundary is the format reviewers see most often; TARA (ISO/SAE 21434 style) is acceptable when justified. Cover at minimum: external interfaces, wireless protocols, update mechanisms, debug/service interfaces, cloud APIs, and any AI/ML model endpoints. See STRIDE threat modeling for medical devices.
4. System and Security Architecture Views
Provide multiple architecture views: global system, multi-patient harm view, updateability/patchability, and security use-case view. Each view should call out trust boundaries and the security controls at each boundary.
5. Software Bill of Materials (SBOM)
Submit a machine-readable SBOM in CycloneDX or SPDX format. Include the seven NTIA minimum data fields plus dependency relationships, license, and hash. Pair the SBOM with a known-vulnerability assessment (KEV-aware) and VEX statements for any unaffected CVEs. See our CycloneDX vs SPDX comparison and VEX document guide.
6. Vulnerability Management Plan
Document how you triage, score (CVSS v3.1 / v4.0), and remediate vulnerabilities, including the SLA from disclosure to deployed patch. The plan must cover both your own code and third-party components surfaced by the SBOM. See SBOM vulnerability management for medical devices.
7. Secure Product Development Framework (SPDF) Evidence
Show that security activities are wired into your QMS lifecycle — design inputs, design reviews, V&V, and change control — aligned to IEC 81001-5-1 and NIST SP 800-218 (SSDF). Reviewers reject "policy only" evidence; provide artifacts (review records, training rosters, tooling output).
8. Penetration Testing Report
A third-party penetration test report covering all external interfaces and protocols (Wi-Fi, BLE, USB, NFC, cellular, web/API, mobile companion app, DICOM, HL7/FHIR where applicable). Reviewers expect named tooling — typically Nessus or OpenVAS for network/vulnerability scanning, Burp Suite for web/API testing, OWASP ZAP as a secondary, plus protocol-specific tools (e.g., Wireshark, hcitool, sdrtrunk for RF). Include scope, methodology, findings, CVSS scoring, and remediation status. See our pentest cost guide.
9. Cryptographic Inventory and Key Management
List every cryptographic primitive (algorithm, mode, key length), the FIPS validation status of each implementation, and the key lifecycle (generation, storage, rotation, destruction). Flag any deprecated algorithms (MD5, SHA-1, 3DES, RSA <2048, TLS <1.2). Note any plan for post-quantum readiness.
10. Update and Patch Mechanism Design
Section 524B(b)(2) explicitly requires that devices be "designed to be updated and patched." Describe the technical mechanism (signed firmware, OTA channel, container registry, app-store distribution), the integrity protections, and how the operating organization is notified.
11. Monitoring, Detection, and Coordinated Vulnerability Disclosure (CVD)
Provide a CVD policy with a published intake channel (security.txt or dedicated email). Describe production monitoring — log sources, retention, and the events that would indicate compromise. CISA / KEV monitoring should be tied to the SBOM.
12. Labeling for Cybersecurity
Labeling must include: a list of cybersecurity controls, a description of the device's secure configuration, a list of network ports/protocols, the SBOM (or pointer to it), the CVD intake, the support lifecycle and end-of-support date, and the operating-environment assumptions the customer must satisfy.
13. Traceability Matrix
A single matrix that maps: security requirement → design element → V&V test → residual risk. Reviewers use this as a navigation index for the whole package — a weak matrix forces them to hunt, which produces deficiencies.
14. Postmarket Cybersecurity Management Plan
Required by Section 524B(b)(1). Cover: SBOM maintenance cadence, vulnerability monitoring sources, patch SLA by severity, customer notification process, and the integration with your CAPA system. This plan is reviewed at premarket but executed postmarket — write it so a different team can run it.
15. eSTAR Section 14 Completeness
For 510(k) and De Novo, the cybersecurity content must be populated in the correct eSTAR fields, with attachments named to match. See eSTAR cybersecurity readiness checklist.
Frequently asked questions
What does the FDA require for cybersecurity in a 510(k)?
Every cyber device under Section 524B(c) requires the 15 deliverables above. The minimum that survives RTA is items 1, 2, 5, 6, 8, 10, 11, and 14; the substantive review will request the rest.
What SBOM format does the FDA prefer?
CycloneDX and SPDX are both acceptable. CycloneDX has better native support for VEX, which most teams find easier; SPDX is more common in OSS ecosystems. Either is fine if machine-readable and complete.
Is penetration testing required for every device?
Yes for every cyber device under Section 524B. The depth scales with risk: a Class II connected monitor needs interface and protocol testing; a Class III implantable with RF telemetry needs RF, firmware, and companion-app testing.
How long does an FDA cybersecurity review take?
See our FDA cybersecurity review timeline. Clean packages add minimal time to the underlying 510(k) clock; deficiency letters stop the clock for the response window.
What triggers an RTA hold for cybersecurity?
Missing SBOM, missing vulnerability management plan, missing pen test report, or a threat model that is a bullet list rather than a diagram-driven analysis. These are the four highest-frequency RTA triggers we see.
How Blue Goat Cyber helps
Unlike software-only solutions, Blue Goat Cyber executes every artifact in this checklist as a service — SBOM, threat model, pen test, and submission packaging — and stays with you through deficiency response. See FDA premarket cybersecurity services.
Sources & primary references
- FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 2026)
- Section 524B of the Federal Food, Drug, and Cosmetic Act
- AAMI SW96:2023 — Standard for medical device security — Security risk management
- IEC 81001-5-1:2021 — Health software and health IT systems safety, effectiveness and security
- NIST SP 800-218 — Secure Software Development Framework (SSDF)
- NTIA, Minimum Elements for a Software Bill of Materials (SBOM)