On this page
Published: · Updated:
Key Takeaways
- The current FDA cybersecurity guidance is the Feb 3, 2026 final, which supersedes the June 2025 and September 2023 finals.
- It treats the SPDF as the framework and anchors expectations to AAMI SW96 and IEC 81001-5-1.
- Machine-readable SBOMs, threat models with trust-boundary coverage, and postmarket vulnerability plans are expected premarket deliverables.
- Postmarket cybersecurity is scoped inside premarket review: the FDA judges the plan before clearance, not just after.
- Missing cybersecurity artifacts can put a submission on hold at the acceptance review stage.
What is the current FDA cybersecurity guidance for medical devices?
The FDA cybersecurity guidance for medical devices is the February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. It supersedes the June 2025 final, which superseded the September 2023 final, and it is the interpretation reviewers apply when they measure a submission against Section 524B of the FD&C Act. In practice it requires a Secure Product Development Framework tied into the QMS, an ANSI/AAMI SW96:2023 security risk file, a threat model, a machine-readable SBOM with VEX, a vulnerability management plan and CVD policy, demonstrated patchability, and interface-scoped penetration testing, filed as clearly named attachments in the single eSTAR v7.0 Cybersecurity attachment area.
What the FDA cybersecurity guidance requires, how Section 524B fits on top of it, what changed across the 2023, 2025, and 2026 versions, and what manufacturers must do now.
Last reviewed: August 2026 · Aligned to the FDA's February 2026 final guidance and Section 524B of the FD&C Act. For what changed this month, see our medical device cybersecurity news roundup.
The FDA's 2026 final guidance - Cybersecurity in Medical Devices: Quality Management 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 and June 2025 final guidance versions, 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.
What manufacturers must do now
The guidance chain moves faster than most submission calendars. If your cybersecurity package was assembled against the September 2023 or June 2025 final, re-baseline it before you file. Here is the sequence we run with sponsors, in the order it pays off.
| # | Action | Why it matters now | Owner |
|---|---|---|---|
| 1 | Confirm whether your device is a "cyber device" under Section 524B(c) | Determines whether an incomplete package is an RTA hold or just a deficiency | Regulatory |
| 2 | Re-baseline documents to QMSR terminology | The QMSR final rule took effect February 2, 2026, replacing 21 CFR Part 820 with ISO 13485:2016 by reference. This is the main reason the guidance title changed | Quality |
| 3 | Map your existing artifacts to the 8 eSTAR v7.0 cybersecurity slots | Reviewers open the slots, not your folder structure. Unmapped evidence reads as missing evidence | Regulatory |
| 4 | Align the security risk file to ANSI/AAMI SW96:2023 | SW96 is the FDA-recognized standard (recognition 13-131). TIR57 sits underneath it as the implementation guide | Security |
| 5 | Refresh the threat model against the current architecture | Threat models built pre-integration miss the interfaces that actually shipped | Engineering |
| 6 | Regenerate the SBOM and attach VEX statements | VEX is now expected alongside the SBOM so reviewers can see which CVEs are not exploitable in your build | Engineering |
| 7 | Re-scope the penetration test to every live interface | Scope gaps between the architecture views and the test report are one of the most common deficiency triggers | Security |
| 8 | Check that the PCCP covers security-relevant changes | PCCPs written only for AI performance retraining leave the security change path unauthorized | Regulatory |
If you file within the next quarter, items 2, 3, and 6 are the ones most likely to generate a deficiency if skipped, because they are version-specific to the February 3, 2026 guidance rather than carried over from 2023.
Two framing points worth keeping straight. Section 524B is binding statute; the guidance is nonbinding but is the operative interpretation reviewers apply, so ignoring it still produces real RTAs. And the guidance is broader than 524B: it reaches devices with cybersecurity considerations generally, including 510(k)-exempt, IDE, BLA, and IND submissions, so cyber devices under 524B(c) are a subset of what the guidance covers.
The 18 deliverables in a 2026-ready cybersecurity submission
A cyber device 510(k), De Novo, or PMA needs 18 cybersecurity deliverables, each tied to a section of the February 3, 2026 guidance and to a field in the eSTAR v7.0 template. Two are required by Section 524B itself and cannot be omitted: the SBOM and the Cybersecurity Management Plan. The other 16 are required in practice. Grouped, they are:
- Risk management: Risk Management Report, Threat Model, Cybersecurity Risk Assessment, and Interoperability Risk Assessment. See our Threat Model Starter.
- Software components: SBOM (CycloneDX or SPDX, machine-readable, NTIA minimum elements), Component Support and End-of-Support, and Assessment of Unresolved Anomalies.
- Design: Security Requirements and Control Coverage (authentication, cryptography, patch and update, logging) and Security Architecture Views (trust boundaries, data flows, interface inventory).
- Testing: Static Application Security Testing, plus the penetration test plan, test cases and test report.
- Metrics: Measures and Metrics.
- Labeling: Cybersecurity Labeling, the MDS2, and Interoperability Labeling.
- Postmarket: Cybersecurity Management Plan, covering vulnerability monitoring, coordinated disclosure and patching.
For each deliverable's guidance section and exact eSTAR field, see our FDA premarket cybersecurity deliverables and eSTAR v7.0 map.
Submissions missing any of these typically draw a deficiency letter and, in some cases, a Refuse to Accept hold.
What is a "cyber device" under Section 524B?
Section 524B applies if all three are true:
- The device contains software validated, installed, or authorized by the sponsor.
- The device has the ability to connect to the internet.
- 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 |
Transition checklist: from the 2023 final to the Feb 3, 2026 final
If your team built a cybersecurity submission package against the February 2026 final guidance and you are now preparing a submission under the Feb 3, 2026 final, these are the deltas reviewers actually flag:
- Re-baseline the security risk file against AAMI SW96:2023. TIR57 alone is no longer the anchor. SW96 is the FDA-recognized standard (recognition number 13-131); TIR57 sits underneath it as the implementation guide.
- Rebuild the submission around eSTAR v7.0's 8 Cybersecurity attachment slots (not the prior free-form structure). See the slot-by-slot mapping in our eSTAR v7.0 Cybersecurity Attachments mapping guide.
- Promote patchability from a design choice to a Section 524B(b)(1) statutory requirement. Reviewers want signed updates, root-of-trust, rollback handling, and a documented time-from-CVE-to-deployed-patch SLA.
- Add VEX statements alongside the SBOM. A bare CycloneDX or SPDX file is no longer enough; reviewers expect a VEX-style "affected / not affected / fixed / under investigation" justification for every High or Critical finding.
- Tighten the CVD policy.
security@mailboxes without an SLA, triage process, and link back to the VMP are now a frequent deficiency. - Cover security-relevant model updates in any PCCP. A Predetermined Change Control Plan that addresses performance retraining but ignores security-relevant changes is incomplete under the 2026 guidance.
- Map AAMI TIR97:2019 to the postmarket plan explicitly. Postmarket sections that cite TIR57 instead of TIR97 misalign with reviewer expectations.
- Scope the pen test to actual interfaces, including hardware. Web/API-only pen tests against a device with BLE, NFC, USB-OTG, OTA, or debug ports draw scope-narrowness deficiencies.
eSTAR v7.0 cybersecurity attachment checklist (8 slots)
The Feb 3, 2026 final guidance is filed in eSTAR v7.0 through eight Cybersecurity attachment slots. A submission missing any of them typically draws an RTA hold within the 15-day window.
| Slot | Attachment | What goes here |
|---|---|---|
| 1 | Cybersecurity Management Plan | Scope, QMS integration, SPDF alignment, postmarket commitments. See the Cybersecurity Management Plan guide. |
| 2 | Security Risk Management | AAMI SW96:2023-aligned risk file, traceable to ISO 14971. |
| 3 | Threat Model | STRIDE enumeration, attack-tree or kill-chain analysis for life-sustaining functions, plus security architecture views (trust boundaries, data flows, interface inventory). |
| 4 | Risk Assessment | Per-threat residual-risk argument with control traceability. |
| 5 | SBOM | CycloneDX 1.5+ or SPDX 2.3+, NTIA minimum elements, PURL/CPE identifiers, plus VEX statements. See SBOM for medical devices. |
| 6 | Security Controls | Authentication, authorization, cryptography, code/data/execution integrity, confidentiality, event detection and logging, resiliency and recovery, updatability. See FDA security control categories. |
| 7 | Testing | SAST/SCA/DAST, fuzz testing, vulnerability scanning, penetration testing scoped to actual interfaces. See FDA cybersecurity testing requirements taxonomy. |
| 8 | Metrics and Unresolved Anomalies | Coverage metrics, VEX-justified unresolved findings, postmarket monitoring KPIs. |
Labeling (MDS2/HSCC), the Vulnerability Management Plan, and the Coordinated Vulnerability Disclosure policy are filed under their own non-Cybersecurity eSTAR sections but are referenced from Slots 1 and 6.
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-131)
- 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 275+ devices, the most common deficiencies are:
- SBOM without VEX statements - components listed, but no analysis of whether known CVEs are exploitable in the device's context.
- Threat model that is not traceable - STRIDE entries with no link to controls, verification evidence, or residual-risk argument.
- Pen test scope too narrow - generic web/API pen test that does not exercise BLE, NFC, USB-OTG, OTA, or hardware debug ports.
- No documented patchability - no signed-update mechanism, or no evidence of the time-from-CVE-to-deployed-patch SLA Section 524B(b)(1) requires.
- CVD policy missing or generic - a
security@mailbox with no SLA, no triage process, and no link back to the VMP. - TIR57 cited alone - no reference to SW96 (the FDA-recognized standard) or TIR97 (postmarket).
- AI/ML PCCP without security coverage - change-control plan that addresses performance updates but ignores security-relevant model changes.
- 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:
- Traceability. Threat → control → requirement → verification evidence → residual-risk rationale, in one auditable thread. SW96 makes this explicit.
- Operability. A postmarket plan that a real team can run, with named owners, SLAs, and tooling - not a paragraph of intent.
- 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.
How Blue Goat Cyber Approaches the 2026 FDA Cybersecurity Guidance
The February 2026 final guidance changed reviewer expectations across every section of the eSTAR - from SBOM depth to postmarket update commitments. We updated our delivery model on the day it dropped. Here is how we run engagements under the new guidance.
- Every artifact traced to the 2026 text. Threat models, SBOMs, SPDF plans, and pen-test reports carry inline citations to the specific guidance paragraphs they satisfy, so reviewers do not have to guess.
- eSTAR v7 mapping baked in. Deliverables are named, formatted, and structured to match the current eSTAR subforms, not the 2023 layout.
- Postmarket teeth. The 2026 guidance made postmarket commitments a first-class deliverable. Every package leaves you with a working monitoring plan, CVD process, and update cadence.
- AI/ML alignment. For devices with learning components we align threat models and PCCPs to the new guidance's AI/ML expectations - the fastest-growing deficiency category in 2026.
- Deficiency-pattern awareness. We track the RTA, AI-letter, and Major deficiency patterns FDA has issued under the new guidance and pre-empt them in the initial submission.
- Senior engineers on every engagement. No junior handoffs. The person building your package is the person defending it if a deficiency arrives.
Our FDA Premarket Cybersecurity Services engagement is the standard entry point.
FAQ
What are the FDA cybersecurity guidelines for medical devices in 2026?
The current FDA cybersecurity guidelines are set by the Feb 3, 2026 final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, layered on top of Section 524B of the FD&C Act. In practice that means: a Secure Product Development Framework (SPDF) tied into the QMS, an AAMI SW96:2023-aligned security risk file, a STRIDE-grade threat model, a CycloneDX or SPDX SBOM with VEX statements, a Vulnerability Management Plan and CVD policy, demonstrable patchability, and an independent penetration test scoped to the actual interfaces. Submissions are filed through eSTAR v7.0 in 8 Cybersecurity attachment slots.
Where can I read the official FDA cybersecurity guidance?
The FDA publishes the full text on its guidance documents site under the title Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. The official FDA page links the PDF. Make sure you are reading the February 3, 2026 version. Many search results still point to the 2023 or 2025 versions, which the FDA has superseded.
When did the FDA's new cybersecurity guidance take effect?
The final guidance was issued on February 3, 2026 and is in force for new premarket submissions today. It supersedes the June 2025 final guidance, which itself superseded the September 2023 final. Sponsors with packages built against either earlier version should re-baseline against the deltas in the transition checklist above before filing.
What's the latest medical device cybersecurity news from the FDA?
The biggest 2026 updates: (1) AAMI SW96:2023 is the FDA-recognized security risk-management standard (recognition number 13-131), with TIR57 underneath as the implementation guide; (2) eSTAR v7.0 (June 1, 2026) keeps cybersecurity in a single attachment area, so sponsors choose how to package the deliverables; (3) VEX statements are now expected alongside the SBOM; (4) PCCPs must cover security-relevant model changes, not just performance retraining; (5) a missing SBOM, VMP, threat model or pen test can stop a submission at the 15-day acceptance review. For ongoing coverage, see our medical device cybersecurity news roundup, the daily Goat Feed, or subscribe to the Blue Goat Pulse.
What is the FDA's 2026 cybersecurity guidance?
It is the final version of Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued in February 2026. It replaces the 2014 guidance and supersedes both the September 2023 and June 2025 finals, 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 (signed December 2022, with FDA RTA authority effective March 2023 and active enforcement beginning October 1, 2023). The 2026 guidance is the FDA's interpretation of how to meet Section 524B's core obligations (postmarket plan, secure design and patchability, SBOM). The guidance is broader than 524B: it covers devices with cybersecurity considerations generally, including ones that are not "cyber devices" under the statute (such as 510(k)-exempt devices, IDE, BLA, and IND submissions). Cyber devices under 524B are a subset of the devices the guidance covers. For how device cybersecurity content lands in a BLA or IND for combination products, see combination products in the FDA pathway cybersecurity guide.
Did the February 3, 2026 version change what 524B requires?
No. The substantive 524B obligations are unchanged from the September 2023 and June 2025 versions. The February 3, 2026 update is mainly alignment to QMSR: the QMSR final rule took effect February 2, 2026, replacing the old Quality System Regulation in 21 CFR Part 820 with ISO 13485:2016 incorporated by reference, which is why the guidance title shifted from "Quality System Considerations" to "Quality Management System Considerations." The 524B requirements, the SPDF expectation, the SBOM format, and the architecture-views structure carry through. New submissions should reference QMSR terminology and the Feb 3, 2026 guidance.
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: SBOM for Medical Devices
- Postmarket plan: Postmarket Cybersecurity Readiness Plan
- Service: FDA Premarket Cybersecurity Services
- Service: FDA Cybersecurity Deficiency Response
- Premarket Cybersecurity Deliverables to eSTAR Map - which guidance artifact lands in which eSTAR section.
- Premarket FDA Cybersecurity Submission Checklist - turn the guidance into a packing list.
Primary FDA sources
- Cybersecurity in Medical Devices: Quality Management 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)
Sources & references
Primary sources cited in this article. Links open in a new tab.
