IEC 62304 Software Safety Classes A B and C Explained

IEC 62304 software safety classes determine how much lifecycle rigor a medical device software system requires. Class A applies when software failure cannot cause injury or damage to health. Class B applies when non-serious injury is possible. Class C applies when failure could lead to death or serious injury. The class affects the required depth of architecture, design, verification, traceability, configuration management, and problem resolution work.

Introduction

IEC 62304 defines lifecycle processes for software that is itself a medical device or forms part of a medical device. The current consolidated edition, IEC 62304:2006+A1:2015, uses three software safety classes: A, B and C. These classes do not rate code quality and do not correspond directly to FDA device classes or EU MDR device classes. They scale the required software engineering controls according to the harm that a software failure could make possible.

Classification matters early. It changes the development plan, architecture evidence, testing strategy, traceability depth, review effort, supplier controls, and maintenance workload. An optimistic classification can leave a submission without required evidence. An unnecessarily high classification can impose avoidable process overhead. Teams therefore need a documented, risk-based rationale that connects the software architecture to the device risk analysis.

What IEC 62304 Classifies

IEC 62304 classifies the medical device software system, then applies that class to its software items unless the manufacturer can justify a lower class for a particular item through documented architecture, segregation, and risk analysis. The starting point is conservative: until a class has been assigned, the software system is treated as Class C.

The classification should be part of the product risk-management process, normally aligned with ISO 14971. The analysis asks what harm could result if the software fails or contributes to a hazardous situation. It does not begin by estimating how likely a coding defect is. Probability remains important in the wider risk analysis, but the A, B or C decision focuses on the possible severity of harm and on qualifying risk controls outside the software system.

IEC 62304 Classes A B and C

Class A

Class A is appropriate only when failure of the software cannot result in injury or damage to health. A non-clinical log viewer or an administrative configuration utility may qualify if its outputs cannot influence diagnosis, treatment, alarms, protective functions, or the availability of essential clinical information. The conclusion must follow from the actual intended use and system architecture, not from the team's view that the code is simple.

Class B

Class B applies when software failure can cause non-serious injury. A rehabilitation device function that sets a low-energy exercise parameter could fall into this class if a credible failure can cause reversible discomfort or minor injury but cannot cause serious injury. The classification still requires a device-specific hazard analysis. A similar-looking function could become Class C if the delivered energy, patient population, or clinical context changes.

Class C

Class C applies when software failure can cause death or serious injury. Common examples include software that controls infusion delivery, calculates radiotherapy dose, manages life-support alarms, or implements a safety interlock whose failure could expose a patient to severe harm. Class C does not mean that failure is likely. It means that the possible consequence demands the standard's highest software lifecycle rigor.

How to Determine the IEC 62304 Software Safety Class

1. Define the software system boundary. Identify executable code, configuration data, operating-system services, third-party libraries, cloud components, and interfaces that belong to the medical device software system.
2. Map software failures to hazardous situations. Use the product risk analysis to identify incorrect output, delayed output, unavailable functions, corrupted data, timing failures, unintended actuation, alarm failures, and foreseeable misuse involving software.
3. Determine the worst credible harm. Classify by the possible health consequence: no injury or damage to health for A, non-serious injury for B, or death or serious injury for C.
4. Evaluate external risk controls. A hardware or other control outside the software system may support a lower class when its independence and effectiveness are demonstrated. A software check inside the same software system does not automatically justify a downgrade.
5. Assign and document the class. Record the rationale in the risk-management file and software development plan, including assumptions, external controls, traceability to hazards, and approval records.
6. Classify decomposed software items. Items inherit the parent class unless the architecture and risk analysis show that an item cannot contribute to the higher-severity hazardous situation.
7. Reassess after change. New features, updated intended use, architectural changes, SOUP updates, new hazards, or field data can invalidate the original rationale.

How the Classes Change Lifecycle Work

All three classes require disciplined lifecycle work, including planning, requirements, system testing, release controls, maintenance, configuration management, and problem resolution. Higher classes add activities and require more detailed evidence. The exact applicability must be checked against the licensed standard and the project's regulatory basis, but the practical progression is clear.

For embedded products, this progression affects the full stack. Teams may need traceability from hazards to firmware requirements, unit tests for low-level drivers, integration evidence on target hardware, documented anomaly handling, and controlled releases. Conclusive Engineering's guides to embedded systems programming, firmware and software, and code analysis tools for embedded systems provide useful background for these engineering controls.

Software Decomposition and Segregation

IEC 62304 allows a software system to be decomposed into software items. Each item initially inherits the class of its parent. A lower class can be justified only when the manufacturer demonstrates that the item cannot contribute to the hazardous situation associated with the higher class.

That argument depends on architecture, not naming. Separate source directories or RTOS tasks do not prove independence. Teams should examine memory protection, privilege boundaries, shared resources, data flow, control flow, timing interference, common services, boot and update paths, and failure propagation. If a lower-class user-interface component can corrupt a shared buffer used by a Class C control loop, the claimed separation is weak.

Effective segregation can reduce verification scope, but it creates evidence obligations of its own. The architecture should make the boundary testable, and verification should challenge the assumed independence through interface tests, fault injection, resource-exhaustion tests, and analysis of common-cause failures.

IEC 62304 Classes Versus Device Risk Classes

IEC 62304 Class A, B, or C should not be copied from a device's regulatory class. The schemes answer different questions and use different criteria.

A high-risk medical device may contain some software items with a lower justified IEC 62304 class, while a lower regulatory class does not by itself prove that embedded software is Class A. FDA recognizes IEC 62304 Edition 1.1 as a consensus standard, and its premarket software guidance separately uses Basic and Enhanced documentation levels. EU software qualification and regulatory classification are addressed in MDCG 2019-11. None of these labels should be substituted for the IEC 62304 safety-class analysis.

Best Practices for Classification

• Classify during concept and architecture work, before the development plan and verification budget are fixed.
• Use cross-functional review. Software, systems, clinical, hardware, quality, and risk-management specialists see different failure paths.
• Write explicit assumptions about users, patients, operating environments, connectivity, data quality, hardware protection, and response time.
• Trace every class decision to hazards and hazardous situations rather than relying on a generic product category.
• Treat third-party software and SOUP as part of the safety argument. Document versions, known anomalies, integration constraints, and update controls.
• Design architecture around containment where a lower-class partition offers a real reduction in lifecycle scope.
• Reassess classification through change control and post-market feedback. A new interface or use case can create a new path to harm.

Common IEC 62304 Classification Mistakes

• Matching the device class by name. FDA Class II does not imply IEC 62304 Class B, and EU Class III does not automatically imply software Class C.
• Classifying by complexity. A small function can be Class C if its failure can cause serious injury. A large administrative application can be Class A if it cannot cause health harm.
• Using defect probability to lower the class. Clean code, static analysis, and high test coverage reduce risk but do not change the possible consequence of failure.
• Crediting a control inside the same software system. A watchdog task or duplicate software check may improve safety, but it does not automatically provide the independence needed to reduce the software-system class.
• Downgrading components without proven segregation. A lower class needs documented control of failure propagation and shared resources.
• Treating classification as a one-time document. Changes to intended use, architecture, dependencies, or field evidence require reassessment.

IEC 62304 Software Safety Class Checklist

[ ] Software-system boundary and intended use are defined

[ ] Software failure modes are linked to device hazards and hazardous situations

[ ] Worst credible harm is documented for each relevant failure path

[ ] External risk controls and their independence are justified

[ ] System class and item-level classes are approved and traceable

[ ] Architecture supports every claimed lower-class partition

[ ] The development plan applies all clauses required for the assigned class

[ ] SOUP, cybersecurity, and update paths are included in the analysis

[ ] Change control includes a classification review trigger

[ ] Regulatory device class and software safety class are documented separately

Frequently Asked Questions

What are the three IEC 62304 software safety classes?

Class A means software failure cannot cause injury or damage to health. Class B means non-serious injury is possible. Class C means death or serious injury is possible.

Is IEC 62304 Class C the same as FDA Class III?

No. IEC 62304 Class C scales software lifecycle rigor. FDA Class III is a regulatory classification for the medical device. A project must determine both independently.

Can one medical device contain software items with different classes?

Yes. A software item inherits its parent's class unless documented decomposition, segregation, and risk analysis justify a lower class. The argument must address failure propagation and shared resources.

Can risk controls reduce the software safety class?

Potentially, when effective controls outside the software system reduce the possible consequence and their independence is justified. A control implemented inside the same software system does not automatically support a downgrade.

Does Class A remove the need to follow IEC 62304?

No. Class A still requires the lifecycle activities applicable to that class, including planning, requirements, system testing, release, maintenance, configuration management, and problem resolution.

When should a team assign the class?

Assign it before software development activities begin and revisit it whenever intended use, architecture, dependencies, risk controls, or field evidence change.

Conclusion

IEC 62304 software safety classes connect possible patient or user harm to the rigor of the software lifecycle. Class A covers failures that cannot cause injury or damage to health. Class B covers possible non-serious injury. Class C covers possible death or serious injury. The defensible class comes from the device risk analysis, system boundary, architecture, and external risk controls, not from code size, developer confidence, or the device's regulatory class.

Teams that classify early can design appropriate boundaries, plan verification evidence, and avoid late compliance rework. Conclusive Engineering supports medical device development, functional safety engineering, and firmware development for embedded products that require traceable requirements, controlled implementation, hardware-software integration, and verification on target platforms.