What the FDA's QMSR Means for Medical Device Cybersecurity

Reviewed September 17, 2026

Teams sometimes read the QMSR transition as a cybersecurity event. It is not. Section 524B is where the cybersecurity obligations come from, and the February 3, 2026 premarket guidance is where the expectations are described. The QMSR governs the quality system those activities are performed within.

That distinction matters because the practical work is real even though the requirements did not change. Procedures reference clause numbers that moved, design control language shifted, and inspections now follow a different program. If your cybersecurity procedures still cite subparts that are reserved, you have documentation work to do even if your actual practices are sound.

What Actually Changed

The FDA published the QMSR final rule in February 2024, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference, with a compliance date of February 2, 2026. The intent was harmonization: manufacturers who already maintained an ISO 13485 quality system had been maintaining two overlapping structures, and the rule reduces that duplication.

Structurally, much of the former Part 820 text is gone. Subparts that previously carried the detailed requirements are reserved, because the substance now lives in the incorporated standard. A small number of FDA-specific requirements remain in the regulation, including 820.35, which addresses records and includes device-specific record requirements rather than restating design controls.

Inspection changed alongside it. The Quality System Inspection Technique, the approach investigators had used since 1999, was retired on February 2, 2026, and inspections are conducted under Compliance Program 7382.850. For manufacturers, the practical effect is that the familiar four-subsystem framing is no longer the structure an investigator walks through.

What Did Not Change for Cybersecurity

The useful way to hold this is that Section 524B tells you what cybersecurity work must be done, the premarket guidance tells you what evidence of it to file, and the QMSR tells you what quality system that work is performed inside. Confusing the three leads to procedures that cite the wrong authority for the right activity.

[KEY REQUIREMENT] Review every cybersecurity procedure for citations to former Part 820 subparts. Citing a reserved subpart does not make your practice wrong, but it makes your documentation wrong, and that is what an investigator reads.

Where Cybersecurity Lives in an ISO 13485 System

Two of these are where the real integration work sits. Design inputs is the first: security requirements that exist only in a security document, and never enter the design input set, are not traceable to outputs or verification, which is exactly the gap an investigator or a reviewer will find. The second is CAPA. A vulnerability identified after release is a nonconformity, and handling it in a separate security process that does not feed CAPA leaves the quality system unaware of it.

Supplier controls deserve a mention because the SBOM makes third-party components visible in a way they were not before. Once you have enumerated every component, the question of how you evaluate and monitor those suppliers becomes concrete.

What to Do If Your Procedures Still Reference the Old Structure

The work is mostly documentation, and it is finite.

None of this improves your security posture. It makes your quality system accurately describe the security work you already do, which is the part an inspection evaluates.

How the Change Affects Inspections

See also: Medical Device Cybersecurity Risk Analysis, Home Use vs Hospital Device Cybersecurity Requirements, and Indications for Use, Predicates, and Cybersecurity Scope.

With QSIT retired, the four-subsystem walkthrough is no longer the frame investigators use. What has not changed is what makes an inspection go badly: procedures that do not match practice, records that cannot be produced, and activities performed outside the quality system.

For cybersecurity specifically, the questions that come up are consistent. Show the security requirements in the design inputs. Show verification evidence for each one. Show how a reported vulnerability moved through CAPA. Show the SBOM and how it is maintained across releases. Show how a design change was assessed for security impact before approval.

Each of those is answerable from a well-integrated system and awkward from a system where security lives in parallel documents maintained by a separate team.

How Blue Goat Cyber Approaches This

We work inside the quality system rather than beside it, which means the threat model produces design inputs, the testing produces verification evidence, and the findings route into CAPA the way any other nonconformity would. That is what makes the cybersecurity file defensible in both a submission and an inspection.

Our threat modeling output is written to be usable as design input rather than as a standalone report, and our medical device penetration testing evidence is structured to support verification records.

Frequently Asked Questions

Does the QMSR add new cybersecurity requirements?

No. The QMSR incorporates ISO 13485:2016 into 21 CFR Part 820 and governs your quality system. Cybersecurity obligations come from Section 524B of the FD&C Act and are described in the FDA's premarket cybersecurity guidance issued February 3, 2026. The QMSR changes the structure the work is performed within, not the work itself.

When did the QMSR take effect?

The final rule was published in February 2024 with a compliance date of February 2, 2026. Manufacturers were expected to have transitioned by that date, and the Quality System Inspection Technique was retired on the same day, with inspections now conducted under Compliance Program 7382.850.

What is 21 CFR 820.35 under the QMSR?

It is a records requirement within the amended Part 820, addressing device-specific records the FDA retains beyond what ISO 13485 specifies. It is not a restatement of design controls, and cybersecurity procedures that cite it as though it were the design control clause are citing it incorrectly.

Where should security requirements live in an ISO 13485 system?

In the design inputs, traced to design outputs and to verification evidence, exactly as any other requirement. Security requirements that exist only in a threat model or a security plan, without entering the design input set, break the traceability chain that both submissions and inspections depend on.

How does vulnerability handling fit into CAPA?

A vulnerability discovered after release is a nonconformity and should enter the CAPA process, with investigation, risk assessment, corrective action, and effectiveness verification. Running a separate security incident process that never feeds CAPA leaves the quality system without a record of the issue and is a recognizable inspection finding.

Do we need to rewrite our cybersecurity procedures?

Usually you need to re-cite and re-map them rather than rewrite them. The activities that were appropriate before remain appropriate. What needs correcting are references to Part 820 subparts that are now reserved, terminology that differs from ISO 13485, and any place where security work sits outside the quality system's traceability and CAPA structure.

Make the Quality System Match the Security Work

If your cybersecurity documentation still describes the old Part 820 structure, we can help you map it into ISO 13485 without disrupting the work itself. Book a strategy session.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.