FDA's 3rd Cybersecurity Guidance in 3 Years: What Actually Changed?

On Tuesday, February 3, FDA dropped a new cybersecurity guidance. The third one in three years.

When I saw the announcement, my first thought was "great, there goes my weekend." Three guidances in three years? That sounds like a moving target. It sounds like FDA keeps changing the rules.

But then I read it. And honestly? Not much changed.

FDA basically did a Ctrl+F: "QSR," Replace with: "QMSR." OK, maybe not quite that limited. But close.

Three Guidances, One Timeline

Here's how we got here (our book chapter on the evolution of FDA cybersecurity requirements traces the longer arc):

• September 2023 brought the first final guidance written for Section 524B, since superseded. This was the big one. New law, new expectations, a full cybersecurity documentation package in every premarket submission. Everyone scrambled.
• June 2025 brought the first update, which replaced the 2023 version. Plenty of tracked changes, most of them clarifications. The documentation list didn't move.
• February 3, 2026 is what we're talking about now. FDA released this the day after the QMSR took effect on February 2. The timing tells you everything you need to know about what changed.

What Actually Changed

Most of the old Quality System Regulation (QSR) text in 21 CFR Part 820 is gone. Part 820 was amended and renamed the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference.

The cybersecurity guidance had to reflect that. So FDA updated the references. QSR became QMSR. Quality system language now points to ISO 13485 subclauses: 7.1 for risk management, 7.3 for design and development, 7.3.6 and 7.3.7 for verification and validation, 8.4 and 8.5 for data analysis and improvement.

That's... pretty much it for the cybersecurity-specific content.

If you were already aligned with ISO 13485 (and most companies selling internationally were), you're in good shape. If your quality system was built entirely around old Part 820 language, you have a bigger project on your hands. But that project is a QMSR transition project, not a cybersecurity project.

What didn't change: the documentation list

This is the part that matters. The cybersecurity documentation FDA expects in your premarket submission is the same as in the superseded versions. Appendix 4 Table 1 lists six documentation types broken into fourteen elements, and every one carries forward. Our book chapter on understanding eSTAR requirements covers how they fit into the submission.

Cybersecurity Risk Management Report (Section V.A). Your complete security risk management output. The guidance calls security risk management "distinct but connected" to ISO 14971 safety risk management, and points to AAMI TIR57 and ANSI/AAMI SW96 for the plan and report. Not a copy of your safety risk file with "cyber" pasted in. The report holds six elements:

• Threat Model (V.A.1). Who would attack your device, why, and how? This needs to be specific to your architecture, your data flows, your deployment environment. Generic threat models get kicked back.
• Cybersecurity Risk Assessment (V.A.2). Distinct from the threat model. This is where you score exploitability and impact, not probability, before and after mitigation, against documented acceptance criteria. FDA's postmarket guidance points to CVSS for scoring, and the MITRE rubric adapts it for devices.
• SBOM (V.A.4). Every software component, with the NTIA minimum elements, in a machine-readable format. This is the one that trips up companies the most because it requires knowing exactly what's in your software stack. All of it.
• Vulnerability Assessment and Software Support (V.A.4(b)). For each component, the level of support from its maintainer and the end-of-support date. For each known vulnerability, how you found it, a safety and security risk assessment, and the controls that address it.
• Unresolved Anomalies Assessment (V.A.5). Bugs happen. Some ship with the product. FDA wants to see that you've evaluated every known anomaly for cybersecurity implications and made a deliberate decision about each one.
• Traceability. The identifiers that connect the threat model, the risk assessment, the SBOM, and the test evidence.

Measures and Metrics (V.A.6). Three measures, when available: the percentage of identified vulnerabilities patched, the time from identification to patch, and the time from patch availability to field deployment. Pick metrics that tell you something and say how you track them.

Architecture Views (V.B). Two elements. The security requirements and acceptance criteria for each of the eight control categories in Appendix 1, from authentication to updatability. And the views themselves: Global System, Multi-Patient Harm, Updatability and Patchability, and Security Use Case Views, showing data flows, trust boundaries, external interfaces, and where your controls sit. FDA reviewers need to see the whole picture, not just a list of features. Interoperability risks (V.A.3) show up here and in the risk assessment.

Testing (V.C). Penetration testing, fuzz testing, static analysis (SAST), dynamic analysis (DAST), threat mitigation testing against each view. Show your work. Include the results, not just a statement that testing was performed.

Labeling (VI.A). What do users need to know about your device's cybersecurity? Network ports and requirements, supported configurations, hardening instructions, how to get updates, end-of-support dates.

Cybersecurity Management Plans (VI.B). Your post-market plan. How will you monitor for new vulnerabilities? How will you handle coordinated vulnerability disclosure? What's your patch cadence? For cyber devices, this plan is required by Section 524B(b)(1).

That's the list. Same list as the superseded 2025 version. Same list today.

The QMSR Transition Matters (Just Not Here)

I don't want to undersell the QMSR change. It's a big deal for your quality system. ISO 13485 becoming the law of the land in the US changes how you structure your design history files, how purchasing controls work, how you handle document control.

But for your cybersecurity submission? The practical impact is limited. Your documents still need to exist. They still need the same content. The difference is that they now sit within an ISO 13485 quality management framework instead of the old Part 820 framework. If your QMS was already dual-tracked for international markets, this is almost a non-event.

What You Should Do

Check your references. Open your cybersecurity SOPs, templates, and procedures. If they say "QSR" or "21 CFR Part 820," update them to reference the QMSR and ISO 13485:2016. This is a find-and-replace exercise.

Map your cybersecurity docs to ISO 13485. Here's my mapping. Your threat model is a design output under Clause 7.3. The guidance ties your SBOM to the Design and Development Files (7.3.10) and the Medical Device File (4.2.3), with purchasing controls (7.4) governing supplier conformance. Your cybersecurity management plan supports analysis of data and improvement under 8.4 and 8.5. Make sure these connections are explicit in your QMS.

Don't start over. If you built your cybersecurity program around the superseded 2023 or 2025 versions, you're fine. Update the QMS references, make sure everything still traces correctly, and keep going.

Do check your SBOM and threat model. Not because of this guidance update, but because those are the two documents we see rejected most often. Are they current? Complete? Machine-readable?

And if you haven't started your cybersecurity documentation yet, the documentation list hasn't changed. That's good news. It means every resource, template, and guide that existed before February 3 still applies, once you swap the QSR references.

Get the Full Breakdown

We wrote a complete guide to the documents FDA expects in your submission. It walks through each one with examples, common mistakes, and what FDA reviewers actually look for.

And if you want help getting the package done right (and done fast), CyberSprint delivers a complete cybersecurity documentation package in 30 days. Mapped to QMSR. Ready for submission.

Talk to us if you're working on a submission and need a second set of eyes.

Need help with FDA cybersecurity documentation? See our FDA cybersecurity documentation service or email us at info@cybermed.ai.

Sources

1. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, FDA, February 3, 2026.
2. 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (Section 524B of the FD&C Act), Office of the Law Revision Counsel.
3. eSTAR Program, FDA.
4. Medical Devices; Quality System Regulation Amendments, Final Rule, 89 FR 7496, Federal Register, February 2, 2024.
5. Postmarket Management of Cybersecurity in Medical Devices, FDA, December 28, 2016.
6. Common Vulnerability Scoring System (CVSS), FIRST.Org, Inc.
7. ISO 14971:2019, Medical devices: Application of risk management to medical devices, ISO.
8. ISO 13485:2016, Medical devices: Quality management systems, Requirements for regulatory purposes, ISO.