FDA Changed Its Cybersecurity Guidance Again. What Actually Moved?

The guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued 3 February 2026. It supersedes the 27 June 2025 document of nearly the same name, which itself replaced the September 2023 one.

Three versions in under three years, and this time only one word moved in the title. That is easy to miss, and a package that has been in preparation for a while was written against a document the reviewer is no longer reading.

The revision itself is genuinely administrative. But administrative and ignorable are different claims, and the difference is larger than it looks.

What moved

The regulation underneath the guidance changed. The Quality System Regulation at 21 CFR Part 820 has been substantially replaced by the Quality Management System Regulation, which incorporates ISO 13485:2016 by reference and took effect on 2 February 2026. FDA reissued the cybersecurity guidance the following day to point at the new framework.

That is the change. References to the QSR became references to the QMSR and, through it, to subclauses of the standard.

What did not move

Everything you were actually working on.

The Secure Product Development Framework recommendation stands, and the named reference frameworks are unchanged: AAMI TIR45, IEC 81001-5-1, ANSI/ISA 62443-4-1.

The SBOM expectations stand. Machine-readable, NTIA minimum elements including dependency relationships, support level and end-of-support dates per component, and known vulnerabilities with CISA's Known Exploited Vulnerabilities Catalog named as a source. If your SBOM currently lists the framework and stops, that was a gap in June 2025 and it is the same gap now.

The security architecture views stand, and there are still four of them: global system, multi-patient harm, updateability and patchability, and security use case views.

Threat modeling, a security risk assessment distinct from but connected to your safety risk assessment, and security testing that goes beyond what a scanner produces: all unchanged. So are the five security objectives, which remain authenticity including integrity, authorization, availability, confidentiality, and secure and timely updatability and patchability.

If you were building to the June 2025 text, you were building to the right thing.

So why does an administrative change cost anything

Because a submission is a document read by someone checking whether you know which rules apply to you.

A cybersecurity package that cites 21 CFR 820 as your quality system regulation, or refers throughout to "the QSR," is now citing something superseded. Nobody will refuse your submission over it. But you have handed a reviewer a free signal that the package was assembled from templates rather than from a current reading, and a reviewer who finds one such signal tends to go looking for others. That is the same dynamic that turns a deficiency letter from four items into fourteen.

The fix is a find-and-replace across your quality procedures, submission templates, and design control documentation, plus one careful pass to confirm the replacement makes sense in each sentence rather than being merely correct. Call it an afternoon.

The part that is not administrative

By anchoring cybersecurity guidance to a QMSR built on ISO 13485, FDA has made cybersecurity a function of your quality management system rather than a parallel exercise that produces a document at submission time.

The standard requires risk management across the product lifecycle and requires software validation. Design controls under it mean your security controls belong in your design inputs, your design outputs, and your verification and validation, rather than appended afterwards. Change management means a vulnerability disclosed after release runs through your CAPA process like any other nonconformity.

For a company with a functioning quality system, that is a mapping exercise. For a company whose security work has lived in its own document set, maintained by its own person, on its own review cadence, it is a reorganization. That is the work hiding inside a change everyone is describing as a formality.

Here is the practical version of the question. A vulnerability is disclosed against a component in your product next month. Does your existing intake and triage pick it up and route it, without anyone inventing a procedure that afternoon? If the answer is no, that is the gap this update points at, and it exists whether or not anyone at FDA ever mentions it to you.

Where the record lives

The question that surfaces this fastest has nothing to do with cybersecurity. It is what happens the first time an engineering team asks to run its work in a modern issue tracker.

It is a reasonable request and the answer is yes, but only with a boundary drawn explicitly. The tracker is a supporting engineering tool that feeds the quality system. It is not part of it. Quality records stay in your controlled document system, and tickets reference document numbers and requirement IDs rather than containing controlled content. The audit question you have to be able to answer is "where is the record," and the answer can never be "in a ticket."

Draw it the other way, and the tracker becomes a QMS system: ISO 13485 software validation, Part 11 signature territory, and change-control scrutiny of every vendor cloud update. Almost nobody wants that, and almost nobody realizes they have drifted into it. The drift has a specific tell, which is somebody approving a design output by transitioning a ticket.

Two mechanics make the supported version work, and both matter more for security than they look:

Triage at intake. Every incoming item gets classified when it arrives, in required fields, not in someone's head. Does it touch device software. Does it change a design output. Does it meet complaint, nonconformance, or CAPA criteria. Two dropdowns and a short weekly meeting is enough, and if it becomes a form-filling ceremony people will route around it, which is the actual compliance risk. That classification step is the thing that picks up a disclosed vulnerability and routes it, and it is the difference between a coordinated disclosure process that runs and one that exists on paper.

Cost paid per release, not per ticket. One change order per release rather than one per item, with the release's change list exported and filed as a controlled record, the requirement and trace updates for anything design-affecting, the verification evidence, and a short regulatory change assessment. Individual tickets carry almost no overhead. That is what makes the boundary survive contact with a team that ships every two weeks.

A security finding is just another issue type in that scheme, linked to its threat model entry and its remediation record. Which is the whole point. When security work is a row in the same intake your engineering work already goes through, the QMSR alignment is already done. When it is a separate document set, this guidance update is a project.

What to do this week

Confirm which version you are writing to. Pull the guidance off FDA's site rather than from an internal copy someone downloaded, and check the issue date. Do this before you check anything else.

Grep your document set for the old citations. "21 CFR 820," "Quality System Regulation," and "QSR" across quality procedures, submission templates, and design control documents.

Then read one level up. The citation fix is an afternoon. Whether your cybersecurity work lives inside your quality system or merely next to it is the question worth the rest of the week, and it is the one that will still be true after the next revision.

If you are already cleared, none of this is urgent. Devices authorized under earlier versions of the guidance remain authorized, and the current expectations attach when you next submit something. The statutory obligations under Section 524B did not change at all.

This is engineering guidance, not legal or regulatory advice. Regulatory strategy for a specific submission belongs with your regulatory lead.