Medical devices
IEC 62304 Medical Device Firmware Development
Kyros Engineering develops medical device firmware to IEC 62304, with software safety classification, design controls, ISO 14971 risk traceability and verification evidence produced as part of development rather than reconstructed before submission. The code in a regulated device is often comparable to its consumer equivalent — the evidence is not, and the evidence is what gets reviewed.
Scope this with usThe expensive mistake in medical firmware is treating the documentation as a phase that comes after the software. By then the traceability has to be reverse-engineered from commit history and memory, which costs more than writing it as you go and produces a weaker record.
We build the lifecycle artifacts alongside the code, so the design history file is a by-product of doing the work properly rather than a project of its own.
Classification drives everything downstream
Class A, B and C are not paperwork tiers — they change architecture. Getting the classification and the segregation argument right early is what keeps the verification burden proportionate.
- Software safety classification argued from the hazard analysis, not assumed
- Architectural segregation used deliberately, so non-safety code is not dragged up to Class C rigour
- SOUP identified, justified and version-pinned from the first commit
- Risk controls traced from ISO 14971 analysis through to the code that implements them
- Verification planned against requirements, so coverage is designed rather than discovered
Evidence as a by-product
Requirements, design, unit and integration verification, and traceability are maintained continuously. When the submission is assembled, the record already exists and matches the software that actually shipped — which is the property reviewers are really testing.
The standards that arrive with 62304
Firmware rarely meets 62304 alone.
- IEC 60601-1 for safety, where firmware carries part of the essential performance argument
- IEC 60601-1-2 for EMC, which regularly sends teams back to both hardware and firmware
- ISO 14971 risk management as the source of the controls firmware must implement
- ISO 13485 design controls as the process wrapper around all of it
- IEC 62366 usability, where the interface behaviour is firmware's responsibility
When to call
You probably want this if…
Frequently asked
We already have firmware with no documentation. What are our options?
Retrospective compliance is possible and it is honest work, but it is more expensive than doing it alongside development and the record is weaker. The first step is a gap assessment: what exists, what the classification should be, and what genuinely has to be reconstructed versus what can be verified forward.
Does IEC 62304 require a specific language or toolchain?
No. It requires a defined process, appropriate rigour for the safety class, and evidence that you followed it. We work in C and C++ with whatever toolchain your team owns, and put the discipline into the lifecycle rather than into tool selection.
Can you work under our ISO 13485 QMS?
Yes, and that is usually the cleaner arrangement — we operate inside your design controls so the record lives with you and stays auditable after the engagement ends.
How does an engagement typically start?
A two-week architecture diagnostic at $6,000. For regulated work that usually means the classification argument, the risk-to-requirement trace, and a plain statement of where the evidence gaps are. You keep the document either way.
Submission approaching and the trace does not close?
We will tell you what is genuinely missing and what only looks missing.