IEC 62304: Safety Classes, Lifecycle Processes and the Edition 2 Timeline

Introduction

IEC 62304 defines the life cycle processes for medical device software. It is the standard a Notified Body reaches for first when it opens a software technical file, and the one the FDA recognises as a consensus standard. It has been in force, in substance, since 2006.

If you have read about it recently you will have seen that a second edition was due in August 2026. Several widely read guides published this year gave the date precisely, one of them down to 12 August. That date has passed and no second edition exists. What the working group actually did was different, and the gap between the two is worth understanding, because a number of manufacturers have been planning transition work against a deadline that was never real.

This guide covers what the standard requires today: the safety classification and what each class actually obliges you to produce, the five process chapters, the legacy software route, how IEC 62304 sits alongside ISO 14971 and ISO 13485, and the current, accurate status of Edition 2. Verification and validation and SOUP management each have their own guide, linked where they belong.

Which version of IEC 62304 is actually in force
What the standard covers, and three things it does not
Software safety classification: A, B and C
The four rules that decide the class
The probability-of-failure trap
What each safety class actually requires
The five processes: clauses 5 to 9
Clause 5 — Software development
Clause 6 — Software maintenance
Clause 7 — Software risk management
Clause 8 — Software configuration management
Clause 9 — Software problem resolution
Clause 4.4 — Legacy software
How IEC 62304 sits with the other standards
IEC 62304 and the FDA
Edition 2: what it changes and where it actually stands
The audit findings that recur
Frequently asked questions
Conclusions

Which version of IEC 62304 is actually in force

Three designations circulate, and they refer to the same body of requirements at different points in its history.

Designation	Year	Status
IEC 62304:2006	2006	The original edition, with an editorial correction in 2008. Reviewed and confirmed by the IEC in 2023, so it remains current.
Amendment 1	2015	IEC 62304:2006/AMD 1:2015. Substantially reworked the safety classification rules and introduced the legacy software route in clause 4.4.
IEC 62304:2015	2015	The consolidated version — original, correction and amendment in one document. Sometimes called version 1.1. This is what people mean when they say “IEC 62304” without qualification, and it is the state of the art.
Edition 2	—	Does not exist. A draft was withdrawn at the turn of 2021–2022; a new attempt is in committee draft. See the section below.

Amendment 1 matters more than its name suggests. If your development processes were written against the 2006 text alone, the classification rules you are applying are the superseded ones — and the whole documentation burden follows from the class.

What the standard covers, and three things it does not

IEC 62304 applies to software that is a medical device in its own right — standalone software, Software as a Medical Device — and to software embedded in one, from infusion pump firmware to the control layer of an imaging system. It also reaches third-party components integrated into either, which the standard calls SOUP.

It is a process standard. It does not tell you how to write code, which architecture to adopt or which development methodology to use. It defines activities, tasks and the documentation that has to exist as evidence that those activities happened. This is why an agile team can comply: what the standard asks is that the process be planned, followed and evidenced, not that it be sequential.

Three exclusions are worth stating explicitly, because they are the source of recurring confusion:

It does not cover device validation. IEC 62304 stops at software system testing and release. Demonstrating that the finished device meets user needs in the intended environment sits elsewhere — in the design controls of ISO 13485 and in the clinical evaluation.
There is no such thing as organisational certification to IEC 62304. Some test houses offer a form of certification against it. Conformity to a process standard is assessed on a specific product’s file, and a certificate carries weight only if the body issuing it is accredited for what it is certifying.
It does not cover health software that is not a medical device. Wellness apps and fitness software fall outside its current scope; IEC 82304-1 was written for that territory. Edition 2 intends to change this, which is one of its more consequential proposals.

Software safety classification: A, B and C

Everything else in the standard scales from the class. Get it wrong and either you have built a documentation set far heavier than the device needs, or you have a file with holes in it that a reviewer will find in the first hour.

Class	Definition	Typical example
A	The software system cannot contribute to a hazardous situation; or it can, but the resulting risk is not unacceptable once risk control measures external to the software are taken into account	A module displaying administrative data with no bearing on diagnosis or treatment
B	The software system can contribute to a hazardous situation that results in unacceptable risk, and the possible harm is non-serious injury	Software controlling a low-risk therapy where a fault causes discomfort but no lasting damage
C	The software system can contribute to a hazardous situation that results in unacceptable risk, and the possible harm is death or serious injury	Dose calculation in an automated infusion system

The four rules that decide the class

1. No classification means Class C. If the manufacturer does not perform and document the classification, the software system and every component in it default to the highest class. This is not a penalty invented by auditors; it is what the standard says. It also means an undocumented rationale is functionally the same as no classification at all.

2. The highest component sets the system class. Each software item can be classified individually, and the class of the whole system is the highest class assigned to any item within it. This is the mechanism that lets you contain the documentation burden: partition the architecture so that the safety-relevant functionality sits in a small, well-isolated set of items, and the rest can be developed to a lower class.

3. Only external risk control measures can lower a class — and not all of them count. A hardware interlock, a mechanical stop, an independent monitoring circuit: these are external to the software system and may bring the class down. Information for safety does not. A warning in the instructions for use, a training requirement, a caution label — none of these lower the safety class, and a classification rationale that leans on them is a finding.

4. The class is an input to the process, not a verdict on the software. Class C does not mean the software is dangerous or badly built. It means the consequences of a failure would be severe, so the process that produces it has to be correspondingly rigorous. And the IEC 62304 class is not the device’s regulatory risk class: a Class C software system frequently sits inside a Class IIb or III device under the EU MDR, but the two systems use different criteria and neither substitutes for the other. Our guide to SaMD classification under Rule 11 and the FDA covers how the regulatory class is determined separately.

Figure 1 — The classification decision, applied to each software item

The probability-of-failure trap

IEC 62304 contains a sentence that manufacturers routinely carry into the wrong document: the probability of a software failure is to be taken as 1.

That instruction belongs to the classification. It exists so that you cannot argue your way into a lower class by claiming a defect is unlikely — you assume the failure happens and then ask how bad the consequences are. It is not a statement about your ISO 14971 risk file, and it does not mean every software-related risk must be estimated with probability set to certainty. Carrying it across produces a risk file in which every software hazard has the maximum probability, which makes risk evaluation meaningless and is itself a finding. Our guide to ISO 14971 risk management covers how software hazards are estimated properly.

✦ Premium bundle · SW Documentation Kit Gold

Software lifecycle, AI/ML and cybersecurity — the complete file for AI-enabled devices.

The full IEC 62304 lifecycle set, the complete AI/ML module built on the IMDRF GMLP principles including the PCCP, and the cybersecurity documentation — cross-referenced across three coordinated modules with a Master Index and Conformity Matrix.

✓ 23 templates · 19 Word + 4 Excel · three coordinated modules

✓ Scalable to Class A, B or C

✓ Save €199 vs buying the SW Kit and AI/ML Kit separately

Get the Gold Kit → €799

What each safety class actually requires

This is the table that decides how much work you are signing up for. The standard scales the required activities clause by clause, and the difference between B and C is narrower than most people expect — it is essentially the detailed design.

Clause	Activity	Class A	Class B	Class C
5.1	Software development planning	Required	Required	Required
5.2	Software requirements analysis	Required	Required	Required
5.3	Software architectural design	—	Required	Required
5.4	Software detailed design	—	—	Required
5.5	Software unit implementation and verification	Implementation only	Required	Required
5.6	Software integration and integration testing	—	Required	Required
5.7	Software system testing	—	Required	Required
5.8	Software release	Required	Required	Required
Clauses 6 to 9 apply to every class, with the depth of the activity scaling to the class
6	Software maintenance process	Required	Required	Required
7	Software risk management process	Required	Required	Required
8	Software configuration management	Required	Required	Required
9	Software problem resolution	Required	Required	Required

Two observations follow from the shape of this table.

The first is that Class A is not a free pass. Planning, requirements, release, and all four supporting processes still apply. What Class A removes is the architectural and verification burden of clauses 5.3 and 5.5 to 5.7 — significant, but a long way from nothing. A Class A file that consists of a one-page statement is not a compliant Class A file.

The second is that the step from A to B is much larger than the step from B to C. Moving from A to B adds the architecture, unit verification, integration testing and system testing. Moving from B to C adds the detailed design. This is why the architectural partitioning decision in rule 2 above is worth real effort: pushing items from B down to A saves far more work than pushing them from C down to B. The requirements by class for clauses 5.5 to 5.7 are covered in detail in our guide to IEC 62304 software verification and validation.

The five processes: clauses 5 to 9

Clauses 1 to 4 set the scope, references, definitions and general requirements. The substance is in five process chapters.

Figure 2 — The five process chapters and what sits above them

Clause 5 — Software development

The longest chapter, and the one that defines the Software Development Plan. The plan is the document that makes everything else assessable: it declares the lifecycle model, the deliverables of each activity and who approves them, the traceability approach, the configuration and change management approach, and how software problems will be resolved during development.

Two points about the plan are frequently missed. It must be kept current through development — and if it is deliberately not updated at a given stage, the reason for not updating it has to be recorded. And it is the natural home for the classification rationale, which means an auditor reading the plan should be able to see why the software is Class B without opening another document.

Traceability under clause 5 is bidirectional and runs across five layers: software requirements, architecture and design, implementation, verification activities, and the risk control measures that come from ISO 14971. Broken links in this chain are the single most common technical finding against the standard, and they usually surface at integration testing rather than at review.

Clause 6 — Software maintenance

Maintenance is a separate process with its own plan, and it is the chapter most often under-implemented — partly because the distinction between maintenance and development is genuinely unclear in the current text. In practice: development creates new software or new functionality; maintenance handles modifications to software already released.

What clause 6 requires is a documented maintenance plan, a process for analysing problem reports and modification requests, and a process for implementing modifications that loops back through the relevant development activities. Post-market software problems arrive here, and they connect directly to the CAPA system — the anomaly resolution route and the corrective action route are not the same process, and a file that conflates them will be asked to separate them.

Clause 7 — Software risk management

Clause 7 is not a parallel risk management system. It is the software-specific part of the ISO 14971 process: identifying which software items can contribute to a hazardous situation, defining and implementing risk control measures, verifying those measures, and managing the risk implications of software changes.

The connection point that reviewers check is whether software hazards actually appear in the ISO 14971 risk file, or only in a software document that nothing references. A software risk analysis that lives entirely inside the software folder, with no corresponding entries in the risk management file, is a disconnection finding.

Clause 8 — Software configuration management

Configuration identification, change control and configuration status accounting. This is where SOUP is controlled: every third-party and open-source component identified, versioned, its role in the system described, and its known anomalies monitored across the product lifetime.

SOUP management has enough substance to warrant its own treatment — our guide to SOUP management under IEC 62304 covers the risk assessment, verification, patch management and obsolescence side, and our guide to the Software Bill of Materials covers the inventory that makes it operable, including the CycloneDX and SPDX formats and what the FDA expects in a premarket submission.

Clause 9 — Software problem resolution

Preparing problem reports, investigating, advising relevant parties, using change control, keeping records, analysing problems for trends and verifying the resolution. The trend analysis requirement is the one that gets skipped: individual problems are tracked, and nobody ever looks at the set of them for a pattern.

✦ Audit-ready kit · ISO 13485

Build your ISO 13485 QMS with confidence.

IEC 62304 assumes a quality management system underneath it — clause 4.1 says so explicitly. Built on 15+ years of audit experience, every SOP and template references the regulations auditors expect.

✓ 30 SOPs covering the full QMS scope

✓ 56 templates ready to customise

✓ Aligned with EU MDR + FDA QMSR

Get the ISO 13485 Kit → from €499

Clause 4.4 — Legacy software

Amendment 1 added the route that saves manufacturers with software developed before the standard applied, or developed without the documentation the standard requires. It is the most useful thing in the 2015 amendment and the least known.

The premise is that you cannot retrospectively perform a development process you did not perform. What you can do is demonstrate that the software is safe on the evidence available. The route runs through a risk-based gap assessment: identify the hazardous situations the legacy software could contribute to, evaluate the risk using post-market data from the field, close the gaps that matter for safety, and document a rationale for the rest.

The legacy route is not a way to avoid the standard. It substitutes evidence of safe use in the field for evidence of a compliant development process, and it requires the risk assessment and the deliverables that follow from it. What it removes is the obligation to fabricate a design history that never existed — which is what manufacturers do when they do not know clause 4.4 is available.

How IEC 62304 sits with the other standards

IEC 62304 is never applied alone. It assumes several other things are already in place, and it references them normatively.

Standard	Relationship	What breaks if it is missing
ISO 13485	Clause 4.1 requires a quality management system. IEC 62304 defines software processes; it does not define document control, training, purchasing or CAPA	The software processes have nothing to sit on. Records exist without a control system around them
ISO 14971	Clause 4.2 requires a risk management process. Clause 7 is the software-specific extension of it	The classification has no basis, since it depends on severity of harm, and software hazards never reach the risk file
IEC 62366-1	Usability engineering. Not normatively required by the current edition, but use error is a major source of software-related harm	Risk controls that depend on the user behaving correctly are never validated
IEC 81001-5-1	Cybersecurity activities for the health software lifecycle. Written to layer onto IEC 62304’s process structure	Security requirements have no home; the SOUP anomaly monitoring covers bugs but not vulnerabilities. See our IEC 81001-5-1 guide
IEC 82304-1	Health software products that are not medical devices. References IEC 62304 for the lifecycle	Nothing, for a medical device manufacturer — but it is the reason IEC 62304 already reaches beyond medical devices in practice

For devices containing a machine learning model, a further layer applies on top of all of these. The lifecycle obligations of IEC 62304 do not disappear, but they are not sufficient on their own — see our guide to AI medical device regulation under the EU MDR, the FDA and ISO 42001.

IEC 62304 and the FDA

The FDA recognises IEC 62304 as a consensus standard. That is a narrower statement than it sounds: recognition means a declaration of conformity to it can be used to support a premarket submission, not that conformity is required. The FDA has its own expectations for software documentation, expressed through its premarket software guidance and its documentation levels.

Those documentation levels — Basic and Enhanced — are not the IEC 62304 safety classes, and there is no clean mapping between them. They govern a comparable question, namely how much documentation a submission needs relative to risk, but they use different criteria and are determined independently. A file built to Class C does not automatically satisfy Enhanced Documentation Level, and vice versa.

Since the QMSR took effect in February 2026, incorporating ISO 13485 by reference into 21 CFR Part 820, the quality system foundation that IEC 62304 clause 4.1 assumes is the same on both sides of the Atlantic. The software lifecycle requirements themselves did not change.

Edition 2: what it changes and where it actually stands

A second edition has been in preparation for years, and a great deal of published commentary states that it would be released in August 2026. That has not happened, and the reason is worth setting out precisely, because the planning consequences are real.

The actual status

The first Committee Draft went out in 2025. The IEC SC62A MT49 working group received close to 1,500 comments on it and had to work through all of them. The outcome is that the next document to be published is a second Committee Draft, not the standard. On that trajectory an FDIS is not expected before 2028, with publication following. The IEC’s own forecast publication date for the project is October 2028.

There is also precedent for delay here. An earlier attempt at a second edition reached draft international standard stage and had its status changed to withdrawn at the turn of 2021 and 2022. This is the second time the revision has slipped substantially.

And publication is not the end of it. Before Edition 2 can be used to claim presumption of conformity in Europe, CENELEC has to prepare the Z annexes and the standard has to be listed in the Official Journal. The FDA would separately have to add it to its recognised consensus standards list. Historically that process takes a further two to three years after publication.

Figure 3 — The road to a second edition, and where it currently stops

What Edition 2 proposes to change

The drafts are still moving, so treat the following as direction of travel rather than as requirements. The clause structure survives largely intact — no chapters are removed, several sub-clauses are added — which is why the transition, when it eventually arrives, is expected to be manageable.

Area	Proposed change	Why it matters
Scope	The title moves from medical device software to health software, a superset that includes software not regulated as a device	Wellness and fitness software would have a state-of-the-art lifecycle standard for the first time. For device manufacturers, little changes in substance
Classification	The committee draft proposes replacing three safety classes with two Software Process Rigor Levels, aligning with IEC 81001-5-1. Level I corresponds broadly to Class A; Level II absorbs both B and C	Class B software would move up to the rigour currently required of Class C. This is the change with real remediation cost, and it is the one most likely to shift before publication
Security	A dedicated security risk management sub-clause, and explicit security requirements in requirements analysis	Cybersecurity moves from a bolt-on to a named process step
Usability	A dedicated sub-clause, while IEC 62366 ceases to be a normative reference	Usability becomes an obligation without a mandated method
Risk management	ISO 14971 conformity would no longer be normatively required in all cases, with justified alternatives permitted	Of theoretical interest for medical devices; a Notified Body will still expect ISO 14971
AI	Explicit planning requirements for software incorporating AI or machine learning	The first time the standard addresses models directly
Legacy software	Moved to an informative annex	Guidance rather than requirement — arguably a loss for manufacturers who rely on clause 4.4

What to do about it

Nothing urgent, and that is the point of setting the timeline straight. Three things are worth doing anyway, because they hold value under the current edition:

Do not start a remediation programme against Edition 2. The classification model that would drive the remediation is precisely the part still under discussion, and the second committee draft has not been published. Work planned this year against an August 2026 publication was planned against a date that did not exist.

If you are choosing an architecture now, partition for Level I. The proposed model rewards isolating safety-relevant functionality far more than the current one does, because everything not in Level I lands in a single high-rigour bucket. This is good architecture under the current edition too.

Treat security as a process, not a document. Every draft in this revision has moved in that direction, and IEC 81001-5-1 already asks for it. Nothing here depends on the timeline.

✦ Complete catalogue

Find the documentation you need — instantly.

Whether you need a complete kit or just one specific SOP, the catalogue has it. Individual process packages and complete bundles, all instantly downloadable and fully editable.

✓ Complete bundles or individual packages

✓ Individual process packages from €69 each

✓ Software · ISO 13485 · MDSAP · EU MDR · EU IVDR

Browse All Kits →

The audit findings that recur

Unjustified safety classification. A class assigned with no recorded reasoning, or a rationale that leans on warnings and training to bring the class down. Both are findings, and the second is the more common of the two.

Broken traceability. Requirements with no linked test, tests with no linked requirement, or risk control measures that trace to nothing. These usually surface during integration and system testing, and by then they are expensive.

Software hazards absent from the risk file. The clause 7 analysis exists as a software document and never connects to the ISO 14971 risk management file. The two have to be one system, not two.

Incomplete SOUP documentation. Each third-party component needs its version, its role in the system, its known anomalies and a record of ongoing monitoring. Missing anomaly monitoring is the usual gap: the list was compiled once at integration and never revisited.

Change control without impact analysis. Bug fixes, enhancements and security patches implemented without a documented assessment of what they affect, and without re-verification proportionate to that assessment.

A Software Development Plan that no longer matches reality. The plan describes a lifecycle model the team abandoned in month three. Since the plan is what everything else is assessed against, this finding tends to bring several others with it.

Probability set to 1 throughout the risk file. The classification instruction carried into risk estimation, producing a risk file where every software hazard is maximally probable and risk evaluation conveys nothing.

Frequently asked questions

What is IEC 62304?

IEC 62304 is the international standard defining life cycle processes for medical device software. It applies both to software that is a medical device in its own right and to software embedded in one, and it specifies the activities, tasks and documentation required across development, maintenance, risk management, configuration management and problem resolution. The current version is IEC 62304:2006 with Amendment 1:2015, usually referred to as the consolidated 2015 version.

What are the IEC 62304 safety classes?

Class A: the software cannot contribute to a hazardous situation, or the risk is acceptable once risk control measures external to the software are considered. Class B: it can contribute to a hazardous situation resulting in unacceptable risk, but the possible harm is non-serious injury. Class C: the possible harm is death or serious injury. Each software item is classified individually, the highest class of any item determines the class of the system, and software that is not classified defaults to Class C.

Has IEC 62304 Edition 2 been published?

No. Many guides published in 2025 and 2026 stated that Edition 2 would appear in August 2026. It did not. The working group received roughly 1,500 comments on the 2025 committee draft, and the next document to be issued is a second committee draft rather than the standard. An FDIS is not expected before 2028; the IEC’s own forecast publication date is October 2028. IEC 62304:2006+A1:2015 remains the standard in force.

What changes in IEC 62304 Edition 2?

The drafts propose extending the scope from medical device software to health software generally, replacing the three safety classes with two Software Process Rigor Levels, adding explicit security risk management and usability sub-clauses, introducing planning requirements for AI and machine learning, and moving legacy software into an informative annex. The clause structure is largely retained. All of it remains subject to change before publication.

Does Class A software need documentation?

Yes. Class A removes the architectural design, unit verification, integration testing and system testing requirements of clauses 5.3 and 5.5 to 5.7. Software development planning, requirements analysis and release still apply, as do all four of the supporting processes — maintenance, risk management, configuration management and problem resolution.

Is the IEC 62304 safety class the same as the EU MDR device class?

No. They are determined by different criteria and neither substitutes for the other. Class C software is often found in Class IIb or III devices, but the correlation is not a rule and each classification has to be performed and justified on its own terms.

Can warnings in the instructions for use lower the safety class?

No. Only risk control measures external to the software system can lower the class — a hardware interlock or an independent monitoring circuit, for example. Information for safety, including warnings, labelling and training requirements, does not reduce the safety class, and a classification rationale that relies on it will be challenged.

Does the FDA require compliance with IEC 62304?

No. The FDA recognises IEC 62304 as a consensus standard, which means a declaration of conformity can support a premarket submission, but conformity is not mandatory. The FDA applies its own documentation levels, Basic and Enhanced, which are determined independently of the IEC 62304 safety classes and do not map cleanly onto them.

Conclusions

IEC 62304 is a process standard with one decision at its centre. The safety classification determines how much architecture you document, how much verification you perform, and how much of your development history has to be reconstructible years later. Every other choice follows from it, which is why an unjustified classification is the finding that brings other findings with it.

The two levers worth pulling are both structural. Partition the architecture so that safety-relevant functionality is isolated in a small number of items, because the step from Class A to Class B costs far more than the step from B to C. And connect clause 7 to the ISO 14971 file properly, because a software risk analysis that nothing references is work performed and not banked.

On Edition 2: build to the current standard. The revision has now slipped twice, the second committee draft is still to come, and even after publication the CENELEC and FDA recognition processes add years. Anyone who planned remediation against an August 2026 release was working from a date that never had a document behind it.

If you are building the software documentation set, the SW Documentation Kit Gold covers the IEC 62304 lifecycle, the AI/ML module and the cybersecurity documentation as one cross-referenced set, scalable to Class A, B or C.