IEC 62304 Explained: Software Safety Classes A, B, and C

IEC 62304 is the international standard for medical device software lifecycle processes, and it sorts software into three safety classes by the severity of harm a failure could cause: Class A, where no injury is possible; Class B, where non-serious injury is possible; and Class C, where death or serious injury is possible. The class you land in decides how much of your development process you must document and verify, which makes classification the single most consequential early decision in a regulated software project.

This guide explains what IEC 62304 is, what each class means, how to determine your class, and what each one requires. It is written for the engineering and regulatory leads who scope medical device software development and have to decide, early and defensibly, how much rigor a given product demands.

What is IEC 62304?

IEC 62304 is an internationally recognized standard, published by the International Electrotechnical Commission and recognized by the US FDA, that defines the lifecycle processes for developing and maintaining safe medical device software. It applies both to standalone Software as a Medical Device and to software embedded inside a physical device, and it covers the full lifecycle from development planning through maintenance of released software.

The current version is IEC 62304:2006 together with its Amendment 1:2015. Two points are worth knowing because they signal how the standard actually behaves. First, its only normative reference is ISO 14971, the standard for medical device risk management, so classification under IEC 62304 is fundamentally a risk-based decision. Second, IEC 62304 assumes you already operate an ISO 13485 quality management system and an ISO 14971 risk management process; it does not recreate them.

It is equally useful to know what IEC 62304 does not cover. Final device validation and clinical evaluation live in other standards and regulations. IEC 62304 governs the engineering of the software itself, which is why it sits at the heart of medical device software development but never stands alone.

What processes does IEC 62304 define?

IEC 62304 organizes the software lifecycle into five processes, and how much rigor you apply to each one scales with your safety class. These five processes are the backbone of the standard.

• Software development (clause 5): planning, requirements, architecture, detailed design, implementation, integration, testing, and release.
• Software maintenance (clause 6): handling changes, feedback, and defects after release with the same discipline as original development.
• Software risk management (clause 7): the software-specific extension of the ISO 14971 risk process.
• Software configuration management (clause 8): controlling versions, changes, and builds so every release is traceable.
• Software problem resolution (clause 9): recording, analyzing, and resolving defects across the entire lifecycle.

A well-run medical device software development program treats these five as one connected system rather than separate boxes to tick, because the standard expects them to reference and feed one another.

Who needs to follow IEC 62304?

IEC 62304 applies to any manufacturer developing software that is itself a medical device or that is embedded inside one. It is recognized by the US FDA as a consensus standard, aligns with the software expectations of the EU Medical Device Regulation, and has been adopted as national standards in many markets, for example EN 62304 in Europe and ANSI/AAMI/IEC 62304 in the United States. Following the standard is not a legal mandate in itself, but it is the most widely accepted way to show a regulator that your software lifecycle is under control. For most companies scoping medical device software development, the practical question is not whether IEC 62304 applies, but which class applies and how much rigor that entails.

What are the IEC 62304 software safety classes?

IEC 62304 defines three software safety classes, each based on the severity of injury a software failure could cause. The classification is an input to your development rigor, not a judgment on code quality.

A Class C classification does not mean your software is dangerous or poorly built. It means that if a failure did occur, the consequences could be severe, so the process that produces the software must be held to the highest standard. The class is the input that sets your rigor, not an output of how good your engineering is.

How do you determine your IEC 62304 safety class?

You determine your class from the most severe harm a software failure could cause, after accounting for risk control measures outside the software itself. In practice the assessment runs in four steps.

• Identify the hazardous situations the software could contribute to, working from your ISO 14971 risk analysis.

• Assess the severity of the resulting harm. IEC 62304 assumes a software failure will occur, fixing the probability of software failure at 100 percent, so classification turns on how severe the harm could be, not on how unlikely you believe a bug is.

• Account for external risk controls such as hardware interlocks or independent alarms. If a control outside the software prevents the hazardous situation from causing harm, it can lower the class.

• Assign the class from the worst-case severity that remains after those external controls are considered.

A short worked example makes this concrete. A symptom-tracking journal that only stores what a user types cannot, by itself, cause injury, which points toward Class A. An application that calculates an insulin dose and presents it for the patient to act on could contribute to serious harm if it miscalculated, which points toward Class C unless an independent check outside the software reliably catches the error first. Same broad category of product, very different class, because the severity of a failure differs.

Two points trip teams up. First, you cannot argue your way to a lower class by claiming a software failure is improbable, because IEC 62304 assumes the probability of a software failure is 100 percent. What you can legitimately do is account for risk control measures outside the software that stop a failure from reaching the patient. Second, not all medical device software is Class C. Over-defaulting to Class C is one of the most common and most expensive classification mistakes, for reasons the insight below explains.

What does each IEC 62304 class require?

The higher the class, the more of the development process you must document and verify, and the requirements build cumulatively. This is the point where an abstract classification turns into real budget and schedule.

• Class A requires you to document the software requirements and the software release.
• Class B adds the software architecture and software verification, including test coverage that traces to requirements.
• Class C adds the detailed software design, the most granular documentation the standard asks for.

One detail that surprises teams: since Amendment 1:2015, system-level testing applies from Class A upward, so even the lightest class is not a documentation-free zone. Because class is the primary driver of effort, it is also the primary driver of cost, which is covered in depth in our guide to how much medical device software development costs. Getting the class right early is the cheapest decision you will make on the whole program.

The FDA’s documentation levels are worth a specific note. In its 2023 guidance, Content of Premarket Submissions for Device Software Functions, the FDA replaced the older Major, Moderate, and Minor “level of concern” categories with just two levels, Basic and Enhanced, determined by the risk of the software in the context of the device as a whole. A Class C safety classification often correlates with an Enhanced documentation level and a higher MDR class, but you must evaluate each system on its own criteria rather than mapping one onto another.

Is IEC 62304 changing?

A second edition of IEC 62304 is in development, and it has been reported to move toward two safety classes instead of three, but it is still a draft and not in force. Until it is published and adopted, classification continues to use the three classes A, B, and C described here. It is worth tracking, because a change to the class structure would ripple straight through the documentation each project owes, but it is not something to design around today.

Discover how Ailoitte AI keeps you ahead of risk

Let's Talk

Sunil Kumar

Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering. Connect on LinkedIn