Firmware sits closest to the device and the patient
It reads the sensor, drives the pump, controls the display, and in an implantable device it does all of that for years without a service visit. It has to be correct, and it has to stay correct through updates, power events, and hardware variation across a production run.
The standards that apply
IEC 62304 defines the software lifecycle for medical device software and sorts it into safety classes. The class determines how much documentation, testing, and traceability is expected at every stage.
Software that cannot contribute to a hazard.
Software that can contribute to a non serious injury.
Software that can contribute to death or serious injury.
Firmware on a therapeutic or implantable device is frequently Class C. ISO 14971 covers risk management for the device as a whole, and the firmware's hazards feed into it.
What makes firmware hard here
Real time constraints
A drug delivery device or a sterilizer has timing requirements that are not negotiable. The firmware architecture — bare metal, a real time operating system, or embedded Linux — is chosen to guarantee them, and the choice has to be justified.
Safety mechanisms
Watchdog timers, redundant checks on critical values, defined safe states on fault, and fault logging are expected, not optional. A device that fails has to fail in a known direction.
Power and longevity
Wearables and implantables run on batteries that cannot be swapped casually. Low power design, from sleep states to sensor duty cycling, is a core firmware concern.
Secure update
Devices in the field need firmware updates, and every update is a risk. Secure boot, signed images, and safe update pipelines that can roll back on failure are the standard engineering pattern, and regulators now expect them.
Cybersecurity
FDA's premarket expectations for connected devices include threat modeling, a software bill of materials, and a plan for handling vulnerabilities after release. Firmware is where most of that has to be implemented.
Verification
Firmware verification on a medical device is systematic. Unit tests, integration tests, hardware in the loop testing against the real device, and regression suites that run on every change, with every test traced back to a requirement.
At production scale that means automated test infrastructure and, often, device farms running the same test cycles across many units.
SequoiaAT engineers device firmware under design controls and DFMEA sized to device class.