Fixing the Refrigeration Attack: A Remediation Plan for Danfoss AK-SM and AK-SC Sites

The attack on 11 October 2026 put refrigeration into forced defrost at roughly 700 French supermarkets. If you operate the same equipment — and a great many US grocers, cold stores, restaurant groups and food distributors do — this is the remediation plan.
It is deliberately narrow. The small-business guide and the enterprise architecture cover how to secure operational technology in general. This article covers what to do about this, now, in order, with the version numbers.
The short answer
Five actions, in this order. The first two are same-day work and they carry most of the risk reduction.
- Find every refrigeration controller you own, including ones with their own cellular modem.
- Remove all inbound internet access to them. No port forwards, no public management interface.
- Patch AK-SM 8xxA units to R4.3.1 or later.
- Isolate AK-SM800 and AK-SC355 units, which cannot be patched at all, and plan their replacement.
- Add temperature monitoring that does not come from the controller.
Everything below is the detail of those five.
Step 1: Find out whether you run this equipment
Danfoss has said the majority of affected units were the AK-SM800, declared end of life in 2021, and the AK-SC355, phased out in 2016 — along with some current AK-SM800A systems running outdated firmware.
The equipment will not be in your IT asset register. Three places to look:
- The plant room and the back of house. An AK-SM or AK-SC system manager is a wall-mounted panel with a display, usually near the compressor rack. Photograph the model and firmware version from the screen.
- Your refrigeration contractor's service records. They commissioned it, they maintain it, and they know the model and firmware of every site. Ask for the list in writing.
- The firewall. Look at inbound rules, port forwards, and any static DHCP reservation or VLAN with a name like "refrig", "rack", "danfoss" or "controls".
Ask every contractor directly whether any installed equipment has a SIM card in it. Some of the French controllers were connected through their own cellular modems for remote monitoring. That traffic never crosses your firewall, so it will not appear in any inventory built from network data, and none of your firewall rules apply to it. This is the single most commonly missed item.
Record, per site: model, firmware version, IP address, who maintains it, how they connect, and whether it has its own cellular link.
Step 2: Find out whether it is reachable
Three checks, in increasing order of effort.
From outside. From a connection that is not your office network — a phone on cellular data is fine — try to reach the controller's address and port. If a login page appears, that is the problem, and it is the condition that was swept up at scale in France.
In the firewall configuration. List every inbound rule, NAT entry and port forward. Expect to find at least one nobody can account for. Pay attention to rules on non-standard ports, which is where "temporary" vendor access usually ends up.
In the public scan data. Services such as Shodan and Censys index what answers on the internet, and you can look up your own address ranges. The counts published during this incident give a sense of scale: Claroty cited 2,765 exposed devices via Censys, and a Shodan scan on 19 August 2026 found 3,726 of these controllers answering the public internet. Some reporting after the attack put the figure higher still.
If you would rather check a single site quickly, our free port scanner tests the connection it is called from and reports which service ports are reachable from outside. It only ever scans the address the request came from, which is yours.
Step 3: Cut the exposure today
This is the change that would have prevented the French incident, and on an existing firewall it is a configuration edit rather than a purchase.
- Delete every inbound rule that reaches a controller. Not "restrict to the vendor's IP" — delete. Vendor access is restored properly in step 6.
- Block the controller's outbound access except what it needs. DNS to your resolver, NTP, and the specific vendor cloud endpoints if the system uses them. Nothing else. Open outbound access is how a compromised device reaches whoever compromised it.
- Put the controllers on their own VLAN with default-deny toward business and payment networks. The low-cost guide has the rule table; multi-site operators should work from the enterprise segmentation model.
- For cellular-connected units, exposure is not yours to firewall. Ask the vendor to disable the modem, or to document what it accepts connections from. Until that is answered, treat the unit as sitting on an untrusted network bolted to your building.
CISA's own guidance for this hardware says the same three things, in the same order: minimise network exposure so devices are not accessible from the internet; put control networks behind firewalls, isolated from business networks; and where remote access is required, use more secure methods such as VPNs — while recognising that VPNs have vulnerabilities of their own and need updating too.
Step 4: Patch what can be patched
For AK-SM 8xxA series units, CISA advisory ICSA-25-140-03 (last revised 26 August 2025) documents three vulnerabilities and the releases that fix them:
| CVE | Type | Affected | Fixed in |
|---|---|---|---|
| CVE-2025-41450 | Improper authentication (CWE-287) — datetime-based password generation, allowing authentication bypass | Versions prior to R4.2 | R4.2 |
| CVE-2025-41451 | Command injection (CWE-77) via alarm-to-mail configuration fields, giving post-authenticated remote code execution | Versions prior to R4.3.1 | R4.3.1 |
| CVE-2025-41452 | External control of system configuration (CWE-15), causing denial of service | Versions prior to R4.3.1 | R4.3.1 |
Target R4.3.1 or later. R4.2 fixes only the first of the three.
Two things are worth understanding about that table rather than just acting on it.
The first is how the authentication flaw worked. The platform accepted a code derived from the device's current date — so anyone who reproduced the algorithm could generate a valid administrative code for any unit, on any day, without knowing a password. That is why this scaled: the same code worked everywhere. Kevin Beaumont's summary during the incident was "the username is admin and the password changes every day automatically to.. the current date. Every single one is like this."
The second is that CVE-2025-41450 and CVE-2025-41451 chain. An authentication bypass followed by post-authenticated command injection is remote code execution on the controller, not merely an unauthorised defrost command. If you are assessing impact, assume an attacker who reached one of these could do anything the device can do, including lying about temperature.
Patching an OT controller is an operational change, not an IT one. Schedule it with the refrigeration contractor, in a maintenance window, on a stocked store — and take a configuration backup first.
Step 5: Isolate what cannot be patched
AK-SM800 and AK-SC355 receive no security updates and never will. The AK-SM800 was declared end of life in 2021 and the AK-SC355 was phased out in 2016. No firmware version makes these safe to expose.
That does not mean they must be replaced this quarter. It means the network has to do the work the device cannot:
- No inbound internet access, at all, with no exception for the vendor
- Own VLAN, default-deny in both directions except explicitly required flows
- Administration only via VPN or a zero-trust broker, never directly
- Monitor outbound connections from that VLAN and alert on anything new
- Independent temperature monitoring, because this is the equipment most likely to misreport
- A replacement line item in the capital plan, with a date
Those are compensating controls, and they are a legitimate answer. Document them on the risk register next to the asset, so that "we cannot patch it" is a decision with controls attached rather than an open gap.
Step 6: Fix credentials and vendor access
Default and derivable credentials are what made this trivial to scale.
- Change every default password on controllers, gateways and the switch and firewall in front of them.
- Unique credentials per system. A shared password across forty sites means one compromise is forty.
- Replace shared vendor logins with named accounts, so you can tell which engineer did what.
- Restore vendor access properly: site-to-site VPN, client VPN with MFA, a zero-trust broker, or a jump host they work from. Enable it for a maintenance window rather than permanently where the contract allows.
- Log it. Who connected, when, from where, to what.
If a contractor insists they need an open inbound port, the practical alternatives are set out in the low-cost guide's section on vendor remote access. At enterprise scale this becomes contractual rather than technical — see vendor risk.
Step 7: Monitor temperature independently
Claroty's research demonstrated that a compromised AK-SM800A could be made to disable cooling while continuing to report normal temperatures.
Read that again if you own one, because it defeats the control most operators assume they have. If your temperature alarm comes from the controller, a sufficiently capable attacker can turn off the cooling and leave the dashboard green.
The fix is cheap: standalone temperature sensors in each case and cold room, on a different network path, with their own alerting to a phone. A few hundred dollars per store against a loss that ran to €270,000 at two stores in Alsace alone. This is the control that gets somebody out of bed at midnight instead of discovering it at six.
It also helps with something unrelated to security: it is independent evidence for food-safety temperature records, which matters if the system that normally produces those records is ever in question.
Step 8: Verify
Fixing is not the same as having fixed. Four checks that produce evidence:
- Re-run the external test from a connection outside your network. Nothing should answer.
- Read back the firmware version on each AK-SM 8xxA and confirm R4.3.1 or later, per site, in writing.
- Test the segmentation from inside. From a device on the OT VLAN, try to reach a business server. It should fail.
- Export and store the controller configurations, then restore one onto a spare or a bench unit to prove the backup works. Commissioning data represents days of engineering, and the French stores that recovered fastest were the ones that could restore it.
Write the results down with dates. If a customer, insurer or auditor asks what you did about the refrigeration attack, that document is the answer.
What we still do not know
Nobody has publicly identified how the attackers got in. Danfoss has not named a vector, no advisory connects the attack to a specific CVE, and no source we can find names the flaw used. Attribution is also open — no actor has been identified and no motive established. ANSSI and the Paris prosecutors are investigating.
That uncertainty is worth stating plainly, and it does not change the plan. The candidate paths are internet-exposed management interfaces, the documented authentication weakness, a compromised supplier account, and cellular-connected units outside anyone's firewall. The five steps above close all of them, which is the point of working from exposure rather than from a single CVE.
It is also why "we patched it" is not a complete answer on its own. Patching addresses one of those paths. Removing exposure and controlling vendor access addresses the rest.
Questions for your refrigeration contractor
Send these, and ask for written answers:
- Which refrigeration controller models and firmware versions are installed at each of our sites?
- Which of those models are end of life or past their security-update date?
- Does any installed equipment have its own cellular connection or SIM card?
- How do your engineers currently connect to our equipment remotely?
- Is that access through named individual accounts, or a shared one?
- Can AK-SM 8xxA units be updated to R4.3.1, and when can that be scheduled?
- For end-of-life units, what is the replacement path and the lead time?
- Will you work with VPN or zero-trust access instead of an inbound port?
Question 3 is the one most likely to surprise you. Question 5 is the one most likely to be answered badly.
A realistic timeline
Within 72 hours — inventory the controllers, test them from outside, delete every inbound rule that reaches one, and send the contractor questionnaire.
Within 30 days — patch AK-SM 8xxA units to R4.3.1 in scheduled windows, move controllers onto their own VLAN with default-deny policy, replace shared vendor credentials with named accounts behind VPN or a broker, and enable logging.
Within 90 days — install independent temperature monitoring where spoilage is expensive, document compensating controls for equipment that cannot be patched, put end-of-life replacement in the capital plan, back up and restore-test configurations, and run the verification checks.
For a single site with a capable firewall already in place, the 72-hour work is a few hours and costs nothing but attention. The 30-day work is typically a day or two of engineering.
What this buys, and what it does not
These steps would have prevented what happened in France. An attacker scanning the internet for controllers would not have found yours; one who found a patched controller would not have had a date-derived administrative code; one who reached the OT VLAN anyway would not have had a path to the business network; and the independent sensors would have raised an alarm while the product was still cold.
They do not make the equipment invulnerable, and nothing does. A compromised contractor laptop with legitimate VPN access is a different problem, and so is an attacker who is already inside your network. What these controls do is remove the cheap, scalable paths — the ones an opportunistic campaign uses, and the ones nearly every victim is taken by — and make what remains visible.
That is defence in depth in practice: not a guarantee, but several independent things that each have to fail before the freezer gets warm.
Related reading
- French Grocery Store Refrigeration Hack Shows the Growing Risk of OT Cyberattacks — the incident, with sources
- Low-Cost OT & IoT Security Guide for Small and Mid-Sized Businesses — the general architecture for a single site or a small estate
- Enterprise OT Security Architecture — zones, OT DMZ, privileged access and site isolation at scale
If you want this done rather than planned, our OT and ICS security and attack surface management teams run exactly this exercise, starting with what is reachable from the internet today.
Sources
- Danfoss AK-SM 8xxA Series (Update A), ICSA-25-140-03 — CISA
- Hack of Danfoss refrigeration controllers in Europe causes tens of millions in food losses — Facilities Dive
- Major French Supermarket Chains Hit by Cyber-Attack — Infosecurity Magazine
- Cyberattack shuts down refrigerators at French supermarkets — BleepingComputer
- 2026 French supermarket refrigerator hack — Wikipedia


