FDA QMSR 2026: What Medical Device Founders Should Change Before the Next Prototype

FDA's Quality Management System Regulation (QMSR) amends 21 CFR Part 820, the current good manufacturing practice requirements for devices, and incorporates ISO 13485:2016 by reference. It took effect on February 2, 2026. The final rule, Medical Devices; Quality System Regulation Amendments, was published in the Federal Register on February 2, 2024, with a two year runway to that effective date.

In plain English, the quality system expectations you meet are now written mostly in ISO 13485 language, with FDA specific additions layered on top. QMSR also incorporates Clause 3 of ISO 9000:2015 for vocabulary, so terms mean what the standard says they mean. Where ISO 13485 and the Federal Food, Drug, and Cosmetic Act (or its regulations) conflict, the Act and its regulations control.

Inspections changed too. As of February 2, 2026, FDA stopped using the Quality System Inspection Technique (QSIT) and Compliance Programs 7382.845 and 7383.001. Inspections now follow the updated Compliance Program 7382.850, Inspection of Medical Device Manufacturers. The practical effect for a small team is that an investigator walks your quality system the way the standard is structured, not the way the old four subsystem model was structured.

QMSR applies to finished device manufacturers who intend to commercially distribute their devices. Accessories that are treated as finished devices can pull a manufacturer into scope as well. So the question is not whether you have a quality system on the day you build your first bench model. The question is whether the builds you intend to lean on later were produced and documented in a way that survives review.

One point catches founders off guard. Devices under an Investigational Device Exemption are not exempt from design and development requirements. 21 CFR 820.10(c) keeps those obligations in place, and they map to the Design and Development requirements in Clause 7 of ISO 13485. If your clinical or human factors work runs under an IDE, the design record has to exist.

Not every build needs a controlled record. Exploratory models exist to answer a question: does this mechanism work, does the enclosure feel right in a gloved hand, can the sensor read through this wall thickness. Learn fast, keep an engineering notebook, move on. Nobody expects a design history file behind a foam mockup.

An evidence build is different. The moment a unit is used to support a claim, it is evidence. Usability and human factors sessions, bench performance testing, biocompatibility sample articles, and design verification runs all fall here. For those, the build needs a known configuration, a bill of materials you can reproduce, a build record naming who built what and when, materials and process traceability, and a link back to the requirement being tested.

The cheapest moment to draw that line is before the build, not after. Retroactively reconstructing a configuration is where teams lose weeks and sometimes have to rebuild and retest. This is the part of the work we spend the most time on with founders moving from idea to functional prototype in medical device prototyping, and it is why we treat documentation as an engineering deliverable rather than paperwork that happens later.

QMSR moves the baseline onto ISO 13485:2016, which is good news if your contract manufacturer or your European plans already run on that standard. It is not the same as saying an ISO 13485 certificate makes you QMSR compliant. Certification is a third party audit outcome against the standard. QMSR is a US regulation that incorporates the standard and then adds and modifies requirements, and FDA inspects against the regulation, not against your certificate.

Areas that remain distinctly FDA include labeling and packaging controls written into Part 820, device specific record expectations, and reporting obligations that live outside the quality system regulation entirely. Broader program discipline still helps, and if you are building that muscle for the first time, our note on quality management systems in new product development covers the groundwork.

If you are early and trying to decide how much structure your next build actually needs, that is a short conversation, not a project. You can compare approaches in our overview of medical device design companies, read how we scope engagements in product development consulting, or tell us what you are building and we will tell you plainly where the documentation line should fall for your device.