Key takeaways
- IEC 62304 governs the software lifecycle, not the whole device — pair it with ISO 13485 and ISO 14971.
- Safety classes A / B / C are driven by the harm a software failure can cause, after risk control.
- Class B and C require detailed architecture, unit verification and full traceability; class A is lighter.
- The standard expects a software safety classification, SDLC plan, and a problem-resolution process.
- Traceability from requirement → design → test is the deliverable auditors check first.
What IEC 62304 actually covers
IEC 62304 defines the software development lifecycle for medical device software, whether the software is the device (SaMD) or embedded firmware inside one. It does not replace your quality system: ISO 13485 governs the quality management system around it, and ISO 14971 governs risk management that feeds the software safety classification. Think of the three as a stack — 13485 is the company, 14971 is the risk, 62304 is the code.
The standard is process-based. It tells you what processes and records you need — planning, requirements analysis, architectural design, implementation, verification, release, maintenance, and problem resolution — without prescribing a specific methodology. Agile, V-model or incremental are all acceptable if the records exist.
The safety classification: A, B, C
Before you write a line of production code, you classify each software item by the worst plausible harm a failure could cause, after external risk controls are considered:
| Class | Possible harm from failure | Rigour required |
|---|---|---|
| A | No injury or damage to health is possible | Lightest: lifecycle records, but no detailed architecture/unit verification mandated |
| B | Non-serious injury is possible | Detailed software architecture, unit verification, integration testing, full traceability |
| C | Death or serious injury is possible | Everything in B, plus the most exhaustive design detail, verification and documentation |
A common engineering lever: if architecture segregates a high-risk function so a failure cannot reach the patient, you may justify a lower class for the rest of the software. That segregation must itself be documented and verified. See our class B vs C cost analysis for how this drives budget.
The lifecycle processes and their deliverables
Planning and requirements
You produce a software development plan and a versioned set of software requirements derived from system requirements and risk controls. Every requirement gets a unique identifier so it can be traced downstream.
Architecture and detailed design (class B/C)
For class B and C you document the software architecture — items, interfaces, and how risk-control measures are realized. Class C adds the deepest detailed design. Class A is exempt from the detailed architecture requirement.
Implementation, verification and integration
Code is implemented to the design, then verified. Class B and C require unit verification against documented acceptance criteria and integration testing of assembled items. Results are recorded, not just run.
Release, maintenance and problem resolution
Release requires that planned activities are complete and known anomalies are evaluated. A problem-resolution process must capture, investigate and track every defect across the product’s life — this connects directly to post-market obligations.
Traceability is the deliverable that fails audits
The single most-checked artifact is bidirectional traceability: each software requirement traces to its design, its verification, and to the risk control it implements — and back again. If a reviewer picks a random requirement and cannot follow it to a passing test, the file is incomplete regardless of code quality. Build the traceability matrix from day one; reconstructing it at the end is where projects bleed schedule.
Where IEC 62304 fits with other standards
IEC 62304 rarely travels alone. For market access you also satisfy ISO 13485 (quality system), ISO 14971 (risk), IEC 60601 for electrical safety on powered devices, and increasingly FDA 524B cybersecurity expectations for connected devices. Our 524B cybersecurity guide covers the connected-device overlay, and the compliant medical IoT hub maps the full landscape. Across North America and globally, the lifecycle discipline is the same; the submission wrapper differs by market.
Where Fundamentum fits
IEC 62304 demands traceable lifecycle records and governed releases. Fundamentum, our Canadian IoT platform, gives connected medical devices signed firmware, governed OTA and a complete audit trail inside a SOC 2 Type II perimeter — so the post-market discipline the standard expects is built in, not bolted on. It can interface with AWS, Azure or Google Cloud if your architecture requires it. See the platform →
Frequently asked questions
What are the IEC 62304 software safety classes?
There are three: Class A (no injury possible), Class B (non-serious injury possible), and Class C (death or serious injury possible). The class is set by the worst plausible harm a software failure could cause after risk controls, and it determines how much design, verification and documentation you must produce.
Is IEC 62304 the same as ISO 13485?
No. IEC 62304 governs the software development lifecycle; ISO 13485 governs the surrounding quality management system, and ISO 14971 governs risk management. They work together: 13485 is the company-level system, 14971 feeds the software safety classification, and 62304 covers the code lifecycle itself.
Does class A really need less work?
Yes. Class A is exempt from the detailed architecture and unit-verification requirements that bind class B and C. You still keep lifecycle records, but the documentation and verification burden is materially lighter — which is why architectural segregation to reduce a software item’s class is a common cost lever.
Why is traceability so important?
Traceability is the first thing reviewers check. Each software requirement must trace to its design, its verification and the risk control it implements — and back. If a requirement cannot be followed to a passing test, the file is incomplete regardless of code quality. Build the matrix from day one rather than reconstructing it at the end.
Does IEC 62304 cover cybersecurity?
Only partly. IEC 62304 anchors the lifecycle and connects to risk, but connected devices now also need a dedicated cybersecurity package — notably under FDA 524B — covering SBOM, signed firmware and post-market patching. Treat the two as complementary layers of the same engineering file.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
