Software as a Medical Device (SaMD) has become one of the most “regulation-dense” topics in MedTech. A single product may simultaneously be a medical device or IVD (MDR/IVDR), an AI-enabled system (AI Act), an app distributed via online platforms (DSA), and a solution processing health data in the EHDS ecosystem. In 2025, several EU guidance updates materially clarified these overlaps—changing how we design, validate and clinically evidence software products.

EN 62304: software life-cycle validation as “state of the art”

EN IEC 62304 defines life-cycle requirements for developing and maintaining medical device software—both when software is the device and when it is embedded or integral to a device. It structures safety classes (A/B/C), requirements, architecture, verification, configuration management and problem resolution.

In practice, “life-cycle validation” is not a single report, but evidence that:

  • risks (including SOUP and cybersecurity aspects) are identified and controlled,

  • requirements are testable and traceable,

  • unit/integration/system testing covers critical functionality,

  • changes and versions are controlled to preserve safety and compliance.

Beyond MDR/IVDR: what else matters for SaMD?

For most SaMD manufacturers, compliance does not stop at MDR/IVDR. Increasingly, teams must account for:

AI Act

A phased timeline: prohibited practices and AI literacy obligations have applied since 2 February 2025; rules for high-risk AI embedded in regulated products (incl. medical devices) have an extended transition period until 2 August 2027.

EHDS

The Regulation entered into force on 26 March 2025, impacting interoperability and the sharing/re-use of health data.

Cyber Resilience Act / NIS2

Rising expectations on cybersecurity, vulnerability handling and supply-chain controls.

Platform distribution

App stores and online platforms raise “who is responsible for what” questions across the value chain.

2025 updates you should not miss

MDCG 2019-11 rev.1 (June 2025)

Updated EU guidance on software qualification and classification. Rev.1 reinforces the need for a crystal-clear intended purpose, expands considerations on modules, and updates examples/interpretations (including EHR/EHDS aspects).

MDCG 2025-4 (June 2025)

Practical guidance on making medical device software apps available via online platforms. It distinguishes when a platform acts as an intermediary service provider (DSA) versus a distributor/importer, and outlines key information that should be visible to patients/users.

MDCG 2025-6 (June 2025)

An FAQ on the interplay between MDR/IVDR and the AI Act. For SaMD/AI, the most relevant topics include human oversight, traceability, cybersecurity, post-market monitoring, and how changes after placing on the market affect obligations.

SaMD or “just software”? A pragmatic qualification path

  • Intended purpose – does the manufacturer claim a medical purpose (diagnosis, monitoring, treatment, prevention, etc.)?

  • Clinical decision relevance – does the software provide information used for diagnostic/therapeutic decisions (Rule 11), or is it limited to storage/transfer?

  • MDR or IVDR? If the output relates to in vitro diagnostics (e.g., specimen-based results), IVDR rules apply.

  • Use MDCG 2019-11 rev.1 as your map – definitions, decision figures and examples help avoid “borderline” surprises.

What does this change for clinical evidence and development?

Evidence, verification and validation – the more the software drives clinical decisions, the higher the expectations on evidence (clinical, analytical, usability) and change control.

AI in scope – add model life-cycle controls (performance monitoring, drift, vulnerability handling, human oversight).

App distribution – how software is made available impacts responsibilities and user-facing information duties.

Key highlights

  • 2025 clarified SaMD distribution on platforms (MDCG 2025-4) and the MDR/IVDR ↔ AI Act interface (MDCG 2025-6).

  • MDCG 2019-11 rev.1 strengthens intended purpose discipline and updates qualification/classification examples.

  • EN IEC 62304 remains a backbone for demonstrating software life-cycle compliance.

Source documents

We recommend reading the source documents end-to-end, especially if your product reaches patients as an app or supports clinical decision-making.

MDCG 2019-11 rev.1 (June 2025):
https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf

MDCG 2025-4 (June 2025):
https://health.ec.europa.eu/document/download/ec9b0f40-7f82-43a7-b833-ebd45b772eae_en?filename=mdcg_2025-4_en.pdf

MDCG 2025-6 (June 2025):
https://health.ec.europa.eu/document/download/b78a17d7-e3cd-4943-851d-e02a2f22bbb4_en?filename=mdcg_2025-6_en.pdf

AI Act timeline (EC):
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

EC guidelines (AI prohibited):
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-guidelines-prohibited-artificial-intelligence-ai-practices-defined-ai-act

EHDS info (EC):
https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en

IEC 62304 (IEC Webstore):
https://webstore.iec.ch/en/publication/22794

CRA (EC):
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

NIS2 (EC):
https://digital-strategy.ec.europa.eu/en/policies/nis2-directive