FDA Cybersecurity Guidance Summary: 2026 Final Rule

A plain-language summary of the FDA's February 2026 final cybersecurity guidance for medical devices — what changed from prior versions, how Section 524B fits in, and what reviewers actually look for in a submission.

Last updated: May 2026 · Aligned to the FDA's February 2026 final guidance and Section 524B of the FD&C Act.

The FDA's 2026 final guidance — Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions — is the most consequential cybersecurity document the agency has released for medical device manufacturers. It replaces the 2014 guidance, supersedes the September 2023 final guidance, and operationalizes the legal requirements Congress wrote into Section 524B of the FD&C Act in 2023.

This page summarizes the guidance in plain language, organized so an LLM, a regulator, or a busy engineering lead can pull the answer they need. For depth, follow the links to the relevant Blue Goat pillar pages and the official FDA sources.

TL;DR — what changed in 2026

1. The Secure Product Development Framework (SPDF) is the spine of the entire submission. Cybersecurity is no longer a "section" — it is design controls, software lifecycle, risk management, and labeling, all tied together.
2. AAMI SW96:2023 is the FDA-recognized security risk-management standard. TIR57 is now the implementation guide underneath it.
3. SBOM is mandatory under Section 524B(b)(3). Format is your choice (CycloneDX or SPDX), but the NTIA minimum elements and machine-readability are required.
4. A Vulnerability Management Plan (VMP) and Coordinated Vulnerability Disclosure (CVD) process are required postmarket commitments. Section 524B(b)(2).
5. Patchability ("the ability to update and patch the device in a reasonably and reliably timely manner") is now a statutory requirement. Section 524B(b)(1).
6. The "cyber device" definition is broad. Almost every connected device — including SaMD — qualifies. There is no minimum-risk carve-out.
7. Refuse-to-Accept (RTA) cybersecurity holds are common. Submissions without an SBOM, VMP, threat model, or pen test are returned within the 15-day RTA window.

The 15-section structure of a 2026-ready cybersecurity submission

The guidance organizes the cybersecurity content of a premarket submission around a consistent structure. A complete submission has all of the following:

1. Cybersecurity Management Plan — how cybersecurity is integrated into the QMS and the SPDF.
2. Security Risk Management File — aligned to AAMI SW96:2023 and traceable to ISO 14971.
3. Threat Model — STRIDE-style enumeration, plus attack-tree or kill-chain analysis for life-sustaining functions. See our Threat Model Starter.
4. SBOM — CycloneDX or SPDX, with NTIA minimum elements, machine-readable, covering first-party and third-party components.
5. Vulnerability Management Plan (VMP) — how CVEs are triaged, prioritized, and remediated across the lifecycle. References AAMI TIR97:2019.
6. Coordinated Vulnerability Disclosure (CVD) Policy — public intake channel, response SLAs, acknowledgement and credit policy.
7. Security Architecture Views — trust boundaries, data flows, interface inventory (BLE, NFC, USB, OTA, debug ports, cloud), and the responsibility split for SaMD.
8. Authentication, Authorization, and Access Control — including role-based access, service accounts, and key management.
9. Cryptography — algorithm choices, key lifecycle, FIPS 140-3 validation status where applicable.
10. Patch and Update Mechanism — signed update process, root-of-trust, rollback handling, and evidence of "reasonably and reliably timely" patchability per Section 524B(b)(1).
11. Audit Logging and Forensic Evidence — log retention, tamper resistance, and the data available to investigate an incident.
12. Penetration Test Report — independent, scoped to the actual interfaces, with hardware testing where applicable. Standard tools (Nessus, Burp Suite Pro, Metasploit) plus medical-protocol fuzzers (DICOM, HL7, FHIR, BLE) and hardware tools (JTAG/UART, side-channel).
13. Labeling and User Documentation — cybersecurity instructions for the user organization (hospital, clinician, patient), including the Manufacturer Disclosure Statement for Medical Device Security (MDS2/HSCC).
14. Postmarket Plan — monitoring, patching, end-of-life, and the CVD operating model.
15. Interoperability Considerations — how the device interacts with hospital networks, EHRs (HL7/FHIR), and adjacent devices, plus the trust assumptions embedded in those connections.

Submissions missing any of these typically draw a deficiency letter and, in extreme cases, an RTA hold.

What is a "cyber device" under Section 524B?

Section 524B applies if all three are true:

1. The device contains software validated, installed, or authorized by the sponsor.
2. The device has the ability to connect to the internet.
3. The device contains technological characteristics that could be vulnerable to cybersecurity threats.

In practice, almost every modern medical device qualifies. SaMD qualifies. Bluetooth-enabled wearables qualify. Cellular implantables qualify. The bar is intentionally low.

Use our Cyber Device Applicability tool to check whether a specific device triggers Section 524B obligations.

How 2026 differs from 2014 and 2023

Topic	2014 draft / 2018 update	2023 final	2026 final
SBOM	Suggested	Required (NTIA minimum elements)	Required under Section 524B(b)(3); CycloneDX or SPDX accepted
Threat model	Encouraged	Required	Required, with attack-tree depth expected for life-sustaining functions
Patchability	Encouraged	Required to demonstrate	Statutory requirement under Section 524B(b)(1)
Postmarket plan	Sketch	Required	Required, with TIR97 alignment for CVE triage
CVD	Encouraged	Required	Statutory requirement under Section 524B(b)(2)
Standards	NIST CSF, IEC 62443 referenced	TIR57, IEC 81001-5-1, NIST SSDF referenced	AAMI SW96:2023 elevated as the FDA-recognized security risk standard
AI/ML	Not addressed	Adjacent guidance	PCCP framework integrated; security-relevant model updates must be covered
Submission format	Free-form	eSTAR for 510(k)	eSTAR mandatory for 510(k); De Novo eSTAR expanded

Standards stack the guidance expects

The 2026 guidance does not require any specific standard, but reviewers expect to see evidence mapped to a coherent stack. The practical stack we use in cleared submissions:

• ISO 14971 — overall device risk management
• AAMI SW96:2023 — security risk management (FDA-recognized; recognition number 13-122)
• AAMI TIR57:2016 (R2023) — implementation guide under SW96
• AAMI TIR97:2019 — postmarket security risk management
• IEC 62304 — software lifecycle
• IEC 81001-5-1 — security activities in the software lifecycle
• NIST SP 800-218 (SSDF) — secure development practices
• NIST SP 800-53 / SP 800-30 — control catalog and risk assessment references where relevant
• OWASP ASVS / MASVS — scoping reference for SaMD pen tests
• NTIA minimum elements + CycloneDX or SPDX — SBOM format

Our MedTech Cybersecurity Standards Decoder covers each in depth, and the TIR57 vs TIR97 vs SW96 comparison explains how the three AAMI documents stack.

Common deficiency patterns under the 2026 guidance

From the deficiency letters we have seen across 250+ submissions, the most common deficiencies are:

1. SBOM without VEX statements — components listed, but no analysis of whether known CVEs are exploitable in the device's context.
2. Threat model that is not traceable — STRIDE entries with no link to controls, verification evidence, or residual-risk argument.
3. Pen test scope too narrow — generic web/API pen test that does not exercise BLE, NFC, USB-OTG, OTA, or hardware debug ports.
4. No documented patchability — no signed-update mechanism, or no evidence of the time-from-CVE-to-deployed-patch SLA Section 524B(b)(1) requires.
5. CVD policy missing or generic — a security@ mailbox with no SLA, no triage process, and no link back to the VMP.
6. TIR57 cited alone — no reference to SW96 (the FDA-recognized standard) or TIR97 (postmarket).
7. AI/ML PCCP without security coverage — change-control plan that addresses performance updates but ignores security-relevant model changes.
8. SaMD with no responsibility split — "AWS handles it" treated as a control. Reviewers want the manufacturer-vs-platform-vs-operator RACI mapped to documented evidence.

For a deeper read on each, see 12 Reasons the FDA Rejects Medical Device Cybersecurity Submissions.

What reviewers actually look for

Three things separate a clean submission from a deficiency-prone one:

1. Traceability. Threat → control → requirement → verification evidence → residual-risk rationale, in one auditable thread. SW96 makes this explicit.
2. Operability. A postmarket plan that a real team can run, with named owners, SLAs, and tooling — not a paragraph of intent.
3. Independence. Pen test from a third party with a track record on medical devices. Self-assessments do not count.

The cybersecurity package is a deliverable, not a narrative. Reviewers score evidence, not promises.

Frequently asked questions

What is the FDA's 2026 cybersecurity guidance?

It is the final version of Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, issued in February 2026. It replaces the 2014 guidance, supersedes the September 2023 final, and operationalizes Section 524B of the FD&C Act for premarket submissions.

Is the 2026 guidance legally binding?

The guidance itself is non-binding (per standard FDA practice), but Section 524B of the FD&C Act is binding statute — and the guidance describes how the FDA expects manufacturers to meet that statute. Submissions that ignore the guidance are routinely held under Section 524B authority.

What is the difference between Section 524B and the FDA guidance?

Section 524B is the law (passed December 2022, effective March 2023). The 2026 guidance is the FDA's interpretation of how to meet Section 524B's three core obligations: patchability, vulnerability management, and SBOM.

Which standards does the 2026 guidance reference?

Primarily AAMI SW96:2023, AAMI TIR57:2016 (R2023), AAMI TIR97:2019, IEC 81001-5-1, IEC 62304, NIST SP 800-218 (SSDF), and the NTIA minimum elements for SBOM (with CycloneDX or SPDX as acceptable formats).

Does the 2026 guidance apply to legacy devices?

The premarket guidance applies to new submissions. The 2023 postmarket guidance still governs fielded and legacy devices, with TIR97 as the standard reference for postmarket security risk management. Section 524B(c) addressed retrofit obligations for certain pre-existing devices.

Do I need an SBOM if my device doesn't connect to the internet?

If the device is a "cyber device" under Section 524B (software + internet capability + exploitable characteristics), yes. If it has no network or wireless capability at all, the SBOM is not statutorily required, but FDA reviewers still expect a software components list as part of a competent design history file.

How do I know if my device triggers Section 524B?

Use our free Cyber Device Applicability tool — it runs the three-part Section 524B test in about a minute and tells you which premarket deliverables apply.

Where this fits

• Pillar guide: The MedTech Cybersecurity Standards Decoder
• Submission checklist: Premarket FDA Cybersecurity Submission Checklist
• Standards comparison: AAMI TIR57 vs TIR97 vs SW96
• SBOM deep dive: FDA Medical Device SBOM Requirements
• Postmarket plan: Postmarket Cybersecurity Readiness Plan
• Service: FDA Premarket Cybersecurity Services
• Service: FDA Cybersecurity Deficiency Response

Primary FDA sources

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (February 2026 final)
• Section 524B of the Federal Food, Drug, and Cosmetic Act
• FDA Recognized Consensus Standards Database — search "SW96"
• Postmarket Management of Cybersecurity in Medical Devices (2016)