Industrial IoT cybersecurity: making a deployed fleet CRA-ready

An industrial sensor is rarely secured once: by the time anyone finds what it lacks, it is already in the field, on battery, behind gateways nobody really controls. Industrial IoT cybersecurity then means hardening an existing fleet without recalling it: authenticate every message, protect the keys, sign the updates, then prove all of it under the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847.

At AESTECHNO, an electronics design house in Montpellier, France, we design the hardware and firmware of these sensors and keep their security register. This guide comes from that work: what an OTA update can fix, what needs physical access, and what should have been decided before the first unit shipped. For the full regulatory picture, see our Cyber Resilience Act compliance guide.

Contents

• What does industrial IoT cybersecurity cover for a fleet?
• What does the CRA already require of a fleet in service?
• Threat model: the gateway is an adversary
• How do you authenticate every message without encrypting the radio link?
• Keys, secure element and debug port
• Signed OTA and anti-rollback: decide before the first unit
• Hardening a deployed fleet in stages
• SBOM, CVEs and the security register
• Field report: a fleet of battery-powered BLE sensors
• Checklist: making an existing fleet CRA-ready
• Bottom line

What does industrial IoT cybersecurity cover for a fleet?

Industrial IoT cybersecurity for a fleet is the set of measures that ensure a deployed sensor sends authentic data, runs only signed firmware, keeps its keys out of reach and can be patched remotely, for its whole service life and not just on the day it is placed on the market.

The difference from securing a new product comes down to one word: legacy. A product still in design can switch microcontroller, add a secure element or rework its bootloader. A fleet in service can only change what its current firmware and bootloader allow it to change remotely. Everything else requires physical access to each unit.

That is why we always start with the same question: of the defects found, which ones an OTA update can fix, which ones need a site visit, and which ones stay accepted until the next hardware generation? For a product still on the drawing board, our guide to securing an IoT product from design to deployment covers the other side.

What does the CRA already require of a fleet in service?

The Cyber Resilience Act requires manufacturers of products with digital elements to meet security requirements across the whole life cycle. Its Article 14, the duty to report actively exploited vulnerabilities and severe incidents, has applied since 11 September 2026, including to products placed on the market before that date.

The reporting clock is tight: an early warning within 24 hours, a notification within 72 hours, then a final report, through the single reporting platform run by ENISA. For a fleet already sold, that means knowing which firmware runs in the field, which software components it contains, and how to push a fix.

The Annex I essential requirements apply from 11 December 2027 to products placed on the market after that date, or substantially modified. A security update on its own is not a substantial modification. Fines reach up to EUR 15 million or 2.5% of worldwide turnover. For a radio sensor, CE/RED certification and EN 18031 have applied on top since August 2025.

Threat model: the gateway is an adversary

A threat model describes who can attack the system, from where, and with what means. For a fleet of industrial sensors, the realistic starting point is simple: the gateway, the maintenance smartphone and the network are untrusted intermediaries, able to read, delay, replay or modify every message.

That assumption changes the architecture. If the sensor reports through third-party gateways shared between several organisations, encrypting the radio link protects nothing: the presumed attacker is precisely the peer of that link. Contrary to a common belief, Bluetooth Low Energy (BLE) pairing in Just Works mode authenticates nobody, and the modes that do authenticate need a passkey or an out-of-band channel that a screenless sensor does not have.

Protection therefore has to live above the link, end to end between sensor and server. Figure 1 sums up the four families of vectors we handle: network, local access, supply chain and side channels.

A second question often settles the debate: is confidentiality actually required? A temperature, a vibration level or a tank level is not always secret. A forged reading, however, can trigger an alarm, stop a line or hide a drift. In our practice the real requirement often boils down to three properties: authenticity, integrity and freshness. Writing them down explicitly avoids designing a full encryption protocol where a message signature is enough.

How do you authenticate every message without encrypting the radio link?

Message authentication guarantees that a reading really comes from the sensor it claims and was not altered on the way. It is achieved by appending to each frame a code computed with a secret key unique to the sensor, an HMAC, that only the server can verify.

On a recent project we chose a two-step design. First, a session established with an Ed25519 signature: the sensor proves its identity with a private key that never leaves the chip. Then every message carries an HMAC truncated to a few bytes, because the payload of a radio frame is tight. A monotonic counter, saved in non-volatile memory, is part of every computation: a replayed message carries a counter already seen and is rejected.

Why this is not a zero-knowledge proof

This is not a zero-knowledge proof (ZKP), even though the sensor proves it holds a key without revealing it. A ZKP is a distinct and heavier cryptographic construction, rarely justified on a battery-powered sensor. A session signature plus a per-message HMAC meets the need with proven primitives that are well supported on MCUs.

The delicate part is the counter. If its storage area becomes unreadable while the key survives, a naive firmware restarts at zero with the same key, and every previously captured message becomes replayable again. We recommend that this case fail closed: the sensor refuses commands, reports it to the server, and the only way out is re-provisioning with a new key. On that project we reproduced the defect in a radio simulation before it reached the bench, then verified the fix in the same test matrix.

Keys, secure element and debug port

A secure element is a dedicated chip that stores private keys in memory protected against direct readout and physical attacks. Recent microcontrollers also offer built-in, non-exportable key storage that provides a comparable service without an extra component.

Either way the principle is the same: the private key is generated or injected at the factory, signs in place, and only the public key ever leaves. Common parts are the Microchip ATECC608B, NXP SE050, Infineon OPTIGA Trust M and ST STSAFE-A110; the right choice depends on the software stack and on what the MCU already does. Unlike keys stored in internal flash, a firmware extraction then no longer compromises the whole fleet.

The debug port remains the most frequent hole. During a hardware audit we found an industrial product shipped in volume with its JTAG port active and unlocked: flash readout with an off-the-shelf debugger, full extraction of the firmware and the TLS keys. Unlike a server, that defect cannot be fixed by a remote patch on units already delivered. We recommend locking the Joint Test Action Group (JTAG) and Serial Wire Debug (SWD) ports at end of line, and documenting how a returned sensor is unlocked, erased and re-provisioned at the workshop.

Key storage is also a process question. The factory provisioning order (identity key, message key, initial counter) must be tested like a product feature, with a simple fleet check: every sensor must report that it holds its keys. Our prototype-to-series industrialization process builds this check into the production test bench.

Signed OTA and anti-rollback: decide before the first unit

A signed OTA update is firmware that the bootloader accepts only after verifying its signature against a public key stored in the sensor. MCUboot, the bootloader of the Zephyr Project, handles that verification, the slot swap and the post-boot confirmation natively.

A signature is not enough. Without downgrade protection, an attacker can reinstall an older, correctly signed version that contains a known vulnerability. MCUboot offers a security counter attached to each image: the bootloader rejects any image whose counter is lower than the one already installed.

The catch is that this setting lives in the bootloader, and on many products the bootloader cannot be updated over the air. Units flashed before anti-rollback was enabled then stay unprotected until their next workshop visit. The same goes for write-protecting the bootloader: if the application can rewrite the bootloader area, compromised firmware can make itself permanent. These decisions belong before the first unit ships, not after.

The rest of the chain is well known: signature on the build server, authenticated transport, write to the inactive slot, atomic swap and watchdog confirmation. Our Zephyr, FreeRTOS or real-time Linux comparison covers the stacks that support it, and our article on the CRA for embedded Linux handles Linux gateways.

Hardening a deployed fleet in stages

Hardening a fleet in stages means deploying security controls in observation mode first, then making them blocking once the whole fleet is ready. It prevents a rule switched on too early from cutting off badly provisioned sensors or maintenance tools that have not been updated yet.

On an existing fleet, an unsigned command is therefore not refused on day one: it is accepted and counted. The server sees which sensors, gateways and tools still send unauthenticated traffic. Once that count drops to zero and every sensor reports its keys, the fleet is armed and refusal becomes the rule. Despite the temptation to move fast, we recommend treating this arming step as a project milestone with its own exit criteria.

The table below works as a decision matrix: for each defect, it states the fix and what that fix costs on a fleet in service.

This matrix is why we prefer an imperfect but measured fleet to one that is merely assumed secure. A defect that is accepted, written down, with its reason and review date, is a managed defect. The same defect ignored becomes a vulnerability to report within 24 hours on the day someone exploits it.

SBOM, CVEs and the security register

A Software Bill of Materials (SBOM) is the inventory of the software components inside a firmware image: RTOS, libraries, network stacks and their versions. The CRA makes it the basis of vulnerability handling, because nobody can report or fix a flaw in a component they do not know is there.

In our practice the SBOM is not an end-of-project deliverable. It is generated on every build in SPDX format, fed to a vulnerability scanner such as Grype, and the pipeline fails on any high-severity finding. A scheduled scan also runs with no commit at all, because new CVEs appear against code that has not changed. The SBOMs are archived per release, so the question "which units carry this library?" has an answer.

Filtering and prioritising vulnerabilities

The second filter is often forgotten: matching the RTOS security advisories against what is actually compiled into the image. A flaw in a driver absent from the binary does not carry the same priority as a flaw in the radio stack in use. We add static analysis (cppcheck in continuous integration) and, for embedded CI/CD pipelines, one simple rule: deployment only happens if the full test suite passes.

As Thierry Durand, embedded cybersecurity expert at Embedded Expertise, points out, a CVE scan (Grype, Trivy) is only the first step: the real work is piloting remediation, meaning triage, prioritisation by operational context, tracking of fix status and a justification for every exclusion. In his experience an embedded project can surface more than 3000 CVEs from an SBOM scan; without prioritisation the report is unusable.

The security register

Hence the security register: one line per defect, with its severity, status and decision. On our latest fleet project, the register holds more lines on the server and MQTT broker side than on the firmware side. Fleet security does not stop at the sensor.

Field report: a fleet of battery-powered BLE sensors

A field report sums up what a real project taught us that the documentation did not say. This one covers a fleet of battery-powered BLE sensors whose readings travel through third-party gateways and phones to a server, with MCUboot-signed OTA updates.

On that recent project our methodology followed three steps. First, a written threat model that puts the attacker at the gateway and drops confidentiality from the requirements: that choice avoided a full encryption protocol and kept the effort on authentication. Second, a radio simulation of the fleet that replays failure scenarios (reboot, OTA, corrupted memory) before the bench. Third, a security register reviewed at every release, covering firmware, bench tools, broker and server alike.

What we observed

Contrary to the common assumption that cryptography is the hard part, we observed that the serious defects sat at the boundaries: a counter that did not survive memory corruption, a bootloader setting impossible to fix remotely, a bench tool that disabled broker TLS verification by default. None of them came from a bad algorithm.

Despite the pressure to switch every control on at once, we recommend the staged arming described above, plus an end-of-line rule: no unit leaves without provisioned keys, a locked debug port and active anti-rollback. Whatever the fleet cannot fix by itself must be settled before it leaves the workshop.

Checklist: making an existing fleet CRA-ready

A fleet compliance checklist gathers the checks that let you answer the three CRA questions on the day of an incident: which products are affected, what software they contain, and how to fix them. It runs in order, from inventory to arming, and each step depends on the one before it.

Each step produces evidence you can reuse in the CRA technical file: a dated inventory, a signed-off threat model, SBOMs archived per release, scan reports, a register of decisions. Unlike a one-off certification, that evidence updates with every firmware release. We recommend producing it from the pipeline rather than by hand, so it is still true on the day an incident forces a 24-hour report.

• Inventory the fleet: firmware and bootloader version of every sensor, reported automatically.
• Write the threat model: who is untrusted (gateway, phone, network), and which properties are required.
• Generate an SBOM on every build and schedule a vulnerability scan even without new commits.
• Authenticate every message end to end, with a persistent counter that fails closed.
• Check the OTA chain: signature, anti-rollback, bootloader write protection.
• Lock JTAG/SWD on every unit leaving production.
• Arm in stages: observe unsigned traffic, then refuse it once it drops to zero.
• Keep a security register and a 24-hour reporting procedure.

The detailed, printable version is our Cyber Resilience Act checklist. For a radio product, add the CE/RED certification checklist, and for the battery life of these sensors, our guide to embedded power management.

Bottom line

Industrial IoT cybersecurity for a deployed fleet does not hinge on choosing an algorithm, but on what the fleet can fix by itself. A sensor in the field can only change what its current firmware and bootloader allow; everything else costs a workshop visit. The CRA adds a concrete deadline: knowing, at any time, what software runs on each unit and how to fix it. In our practice a fleet is secured through written decisions and measured stages, not through a list of technologies. Every decision has an owner, a date and evidence.

Five takeaways, from the regulation down to the build pipeline, for a fleet already in the field:

• The CRA already applies: 24-hour reporting since 11 September 2026, products already sold included.
• The gateway is an adversary: authenticate end to end, not on the radio link.
• The counter matters as much as the key: a lost counter must fail closed.
• Decide the bootloader before the first unit: anti-rollback and write protection cannot always be retrofitted.
• SBOM, scheduled scans and a register turn a list of CVEs into tracked decisions.

IEC 62443-4-2, ETSI EN 303 645 and the OWASP IoT Top 10 provide the method; the work is wiring it into the product and the pipeline.

Related articles

• Cyber Resilience Act: IoT compliance guide, the regulatory framework, timeline and product classification.
• Securing an IoT product from design to deployment, the new-product side of this guide.
• CRA and embedded Linux, for Linux gateways and products.
• LoRaWAN, NB-IoT, Sigfox compared, choosing the radio for a sensor fleet.
• Predictive maintenance IoT, the industrial use of these sensors.

FAQ: industrial IoT cybersecurity

Does the CRA apply to sensors already sold?
Yes, for reporting. Article 14 of the Cyber Resilience Act, which requires reporting actively exploited vulnerabilities and severe incidents, has applied since 11 September 2026 to all products in scope, including those placed on the market before that date. The Annex I essential requirements only apply to products placed on the market from 11 December 2027, or substantially modified. A plain security update is not a substantial modification.

Should an industrial sensor's Bluetooth link be encrypted?
Not necessarily. If readings travel through third-party gateways or phones, the presumed attacker is the peer of the radio link, and link encryption does not protect against it. Just Works pairing authenticates nobody. It is better to authenticate every message end to end, between sensor and server, with an HMAC and a counter. Encryption remains useful if the data itself is confidential, which the threat model should decide explicitly.

Is a truncated HMAC secure enough?
Yes, provided the truncation is sized to the threat and paired with a counter. An HMAC truncated to a few bytes leaves only a tiny chance of guessing a valid code for a given message, and the server can limit attempts per sensor. The monotonic counter included in the computation prevents replaying a message already seen. Truncation is a standard trade-off when the payload of a radio frame is tight.

Can anti-rollback be added with an OTA update?
It depends on the bootloader. With MCUboot, protection against downgrading to an older version relies on a security counter checked by the bootloader itself. If the bootloader cannot be updated remotely, sensors flashed before that option was enabled stay unprotected until their next workshop visit. That is why we recommend deciding on anti-rollback and bootloader write protection before the first unit ships.

Secure element or the microcontroller's key storage?
Both protect the private key from direct readout. A secure element such as the ATECC608B, SE050 or OPTIGA Trust M adds a dedicated chip resistant to physical attacks, useful when the MCU has no protected storage. Recent microcontrollers include non-exportable key storage that is often enough. The deciding criterion stays the same: the private key must never leave the chip, and the debug port must be locked in production.

Where do you start securing an existing fleet?
Start with the inventory: which firmware and bootloader version runs on each sensor, and which software components each image contains, thanks to an SBOM. Then write the threat model, and sort every defect by whether it can be fixed over the air, at the workshop, or only at the next board revision. Finally, deploy controls in observation mode before making them blocking. Our Cyber Resilience Act checklist follows that order.