Summary: Enlit Europe closed in Vienna on 12 November. Before the show we sorted the exhibitor list by what each company builds: from 473 profiles, 153 were hardware makers. Most of what they make is not solar panels or batteries, but grid automation, meters, gateways and sensors: devices that sit in a basement, a substation or on an overhead line for years. Under the EU Cyber Resilience Act these devices share one show floor but take different paths. Here is what was on the floor, how the CRA treats each group, why a meter and a gateway have opposite update problems, and where we would start for each.
What was on the floor
We shortlisted the 153 hardware makers by their main product group. Many companies fit several groups, so the shares are rounded:
| Device group | Share | Typical connectivity | CRA category |
|---|---|---|---|
| Grid automation and protection | ~25% | Ethernet, IEC 61850 / 104, LTE | Default, unless the core function is routing or switching |
| Water, gas and heat meters | ~20% | wM-Bus, LoRaWAN, NB-IoT | Default |
| Electricity meters | ~20% | PLC, cellular, Ethernet (C&I) | Default |
| Gateways and comms modules | ~10% | LTE, Ethernet, meter radios | Important or critical |
| Energy management systems | ~10% | Wi-Fi, Modbus, cloud | Default |
| Line sensors (load and sag on overhead lines) | <5% | Cellular, low-power radio | Default |
The security rules are no longer in the future
For connected devices sold in the EU, three dates matter:
- Since 1 August 2025, wireless devices must meet the cybersecurity requirements of the Radio Equipment Directive (RED).
- Since 11 September 2026, the CRA requires an early warning within 24 hours of learning about an actively exploited vulnerability.
- From 11 December 2027, the full CRA applies, including a support period that the manufacturer states and has to keep.
A 24-hour warning only helps if the fix can follow. Nobody drives out to a basement or a substation to update each unit, so the fix travels over whatever link the device already has.
Same show floor, different CRA paths
The CRA category follows a product’s core function, not the booth it stands on. Routers, modems and switches are listed in Annex III as important products (Class I). Smart meter gateways are listed in Annex IV as critical. Most meters, sensors and energy management systems fall into the default category, and a grid automation device does too, unless its core function is routing or switching. Two companies in the same hall, both selling to utilities, can face very different conformity work.
What we saw on the floor matched that:
- Router and gateway makers looked the most prepared. Their products are network infrastructure, and patching is already part of the job.
- Meters and line sensors looked the least prepared. For years they were built with one firmware for their whole life. Now they need firmware updates over the air (FUOTA).
- FUOTA over a thin radio link isn’t trivial. It takes advanced connectivity expertise and deep firmware knowledge.
Meter and gateway: opposite update problems
A LoRaWAN meter and a Linux gateway in the same substation show how different the work is.
The meter’s problem is getting a few hundred KB through at all. Many LoRaWAN meters and sensors were built to be installed once and left alone on a battery. Now they need security updates for their whole support period, over a radio built for tiny messages:
- At the slowest data rates in the EU868 band, one packet carries at most 51 bytes, so a 200 KB image is roughly 4,000 packets.
- Most EU868 sub-bands allow transmitting only 1% of the time.
- Most battery LoRaWAN devices only listen for a moment right after they send, so updates need the LoRa Alliance FUOTA building blocks: clock sync, multicast sessions and fragments with redundancy.
- Every update spends battery that was budgeted for years of readings.
The gateway’s problem is how often it has to be patched. Bandwidth is fine over Ethernet or LTE, but:
- The image is tens or hundreds of MB: a kernel, a bootloader and hundreds of open-source packages.
- Each of those packages gets its own vulnerabilities, so the gateway needs security updates far more often than a meter.
- A failed update can cut off every device behind the gateway, so an A/B root file system with automatic rollback is a must.
Where we would start, group by group
- Grid automation and protection. Updates must fit the operator’s maintenance window. Start by checking each product’s core function against Annex III.
- Water, gas and heat meters. Every update eats battery. Start by checking that the radio, battery and flash can carry an update, and measure one full update in airtime and battery.
- Electricity meters. One bad release can reach every meter. Start with signed updates and rollback, then staged rollouts with an automatic stop.
- Gateways and comms modules. The CRA is stricter here (“important” or “critical”). Start with an SBOM per release, and contact a notified body early.
- Energy management systems. One weak cloud account can reach every inverter. Start by listing every account and key that can command a device.
- Line sensors. Reaching one takes a line crew. Start by designing FUOTA with A/B images and rollback before units ship, and cut power mid-update on the bench to check the sensor recovers.
What every group needs, whatever its category
Whether the device is a meter or a gateway, keeping it secure for its whole life is a different engineering job from shipping it:
- Updates that work over thin links: FUOTA over LoRaWAN, PLC, NB-IoT or LTE-M, with small delta packages, resumable downloads and an A/B partition that rolls back on failure.
- Staged rollouts: a small group of units first, health checks, automatic stop.
- Signed firmware and secure boot, with a unique key per unit set at the factory.
- An SBOM of the image you actually ship, so a new vulnerability maps to affected units in hours, not weeks.
- A support period you can keep: the device will outlive several versions of its SDK and chip documentation.
Our own fleet is a useful reference for the rollout side. On LaMetric we have shipped 250 releases over the air to about 75,000 devices that are online. That works because the update path was designed in from the start, not added once the devices were in the field.
How we help
At Smart Atoms we design the connectivity and update path of connected devices from the first prototype to the fleet: FUOTA over constrained links, A/B updates with rollback, secure boot, signed releases and staged rollouts. See how we approach device connectivity and secure OTA updates and the EU CRA readiness assessment, or take the 5-minute CRA readiness check. If your meters, sensors or gateways need an update plan that lasts their whole support period, talk to an engineer.
Which group is yours?
Sources: Smart Atoms analysis of 473 Enlit Europe 2026 exhibitor profiles (153 hardware makers shortlisted); Cyber Resilience Act, Regulation (EU) 2024/2847, Annexes III and IV; LoRa Alliance FUOTA building-block specifications.
