EN 62304:2006+A1:2015 is a process standard — it defines how medical device software must be developed and maintained across its life cycle. IEC 82304-1 is a product standard for the safety and security of health software products as a whole — it addresses the finished software product, its accompanying information, and the conditions under which it is safe to use. For Software as a Medical Device under MDR Annex I Section 17, the two standards answer different questions and are used together: EN 62304:2006+A1:2015 governs the development processes that produce the software, and IEC 82304-1 is referenced as the product-level framing for health software as a whole. The MDR is the North Star. Both standards are tools that serve Annex I.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 is a process standard for medical device software life-cycle activities — planning, requirements, design, implementation, verification, release, maintenance, configuration management, problem resolution, and software risk management.
  • IEC 82304-1 is referenced as a product standard for health software, addressing the finished software product and the conditions for its safe use, including accompanying information and the user's operating environment.
  • For Software as a Medical Device under MDR Annex I Section 17, the two standards do not compete — they complement each other. One governs the process, the other frames the product.
  • IEC 82304-1 is not listed in the project's regulatory ground truth catalog and its harmonisation status under the MDR is not confirmed in that catalog. This post frames the standard at a general level and does not cite specific clause numbers.
  • A SaMD startup typically applies EN 62304:2006+A1:2015 in full for the development process and uses IEC 82304-1 as the product-level framing for how the finished software is intended to be deployed, used, and supported.
  • The single largest Subtract to Ship move is to avoid building two parallel documentation sets — the process evidence and the product framing should reference the same artefacts, not duplicate them.

Why SaMD founders end up asking about two standards

The question arrives sooner or later on every SaMD certification project. The team has read EN 62304:2006+A1:2015, built the development plan around it, and started producing the lifecycle evidence. Then somebody — a Notified Body contact, a peer at a regulatory meetup, a consultant the investor suggested — mentions IEC 82304-1, and the founder wants to know whether this is a second standard to implement, a replacement for the first one, or something else entirely.

The short answer is: something else entirely. EN 62304:2006+A1:2015 and IEC 82304-1 are not alternatives and they are not duplicates. They answer different questions about the same software. EN 62304:2006+A1:2015 answers "how was this software developed" — the process question. IEC 82304-1 is referenced in the industry as the framing for "what is this software as a finished product, and under what conditions is it safe to use" — the product question. A competent SaMD file uses both, and the work does not double because the two standards point at the same underlying artefacts from different angles.

This post walks through the distinction, shows where IEC 82304-1 complements EN 62304:2006+A1:2015 for a SaMD startup, explains the harmonisation-status caveat honestly, and lists the common mistakes founders make when they try to apply one standard without the other.

What IEC 82304-1 is at a general framing

IEC 82304-1 is an international standard for health software. At a general framing level, it is concerned with the safety and security of health software products — the finished thing that ends up in the hands of a user — rather than with the internal processes by which the software was produced. The standard sits at the product level: it asks what the software is, what its intended use is, what its operating environment looks like, what accompanying information the manufacturer has to provide, and what the conditions are under which the product is safe and fit for purpose.

The scope of IEC 82304-1 is broader than the medical device scope of EN 62304:2006+A1:2015 in one direction and narrower in another. It is broader because "health software" includes software that is not a medical device under the MDR but is still used in a health context — wellness applications, health-information systems, lifestyle software. It is narrower because it addresses the software as a standalone product, not as an embedded component of a larger device with hardware. For a SaMD startup — software that is itself a medical device and has no hardware — IEC 82304-1 sits directly on top of the product the company is shipping.

Important caveat for this post. IEC 82304-1 is not listed in the project's condensed regulatory ground truth catalog (Sources/CONDENSED-REGULATORY-GROUND-TRUTH.md). Its precise current edition and its harmonisation status under the MDR are not established in that catalog. In this post, the standard is therefore discussed at a general framing level only. Specific clause numbers, section references, and harmonised-standard claims are deliberately not made. Before relying on IEC 82304-1 for a real certification project, verify the current edition, the harmonisation status, and the specific requirements directly against the standard text and the current OJEU listing.

Process standard vs. product standard — the distinction that matters

The cleanest way to understand how EN 62304:2006+A1:2015 and IEC 82304-1 fit together is to hold the process-versus-product distinction firmly.

EN 62304:2006+A1:2015 is a process standard. It defines life-cycle activities a manufacturer of medical device software must perform and evidence. It answers questions like: did you plan the development, did you specify requirements traceably, did you design an architecture, did you implement under configuration management, did you verify at unit and system level, did you manage software risks under EN ISO 14971:2019+A11:2021, did you handle problems, did you maintain the software after release. Every one of those is a process question with a process answer. The evidence is records of activities performed. Post 376 covers this standard in full.

IEC 82304-1 is referenced as a product standard. It is concerned with the software as a finished output. It frames the software as a health product with an intended use, a target user, an intended operating environment, accompanying information (instructions for use, user manuals, technical descriptions of dependencies), and conditions under which the manufacturer claims the product is safe and effective. The evidence is not records of activities; it is the product itself together with the information supplied with it.

The two kinds of evidence do not cover the same ground. A software project can have perfect EN 62304:2006+A1:2015 process evidence — every activity performed, every document traceable — and still have an unclear product-level framing. The user does not know what the software is for, the operating environment is not specified, the accompanying information is thin or missing, and the conditions for safe use are implicit rather than stated. Conversely, a product can have a clean product-level framing and poor process evidence — an excellent user manual wrapping a code base whose development history cannot be audited.

A SaMD that survives a Notified Body review needs both. The process evidence shows that the software was built correctly. The product framing shows that the finished software is presented to the user in a form that supports safe use. The MDR Annex I obligations reach into both.

Where IEC 82304-1 complements EN 62304:2006+A1:2015 for SaMD

For a SaMD startup, the areas where IEC 82304-1 framing adds something EN 62304:2006+A1:2015 does not explicitly cover are consistent across projects. At a general framing level, these are the complements worth attention.

Product-level intended use and operating environment. EN 62304:2006+A1:2015 takes the intended purpose as an input from the manufacturer and the MDR technical file. IEC 82304-1 framing pushes the manufacturer to state the product-level intended use, the target user, and the operating environment — including the hardware, IT networks, and other software the health software is intended to run with — as a first-class product characteristic. For a SaMD, this overlaps with the MDR Annex I Section 17.4 minimum-requirements obligation covered in post 394 on cloud deployment.

Accompanying information. The instructions for use, the user manual, and any other information supplied with the software are treated as part of the product under the IEC 82304-1 framing, not as a separate deliverable. The information has to match what the software actually does, has to be comprehensible to the intended user, and has to cover the conditions the manufacturer has identified as necessary for safe use. This is where many SaMD startups have the largest gap — the engineering side has built a competent process file, and the user-facing documentation has been treated as a marketing afterthought.

Conditions for safe use. The framing asks the manufacturer to state the conditions under which the software is safe to use — user qualifications, environmental assumptions, data quality requirements, dependencies on third-party components, limits of intended use. These conditions have to be consistent across the intended purpose, the accompanying information, the risk file, and the technical documentation. The IEC 82304-1 framing is the forcing function that keeps them consistent when four different documents are being written by four different people.

Post-release product responsibilities. Responsibilities toward the user during the product's operational life — availability of support, provision of updates, handling of reported problems — are part of the product framing, not only the process framing. EN 62304:2006+A1:2015 covers the maintenance process (how the manufacturer performs maintenance activities); the IEC 82304-1 framing covers what the manufacturer commits to as a product (what the user can expect from the product over time).

In each of these areas the complementarity is real. Neither standard makes the other redundant. The process standard shows that the software was built right. The product standard, applied at a general framing level, shows that the finished software is presented to the user in a way that supports safe and effective use in the intended environment.

When to apply both for a SaMD startup

The pragmatic answer for a SaMD startup is: apply EN 62304:2006+A1:2015 in full for the development process, and use IEC 82304-1 at a framing level to make sure the product-level characteristics of the finished software are stated, consistent, and tied to the MDR Annex I obligations.

"Apply EN 62304:2006+A1:2015 in full" means run the life-cycle activities described in post 376 — software development planning, requirements, architecture, design, implementation, verification, release, maintenance, software risk management, configuration management, and problem resolution — at the depth the software safety class (A, B, or C) requires. This is the non-negotiable process spine of a SaMD.

"Use IEC 82304-1 at a framing level" means, for the SaMD startup working under the caveat above, treating the standard as a product-framing checklist rather than a clause-by-clause compliance exercise. The questions the framing forces are the valuable part: is the product-level intended use stated, is the operating environment specified, is the accompanying information complete and consistent, are the conditions for safe use explicit, are the post-release product commitments stated. These questions can be answered and documented inside the MDR technical file regardless of whether the standard is applied as a formal presumption-of-conformity tool or as a product-framing discipline.

For a startup targeting first CE marking, our practical recommendation is: build the EN 62304:2006+A1:2015 process evidence as the primary lifecycle file, and produce a product-level description of the SaMD — intended use, operating environment, user profile, accompanying information, conditions for safe use, post-release commitments — as a companion document inside the technical file. If a Notified Body asks about IEC 82304-1 specifically, the answer is that the product-level framing is in place and the specific harmonisation position of the standard will be confirmed against the current OJEU listing before the standard is cited as a presumption-of-conformity tool.

The harmonisation status caveat — being honest about what we know and do not

The project's regulatory ground truth catalog (Sources/CONDENSED-REGULATORY-GROUND-TRUTH.md) lists the standards that have been verified as harmonised for the MDR for the scope of this blog. IEC 82304-1 is not in that catalog. That does not mean the standard is not used, not useful, or not referenced in industry practice — it means its current edition and its harmonisation status under the MDR have not been verified inside the ground truth collection this blog relies on.

What this means in practice for a SaMD startup reading this post. First, treat any industry claim that "IEC 82304-1 is harmonised under the MDR" as something to verify against the current OJEU list of harmonised standards before acting on it. Second, treat any industry claim that the standard is not harmonised with equal scepticism — harmonisation lists change. Third, if the standard is cited in a technical file as a presumption-of-conformity tool, verify the exact edition and its harmonisation status at the time of verification, and record the verification in the file. Fourth, if the standard is used as a product-framing tool without a presumption-of-conformity claim, the harmonisation status is less load-bearing and the framing can still add value regardless.

This caveat is not a reason to ignore IEC 82304-1. It is a reason to be precise about the claim being made when the standard is cited. Subtract to Ship is compatible with precision — in fact it depends on it. See post 065 on the framework.

Common mistakes

  • Treating EN 62304:2006+A1:2015 and IEC 82304-1 as alternatives. They are not. One is a process standard and one is referenced as a product standard. A SaMD file uses both.
  • Building two parallel documentation sets. The process evidence and the product framing should reference the same artefacts — one intended purpose, one risk file, one set of user-facing information — from different angles. Two parallel sets drift and contradict each other.
  • Citing IEC 82304-1 in a technical file without verifying the current edition and harmonisation status. If the standard is being used as a presumption-of-conformity tool, the citation has to be backed by a check against the current OJEU listing.
  • Treating accompanying information as a marketing task. For a SaMD, the user manual is part of the product and part of the regulatory file. It has to match the software exactly and cover the conditions for safe use.
  • Ignoring the product-level framing entirely. Even if IEC 82304-1 is not cited, the product-level questions it raises still need answers inside the technical file under MDR Annex I Section 17 and Annex II.
  • Copying the operating environment from marketing materials. The operating environment the manufacturer commits to in the accompanying information is a regulatory commitment, not a sales promise. It has to be verifiable.

The Subtract to Ship angle

The subtraction move in this area is to refuse the trap of duplicating work. The temptation, once a startup learns about both standards, is to build a second lifecycle file for IEC 82304-1 alongside the first one for EN 62304:2006+A1:2015. That duplication is waste, and it is the kind of waste that compounds because every change to the intended use, the risk file, or the accompanying information then has to be made in two places.

The Subtract to Ship move is to have one technical file that answers both the process question and the product question, with the right sections pointing at the right artefacts. The intended use is stated once and referenced everywhere. The risk file is one file integrated with EN ISO 14971:2019+A11:2021 and not duplicated. The accompanying information is one set, produced to product-framing standards, referenced by both the process evidence and the product framing. The operating environment is specified once — in the MDR Annex I Section 17.4 minimum-requirements description — and reused by every standard and process that needs it.

The other subtraction move is to resist the urge to cite every standard the startup has heard of. Cite the standards whose current edition and harmonisation status are verified, and cite them for the specific requirements they address. IEC 82304-1 can be referenced at the product-framing level even when a harmonised-standard citation is not yet backed by verification — but be explicit in the file about the nature of the reference. For the broader methodology see post 065.

Reality Check — Does your SaMD file answer both the process and the product question?

  1. Do you have an EN 62304:2006+A1:2015 process file that covers every life-cycle activity at the depth your software safety class requires?
  2. Do you have a product-level description of the SaMD inside your technical file that states the intended use, the target user, the operating environment, the accompanying information, and the conditions for safe use?
  3. Are the intended use and the conditions for safe use consistent across the MDR technical documentation, the risk file, the process file, and the user-facing accompanying information?
  4. Is the accompanying information — instructions for use, user manual, technical description of the operating environment — complete, comprehensible to the intended user, and an exact match for what the software does today?
  5. If IEC 82304-1 is cited in your file, has the current edition and the harmonisation status been verified against the current OJEU listing, and is the verification recorded?
  6. If IEC 82304-1 is used as a product-framing tool without a harmonisation claim, is the nature of the reference explicit in the file so a reviewer cannot mistake it for a presumption-of-conformity claim?
  7. Are the post-release product commitments — support, updates, problem handling — stated in a way that is consistent with the EN 62304:2006+A1:2015 maintenance process and the MDR post-market surveillance obligations?

Any question you cannot answer with a clear yes is a gap between current practice and an audit-ready SaMD file.

Frequently Asked Questions

Is IEC 82304-1 a replacement for EN 62304:2006+A1:2015? No. EN 62304:2006+A1:2015 is a process standard for medical device software life-cycle activities. IEC 82304-1 is referenced as a product standard for health software as a whole. They answer different questions and are used together for SaMD. A file that cites only one of the two is incomplete in the area the other standard addresses.

Is IEC 82304-1 harmonised under the MDR? The harmonisation status of IEC 82304-1 under the MDR is not confirmed in the project's regulatory ground truth catalog used for this blog, and this post therefore does not make a harmonisation claim. Before citing the standard in a real technical file as a presumption-of-conformity tool, verify the current edition and the harmonisation status directly against the current OJEU listing of harmonised standards.

Do I need IEC 82304-1 if my SaMD already complies with EN 62304:2006+A1:2015? You need both kinds of evidence — process evidence and product-level framing — regardless of which standards you formally cite. EN 62304:2006+A1:2015 handles the process side. The product-level questions IEC 82304-1 frames still have to be answered inside your technical file under MDR Annex I Section 17 and Annex II, even if the standard is not formally cited.

Where does IEC 82304-1 fit alongside EN IEC 81001-5-1:2022 for cybersecurity? EN IEC 81001-5-1:2022 is the cybersecurity life-cycle standard covered in post 393 and referenced in post 394. It is its own standard with its own scope. IEC 82304-1 framing touches on security as part of the conditions for safe use, but the cybersecurity life-cycle activities themselves are governed by EN IEC 81001-5-1:2022. The standards are complementary, not substitutable.

Does IEC 82304-1 apply to software that is not a medical device? The framing of IEC 82304-1 extends to health software beyond the strict medical device scope of the MDR, which is one of the reasons it is discussed alongside EN 62304:2006+A1:2015. For a SaMD startup — software that is a medical device — the relevant question is how the standard complements the MDR obligations for the device, not whether it covers non-device software.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I, Section 17 (software and electronic programmable systems). Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. IEC 82304-1 — Health software — Part 1: General requirements for product safety. Verification note: IEC 82304-1 is not listed in the project's condensed regulatory ground truth catalog (Sources/CONDENSED-REGULATORY-GROUND-TRUTH.md). Its current edition and its harmonisation status under the MDR have not been verified within the ground truth collection used for this blog. This post therefore discusses the standard at a general framing level only and does not cite specific clause numbers or make a presumption-of-conformity claim. Before relying on IEC 82304-1 for a real certification project, verify the current edition, the harmonisation status, and the specific requirements directly against the standard text and the current OJEU listing of harmonised standards under the MDR.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on how the process-oriented EN 62304:2006+A1:2015 and the product-oriented IEC 82304-1 fit together for Software as a Medical Device under MDR Annex I Section 17. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 and IEC 82304-1 are tools that serve MDR Annex I, not independent authorities. For startup-specific regulatory support on SaMD standards selection, technical file construction, and Notified Body preparation, Zechmeister Strategic Solutions is where this work is done in practice.