FDA’s Computer Software Assurance 2026: Changes and What to Do Next 

On February 3, 2026, the FDA released an updated final guidance, Computer Software Assurance for Production and Quality Management System Software, superseding the September 24, 2025 final guidance and aligning CSA expectations to the new Quality Management System Regulation (QMSR). The document reframes assurance of software used in device production and the quality management system (QMS) around intended use and process risk, with explicit ties to ISO 13485:2016 now incorporated by reference into 21 CFR 820.

Below is a walkthrough of this guidance to see the history of changes, the rationale behind these changes and FDA’s guiding principles, and what steps manufacturers can take now to become compliant.

CSA in 2026

CSA covers software used as part of device production or the QMS—including on‑prem, SaaS/IaaS/PaaS, analytics, automation, and even AI/ML tools when used for production/QMS purposes. It does not cover device software functions (SiMD or SaMD), which remain governed by device software guidance and verification/validation rules.

The guidance centers on intended use, process risk, right‑sized assurance activities, appropriate records, emphasizing that “high process risk” features warrant more rigorous, often scripted or hybrid testing, while “not high” risks may be covered with leaner methods like exploratory or scenario testing. CSA is also approached as not a one‑time event, but performed in a lifecycle; the updated final underscores the importance of maintaining the validated state, including when software changes occur.

Historical Draft Updates of the CSA Guidance

1) Regulatory alignment is updated for QMSR/ISO 13485

• Then: the title used “Quality System” and the draft guidance was mapped primarily to 21 CFR 820.70(i).
• Now: the title now uses “Quality Management System” and anchors to QMSR along with explicit references to ISO 13485:2016 subclauses (e.g., 4.1.6, 7.5.6, 7.6) for software validation obligations.

2) A new Definitions section—cloud models are formally defined

• Then: No standalone definitions; cloud terminology wasn’t formalized in the draft guidance.
• Now: A dedicated Definitions section adopts NIST‑based definitions for Cloud, IaaS, PaaS, and SaaS, clarifying how these deployments fit into CSA decision‑making.

3) The risk scope and framework explicitly calls out automation, analytics, and AI/ML

• Then: The draft guidance introduced the framework but didn’t explicitly list AI/ML or bots as examples.
• Now: The final guidance states the approach “can be applied, but is not limited, to automation tools (e.g., bots), data analytic tools, AI/ML tools, and cloud computing when used as part of production or the QMS.”

4) Appendix A gains a new, hands‑on example: SaaS PLM

• Then: The draft guidance had three examples (NCMR, LMS, BI applications).
• Now: The final guidance adds Example 4: SaaS PLM, illustrating intended use analysis, risk rationale, and right‑sized assurance for a cloud system that maintains quality records.

5) New subsection on “Production or QMS Software Changes”

• Then: Changes were implied but not given their own subsection.
• Now: The final guidance explicitly covers changes, reinforcing continuous assurance and risk‑scaled rigor for updates and configurations.

6) The “Appropriate Record” is more prescriptive

• Then: The draft guidance introduced the concept but left more latitude on content.
• Now: The final guidance outlines specific elements, such as intended use, risk‑based rationale, objectives tested, testing performed, issues found, and conclusion, prescribing more concise, inspector‑friendly documentation.

7) Dedicated 21 CFR Part 11 section clarifies e‑records/e‑signatures scoping

• Then: The draft did not include a standalone 21 CFR Part 11 section.
• Now: The final guidance adds “Considerations for Electronic Records Requirements,” clarifying when 21 CFR Part 11 applies for records, with a focus on predicate‑rule QMS records, and steering teams away from burdensome routine logs.

8) More granular high‑process‑risk indicators

• Then: The draft guidance had high risk vs. not high risk comparisons, with broad descriptions.
• Now: The final draft expands indicators—for instance, software that could lead to severe harm, such as those that maintain essential process parameters, performs automated acceptance/rejections, execute automated process corrections, produce labeling necessary for safe use, or automate safety‑critical surveillance (e.g., cybersecurity) can be considered high process risk. Use scripted or hybrid testing, robust traceability, and documented rationale for these features; use exploratory testing for low‑risk features with clear objectives and acceptance criteria.

Practical Steps for Manufacturers to Comply with CSA

1. Update SOPs and templates
   Refer to QMSR/ISO 13485 clauses (e.g., 4.1.6, 7.5.6, 7.6) for validation policy and work instructions; update forms to capture appropriate record elements enumerated in the final CSA guidance.
2. Classify software by intended use and process risk
   Break complex systems down to feature/function level, decide on high vs. not‑high process risk systems, and scale assurance activities accordingly (scripted/hybrid for high; exploratory/scenario for not‑high).
3. Right‑size cloud/SaaS assurance
   Apply the new cloud definitions; leverage vendor evidence and documentation for platform controls while defining configuration, access, data integrity, and QMS record elements in the environment (see SaaS PLM example for a pattern).
4. Scope 21 CFR Part 11 precisely
   Focus controls on predicate‑rule QMS records and document scoping decisions.
5. Embed change‑driven CSA
   Treat configuration updates, vendor releases, and workflow changes as CSA triggers with risk‑scaled impact assessments and testing.

Bottom line

The new CSA update makes it easier to be both compliant and efficient. Additional references to the QMSR/ISO‑13485 framework, formalized concepts, clarifications on electronic records demonstrate the FDA’s expectations are on what lean, risk‑based assurance looks like in practice. By understanding the rationale behind these updates, and by revising procedures, records, and change process around these updates, validation can be made more efficient with strengthened controls for improved compliance. To read more, visit our guide for CSA vs CSV here.