Can I lower a class using external risk controls?

Yes, if the external control is not implemented in the same software item and its effectiveness is documented. A hardware watchdog or an independent hardware limit is a common example.

Does FDA accept IEC 62304 classification?

Yes. FDA recognizes IEC 62304 and its amendments. The Level of Concern concept in the 2005 Premarket Software guidance was largely replaced by the 2023 Content of Premarket Submissions for Device Software Functions guidance, which uses Basic vs Enhanced documentation instead.

How do I document classification?

In the software development plan and the software architecture, with a rationale linked to the hazard analysis and any external risk controls relied upon.

All terms

Software & AISoftware Lifecycle Startup Lifecycle

Software Safety Classification

IEC 62304 classes A, B, C reflecting potential harm from software failure.

Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed May 5, 2026

Definition

Per IEC 62304 clause 4.3, software is assigned to Class A (no injury or damage to health is possible), Class B (non-serious injury is possible), or Class C (death or serious injury is possible) based on the hazardous situation to which the software system can contribute, assuming failure of any external risk controls.

What the regulation says

IEC 62304 is the globally recognized standard for medical device software lifecycle processes. It mandates a software safety classification system (Classes A, B, C) based on the potential for the software to contribute to a hazardous situation, influencing the rigor of development, verification, and validation activities. The FDA highlights the importance of hazard analysis in determining appropriate software classification, while the EU MDR emphasizes the general safety and performance requirements that are directly impacted by software classification.

What this means in practice

Classification is done at the software system level after the hazard analysis, then propagated to items and units. Amendment 1:2015 allows decomposition so an item can be assigned a lower class than its parent system when there is segregation of concerns with justification. Class B and C add required activities (detailed design, integration testing, verification of software units, unit testing, documented software architecture). Regulators (FDA and Notified Bodies) frequently challenge under-classification, especially when external risk controls are software-based or unproven.

Examples

A radiation therapy dose calculator: Class C (miscalculation could cause serious injury or death).
An insulin pump bolus algorithm: Class C.
A patient monitor waveform display: Class B (missed alarm could delay clinical response but hardware alarms remain).
A cosmetic image-viewer with no clinical claim: Class A.

Common pitfalls

•Claiming Class A because 'a clinician always checks the output' without documenting that check as a validated external risk control in the risk file.
•Assigning a class to the whole system when segregation would allow a lower class for isolated items - and losing effort savings.
•Not re-classifying after a design change that removes an external risk control (change control gap).
•Confusing software safety class with IEC 60601-1 basic safety or with ISO 14971 risk levels - they are separate axes.

Frequently asked questions

No. Risk (ISO 14971) is severity times probability of harm. Software safety class (IEC 62304) is severity-only and assumes failure of external risk controls. A device can be low risk overall but Class C in software if the software failure mode is severe.

Cross-references

Used by

Things that build on this term.

IEC 62304

Shared paths + category

Standards

IEC 62304

Lifecycle requirements for medical device software.

SaMD & AI/ML Devices · adjacentSoftware Team Onboarding · adjacent

Standards

ISO 14971

International standard for the application of risk management to medical devices.

Quality & Risk

Risk Management File(RMF)

Set of records and outputs from the ISO 14971 risk management process.

Software & AI

Software of Unknown Provenance(SOUP)

Software not developed for medical device use, or lacking adequate development records, incorporated into a device.

SaMD & AI/ML Devices · adjacentSoftware Team Onboarding · adjacent

Software & AI

Clinical Decision Support(CDS)

Software providing healthcare professionals with knowledge and patient-specific information.

SaMD & AI/ML DevicesSoftware Team Onboarding

Software & AI

Predetermined Change Control Plan(PCCP)

FDA mechanism to pre-authorize specific modifications to AI/ML-enabled devices.

SaMD & AI/ML DevicesSoftware Team Onboarding

Latest in MedTech

Primary references

3 sources

Link health: 2 verified 1 unchecked· last checked 2026-06-20

ISO·1FDA·1MDCG·1

Inline markers like [1] jump to the matching reference above.

On this term

Category: Software & AI
Sources: 3
Updated: 5/5/2026

Compare with another term

Learn in 60 seconds

IEC 62304 classes A, B, C reflecting potential harm from software failure.

·Classification is done at the software system level after the hazard analysis, then propagated to items and units.
·Amendment 1:2015 allows decomposition so an item can be assigned a lower class than its parent system when there is segregation of concerns with justification.
·Class B and C add required activities (detailed design, integration testing, verification of software units, unit testing, documented software architecture).

Remember this

Watch out: Claiming Class A because 'a clinician always checks the output' without documenting that check as a validated external risk control in the risk file.

Related terms

You may also need

Auto-suggested from Software & AI and shared keywords.

All Software & AI terms

From the Blue Goat network

Related resources and services on this topic.