February 2, 2026 was the most significant single-day change to medical device manufacturing regulation in the United States in three decades. On that date, the FDA's Quality System Regulation (QSR) — the framework that governed how device manufacturers had to design, build, and document their products since 1996 — was replaced by the Quality Management System Regulation (QMSR). The citation, 21 CFR Part 820, stayed the same. The contents inside that citation changed almost entirely.
Most coverage of the transition focused on the obvious implications: ISO 13485:2016 is now incorporated by reference into US law, the inspection program is new, the documentation expectations shift toward risk-based thinking. What got less attention is what the transition means specifically for cybersecurity documentation — which is where the FDA quietly reissued its cybersecurity guidance the very next day, on February 3, 2026.
The two changes are not coincidental. They're interlocked. If you operate a medical device cybersecurity program, understanding both is now non-optional.
What QMSR actually is
QMSR — Quality Management System Regulation — is the FDA's new framework for medical device quality systems. It replaces the older QSR (Quality System Regulation) that had been in effect since 1996. The headline change: QMSR incorporates ISO 13485:2016 by reference, meaning the international standard is now legally binding in the United States for medical device manufacturers, with a small set of US-specific additions on top.
The practical meaning of "incorporated by reference" is important. It's not that ISO 13485 is "suggested" or that manufacturers should "consider" it. It's that the text of ISO 13485:2016 is now the controlling text for what a US medical device quality management system must look like, with FDA-specific overlays for things like Medical Device Reports, complaint handling specifics, and record retention.
For manufacturers that already operated under ISO 13485 (typically because they sell in EU, UK, Canada, Japan, or other jurisdictions that accept ISO 13485 as the basis for quality system audits), QMSR is largely a confirmation of what they were already doing. For manufacturers that operated only under the older US QSR framework, QMSR is a meaningful homework assignment.
Why the change happened
The FDA published the final QMSR rule in early 2024 with a two-year transition window. The reasoning was articulated openly by FDA leadership: harmonization with international standards reduces duplicate compliance work for manufacturers selling globally, modernizes the regulatory framework, and aligns US oversight with the risk-based approach that international standards bodies have evolved toward over the past 25 years.
The older QSR was prescriptive — it specified what to do. ISO 13485 is risk-based — it requires manufacturers to identify risks specific to their products and processes, and to demonstrate that their quality system addresses those risks proportionally. This is a meaningful philosophical shift, even when the day-to-day documentation looks similar.
QSR vs. QMSR at a glance
The clearest way to understand what changed is a side-by-side comparison of the two frameworks' orientation:
| Dimension | QSR (pre-Feb 2026) | QMSR (post-Feb 2026) |
|---|---|---|
| Citation | 21 CFR Part 820 | 21 CFR Part 820 (unchanged citation, new content) |
| Effective | 1996–February 1, 2026 | February 2, 2026 onward |
| Underlying standard | US-specific, prescriptive | ISO 13485:2016 incorporated by reference |
| Orientation | "What you must do" | "Manage the risks specific to your product" |
| Inspection program | QSIT (Quality System Inspection Technique) | Inspection of Medical Device Manufacturers Compliance Program 7382.850 |
| Terminology | "Quality System" | "Quality Management System" |
| International harmonization | Partial | Substantial — ISO 13485 is the global baseline |
The new inspection program: 7382.850
Along with QMSR, the FDA retired QSIT — the Quality System Inspection Technique that had guided FDA inspector training and inspection conduct for over two decades — and replaced it with the new Inspection of Medical Device Manufacturers Compliance Program 7382.850, effective the same day.
The new compliance program reflects the ISO 13485 risk-based orientation. Inspectors are now trained to evaluate not just whether documentation exists, but whether the manufacturer has identified the risks specific to their product and process, and whether the quality system addresses those risks meaningfully.
For cybersecurity specifically, this is consequential. Under QSIT, an inspector might check whether a cybersecurity SOP existed. Under 7382.850, an inspector is more likely to evaluate whether the manufacturer's risk analysis identifies cybersecurity threats specific to the device, whether the quality system's design controls integrate cybersecurity risk treatment, and whether postmarket surveillance includes vulnerability monitoring as a discipline integrated with other CAPA (Corrective and Preventive Action) processes.
The shift from "do you have a cybersecurity SOP?" to "is your cybersecurity program proportional to the cyber risks your specific device presents?" is the QMSR-era inspection mindset.
Why FDA reissued the cybersecurity guidance one day later
This is the part most QMSR coverage misses. On February 3, 2026 — exactly one day after QMSR took effect — the FDA reissued its premarket cybersecurity guidance, retitling it from "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" to "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions".
The single word added — Management — was the surface signal of a deeper alignment. The cybersecurity guidance had to align with the new QMSR framework because the cybersecurity expectations sit inside the broader quality system the manufacturer operates. You can't have a cybersecurity program that ignores how your QMS works.
The substantive cybersecurity requirements didn't change. SBOM, Threat Models, postmarket vulnerability management, Secure Product Development Framework — all the same. What changed is the framing: cybersecurity is now expected to live inside a QMSR-aligned (ISO 13485-based) quality management system, not alongside it.
The cybersecurity-specific impacts of QMSR
Most teams reviewing the QMSR transition focus on the general quality system impacts: design controls, document control, management responsibility, internal audits, supplier controls. Important, but well-covered elsewhere. Here are the cybersecurity-specific implications that get less attention:
1. Cybersecurity is integrated, not siloed
Under QMSR / ISO 13485, design controls are an integrated discipline. Cybersecurity is no longer a separate workflow that runs parallel to design controls — it's an expected input to design controls. Threat Models inform design inputs. Cybersecurity risk treatment informs design verification. Vulnerability monitoring feeds into post-market surveillance and management review. Teams that built their cybersecurity program as a separate vertical now face the work of integrating it with the QMS spine.
2. Risk management integration with ISO 14971
ISO 13485:2016 explicitly requires manufacturers to apply ISO 14971 (the international risk management standard) throughout the product lifecycle. ISO 14971 is about safety risk management — patient harm. Cybersecurity risk is different (focused on confidentiality, integrity, availability) but the two are interrelated. The FDA Cybersecurity Guidance, AAMI TIR57, and the new AAMI SW96 all address this interface. Under QMSR, the expectation that your cybersecurity risk analysis and your safety risk analysis (ISO 14971) talk to each other coherently is now baseline.
3. Software lifecycle alignment with IEC 62304
ISO 13485 references IEC 62304 (medical device software lifecycle) for software-containing devices. QMSR carries this forward. For cybersecurity, this means your Secure Product Development Framework needs to be visibly integrated with your IEC 62304-compliant software lifecycle. The cyber security architecture work and the software safety classification work shouldn't be done by disconnected teams producing disconnected documents.
4. Postmarket surveillance broader scope
Under ISO 13485 clause 8.2 (Monitoring and measurement), postmarket surveillance is an expected, structured activity. Section 524B's postmarket cybersecurity obligations (continuous vulnerability monitoring, coordinated vulnerability disclosure, patch coordination) now fit cleanly within this broader postmarket surveillance framework rather than standing alone. The implication: your cybersecurity postmarket activities should be documented as part of your overall postmarket surveillance procedure, not as a separate "cyber-only" workflow.
5. Management review now includes cyber metrics
ISO 13485 clause 5.6 (Management review) requires periodic management review of the quality system, including monitoring outputs and improvement opportunities. Under QMSR, this is enforced. Cybersecurity metrics — vulnerability disclosure response times, patch coordination KPIs, SBOM update cadence, postmarket incident rates — are now expected inputs to management review. If your management review minutes don't mention cybersecurity, an inspector under 7382.850 will notice.
What you need to do
If your team operated under QSR previously and you have an active or imminent cybersecurity-relevant submission, here's the practical checklist for the QMSR era:
- Audit your QMS against ISO 13485:2016 clauses, not against the old QSR sections. The clause numbers are different, and the orientation is different. Identify gaps and address them.
- Update cybersecurity SOPs to reference QMSR. Anywhere your procedures cite "21 CFR Part 820 (QSR)" should now cite "21 CFR Part 820 (QMSR) / ISO 13485:2016." Anywhere your documentation references QSIT should reference the new Compliance Program 7382.850.
- Integrate your Cybersecurity Management Plan into your QMS as a cross-functional discipline rather than a standalone document. Reference design controls, risk management, postmarket surveillance, and management review explicitly.
- Train your team on 7382.850 inspection expectations. Inspectors are looking for risk-based thinking, not just documentation existence. Practice articulating why your cybersecurity controls are proportional to your specific device's risk profile.
- Update vendor and supplier agreements to reflect QMSR-era supplier control expectations. ISO 13485 clause 7.4 (Purchasing) has specific requirements that your supplier contracts may not currently address — including cybersecurity-relevant supply chain expectations.
- Ensure management review minutes from Q1 2026 onward include cybersecurity metrics. If your March or April 2026 management review didn't mention cyber, schedule a remediation review.
- Reread the FDA Cybersecurity Guidance (Feb 3, 2026 version) with QMSR in mind. The language is subtly different from June 2025 in ways that matter for documentation tone and emphasis.
The common pitfall
The most common misconception about the QMSR transition is that it's "QSR with a rename." This isn't true. QMSR is a substantively different framework — same regulatory citation, fundamentally different orientation toward risk, integration, and proportionality. Teams that treat QMSR as a search-and-replace exercise on their existing QSR documents will pass surface inspection but fail substantive review.
The second common pitfall is treating the QMSR transition and the February 3 cybersecurity guidance reissue as separate events. They're not. They're a coordinated pair, and FDA reviewers in 2026 expect cybersecurity documentation to reflect both shifts coherently. A submission that updates its cybersecurity references to Feb 2026 but doesn't reflect QMSR integration in its quality system documentation reads, to a reviewer, as half-aligned.
The bottom line
February 2, 2026 was a structural change to medical device regulation in the United States. February 3, 2026 was the cybersecurity guidance's alignment with that structural change. Both are now in effect, both are controlling, and both have specific implications for how cybersecurity work is documented, integrated, and inspected.
The teams that treat this as a paperwork update will find themselves caught in subtle but consequential inspection findings. The teams that treat it as a re-architecture of how cybersecurity lives inside the broader quality management system will find themselves operating cleanly within the new framework — and producing documentation that reads correctly to reviewers trained on the new standards.