Connected is only the beginning.

Connecting a device is the first step. Securing it throughout its life and independently checking the conditions it controls require a much longer view.

Who tells you when the controller is wrong?

A refrigeration controller can change a setpoint, schedule a defrost cycle and report the temperature. If that system is compromised, I want to know what else can tell the operator what is actually happening to the stored products.

The attacks on supermarket refrigeration in France in October 2026 brought that risk into view. A remote connection reaches equipment that affects real products.

The investigation of those incidents is separate from the question I want to explore here: what remains available to the operator when the control system can no longer be trusted?

The connection is the easy demonstration

Connecting equipment produces an immediate, visible result. A technician can see the installation remotely, change a setting and investigate a fault without travelling to the store. Those are useful capabilities.

Keeping that access secure is a continuing responsibility. Someone needs to maintain the equipment inventory, manage accounts, review supplier access, apply suitable updates and plan replacement when support ends. Those tasks continue long after commissioning.

The commissioning demonstration is easy to remember. Responsibility five years later can be harder to locate. Who owns access after a maintenance contract changes? Who checks support status? Who removes a temporary connection?

Start with the device

NIST’s 2020 IoT Device Cybersecurity Capability Core Baseline gives manufacturers, integrators and buyers a useful starting point. It covers six areas: device identification, device configuration, data protection, logical access to interfaces, software updates and cybersecurity state awareness. It is a baseline to adapt to the use case, not a certification of an installation.

Those six areas belong in the purchasing discussion. Show how each device is identified, how configuration and access are controlled, how data are protected, how updates work and how the operator learns about security problems.

Those questions belong in the specification and purchasing decision. They also need answers during operation. An update capability is useful only if someone manages the update process. Access restrictions need to remain effective when staff, contractors or network arrangements change.

Separate control from independent observation

Where temperature control protects product safety or quality, I expect a clear separation between operating the refrigeration and independently checking the conditions. Both functions need to be designed around the consequences of failure.

The controller manages the process. The independent monitoring system measures at justified locations, retains its own record and alerts the responsible team when conditions require attention. The alarm should not depend entirely on the controller whose behaviour it is meant to check.

The aviation analogy helps frame the question: what checks the system doing the controlling? Aircraft have varied, complex architectures. The principle I take from the analogy is independent checking, proportionate to the consequences of failure.

Two screens can share one failure

A second dashboard fed by the controller’s own reading gives us another view of the same source. To assess independence, trace what both functions still share.

Could the same compromised administrator account change both sets of limits? Would a network outage stop both systems reporting? Does one cloud service deliver every alarm? Does a common power failure remove the measurement, record and notification together?

Those questions determine how much independence the design really provides. Depending on the risk, the answer may involve separate probes, access rights, network boundaries, local recording, backup power or an alternative notification route. Buying two products is not a substitute for examining their shared dependencies.

Detection needs a response

Independent monitoring cannot prevent every unauthorised command, repair a refrigeration fault or guarantee that products remain suitable for use. It can provide another opportunity to detect the change and preserve evidence, provided it remains available and reaches someone who can act.

That means testing the whole response. If a temperature rises overnight, who receives the alert? Who acknowledges it? What happens if the first contact is unavailable? Can the team protect the stock and have any excursion assessed under the relevant quality procedures?

The time available matters. An alarm that arrives after the product has suffered an unacceptable exposure may document the loss without helping prevent it.

Secure the controller as well

Independent monitoring belongs alongside security measures on the control system. CERT-FR’s immediate recommendations include removing public Internet exposure, checking configurations and restoring access through a secure VPN or protected network. Its alert also warns that a factory reset alone does not resolve the vulnerability of an exposed unsupported device.

The baseline applies to the independent monitoring equipment too. A second system with unmanaged accounts, exposed interfaces or no update plan introduces another set of weaknesses. Independence and device security need to be considered together.

NIST’s operational technology guidance broadens the assessment to security, reliability and safety. For this installation, that means examining remote access, network boundaries, maintenance and what happens to measurements and alarms during a disruption.

At the design review, ask for the failure demonstration. If the controller becomes unavailable or untrustworthy, show how the team still measures conditions, receives an alarm and responds. Test it safely, without exposing stored products.