Understanding FDA's Feb 2026 Cybersecurity Guidance: A Plain-English Guide

If you're a regulatory affairs lead at a medical device company, you have a tab open right now to FDA's premarket cybersecurity guidance. You probably bookmarked it sometime in 2025. And there's a meaningful chance the version you have bookmarked is no longer current.

On February 3, 2026, the FDA reissued the guidance document titled "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions". It superseded the June 27, 2025 version that the industry had been treating as the bible for the previous eight months. The change wasn't loud. There was no major press release. Manufacturers who weren't paying attention can be forgiven for assuming the June 2025 document still applies.

It doesn't. And while most of the substantive cybersecurity requirements are unchanged, the document title, its regulatory anchor, and several specific references have shifted enough that a Threat Model citing the June 2025 guidance can look subtly stale to an FDA reviewer in 2026.

This post is for the people who don't have time to read 70 pages of FDA guidance from scratch. Here's what you actually need to know.

Why the FDA reissued the guidance

The answer is one acronym: QMSR.

For about 30 years, medical device manufacturers in the US complied with the Quality System Regulation, 21 CFR Part 820. On February 2, 2026, that regulation was replaced by the Quality Management System Regulation — same citation (21 CFR Part 820) but with the international standard ISO 13485:2016 incorporated by reference. In practical terms, the FDA now uses ISO 13485 as the baseline for what a medical device quality system looks like, with a few US-specific additions on top.

This was a long-telegraphed change. The FDA published the final QMSR rule in early 2024 and gave the industry two years to prepare. February 2, 2026 was the deadline. On that date, the older QSR documents — including the FDA's Quality System Inspection Technique (QSIT) — were retired and replaced with the new Inspection of Medical Device Manufacturers Compliance Program 7382.850.

The cybersecurity guidance, which referenced "Quality System" in its very title and cited 21 CFR Part 820's older provisions throughout, needed to align. So FDA reissued it one day after QMSR went into effect.

The substantive cybersecurity requirements didn't change. What changed is how those requirements are anchored in the broader quality system framework that manufacturers must comply with.

What stayed the same (the part that matters most)

If you've been working from the June 2025 guidance, here's the good news: your Secure Product Development Framework, Threat Models, SBOM strategy, and Cybersecurity Management Plan don't need to be thrown out. The technical substance is identical.

Specifically, all of the following remain unchanged:

• The definition of a "cyber device" under Section 524B of the FD&C Act — a device that 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.
• The expectation that manufacturers implement a Secure Product Development Framework (SPDF) covering security risk management, security architecture, and cybersecurity testing across the device lifecycle.
• The mandatory documentation expected in premarket submissions for cyber devices — approximately 12 distinct documents covering security risk management, threat modeling, SBOM, architecture views, security testing reports, and a cybersecurity management plan.
• The SBOM requirements, including alignment with NTIA Minimum Elements and machine-readable formats like SPDX or CycloneDX.
• The expectation of postmarket cybersecurity activities — vulnerability monitoring, coordinated vulnerability disclosure (CVD), and patch management — as a continuous obligation tied to the device's commercial lifetime.

If you have these elements documented and aligned with the June 2025 guidance, you're 95% of the way to alignment with February 2026.

What changed (the references and the framing)

The remaining 5% is in how the document anchors itself in the broader regulatory landscape. Three categories of change matter:

1. Title change

The old title was "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions."

The new title is "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions."

One word added. But that word — Management — signals the shift from QSR to QMSR. If your internal documentation cites the old title, update it.

2. References to 21 CFR Part 820 now imply ISO 13485:2016

The guidance still cites 21 CFR Part 820 throughout. The citation itself is unchanged. But what's inside 21 CFR Part 820 changed materially on February 2, 2026 — it now incorporates ISO 13485:2016 by reference. When you read a 2026 FDA document referencing 21 CFR Part 820, the underlying substance you're being held to is now ISO 13485-shaped.

For manufacturers that already align with ISO 13485 (most do, especially those selling in EU markets), this is a clarification. For manufacturers operating only under the old US framework, it's a meaningful homework assignment in adopting ISO 13485 documentation conventions.

3. AAMI SW96 enters the conversation

The Feb 2026 guidance more prominently references ANSI/AAMI SW96, a relatively new standard (published in 2025) covering security risk management for medical device products. Where the June 2025 guidance pointed primarily to AAMI TIR57 for security risk management methodology, the Feb 2026 version weaves SW96 into the conversation alongside it.

In practical terms: if you built your security risk management process using only TIR57 as a reference, you're not out of compliance — TIR57 remains valid. But the increasing prominence of SW96 in FDA's expectations suggests that, over the next 12-24 months, the more mature programs will incorporate both.

What "cyber device" actually means

One of the most common questions Omakyn hears from early-stage medtechs is: "Does my product even need to comply with Section 524B?"

The answer comes down to three criteria from the statutory definition. A device is a cyber device, and therefore subject to Section 524B's mandatory cybersecurity requirements, if it meets all three:

1. It includes software validated, installed, or authorized by the sponsor as a device or in a device.
2. It has the ability to connect to the internet, whether wirelessly, through ethernet, or through any other network protocol.
3. It contains technological characteristics (including those of any device added to the device through a software update or upgrade) that could be vulnerable to cybersecurity threats.

The third criterion is doing a lot of work. In practice, almost any internet-connected medical device with software meets it — vulnerability is the default state of connected software, not an exceptional condition. FDA reviewers interpret this broadly.

What's not a cyber device? A purely mechanical device with no software. A standalone surgical instrument. A diagnostic strip. Most Class I devices. Anything that physically cannot connect to a network, even theoretically.

If your device has even Bluetooth Low Energy connectivity to a paired mobile app, you're almost certainly within scope.

The 12 documents you'll need in your submission

For any premarket submission for a cyber device — whether 510(k), De Novo, or PMA — FDA expects approximately 12 distinct cybersecurity-related deliverables. The exact count depends on device complexity, but the canonical list includes:

• Cybersecurity Management Plan — the overarching strategy document
• Threat Model — analysis of attack surfaces, threats, and mitigations
• Cybersecurity Risk Assessment — formal risk analysis per AAMI TIR57 / SW96
• SBOM (Software Bill of Materials) — machine-readable, NTIA-aligned
• Architecture Views — global, multi-patient, updateability, and security use case views
• Cybersecurity Risk Management Report — summary of identified and mitigated risks
• Penetration Test Report — third-party or internal pen test results
• Static and Dynamic Application Security Testing (SAST/DAST) Reports
• Vulnerability Communication Plan — coordinated vulnerability disclosure (CVD) process
• Software Update / Patch Strategy — postmarket maintenance approach
• Cybersecurity Labeling — disclosures to end users and operators
• Cybersecurity Bill of Materials Lifecycle Plan — how the SBOM is maintained over time

Each of these has expectations about depth, format, and traceability. The most common reason for an RTA (Refuse to Accept) decision in 2024-2025 was missing or inadequate SBOM documentation — recent reporting suggests roughly 15% of 510(k) submissions hit a Technical Screening hold for SBOM issues since FDA started requiring them in October 2023.

What you should do this week

If you're a manufacturer with an active submission in flight, or a submission planned in the next 6 months, here's a practical checklist:

1. Update internal references. Anywhere your documentation cites the June 27, 2025 guidance, update to Feb 3, 2026. Anywhere it says "Quality System Considerations" in the cybersecurity guidance title, update to "Quality Management System Considerations."
2. Verify your QMS aligns with ISO 13485:2016. If you've been operating under the old QSR conventions, identify the gaps between your current QMS and ISO 13485 and address them before your next FDA interaction.
3. Audit your SBOM. Confirm it's machine-readable (SPDX or CycloneDX), covers all software components including OSS and commercial third-party, and meets NTIA Minimum Elements.
4. Review your Threat Model for completeness against the four required architecture views: global, multi-patient harm, updateability, and security use cases.
5. Check that your Cybersecurity Management Plan addresses postmarket obligations, not just premarket. Section 524B requires a documented plan for continuous monitoring and CVD throughout the device's commercial lifetime.
6. If you're working with consultants or vendors, ask them explicitly whether their materials reference the Feb 2026 guidance or the older June 2025 guidance. A surprising number of vendor materials in circulation still reference the older version.

The bottom line

The FDA's February 3, 2026 reissue is not a substantive policy change. The cybersecurity expectations are the same as they were in June 2025. What changed is the framing: the cybersecurity guidance now lives inside a Quality Management System framework rather than the older Quality System framework, and that reframing has implications for how you cite, document, and reference your compliance work.

For most manufacturers, this means small but real updates to existing documentation, not a complete overhaul. For manufacturers that hadn't yet developed their cybersecurity program, it means starting fresh with the current document rather than the superseded one. And for everyone, it's a reminder that FDA guidance is a living target — the current version on the FDA website is the one that controls, regardless of what version your team last read.