The Fix Has Been Out for a Year. The Controller Is Still Exposed.

Quick answer: A gap exists between when OT vendors fix vulnerabilities and when operators can actually patch. In food, pharma, and cold-chain sites the update waits for a rare maintenance window because a bad one costs product, not just uptime - a discarded batch, a broken cold chain, a quality deviation that has to be investigated. Two of the most common refrigeration controllers, the Copeland XWEB Pro and Danfoss AK-SM 800A, have serious documented flaws; both vendors shipped firmware fixes months ago, yet thousands of management interfaces remain reachable from the public internet. The practical fix for the gap is reachability: restricting which systems and people can reach the controller lets operators take the update on their own schedule without leaving it exposed in the meantime.

Two of the most common supervisory controllers in commercial refrigeration have serious, publicly documented vulnerabilities. Both were fixed by their vendors months ago - Danfoss shipped a fix for the AK-SM 800A in 2025 (CISA advisory), Copeland for the XWEB Pro in February (CISA advisory). A Shodan query on August 19, 2026 returns 3,726 of the Danfoss management interfaces reachable from the public internet - Team82 counted roughly 2,800 via Censys during its research. Different engines, so not a trend line, but the order of magnitude has not moved.

If you run a cold-storage warehouse, a food plant, a pharmaceutical distribution site, or a supermarket chain, one of these boxes is probably what tells your compressors and evaporator fans what to do. This piece looks at the gap between "the fix is available" and "the fix is applied": why that gap is wider on the equipment that keeps product cold than almost anywhere else on a plant floor, and what an operator can do inside it.

What the researchers showed, and why the vendor names matter less than they look

Team82's XWEB Pro research, published August 9, is the bigger set: 23 vulnerabilities, 21 rated high. Two of them do the heavy lifting. The administrator password on affected firmware is derived from the date, the device's hardware address, and a fixed value in the firmware, so anyone who can reach the management page can work out today's password without guessing. And once in, an attacker has 19 separate ways to run their own commands as root. The Danfoss AK-SM 800A had fewer flaws - three, all in its web management interface - but one was a hidden "code-of-the-day" login that also bypasses authentication.

The demonstration is the part worth remembering. The researchers connected an XWEB Pro to a field controller and a small test refrigerator, held the temperature reading on the display steady at the correct value, and quietly switched off the cooling fans. The fridge warmed. The screen said everything was fine. On a real unit, the temperature log that a food-safety auditor or a pharma quality team would pull to prove the product stayed in range lives on the same controller - in food or pharma, that gap is a discarded batch at best, and a product-integrity question that reaches the market at worst.

Both vendors did what vendors should: took the report, shipped fixes, told customers. The more interesting problem sits with the operator, because the position the disclosure puts them in looks the same whatever logo is on the controller.

Why the fix sits unapplied

In most manufacturing, a bad maintenance window costs throughput. You lose a shift, you catch up. In food and beverage, pharmaceuticals, and temperature-controlled consumer goods, a bad window can cost the product itself. A refrigeration excursion - the industry's word for temperature drifting outside its allowed band - is a discarded batch, a quality deviation that has to be investigated and written up under the manufacturing quality rules (GMP) that food and pharma operate under, or a food-safety record that follows the product through the supply chain. We wrote about this asymmetry last year in Why Uptime Is the New Cybersecurity KPI in Manufacturing; cold chain is where it bites hardest.

To be fair to the equipment, a firmware update on a supervisory controller is not the same as flashing a PLC mid-shift. Copeland even lets you update from the controller's own menu, provided the controller can reach Copeland's servers outbound - which is a very different thing from being reachable inbound by anyone. But the risk that schedules a maintenance window is the perceived risk, and no one likes to hear "usually straightforward" about the box holding a vaccine warehouse between 2 and 8 degrees Celsius. So the advisory gets read, the update gets queued for the next planned outage, and the next planned outage is months away.

There is a quieter reason too, and anyone who has tried to find the owner of a refrigeration controller will recognize it. These units often belong to facilities, or to the refrigeration contractor under a service agreement - not to IT, and not to whoever owns OT security. The vendor's advisory email lands in an inbox that does not read CISA advisories, if it lands anywhere. Nobody in this chain is refusing to patch; the request just never reaches someone who could schedule it.

And in the meantime the controller cannot simply be unplugged, because the same interface the attacker wants is the one the business depends on. The refrigeration OEM's technicians connect to diagnose and tune it. The operator's own maintenance team watches it from wherever they happen to be sitting. The researchers' guidance - keep the management interface off the internet, restrict it to trusted networks or a VPN - is sound, and it is where most standard advice stops. It also leaves the controller reachable by every device on the plant network and every account on the vendor's VPN.

Is "patch now or stay exposed" really the choice?

That is the choice operators are usually handed: a risky window now, or a known exposure until the next outage. Both options treat the vulnerability as the risk. The real risk is what can reach it.

A serious flaw on a controller that nothing unnecessary can reach is a backlog item. The same flaw on a controller reachable from any laptop on the plant network, any compromised office workstation, or any account on the vendor's VPN is a different situation entirely, and the difference has nothing to do with the CVE list. Every step in the published attack chains, on both platforms, starts with network access to the management interface. Remove that access and the 23 CVEs are still there, but the path to them is not.

That is the third option, and it is the one that rarely gets priced: shrink who and what can reach the controller until you can take the update on your schedule instead of the attacker's. It does not replace the firmware. It makes the firmware a planned event rather than an emergency, and it limits the damage when the next disclosure lands the week after your outage window closes.

What "shrink reachability" looks like on a real plant floor

Three attributes describe the target state:

• The controller can be reached only from specific, explicitly authorized endpoints and users - the monitoring server, the two engineers who own it, the OEM's support group - not from an entire network segment.
• When a third-party technician needs access, they get a session to that one device for the duration of the job, with no standing presence on the plant network before or after.
• None of it requires re-addressing the controller, installing anything on it, or rebooting it. If the security control means touching the device, you are back to the maintenance-window problem you were trying to avoid.

That last attribute pays off twice - once for the operator, once for the vendor. For a pharma site, the device itself is not modified, so its qualified state is not disturbed; the network change still goes through change control, but that is a lighter lift than requalifying a controller after new firmware. And for the refrigeration OEM, brokered access is easier than a VPN, not harder - no client to install, no shared credentials to rotate, no waiting on the customer's IT to open a port. Vendors are how these controllers get installed and kept running. This should make their technicians' lives simpler, not treat them as the threat.

That third property is also the one that has historically made segmentation policy fail in practice. Eaton's security team described exactly this in their write-up from earlier this month: written segmentation policy across more than two hundred manufacturing sites that could not be enforced, because enforcing it with VLANs and NAC meant touching legacy devices they could not afford to touch. Eaton is electrical manufacturing, not cold chain, so the transferable part is the constraint rather than the vertical - agentless legacy equipment that cannot be re-addressed or restarted is the norm on any plant floor, and enforcement has to work around it.

Where Zscaler fits

Three capabilities map to this - two that close the paths above, and a third for the gap that closing paths cannot address.

Zero Trust Device Segmentation isolates a controller like an XWEB Pro or AK-SM 800A from the rest of the plant network without agents, without re-addressing, and without changing the physical network - each device gets its own enforcement boundary, reachable only by the endpoints you authorize and the users you admit through policy. Lateral movement from a compromised laptop or workstation toward the controller stops at that boundary.

Zero Trust for 3rd Party Access gives the OEM's technician a brokered, recorded session to that one controller for that one job, with no VPN and no network presence. When the session ends, so does the access. It also removes the most common reason these interfaces end up on the public internet in the first place - if the vendor's path is brokered, there is nothing to expose.

Closed paths do not vet the traveler - a compromised monitoring host or a misused authorized account arrives with legitimate access.

That is where Zscaler Deception fits: a decoy that looks like one more controller on the same plant network, which no legitimate system has any reason to touch, so the first wrong move is the alert. Two things make that more than a tripwire. Because nothing legitimate ever talks to the decoy, a hit arrives already interpreted - an authorized source doing something it should not - rather than one more line for an analyst to triage. And because the real controller already sits behind a policy-enforced boundary, the response can be as narrow as the alert - drop the monitoring host's path to the controller, end the account's session - without touching the controller itself. The decoy asks nothing of the real device - no agent, no load, no change - which is the same property that made the boundary workable in the first place. It is still detection: someone, or a policy, has to act on it.

None of this replaces the firmware update, and no one should read it that way. Copeland's 1.13 and Danfoss's R4.3.1 still need to be applied. And none of it helps a controller nobody has pulled behind the boundary yet - the thousands of exposed interfaces are exposed because that step has not been taken, not because it is unavailable. What changes is when you have to apply the update and what happens to you in the meantime - a Tuesday you chose rather than a Saturday someone else did.

With the boundary in place, the next advisory lands differently. You check what can reach the controller - one monitoring host, two engineers, a brokered vendor path - schedule the firmware for the next planned window, and go back to work. The picture to keep from the demonstration is a display that says everything is fine while the fans are off. The controllers that keep product in spec are the ones with the least tolerance for a bad patch day, and that is why they need the fewest things able to reach them.

If you want to work through what this looks like for your own sites, our OT architecture workshop maps the controllers, the vendors who reach them, and the enforcement points you already have.