Firmware is the low-level software stored in a medical device’s non-volatile memory that controls the hardware directly. It sits between the physical electronics and any higher-level application, driving sensors, motors, alarms, and safety logic. In regulated products, firmware counts as medical device software and falls under the same lifecycle and risk controls as any other code, including IEC 62304.
What is firmware?
Firmware is program code written to non-volatile memory such as flash, ROM, or EEPROM, where it persists when power is removed. It runs close to the hardware, often with no operating system or with a small real-time operating system (RTOS) beneath it. On a medical device, firmware is what reads a sensor, times a pump stroke, fires an alarm, or holds a heater at a set temperature.
Roughly, application software handles what the user sees while firmware handles what the hardware does, though the line is not always sharp. A pacemaker, an infusion pump, and a patient monitor all run firmware that often carries the most safety-critical functions on the device.
Why firmware matters in medical device development
A firmware fault can change therapy delivery, suppress an alarm, or corrupt a reading, so the patient-safety stakes are direct. The FDA and EU notified bodies expect firmware to be developed under a controlled software process, not waved through as part of the electronics.
The consequences are concrete. Recalls tied to software defects are common, often tracing back to weak requirements, thin testing, or uncontrolled changes. Missing firmware documentation is a frequent audit finding. A defect found late can stall a submission or force a redesign near launch, where schedule and budget damage concentrate.
How firmware fits the medical device software lifecycle
Under IEC 62304, firmware is medical device software, with a defined lifecycle and a safety classification. The standard assigns each software item to Class A, B, or C by the harm a failure could cause, and the required rigor scales with that class. Typical activities include:
- Software development planning, with the safety class set early
- Requirements traced to system and risk inputs.
- Architecture and detailed design
- Implementation and unit verification
- Integration and system testing against the requirements
- Release, maintenance, and change control after launch
Other standards apply alongside it. Risk management follows ISO 14971, and firmware-driven user interfaces fall under IEC 62366-1 usability engineering. Programmable electrical medical systems are covered by IEC 60601-1. The work sits inside an ISO 13485 quality system, now reflected in the FDA Quality Management System Regulation (21 CFR Part 820), effective February 2, 2026, which incorporates ISO 13485 by reference. In the EU, the EU MDR 2017/745 places software requirements in its general safety and performance requirements.
For cyber devices, section 524B of the US FD&C Act requires a software bill of materials (SBOM) and a postmarket vulnerability management plan, with IEC 81001-5-1 as the recognized security lifecycle standard. For firmware, that means signed and verified updates, secure boot where supported, and a maintained inventory of third-party and open-source components.
Common challenges and best practices
The most common mistake is treating firmware as hardware and skipping the software lifecycle. If a component can contribute to harm, it needs documentation and testing to meet its safety class demands.
Habits that separate clean shipping from rework:
- Write testable requirements first, and keep risk-to-requirement-to-test traceability current as code changes.
- Lock toolchain and compiler versions so builds are reproducible.
- Treat every field update as a change needing impact analysis and regression testing.
- Plan over-the-air or in-field updates early, including rollback and image verification.
- Keep an SBOM from the start rather than reconstructing it before submission.
How SJML helps with firmware
Syrma Johari MedTech designs and develops embedded systems and firmware as part of end-to-end electromechanical device engineering, spanning mechanical, electronics, software, and systems work. Firmware is built inside an ISO 13485 quality system, with risk management to ISO 14971 and usability engineering to IEC 62366-1 integrated into the process. SJML supports the IEC 62304 software lifecycle and IEC 81001-5-1 cybersecurity activities, with in-house labs for electrical safety, IEC 60601 testing, EMC, and reliability.
Talk to SJML’s engineering team →
Frequently asked questions
Yes. IEC 62304 treats firmware as medical device software, whether bare-metal or on a small RTOS. It receives a software safety class (A, B, or C) and follows the same lifecycle activities as any other code. Calling it firmware does not exempt it from the standard.
Firmware is software stored in non-volatile memory that controls hardware directly. Application software runs above it and handles workflows and the user interface. The difference is where the code sits and what it controls. Both are medical device software when they can affect safety.
For cyber devices, yes. Section 524B of the US FD&C Act requires an SBOM listing commercial, open-source, and off-the-shelf components and firmware counts. The SBOM supports vulnerability monitoring across the product life cycle. Maintaining it during development beats reconstructing it from binaries before a premarket submission.
A field firmware update is a controlled change. It needs impact analysis, risk review, regression testing, and documentation under the device’s change control process and ISO 13485 quality system. For cyber devices, updates also support postmarket cybersecurity obligations. Secure delivery, image verification, and rollback help avoid new hazards.
It depends on the harm a firmware failure could cause. IEC 62304 defines Class A (no injury possible), Class B (non-serious injury possible), and Class C (death or serious injury possible). Firmware controlling therapy or a critical alarm often lands in Class B or C, raising the rigor required.
Related terms
- IEC 62304
- Embedded Systems
- Software as a Medical Device (SaMD)
- Design Verification
- Medical Device Cybersecurity
