Why Cold Storage Sites Need a Manual Fallback Plan
Security Intermediate 5 min read

Why Cold Storage Sites Need a Manual Fallback Plan

A cold storage fallback plan keeps product safe when a refrigeration controller is compromised. Cover detection, manual control, product moves and reporting.

Published: November 9, 2026 • Updated: November 9, 2026
cold chainbusiness continuityincident responseot security

A cold storage fallback plan is a written procedure for keeping product safe when the refrigeration controller or its monitoring cannot be trusted. Hardening controllers lowers the odds of an attack, but the 2026 refrigeration controller attacks showed that sites with default passwords and internet exposure were hit overnight, before anyone noticed. A site with a manual fallback plan treats a compromised controller as an operational problem with known steps. A site without one finds spoiled stock in the morning.

Why do cold storage sites need a manual fallback plan?

Cold storage sites need a manual fallback plan because the controller is a single point of failure for both temperature and visibility. When it is compromised, staff may lose the ability to see the temperature and to change it at the same moment, and the only remaining controls are physical and procedural.

The European attacks illustrate the point. Units were forced into continuous defrost and heating, temperatures reached 50°C, and hundreds of supermarkets discarded food. In France, staff at the national blood service stepped in at three cold storage sites before blood products were compromised. The difference between those outcomes was human intervention in time.

What should a cold storage fallback plan cover?

A cold storage fallback plan should cover four things: how staff notice a problem, how they take control of the equipment without the controller, how they decide what happens to the product, and who they tell. Each needs a named owner and a phone number, not a department.

Detection and escalation

Define the triggers that start the plan. Examples include a high-temperature alarm, a monitoring "no data" alert, a setpoint or defrost change nobody requested, or a contractor reporting suspicious access. Write down who gets the first call at any hour and who can authorize product moves or disposal.

Overnight coverage deserves particular attention. Both European waves ran overnight. If the only person who receives alerts is the day manager, the plan needs a second contact.

Manual control

Work out with your refrigeration contractor how each unit can be run safely without the network controller. That may mean a local mode on the unit, a physical isolation switch for the controller's network connection, or shutting off defrost heaters at the breaker. Do not guess this part: the right method depends on the equipment, and the contractor should document it per unit.

Record where those switches and breakers are, and label them. Staff at 3 a.m. should not need a site plan to find them.

Product decisions

Decide in advance how long each product category can sit outside its range before it must be discarded, and where it can go in the meantime: another unit on the same site, a sister store, a rented reefer trailer or a partner's cold store. For regulated products such as blood, vaccines, medicines and lab samples, the decision rules usually come from the product owner's quality procedures; reference them rather than inventing new ones.

Keep independent temperature records that do not depend on the controller, such as battery data loggers. After an incident, those records are what tell you which product stayed in range and can be kept.

Communication and reporting

List who must be told and when: management, the refrigeration contractor, the insurer, food safety or health regulators where required, and law enforcement. The US agencies ask organizations to report suspicious activity to CISA or the FBI's IC3, and healthcare operators can report supply chain disruptions to HHS.

How is this different from an IT incident response plan?

A cold storage fallback plan protects a physical process with a clock running, while an IT incident response plan protects data and systems. The IT plan asks what was accessed and how to restore it; the fallback plan asks how long the product has and where it goes.

The two plans should point to each other. Once the product is safe, the IT side takes over: preserve the controller's configuration and logs, take it off the network, change credentials, restore a known-good configuration and find out how the attacker got in.

Who owns the plan?

Ownership is usually the hard part. The equipment belongs to facilities, the controller was installed by a contractor, the network belongs to IT, and the product belongs to operations or a clinical team. In small businesses, such as the Dutch butcher shops hit in November 2026, one person may hold all four roles without realizing it.

Assign one owner for the plan as a whole, and make each role's part explicit. The contractor's part belongs in the service contract: response time, documented manual procedures per unit and notification if they detect suspicious access on their side.

Testing the plan

A plan that has never been run is a document, not a capability. Run a short tabletop exercise once a year, using a realistic trigger such as "the freezer alarm fires at 2 a.m. and the dashboard shows normal." Then do one physical drill: have staff find the isolation point for a unit and read an independent logger without the controller.

Measure two numbers each time: how long from trigger to a person on site, and how long from arrival to the unit under manual control. Compare those against the time the product can tolerate.

Where this fits with hardening

The fallback plan is the last layer, not the first. The first layers are the measures the agencies list: remove internet exposure, change default passwords, segment the network and apply firmware updates. The middle layer is tight refrigeration setpoint limits and alerts, plus a way to notice a denial-of-view attack when readings stop.

Budget for the plan in the same cycle as controller replacement. Legacy units the vendor no longer supports are the ones most likely to fail open, and the fact sheet asks operators to identify and replace them. Until they are gone, the fallback plan carries the risk they leave behind.