FDA QMSR Update: Why Cybersecurity Is Now a Quality System Mandate
August 19, 2026
At a Glance
FDA's February 2026 update didn't add new cybersecurity requirements — it replaced Quality System Regulation (QSR) references with the new Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016.
The substantive requirements — SBOMs, security test evidence, and Secure Product Development Framework documentation — were established in the June 2025 guidance and remain fully in force.
What's new is structural: cybersecurity risk is now formally a quality system function, connected to ISO 14971 risk files, CAPA, and complaint handling — and evaluated as such during inspections.
For device and SaMD manufacturers, that shift creates real validation and automation work: SBOM lifecycle management, security test evidence generation, and traceability between them and the risk management file.
On February 03, 2026, the FDA reissued its cybersecurity guidance for medical device premarket submissions, updating references to align with the transition from the former Quality System Regulation (QSR) to the new Quality Management System Regulation (QMSR). The guidance reflects the FDA's adoption of ISO 13485:2016 by reference, reinforcing a harmonized quality management framework for medical device manufacturers.
For manufacturers, the key change is not just what evidence is required, but where that evidence is managed and how the FDA evaluates it. Cybersecurity risk management is no longer treated as a submission-day artifact. It is now formally integrated into the quality system, connected to the same risk management processes, CAPA workflows, and complaint handling structures that govern other aspects of device quality.
After February 2026, FDA inspections will evaluate cybersecurity as part of the manufacturer's broader quality management system, rather than as a standalone cybersecurity activity. Manufacturers will need to demonstrate how cybersecurity risks are identified, controlled, monitored, and maintained throughout the device lifecycle.
FDA Cybersecurity Requirements: What Changed with the QMSR Update?
The core cybersecurity information expected in premarket submissions was established in FDA's June 2025 cybersecurity guidance and remains focused on demonstrating that cybersecurity risks have been appropriately identified, assessed, and managed throughout the device lifecycle.
For devices that meet the Section 524B definition of a "cyber device" which includes devices with software, internet connectivity, and technological characteristics that could be vulnerable to cybersecurity threats — manufacturers are expected to provide, among other elements:
A software bill of materials (SBOM) identifying the software components included in the device, including proprietary, commercial, open-source, and off-the-shelf software, to support ongoing vulnerability management and risk assessment activities.
Evidence of cybersecurity testing appropriate to the risk profile of the device, such as vulnerability assessments, penetration testing, and evaluation of security controls, demonstrating that implemented measures are effective rather than simply documenting their existence.
Documentation demonstrating that the device was developed using a Secure Product Development Framework (SPDF), showing that cybersecurity considerations were incorporated throughout the product lifecycle, from design and development through post-market monitoring and updates.
While these expectations were established through FDA's cybersecurity guidance, the transition to QMSR reinforces how these activities are managed within the broader quality system.
Cybersecurity risk management is expected to align with the manufacturer's overall risk management processes, applying the same risk-based approach used to evaluate other device hazards. The processes used to generate, maintain, and apply cybersecurity documentation must be supported by appropriate quality system controls, including design controls, change management, corrective action processes when issues are identified, and post-market monitoring activities.
The Key Operational Impacts: SBOMs, Test Evidence, and SaMD Validation
Integrating cybersecurity evidence into the quality management system transforms cybersecurity from a submission-time activity into an ongoing operational responsibility. For manufacturers, that means cybersecurity processes must be repeatable, traceable, and scalable across the entire product lifecycle. This creates new challenges for validation, software development, and automation teams.
SBOM Lifecycle Management
A Software Bill of Materials (SBOM) generated once at submission is already outdated by the time a device reaches the market. Software components are patched, dependencies change, and new vulnerabilities are continuously identified across libraries and third-party components.
Manufacturers need to treat a SBOM as a controlled, continuously maintained record. One that can be regenerated as builds change, evaluated against vulnerability information, and linked back to software versions, risk assessments, and product documentation. This requires a structured lifecycle process supported by automation, traceability, and appropriate quality controls.
Security Test Evidence, Generated and Maintained
FDA's expectation is evidence. Cybersecurity testing activities, including vulnerability assessments, penetration testing, fuzz testing, and security control verification must produce documented, repeatable, and defensible results that demonstrate security risks are appropriately managed.
For manufacturers, the challenge is ensuring these activities remain traceable to specific software versions, identified risks, and mitigation strategies. Manual, ad hoc security testing approaches become difficult to maintain as products evolve and software releases accelerate.
SaMD Lifecycle Validation
Software as a Medical Device (SaMD) evolves at a pace far faster than traditional hardware products, with updates often occurring on a cadence measured in weeks rather than years. Under a QMS-integrated cybersecurity approach, every meaningful software change requires an evaluation: Does the update affect the SBOM? Does it introduce new vulnerabilities? Does it require additional security testing or changes to the risk management file?
QMSR Cybersecurity Readiness Checklist for Device Manufacturers
Embedding these assessments into the software validation and change management lifecycle, rather than treating cybersecurity as a separate workstream helps manufacturers reduce duplication, maintain compliance, and identify gaps before they become inspection findings. For teams assessing how exposed they are to this shift, a few questions are usually revealing:
Is your SBOM regenerated automatically with each build, or maintained manually and updated only near submission?
Are your security test results traceable to specific software versions and specific entries in your risk management file?
If an inspector asked to see how cybersecurity risk is reviewed through your CAPA and complaint handling process today, could you show them — or would that answer require assembling something new?
None of these are new obligations created by the February 2026 update. They're existing obligations that are now considerably easier for FDA to evaluate and considerably harder to answer informally.
The FDA Quality System Trend: From Submissions to QMS Lifecycle Integration
This is a familiar shape for anyone who has watched FDA's regulatory approach mature: a requirement introduced as a submission-content checklist eventually gets absorbed into the quality system itself, at which point it stops being optional documentation and becomes an operational expectation, inspected and enforced accordingly. AI validation and CSA-aligned software testing followed by a similar arc. Cybersecurity is simply the latest example and the manufacturers who treat SBOM and security test evidence as validated lifecycle-integrated quality records now will be in a materially stronger position than those who treat them as a submission-season sprint.
Partner With AVS Life Sciences
Building Validated, Lifecycle-Integrated Processes for QMS Cybersecurity
AVS Life Sciences works with device, SaMD, and biologics manufacturers to build validated, lifecycle-integrated processes for exactly this kind of cross-functional requirement. If your team is mapping out what QMS-integrated cybersecurity actually looks like in practice, we're glad to compare notes.
No. The substantive requirements — SBOMs, security test evidence, and Secure Product Development Framework documentation were established in the June 2025 guidance. The February 2026 revision replaced references to the old Quality System Regulation with the new Quality Management System Regulation and aligned terminology with ISO 13485:2016.
Generally, a device that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. This statutory definition, not the guidance itself, is what triggers the premarket cybersecurity documentation expectations.
Yes. Inspections conducted after the QMSR's February 2, 2026 effective date use an updated compliance program that references ISO 13485, meaning cybersecurity practices are now evaluated through the same lens as the rest of the quality system rather than as a standalone topic.
Start by mapping the current process end to end — from build to SBOM generation to security testing to risk file entry — and identifying where that chain breaks down or depends on someone's memory. That gap analysis usually makes the validation and automation priorities self-evident.
