What is firmware?
Firmware is the embedded software stored in a device’s non-volatile memory that controls the basic functions of its hardware, such as booting, communication and the processing of inputs and outputs. Firmware sits between the hardware and the application: in a PLC it is effectively the operating system on which the user program runs. In OT environments, firmware governs the behaviour of PLCs, sensors, HMIs, drives, switches and communication modules. Because firmware works out of the user’s sight, it is both a silent source of vulnerabilities and an attractive target for attackers.
🧠 Where does firmware live in an OT installation?
Almost every device with a microcontroller has firmware, usually stored in flash memory or EEPROM. That memory retains its contents without power but can be rewritten (“flashed”). Firmware is therefore not permanent: that makes updates possible, but also tampering.
| Device | Firmware determines, among other things | Typical update method |
|---|---|---|
| PLC / Safety PLC | Cycle behaviour, logic execution, communication stacks, access protection | Engineering software, SD card or the CPU’s web server |
| Variable Frequency Drive / drives | Motor control, motion profiles, protections and fail-safes | Vendor software via USB or fieldbus |
| Industrial switch | VLANs, redundancy protocols, routing (on layer 3 switches), management interfaces | Web interface, TFTP or a management platform |
| Field devices and sensors | Measuring ranges, diagnostics, protocols such as HART or PROFINET | Device management tool, often only on site |
| HMI and panel PCs | Interface behaviour, scripting, security settings | Project download, USB or network |
| RTU, IED and gateways | Telecontrol protocols, time synchronisation | Vendor tool or remote management |
An important distinction: the firmware comes from the vendor, the user program (for example ladder logic) from the engineer. Both need protecting, but they are managed separately and each has its own version number.
🎯 Why is firmware an OT security risk?
Firmware contains security- and performance-critical logic that the user cannot see and that is rarely updated. This creates typical risks:
| Risk | Example in an OT context |
|---|---|
| Outdated firmware | A known CVE or zero-day in a communication stack stays open for years |
| Uncontrolled updates | A technician flashes the wrong version and the controller no longer starts |
| Tampered firmware | An attacker loads their own image that looks normal but contains a backdoor |
| No authentication | Firmware can be overwritten without Secure Boot or Code Signing |
| End of support | The vendor no longer supplies patches for legacy systems |
Firmware attacks are also persistent: they often survive a restart and a reinstallation of the user program, and network or endpoint security barely sees them.
⚠️ Which attacks on firmware are known?
- Stuxnet (discovered in 2010) - modified the user program of Siemens S7-315 and S7-417 PLCs and hid those changes with a rootkit in the Step 7 software. Strictly speaking, Stuxnet therefore did not touch the firmware, but it showed how invisible malicious code on a controller can be.
- Ukraine, December 2015 - attackers uploaded malicious firmware to Moxa and IRZ serial-to-Ethernet converters in substations. The devices became unusable, cutting communication between the control centre and the substations and forcing field crews to operate breakers manually on site.
- TRITON (2017) - targeted Schneider Electric Triconex safety controllers at a petrochemical plant. Using a zero-day in the firmware (versions 10.0 to 10.4 of the MP3008 main processor module), the attackers placed a remote access trojan in firmware memory. Because a SIS is rarely restarted, that code was effectively persistent.
- S7-1500 boot vulnerability (2023) - researchers showed that more than a hundred models of the Siemens S7-1500 lacked a hardware root of trust with asymmetric signature verification at boot. With physical access, modified firmware could be loaded; a firmware update cannot fix this hardware flaw.
🔐 How do firmware signing and secure boot protect devices?
Two techniques together form a chain of trust:
- Firmware Signing - the vendor signs every firmware image with a private key. Before installation, the device uses the public key to check that the image really comes from the vendor and has not been altered.
- Secure Boot - at every start-up, an immutable root of trust, often in ROM or in a TPM or secure element, verifies the signature of the bootloader and firmware. A tampered image then does not boot.
A checksum or hash on its own proves integrity, not origin: an attacker can simply supply a new hash. Encrypting firmware does not guarantee authenticity either. Only a digital signature, verified by the device itself, truly rules out tampered images.
The IEC 62443-4-2 standard sets this out for components: requirement CR 3.4 calls for software and information integrity, EDR 3.10 for support for updates (with requirement enhancement RE(1) adding that the device verifies the authenticity and integrity of each update), and EDR 3.14 for integrity of the boot process. NIST SP 800-193 (2018) adds the principle of protect, detect and recover.
🔧 How do you set up firmware management?
A practical approach in seven steps:
- Inventory - record type, firmware version and support status per asset in the asset inventory. Passive network monitoring can often read versions automatically.
- Follow advisories - subscribe to vendor advisories and to the ICS advisories from CISA and the NCSC. Siemens, for example, publishes monthly on the second Tuesday, and many vendors provide machine-readable CSAF files.
- Assess - weigh each vulnerability in vulnerability management against reachability, process impact and compensating controls.
- Verify - download only via official channels and check the signature or published hash before use.
- Test - install first on a test rig or spare unit, following the OTAP principle (development, test, acceptance, production).
- Plan and install - carry out the update under change management and patch management, during a maintenance shutdown, with a backup of configuration and user program and a fallback plan.
- Check and log - verify the new version, record the change and forward firmware events to the SIEM or SOC.
In the process industry, firmware updates are often bundled into planned shutdowns that may be years apart. Compensating controls such as network segmentation, USB control and the CPU’s key switch or protection mode bridge that gap.
🧱 Which EU rules apply to firmware updates?
The Cyber Resilience Act (Regulation (EU) 2024/2847) makes secure firmware updates a legal obligation for manufacturers of products with digital elements, including PLCs, switches and sensors.
| Obligation | Content | From |
|---|---|---|
| Entry into force | Regulation in force | 10 December 2024 |
| Reporting obligation | Actively exploited vulnerabilities: early warning within 24 hours, notification within 72 hours, final report within 14 days of a fix being available | 11 September 2026 |
| Support period | At least five years, unless the product is expected to be in use for less | 11 December 2027 |
| Availability of updates | Each security update available for at least ten years, or the remainder of the support period if longer | 11 December 2027 |
| Free, secure updates | Security updates free of charge, separate from functionality updates where feasible, and securely distributed | 11 December 2027 |
| SBOM | Machine-readable software bill of materials covering at least the top-level dependencies | 11 December 2027 |
For OT operators, NIS2 also applies; in the Netherlands it is implemented by the Cyberbeveiligingswet (Cbw), which entered into force on 15 August 2026. It requires, among other things, supply chain security and vulnerability handling, which directly covers firmware. Vendors can have their development process, including security update management, assessed against IEC 62443-4-1.
✅ Which best practices apply to firmware in OT?
| Measure | Why |
|---|---|
| Accept only signed firmware | Prevents tampered images, including via USB, SD card or Ethernet |
| Use the CPU’s protection mode or key switch | Blocks unauthorised downloads during operation |
| Compare firmware versions periodically against an approved baseline | Detects unplanned changes (configuration management) |
| Require an SBOM and advisories at procurement | Makes supply chain risks and vulnerable components visible |
| Keep known-good images and backups | Fast recovery after a failed update or an attack |
| Include firmware in threat intelligence | Recognise new attack techniques in time |
In addition, record version numbers, vulnerabilities and update history per device, and include authentication on management interfaces in the hardening baseline.
❓ Frequently asked questions
What is the difference between firmware and software?
Firmware is software tied to a specific device that controls the hardware directly, whereas ordinary software runs on a general-purpose operating system. Firmware is stored in non-volatile memory such as flash and is updated less often. In a PLC, the user program runs on top of the vendor’s firmware.
How often should you update PLC firmware?
In OT, PLC firmware is usually not updated as soon as a release appears, but after a risk assessment and during a planned maintenance shutdown. Critical vulnerabilities that are reachable from the network take priority; for the rest, compensating controls often suffice until the next shutdown. What matters is that every firmware version is known and actively assessed.
Can malware hide in firmware?
Malware can hide in firmware, as TRITON demonstrated in 2017 on Triconex safety controllers. Firmware malware is hard to detect because antivirus software and network monitoring cannot see the contents of device memory. Secure boot, signed firmware and periodic integrity checks reduce that risk.
What is firmware signing?
Firmware signing is the vendor’s digital signing of a firmware image, so that a device can check before installation that the firmware is genuine and unaltered. Unsigned or modified images are rejected. Both IEC 62443-4-2 and the Cyber Resilience Act call for this check.
What does the Cyber Resilience Act require for firmware?
From 11 December 2027, the Cyber Resilience Act requires manufacturers to provide free security updates for at least five years and to maintain an SBOM. Actively exploited vulnerabilities must already be reported within 24 hours from 11 September 2026. For OT operators this means better updates, but installing them remains their own responsibility.
How do you check that firmware has not been tampered with?
You check firmware integrity by comparing the installed version and, where the device supports it, the hash or signature with the vendor’s official values. Many OT monitoring platforms flag unexpected firmware changes automatically. If in doubt, forensic analysis or reinstallation from a trusted image helps.
📌 In summary
Firmware is the invisible foundation of industrial automation: if you do not inventory, verify and update firmware in a controlled way, you leave one of the most persistent attack paths in OT open. Signed firmware, secure boot, an up-to-date inventory and a tested update process together form the basis, and the Cyber Resilience Act makes secure updates an obligation for vendors from 2027. In this way firmware management contributes directly to safety, availability and compliance.