A practical guide for medical device and Software-as-a-Medical-Device (SaMD) teams preparing for the next edition of the software life-cycle standard.

IEC 62304 is the international standard that defines the life-cycle processes for medical device software. Its long-awaited second edition reshapes how software rigor is determined, widens the scope to all health software, adds a dedicated AI planning requirement, and is built to sit cleanly alongside modern cybersecurity practice. Here is what is actually changing, what is hype, and how to prepare.

What is IEC 62304, and why a new edition now?

IEC 62304 specifies the processes, activities and documentation that teams must follow to develop and maintain medical device software, whether it is embedded firmware (Software in a Medical Device, SiMD) or standalone software (Software as a Medical Device, SaMD). It is recognized by the U.S. FDA as a consensus standard and accepted in the EU as EN 62304 under the Medical Device Regulation (MDR) and IVDR. Crucially, it is a process standard: it tells you which life-cycle activities are required, not what your software must do.

The current version, IEC 62304:2006+A1:2015, has anchored medical software development for nearly two decades. Since 2006, however, AI/ML has moved into diagnostics, cybersecurity has become a pre-market requirement, and “health software” that is not a regulated device has proliferated. Edition 2 is the response — a structural refresh rather than a cosmetic amendment. For background on how classification evolved under the 2015 amendment, see this explainer on IEC 62304 software safety classifications.

The headline change: three classes become two rigor levels

The single most consequential proposal in Edition 2 is the retirement of the three-tier safety classification (Classes A, B, C) in favour of two Software Process Rigor Levels. This removes the long-debated line between “non-serious” and “serious” injury and asks a simpler question: can the software contribute to harm at all?

Sources: IEC 62304 Ed. 2 Design Specification and Change Rationale (IEC SC62A); see references below.

What it means for developers, by current class

Legacy Class A → Level I

Baseline engineering effort changes little — but not nothing. Edition 2 reflects “state of the art” by expecting some architectural planning across all levels, so Level I software now warrants foundational architectural oversight that Class A could previously skip.

Legacy Class B → Level II (the big jump)

This is where the workload concentrates. Because Class B folds into Level II, those products must rise to the development, testing and documentation rigor formerly reserved for Class C: detailed software architecture, unit-level verification, and end-to-end traceability down to software units. Teams sitting on a large Class B portfolio should plan a meaningful remediation effort.

Legacy Class C → Level II

Largely business as usual. Class C teams already practise the highest tier of life-cycle rigor, so Level II should feel familiar. Sensaco’s overview of developing medical device software walks through the design-control backbone that Level II expects.

Broader scope: from “medical device software” to “health software”

Edition 2 widens its boundary from strictly medical device software to the broader category of health software, aligning with the product-safety standard IEC 82304-1. This positions IEC 62304 as a single life-cycle reference across the health-software continuum — including clinical software that may not meet a regulatory device definition.

One important and often-missed consequence of the scope change: because non-device health software cannot be obliged to follow medical-device standards, Edition 2 removes the normative references to ISO 13485 and ISO 14971. The standard instead relies on those companion standards being supplied by the surrounding regulatory framework. In practice, if you build a regulated medical device you will still apply ISO 13485 and ISO 14971 — the draft simply notes that ISO 14971 application is expected for medical software rather than mandating it inside IEC 62304 itself.

AI in Edition 2: less than the headlines claim

Despite a lot of “AI lifecycle” marketing, the AI footprint in Edition 2 is deliberately modest. According to contributors on the drafting team, AI was intentionally kept from dominating the standard. Concretely, the draft adds:

• One normative requirement — “AI Planning” — that applies to both Level I and Level II. It requires you to plan AI-specific activities (data management, performance evaluation, documentation), but it is a planning clause, not a full technical V&V regime.
• One informative annex (Annex E) offering structured guidance on AI/ML development life-cycle activities — the first time a major medical software standard has done so. Being informative, it is guidance rather than a hard requirement.

The practical takeaway: deep technical verification and validation for AI/ML is expected to arrive through separate guidance (e.g. FDA AI/ML guidance and IMDRF Good Machine Learning Practice), not from IEC 62304 alone. Notified Bodies and reviewers will still expect you to study Annex E carefully and document your training/validation data strategy, so treat data selection as a genuine design control even though the clause itself is light.

Other structural changes worth planning for

• QMS general requirements removed (Clause 4.1). Edition 2 strips the general quality-system requirements, leaning on your wider QMS (e.g. ISO 13485) to cover them — reinforcing that IEC 62304 is a process standard, not a QMS.
• Legacy software moves to an informative annex. Guidance for software developed under earlier editions (including how to handle former Class B now mapped to Level II) shifts into an annex. Expect to update — not blindly re-engineer — your software development plan, and to upgrade legacy Class B documentation to Level II either at the next change or on a risk-based schedule.
• Clearer development vs. maintenance split. The draft separates new-software development from maintenance, allowing a leaner process for rapid changes that address urgent problems.
• “Supporting items to be controlled” clarified. You must control whatever is needed to recreate the software — tools, development environment, settings, data and simulators — made explicit beyond Edition 1’s brief wording.

Cybersecurity and the secure software life cycle

Edition 2’s two-level structure dovetails neatly with the health-software cybersecurity standard IEC 81001-5-1, which was intentionally written to mirror IEC 62304’s clause architecture. The two are complementary: IEC 62304 governs the safety life cycle, while IEC 81001-5-1 layers security activities onto the same phases. Together with ISO 14971, leading teams increasingly run safety, risk and security as one integrated workflow rather than three siloed efforts.

What this means in practice: pair each software requirement with a security view, keep your SOUP/SBOM inventory current for both safety bugs and vulnerabilities, and run security patches through the same verified-release loop as functional fixes so a patch never silently introduces a safety regression. Sensaco’s medical software cybersecurity practice and its strategies for security approvals cover exactly this integration.

An implementation roadmap

1. Gap-analyse now. Map every software item to its future rigor level. Anything currently Class B should be flagged for a Level II upgrade.
2. Upgrade Class B documentation. Author the missing architecture, unit-level verification and traceability that Level II demands — either at the next change or on a documented, risk-based plan.
3. Stand up AI planning. If you ship AI/ML, add an AI plan covering data management, training vs. validation splits, bias considerations and post-market model monitoring, and study Annex E.
4. Integrate security. Align IEC 62304 with IEC 81001-5-1 and your FDA 524B / MDR obligations: threat modeling, SBOM from your SOUP list, and a unified maintenance/patch loop.
5. Decide your timing. EN 62304:2006+A1:2015 stays the state of the art until Edition 2 is published and harmonized (the EU deadline for several key standards has shifted to 27 May 2028). New programs are the ideal place to design to Edition 2 early.

What Edition 2 means for medtech products

At product level, Edition 2 raises the floor and removes ambiguity. The collapse to two rigor levels eliminates the contested “is this B or C?” debate, but it pulls a large share of yesterday’s mid-risk software up to high-rigor expectations. Products that were comfortably Class B now need deeper architecture, unit-level verification and finer-grained traceability — work that is far cheaper to build in than to retrofit during an audit or a submission. Connected and AI-enabled products feel this most: a security-and-safety-by-design posture, a maintainable SBOM, and a documented AI plan move from “nice to have” to “expected evidence.” The upside is a cleaner, more defensible technical file that maps directly onto both EU MDR and FDA expectations — and a faster path through review when reviewers can trace every requirement, risk control and security measure end to end.

What Edition 2 means for medtech organizations

Organizationally, the change is as much about process integration as paperwork. Safety (IEC 62304), risk (ISO 14971) and security (IEC 81001-5-1) can no longer be run by three separate teams on three separate cadences; Edition 2’s structure rewards companies that manage them as one connected system. Expect to refresh SOPs, classification procedures, internal-audit checklists and training; to brief management on transition readiness; and to decide a migration approach for legacy portfolios. Teams that still rely on document-centric, manually maintained traceability will feel the strain most — the Level II jump multiplies the number of links between requirements, design, code, tests, risks and security controls that have to stay consistent. The organizations that adapt fastest will be those that treat compliance as a continuously maintained, tool-supported design-control backbone rather than a pre-audit scramble.

Why Sensaco is the ideal partner to adapt quickly

Preparing for IEC 62304 Edition 2 is precisely the problem Sensaco was built for. As a software-systems consultancy active in medtech since 2002, Sensaco specializes in secure, compliant and agile development of medical software — pre-market and post-market — and helps clients align day-to-day engineering with IEC 62304, ISO 13485, ISO 14971 and IEC 81001-5-1 without sacrificing DevOps velocity. That combination is exactly what an Edition 2 transition demands: deep regulatory insight paired with the practical ability to ship.

Concretely, Sensaco can:

• Run your Edition 2 gap analysis and re-map software items to Level I / Level II, with a defensible plan for upgrading legacy Class B to Level II rigor.
• Build the missing artefacts — software architecture, unit-level verification, and full traceability — using agile, automation-friendly methods (AAMI TIR45) that keep documentation in step with code.
• Integrate security by design via IEC 81001-5-1 and an SPDF aligned to FDA pre-market guidance, including threat modeling, SBOM and a unified patch/release loop.
• Stand up AI planning and the data-control discipline that Annex E and downstream regulators expect.

To make that rigor fast and sustainable, Sensaco pairs its consulting with the right tooling. The right eQMS turns Technical File and quality work into a single source of truth with automated change control, audit trails, consistency checks and instant, branded traceability reporting, pre-loaded with SOPs and templates aligned to MDR/IVDR, FDA QSR, ISO 13485, ISO 14971 and IEC 62304. That is the difference between surviving the Level II jump and absorbing it cleanly: expert hands plus a system that keeps every requirement, risk control and security measure consistent as the standard — and your product — evolves.

Frequently asked questions

References & primary sources

• IEC SC62A — IEC 62304 Edition 2.0 Design Specification (primary draft).
• IEC SC62A/MT49/N0166 — IEC 62304 2nd Edition Change Rationales (primary draft).
• ISO — IEC 62304:2006 (current edition) and ISO 14971:2019, Application of risk management to medical devices.
• Jama Software — Webinar recap with an Edition 2 drafting-team contributor, and the IEC 62304 guide.
• 8fold Governance — Edition 2: big changes in SaMD requirements.
• FDA Section 524B (cybersecurity / SBOM for cyber devices) and EU Regulation 2017/745 (MDR) for the regulatory context referenced above.

This article is for general information and does not constitute regulatory or legal advice. Always work from the published standard and your Notified Body’s / regulator’s current expectations.