# Electronic shelf label security: real threats and what to demand from your vendor

> What can be attacked in an electronic shelf label system (radio, gateway, cloud, NFC, firmware) and what to ask any vendor before you sign.

Source: https://etiquetaselectronicas.io/en/technology/electronic-shelf-label-security/
Published: 2026-11-09 | Updated: 2026-11-09

An electronic shelf label is a small radio device that obeys commands and changes what the customer sees. Its main risk is not data theft but manipulation: a false price on the shelf, blank screens, or a compromised cloud platform. What decides it is whether commands are authenticated, encrypted and signed.

This article does not explain how a label works (see the [technology guide](https://etiquetaselectronicas.io/en/technology/)). It covers what can go wrong, what we know from sources, and what to ask before signing.

## What is really at stake

Let us start by toning down the drama. A label stores no customer data and no card numbers. It also does not set the checkout price; the point-of-sale system does. What an attacker can touch is the **consistency between what you see and what you pay**.

That is enough to do harm. A lower shelf price means complaints and queues at the till. A higher one is a practice nobody wants to be accused of. A block of wiped displays in the middle of a promotion forces staff to relabel by hand. And if the attack reaches the management platform rather than a single label, the whole chain is exposed.

So the system has to be considered in layers, not just at the label.

## Layer 1: the radio link between gateway and label

This is the most publicly researched layer, and the picture is not reassuring for older systems.

**A case with a CVE number.** Record CVE-2022-45914, published on 27 November 2022, describes a label protocol implemented on a specific board (ETAG-2130-V4.3, with an OV80e934802 transceiver) that "does not use authentication" and lets anyone change label values through 433 MHz signals. It is classified as an authentication bypass by capture-replay (CWE-294) and scores 6.5 out of 10 on CVSS 3.1 according to NVD; the GitHub advisory lowers it to 5.3. Behind it is a SEC Consult advisory. The record itself cites altering the organisation of a hospital warehouse and changing retail prices as examples.

**The talk behind it.** SEC Consult presented an analysis of a popular 433 MHz label at Hardwear.io USA 2022. Its abstract describes several flaws that allowed the radio signal to be forged and arbitrary content to be shown on the displays.

**A demonstration with hobbyist hardware.** According to Hackster, researcher Aaron Christophel showed a battery-powered ESP32 with a CC1101 module. It listens for a few seconds to a store's sync messages to learn the system identifier and frequency, then transmits a sync message longer than the gateway's; the gateway stops transmitting because it does not transmit when it detects traffic on the channel. In his test in a real shop it only refreshed the screens without changing content, but he pointed out that a wipe command would leave them unusable. The report does not say which manufacturers are affected, and he published the access point firmware but not the attack code.

**A more recent talk.** The TROOPERS26 programme announces "Priceless: Hacking Electronic Shelf Labels", covering weaknesses in Android apps, management software, Bluetooth Low Energy and 2.4 GHz traffic, and states that the researchers got no response from manufacturers. This is a programme summary: we could not verify what was finally presented or which manufacturers are named, and the claim about manufacturers should not be taken as a verified fact.

What can be concluded without exaggeration? Three patterns: no authentication on the link, messages that can be recorded and replayed, and a shared channel that can be occupied to silence the gateway. All three are protocol design flaws, not display flaws.

### What the standard says

The Bluetooth SIG ESL profile, published in February 2023 on top of Bluetooth 5.4, specifies that commands and responses are encrypted and authenticated with AES-CCM. That is a public, auditable baseline, something a proprietary protocol does not offer by default. But a standard does not guarantee a correct implementation: key management, commissioning and firmware remain the manufacturer's job. And not the whole installed base uses it.

For manufacturers with their own protocol, what exists are datasheets. The Vusion 2.6 F one mentions 128-bit AES encryption and encrypted NFC, for example. That is a starting point; the question is what is encrypted, with which keys and who holds them.

## Layer 2: the gateway

The gateway is the bridge between the store network and the labels' radio, and it is usually a Linux-type device connected by Ethernet with PoE or by Wi-Fi. If you have already read how many are needed in the [article on gateways](https://etiquetaselectronicas.io/en/technology/esl-gateway-how-many-needed/), the question here is different: what happens if someone takes it over.

A compromised gateway can forward forged commands to every label in its radio range and move across the store network to the rest. What to look at:

- **Segmentation.** The gateway should live on its own VLAN, with outbound access only to the platform endpoints the vendor documents. If the vendor demands opening the whole store network, that is a bad sign.
- **Outbound connection.** It is preferable that the gateway connects outwards over TLS, rather than having ports open towards it from the internet.
- **Credentials and services.** No default passwords shared between installations, no unused SSH or web panels left open.
- **Boot and update.** Whether the gateway accepts any firmware image or only signed ones.
- **Physical access.** It hangs from a ceiling or sits in a storeroom, not in a locked room.

## Layer 3: the account and the cloud

This is the most rewarding layer for an attacker and the least spectacular. A single user with broad permissions on the management platform can alter thousands of labels without touching the radio. It is reasonable to require:

- Two-factor authentication and, where available, single sign-on with the company's identity provider.
- Separate roles: whoever designs templates, whoever approves a bulk price change and whoever only views should not be the same person.
- An audit log: who changed which price and when, exportable.
- ERP or POS integration through the integration's own credentials, with minimal permissions and rotation, not an employee's account.
- An approval procedure for bulk changes, especially if they relate to [dynamic pricing](https://etiquetaselectronicas.io/en/regulation/dynamic-pricing-supermarkets/), where a mistake or abuse has legal consequences as well as commercial ones.

And the continuity question: what happens to the labels if the cloud goes down or the store loses its connection. Showing the last price is the normal behaviour, but it is worth asking rather than assuming.

## Layer 4: NFC

NFC on a label is used to pair, configure or update it with a phone, without going through the gateway. It is convenient, and for that reason it is also a door. The range is a few centimetres, so the risk is a customer or a disgruntled employee standing at the shelf, not a remote attacker. Even so:

- Can any phone with a generic app write to the label, or is a credential required?
- Can NFC be disabled by policy when it is not in use?
- Does an NFC write leave a trace in the platform?

Datasheets mention AES-encrypted NFC on some models, but none of those we reviewed explains how writes are authorised. It is an open question for the vendor.

## Layer 5: firmware

A label that lives for 5 to 10 years has to be patchable. Two questions define this layer:

1. **Is label and gateway firmware updated over the air (OTA)?** If not, a vulnerability found in year three stays on the ceiling until the installed base is replaced.
2. **Are images signed and verified?** Without signature verification, anyone who manages to talk to the label can install their own code.

There is a nuance that costs money: updating over the air uses battery, so a serious manufacturer publishes how much each firmware update takes off the estimated battery life. If they cannot answer, they probably have not measured it.

## What European regulation changes

Two European rules push in the same direction.

- **Radio Equipment Directive.** Delegated Regulation (EU) 2022/30 made cybersecurity requirements for internet-connected radio equipment enforceable from 1 August 2025. Delegated Regulation (EU) 2026/339, of February 2026, repeals it with effect from the day the Cyber Resilience Act applies in full, and specifies that 2022/30 applies until 10 December 2027.
- **Cyber Resilience Act (EU) 2024/2847.** According to the Commission, it entered into force on 10 December 2024; manufacturers must report actively exploited vulnerabilities from 11 September 2026, and the main obligations apply from 11 December 2027. It includes vulnerability handling throughout the product lifecycle and security updates.

We have not analysed whether a specific label falls under one conformity assessment procedure or another, and that cannot be said in the abstract. What is useful to the buyer is practical: **ask in writing for how many years the vendor commits to publishing security fixes** and how a vulnerability is reported. Before 2027 that was a courtesy; from then on it is a manufacturer's obligation.

## Questions for any vendor

These fourteen questions fit in a one-hour meeting and quickly separate someone who has thought about the problem from someone with a marketing sheet. Scoreable versions are in the [vendor checklist](https://etiquetaselectronicas.io/en/tools/esl-vendor-checklist/) and the [RFP template](https://etiquetaselectronicas.io/en/tools/esl-rfp-template/).

| Layer | Question | A good answer includes |
|---|---|---|
| Radio | Are commands to labels authenticated and encrypted? | Algorithm, who holds the keys and how they are renewed |
| Radio | What protects against replay of recorded messages? | Counters or nonces, not just "it's encrypted" |
| Radio | What happens if someone occupies the channel? | Interference detection and alerting |
| Gateway | Which ports and services does it expose, and where does it connect? | A closed list, outbound TLS connection |
| Gateway | Does it accept only signed firmware? | Yes, and how an image is revoked |
| Cloud | MFA, roles and an audit log as standard? | Log export |
| Cloud | Is there a test environment separate from production? | Different data and credentials |
| Cloud | Which certifications or penetration test reports can they show? | A dated report, not just a logo |
| NFC | Who can write to a label over NFC? | Credential per operation; option to disable it |
| Firmware | Over-the-air updates, and how many years of patches? | Written commitment |
| Firmware | How much battery does each update cost? | A measured figure |
| Process | How is a vulnerability reported and how fast is it answered? | Published channel and deadlines |
| Process | Have they had incidents, and what changed afterwards? | A frank answer |
| Exit | How are keys and data erased when the contract ends? | Procedure and certificate |

If the vendor answers almost everything with "it's secure" and no detail, that is information. If they say "we don't publish that" but offer to show it under a non-disclosure agreement, that is information too, and more acceptable.

## A sensible order of priorities

For a store or chain that is evaluating, effort pays off most in this order:

1. **The platform account and roles.** This is where most damage can be done and what you can control most.
2. **The written patch commitment**, because it determines the useful life of what you are buying (see also [vendor lock-in](https://etiquetaselectronicas.io/en/blog/electronic-shelf-labels-vendor-lock-in/)).
3. **The gateway network.** Cheap to segment at the start, expensive to redo later.
4. **The radio.** You cannot audit it yourself, but you can ask what documentation and independent testing exist.
5. **NFC.** It matters, but the risk is local.

A simple security test during a pilot is to ask the vendor's team to attempt (with your permission and on your premises) a replay attack on a group of test labels. If they are unwilling, that is also an answer.

## What this article cannot say

There is no independent study comparing the security of the major manufacturers, and the known public vulnerabilities mostly affect cheap 433 MHz systems and the work of individual researchers. That does not prove the big vendors are secure; it proves that no comparison has been published. We treat every manufacturer security claim as the manufacturer's own statement until external evidence supports it.

## Frequently asked questions

### Can electronic shelf labels be hacked?

Some can. There are public vulnerabilities in specific 433 MHz systems that do not authenticate commands, and researchers have shown that displays can be changed or wiped with cheap radio hardware. That does not make every system vulnerable; it depends on whether commands are authenticated and encrypted.

### What can an attacker achieve with an ESL?

At worst, show a false price or blank the displays. The checkout price does not change, but the shelf and the till no longer agree, which is a commercial and complaints problem. Access to the cloud platform would be far more serious than access to a single label.

### Is it enough for a vendor to say it uses AES encryption?

No. What matters is where it is applied (radio, gateway, cloud), how keys are managed, whether replayed messages are rejected and how firmware is updated. "128-bit AES" on a datasheet is a starting point, not an audit.

### Does the Cyber Resilience Act apply to ESL systems?

It applies to products with digital elements placed on the EU market. Reporting obligations start on 11 September 2026 and most requirements on 11 December 2027. Before that, radio equipment has been subject to cybersecurity requirements under the Radio Equipment Directive since August 2025.

## Sources

- [SEC Consult, Blackmail Roulette: research on a 433 MHz electronic shelf label (presented at Hardwear.io USA 2022)](https://sec-consult.com/blog/detail/blackmail-roulette-the-risks-of-electronic-shelf-labels-for-retail-and-critical-infrastructure/)
- [CVE-2022-45914, GCVE database](https://db.gcve.eu/vuln/CVE-2022-45914)
- [Hackster.io, ESP32 tool that takes over e-paper shelf labels](https://www.hackster.io/news/aaron-christophel-s-esp32-tool-can-take-over-wipe-common-epaper-electronic-shelf-labels-32acda823cb2)
- [TROOPERS26, "Priceless: Hacking Electronic Shelf Labels" (programme)](https://cfp.troopers.de/tr26-cfp/talk/DAARST/)
- [European Commission, Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [Delegated Regulation (EU) 2026/339, repeals 2022/30 (text)](https://www.ibf-solutions.com/fileadmin/dateidownloads/2026-339-en.pdf)
- [Bluetooth SIG, Electronic Shelf Label profile (8 Feb 2023)](https://www.bluetooth.com/blog/bluetooth-esl-the-global-standard-for-the-electronic-shelf-label-market/)
- [Vusion, datasheet ESL VUSION 2.6 F BW 2.4GHz](https://d2siani1ghtwy4.cloudfront.net/wp-content/uploads/2018/12/datasheet_ESL_VUSION_2.6_F_BW_2.4GHz.pdf)