In October 2026, intruders reached into hundreds of French food stores and changed their refrigeration settings. Freezers ran warm; stores threw out fresh and frozen stock, and reports described equipment fires and water damage as well. Within days the same pattern spread across Europe — supermarkets, wholesalers, food processors, independent businesses — as attackers pushed temperatures up, altered defrost cycles, and at some sites switched off the alarms that would have flagged the change. An Associated Press overview described tons of spoiled food and losses in the millions; Reuters put one specific on it — a Belgian butcher who discarded about EUR 15,000 of meat. CERT-FR documented the French incidents.
None of it took exotic malware. Attackers used ordinary remote-control functions, working as designed, to inflict physical and economic harm on civilian systems — and each of the weaknesses they leaned on had been shown in public years earlier. The defences were known; what the incidents reveal is what happens where they are not in place.
The risk was not confined to retail. A refrigeration-equipment provider served three sites of the French Blood Establishment, and the same tampering reached them: cold-storage setpoints driven toward extreme values, reportedly as high as 110°C against the deep-freeze near −30°C the plasma requires.
It was caught overnight. The French Blood Establishment credited its monitoring and alarm systems, through the Associated Press, while French reporting attributes the catch to an on-call technician who saw the temperatures climbing; the precise alert chain has not been disclosed. Either way, staff secured or transferred the plasma with no product lost.
Blood is a tightly regulated cold chain, and a sector that already keeps a technician watching overnight was likelier to catch a drifting setpoint than a food store was — that is maturity. But a person noticing in the small hours is also partly luck. The food-sector losses are what the same attack does where neither the watch nor the luck is there.
No authority has tied the healthcare event to the food-sector ones, and no common actor or access route is established; the supported term is incident cluster, not campaign. It makes no difference to the operational conclusion, which holds either way: vendors and operators are carrying the risk now, the Cyber Resilience Act’s deadlines are closing in, and the work of reducing it should have begun years ago.
Safety regulation is usually written in blood — the rule that comes after the crash, the fire, the dead. This cluster came disquietingly close to the phrase: its sharpest edge fell on a blood service, and the plasma survived the night. It did not come to blood. It came to spoiled food. Call that an inoculation, if it takes — a dose of the real thing small enough to survive, in the hope it builds immunity before the next exposure arrives at a cost that cannot be refunded. Whether a warning that only stinks is enough, when it usually takes blood, is the question the industry is now being asked.
Ordinary functions scale into physical loss
Nothing in the record points to custom industrial malware. What the reports mention is mundane: exposed interfaces, default passwords, known vulnerabilities, end-of-life products, remote-service access — though no single one applied to every victim. Two ideas are worth separating. An access route is how an unauthorized user reaches a system; a control path is what connects that access to a physical effect. Old equipment is only a condition; a shared password is an access route; the command that raises a temperature setpoint belongs to the control path.
The loss is not in doubt: hundreds of sites, tons of discarded food, real money written off from single shops to national chains. What one controller does in one store, the same model, the same management portal, or the same maintenance contract does across hundreds of them — a reused credential or a shared service turns one foothold into a fleet-wide exposure. The public evidence does not prove one shared weakness explains every victim, but it does not have to: the damage is already spread across a continent and already counted. What remains to establish is the mechanism, not the harm.
A reader can still object that this is a bad week for refrigerated logistics and little more — spoiled groceries, insured and replaceable, plus one healthcare scare that ended with nothing lost. Take the objection seriously, then measure it properly. Severity is not the outcome this round; it is the distance between what happened and what that same access was already shown to do. A setpoint driven toward 110°C in a room of transfusion plasma is not a grocery problem that brushed against healthcare — it is a safety-critical capability that happened to be caught. So it is fair to ask, plainly, what it points at next: a water system, a power grid, a chemical plant — or the bedside communicator a pacemaker depends on, next to one father’s bed and a thousand others. Judging the risk by the kindest outcome of its first wave is how every preventable disaster looks reasonable in advance.
Responsibility tracks the decisions that shaped the system in the first place. The vendor sets the architecture, the defaults, the update mechanism, and the support window; the integrator decides how sites connect and how remotely they are deployed; the service provider may hold access across the whole fleet; the operator controls configuration, replacement, and local recovery. And the price tag on a controller says nothing about how much rides on it. A cheap device may govern a store’s entire food inventory, a building’s heat, or a hospital’s cold storage. Security scope has to follow the physical function, not the invoice.
The CRA makes difficult work mandatory
The European Commission published its CRA proposal on 15 September 2022; the regulation entered into force on 10 December 2024, its Article 14 reporting duties have applied since 11 September 2026, and most provisions take effect on 11 December 2027 (summary; regulation). None of this makes the refrigeration incidents a proven violation — most of the text was not yet in force, and the question would turn on specifics.
We set out the seven parts of the CRA that matter most for product teams in December 2024, in The Critical 7 of the Cyber Resilience Act.
There is an obvious objection to invoking the CRA: that companies were right to wait for the law to settle. The argument has a logic — a proposal is not a law, final text can shift obligations, and re-architecting a connected product is expensive to do twice — and for the paperwork, the conformity files and documentation, it holds. For the physical exposures it does not, because those were demonstrated before the proposal existed and never depended on a word of its final text. A default password, an exposed interface, a missing recovery path was unsafe in 2021 and still unsafe in 2027. Waiting to remove a known unsafe state was never defensible — and the incidents, a blood service among the targets, have made further waiting indefensible on the merits. Whether that is enough to move anyone is the open question; it is not one a vendor’s argument, this one included, can settle.
What the incidents illustrate is why the regulation exists. The CRA obliges manufacturers to ship secure defaults, to handle vulnerabilities and maintain a software bill of materials, to provide security updates and a defined support period, and to tell operators how to run the product safely; operators, in turn, have to know what they have deployed, what of it is reachable from the internet, and how it recovers. None of it is cheap, and a documentation exercise bolted on at the end cannot substitute for the engineering. December 2027 is a deadline, not a starting gun — preparing products and reducing the risk already in the field have to proceed together. The CRA is itself the rare safety rule written ahead of the dead rather than after them, and the refrigeration cluster is a warning in the same key. Acting on both while the bill is still ruined stock, not lives, is the opening — and it will not be this cheap twice.
The knowledge predated the incidents
The methods are not new, and neither is the public knowledge of how these systems fail. Practical Hardware Pentesting (2021 — the author’s mandatory self-plug) sits beside work such as The Hardware Hacking Handbook (O’Flynn and van Woudenberg, 2021), and the discipline sustains its own annual conference — hardwear.io has run since 2015 for a reason. On the industrial side, NIST codified control-system security in SP 800-82 in 2011, and a year later Digital Bond’s Project Basecamp showed mainstream PLCs were “insecure by design.” On the far larger consumer side, the Mirai botnet conscripted hundreds of thousands of connected devices in 2016 through nothing more than factory-default passwords. The refrigeration controllers belong to that second world. And a weakness is typically demonstrated years before an incident exploits it: OT
What was missing was not a technique but a set of decisions, and decisions can be audited. Testing needs an owner. Engineers need permission to expose defects without penalty. Remediation needs a budget set before the assessment, not argued for after it. Procurement needs to demand evidence instead of accepting a claim.
Testing has to reach the physical function
A network test will find exposed services, outdated software, and weak segmentation — findings that matter, but that leave the one operational question untouched: can an unauthorized user drive this product into an unsafe physical state? Answering it means following the control path wherever it runs — across the product (firmware, authorized startup, updates, local authentication), the remote side (accounts, cloud services, portals, maintenance tools), and the process (industrial protocols, alarm logic, safety limits, recovery behavior). Each needs a defined physical effect to test against and a safety boundary not to cross, worked on representative devices and simulators rather than the live fleet. Done badly, this testing either overstates the risk or creates real operational danger, so competence here is process knowledge and safety control as much as method. Penetration testing supplies one kind of evidence; secure development, architecture and code review, monitoring, and incident response remain necessary around it.
What the longer record shows
This is not a new problem. The timeline below sets out 146 selected public records from Stuxnet in 2010 through the 2026 cluster — hostile operations, discovered capabilities, and controlled demonstrations, kept as separate categories. Two patterns stand out. Reach: only 42 of the 146 involve purpose-built OT as the direct target; the other 104 are “bridge” cases, where a connected device was the way in rather than the prize — consumer IoT (39), OT used as a conduit (37), industrial IoT (28) — so the civilian edge is now as well represented as the plant floor. Timing: 32 of the records are controlled demonstrations, and they tend to land years before the hostile incidents that reuse the same weakness. The detail — Ukraine’s grid, CRASHOVERRIDE, the TRISIS safety-system attack, PIPEDREAM, FrostyGoop leaving more than 600 buildings without heat, Volt Typhoon — is in the timeline. The throughline is constant: operational equipment can be the target, the thing disrupted, or the infrastructure used to reach something else, and valid functions together with exposed interfaces produce real effects without any custom process malware at all.
Interactive timeline
OT and IoT attacks, 2010–2026
146 selected public records, curated by Crimson7. Selective and incomplete: it shows how attack paths changed, not how often attacks happen.
146 public records, 2010–2026
The interactive timeline loads as you scroll. Open the timeline data (JSON)
Research cutoff 4 November 2026.
What counts as evidence
The duties above only matter if someone can later tell whether they were met — and that is a question of records. A vendor’s word that a control exists is weak evidence; a recorded test result, against a stated safety boundary and an expected outcome, is strong. So each correction wants an owner and a due date, each finding a remediation decision, and wherever those records are missing the work simply has not been done. That standard also exposes the organizational problem beneath the technical one: vendors have to accept findings early enough to redesign around them, clients have to supply representative equipment and the process knowledge to test it properly, and management has to fund the fix once the assessment is in.
Crimson7’s interest
I should be plain about the interest behind this piece. Crimson7 sells the front of this work, not the back — security testing and secure-design review that detect the exposed paths, and the engineering support that helps a vendor move toward closing them — not the remediation itself, which is the vendor’s to build and own. The firm stands to gain from the argument I am making, and I will not pretend otherwise. Nor is the interest only commercial: the risk now landing is the one that embedded and industrial-security people spent more than a decade warning about — not me alone, but I was among them — and having been part of trying to move this industry, and having found it slow and hard to mature, I cannot watch that warning come true from a neutral distance. Weigh all of that as you read; none of it makes the control paths any less exposed.
The first observable decision
The physical effects already exist — food discarded, a specific loss booked in Belgium, plasma rescued after someone changed the settings around it. In a reasonable amount of time, depending on the size and complexity of the estate, a serious organization can do three things for itself: name an owner for its internet-exposed control systems; find what is exposed and close the obvious holes, default passwords and open interfaces among them; and rehearse recovery by pulling the network, failing an alarm, and restoring local control by hand. Only then, and only where the physical risk warrants it, does an independent test of a representative product become the next step rather than the first. Those three leave a trail — an owner named, a list of holes closed, a recovery drill logged — and that trail is the observable test of intent. None of it requires a vendor. If it doesn’t exist, the work hasn’t started.
Disclosures and evidence limits
- Crimson7 sells the detection and secure-design services discussed above, not the remediation itself.
- The companion timeline is Crimson7-curated and non-exhaustive.
- The historical figures synthesize selected public evidence; they do not measure a statistical time series.
- Product-specific CRA conclusions require legal review.
Jean-Georges Valle is Head of HEI & Compliance at Crimson7 and author of Practical Hardware Pentesting. These credentials explain the author’s perspective. They do not replace evidence for the claims above.
