We have seen the same conversation happen more than once. A firmware team has built something genuinely good — a battery-powered monitor, clean RTOS architecture, disciplined code, a test rig that runs overnight. Then someone asks for the software requirements specification, the traceability matrix, and the record showing which unit tests verify which risk control. The room goes quiet. The engineering is fine. The evidence that the engineering happened is missing, and in a regulated submission, missing evidence is indistinguishable from missing work.
ISO 13485 and IEC 62304 are not code quality standards. They are evidence standards. They describe a process you can show an auditor, a notified body, or an FDA reviewer, and they assume that if you follow the process, the software that comes out the other end is safe enough for its intended use. Understanding what each standard actually asks for — and what it deliberately leaves to your judgement — saves months of retrofitting documentation onto a product that is already in DVT.
Two standards, two very different jobs
People say "13485 and 62304" as if they were one requirement. They operate at different levels.
ISO 13485:2016 is a quality management system standard for the whole organisation that designs, manufactures or services medical devices. It covers management responsibility, document and record control, design and development controls, purchasing and supplier evaluation, production, complaint handling, corrective and preventive action (CAPA), and internal audits. It applies to your company, not to your firmware. Notably, clause 4.1.6 requires you to validate the software you use to run your QMS and your processes — your test automation, your issue tracker, your build server — proportionate to risk. That one catches teams out constantly.
IEC 62304 is a software life cycle standard. It applies to medical device software: software that is part of a device, or that is a device in its own right. It defines processes rather than prescribing a methodology: software development planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing, release. Alongside those it defines maintenance, software risk management, configuration management, and problem resolution as ongoing processes that never really finish.
The important structural point: IEC 62304 assumes a QMS and a risk management process already exist. It explicitly relies on ISO 14971 for hazard identification, risk estimation, risk control and residual risk evaluation. You cannot do 62304 properly without 14971 running underneath it. And neither one replaces the regulatory route itself — EU MDR 2017/745, an FDA 510(k) or De Novo, or whichever jurisdiction you are entering.
Safety classification decides how much work you do
IEC 62304 assigns every software system — and, importantly, its individual software items — a safety class:
- Class A: no injury or damage to health is possible from software failure.
- Class B: non-serious injury is possible.
- Class C: death or serious injury is possible.
Amendment 1 (2015) tightened this considerably. Classification is based on the severity of harm that could result if the software fails, considered before software risk controls but after risk controls external to the software — hardware interlocks, mechanical limits, independent monitors. In practice, if a hazardous situation can arise from a software failure, you are in B or C, and you need a documented rationale for whichever class you claim.
The required activity set scales with the class. Class A is comparatively light. Class B adds architectural design, documented segregation, integration testing rigour, and anomaly evaluation for third-party components. Class C adds detailed design down to the unit level, documented unit verification acceptance criteria, and the strictest treatment of residual anomalies at release.
This is where architecture becomes a regulatory tool, not just an engineering preference. If you can demonstrate genuine segregation — separate MCU cores, MPU-enforced memory partitions, an independent safety monitor, a hardware watchdog outside the application processor — you can justify classifying some software items lower than the system as a whole. That decision, made early, can be the difference between a manageable documentation set and an enormous one. Made late, it is a rewrite.
What an audit actually asks to see
Auditors do not read your source code line by line. They pull threads and see whether they hold. Expect to produce, and keep current:
- A software development plan that names the life cycle model, deliverables, standards, tools and configuration items — written before development, not after.
- Software requirements that are specific, verifiable and uniquely identified, including performance, timing, interfaces, alarms, security, and behaviour under fault conditions.
- A software architecture document showing items, interfaces, and how safety-relevant items are segregated from the rest.
- Bidirectional traceability from system requirements through software requirements, architecture, units, tests and identified risk controls — so a reviewer can pick any hazard and follow it to the code and the test that proves the control works.
- Verification records with pass/fail criteria and actual results, tied to a specific software version and build.
- A risk management file per ISO 14971 that includes software-caused hazardous situations, not just electrical and mechanical ones.
- A problem resolution record: every anomaly logged, evaluated for safety impact, dispositioned, and — for anything left unresolved at release — justified.
- Release documentation: what was built, from which sources, with which toolchain, verified how, with which known residual anomalies.
The most common audit finding we see discussed in this space is not a bad design. It is a trace matrix that no longer matches the code, or a test report that cannot be tied to a specific, reproducible build.
SOUP, third-party stacks, and legacy firmware
Almost no embedded medical product is written entirely in-house. You have an RTOS, a BLE stack, a USB stack, a filesystem, an encryption library, vendor HAL code, maybe a graphics library. IEC 62304 calls this SOUP — software of unknown provenance — and it demands specific handling.
For each SOUP item you need to record the identity, version and manufacturer; the functional and performance requirements you rely on it for; and the hardware and software resources it needs. For Class B and C you must also evaluate published anomaly lists and assess whether any known defect could contribute to a hazardous situation. "We use the vendor stack, it's fine" is not an evaluation.
Two practical consequences. First, pin your versions and archive the sources — you must be able to rebuild a released binary years later. Second, every SOUP upgrade is a change that goes through your change control and re-verification, so choose components whose maintenance model you can live with for the product's whole market life. A vendor stack that ships breaking changes every quarter is a compliance cost, not just an engineering annoyance.
If you are bringing an existing product into compliance, Amendment 1 added a legacy software route: you assess the software against current requirements using post-market data and a documented gap analysis, then close the gaps that matter, rather than reverse-engineering a full development history you never had. It is real, it is legitimate, and it is far cheaper than pretending.
The embedded-specific issues the standards do not spell out
IEC 62304 is deliberately technology-neutral. That leaves the hard firmware questions to you, and reviewers will ask about them anyway.
Timing, memory and determinism
If a requirement says an alarm annunciates within a bounded time, you have to verify it — which means worst-case execution path analysis, priority inversion review, stack depth analysis, and heap policy. Many teams simply forbid dynamic allocation after initialisation because it is easier to defend than to characterise.
Unit verification on host versus target
Host-based unit tests are fast and give you coverage numbers. They also run on a different compiler and a different word size than the device. A defensible strategy usually uses both: host tests for logic and coverage, on-target tests and hardware-in-the-loop runs for timing, peripheral behaviour and integration. Document which you used for what, and why.
Coding standards and static analysis
Neither standard names MISRA C. But 62304 does ask you to define and follow coding standards, and a documented subset with justified deviations plus static analysis output is strong, cheap evidence. Treat unresolved warnings as anomalies in your problem resolution process.
Security and field updates
Cybersecurity is now inseparable from safety for connected devices. IEC 81001-5-1 gives a security life cycle that maps onto 62304, and regulators in both the EU and US expect a threat model, an SBOM, and a plan for handling vulnerabilities post-market. If you support firmware over-the-air updates, signature verification, rollback behaviour and power-loss recovery are all safety requirements that need their own tests.
Machine learning in the device
An inference model running on-device is still software under 62304 — but the standard was not written with data-driven components in mind, so you carry extra weight: dataset provenance, training and validation separation, performance across intended patient populations, and a change control plan if the model will ever be updated. If that is your situation, our AI and ML engineering work is where we usually start those conversations, because the model lifecycle and the software lifecycle have to be planned together, not stitched together later.
Agile is allowed. Improvisation is not.
A persistent myth is that IEC 62304 forces a waterfall. It does not. It requires that activities happen, that inputs precede outputs, and that records exist. AAMI TIR45 exists specifically to explain how agile practices map onto medical device software development, and incremental delivery works well here — provided each increment carries its requirements, its verification and its risk review with it.
What breaks is the informal part of agile culture: undocumented scope changes, verbal acceptance, tests that live only in someone's terminal history. The habit worth building is that a story is not done until its requirement, its trace links, its test record and any risk impact are updated in the same change. Retrofitting a trace matrix across eighteen months of sprints costs several times what maintaining it costs. We have seen how teams we embed with clients work best when compliance tasks sit inside the definition of done rather than in a separate documentation phase at the end.
When you do not need all of this
Honest advice: not every health-related product needs this apparatus, and taking it on unnecessarily is expensive.
- General wellness products that make no diagnostic or therapeutic claim are usually outside medical device regulation in both the US and EU. The claim you make on the box is what pulls you in.
- If your software genuinely cannot cause harm — a logging companion app, a purely informational display with an independent safety path in hardware — a defensible Class A rationale means a much lighter activity set.
- You may not need to be ISO 13485 certified yourself. Certification belongs to the legal manufacturer. Development partners frequently operate as controlled suppliers within the manufacturer's QMS, working to their procedures, templates and design history file. That is a normal and accepted arrangement, and it is often faster than building a parallel QMS.
- If you are early in feasibility, a throwaway prototype does not need design controls. What matters is knowing the point at which it stops being a prototype — and not letting prototype code drift into the product without going through requirements, review and verification.
The reverse is also true. If your device delivers energy or a therapy, controls dosing, drives an alarm that a clinician relies on, or makes a call that changes treatment, plan for Class C from day one. That decision shapes your architecture, your MCU selection, your test infrastructure and your schedule, and it is much cheaper to make at the whiteboard than at the design review.
If you are scoping medical device firmware, bringing legacy software into compliance, or trying to work out which safety class you can defend before you commit to an architecture, we are happy to talk it through — including telling you when the simpler path is the right one. You can see the kind of embedded and platform work we take on in our work, or just get in touch and describe the device.
