Firmware

Definition: Low-level software permanently or semi-permanently programmed onto a hardware device’s memory, controlling its most basic hardware-level functions.

How It Works

Sits between raw hardware and any higher-level software, directly controlling chips, sensors, and peripherals through their register-level interfaces
Stored in non-volatile memory (flash) so it persists without power, unlike RAM, which loses its contents the instant power is removed
Can often be updated (“flashed”) without replacing the physical hardware, which is how devices receive bug fixes and new features after manufacturing
A bootloader is itself a small piece of firmware that runs first at power-on, its job is to verify and load the main application firmware, and often to accept new firmware images during an update
On more capable devices, firmware may include a small RTOS or scheduler; on the simplest devices, firmware is just one continuously running program with no OS underneath it at all
Firmware version numbers are typically tracked in both the device itself (readable over a diagnostic interface) and a backend fleet-management system, so operators know exactly which devices in the field are running which version
Firmware updates are commonly delivered Over-The-Air (OTA), downloaded over Wi-Fi or cellular and written to flash without a physical connection to the device

Under the Hood

The “spare flash region” step is what makes safe OTA updates possible: writing the new firmware over the currently-running firmware in place would leave the device unbootable if power is lost mid-write.

Worked example 1: A/B partition update safety

Given: a device has 2MB of flash split into two 1MB partitions, A (currently running firmware v1.2) and B (currently empty)
Step: an OTA update downloads firmware v1.3 (900KB) and writes it entirely into partition B, while partition A keeps running v1.2 undisturbed throughout the download
Step: once v1.3’s checksum in partition B is verified, the bootloader’s “active partition” flag is flipped from A to B, and the device reboots into v1.3
Answer: if power is lost at any point during the download or verification, partition A still holds a complete, untouched, working v1.2, the device simply reboots back into the version it had before, this A/B scheme is exactly why a failed OTA update doesn’t have to mean a bricked device

Worked example 2: flash write endurance

Given: a flash memory chip rated for 100,000 erase/write cycles per sector, and a firmware design that writes a small logging counter to the same flash sector once every hour
Step: writes per day = 24; writes per year = 24 × 365 = 8,760
Step: years to exhaust the rated cycle limit = 100,000 / 8,760 ≈ 11.4 years
Answer: at this rate, the flash sector would wear out in about 11 years of continuous operation; in practice, engineers use wear-leveling (spreading writes across many sectors) or write less frequently to a dedicated log area to push that limit far beyond the device’s expected service life

Worked example 3: signature verification blocking a malicious update

Given: a device’s bootloader is configured to only accept firmware images signed with the vendor’s private key, verified against a public key baked into the bootloader itself
Step: an attacker crafts a modified firmware image and attempts to push it to the device via the same OTA channel
Step: the bootloader computes a cryptographic hash of the received image and checks it against the attached signature using the embedded public key; since the attacker doesn’t have the vendor’s private key, the signature check fails
Answer: the device rejects the image and either stays on its current firmware or refuses to boot the new one, this signature-checking step is what prevents OTA update mechanisms from becoming an open door for installing arbitrary malicious firmware

Firmware Update Delivery

Stage	What happens	Why it matters
Download	New image transferred over Wi-Fi, cellular, BLE, or a wired connection	Must tolerate interrupted or unreliable connections gracefully
Staging	Image written to a spare flash partition, not the active one	Keeps the currently running firmware untouched and bootable
Verification	Checksum and/or cryptographic signature validated	Rejects corrupted transfers and unauthorized/malicious images
Activation	Bootloader’s active-partition flag flipped, device reboots	The actual moment the new firmware takes over
Rollback	If the new firmware fails to boot or self-check, revert to the previous partition	Prevents a bad update from permanently bricking the device

Why It Matters

Firmware bugs are uniquely painful, they can be much harder to fix after a device has shipped to millions of units in the field than a typical application bug
A reliable OTA update mechanism is often the difference between a shippable product and a liability, security vulnerabilities discovered after launch need a real path to a fix
Firmware quality directly determines a device’s reliability and battery life, since it controls every low-level hardware interaction with no forgiving OS layer to catch mistakes
Regulatory and safety-critical devices (medical, automotive) often require firmware to go through formal certification, making a broken or insecure update mechanism a compliance problem, not just a technical one

Common Pitfalls

Shipping firmware without a reliable update mechanism, leaving no way to fix critical bugs or security issues after devices are already in the field
Underestimating how memory- and power-constrained firmware development is compared to typical application development, a technique that’s fine on a server can be entirely impractical on a device with 2KB of RAM
Writing directly over the only copy of running firmware during an update instead of using an A/B or staged approach, risking a bricked device if power is lost mid-flash
Not verifying a firmware image’s integrity (checksum or cryptographic signature) before accepting it, opening the device to corrupted or malicious firmware being installed
Ignoring flash wear limits when designing frequent write patterns (logging, configuration saves), leading to premature hardware failure well before the device’s intended lifespan
Not implementing a rollback path if the new firmware fails to boot or fails a self-check, turning a bad update into a permanent brick instead of a recoverable failure
Hardcoding secrets (Wi-Fi credentials, API keys, signing keys) directly in firmware without any protection, since firmware images can often be extracted and reverse-engineered from the device itself
Skipping real-world power-loss testing during development, a firmware update process that works perfectly in the lab can still fail in the field if power drops at an untested moment mid-write

Comparison

Update method	Risk if interrupted	Requires physical access	Typical use
Single-image overwrite	High, can brick the device	Sometimes	Very simple, low-risk devices
A/B partition (dual bank)	Low, always has a working fallback	No	Most modern consumer IoT devices
JTAG/SWD physical reflash	None to the device’s own logic, but requires hardware access	Yes	Development, recovery from a bricked device
OTA over Wi-Fi/cellular	Low with A/B, high without it	No	Connected consumer and industrial IoT devices
No update mechanism at all	N/A, no update path exists	N/A	Extremely simple or cost-constrained devices, accepted as a trade-off

Example

A smart lock’s firmware controls the actual motor that locks and unlocks the door, reading a wireless unlock command and driving the motor directly, updated periodically over the air to patch security vulnerabilities. ESP32-based IoT devices commonly use the ESP-IDF or Arduino framework’s built-in OTA update APIs, writing new firmware images to a spare flash partition exactly as described above, so a failed update never leaves the lock unable to boot at all. Home routers are another familiar example: their firmware update process (often user-initiated through a web interface) is the same underlying pattern, download, verify, stage, activate, reboot, just with a human clicking “Update” instead of an automated OTA trigger.

Common Interview Questions

What’s the difference between firmware and a typical application (like a mobile app)? — firmware runs closer to the hardware, often with no OS or a minimal one, direct register access, and far tighter memory/power constraints than typical application software
Why is a bootloader a separate piece of firmware from the main application? — it needs to remain valid and functional even if the main application firmware is corrupted or being updated, acting as a safety net that itself rarely if ever changes
Why use an A/B (dual-bank) update scheme instead of updating firmware in place? — it guarantees a complete, working firmware image always exists even if the update process is interrupted, preventing a bricked device
What’s flash wear, and why does it matter for firmware design? — flash memory has a limited number of erase/write cycles per sector before it becomes unreliable, firmware that writes frequently to the same location needs wear-leveling or reduced write frequency to avoid premature failure
How does OTA firmware update security typically work? — the device verifies a cryptographic signature on the new firmware image before accepting it, ensuring only firmware actually signed by the legitimate vendor can be installed
What’s the risk of hardcoding secrets directly in firmware? — firmware images can often be extracted and reverse-engineered from the physical device, so embedded secrets (Wi-Fi credentials, private keys) aren’t nearly as protected as secrets kept server-side
Why might a device deliberately ship without any OTA capability at all? — extreme cost or power constraints, or a design where the certification cost of ever changing the firmware outweighs the benefit of being able to patch it later

FAQ

Is firmware the same thing as an operating system? — not usually, firmware is closer to the hardware and can run with no OS at all, though some firmware does include a small embedded OS or RTOS as part of it
Can firmware be “erased” accidentally? — yes, an interrupted update, a power loss mid-write, or a bug that corrupts the wrong flash region can wipe or corrupt firmware, which is exactly why A/B partitioning and verified rollback exist
Why do some devices need a physical connection (JTAG/SWD) to recover from a bad update instead of OTA? — if the bootloader itself is corrupted or the device can’t reach the network, OTA has no path in, a physical debug interface is the last-resort recovery method
How is firmware different from “software” in general usage? — the distinction is really about how tightly coupled the code is to specific hardware and how permanently it’s stored, the line has blurred as devices get more capable, but firmware still implies closer-to-the-metal, flash-resident code
Do all embedded devices support OTA updates? — no, very simple or extremely cost-constrained devices sometimes ship without any update mechanism at all, accepting the risk that a bug found after shipping can’t be fixed remotely

History

Early consumer electronics firmware was typically stored in ROM (read-only memory) or one-time-programmable chips, meaning a firmware bug shipped in a product was permanent unless the customer physically replaced a chip. The shift to flash memory (rewritable in-circuit) made updatable firmware practical, and the later addition of wireless connectivity to embedded devices made OTA delivery practical, together turning “firmware bug” from a manufacturing-recall-level problem into something closer to a routine software patch.

Firmware vs Software Boundary

The line has blurred over time: modern high-end devices sometimes run Linux-based firmware that looks much closer to conventional software than the tightly hand-optimized firmware of a simple sensor node
Regardless of complexity, the defining trait stays the same: firmware controls hardware directly and is stored in the device’s own non-volatile memory, rather than being installed by a user the way a typical application is
Fleet management platforms for connected devices track firmware version, rollout status, and rollback history across potentially millions of deployed units, treating firmware updates as a continuous operational process rather than a one-time release

Referenced by

Dig deeper

Spot an error in this note?