Premarket FDA Cybersecurity Checklist

The FDA no longer treats medical device cybersecurity as supplementary paperwork. Since Refuse-to-Accept (RTA) enforcement of Section 524B began on October 1, 2023, and the February 3, 2026 final premarket cybersecurity guidance took effect, reviewers apply the same rigor to your Security Risk Report that they apply to your bench testing.

Teams that clear on the first pass do one thing consistently: they treat every checklist item as evidence, not narrative. This guide walks through the exact deliverables a reviewer expects, in the order the FDA reads them.

Table of Contents

• Does Section 524B apply to your device?
• Why the 2026 checklist looks different
• Secure Product Development Framework (SPDF)
• Threat model and cybersecurity risk assessment
• SBOM and third-party component management
• Verification and cybersecurity testing evidence
• Labeling, transparency, and postmarket plans
• How Blue Goat Cyber approaches the premarket checklist

Why this matters

Section 524B of the FD&C Act was signed into law on December 29, 2022 and took effect on March 29, 2023. The FDA held off on active Refuse-to-Accept enforcement until October 1, 2023, and now routinely returns submissions that lack any of the statutory cybersecurity elements. The controlling document reviewers apply is the FDA's February 3, 2026 final premarket cybersecurity guidance, which supersedes the June 2025 final and the September 2023 final. Applicable consensus standards include ANSI/AAMI SW96 (medical device security risk management), AAMI TIR57 (principles for medical device security risk management), ISO 14971 (medical device risk management), and IEC 81001-5-1 (health software security lifecycle activities). Missing evidence in any one area is enough to delay clearance by a full review cycle.

Does Section 524B apply to your device?

Section 524B(a) of the FD&C Act applies to devices submitted under 510(k), De Novo, PMA, PDP, or HDE, provided the device is a "cyber device" as defined in Section 524B(c): it contains software, has the ability to connect to the internet or another network or device, and has technological characteristics that could be vulnerable to a cybersecurity threat.

Investigational Device Exemptions (IDEs) are governed by Section 520(g) and are not a 524B(a) pathway. Cybersecurity expectations still apply to IDE devices under the February 3, 2026 premarket guidance; do not describe an IDE as a "524B submission."

Software as a Medical Device and cloud components

SaMD running on commercial mobile hardware or cloud infrastructure is not exempt. The FDA treats companion apps, APIs, backend services, and cloud datastores as part of the device system boundary. Every endpoint, transit path, and stored artifact must appear in the threat model and the security architecture views.

Why the 2026 checklist looks different

Three things changed the checklist for submissions filed in 2026:

1. The February 3, 2026 final premarket cybersecurity guidance now specifies the level of detail expected for Security Architecture Views (global system view, multi-patient harm view, updateability view, and security use case views).
2. The QMSR final rule became effective on February 2, 2026, replacing the Quality System Regulation with ISO 13485:2016 requirements. That is why the guidance title now reads "Quality Management System" rather than "Quality System."
3. FDA reviewers now treat a PDF SBOM as a Major deficiency by default. Machine-readable CycloneDX or SPDX is the expected format.

Secure Product Development Framework (SPDF)

The FDA expects the entire submission to sit inside a documented Secure Product Development Framework. An SPDF is not a certificate or a single tool: it is a set of processes that identify, assess, and mitigate security vulnerabilities across the product lifecycle.

Identity products like DigiCert deliver one control (device identity and code signing via PKI). PKI is important, but it is not an SPDF. Your dossier must show that cybersecurity was a design input from the first requirements review through postmarket surveillance.

Threat model and cybersecurity risk assessment

The threat model is the foundational document of the entire cybersecurity submission. Reviewers open it before anything else.

The FDA recommends a structured methodology such as STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Whichever methodology you use, the model must:

• Enumerate every asset, interface, trust boundary, and data flow.
• Map identified threats to CIA (confidentiality, integrity, availability) and to patient-safety impact.
• Link each threat to a specific engineering mitigation and to the verification test that proves the mitigation works.
• Feed a cybersecurity risk assessment that is separate from, and reconciled with, the ISO 14971 safety risk file.

System boundaries and data flows

Data Flow Diagrams (DFDs) must show trust boundaries, external interfaces, data stores, and processes at a level of detail a reviewer can independently reason about. A single "cloud" cloud icon is not enough; enumerate the API gateway, auth service, application tier, and datastore, and mark the transport protocol on each edge.

From threats to documented mitigations

Every threat needs a traceable mitigation. A defensible entry looks like:

Threat:      T-014 Spoofed firmware image installed via USB service port
Asset:       Bootloader / application firmware partition
Impact:      Safety (patient harm) + Integrity + Availability
Mitigation:  ECDSA P-256 signature verification in bootloader (REQ-SEC-041)
Verified by: VER-SEC-041 (bench test) + PEN-2026-03 finding closure
Residual:    Low (accepted; documented in Security Risk Report Section 7)

SBOM and third-party component management

Section 524B(b)(3) requires a Software Bill of Materials. Under the 2026 guidance, that SBOM must be machine-readable in CycloneDX or SPDX format and cover commercial, open-source, and custom code, including transitive dependencies.

Each component entry must include, at minimum: component name, version, supplier, unique identifier (CPE, SWID, or purl), cryptographic hash, license, and relationship (direct or transitive).

See also: FDA AI Cybersecurity Threats: 7 Attacks 524B Manufacturers Must Address, FDA IDE Cybersecurity Requirements: 2026 Submission Guide, and MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns.

Every component must be paired with a vulnerability assessment. For every known CVE, document the CVSS score, an exploitability analysis specific to your device, and a remediation plan or a VEX (Vulnerability Exploitability eXchange) justification explaining why the CVE does not apply.

A minimal CycloneDX component entry:

{
  "group": "org.openssl",
  "name": "openssl",
  "version": "3.0.8",
  "purl": "pkg:generic/openssl@3.0.8?arch=arm32",
  "hashes": [{ "alg": "SHA-256", "content": "b93e1e28..." }],
  "licenses": [{ "license": { "id": "Apache-2.0" } }],
  "externalReferences": [
    { "type": "vulnerability-assertion", "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0286" }
  ]
}

Verification and cybersecurity testing evidence

Claims like "data is encrypted" or "the API is authenticated" are not evidence. The FDA expects four categories of testing artifacts:

Test category	What it proves	Common artifact
Vulnerability scanning	Known-CVE hygiene across libraries and OS/kernel	Tool output plus triage notes
SAST / DAST	Secure coding practices, no hardcoded secrets or unsafe patterns	Report with issues, severity, and closure evidence
Boundary and robustness (fuzzing)	Device stays in a safe state under malformed input	Protocol fuzz reports (BLE, USB, DICOM, HL7)
Penetration testing	Layered defenses hold up against a skilled attacker	Independent pentest report with re-test closure

Aligning penetration testing to reviewer expectations

Automated vulnerability scanner PDFs are not penetration testing. A pentest report the FDA accepts:

• Is executed by independent, credentialed testers with medical device experience.
• Covers the physical device, firmware, companion apps, cloud backend, and wireless protocols in scope (BLE, Zigbee, DICOM, HL7, MQTT, and any custom RF).
• Documents methodology, exploitation steps with reproducible commands, CVSS impact, and evidence of successful re-test after remediation.
• Is dated close enough to the submission that the tested build matches the device to be marketed.

See our guide on the cost of medical device penetration testing for how scope drives price.

Labeling, transparency, and postmarket plans

Section 524B(b)(2) requires a postmarket cybersecurity management plan. Reviewers want to see three things:

1. Secure update mechanism. Signed firmware (ECDSA or RSA), anti-rollback, and authenticated update transport. Cover how you rotate signing keys and how a lost key is recovered.
2. Cybersecurity labeling. Instructions for hospital IT and clinical users covering connectivity features, ports, secure configuration, patch installation, and backup and recovery after an incident.
3. Coordinated Vulnerability Disclosure (CVD). A public, crawlable intake channel (commonly /security or /.well-known/security.txt), documented acknowledgement and triage timelines, and coordination with CISA and the FDA.

See our post on cybersecurity labeling, the key to transparency and accountability in medical device security for the label content the FDA scores.

Inline CTA

Working on a submission right now? Download the FDA 2026 Premarket Cybersecurity Decoder for a side-by-side of the statute, the guidance, and the eSTAR fields each deliverable maps to.

How Blue Goat Cyber approaches the premarket checklist

Our team writes the six deliverables the FDA scores: the threat model, the cybersecurity risk assessment, the CycloneDX SBOM with VEX, the independent penetration test report, the cybersecurity labeling, and the postmarket plan. Every artifact is written to the language of the February 3, 2026 guidance and reconciled with your ISO 14971 safety risk file so the two do not contradict each other. Christian Espinosa (CISSP, OSCP, former Air Force cyber red team) leads the technical reviews. See our medical device penetration testing and FDA cybersecurity submission services. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

FAQ

What is a cyber device under FDA Section 524B?

A cyber device, defined in Section 524B(c), is any device that contains software validated, installed, or authorized by the sponsor; has the ability to connect to the internet or another network or device; and has technological characteristics that could be vulnerable to a cybersecurity threat. If all three apply, the statute applies.

Does Section 524B apply to an IDE submission?

No. Section 524B(a) enumerates 510(k), De Novo, PMA, PDP, and HDE. IDE submissions are governed by Section 520(g) and are outside the 524B(a) statute. The FDA still expects cybersecurity evidence for IDE devices under the February 3, 2026 premarket guidance; call it a guidance expectation, not a 524B(a) requirement.

Is a PDF SBOM acceptable for the FDA?

No. The February 3, 2026 final guidance expects a machine-readable SBOM in CycloneDX or SPDX format. A PDF rendering is one of the most commonly cited Major deficiencies. Submit the JSON file alongside the human-readable summary.

Does an automated vulnerability scan count as penetration testing?

No. The FDA distinguishes vulnerability scanning from penetration testing. Scanning finds known-CVE hygiene issues; penetration testing proves that combined controls resist a skilled attacker chaining exploits across the device, its apps, and its cloud. Both are required.

Where should we host our Coordinated Vulnerability Disclosure policy?

At a stable, crawlable URL on your corporate site, typically /security or /.well-known/security.txt. Reviewers and security researchers both expect to reach it without authentication. Include an intake channel, acknowledgement window, and coordination language for CISA and the FDA.

How long does it take to build the full submission dossier?

For a device with a well-scoped architecture, a threat model plus risk assessment takes four to six weeks; SBOM and VEX generation takes two to three weeks in parallel with development; independent pentesting takes three to five weeks depending on scope. Building the dossier in parallel with design freeze is the difference between a first-pass clearance and a review cycle spent responding to deficiencies.

Ready to pre-flight your submission?

Book a submission readiness review with Blue Goat Cyber. We audit your dossier against the February 3, 2026 guidance and flag every gap a reviewer will find, before you file. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a call.

About the author

Christian Espinosa, CISSP, OSCP, Founder of Blue Goat Cyber. Christian's team focuses exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.