---
title: MDR Firmware Development: Where IEC 62304 Meets Hardware Requirements
description: Firmware for medical devices under EN 62304 and EN 60601-1: hardware abstraction, real-time constraints, and joint hardware and firmware verification.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: firmware development IEC 62304 hardware medical device
canonical_url: https://zechmeister-solutions.com/en/blog/firmware-development-iec-62304-hardware
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Firmware Development: Where IEC 62304 Meets Hardware Requirements

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Firmware in a medical device is software under EN 62304:2006+A1:2015, even when it lives on a microcontroller with no operating system. It is also the layer that makes or breaks EN 60601-1 compliance for programmable electrical medical systems. Treating firmware as "just the hardware team's problem" is the single most expensive assumption a medtech startup can make under MDR Annex I §17.1.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Firmware is software under EN 62304:2006+A1:2015. Bare-metal C on a Cortex-M is in scope. There is no "too small to need a lifecycle" exemption.
- MDR Annex I §17.1 requires devices incorporating electronic programmable systems to be designed to ensure repeatability, reliability and performance in accordance with the intended use. §17.2 requires the software to be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.
- The firmware safety class under EN 62304 is assigned based on the hazard that software failure can contribute to. Hardware mitigations can lower the class. Document that decision honestly.
- Hardware abstraction is not a style preference. It is how you make firmware verifiable and portable across board revisions without re-verifying the whole stack.
- Real-time constraints are design inputs, not nice-to-haves. If a watchdog must fire within 100 ms, that number belongs in the software requirements and the verification plan.

## Why this matters

Every electromedical startup eventually hits the moment where a firmware engineer says "this is embedded, not software, 62304 doesn't apply the same way." It always applies the same way. EN 62304 scope is medical device software. The microcontroller firmware that drives a motor, reads a sensor, controls a heater, or blinks a status LED on a Class IIa device is medical device software. The notified body will apply the standard to it exactly as they apply it to a mobile app.

The real problem is not scope, it is posture. Firmware teams that came up through consumer electronics treat the codebase as an artifact of hardware bring-up. The schematic is the truth and the firmware is whatever made it work. Under EN 62304 the firmware has to stand on its own: documented requirements, documented architecture, documented unit tests, documented integration tests, documented system tests, and a traceability matrix from hazards through to tests. If you try to reconstruct that after the fact, you will miss things, and the notified body will find what you missed.

The second problem is the hardware-firmware seam. EN 60601-1 treats the programmable electrical medical system (PEMS) as a whole. The firmware is not a separate object from the electronics. A hazard like "unintended output when the battery voltage drops" has to be controlled somewhere: in hardware, in firmware, or jointly. The design team has to decide where, document the decision, and verify the control where it lives.

## What MDR actually says

MDR Annex I §17.1 requires that "devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use." §17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.

The harmonised standard that operationalises §17.2 for the software lifecycle is EN 62304:2006+A1:2015. EN 62304 defines activities for planning (clause 5.1), requirements analysis (5.2), architectural design (5.3), detailed design (5.4), unit implementation and verification (5.5), integration and integration testing (5.6), system testing (5.7), and release (5.8). It also defines software safety classification (clause 4.3): Class A, B, or C, based on the severity of possible harm a software failure could contribute to.

EN 62304 allows external risk control measures (hardware safeguards, mechanical locks, user procedures) to reduce the software safety class. The reduction must be justified in the risk file under EN ISO 14971:2019+A11:2021 and documented. This is where firmware and hardware design meet regulatory design.

For electromedical devices, EN 60601-1 clause 14 applies PEMS requirements on top of EN 62304. It adds a risk management process for the programmable system at the hardware-software boundary, with specific requirements for risk control measure verification when the control crosses the boundary.

## A worked example

A Class IIa infusion accessory pumps a fixed volume of saline through a disposable line. The system has three relevant hazards: over-delivery, under-delivery, and uncontrolled free-flow. The team performs the EN ISO 14971 analysis and identifies the following controls:

For over-delivery, a hardware current limit on the pump motor plus a firmware step counter with a maximum per-session limit. The hardware limit is an independent hardware control. The firmware contribution is classified based on the residual hazard if the firmware misbehaves and the hardware control does its job. Because the hardware control is independent and sufficient to prevent serious injury, the contribution of the firmware over-delivery logic is classified as Class B under EN 62304. This decision is documented in the risk file with a justification.

For under-delivery, the primary control is a flow sensor read by firmware, with a firmware alarm on deviation. There is no independent hardware backup. The hazard severity is moderate (therapy delay, not immediate harm), so this firmware function is also Class B.

For uncontrolled free-flow, the primary control is a mechanical slide clamp on the disposable. The firmware has no role. This is not a firmware control.

Now the EN 62304 activities apply to the firmware at Class B. Requirements are written, including "the firmware shall halt motor drive within 50 ms of detecting a step count exceeding the session maximum." The architecture document separates the pump control module from the UI module, from the communication module, and from the hardware abstraction layer. Unit tests cover the step counting logic with boundary cases. Integration tests run on real hardware with a scope on the motor drive line confirming the 50 ms response time. The traceability matrix links hazard RM-0012 to software requirement SR-0047 to test case TC-0103 with a captured scope trace as evidence.

Joint verification with hardware happens at the PEMS level under EN 60601-1 clause 14. The test injects a fault (a simulated stuck sensor) and the PEMS-level response is observed: the hardware current limit triggers, the firmware reads the fault condition, the alarm fires, the system enters safe state. The verification report is signed by both the hardware and firmware leads and the test is referenced from both the EN 62304 system test report and the EN 60601-1 test lab summary.

This is what the auditor wants to see: a clear decision about which layer controls which hazard, evidence that the control works in that layer, and a joint test at the boundary where both layers interact.

## The Subtract to Ship playbook

**Classify firmware safety honestly.** Under EN 62304 clause 4.3, the class is based on the contribution of software failure to harm, considering external risk controls. If a hardware control is truly independent and sufficient, the software class can be reduced. If it is not, do not pretend. A wrong classification is the fastest way to fail a software audit.

**Use a hardware abstraction layer, always.** A thin HAL between the application firmware and the board-specific drivers lets you swap in board rev C without re-verifying the entire application. It also lets you unit test application logic on a PC with a mock HAL. EN 62304 does not require a HAL, but the verification economics make it a near-necessity.

**Write real software requirements.** "Motor off on fault" is not a requirement. "The firmware shall deassert the motor enable line within 50 ms of detecting the step count exceeding the configured session maximum, with the measurement defined as the interval from the interrupt service entry to the GPIO toggle" is a requirement. The difference is whether the requirement is testable.

**Treat real-time constraints as first-class requirements.** Response times, interrupt latencies, watchdog intervals, maximum cycle times. These are design inputs under EN ISO 13485 clause 7.3.3. They drive architecture choices (OS vs bare metal, interrupt priority scheme, scheduler design) and they must be verifiable in system testing.

**Version control and build reproducibility.** The firmware image used in verification must be reproducible byte-for-byte from the source. Commit hashes, toolchain versions, build flags, and signing keys all go into controlled records. A verification result tied to a firmware image nobody can rebuild is not an acceptable verification result.

**Manage SOUP deliberately.** Any third-party library (an RTOS, a Bluetooth stack, a cryptographic library) is SOUP under EN 62304 clause 5.3.3. It requires documented system and hardware requirements, evaluation of known anomalies, and a risk analysis of its use. This includes vendor-provided HAL code from chip manufacturers.

**Plan joint hardware-firmware verification.** At the PEMS boundary (EN 60601-1 clause 14), hazards are controlled jointly. The test plan must exercise the integrated system with faults injected at the boundary. Schedule this as a joint activity, not as a hardware test with firmware present or vice versa.

**Keep the firmware file in the design history file.** The software plan, software requirements, architecture, detailed design where applicable, unit test reports, integration test reports, system test reports, SOUP evaluations, and the traceability matrix all belong in the QMS. Not in the git repo readme. Not on a wiki. In controlled documents linked to the DHF.

## Reality Check

1. Have you assigned an EN 62304 software safety class to your firmware, and is the decision justified in the risk file?
2. Do your software requirements specify real-time behaviour in numbers that can be measured in verification?
3. Is there a hardware abstraction layer clear enough that application-level unit tests can run without the target board?
4. For every hazard controlled jointly by hardware and firmware, do you have a documented PEMS-level test under EN 60601-1 clause 14?
5. Can you rebuild the exact firmware binary used for verification from source control, toolchain, and build scripts alone?
6. Are all third-party libraries documented as SOUP with requirements, known anomaly evaluations, and risk analysis?
7. Is your firmware change control tied to the QMS such that a merged pull request triggers a change record?
8. If a notified body asked for the full traceability from hazard to requirement to unit test to integration test to system test, could you produce it?

## Frequently Asked Questions

**My firmware is 8 kB of C on a Cortex-M0. Do I really need EN 62304?**
Yes. EN 62304 scope is medical device software regardless of size or platform. The activities scale with safety class, not lines of code.

**Can a bootloader be a separate software item with its own class?**
Yes. EN 62304 allows segregation of software items with different safety classes if the segregation is documented and verified. A bootloader with no safety-relevant behaviour can be Class A while the application is Class B.

**Do I need a real-time operating system?**
No. Bare metal is fine if the real-time requirements are met and verified. An RTOS brings SOUP obligations. Choose based on architectural needs, not regulatory preference.

**Who owns PEMS verification, hardware or firmware?**
Both. PEMS under EN 60601-1 clause 14 is a joint concern. The design history file should show both hardware and firmware leads signing off on the PEMS risk controls and verification.

**Can I use Yocto, FreeRTOS, or a vendor HAL under EN 62304?**
Yes, as SOUP. Document the selection rationale, evaluate known anomalies from the vendor's issue tracker, and include the SOUP risk analysis in the file.

**Does firmware need its own design review gates?**
Yes. EN ISO 13485 clause 7.3.5 requires design reviews. For firmware, that typically means architecture review, pre-release review, and release review at minimum, with documented participants and outcomes.

## Related reading
- [MDR Software Lifecycle under IEC 62304](/blog/mdr-software-lifecycle-iec-62304) — the full lifecycle overview
- [Software Safety Classification under IEC 62304](/blog/software-safety-classification-iec-62304) — how Class A, B, and C are assigned
- [Software Architecture Documentation under IEC 62304](/blog/software-architecture-documentation-iec-62304) — what the architecture document must contain
- [MDR PEMS under IEC 60601-1](/blog/mdr-pems-iec-60601-1) — the programmable electrical medical system view
- [SOUP and OTS Software under MDR](/blog/soup-ots-software-mdr) — handling third-party code

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.1, §17.2.
2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clauses 4.3, 5.1–5.8, 5.3.3.
3. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment. Clause 14 (PEMS).
4. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.
5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems. Clause 7.3.

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*