Cyberattack Set Swedish Store Freezers to 50°C: What the *Reporting Rules* Actually Say

The freezers became ovens

Sometime during the night, freezers in ICA and Coop stores across Sweden stopped doing what freezers do. Instead of keeping things cold, they heated up to 50°C ^[1]. Ice cream melted, meat spoiled and staff arrived in the morning to a mess.

The cause was a cyberattack, and it shows what can happen when digital systems control physical infrastructure ^[1]. The interesting part, from a regulatory perspective, is what happens after you notice.

The 24-hour clock

Sweden's Cybersecurity Act has been in force since 15 January 2026 ^[2]. It implements the EU's NIS2 directive and applies to essential and important entities in 18 sectors, including retail that depends on digital infrastructure for daily operations.

When something significant happens, the law sets out three steps. First, an early warning within 24 hours of becoming aware of the incident. Second, an incident notification within 72 hours. Third, a final report within one month ^[2].

The 24-hour deadline is like a lost bank card. The clock starts when you notice it's gone, not when you get around to calling the bank. If you spot something odd at 10 p.m. on a Tuesday, the early warning is due by 10 p.m. on Wednesday, whether that's convenient or not.

The reporting goes through a common platform run by ENISA, and supervisors can ask follow-up questions ^[2]. They will want to know when you first knew, what you did about it and why.

What counts as significant

Not every glitch needs reporting, but a cyberattack that turns freezers into ovens and spoils stock across multiple stores would likely meet the threshold. The law talks about incidents that have caused or could cause serious operational disruption or financial loss ^[2].

The guidance will get clearer as cases build up, but the basic test is whether the incident materially affects your ability to deliver the service or puts people, assets or data at risk. A single freezer breaking down is maintenance. Dozens of freezers overheating because someone broke into your control systems is an incident.

A sealed incident timeline

When a supervisor asks why the early warning went out after 30 hours instead of 24, you need to show when you first detected the problem and when you decided it was reportable.

Here, the thing to seal is each step of the incident as it happens: the first detection note, the decision to escalate and each report as it is sent. Sealing takes a fingerprint, not the data itself, so the content of your incident log stays with you. You seal through the REST API, the SDK or the MCP server, and you get a witness ID back.

If the timeline is questioned later, anyone you share it with can check that each record is exactly what was written at that time, even if someone with administrator rights had access to the log in between. Change a single character in a sealed entry and the fingerprint won't match.

How it would work

1. Your monitoring system flags unusual activity with the freezers at 22:14 on Tuesday.
2. You seal a note of that detection with WitniumChain, and the fingerprint goes on a chain where any later change would show.
3. At 23:02, the on-call engineer escalates it as a potential cyberattack. You seal that decision.
4. At 21:50 on Wednesday, you send the early warning through ENISA's platform and seal a copy of what you sent.
5. When the supervisor asks, you show the sealed timeline: detected at 22:14, escalated at 23:02, reported at 21:50. The maths is clear.

What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. What it doesn't show is that your response was adequate or that the report was complete. Those are separate questions. But it does answer the first one a supervisor will ask: when did you know? Read the docs.

The first 2,000 witnesses a month are free.

What this means for you

If you run an essential or important entity under the Cybersecurity Act, here are three questions to put to your team this week.

First, do you have a clear process for deciding when something crosses the threshold into a reportable incident, and does everyone on call know it?

Second, if a supervisor asked you to prove when you first became aware of an incident, could you show it? Not in an email you sent yourself, but in a record that nobody, including you, could have edited after the fact.

Third, have you tested the ENISA reporting platform, or are you planning to figure it out for the first time at 11 p.m. on a Tuesday when half the freezers have turned into ovens?

What to watch

The Cybersecurity Act's deadlines are already running: 24 hours for the early warning, 72 hours for the incident notification and one month for the final report ^[2]. The Cyber Resilience Regulation adds another layer from 11 September 2026, when manufacturers of connected products must report actively exploited vulnerabilities and serious incidents, again with short deadlines ^[3].

Both sets of rules count the hours from when you became aware, not from when it's convenient. The organisations that get this right are the ones that have decided in advance what counts as significant, who makes the call and how they keep a record of it.