Written and maintained by CASRAI Editorial Board
Last updated
IEC 62304 software safety classification (defined in Clause 4.3 of IEC 62304:2006+AMD1:2015 — Medical device software: Software life cycle processes) is the foundational engineering and regulatory mechanism that determines which software development, verification, and risk-management deliverables are mandatory for a medical device software system or Software as a Medical Device (SaMD). Distinct from overall regulatory device classification—such as U.S. FDA Class I, II, and III or EU MDR Rule 11 Class I, IIa, IIb, and III—IEC 62304 assigns a software-specific safety class (Class A, Class B, or Class C) that scales lifecycle rigor and maps directly to FDA’s 2023 Basic vs Enhanced Documentation Levels and the IEC 62304 deliverable checklist.
How Are IEC 62304 Software Safety Classes A, B, and C Defined?
Because software fails systematically (via deterministic logic defects, unhandled edge cases, or concurrency race conditions) rather than through predictable physical wear-and-tear, IEC 62304 Annex B.4.3 explains that the numeric probability of a software failure cannot be reliably estimated statistically prior to classification. Therefore, IEC 62304 Clause 4.3 classifies every software system (and subsequently decomposed software items) based on the severity of harm resulting from a hazardous situation to which a software failure can contribute:
- IEC 62304 Class A: The software system cannot contribute to a hazardous situation, OR any hazardous situation to which it could contribute (after accounting for external risk control measures) cannot result in injury or damage to health.
- IEC 62304 Class B: The software system can contribute to a hazardous situation whose worst-case severity (after accounting for external risk control measures) is non-serious injury (reversible harm not requiring major surgical/medical intervention).
- IEC 62304 Class C: The software system can contribute to a hazardous situation whose worst-case severity (even after external risk control measures) is death or serious injury (defined per ISO 14971 as life-threatening injury, permanent impairment of a body function or permanent damage to a body structure, or injury necessitating medical or surgical intervention to prevent permanent impairment).
Under Clause 4.3(d) and 4.3(g), a software system is initially classified as Class C by default until the manufacturer completes and documents a formal ISO 14971 risk analysis justifying Class A or Class B in the Risk Management File.
How Did Amendment 1 (2015) Change IEC 62304 Software Safety Classification Using External Risk Controls?
In the original 2006 edition of IEC 62304, manufacturers were required to assign the initial software safety class before taking credit for any hardware or procedural risk controls. As a result, even if an independent hardware thermal cutoff physically prevented a device from overheating, the control software was still forced into Class C initially. Amendment 1 (2015) replaced Clause 4.3 with a four-step Risk-Based Software Safety Classification Decision Tree:
- Step 1 — Can a hazardous situation arise from a failure of the software system? If No → Class A. If Yes → proceed to Step 2.
- Step 2 — Does the failure of the software system result in an unacceptable risk BEFORE any risk control measures are applied? If No (risk is already acceptable per the ISO 14971 risk acceptability matrix) → Class A. If Yes → proceed to Step 3.
- Step 3 — Are Risk Control Measures EXTERNAL to the software system implemented to reduce the risk?
- If external risk controls (such as an independent hardware watchdog/interlock, a mechanical relief valve, or a verified clinical workflow verification step) reduce the residual risk to an acceptable level → Class A.
- If external risk controls only partially reduce the risk (or no external controls exist), evaluate the worst-case severity of the remaining hazardous situation in Step 4.
- Step 4 — Evaluate Resulting Severity After External Risk Controls:
- If worst-case resulting harm is non-serious injury → Class B.
- If worst-case resulting harm is death or serious injury → Class C.
Architectural Segregation: Decomposing a Class C System into Lower-Class Items (Clause 5.3.5)
When a top-level software system is classified as Class C (or Class B), every software item inside it inherits that top-level class unless the manufacturer decomposes the architecture into distinct software items and documents in the risk management file why a specific item (for example, a user-interface theme module or a non-critical SOUP logging library) merits a lower safety classification. Under Clause 5.3.5, the software architecture must identify and verify effective segregation mechanisms (process isolation, memory protection units, hardware partitioning, and strict input/output sanitizers) proving that a failure in the Class A or Class B item cannot negatively impact any Class C software item.
Which IEC 62304 Lifecycle Clauses Are Required for Class A vs Class B vs Class C Software?
Assigning Class A, Class B, or Class C directly governs engineering workload and aligns with the U.S. FDA’s June 2023 guidance on Content of Premarket Submissions for Device Software Functions:
| Engineering Process / Regulatory Mapping | IEC 62304 Class A | IEC 62304 Class B | IEC 62304 Class C |
|---|---|---|---|
| Software Requirements Analysis (Clause 5.2) | Required (5.2.1–5.2.6) | Required (5.2.1–5.2.6) | Required (5.2.1–5.2.6) |
| Software Architectural Design (Clause 5.3) | Not required (unless used to prove segregation) | Required (5.3.1–5.3.6: items, interfaces, SOUP specs, verification) | Required (5.3.1–5.3.6 including segregation control 5.3.5) |
| Software Detailed Design (Clause 5.4) | Not required | 5.4.1 only (refine architecture into software units) | Full 5.4.1–5.4.4 (documented detailed design for every unit and external interface, plus formal verification) |
| Unit Implementation & Verification (Clause 5.5) | 5.5.1 only (implement units) | 5.5.1, 5.5.2 (unit verification process), 5.5.3 (acceptance criteria), 5.5.5 (unit verification) | Full 5.5.1–5.5.5 including 5.5.4 Additional Unit Acceptance Criteria (proper event sequence, data/control flow, fault handling, memory initialization, boundary conditions) |
| Integration & System Testing (Clauses 5.6 & 5.7) | System testing (5.7) required; Integration testing (5.6) not required | Both Integration Testing (5.6) and System Testing (5.7) required | Both Integration Testing (5.6) and System Testing (5.7) required |
| FDA 2023 Premarket Documentation Level Equivalent | Typically maps to FDA Basic Documentation Level | Typically maps to FDA Basic Documentation Level | Maps to FDA Enhanced Documentation Level (where failure could present a probable risk of death or serious injury prior to software risk controls) |
Note a crucial regulatory nuance between IEC 62304 Amendment 1 and the 2023 FDA Premarket Software Guidance: while IEC 62304 Amendment 1 allows external hardware risk controls to lower a software system from Class C to Class B or A, the FDA determines whether a submission requires Enhanced Documentation by evaluating whether a software failure or latent design flaw could present a probable risk of death or serious injury prior to the implementation of risk control measures.
Frequently Asked Questions
How are IEC 62304 Software Safety Classes A, B, and C defined?
Under IEC 62304 Clause 4.3, every medical device software system is assigned to one of three safety classes based on the worst-case severity of injury that could result from a hazardous situation to which the software system can contribute: Class A (no injury or damage to health is possible), Class B (non-serious injury is possible), and Class C (death or serious injury is possible).
How did Amendment 1 (2015) change IEC 62304 software safety classification using external risk controls?
In the original 2006 edition of IEC 62304, initial safety classification was determined before accounting for any risk controls, forcing many software systems into Class C. Amendment 1 (IEC 62304:2006+AMD1:2015 Clause 4.3) introduced a risk-based decision tree that allows manufacturers to evaluate the residual risk remaining AFTER applying risk control measures that are strictly EXTERNAL to the software system (such as independent hardware cutoffs or mechanical pressure relief valves) when assigning Class A, B, or C.
Which IEC 62304 lifecycle clauses are required for Class A vs Class B vs Class C software?
Class A requires software development planning (5.1), requirements analysis (5.2), unit implementation (5.5.1), system testing (5.7), release (5.8), maintenance (6), configuration management (8), and problem resolution (9), but omits architectural design (5.3), detailed design (5.4), and integration testing (5.6). Class B adds architectural design (5.3), unit verification (5.5.2–5.5.3, 5.5.5), integration testing (5.6), and full software risk management (7). Class C adds coding/tool standards (5.1.4), full unit/interface detailed design (5.4.2–5.4.4), and strict unit acceptance criteria (5.5.4).
Sources
- International Electrotechnical Commission (IEC). IEC 62304:2006+AMD1:2015 CSV — Medical device software – Software life cycle processes (Clause 4.3 & Annex B.4.3). https://webstore.iec.ch/en/publication/22794
- U.S. Food and Drug Administration (FDA). Content of Premarket Submissions for Device Software Functions — Guidance for Industry and Food and Drug Administration Staff (June 2023). https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
