Nobody wrote malware to spoil the food in hundreds of French supermarkets. They didn't need to. The door was already open, and the fix had been sitting on a vendor's website for over a year.
On the night of October 11, 2026, refrigeration controllers at up to 700 supermarkets across France switched into defrost mode. Intermarché and Netto lost more than 300 stores; Carrefour and Coopérative U lost 80 each. Some cases climbed as high as 50°C, alarms didn't fire, and estimated losses run into the tens of millions of euros. On November 2 the same pattern showed up in Belgium, the Netherlands, Germany, Sweden, and several other countries.
If you're building a connected product right now, read this as a preview. The controllers that failed were somebody's carefully engineered product once. Yours will be ten years old someday too.
Three Failures, Not One
The easy headline is "outdated firmware." That's about a third of the story.
The devices at the center of it are Danfoss AK-SM 800 and AK-SC355 system managers, the boxes that run every refrigerated case and freezer in a store. The official investigation hasn't confirmed the exact method yet, but the experts' working explanation involves three separate failures stacked on top of each other.
The first was a design flaw. In 2025, Claroty's Team82 found a hidden "code of the day" login in the AK-SM 800A: a password generated from the device's own date. Anyone who knew the algorithm could log into any unit. CISA rated it as remotely exploitable, leading to code execution. That bug was in Danfoss's own code, not a third-party library.
The second was a fix nobody installed. Danfoss disclosed the findings in March 2025 and shipped patched firmware (R4.2, then R4.3.1) that year. Only units that never got the update were hit.
The third was hardware that can never be fixed, sitting on the open internet. The AK-SC355 reached end of life in 2016; the AK-SM 800 in 2021. No update is coming for either. Researchers counted roughly 2,700 Danfoss systems reachable online before the attack, about 1,600 of them in France. No malware appears to have been involved: the attacker just logged into a web page and changed setpoints.
That's a design decision, a lifecycle decision, and a deployment decision, made years apart by different people. Ken Munro of Pen Test Partners said the culprits could have been "kids messing around." When the attack is that easy, attribution almost doesn't matter.
You Can't Patch What You Can't Find
When Claroty reported the flaw, Danfoss had to answer three questions fast. Which products and hardware revisions run the affected firmware? Which of those can still receive a fix, and which are past end of life? And where are those units right now?
The first two are design-intent questions, and they're exactly what firmware tracked as a versioned line on your BOM answers. Hardware revision C pairs with firmware v4.5; revision B is capped at v3.9 because the flash is too small; revision A is end of life and will never see another build. If that record lives in a git tag nobody connected back to the product, or in one engineer's head, the security advisory turns into an archaeology project.
End of life deserves particular attention, because it's the decision startups never make on purpose. A part on your BOM has a lifecycle state; your firmware support for a hardware revision should too, with a date and a plan for what customers are told. "We stopped shipping updates and stopped talking about it" is how a 2016 controller ends up online in 2026.
The third question, where the units are and what they're running today, is not something a PLM answers on its own. That's fleet state, and it belongs to a device-management platform sitting next to your BOM. Be honest about which system owns which half. In France, the vendor knew the fix existed; the failure was getting it onto the units that needed it.
Design for the Update You'll Need in 2031
Every connected product you ship will need a security update you can't predict today. The only question is whether you designed a way to deliver it.
Over-the-air updates are the baseline, and the update path is itself an attack surface, so build it carefully. Sign every firmware image. Have the bootloader verify that signature with secure boot before anything runs. Add rollback protection so an attacker can't push an older, vulnerable build that's still validly signed. Use an A/B partition scheme so a failed update falls back to the last good image instead of bricking a unit in a customer's building.
Then think hard about how the device connects. The Danfoss controllers ran a web server built for a local network, and however they ended up exposed to the internet, that server was listening for anyone who found it. A better pattern is a device that never listens at all: it dials out to your service over TLS, pulls updates, and takes commands from a connection it initiated. Remote access for installers runs through your cloud with real authentication, not a port forward on a store router.
This is a bring-up decision, not a firmware feature you bolt on after DVT. Secure boot depends on the microcontroller you pick, key storage depends on whether there's a secure element on the board, and A/B partitions depend on how much flash you specced. All of that is locked in by your hardware revision long before anyone writes the update service, which is why an IoT product's BOM has to cover the board and its firmware as one product, not two projects that meet at the factory.
Every Device Gets Its Own Identity
The "code of the day" is the textbook anti-pattern: one algorithm unlocks every unit in the world. Once somebody works it out, the whole installed base falls at once.
Give every device its own cryptographic identity instead. A unique X.509 certificate per unit, with its private key generated inside a secure element like a Microchip ATECC608 or an NXP SE050 so it never leaves the chip, and mutual TLS so your service and the device each prove who they are. If one unit is compromised, an attacker gets one unit. You revoke that certificate and the rest of the fleet doesn't notice.
Provisioning those identities happens on the factory line, which makes it a manufacturing step like any other. It belongs in your CM handoff and in the release note that travels with your firmware binary, alongside how serial numbers and MAC addresses get assigned during the flash.
Regulators have caught up to this. The UK's Product Security and Telecommunications Infrastructure Act has banned universal default passwords on consumer connected products since April 2024, and the EU Cyber Resilience Act's secure-by-design requirements point the same direction.
Your Device as a Weapon, Your Device as a Target
Insecure IoT fleets have hurt people before, in a different way. In October 2016, the Mirai botnet took over hundreds of thousands of cameras and DVRs using factory-default passwords and pointed them at the DNS provider Dyn. Twitter, Netflix, Reddit, and GitHub went down for millions of users across the US and Europe. None of those devices were damaged; their owners mostly never knew. The devices were weapons aimed at someone else.
France is the other failure mode. The device was the target, and the damage was physical: spoiled food, empty shelves, and fires in some stores. NPR has since reported attacks on refrigeration in Israel and the US as well.
Your product can fail either way. A smart sensor that only reports temperature can still join a botnet. A controller that drives a compressor, a motor, or a valve can do real harm on its own. Which one you're building changes how much security engineering it deserves, and if your device moves anything physical, the answer is "more than you've budgeted."
Whether You Wrote It or Imported It, You Own It
Every connected product runs a stack: an RTOS or embedded Linux, a TLS library, a network stack, maybe a vendor SDK for the radio. Each one ships vulnerabilities on its own schedule, and you need to know when they do. That's what a software bill of materials is for, and under the Cyber Resilience Act it's no longer optional for anything you sell in the EU: you need one, and it has to be updated with every firmware release.
But the Danfoss flaw wasn't in a dependency. It was in code Danfoss wrote. Writing your own firmware doesn't make it more secure than importing someone else's; the most common C and C++ vulnerabilities are memory bugs that hand-written code introduces just fine. Review your own authentication and update code as if a stranger wrote it, because in ten years one effectively did.
For a hardware startup, that's the real lesson from a few hundred warm freezers. The product you ship is not finished when it leaves the factory. Track which firmware every revision runs, plan the day each revision stops getting updates, build the update path into the board, and give every unit a key of its own. Your first field advisory is a bad time to find out you can't answer which units need the fix; see pricing and start the record now.
