Marius Pareščius, IT expert and cybersecurity specialist
Could someone connecting to your technology change a physical process and cause damage that cannot be reversed? For a food manufacturer, warehouse operator, water supplier or hospital, this question matters just as much as email security and data backups.
I see the cyberattacks on refrigeration systems in France as a warning for the entire food supply chain and for critical infrastructure. Once control of a process is lost, restoring a server may be easier than restoring a safe service. A backup cannot restore spoiled food.
What is confirmed, and what I am not assuming
In an alert published on 12 October 2026 and updated on 16 October, France’s CERT-FR reported numerous compromises of refrigeration remote controllers. It named the Danfoss AK-SM and AK-SC, Copeland XWEB and Dixell XWEB families, and recommended removing direct internet exposure of management interfaces.
The alert does not establish one particular vulnerability as the cause of every incident. I therefore do not infer that the manufacturer’s central infrastructure or a single shared contractor was breached. Disruption affecting a supply chain and an intrusion through a supplier are different things.
A dangerous command can look ordinary
Operational technology, or OT, controls physical processes. My approach to assessing risk starts with what a system can change in the real world: temperature, processing time, water supply or equipment operating mode. Asking whether a computer has antivirus software does not answer those questions.
I suggest testing three scenarios. First, the system stops. Second, it continues operating with settings that someone has changed without authorisation. Third, staff can see readings but can no longer trust them. These are preparedness exercises, not claims that all three scenarios occurred in France.
Management needs to know who would detect such a change and who could stop the process. If the answer depends on one person, one account or one remote platform, I would explicitly record that dependency in the business continuity plan. An assumption about availability should become something the organisation can test.
The food chain starts long before the shop
For farms, I would include milk cooling, livestock housing conditions, water supply, feed delivery and grain storage in the review. Each process needs a specific answer: who can change an important setting, and how would staff learn that it had happened?
For manufacturers and processors, production downtime is only one scenario. They also need a way to identify potentially affected batches if processing conditions change. Warehouse operators and carriers should plan how they would work without their usual temperature history or shipment traceability platform.
I would ask retailers, caterers and institutional food providers to check alternative supply arrangements. A school, hospital or care home needs to know whether it could obtain food safely if its main supplier stopped operating. These are assessment questions, not allegations about particular Lithuanian organisations.
Critical infrastructure and contractors must participate together
For electricity, water, heating, transport and communications operators, I would review supporting systems as well: building automation, cooling, backup power control and remote maintenance. The practical question is whether the main service could continue if essential supporting infrastructure failed.
I would separately check whether the primary and backup sites are controlled through the same account. Two devices do not provide two independent layers of protection if the same access can affect both. I suggest assessing resilience through shared dependencies, rather than through the number of devices purchased.
I would ask manufacturers for a clear security support period, integrators for documented access arrangements, and maintenance contractors how many customers could be affected by a compromise of one account. The customer must also know who could promptly suspend a contractor’s access and how that decision would be implemented.
What I suggest checking in practice
- Choose one critical process. Map the equipment to the activity, responsible people, suppliers and tolerable disruption time. Record how you would maintain a minimum safe level of operation and what resources that would require.
- Review remote access. Work with equipment operators to establish who connects, what permissions they receive and how access is revoked. Plan changes with their effects on the process and maintenance arrangements in mind.
- Test independent monitoring. Assess whether an alert would reach a responsible person if the main platform failed. Ask to see the result of the most recent test, including whether anyone acted on the alert.
- Agree how products will be assessed. Define who will restrict movement of potentially affected batches, assess available evidence and decide what happens next under the product requirements and food safety procedures.
- Exercise recovery. With engineers, test configuration backups and local or manual operation where technically possible and safe. A working control system does not, by itself, confirm that the products are safe.
- Run a joint exercise. Include management, IT, automation engineers, quality specialists and suppliers. Each finding should have an owner, a deadline and a method for checking that the problem has been resolved.
Questions for organisations, and my proposal
When did you last test remote control of your operational processes? Can you restrict one supplier’s access without stopping the entire organisation? Who would notice an unauthorised process change if the main platform showed no problem? How long could you maintain minimum safe operation?
I am not suggesting that organisations publish network diagrams or their weakest points. They can nevertheless discuss the scope of assessments, assigned responsibilities and completed exercises without exposing sensitive technical information. A general statement about taking security seriously does not demonstrate that the decision-making chain has been tested.
I suggest starting with one real process: a management consultation, a review of supplier access and a tabletop incident exercise. The technical assessment should involve your IT team and equipment operators. My aim is an action plan whose implementation can be verified, rather than a document that nobody has tried to use.
The useful questions are concrete: what would prevent us from operating safely, who could affect it, and what have we actually prepared to do? Those answers should connect technology, products, service users and the people making decisions during an incident.
To discuss cyber incident preparedness across your food supply chain or critical infrastructure, contact pagalba@parescius.lt.
Source for incident facts: CERT-FR, CERTFR-2026-ALE-012, updated 16 October 2026 and checked 17 October 2026. Risk scenarios, questions and proposed actions are the author’s assessment.