EN 62304:2006+A1:2015 Section 4.3 requires the manufacturer to assign each software system — and, where segregation arguments support it, each software item inside the system — a software safety class based on the severity of the possible harm that could result from a software failure. Class A applies when no injury or damage to health is possible. Class B applies when non-serious injury is possible. Class C applies when death or serious injury is possible. The class is determined from the outputs of the risk-management process under EN ISO 14971:2019+A11:2021 before external risk controls outside the software are taken into account, and it drives the depth of the lifecycle activities required by the rest of EN 62304:2006+A1:2015. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool.

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

TL;DR

  • The EN 62304:2006+A1:2015 software safety class — A, B, or C — is assigned per Section 4.3 of the standard and reflects the severity of possible harm from a software failure.
  • Class A means no injury or damage to health is possible. Class B means non-serious injury is possible. Class C means death or serious injury is possible.
  • The class is determined from the EN ISO 14971:2019+A11:2021 risk-management outputs, before external risk controls outside the software are considered.
  • The software safety class is not the same as the MDR device class under Annex VIII Rule 11. A single MDR device can contain software items at different safety classes.
  • The class scales the required lifecycle activities. Higher class means more required activities and more documented evidence.
  • A software system can be segregated into items of different classes if the segregation is justified and verified — the segregation argument is how a startup legitimately keeps lower-risk code out of the highest class.
  • External risk controls — hardware safeguards, procedural controls, clinical monitoring — can downgrade the class if they are effective and independent of the software.
  • Assigning Class C by default to avoid the analysis is not the safe choice. It is the expensive choice, and it buries the lifecycle in work the Regulation does not require.

Why the software safety class decides how much work you have to do

Every medical software team we work with hits the same fork in the road about six weeks into the lifecycle conversation. The engineering lead has read EN 62304:2006+A1:2015, the founder has read the summary, and the question lands on the table. What class are we? The answer decides how much work the team has in front of it for the next twelve months. Class A means a short planning document, a requirements specification, and system-level testing. Class C means the full lifecycle — detailed design at the unit level, unit-level verification, integration testing, the fullest documentation trail the standard demands. The difference in engineering hours between the two, for the same code base, is large.

This is where teams make expensive mistakes in both directions. The first mistake is assigning Class A to code that deserves Class B because nobody wants to do the extra work. The file collapses at the Notified Body audit, the team re-runs the activities under deadline pressure, and the certification slips by months. The second mistake is assigning Class C to everything to be safe. The team does not save time at the audit, because the audit is not the problem — the problem is that the team has just committed to the most expensive version of the lifecycle for modules that do not need it. Both mistakes come from the same root cause: the class was not assigned from the risk analysis, it was assigned from a gut feeling.

The software safety class is a structured question with a structured answer. EN 62304:2006+A1:2015 Section 4.3 is explicit about how the class is determined, and EN ISO 14971:2019+A11:2021 provides the risk-management process that feeds it. This post walks through both, shows how the class is actually assigned in practice, and explains how a startup legitimately keeps code out of Class C when the risk analysis supports it.

What "software safety class" means in Section 4.3

EN 62304:2006+A1:2015 Section 4.3 — Software safety classification — sets out the rule. The manufacturer shall assign to each software system a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a hazardous situation to which the software system can contribute. The class reflects the severity of the worst-case harm that a failure of the software could contribute to, not the probability of the failure.

This is a point founders often miss. The class is severity-driven, not probability-driven. A software failure that is extremely unlikely but could contribute to a fatal outcome puts the software in Class C. A software failure that happens often but only ever causes a minor inconvenience keeps the software in Class A. The standard is deliberately severity-only at this point because the lifecycle activities are the way the manufacturer reduces the probability of failure — the class is set by what the failure could cause, and the class then drives the activities that reduce how often failures happen.

The second point in Section 4.3 that matters: the class is assigned based on the possible harm before external risk controls outside the software are taken into account. If the software alone could contribute to a fatal outcome, the starting class is C, even if a hardware safeguard or a clinical protocol would catch the problem before the patient is harmed. External controls can reduce the class, but only if the controls meet specific conditions covered later in this post.

The third point is that the class applies to the software system by default. The system is the whole software product. A system-level Class C assignment means every software item in the system inherits Class C unless segregation is argued and implemented. This is where the cost of a wrong default choice compounds — assigning Class C at the system level without segregation commits every module to the full lifecycle, even the modules that handle administrative functions with no safety implications.

Class A, Class B, Class C — what each class actually means

The three classes are defined in Section 4.3 of EN 62304:2006+A1:2015 by the worst possible consequence of a software contribution to a hazardous situation.

Class A — No injury or damage to health is possible. This is software whose failure, even in the worst case, cannot contribute to any injury to a patient, operator, or other person. Pure logging software that records non-safety data. A configuration tool that sets preferences with no clinical effect. An administrative module that books appointments without influencing clinical decisions. The Class A bucket is narrower than founders hope. If the software output is read by a clinician and could influence a clinical decision in any way, it is almost never Class A.

Class B — Non-serious injury is possible. This is software whose failure could contribute to injury that is not serious — injury that is reversible, does not require significant medical intervention, and does not threaten life or permanent health. A software failure that could cause a minor skin irritation, a short delay in a non-critical treatment, or a temporary loss of a non-essential function. Most clinical decision-support software that informs routine, non-urgent decisions falls into Class B territory once the risk analysis is done honestly.

Class C — Death or serious injury is possible. This is software whose failure could contribute to death or serious injury — serious meaning life-threatening, permanent, or requiring significant medical intervention. Software that drives a critical physiological parameter. Software that interprets imaging for urgent diagnoses. Software whose wrong output could lead a clinician to administer a lethal dose or miss a life-threatening condition. The Class C bucket is the expensive one, and it is the correct one when the risk is real.

The boundaries between classes are judgement calls that must be justified in the risk-management file. "Non-serious" and "serious" are defined in the risk analysis, not in the standard, and the definitions have to be consistent with the EN ISO 14971:2019+A11:2021 severity categories the manufacturer is using for the rest of the risk work. A startup that defines "serious" differently for the software safety class than for the device risk file will be caught by any competent auditor.

How the risk-management process drives the class

EN 62304:2006+A1:2015 does not operate in isolation. Section 4.3 assumes the manufacturer is running a risk-management process under EN ISO 14971:2019+A11:2021, and the software safety class is derived from that process. The chain is specific.

The EN ISO 14971:2019+A11:2021 process starts with the intended use and the reasonably foreseeable misuse, identifies hazards associated with the device, estimates the severity and probability of the harm that could result, evaluates the risk against the manufacturer's risk acceptability criteria, and implements risk controls to reduce unacceptable risk. The output that matters for the software safety class is the list of hazardous situations to which the software can contribute, with the severity of the possible harm for each one.

The software safety class is then assigned to each software system based on the worst-case severity across all the hazardous situations to which that software system can contribute. If any software contribution could lead to death or serious injury, the system is Class C. If the worst software contribution is non-serious injury, the system is Class B. If no software contribution could lead to any injury, the system is Class A.

The timing of this analysis matters. The risk analysis has to be mature enough to support the class determination before the development lifecycle activities fully kick in — because the activities required by EN 62304:2006+A1:2015 depend on the class, and you cannot run the right activities without knowing the class. In practice, the class is assigned early in the planning phase, reviewed after the architectural design, and confirmed after the hazard analysis is mature. It is not a one-shot decision; it is revisited whenever the risk file changes materially.

The reverse loop matters too. If a software verification activity uncovers a new hazard contribution that was not in the risk file, the risk file is updated, the class is re-assessed, and the lifecycle activities are re-scoped if the class changes. This is where the three standards — EN 62304:2006+A1:2015, EN ISO 14971:2019+A11:2021, and the QMS — have to talk to each other continuously. A static class assignment written at the start of the project and never revisited is a sign that the integration is not working.

What activities the standard requires at each class

The class is not an abstract label. It scales the specific activities EN 62304:2006+A1:2015 requires across the lifecycle. Here is what changes as the class moves from A to C.

Software development planning. Required at all three classes. The plan exists for Class A, B, and C. The depth of the planning grows with the class — a Class C plan covers more detail on verification strategy, configuration management rigour, and risk-management integration than a Class A plan.

Software requirements analysis. Required at all three classes. Requirements are written, traced, and verified for Class A, B, and C.

Software architectural design. Required for Class B and Class C. At Class A, the standard does not require architectural design beyond what is implicit in the requirements and implementation. At Class B and Class C, the architecture identifies software items and the interfaces between them.

Software detailed design. Required at Class C only, at the unit level. At Class B, detailed design is required at the software item level but not necessarily down to units. At Class A, detailed design is not required by the standard.

Software unit implementation and verification. Implementation happens at all three classes. Unit-level verification — unit tests, code reviews at unit level — is required at Class C. At Class B and Class A, unit-level verification is not required by the standard as a separate activity, though modern engineering practice usually runs it anyway.

Software integration and integration testing. Integration testing is required at Class B and Class C. At Class A, integration testing is not required as a distinct activity.

Software system testing. Required at all three classes. Every software system, including Class A, goes through system-level testing against the requirements.

Software release. Required at all three classes. The release activity — the controlled production of a verified, documented version — is a gate for every class.

Software maintenance. Required at all three classes, with the depth matching the class of the software being maintained.

Software risk management. Required at all three classes. Risk management runs continuously throughout the lifecycle regardless of class.

Software configuration management. Required at all three classes. Configuration control over source code, documents, and third-party components applies to every class.

Software problem resolution. Required at all three classes. The depth of the investigation and the formality of the documentation grow with the class.

The pattern is clear. Class A is the lightest lifecycle — planning, requirements, implementation, system testing, release, maintenance, risk management, configuration management, problem resolution, but not architectural design, not detailed design, not unit-level verification, not integration testing. Class B adds architectural design, detailed design at the item level, and integration testing. Class C adds detailed design at the unit level and unit-level verification. Each step up the class ladder adds a band of required activities and documented evidence.

The software safety class and the MDR device class are not the same

This is the most persistent confusion we see in the field, so it is worth saying directly. The EN 62304:2006+A1:2015 software safety class (A, B, C) and the MDR device class under Annex VIII (I, IIa, IIb, III) are different classifications with different purposes. They are related but they are not the same, and neither determines the other.

The MDR device class is assigned to the device as a whole under Annex VIII, following the classification rules — Rule 11 for software. It drives the conformity assessment route with the Notified Body under MDR Article 52. It is a regulatory classification that determines who assesses the device and how.

The software safety class is assigned to each software system (and, with segregation, to items inside it) under EN 62304:2006+A1:2015 Section 4.3, following the severity-of-harm logic. It drives the depth of the software lifecycle activities the manufacturer has to run. It is a technical classification that determines what the development team has to do.

A single MDR Class IIa device can contain Class A, Class B, and Class C software items inside it. A Class III MDR device does not automatically have Class C software throughout — parts of its software could be Class A if the risk analysis supports it. A Class I MDR device with software still needs software safety classification, and the class could be A, B, or C depending on the risk analysis.

Both classifications are required on the same file, and they have to be internally consistent. We cover Rule 11 and the MDR device class for software in post 371. This post is about the software safety class, which is a separate analysis with its own logic. For the lifecycle activities that the software safety class drives, see post 376.

Downgrading a class through segregation and external risk controls

Section 4.3 of EN 62304:2006+A1:2015 allows two legitimate paths to reduce the class of a software system or of specific software items inside it. Both are useful, and both have to be justified rigorously.

Segregation. If a software system can be architecturally split into items that are effectively independent of each other, the manufacturer can argue that a failure in one item cannot propagate to another, and the items can then carry different classes. A Class C system might contain a Class C core and a Class A administrative module if the administrative module is segregated from the core in a way that prevents the administrative code from contributing to any hazardous situation the core is responsible for. The segregation argument has to be made explicitly in the architecture, implemented in the code, verified through testing, and documented in the lifecycle file. The Notified Body will examine the segregation evidence carefully — and a weak segregation argument is worse than no segregation at all, because it signals that the manufacturer is trying to escape the class rather than manage the risk.

External risk controls. If a risk control outside the software — a hardware safeguard, a procedural control, clinical monitoring, a mechanical limit — reduces the probability or severity of the harm such that the software's contribution no longer meets the Class C or Class B threshold, the class can be reduced. The conditions in the standard are strict. The external control has to be effective, independent of the software, and itself verified and controlled. A software watchdog that sits in the same system as the software being watched is not an external control. A hardware cut-off circuit that triggers independently of the software, with its own verification, is. The reduction has to be justified in the risk file and accepted by the Notified Body.

The practical use of these two mechanisms is how competent teams keep their lifecycle scope proportionate. A medical imaging platform might have a Class C core — the interpretation algorithm that produces the diagnostic output — and Class A user-interface modules, Class A reporting modules, and Class A configuration modules, all segregated from the core. The Class C work focuses on the Class C code. The rest of the platform runs at Class A. The total lifecycle cost is a fraction of what it would be if the whole system carried Class C.

The opposite move — inflating everything to Class C to avoid the analysis — is the expensive mistake. Class C is not the safe choice. It is the choice that commits the team to the fullest lifecycle for code that does not need it. The competent move is to do the risk analysis, apply segregation where the architecture supports it, apply external controls where they genuinely work, and assign the class honestly.

The Subtract to Ship angle — honest classification as subtraction

The software safety class is the category where Subtract to Ship pays off most visibly in the engineering schedule. The default move — assign Class C everywhere to be safe — is the addition move. It adds activities, documentation, and review layers to every module regardless of whether the risk justifies them. It looks diligent and is actually waste.

The subtraction move is to run the risk analysis honestly, apply segregation where the architecture supports it, and assign each software item the class the risk truly supports. The work that remains is work the standard requires. The work that disappears is work the standard does not require once the class has been determined correctly. Every activity survives the "trace to a specific clause of the standard" test. Activities that do not trace come out.

The subtraction is not cutting corners. The risk analysis has to be rigorous, the segregation has to be real, the external controls have to be effective, and the class has to be defensible at audit. What the subtraction cuts is the reflexive inflation that comes from treating classification as a fear response rather than an engineering analysis. For the broader framework applied to MDR, see post 065.

Reality Check — Is your software safety classification defensible?

  1. Have you assigned a software safety class — A, B, or C — to each software system in your product, in writing, with the reasoning linked to the EN ISO 14971:2019+A11:2021 risk file?
  2. Is the assignment based on the severity of possible harm from a software failure, not on the MDR device class or a gut-feel assessment?
  3. Have you considered the worst-case harm across every hazardous situation to which the software could contribute, not just the most likely scenarios?
  4. If you have claimed Class A or Class B, have you identified every contribution the software could make to hazardous situations and confirmed none crosses the next-class threshold?
  5. If you have used segregation to keep some items at a lower class than the system, is the segregation argued in the architecture, implemented in the code, verified through testing, and documented in the lifecycle file?
  6. If you have used external risk controls to downgrade the class, are those controls genuinely independent of the software, verified, and controlled under the QMS?
  7. Does the class assignment get revisited when the risk file changes, or is it a static label written at project start?
  8. Is the class consistent with the lifecycle activities the team is actually running — Class C activities for Class C items, Class A activities for Class A items, no silent mismatches?
  9. Would the class assignment survive a skeptical reading by a Notified Body auditor who asked for the derivation from the risk file?

Any answer short of a clear yes is a gap. Close it before the lifecycle activities are locked in, because re-scoping the activities after the class changes is the most expensive form of rework in this category.

Frequently Asked Questions

What is the difference between Class A, Class B, and Class C in EN 62304:2006+A1:2015? Class A means no injury or damage to health is possible from a software failure. Class B means non-serious injury is possible. Class C means death or serious injury is possible. The class is determined from the severity of the worst-case harm the software could contribute to, as identified in the EN ISO 14971:2019+A11:2021 risk-management process, before external risk controls outside the software are taken into account.

Is the software safety class the same as the MDR device class? No. The MDR device class (I, IIa, IIb, III) is assigned to the device as a whole under Annex VIII and drives the conformity assessment route. The software safety class (A, B, C) is assigned to each software system under EN 62304:2006+A1:2015 Section 4.3 and drives the depth of the lifecycle activities. A Class IIa MDR device can contain Class A, Class B, and Class C software items, and both classifications are required on the same file.

Can external risk controls reduce the software safety class? Yes, under conditions. EN 62304:2006+A1:2015 Section 4.3 allows the class to be reduced if an external risk control — a hardware safeguard, a procedural control, clinical monitoring — reduces the severity or probability of the harm such that the software's contribution no longer meets the higher class. The external control has to be effective, independent of the software, and itself verified and controlled. A software watchdog running in the same system is not an external control; a hardware cut-off circuit with its own verification chain is.

Is it safer to assign Class C to everything? No. Assigning Class C to everything is the expensive choice, not the safe choice. It commits the team to the full lifecycle activities for every software item, including items whose risk does not warrant it. The competent move is to run the risk analysis honestly, apply segregation where the architecture supports it, and assign each item the class the risk genuinely supports.

What activities change between Class A and Class C? Class A requires planning, requirements, implementation, system testing, release, maintenance, risk management, configuration management, and problem resolution. Class B adds architectural design, detailed design at the software item level, and integration testing. Class C adds detailed design at the unit level and unit-level verification. Each class adds a band of required activities and documented evidence on top of the lower class.

How is the class documented and where does it live in the file? The class is assigned in the software development plan, justified in the risk-management file, and reflected in the architectural design. The reasoning — which hazardous situations the software could contribute to, the severity of the worst-case harm, the role of any segregation or external controls — lives in the risk file and is traceable from the class assignment to the underlying risk analysis. The class is reviewed whenever the risk file changes and updated when the review triggers a change.

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. 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), Section 4.3 Software safety classification. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software safety classification that scales the EN 62304:2006+A1:2015 lifecycle activities. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that provides presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17, not an independent authority. For startup-specific regulatory support on software safety classification, segregation arguments, and risk-management integration, Zechmeister Strategic Solutions is where this work is done in practice.