Firmware is the embedded software that runs a device at a low level and controls how it behaves. In IoT environments, outdated firmware is a major risk because vulnerabilities can persist for long periods, giving attackers an easy path to compromise devices that are rarely patched like standard endpoints.
Expanded Definition
Firmware sits below the operating system and above hardware control logic. It can include boot code, device initialisation routines, power management, sensor handling, radio configuration, and hardware-specific security checks. In practice, firmware is what lets a device start, identify its components, and enforce basic behaviour before higher-level software takes over.
The boundary that matters is simple: firmware is not the same as an application, driver, or full operating system, even though all three may interact closely. Guidance-vs-consensus note: some organisations use “embedded software” broadly, but security teams usually treat firmware as a distinct lifecycle asset because its update path, trust chain, and recovery options are different from standard software.
This distinction becomes important when a device supports secure boot, signed updates, or hardware root-of-trust features. If those controls are absent or poorly implemented, the device may run untrusted code for its entire lifecycle. For embedded and IoT environments, that is often the practical difference between manageable maintenance and a persistent exposure.
Examples and Use Cases
Firmware appears anywhere a device needs low-level control before a full computing stack is available. A few common examples are:
- Router and firewall firmware that controls boot behaviour, interface handling, and management access.
- IoT sensor firmware that manages telemetry collection, wireless communication, and battery use.
- Industrial controller firmware that mediates timing, actuation, and safety-related device behaviour.
- Server platform firmware such as UEFI or related subsystem code that participates in startup and trust validation.
In operational settings, firmware updates are often slower and more cautious than application patching because a failed update can brick a device or interrupt a physical process. That trade-off means maintenance teams usually need stronger change control, maintenance windows, and verification steps than they would for ordinary software.
Firmware also shows up in supply chain and procurement decisions. If a device vendor cannot explain update support, signing practices, or end-of-life timelines, the device may create a long-lived blind spot even when the rest of the environment is well managed.
Security Implications
When firmware is outdated or poorly protected, vulnerabilities can remain reachable long after the rest of the environment has been patched. That matters because firmware often sits in devices that are difficult to monitor, rarely reimaged, and sometimes deployed in large numbers across homes, offices, plants, and branches.
Common failure conditions include unsigned or weakly signed updates, insecure default settings in device management interfaces, and poor validation of what runs during boot. If an attacker gains firmware-level persistence, removal becomes harder than cleaning up a normal endpoint compromise because the malicious code may survive reinstalls or operating system refreshes.
Practical symptoms often include unexplained device instability, unexpected configuration drift, remote management anomalies, or a mismatch between the device’s published version and its actual behaviour. In blended environments, firmware weaknesses can also expand blast radius by giving attackers a trusted foothold on appliances that sit between users, workloads, and critical services.
Domain and Governance Relevance
Firmware is a governance issue because ownership is often split between operations, IT, procurement, and the vendor. If no one tracks firmware versions, support status, and update responsibility, the organisation can end up with devices that are technically working but no longer defensible.
In identity-rich environments, firmware affects the trust boundary beneath system identity and access control. A compromised device platform can undermine higher-level assurance even when accounts, roles, and secrets are well managed. That is why firmware lifecycle control matters for network appliances, authenticators, badges, controllers, and other components that participate in access decisions or machine-to-machine trust.
For NHI and machine identity environments, firmware is especially relevant where the device itself anchors cryptographic trust, holds keys, or validates certificates. A weak or unmaintained firmware base can undercut the integrity of non-human identity dependencies even if the credentials themselves are correctly issued and rotated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Firmware is part of device software baselines and secure configuration scope. |
| 12 — Network Infrastructure Management | Network and security appliances rely on firmware for resilient management and update paths. | |
| Recommendation — Enforce firmware baselines and block unsupported versions from remaining in service. Track appliance firmware support status and apply updates before exposure grows. | ||
| NIST CSF 2.0 | PR.IP-3 — Configuration Change Control Processes | Firmware updates are a high-impact change control activity with device-level risk. |
| DE.CM-8 — Vulnerability Scans Are Performed | Firmware exposure depends on knowing which devices are outdated or unpatchable. | |
| RC.RP-1 — Recovery Plan Is Executed During or After a Cybersecurity Incident | Firmware failure can require device recovery, rollback, or replacement planning. | |
| Recommendation — Treat firmware changes as controlled releases and verify device state after deployment. Include firmware versions in asset and vulnerability monitoring to spot stale devices. Prepare rollback and recovery procedures for failed or compromised firmware updates. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Firmware underpins devices that store or validate machine identity and secrets. |
| Recommendation — Inventory firmware-bearing devices and assign clear ownership for their trust dependencies. | ||
