FDA QMSR: What It Means for QMS, MES and LIMS Software Vendors

QMSR is the rule that U.S. medical device manufacturers follow to run their quality systems. Its full name is the Quality Management System Regulation, and it is the amended Part 820 of Title 21 of the Code of Federal Regulations (21 CFR Part 820), issued by the U.S. Food and Drug Administration (FDA). It took effect on February 2, 2026, and is built on the international standard ISO 13485:2016.

The rule applies to companies that make devices, such as infusion pumps, implants, or surgical instruments. Software vendors that sell quality management system (QMS), manufacturing execution system (MES), or laboratory information management system (LIMS) software are outside the rule.

However, your customers must validate the software they use in production and in their quality management system for its intended use. This work is important because FDA inspectors check it, and FDA’s guidance lets your customers start from the documents and test results you hand over.

So customers now send you supplier questionnaires that cite ISO 13485 clause numbers, ask to audit your company, and want to know what changed in each release before they install it. The requests can sound like new requirements for your product, but they come from duties the rule puts on the customer and from the customer’s own procedures.

That is why we wrote this guide. It includes an example from the validation framework Zoolatech engineers built with MasterControl, which builds quality, manufacturing, and compliance software for life sciences and other regulated industries.

We explain what changed versus the old Quality System regulation, how FDA QMSR reaches a software vendor, what inspectors look at, what customers may ask you for, and what you can claim about your product without overstating it.

By the end, you will also know which customer requests come from the rule and which come from your customers’ own procedures, and you will get a checklist you can turn into backlog items.

What Is QMSR? Definition, Effective Date and ISO 13485

QMSR is short for Quality Management System Regulation. The intro gave you the one-line definition, so here we look at what the rule is built on, when it started, and whether it will change.

What it is built on. Until February 2, 2026, Part 820 was the FDA’s own list of quality requirements. Now the same part tells manufacturers to follow ISO 13485:2016, the international quality standard for medical devices. Lawyers call this incorporation by reference. For you, it means that customer procedures and checklists now use ISO 13485 clause numbers. The regulation itself is written as “21 CFR Part 820” or simply “21 CFR 820”, and both mean the same thing.

Here is how FDA and ISO 13485 fit together. FDA has the final say, and if the standard and U.S. federal law disagree, the law wins. FDA also kept a few requirements of its own on top of the standard, and the next section lists them.

When it started. The QMSR effective date is February 2, 2026. FDA published the final rule on February 2, 2024, so device makers had 2 years to prepare. FDA says the new rule now specifically requires risk management, and the change table below shows what that means for your product.

Whether it will change. ISO 13485:2016 is the current edition, and ISO confirmed it again in 2025. If ISO publishes a new edition later, FDA says it will evaluate the changes and, if appropriate, amend FDA QMSR through rulemaking. So a new edition of the standard won’t automatically reach your customers.

Who QMSR applies to, and who it doesn’t

QMSR applies to companies that make and sell finished medical devices. FDA calls them finished device manufacturers. Under the old QS regulation, the same companies were in scope, so the change didn’t add or remove coverage.

QMSR does not apply to two groups. The first is companies that make only parts or components for a device. FDA encourages them to consider its provisions as appropriate, and it can inspect them but rarely does so outside the premarket approval (PMA) program. The second is software vendors. The rule does not name them in its scope.

A vendor’s obligations come from a different place. FDA notes that keeping component makers outside the rule does not prevent contracts between manufacturers that require compliance with it. In our reading, the same route reaches software vendors. Device makers write their requirements into purchasing agreements and supplier questionnaires, and the next sections show how.

If your software runs inside a device itself, that is a separate topic, covered by our medical device software development practice.

The main difference between QMSR and the old QSR is the framework the requirements sit in, and most day-to-day duties did not change.

FDA QSR stands for the FDA Quality System Regulation, the old version of Part 820. FDA compared it with ISO 13485 and concluded that the standard, taken as a whole, is substantially similar to the old rule. So your customers did not have to rebuild their quality systems from scratch.

Four things did change, and each of them reaches you in some form:

• The structure. The old rule was FDA’s own text. The new rule is ISO 13485 plus a few FDA additions, so customer documents now quote ISO clause numbers.
• Risk management. FDA says the new rule now specifically requires it. In practice, QMSR risk management means your customers decide how deeply to test each software function based on what can go wrong if it fails.
• Which records FDA can read. Under the old rule, FDA inspectors couldn’t access management review reports and audit reports. Now they are open. If a customer audits your company and writes a report, an FDA inspector can read it.
• How inspections run. FDA retired its old inspection method, QSIT, and now inspects under a new program with its own checklist. That list includes software validation and software changes. The section on inspections below explains it.

The table below shows the same changes side by side, with one more row on record names. Read it left to right: the topic, the old rule, the new rule, and in the last column our reading of what it means for a software vendor.

The last column is our own reading of the changes. A dash means the FDA sources used here do not describe the old rule on that point.

The row on record names deserves a closer look. A device maker keeps three main records about each product:

• How the device is built and serviced. The old name was the device master record (DMR). The new name is the medical device file.
• How the device was designed. The old name was the design history file (DHF). The new name is the design and development file.
• How each unit or batch was made. The old name was the device history record (DHR). The new name is the medical device or batch record.

FDA dropped the old names because ISO 13485 asks for largely the same content under its own names. If your product has templates or reports with the old names, customers may ask you to rename them.

Now to what stayed the same. These are duties your customers had before QMSR and keep under it, and each one relies on a feature that an electronic quality management system (eQMS) or MES products provide. Nothing here requires a change to your product, but customers will keep asking for these functions:

• Who is covered. The same companies as before, so none of your customers dropped out of scope.
• Design controls. Device makers must keep documentation of how they design class II and class III devices, and some class I devices, including those that run on software. This is the design and development file your eQMS may hold.
• Complaint records. Complaints that involve a possible failure of a device, its labeling, or packaging need records of their review, evaluation, and investigation (§820.35).
• UDI. Record every device or batch’s unique device identifier (UDI). This is the job of MES device and batch records.
• Label checks. Labels are checked for accuracy before release, including the UDI, and the check is written down (§820.45). In our reading, this is where MES label printing and verification functions come in.
• Old records. FDA inspectors may look at records created before February 2, 2026, so the QMSR transition did not close the past. Customers need to keep old records retrievable from your product.

How QMSR Requirements Reach QMS, MES and LIMS Vendors

QMSR requirements reach software vendors through three duties the rule puts on device makers. Each duty turns into a request to you. Once you know the three, you can tell where any customer question comes from.

Duty 1. Validate the software. A device maker must prove that the software it uses for production or quality work does what it is supposed to do. ISO 13485 clauses 4.1.6, 7.5.6, and 7.6 set this duty, and cloud products such as software as a service (SaaS) are included.

This duty reaches you because FDA’s guidance lets the customer start from your test results and documentation. The customer sizes the work by risk, so a function that decides whether to release a batch gets more testing than a function that formats a report.

FDA describes the recommended method in its computer software assurance guidance, and our article on computer software assurance for software vendors explains how to apply it. QMSR validation stays the customer’s duty, and your evidence can be its starting point.

Duty 2. Check the suppliers. A device maker must keep assessing its suppliers, and your company is one of them. The depth of the check depends on how much your product affects device quality.

This duty comes to you as questionnaires and audit requests, and they differ from customer to customer because FDA guidance lets each device maker write its own supplier requirements into its procedures.

FDA did not create a “critical supplier” category, and it notes that a supplier’s certificate alone may not be enough without further evaluation. So an ISO certificate helps, but it does not end the conversation.

Duty 3. Show both to FDA. FDA investigators can now read supplier audit reports, and the inspection program checks that device makers monitor and control the products they buy.

This duty reaches you more quietly. A customer’s audit of your company used to be a private document between the two of you. Now an FDA investigator can ask for it, so what the customer writes about you can end up in an inspection file.

Which software falls under Duty 1? FDA describes two kinds, and the table below shows them with our reading of which products fit each one.

FDA does not name products, so the last column is our mapping.

How much a customer asks of you depends on how it uses each function and on what that function can break. For supporting software, FDA says the vendor’s own records and a proper installation may be enough, with no extra testing. The section on what customers may ask shows how this plays out.

Where LIMS fits, and where QMSR stops

A LIMS that a device maker uses for inspection, testing, or production data fits FDA’s description of production software, so the device maker validates it for that use. As with MES, we make this mapping. FDA does not name LIMS.

QMSR stops at finished device manufacturers. A LIMS sold to clinical laboratories or drug manufacturers is not reached through QMSR unless that customer also makes finished devices. Other FDA rules may apply to those customers.

For laboratory-developed tests, one fact is enough here. A federal court vacated FDA’s rule on them on March 31, 2025.

QMSR Inspections: What FDA Checks Under CP 7382.850

A QMSR inspection follows Compliance Program 7382.850, the manual FDA investigators have used since February 2, 2026, instead of the old QSIT method. The manual only tells investigators how to inspect, and the requirements themselves stay in the rule. It decides which of your customer’s records get pulled, and some of those records come from your product.

The program groups QMSR requirements into 6 QMS areas and 4 other applicable FDA requirements. The 6 areas, as FDA names them, are:

• Change Control.
• Design and Development.
• Management Oversight.
• Measurement, Analysis, and Improvement.
• Outsourcing and Purchasing.
• Production and Service Provision.

In a full inspection, investigators evaluate at least one element in each area, in any order they choose.

Three elements and one area concern software and suppliers directly. The table below lists them with the ISO 13485 clauses they map to and our reading of where your product comes up.

Change Control is the area that matters most for your releases. Investigators check there that the customer evaluated every change for risk and impact before using it. In our reading, each update you ship is one of those changes, so the faster your customer can assess it, the easier your product is to keep.

Investigators can also ask for records that used to be closed to them:

• Management review reports.
• Quality audit reports.
• Supplier audit reports, including a customer’s audit of your company.

Investigators may also review QMS records created before February 2, 2026. FDA recommends that firms be ready to discuss and provide records that show compliance. The first published QMSR warning letter, as one law firm describes it, came in May 2026.

FDA says its inspections assess compliance with FDA regulations, while third-party audits assess conformance to a standard.

What enforcement looks like so far

The first enforcement signal under QMSR came in May 2026. Form FDA 483 lists the problems an investigator hands over at the end of an inspection. A warning letter is the public letter FDA sends when it considers those problems serious.

A warning letter dated May 27, 2026 listed five QMSR violations at a device maker, and one of them concerned software. The firm had no documented procedure for validating software used for monitoring and measurement, which ISO 13485:2016 clause 7.6 requires. The software it used for calibration and quality testing was not adequately validated.

The law firm Covington & Burling describes it as the first published warning letter to allege QMSR violations. It is a single letter, so read it as an example of FDA’s wording.

The last full year of inspection data comes from before QMSR, but it shows where device makers get cited. In FY2025, FDA’s system issued 791 device FDA-483s.

The most cited observations were:

• Inadequate corrective and preventive action (CAPA) procedures, 279 times.
• Inadequate complaint procedures, 211 times.
• Inadequate purchasing control procedures, 115 times.

For comparison, software validation for automated processes (§820.70(i)) was cited 17 times. These figures come from FDA’s FY2025 Inspection Observations spreadsheet (Devices sheet) for inspections ending between October 1, 2024 and September 30, 2025, all under the QS regulation.

They include only system-generated FDA-483s, and each figure is a count of citations, so one company can appear several times. FDA says the spreadsheets are not a comprehensive listing of all observations.

In our reading, these numbers matter to eQMS vendors because CAPA and complaint handling are quality processes, and software that automates them is QMS software in FDA’s description. The citations concern procedures, so nobody can blame the software for them.

They do show which processes investigators look at most, and eQMS products run those processes.

What Device Manufacturers May Ask Their Software Vendors Under QMSR

Device manufacturers may ask you for four kinds of evidence under QMSR:

• Records that show your software was tested and does what it claims.
• A description of what changed in each release and how you tested it.
• Proof that the quality records inside your product are protected from silent changes.
• Documents about your company as a supplier, such as SOC reports and certificates.

They ask for these because FDA lets them reuse your work. FDA’s guidance lets a device maker leverage validation work done by developers, suppliers and cloud providers as its starting point, and for some lower-risk functions that evidence may be all the assurance the customer needs.

The rest of this section shows which request comes from which part of the rule and what you can hand over.

The table below has four columns. The first names the QMSR mechanism, the second the request it produces, the third the evidence you can provide, and the fourth the limit FDA puts on it. The second and third columns are our reading and recommendation.

SOC stands for System and Organization Controls, the audit reports on a service provider’s own controls. SDLC stands for software development life cycle.

Here is how the reuse works in practice. FDA gives an example in its computer software assurance guidance. A device maker buys a cloud tool that updates itself.

With every update, the vendor sends a document that summarizes the changes, the testing, and the test results. The device maker then assesses the changes and their effect on its intended use, and runs risk-based testing in proportion to the impact it finds.

That is the idea behind the table. In our reading, the better your release records, the less your customers have to repeat, and for some lower-risk functions your evidence may be all they need.

FDA also says what “properly” means. As a least-burdensome approach, it recommends system logs, audit trails and other data the software generates over paper documentation and screenshots. In our view, a log with a timestamp and a version number is also easier for a customer to check.

The same rule applies to the records inside your product. Every change to a quality record should show who changed it and when. Our article on 21 CFR Part 11 audit trail and record requirements shows how to build that.

How much a customer needs from you depends on what your software does for them. If it only supports a process, FDA says your records and a proper installation may be enough, with no extra testing. If it runs the process, expect more questions.

FDA QMSR adds no features to your product by itself. Your customers’ QMSR requirements become requests, and those requests decide what you build.

Can Software Be “QMSR Compliant”? What Vendors Can Claim

Software cannot be “QMSR compliant” because QMSR regulates a device maker’s quality system, and a quality system is a set of procedures and records. FDA does not certify software against QMSR. It does not even issue ISO 13485 certificates.

FDA says this in its QMSR FAQ in one sentence: “The FDA will not require certificates of conformance to ISO 13485 and will not issue certificates of conformance to ISO 13485.” So a “QMSR certified” label on a product has no basis in FDA’s rule. This is our reading, and a customer’s quality team will read it the same way.

What you can claim is simpler and more useful. Your product supports your customers’ QMSR and ISO 13485 obligations. Your records give them validation evidence they can reuse. Your product keeps secure, time-stamped audit trails.

Here is the same idea as a short list for your website and RFP answers:

• Safe to write: “designed to support customers’ QMSR and ISO 13485 obligations”.
• Safe to write: “provides validation evidence customers can reuse”.
• Safe to write: “secure, time-stamped audit trails”.
• Avoid: “QMSR compliant software”, “QMSR certified”, “FDA approved”.
• Avoid: “pre-validated, so you do not need to validate”.

The last one deserves a word. FDA does say that for some lower-risk functions, vendor evidence may be all the assurance a customer needs. For everything else, the customer decides what more is needed, so a blanket “no validation required” promise is one your customer cannot accept.

Certificates follow the same logic. An ISO 13485 certificate does not exempt a device maker from FDA inspection, and your own certificates are one input to a customer’s assessment of you. They help, and the customer still does the assessment.

Case Study: Automated Validation Evidence in a QMS Vendor’s Product

The evidence pattern from the previous section is cheapest when the product produces it on its own. Here is an example from our engineering work with MasterControl, which builds quality, manufacturing and compliance software for life sciences and other regulated industries.

Before the project, MasterControl’s customers faced validation cycles that ran for weeks. The work was manual, spread across legacy and modern systems, and there was no automated way to produce audit evidence.

A team of 3 Zoolatech engineers worked inside MasterControl’s product and built the Validation on Demand framework together with the MasterControl team. The framework runs end-to-end validation checks and generates a report on every run.

The case record reports three results:

• Validation cycles cut from weeks to 10–20 minutes.
• 100% of workflow runs auto-generate standardized, audit-ready reports.
• Updates and configuration changes ship without lengthy revalidation gates.

Two notes on reading these numbers. The case record does not define a validation cycle. It says the framework runs end-to-end validation and generates a report on every run, so do not read 10–20 minutes as the length of a customer’s whole validation project. This is one project, and your results will depend on your product.

The case does not mention QMSR, ISO 13485, or Part 11, and we do not present it as a “QMSR case”. It shows the pattern from the table above in a product. Every run generates an audit-ready report, and updates ship without lengthy revalidation gates.

In a separate project, Zoolatech engineers helped MasterControl replace paper logbooks with digital logbooks that keep a complete, audit-ready history.

QMSR Checklist for QMS, MES and LIMS Vendors

A QMSR checklist for a software vendor is mostly about documentation and release evidence. Start by mapping which of your product’s functions your customers use as QMS or production software. Then make each release ship evidence your customers can reuse, keep your supplier-assessment kit ready, and check that your claims match what FDA expects.

Each item below comes with a simple test, so you know when to tick it off.

1. Map your product’s functions to FDA’s descriptions of QMS and production software

Go through your product module by module and write down what each one does for your customer. The item is complete when each module has a short note on its intended use that your customers can drop into their risk assessment.

2. Ship a release evidence pack

For every release you make, record what changed, its impact, the tests you ran, and their results. Tick this off once every release has such a pack and the older packs stay retrievable, because investigators may review older records.

3. Keep your test evidence as electronic records from your tools

Use the logs, audit trails, run reports your tools already produce, and avoid screenshots. The test here is whether you can export your results with timestamps and version numbers.

4. Prepare your supplier-assessment kit

Put together your SOC report and certificates if you have them, plus your SDLC and QA documentation. Your kit is ready when you can answer a standard customer questionnaire without new work.

5. Have your service agreement template ready

Make sure it covers security, data integrity, privacy, availability, change management, and business continuity, the topics in FDA’s SaaS example. Count it as finished after your legal and quality teams have reviewed it.

6. Check the integrity of the records in your product

Secure, time-stamped audit trails, encryption, and Part 11 features belong here. Close this item when you have described these controls in a document your customers can file.

7. Support FDA-specific records where your product holds them

These are the UDI for each device or batch, complaint investigations, and labeling release and inspection results. The goal is that your customer can show these records to an investigator straight from your product.

8. Offer the ISO 13485 record names in your templates and reports

Keep DMR, DHF, and DHR as aliases so nobody loses their way. Your customers should be able to use the new names and still find the old ones.

9. Review your marketing and RFP wording

Use the safe wording from the section on claims. This item is done when none of your pages or answers call your product QMSR-compliant or certified.

Final Word

Sorting customer requests into “the rule says so” and “their procedure says so” takes time. You have to read FDA’s documents, your customers’ questionnaires, and your own release process side by side before the picture is complete.

The effort pays off. FDA QMSR does not regulate your company, but your customers’ inspections now look at software validation, software changes and supplier evidence, and a release your customer cannot assess quickly is a release that waits.

Our advice is to make evidence a by-product of your releases instead of a separate project. Vendors whose updates arrive with test records make their customers’ QMSR work smaller, and that is what keeps a product in use after an inspection.

If you want a second opinion on where that evidence can come from in your product, we are ready to review your release process and talk through your options.