Somewhere in France last weekend, a refrigeration controller accepted an instruction it should never have accepted.

Shoppers at several of France’s largest supermarket chains found refrigerators that had spent the night quietly keeping meat, dairy and frozen goods cold instead climbing toward oven temperatures. The Paris prosecutor’s office confirmed on 12 October that it had opened an investigation into what it described as a large scale cyberattack on connected refrigeration systems at food retailers across the country. The attackers did not go after tills or customer databases. They went after the networked controllers that manage temperature setpoints, alarms and defrost cycles.

Tonnes of food destroyed. No data stolen. No ransom note required.

This was not a clever attack. That is the point.

What makes this a cybersecurity story rather than an equipment failure is the pattern: multiple competing retailers hit in the same overnight window, which points at a shared weakness somewhere in the connected refrigeration supply chain rather than a run of coincidental hardware faults.

Nobody who works in operational technology security is surprised. Last year researchers at Armis disclosed ten vulnerabilities, collectively named Frostbyte10, in Copeland E2 and E3 controllers, the devices that run compressor groups, condensers, walk in units, HVAC and lighting in grocery estates across Europe and the United States. The warning was public. The firmware updates existed. The devices mostly stayed as they were.

That is the pattern across the whole category. A refrigeration controller is commissioned by a third party engineer, connected for remote monitoring, and then left in place for a decade. It has a web interface, privileged services enabled by default, and often a password that was never changed from the one in the installation manual. The retailer buying it has no realistic way to assess any of that at purchase, and no way to patch what the manufacturer never designed to be patched.

Which is exactly the problem the EU set out to fix.

The Cyber Resilience Act is not a 2027 problem any more

Most compliance calendars still file the Cyber Resilience Act under December 2027. That is the date the essential cybersecurity requirements and CE marking bite. But the reporting obligations started on 11 September 2026, and they require manufacturers to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements to EU authorities.

Three things make that more serious than it first reads.

First, the reporting duty covers products already on the EU market, not only those placed on it after December 2027. The controller installed in 2019 counts.

Second, the clock is short. An early warning is due within 24 hours to ENISA and the national CSIRTs, through the Single Reporting Platform that went live on the same date.

Third, the penalty ceiling is up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher.

And the scope reaches further than the word “manufacturer” suggests. Importers and distributors that rebrand a product, or modify it substantially, take on the manufacturer’s obligations along with it. If you put your badge on someone else’s controller, the obligation is yours.

So in the week a coordinated attack cooked the stock in stores across France, the legal instrument designed to stop products like these reaching the market is already partially live, and most of the companies in scope have not worked out whether it applies to them.

What a sensible response looks like

If you make, rebrand or integrate connected products sold into the EU:

Establish whether you are a manufacturer under the regulation. Identify the products in scope. Build the vulnerability disclosure route through which you will actually learn that something is being exploited, because without it the 24 hour clock starts when a journalist calls you. Rehearse the reporting decision before you need to make it, including who signs off at 2am. Then start the gap work against the essential requirements, because secure by default configuration, no known exploitable vulnerabilities at release, and a defined support period are design decisions, not documentation exercises.

If you operate estates full of these devices, you are not the regulated party, but you are the one with the spoiled stock. Ask your critical suppliers how and to whom they will notify you. Put it in the renewal.

Where Locked Stack fits

We are a PCI DSS Qualified Security Assessor, and the discipline that goes into a formal assessment is the same discipline the CRA now demands of product makers: evidence, scope definition, tested controls, and a defensible position when a regulator asks.

For CRA readiness we support clients with scope and applicability assessment, product security gap analysis against the essential requirements, penetration testing of connected products and the platforms that manage them, vulnerability management and ASV scanning, coordinated vulnerability disclosure policy design, incident reporting playbooks aligned to the 24 hour and 72 hour timelines, supplier assurance programmes for buyers of connected equipment, and integration of all of it with the ISO 27001, NIST, GDPR, DORA and NIS2 obligations you are already carrying, so you build one control set rather than five.

We are an assessor firm with entities in Europe and the United States, and we would rather help you answer these questions now than help you explain yourself later.

If connected products sit anywhere in your business, whether you build them or buy them, the useful next step is a short conversation about scope. That is usually the question that decides everything else.