Witnium logo
WITNIUM. Chain.
← News

Rules · 2026-11-06 · 5 min read

Harden cooling systems now, feds warn critical infrastructure operators

U.S. authorities have told critical infrastructure operators to secure their cooling and refrigeration systems following cyberattacks. The alert highlights the logging, detection and reporting duties that matter when everyday equipment becomes a target.

VeraBy Vera

Share
Abstract illustration of a refrigeration system with network connections
Illustration: AI-generated

When the fridge becomes the front door

A cyberattack on a refrigeration system sounds odd until you think about what cooling equipment does. It keeps food fresh, it keeps data centres running and it keeps medicines viable. So when attackers worked out how to tamper with it, U.S. authorities took notice.[1]

The alert from CISA and the FBI, issued in late 2024, told operators to review access controls, segment networks and watch for unusual activity around cooling systems. It's a reminder that critical infrastructure includes all the parts that keep essential services going, not just the ones that feel high-tech. In the cases they described, attackers got in through poorly secured remote access, changed temperature settings and caused disruption.

Think of it like this: if your front door is locked but the window above the garage is wide open, locking the door doesn't do much. Remote access to a cooling system is that window. Once someone's in, they can change settings, turn equipment off or cause damage that takes hours to spot and days to fix.

For operators of essential services, the attack itself is one problem. The reporting duty is another.

Reporting under pressure

In the EU, the Cyber Resilience Act and the revised Network and Information Security Directive (NIS2) have aligned their reporting timelines. In Sweden, the new Cybersecurity Act, which came into force on 15 January 2026, requires essential and important entities to send an early warning within 24 hours of becoming aware of a significant incident, a full incident notification within 72 hours and a final report within a month.[2][3]

The 24-hour clock starts when you become aware of the incident, not when it suits you. That's the same idea as when you lose your bank card: the timer begins when you notice it's gone, and waiting a day to report it doesn't pause the clock.

So if a cooling system starts behaving oddly at 3 a.m. on a Tuesday and the monitoring team spots it at 8 a.m., the 24 hours run from 8 a.m. If the team sees the alert but assumes it's a sensor fault and doesn't escalate it until Wednesday morning, the question later will be when they reasonably should have known it was a real incident.

That's where logs come in. They're the receipt for when something was detected, when it was escalated and when the early warning was sent. If all of that is only in a spreadsheet the incident team can edit, it's easy for someone to question the timeline after the fact.

What logs need to do

A log is supposed to tell you what happened and when. But if the people keeping the log can also change it, the log becomes less a record and more a story. During an incident, administrators often have full access to logging systems, and once an event is written, it can usually be edited or deleted if someone with the right permissions decides to.

DORA, the EU regulation on digital operational resilience for the financial sector, is explicit that logs must be protected against tampering, deletion and unauthorised access.[4] Sweden's Cybersecurity Act doesn't spell it out in the same detail, but the duty to report accurate timelines implies that the records behind those timelines can be trusted.[3]

Access control and monitoring are the foundation. They stop most changes. But they don't deal with the last-mile question: how do you show a supervisor or an auditor that a log hasn't changed, when you're the one keeping it?

Sealing the timeline

Here, the thing to seal is the timeline of detection and response: the first alert, the decision to escalate, the early warning as it's sent. Sealing means taking a fingerprint of each step and recording it independently, so that if someone later questions when you knew or when you reported, the answer isn't just in a system you control.

You would seal each detection note when it's logged, each escalation when it's recorded and each report when it's sent. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. The detection note, the escalation and the report stay in your systems. To check later, you calculate the fingerprint again and compare it with the sealed one. If they match, nothing has changed. Change a single character in the log and the fingerprints won't match.

So if a supervisor asks why the early warning took 30 hours instead of 24, you can show the sealed record of when the incident was first flagged, when it was escalated and when the report was sent. The content of each record stays with you. What the seal shows is that the timeline you're presenting is the one recorded at the time, not one written with hindsight.

This doesn't show that your response was adequate or that you reported everything you should have. It shows when you recorded each step.

What this means for you

If you operate essential infrastructure or important services under the Cybersecurity Act, ask these questions now:

  • Who monitors alerts from operational systems like cooling, and how quickly does an alert reach someone who can escalate it?
  • Where are detection times, escalation decisions and reports recorded, and can those records be edited after the fact?
  • If a regulator asks when you first became aware of an incident, what evidence can you show?
  • Can your logging systems prove that a record written at 8 a.m. on Tuesday hasn't been changed since?

For cooling and refrigeration specifically, the CISA alert is clear about the basics: review who has remote access, segment those systems from the rest of the network and watch for unusual logins or configuration changes.[1] The reporting duty starts with detecting the problem. After that, it's about showing you acted within the timelines, and that means logs you can stand behind.

What to watch

The EU Cybersecurity Act's reporting requirements apply across member states, and national laws like Sweden's are already in force. The Cyber Resilience Act's incident reporting duties for manufacturers begin on 11 September 2026.[2] In both cases, the 24-hour early warning is the tightest deadline, and it's the one that tends to get questioned when an incident becomes public.

For operators in sectors covered by NIS2 and its national implementations, incident reporting isn't new, but the timelines are now harmonised and the penalties for non-compliance are substantial. In Sweden, the supervisory authority can issue sanctions for failing to report within the required timelines.[3]

Cooling systems won't be the last everyday piece of equipment to become an attack vector. The principle is the same whatever the target: detect, log, report and be ready to show that the timeline you give is the one that actually happened.

Sources

  1. [1]Cyberattacks on refrigeration systems prompt CISA, FBI alert, The Record from Recorded Future News, 2024-12-18
  2. [2]Regulation (EU) 2024/2847 on cybersecurity requirements for products with digital elements (Cyber Resilience Act), EUR-Lex, 2024-11-20
  3. [3]Cybersäkerhetslagen (2025:1506), Riksdagen, 2025-12-19
  4. [4]Commission Delegated Regulation (EU) 2024/1774 on ICT risk management, EUR-Lex, 2024-06-17
Pass it on

Know someone who should read this?

Share it with a colleague, your compliance team or your network.

Email

Sealed with WitniumChain

1d4c124e52578a5ca052d75ac7552095b329cc65dfbd73bfc844bc66083f1cc1 · 2026-11-06 11:57 UTC

Written with AI assistance and reviewed by Vera. Every version of this article is sealed with WitniumChain.

Related