FDA Warning Letter Tells Software Device Makers That Retraining AI Algorithms and Moving to the Cloud Can Require a New 510(k)

FDA’s Center for Devices and Radiological Health (CDRH) released a Warning Letter finding O.N. Diagnostics’ latest vertebral fracture assessment software is adulterated and misbranded because the company introduced a new algorithm and moved the product to the web without a new premarket notification.

Why it matters: For software as a medical device (SaMD), a routine version release can be a regulatory event.

The Warning Letter

VirtuOst VFA analyzes spine CT images to identify and grade vertebral fractures and help physicians manage osteoporosis, and was cleared in 510(k) K171435. Following a March 2026 inspection, FDA concluded that version 3.0.0 went beyond the clearance, making the device adulterated under section 501(f)(1)(B) of the Federal Food, Drug, and Cosmetic Act (FDCA) and misbranded under section 502(o) for failure to submit a new 510(k) under 21 C.F.R. 807.81(a)(3)(i). FDA asked the company to stop distributing version 3.0.0, citing three changes that each independently required a new 501(k):

• New machine learning algorithm. Release notes showed a new machine learning model for vertebral landmarking. FDA explained that a model trained on different data, with a different architecture, or optimized for a different objective may perform differently across patient populations, imaging equipment, and clinical settings, and that the change “fundamentally changes how the device performs, fails, and affects patients.” Inadequate validation, FDA warned, could lead to missed or delayed diagnoses and overreliance on device output.
• Move to web-based architecture. Shifting from a desktop application to a web platform introduced network-exposed attack surfaces, authentication vulnerabilities, and other cybersecurity risks. The company acknowledged during the inspection that the change expanded its “cyberattack surface area.”
• Technology platform migration. The change required re-verification and re-validation of the entire codebase, including third-party libraries, and noted that FDA had not reviewed the device’s Software Bill of Materials (SBOM) or documentation of third-party components affected by the migration.

FDA also cited violations of the Quality Management System Regulation (including corrective action and supplier controls) and of the Medical Device Reporting requirements.

Lessons for SaMD Manufacturers

O.N. Diagnostics held a 510(k) clearance; its violations arose from the typical evolution of a software product. That is why SaMD and AI-enabled device developers should:

• Treat a new or retrained model as a potential regulatory change. FDA focused on whether the new model could perform or fail differently, not on whether it was intended as an improvement. Changes to training data, architecture, or optimization objective should trigger a documented assessment under 21 C.F.R. 807.81(a)(3) and FDA’s software change guidance. FDA investigators read release notes and version control logs.
• Validate before release, across the intended use population. Each model change should be supported by performance testing on representative, independent data, including subgroup analyses.
• Plan for iteration with a Predetermined Change Control Plan (PCCP). Companies that expect to update their algorithms regularly should consider seeking an authorized PCCP under FDCA section 515C, which allows pre-specified, validated modifications without a new 510(k).
• Recognize that architecture changes are safety changes. FDA treated the web migration as an independent basis for a new 510(k). Moving to cloud, browser-based, or software-as-a-service (SaaS) delivery changes the threat model and may implicate FDA’s cybersecurity requirements for “cyber devices” under FDCA section 524B. Before migrating, update threat modeling, cybersecurity risk assessments, and penetration testing, and evaluate whether a submission is required.
• Maintain a current SBOM. FDA flagged that it had not reviewed the device’s SBOM or the third-party components affected by the platform migration. Keep the SBOM accurate, assess the impact of library and framework changes, and re-verify and re-validate when the underlying stack changes.
• Align regulatory assessments with what the engineering record shows. FDA quoted the company’s own acknowledgment of an expanded “cyberattack surface area” to support its conclusion. Engineering and regulatory teams should share a consistent, documented view of how significant changes were assessed, so that the record presented to investigators supports the company’s regulatory decisions.
• Embed software change assessment in the quality system. Regulatory assessment of software changes belongs in design controls and change management procedures, not ad hoc decisions at release time.

What’s next: As AI-enabled devices proliferate and more products move to cloud-based delivery, we expect FDA to continue scrutinizing whether marketed software still matches what the Agency actually reviewed. SaMD manufacturers should take this opportunity to inventory software releases made since their most recent clearance, confirm that each significant change was either cleared or appropriately documented as not requiring a submission, and evaluate whether a PCCP or a pre-submission meeting would support their product roadmap.

If you have any questions, please contact Georgia Ravitz, Shari Esfahani, Thora Johnson, Amy Joseph, Jeremy Sherer, or another Orrick team member.