Software safety classes
Clause 4.3 asks the manufacturer to assign a safety class to each software system, based on the hazardous situations the software could contribute to and the harm that could result. Amendment 1 (2015) broadened this: any risk control outside the software can be taken into account, and the class depends on whether the remaining risk is acceptable.
| Class | When it applies | Process rigor |
|---|---|---|
| A | The software cannot contribute to a hazardous situation, or the resulting risk is acceptable after risk controls outside the software. | Lightest set; still requires requirements, system testing (since Amendment 1) and release |
| B | An unacceptable risk can remain, and the possible harm is non-serious injury. | Adds architecture, units with verification, and integration testing |
| C | An unacceptable risk can remain, and the possible harm is death or serious injury. | Full rigor, adding detailed design of each unit and its interfaces |
Software items inside a system can be classified separately, which lets teams apply Class C rigor only where it is needed, provided the architecture shows the items are adequately segregated.
The five processes
The standard is organized as a set of processes, each with activities and tasks. Paraphrased:
| Clause | What it covers |
|---|---|
| 5 Development | Planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing, and release. |
| 6 Maintenance | A maintenance plan, analysis of problem reports and modification requests, and implementation of modifications using the development process. |
| 7 Risk management | Identifying how software can contribute to hazardous situations, defining and verifying risk control measures, and managing the risk of software changes. Works within ISO 14971. |
| 8 Configuration management | Identifying configuration items, including SOUP, controlling changes to them, and recording their status and history. |
| 9 Problem resolution | Recording, investigating, evaluating and tracking problems through to resolution, and informing those affected. |
IEC 62304 assumes the software is built inside a quality management system such as ISO 13485, and does not prescribe a development model. Agile teams can comply; the AAMI technical report TIR45 describes how.
This is a summary in our own words. The authoritative text is the standard, available from IEC.
Software changes and maintenance
Most of a device's software life happens after first release, and that is where findings concentrate. Every change to released software, whether a bug fix, a feature or a SOUP update, runs through the same chain:
- Record the request as a problem report or modification request (clauses 6.2 and 9).
- Analyze it: its effect on safety, the software items and the safety class, and whether a regulatory submission is affected (6.2).
- Assess the risk of the change, including side effects on existing risk control measures (7.4).
- Approve and control the change to the configuration items (8.2).
- Implement and verify using the development process, repeating the tests the change affects (6.3 and 5).
- Release with documented versions and known residual anomalies, keeping the change traceable (6.3.2 with 5.8, and 8.2.4).
A software change is also a design change, so ISO 13485 §7.3.9 applies at the same time. See our guide to design change control.
Worked example: a firmware maintenance release
An illustrative case. A team tags firmware v1.4.2 in Git for a steerable catheter's handle controller, fixing a display timing bug. Here is what the change leaves behind when it is handled under IEC 62304.
| Step | What happens | Evidence |
|---|---|---|
| Record | The bug report becomes a problem report linked to the release. | Problem report PR-112 |
| Analyze | The fix touches the display module only; the safety class of the affected item (B) is unchanged. | Change analysis |
| Risk | The team checks that no risk control measure depends on the changed timing. | Risk review note, hazard links |
| Regulatory | A bug fix that restores intended behavior; no new submission expected under FDA's software change guidance. | Regulatory assessment |
| Verify | Unit and integration tests for the display module are rerun, plus regression on system tests. | Test reports |
| Release | Version, configuration and residual anomalies are documented and approved. | Release record v1.4.2 |
The trigger is a Git tag, an event the quality system usually never sees. The interactive demo shows this exact release being detected and cleared.
SOUP: software of unknown provenance
SOUP is software that is already developed and generally available but was not made for your device, such as an operating system, library or open-source component, or software you developed earlier without adequate development records. The standard does not forbid it. For every class, you identify each SOUP item with its title, manufacturer and version. For Class B and C, you also state the functional and performance requirements you rely on, specify the hardware and software it needs, and evaluate its published anomaly lists for effects on safety. Updating a SOUP version is a software change and goes through the maintenance process.
How FDA and the EU use IEC 62304
United States
IEC 62304 is an FDA-recognized consensus standard. FDA's 2023 guidance Content of Premarket Submissions for Device Software Functions replaced the old "level of concern" with two documentation levels, Basic and Enhanced. Enhanced applies where a software failure could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are applied; FDA also generally expects it for Class III devices. Unlike IEC 62304's classes, external risk controls do not lower this level. For the software development and maintenance section, manufacturers can provide a declaration of conformity to IEC 62304 or a summary of their lifecycle processes; at the Enhanced level, FDA also asks for the complete configuration management and maintenance plan. Under the QMSR, design controls in ISO 13485 §7.3 apply to software too.
European Union
MDR Annex I §17.2 requires device software to be developed and manufactured according to the state of the art, taking into account the development lifecycle, risk management including information security, and verification and validation. EN 62304 is not yet listed as a harmonized standard under the MDR, but notified bodies widely treat it as the state of the art for meeting §17.2.
Edition 2: what is coming, and when
A second edition has been in development for years. The draft extends the scope from medical device software to health software in general, and replaces classes A, B and C with two software process rigor levels. After the 2025 committee draft drew around 1,500 comments, according to the Johner Institute, publication slipped: IEC's current forecast is October 2028, and some observers expect 2029. Until then, IEC 62304:2006 with Amendment 1:2015 is the version to comply with.
What auditors check
- A documented safety classification for each software system and item, with its rationale
- A software development plan and a maintenance plan that match what the team actually does
- Traceability from requirements to architecture, tests and risk control measures
- A SOUP list with versions, requirements and anomaly evaluations
- Problem reports and modification requests, each with analysis and outcome
- Risk assessment of every software change before release
- Release records with versions, configuration and known residual anomalies
How Omni Octa handles software changes
Omni Octa watches Git, Jira and your CI for releases and changes. A new tag or merged change is classified against IEC 62304 §6.2, checked for missing problem reports, risk review and test evidence, and routed to the owners. If something is missing, release is blocked; when it is complete, the decision is recorded with its clause and a tamper-evident hash.
Frequently asked questions
What are the IEC 62304 software safety classes?
Class A: the software cannot contribute to a hazardous situation, or the risk is acceptable after external risk controls. Class B: unacceptable risk can remain and the possible harm is non-serious injury. Class C: unacceptable risk can remain and the possible harm is death or serious injury.
Is IEC 62304 mandatory?
Not by name. In the US it is a recognized consensus standard, and in the EU it is the usual way to show the software lifecycle meets MDR Annex I §17.2. In practice, notified bodies and FDA reviewers expect it or an equivalent, well-justified process.
Can we use agile development under IEC 62304?
Yes. The standard defines processes and outputs, not a development model. AAMI TIR45 gives guidance on applying agile practices to medical device software.
Does a software update need a new 510(k)?
It depends on whether the change could significantly affect safety or effectiveness. FDA's guidance on software changes to existing devices walks through the decision; document the outcome either way.
When will IEC 62304 Edition 2 be published?
IEC currently forecasts October 2028, after delays caused by the volume of comments on the 2025 draft. Some observers expect 2029. The 2006 edition with Amendment 1:2015 remains current until then.
Sources
- IEC 62304:2006+AMD1:2015, Medical device software — Software life cycle processes
- FDA: Content of Premarket Submissions for Device Software Functions (June 2023)
- QuickBird Medical: IEC 62304 Edition 2 delayed to October 2028
- Johner Institute: IEC 62304 2nd edition, scope and changes
- Casus Consulting: MDR harmonized standards list (2026)
- Regulation (EU) 2017/745 (MDR), Annex I §17.2
This page is general information, not legal or regulatory advice for a specific device.