IEC 62304 in Practice: What Software Safety Classification Actually Changes

IEC 62304 ("Medical device software — Software life cycle processes") is the standard regulators expect a manufacturer to follow when developing and maintaining medical device software, and it's referenced by both FDA guidance and EU MDR technical documentation requirements. Teams that have only skimmed it tend to treat it as a generic "have a process" requirement. In practice, the standard's central mechanism — software safety classification — is what determines exactly how much process you need, and getting the classification wrong (or ignoring it until late) is one of the most expensive mistakes an engineering team can make on a regulated device. This is a description of how the standard works structurally, not regulatory advice; classification and its consequences always need to be confirmed with your regulatory/quality function for your specific device and jurisdiction.

The three classes, and what "severity of harm" actually means

IEC 62304 classifies each software system (and, in practice, individual software items within it) into Class A, B, or C based on the severity of harm that could result if the software fails or contains a defect:

• Class A — no injury or damage to health is possible from a failure.
• Class B — non-serious injury is possible.
• Class C — death or serious injury is possible.

The classification isn't assigned to the product as a marketing category — it's derived from a hazard analysis (which ties directly into ISO 14971 risk management) asking, for each software item, what happens if it does the wrong thing or nothing at all. A dose-calculation module and a Bluetooth pairing screen in the same device can carry very different classifications, and the standard expects that granularity rather than one blanket rating for the whole codebase.

What actually changes as the class goes up

This is where classification stops being an abstract label and starts dictating engineering practice:

• Documentation depth. Class A software can get away with lighter-weight process documentation. Class B and C require increasingly detailed software requirements, architecture, and detailed design documents — and each has to be traceable to the ones above and below it.
• Verification rigor. Class C software generally needs unit-level verification in addition to integration and system-level testing, with documented test coverage against requirements. For Class A, informal verification may be defensible; for Class C, it typically isn't.
• Configuration management and problem resolution. Higher classes bring stricter expectations around change control, defect tracking, and the ability to show exactly what changed, why, and what was re-verified as a result — which has direct implications for how a team runs its git workflow and CI process, not just its paperwork.
• SOUP (Software of Unknown Provenance) handling. Third-party libraries, RTOS components, and open-source dependencies all need to be identified, and their known anomalies assessed against your safety classification — a step teams accustomed to consumer firmware development often haven't had to formalize before. This overlaps directly with the Software Bill of Materials FDA now expects in cybersecurity documentation — see our note on FDA cybersecurity requirements and SBOMs.

None of this is about writing more documents for their own sake. It's about being able to demonstrate — with evidence, not assertion — that the software does what it's supposed to do and that failure modes have been anticipated and controlled to a degree proportional to the harm they could cause.

Why classification decided late is expensive

Classification is meant to inform architecture and process from the start, not get bolted on before a submission. A team that builds first and figures out classification later usually discovers one of two problems: components that turn out to be Class C don't have the traceability or unit test evidence a reviewer will expect, and reconstructing that evidence after the fact against code that's already shipped iterations is far more labor-intensive than building it incrementally. Or, just as commonly, the whole system gets treated as Class C by default out of caution, which means low-risk components (a settings screen, a logging utility) end up carrying process overhead they don't need — slowing the team down without improving safety.

The fix is architectural as much as procedural: isolating higher-classification logic (the parts that actually drive a safety-relevant output) from lower-classification supporting code (UI, connectivity, logging) with clear interfaces lets a team apply 62304's rigor where it's earned and move faster everywhere else. That separation is a design decision, and it's much cheaper to make early than to retrofit — the same failure-mode-first thinking we describe in our note on fail-safe design for medical wearables.

Practical takeaway

Software safety classification under IEC 62304 isn't a compliance checkbox to satisfy near the end of a project — it's an early architectural input that should shape how a codebase is partitioned, how requirements get written, and what level of test evidence gets built up as the system is developed. We build firmware and embedded systems with that discipline in mind from the outset — see our firmware work and embedded hardware work, and our broader medical IoT and connected medical device development, for how this fits into a full engagement. For the broader regulatory picture this classification sits inside, see our notes on regulatory basics for connected medical devices and HIPAA-compliant data handling for health devices.