If you cannot secure an RFID reader, you should not be putting it on a client’s network

On Monday 2 November, supermarkets in seven European countries found that their freezers had been told to defrost. The BBC reported around 40 Delhaize stores hit in Belgium and Luxembourg, with others in Sweden, Ireland, the Netherlands, Estonia and Finland, and temperatures reportedly reaching 50C. One Delhaize branch put its loss at €100,000 of stock. It was the second wave. The first hit hundreds of French supermarkets in October.

Britain did not escape. The Telegraph reported that Langridge Organic, a west London wholesaler, had six of its ten cold-room systems taken over, with temperatures pushed to 66C and the alarms switched off. Its managing director caught it at 5.30am and pulled them off the internet. Three British meat suppliers were also hit, according to their trade body. None of them lost stock, and the National Cyber Security Centre calls the national impact minimal so far.

These are fridges, not RFID. So why is this on RFID News?

Because take away the compressor and what was attacked was a small networked computer, installed by a contractor, sitting on a network its installer did not own, left reachable so that someone could maintain it from a distance. That is also a fair description of a great many RFID readers.

So here is our position, and some people in this industry will not like it. If you are not competent to manage the security of an RFID or IoT device, you should not be placing it on a client’s network.

What actually went wrong

Nothing clever. Vincent Strubel, head of the French cyber agency ANSSI, told the French Senate that the October attack used basic security failings: refrigeration equipment directly exposed to the internet, administered with no particular protection, and weak passwords. He pointed out that the first recommendation in ANSSI’s industrial security guide, published since 2014, is not to expose these systems to the internet.

The makers’ accounts are no more flattering to the people running the kit. Danfoss said most affected units in France were legacy products that no longer receive updates, one declared end-of-life in 2021 and another phased out in 2016, or current products on outdated firmware. In November a Danfoss spokesperson told Dutch broadcaster NOS that the hacked systems there used a default password and were not on a secure network.

The British victims were reportedly running Copeland XWEB controllers for which a firmware fix had been available since August. Copeland has acknowledged that certain XWEB products are affected and says it has re-sent its patching and security guidance. The NCSC says vulnerabilities that have been public for a long time were used, while ANSSI dismissed that explanation for the French attack. The experts disagree on whether the door was a known bug or a weak password. Neither is a comfortable answer, because closing both is routine work.

The attackers needed no malware to do the damage. They used the system’s own functions: change the setpoint, start the defrost, silence the alarm. No one has claimed responsibility, and no one has been identified.

The scale of what is still out there is the sobering part. Forescout counted 12,976 exposed refrigeration management services on 6,017 internet addresses in 99 countries and territories. That counts systems reachable online, not systems hacked.

Who was responsible? Everyone says someone else

These units are online for a sensible reason. Contractors can diagnose faults without driving to site, and Danfoss says remote connection typically cuts unnecessary callouts by 15 to 30%. Forescout found manufacturer documentation describing port forwarding and public addresses as supported ways of setting this up.

The trouble is what happens to ownership. Forescout describes the common arrangement: a contractor manages the software, the store owns the equipment and its IT department runs the connection, so no single party may have the whole picture. French chains generally outsource refrigeration management, according to local media.

Watch how the first statements went. Intermarché pointed to a service provider that manages refrigeration in its stores. Danfoss said it had long advised customers to update and migrate. Strubel said deploying these systems securely is a company’s fundamental responsibility. The head of Sabcobel, a Belgian firm that makes and operates refrigeration systems, said the simplest fix was managing units over a secure connection, that most customers moved to that after France, and that some units need physical changes, not just software. Langridge’s managing director said no one from Copeland had contacted him about the risk, while Copeland says it is proactively engaging with customers.

To be clear about what has not been shown: nobody has established who put any particular controller online, and we have seen no installer named as being at fault. We are not saying a contractor caused this. We are saying that the argument since has not produced one party who accepts it was their job to prevent this. That should make anyone who installs equipment for a living uncomfortable.

Now look at what we install

A modern fixed RFID reader is a Linux computer with an antenna port. Impinj’s R700 guide describes a Linux system partition, SSH access and a web interface. Zebra’s FX integration guide lists Linux, HTTPS, SFTP, SSH and SNMP, plus IoT Connector and cloud endpoints. These readers publish data over MQTT or webhooks and connect to warehouse and retail systems. All of that is useful. All of it is also attack surface, and it sits on someone else’s network.

The makers have been improving, and they deserve credit for it. Zebra’s guide now says SSH and SNMP are disabled by default, and its readers force a change of the default admin password at first login. On Impinj’s Octane 9.0 and later, the reader will not run until the default password is changed. But the guide ties some of Zebra’s changes to its EU compliance work, so check what your build does elsewhere, and Impinj’s 2021 R700 guide only recommended changing a published default.

And the estate is not all new. Zebra’s own support note says that before firmware 3.31.22, an SSH account on FX7500 and FX9600 readers could be accessed without a password. Reader manuals from several makers document factory logins. That is normal practice. The question is whether anyone changed them, and whether the reader that went on a ceiling several years ago has been touched since.

Then there are the published flaws. Here is a sample:

Most of these are medium severity, and the worst is on a product its maker has retired. This is not a catastrophe list. It is a maintenance list: someone has to know which of these applies to the readers they installed, and that a retired reader will never get a fix.

FEIG went further in 2022, warning customers about the Mirai botnet malware and its Linux-based readers. It told them to take readers off the network, reinstall firmware, switch off unused services, change default logins and never open a port from a reader to the internet. It did not report a confirmed infection, but that is an RFID manufacturer describing exactly the French failure, four years before it happened.

What we did not find

We looked hard for a case of an RFID inventory reader being the way into a company’s network, and we did not find one. None of the reader flaws above appears in the US government’s catalogue of exploited vulnerabilities, checked on 5 November. We also found no study counting how many RFID readers are exposed on the internet. We cannot find dedicated reader network security guidance from the RAIN Alliance or GS1 either, and if it exists we will happily link to it.

That is not a clean bill of health. Most breaches are never described in public at that level of detail, and nobody has counted because nobody has looked. Forescout’s 2026 ranking puts RFID readers fifth among its riskiest IoT device types, and its report says such devices are “deployed and configured by system integrators and then overlooked by security teams”. Forescout sells device security and cites no incident there, so weigh it accordingly. Then read that sentence again and ask whether it describes anything you have installed.

The neighbouring evidence is not reassuring either. Door controllers, which often read RFID credentials, have been attacked for real: Nice Linear eMerge units were targeted at scale in 2020 to build a botnet. And the classic retail breach began with a contractor. Attackers reached Target in 2013 using credentials believed stolen from Fazio Mechanical, a refrigeration contractor. No hacked equipment was involved, just third-party access nobody was watching closely enough. In 2025, ransomware operators blocked by security software on Windows machines found an unmonitored Linux webcam on the victim’s network and encrypted file shares from it. The webcam was not how they got in. It was simply the box nobody was watching, and a fixed reader is a box of the same kind.

The line we are drawing

Nobody expects an RFID integrator to be a penetration tester. A reader installer can be forgiven for not knowing how to harden a Windows domain. You do not have to know everything.

You do have to know what you have taken money to be responsible for. If you bolted a Linux computer to a client’s ceiling and plugged it into their network, then what it is listening on, what it is running, who can log in to it and how it gets patched are not details at the edge of your job. They are the job. Read rates are not the only thing you sold.

If you cannot answer those questions, you have three honest options. Learn it. Bring in someone who knows it, and put their name in the proposal. Or write down exactly what the client’s IT team must own, and get them to agree before the first reader goes up. Shrugging and leaving a reader on the network is not a fourth option. Where a project’s responsibilities are already being carved up, security ownership belongs on that list.

What competent looks like

None of this is exotic. It is what Forescout, CISA and the NCSC have been saying for years, applied to a reader:

• No reader or management interface on a public address, and no port forwarding. Remote access goes through a VPN or secure gateway.
• Readers on their own network segment, able to reach only the systems they need.
• Every factory login changed, with credentials unique to each device. As the NCSC puts it: “No devices deployed in your network should have default passwords”.
• Named accounts for your engineers, with multi-factor authentication and a log, not one shared login that survives every leaver.
• Unused services switched off, and reader data sent over authenticated, encrypted connections.
• A record of every reader and its firmware, a named owner for patching, and a plan for the day a model loses support.
• A written handover saying what you look after, what the client looks after, and what happens when the contract ends.

If you are the client

You were never supposed to know any of this. That is what you are paying someone else for. Ask them anyway:

• Which firmware is on each of our readers, and when does support for it end?
• Can any reader or its management interface be reached from the internet, and how did you check?
• Has every factory password been changed, including service accounts?
• Who at your company can log in remotely, how, and when did they last do so?
• When a new vulnerability is published, who tells us, and who patches it by when?

How quickly the answers come back is part of the answer.

The law will not do this for you

Regulation is moving, mostly at manufacturers. The EU’s Cyber Resilience Act has required manufacturers to report exploited vulnerabilities since 11 September 2026, and applies in full from 11 December 2027. The EU radio equipment cyber rules have applied since 1 August 2025, and Zebra says its FX7500 and FX9600 are in scope. An integrator who sells a product under their own name, or substantially modifies it, can be treated as the manufacturer under the Act. One who only installs and configures an unmodified reader probably is not, though that is our reading and not legal advice.

In the UK, the default password ban covers consumer connectable products, so an enterprise-only fixed reader is probably outside it. The Cyber Security and Resilience Bill is not yet law, and its factsheet leaves out installers who do no management after installation, along with small firms. The food sector is not covered by it either. An integrator on a remote support contract could be caught if medium-sized or larger.

So on today’s rules, an install-and-leave integrator may have no clear legal duty here at all. That is exactly why this has to be a matter of professional standards and contract terms rather than something to wait for. Nobody is going to fine you for the reader you left on a default login. Your client will just find out about it the way those supermarkets did, by opening up to a warm freezer.

Refrigeration engineers did not set out to become a cyber security story. Their industry got there by connecting useful equipment to the internet and assuming someone else was looking after it. RFID still has time to avoid being next. Whether it does comes down to the people installing the readers.