Key takeaways
- Cost scales with required rigour (IEC 62304 class), not with code volume.
- Class C adds detailed design, more exhaustive verification, and heavier review/release overhead.
- The biggest line items are verification and documentation, often exceeding coding effort.
- Architectural segregation can move parts of the software to a lower class and cut cost.
- Get the class right early — reclassifying late forces expensive rework of the whole file.
Why lines of code mislead the budget
Two firmware modules can be nearly identical in source size yet differ sharply in cost once they carry different IEC 62304 safety classes. The reason: most of a regulated firmware budget is not typing code — it is the evidence that surrounds the code. Requirements, design records, verification protocols, results, traceability and reviews all multiply as the class rises from B to C.
Where the cost actually goes
| Cost driver | Class B | Class C |
|---|---|---|
| Detailed design records | Architecture + sufficient detail | Architecture + full detailed design, documented and reviewed |
| Unit verification | Required, risk-prioritized | Required, broader coverage and stricter acceptance criteria |
| Integration & system testing | Documented | Documented, more exhaustive, more edge/fault cases |
| Traceability effort | Requirement → test | Requirement → design → test → risk control, end to end |
| Review & release controls | Standard | Heavier review, more formal release gating |
| Anomaly handling | Tracked | Tracked with deeper risk evaluation before release |
Notice that none of these rows are ‘write more code.’ The delta is verification breadth and documentation formality. On many programs, verification and documentation together outweigh implementation effort — and that ratio widens in class C.
The biggest single lever: architectural segregation
You rarely need the entire firmware at the highest class. ISO 14971 risk analysis plus IEC 62304 allow you to segregate the safety-critical function so a failure elsewhere cannot reach the patient. Done well, a small class C core sits inside a larger class A or B codebase — and you only pay class C rigour on the core. The segregation itself must be designed, documented and verified, but it is almost always cheaper than treating everything as class C.
What inflates cost unexpectedly
- Late classification. Discovering in verification that an item is class C, not B, forces retro-documentation and re-test of work already done.
- Reconstructed traceability. Building the matrix at the end instead of as you go is a recurring schedule sink.
- Cybersecurity bolted on late. Connected devices also carry FDA 524B obligations; retrofitting signed firmware and SBOM is costlier than designing them in.
- Tooling debt. Manual test evidence and document control scale badly; disciplined tooling pays back fast at class C.
How to budget realistically
- Classify first. Run the risk analysis and set the class before estimating — see the IEC 62304 guide.
- Estimate by rigour. Size verification and documentation as first-class line items, not overhead.
- Design for segregation. Push as little as possible into class C.
- Account for the connected overlay. Add the 524B cybersecurity package for networked devices.
This applies across North American and global submissions: the engineering file is reusable, so the rigour you pay for once serves multiple markets. The compliant medical IoT hub ties the cost picture to the full compliance path.
Where Fundamentum fits
Much of class C cost is post-market discipline: verified, auditable updates over the product’s life. Fundamentum, our Canadian IoT platform, absorbs that with signed firmware, governed OTA and a built-in audit trail in a SOC 2 Type II perimeter — so you spend engineering on the device, not on rebuilding update and evidence infrastructure. It can interface with AWS, Azure or Google Cloud if your architecture requires it. See the platform →
Frequently asked questions
Why doesn’t lines of code predict medical firmware cost?
Because most of a regulated firmware budget is the evidence around the code, not the code itself. Requirements, detailed design, verification protocols, results, traceability and reviews multiply as the IEC 62304 class rises. Two similarly sized modules can cost very differently if one is class B and the other class C.
What specifically makes class C more expensive than class B?
Class C adds full detailed design records, broader unit verification with stricter acceptance criteria, more exhaustive integration and fault testing, end-to-end traceability and heavier review and release controls. None of it is ‘write more code’ — it is verification breadth and documentation formality.
Can architecture reduce the cost?
Yes — this is the biggest single lever. Using ISO 14971 risk analysis and IEC 62304, you can segregate the safety-critical function so a failure elsewhere cannot reach the patient. A small class C core then sits inside a larger class A or B codebase, and you only pay class C rigour on the core. The segregation must itself be designed and verified.
What inflates the budget unexpectedly?
Late classification (discovering an item is class C, not B), reconstructing traceability at the end, bolting on FDA 524B cybersecurity late, and manual test-evidence tooling that scales badly. Each of these forces rework of completed work — the most expensive kind.
How should I budget a class C program realistically?
Classify first via risk analysis, then estimate verification and documentation as first-class line items rather than overhead, design for segregation to push as little as possible into class C, and add the 524B cybersecurity package for connected devices. The engineering file is reusable across North American and global markets.
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.
