Is a defrost command a security event?

On the night of 11 October, refrigeration in several hundred French supermarkets was made to heat up and stay hot. It is a sharp example of a question every OT manufacturer now has to answer for the CRA: which events should a device report as security events, and who should hear about them?

On the night of Sunday 11 October, refrigeration units in several hundred French supermarkets were made to heat up and stay hot. Intermarché said its cabinets reached 50°C for six hours. Stock was thrown away, and the BBC reports that in some places there were small fires. According to the BBC, the attack targeted software from Danfoss that lets retailers manage their cold units remotely. The Paris prosecutor has opened an investigation. How the attackers got in has not been published, and these details are as reported on 12 October.

What is known is that the damage came from a function the system is designed to perform. Defrosting is routine: every night the cabinets warm slightly and cool again. This time it happened in hundreds of stores at once, it went on overnight, and it was found when staff arrived in the morning.

That raises most of the questions in this post: what counts as a security event in an OT device, where should it go, and how quickly does it need to get there?

What the CRA asks for

The Cyber Resilience Act requires a product with digital elements to “provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user” (Annex I, Part I (2)(l)). For most OT device manufacturers the first reaction is reasonable: our products already log plenty. Controllers, recorders and HMIs have event journals, audit trails and historians.

In my view that is rarely enough, for two reasons. Existing OT logging was designed to answer different questions, and it does not deliver its answers fast enough for security.

What is a security event?

A useful test: would someone responding to an attack need this event to work out who did what, when, from where, and whether it succeeded?

The last part matters. Log the attempt, not just the success. A successful login tells you someone got in. A run of failed logins tells you someone is trying, while there is still time to act.

IEC 62443-4-2, the standard for components, gives the categories. Its requirement CR 2.8 asks for audit records of access control, request errors, control system events, backup and restore, configuration changes, and events about the audit log itself. Each record carries a timestamp, a source, a category, a type, an event ID and a result. For a device, a reasonable starting list is:

• Authentication attempts, successful and failed
• User, role and permission changes
• Configuration changes, with the user and source attached
• Mode changes: run/program, local/remote, maintenance
• Firmware and software updates, including failed verification
• Changes to the device clock
• Rejected connections, TLS handshake failures, certificate problems
• Events about the log itself: disabled, reconfigured, cleared, full, or unable to reach its destination

Your threat model should refine it.

Why the operational log is not enough

Operational logs are built for alarms, trends, batch records, and operator actions recorded for accountability and product quality. Configuration changes with the user attached belong to both worlds. But operational audit trails typically record what was done and by whom. They rarely record what someone tried and failed to do, a rejected network connection, or a certificate that expired overnight. Those are the events that show an attack in progress.

They are also built for review: stored on the device or in a historian, and queried when someone needs to investigate. A security operations centre works on a different timescale. It needs to see a burst of failed logins, or the same command arriving at hundreds of sites at once, while it is happening, not the following morning. That depends on events reaching the SIEM promptly and reliably, and that integration is the part most often missing from OT products today.

So is a defrost command a security event?

A defrost cycle is routine, and so is a setpoint change. This is where OT engineers and security teams tend to answer differently, and the standards do not settle it.

CR 2.8 lists control system events and configuration changes, but does not say which control system events, or whether a setpoint counts as configuration. The CRA asks for “relevant” activity and leaves relevance to the manufacturer’s risk assessment.

Practical guidance does not settle it either. The EU-funded CRACY project’s implementation guideline (version 1.0, January 2026) is detailed on logging. It asks for every authentication attempt, successful or failed, to be recorded, and for configuration changes “such as firewall rules, access controls, certificates, and update policies”. It recommends recording the operating mode with each event. Its examples come from IT, and it does not mention process parameters.

Current products reflect that. In the published syslog event lists I have read for Siemens, Rockwell and Schneider controllers, logins, program downloads, configuration and mode changes, firmware and clock changes are all security events. An ordinary write to a process value is not. Rockwell comes closest, with events for forced I/O and for changes to constant tags. The clearest exception I found is the FieldComm Group’s HART-IP security guidance, which has the device send a syslog message whenever any configuration parameter changes, saying which one.

So on a typical controller today, a remote command to defrost is most likely recorded only in the operational log, if it is recorded at all.

Who decides?

One answer is that the device records everything and the site decides what goes where. I lean the other way: for most events, the device should decide what goes to the SIEM.

The manufacturer is the one who knows which functions can do harm if misused: forcing a defrost, suppressing an alarm, moving a setpoint past a protective limit. The analyst receiving the event does not know the device, and the integrator rarely has time to work through a vendor’s event catalogue. The CRA points the same way. Products are to be supplied with a secure by default configuration (Annex I, Part I (2)(b)), and the CRACY guideline asks for logging to be on out of the box, requiring “no manual activation from the user or administrator during setup”. A security feed that only works once someone has configured it will not be working on most sites.

That leaves the site a smaller job: adjusting categories where it needs to, and using the opt-out the CRA requires.

Timestamps join the two logs

This does not mean copying every operational event into the SIEM. Most OT systems already synchronise time. If both logs carry trustworthy timestamps, an investigator can line them up after the event. The SOC does not need your process data to reconstruct an incident; it needs timestamps it can correlate.

So send the SIEM the events that may need a rapid security response, and leave the rest in the operational log, where the people who understand it can find it.

Two consequences follow. Timestamps must be good enough to trust, ideally with a stated accuracy. And changes to the device clock are themselves security events, because an attacker who can move the clock can undermine every log it stamps.

Some events go to both

Operational logs serve operators and engineers. Security logs serve a security team. They are different people, with different questions and different response processes.

Where an event matters to both, emit it twice: once to the operational log and once to the security log. That keeps each system complete for its own audience, and neither team depends on the other’s infrastructure to see what it needs.

Open questions

• If you build controllers: can you draw the line between a protective parameter and a routine setpoint, or does that depend on the installation?
• One cabinet defrosting on schedule looks very different from hundreds of sites defrosting at 2am. Should the device report every such command and leave pattern detection to the SIEM?
• If you run a SOC with OT in scope: what do you actually receive from field devices today?

Where syslog fits

Syslog is the obvious format for the security channel. SIEMs accept it, and RFC 5424 adds structured data, so an event can carry the fields CR 2.8 asks for without inventing a format. It also defines fields for time quality, which states how far a timestamp can be trusted, and for message sequence, which lets the receiver tell when events have been lost. The CRACY guideline names RFC 5424 as a suitable structured format. It also says logging failures “should never block the PDE’s primary functions”, that outages should be handled “through queueing and retry mechanisms”, and that the device should raise an alert if logging stops.

Syslog fits the zones-and-conduits model too: devices send to a relay at the edge of the control network, which forwards over TLS to the SIEM.

SolidSyslog

SolidSyslog is an RFC 5424 syslog library for embedded devices, including legacy RTOS products that were never designed with security logging in mind. It carries whatever events the product decides are relevant, structured so the collector can route them by category. It uses no dynamic allocation, supports UDP, TCP and TLS including mutual TLS, stores and forwards events while the collector is unreachable, and numbers every message so gaps can be detected. The first compliant record costs about 5 KB of flash. It is MISRA C:2012 informed and tested in CI on every change. If you are working out how to add security logging to an existing product for the CRA, the product page is the place to start.

If you work in OT or run a SOC, I’d like to know where you draw the line between a process event and a security event.

The newsletter carries release announcements and occasional notes like this one.

Documentation · Product page · GitHub