Medical Device Software Regulations in 2026: What Matters Now
Key takeaways
- QMSR is now in force. As of February 2, 2026, FDA quality system requirements are live under QMSR, and device inspections have shifted to the updated compliance program.
- FDA AI expectations are getting harder to retrofit. The lifecycle guidance remains draft, but PCCP guidance is final, which raises the bar for documented model changes, validation, and post-market control.
- Medical AI in Europe now sits across two frameworks. MDR/IVDR and the AI Act are complementary, not interchangeable, and need explicit mapping across quality, data, oversight, and technical documentation.
- Two EU deadlines matter next. EUDAMED’s first four modules become mandatory on May 28, 2026, and Cyber Resilience Act reporting obligations begin on September 11, 2026.
- The AI Act timetable is still moving. The current August 2026 / August 2027 structure remains the baseline, but an active EU simplification proposal could delay some high-risk obligations.
If you build medical device software, 2025 was the year vague regulatory expectations became more concrete in guidance, implementation timelines, and reviewer focus.
The FDA became more specific about the AI lifecycle evidence. The EU made the interaction between MDR/IVDR and the AI Act more explicit for medical AI. Cybersecurity stopped being a checkbox and became a quality system and submission obligation.
We spent the last year tracking these changes across both sides of the Atlantic. Below is our consolidated review based on publicly available sources and our reading of applicable FDA, MDR/IVDR, and related EU requirements and guidance of what actually changed, how it lands on different roles inside development organizations, and what 2026 is likely to require in practice, whether teams feel ready or not.
United States: FDA Narrowed the Interpretation Gap
AI-enabled device software moved into lifecycle governance
On January 7, 2025, the FDA released draft guidance on AI-enabled device software functions. The significance is not the document itself but the framing. FDA’s draft guidance makes lifecycle evidence for AI-enabled device software functions more explicit and submission-oriented.
For submissions, the draft guidance indicates that the FDA expects to see:
- Clear model descriptions and architecture context
- Documented data lineage for training, validation, and test datasets
- Bias detection and mitigation across relevant demographic subgroups
- Defined human-AI interaction and oversight
- Post-market performance monitoring plans
- A Predetermined Change Control Plan (PCCP) describing how algorithms evolve
FDA’s January 2025 AI-enabled device software guidance remains draft, so lifecycle expectations are still being signaled rather than fully settled in final guidance.
PCCP is different: FDA finalized PCCP guidance for AI-enabled device software functions in August 2025, which makes expectations around predefined modifications, validation methods, implementation, and impact assessment more concrete. It is no longer just a directional idea, but rather a more formal part of how FDA expects manufacturers to define in advance what may change, how those changes will be evaluated, and what performance limits must continue to hold.
Although the lifecycle guidance is still drafted, that limits formal enforcement, not necessarily reviewer expectations.
Sex-specific clinical evidence became a planning requirement
On March 31, 2025, the FDA finalized guidance on the evaluation of sex-specific data in medical device clinical studies. The message is straightforward. Clinical protocols must plan for sex-based analysis upfront, including recruitment targets and statistical methods. Retrospective stratification is no longer sufficient.
Cybersecurity has become enforceable quality evidence.
In June 2025, FDA finalized its cybersecurity premarket guidance. FDA then issued a superseding version on February 3, 2026. The direction did not change: cybersecurity evidence now needs to be visible in both the quality system and the premarket submission.
Manufacturers are now expected to demonstrate:
- A vulnerability management plan
- Evidence that no critical unresolved vulnerabilities exist at submission time
- A complete Software Bill of Materials covering all components
- Integration of a Secure Product Development Framework into design controls
Cybersecurity is now explicitly tied to safety, quality system expectations, and submission readiness.
Submission mechanics tightened
On October 1, 2025, De Novo submissions became mandatory through eSTAR, unless exempted. Combined with existing 510(k) requirements, this pushes manufacturers toward structured, machine-readable submissions and exposes gaps in traceability and consistency.
QMSR is no longer theoretical
The FDA’s Quality Management System Regulation became effective on February 2, 2026. It incorporates ISO 13485:2016 by reference into the U.S. device quality system framework, and FDA is now inspecting under the updated QMSR compliance program. This change drove significant preparation work throughout 2025.
European Union: Dual Regulation Became Explicit
The AI Act moved from debate to staged enforcement
The EU AI Act entered into force in 2024, but 2025 marked the start of real applicability.
Key milestones:
- February 2, 2025: Prohibited practices banned, AI literacy obligations apply
- August 2, 2025: General-purpose AI obligations begin
- August 2, 2026: Most high-risk AI obligations apply
- August 2, 2027: Full high-risk classification for AI embedded in regulated products
The 2027 date caused confusion. While some AI Act obligations for AI embedded in regulated products apply later under the Act’s transition framework, notified bodies and competent authorities may still look for evidence of AI-related readiness before then.
These dates remain the current legal baseline. However, as of March 2026 they should not be treated as politically settled: the Commission’s simplification proposal would, if adopted, push the general high-risk deadline out by up to 16 months and the deadline for AI embedded in regulated products out by up to 12 months, which would move those outer dates to December 2, 2027 and August 2, 2028 respectively.
The interaction between MDR, IVDR, and the AI Act was clarified more explicitly
MDCG guidance (MDCG 2025-6) published in 2025 clarified that for medical AI, MDR/IVDR and the AI Act apply simultaneously and complement each other; MDR or IVDR compliance does not replace AI Act obligations.
In practice:
- MDR or IVDR governs: Clinical safety, performance, PMS, and vigilance
- The AI Act governs: Data governance, robustness, transparency, and human oversight
In many cases, medical AI now needs to be mapped deliberately across two regulatory frameworks at the same time.
App stores became regulated distribution channels.
MDCG 2025-4 clarified expectations for medical device software distributed through app stores or online platforms. In practice, listings may need to present manufacturer identity, intended purpose, and safety information consistent with the product documentation and applicable MDR/IVDR requirements.
App store pages should increasingly be treated as part of the regulated information environment around the device.
EUDAMED timelines became real
The first four EUDAMED modules become mandatory on May 28, 2026. This includes actor registration, device and UDI registration, notified body and certificate information, and market surveillance.
For many manufacturers, preparation work likely needs to start well before that date.
Simplification remains a signal, not relief.
The European Commission published a proposal on December 16, 2025, to simplify MDR and IVDR processes and encourage digital documentation. It is still under review. Current compliance expectations should not be assumed to change unless and until the proposal is adopted and implemented.
The Cyber Resilience Act added security obligations.
The EU Cyber Resilience Act entered into force on December 10, 2024. Incident reporting obligations start September 11, 2026. For connected medical software, this adds another layer of security and reporting requirements alongside MDR.
What to Expect in 2026: Regulatory Timeline for Medical Device Software
February 2, 2026
QMSR enforcement begins in the US. FDA inspections are now being conducted under the updated QMSR compliance program, with the U.S. device quality system framework incorporating ISO 13485:2016 by reference. Internal audits, management reviews, supplier controls, and training records are inspected in practice.
May 28, 2026
EUDAMED core modules will become mandatory in the EU on May 28, 2026. Actor registration, device and UDI data, notified body and certificate information, and market surveillance information must be accurate and complete.
Mid 2026
FDA review posture may continue to tighten around AI lifecycle evidence. Cybersecurity scrutiny shifts from documentation toward lifecycle and post-market behavior.
August 2, 2026
Core AI Act obligations start to apply more broadly. For affected products, AI governance, data controls, bias monitoring, and human oversight, and related documentation should already be taking shape well in advance. This remains the current baseline, although the Commission’s active simplification proposal could delay some high-risk obligations if adopted.
September 11, 2026
Cyber Resilience Act incident reporting obligations begin for connected software products in the EU.
Late 2026
Regulatory reliance and efficiency initiatives may expand in a limited number of areas. Manufacturers with coherent, globally mapped technical documentation are likely to benefit first.
Bottom Line
2025 turned regulatory principles into specific expectations. AI systems increasingly need documented lifecycle control. Cybersecurity increasingly needs quality system integration. Evidence increasingly needs digital traceability. Distribution channels increasingly need regulatory oversight. The question is increasingly less whether to adapt, and more whether teams are doing the work early enough to avoid being forced into it under inspection pressure in 2026.
What This Means for Development Teams
If You Are Building AI or ML Features
AI evidence is becoming harder to assemble retrospectively. Both the FDA and the EU frameworks increasingly point toward generating that evidence as part of the development and lifecycle process.
Practically, this means:
- Dataset versioning must capture sourcing, cleaning, labelling, and inclusion decisions
- Model documentation must be generated during development, not at submission time
- Bias and performance monitoring must continue in production, not stop at validation
- Performance monitoring must detect potential drift or degradation and trigger an investigation
The PCCP changes architecture decisions. Teams must decide upfront which model parameters can change, what validation is required, and which performance thresholds must hold.
A practical implementation is to align CI/CD pipelines with PCCP-defined validation and to use production monitoring to detect when performance moves outside predefined acceptable bounds, triggering investigation, alert, or other controlled action.
For EU-facing products, this work must satisfy both MDR and IVDR evidence and AI Act requirements. They are not interchangeable. They are complementary and need explicit ownership.
If You Handle Security or DevOps
Cybersecurity is no longer just a documentation exercise. It increasingly needs to be visible in day-to-day development, release, and post-market practices.
In practice, your workflow may need to support:
- Automatic SBOM generation from building pipelines
- Integration with vulnerability feeds such as NVD or GitHub advisories
- Defined CVE triage timelines and responsibilities
- Documented safety impact assessments for affected components
Threat modelling becomes a formal design input. Penetration test results, security architecture, and vulnerability assessments must feed into design reviews and release decisions.
For EU markets, Cyber Resilience Act incident reporting starts September 11, 2026. Align CRA incident handling existing MDR vigilance workflows early to avoid parallel processes.
If You Work in Quality or Regulatory
The QMSR transition is the largest structural change for US manufacturers in years.
By February 2, 2026:
- FDA inspections are now being conducted under the updated QMSR compliance program, with the U.S. quality system framework incorporating ISO 13485:2016 by reference
- Internal audits and management reviews to receive inspection attention
- Risk-based quality management applies to the quality system itself
Legacy concepts like Device Master Record, Device History File, and Device History Record are no longer emphasized in the same way as standalone FDA-specific record categories, as the updated framework aligns more closely with ISO 13485-style documentation structures. Procedures, templates, and tools need updating.
What should already be underway:
- Completed gap analysis against QMSR
- Updated procedures and templates throughout 2025
- At least one full internal audit cycle before enforcement
- Strengthened supplier controls and management review processes
In the EU, quality and regulatory teams must manage dual compliance. Evidence matrices mapping MDR or IVDR and AI Act requirements to concrete artifacts are essential. Without a named owner for AI risk management, gaps emerge late.
App store content should generally be brought into regulatory review workflows. In practice, teams should treat listings with discipline similar to other controlled product information. They need approval, version control, and alignment with technical documentation.
If You Are in Product or Engineering Leadership
The regulatory direction appears broadly consistent across regions: evidence increasingly needs to be digitally connected and traceable.
Requirements must be traced to hazards. Hazards must be traced to controls. Controls must trace tests. Tests must be traced to releases. Releases must be traced to post-market data.
Manual document assembly is increasingly difficult to scale under this model.
Leadership decisions should focus on:
- Assessing whether ALM, PLM, and QMS tools are integrated or siloed
- Verifying that tools can generate eSTAR-compatible and EUDAMED-ready outputs
- Standardizing identifiers, versioning, and building metadata across systems
- Funding process redesign, not just tool purchases
EUDAMED preparation is a coordination problem. Regulations define requirements. Engineering provides versioning and builds data. Operations keep information current. Without explicit ownership, the system fails under deadline pressure.