Part 4 of 5 in our Security in plain words series. The EU's Cyber Resilience Act asks for outcomes, not mechanisms. Here is what those outcomes mean for the controller inside your machine, and the questions worth asking of it.
A law about outcomes
The Cyber Resilience Act is the EU's law on the security of products with digital elements: hardware and software that connect to a device or a network. For a machine builder selling into Europe, a connected machine is likely to fall within it, and the controller inside is where most of its digital elements live.
The Act is written as outcomes rather than mechanisms. It does not say which login system to use or how to encrypt a link. It says what the product must achieve, and leaves the manufacturer to decide, from its own risk assessment, what is appropriate for that product.
The Act, Regulation (EU) 2024/2847, comes into force in stages: its reporting duties first, then its full requirements - secure defaults, security updates and a software bill of materials - from December 2027, as we wrote in Sense, Decide, Act. A machine designed today will still be on sale after that, which makes the requirements a design question now rather than a paperwork question later.
One note before going further: this is a plain-words reading for engineers and managers, not legal advice. Your own advisers will tell you how the Act applies to your machines.
What the outcomes mean for a controller
Read with a controller in mind, the Act's main outcomes come down to a short list.
Secure by default
The product ships in a secure state, without the buyer having to harden it first. Above all, that rules out a default password shared across every unit - the first thing any secure-by-default rule removes. The Act also asks for a way to reset the product to its original, secure state.
Access that is controlled and accountable
Unauthorised access is prevented by appropriate controls: authentication, and identity and access management. In practice that points to a credential for each person, a role that limits what they can do, and a way to withdraw one person's access when they leave. Security-relevant activity - logins, refusals, changes - is recorded and can be monitored.
Few doors, and harm contained
The attack surface is kept small, and an incident is kept from spreading. Every way in is there on purpose, and trouble in one part does not open the rest.
Security updates for the support period
Vulnerabilities are fixed through security updates for the product's support period, delivered without delay and free of charge.
Knowing what is inside, and acting on what is found
The manufacturer keeps a software bill of materials - a list of every software component in the product - so that when a flaw is found in one, it knows at once which products carry it. It also gives anyone a way to report a vulnerability, and has a process to fix and disclose it.
Questions to ask of the controller inside your machine
Most of these outcomes land on the controller, because that is where the machine's software, network doors and logins live. The machine builder answers for the whole machine, so the controller's supplier should make that easier, not harder. Questions worth asking:
- Does it ship with no default or shared password, and can it be reset to its original, secure state?
- Does each person get their own credential and role, and can one person's access be withdrawn?
- Is security activity recorded in a form you can hand to your customer's security team?
- How are security updates delivered, for how long, and do they cost extra?
- Will the supplier provide a software bill of materials, and how does it handle a reported vulnerability?
- Is the security the Act requires part of the product, or sold as an option?
How we approach it in CATIM Nimbus
The approach in CATIM Nimbus is designed to meet the EU Cyber Resilience Act's requirements. A few principles carry it:
- No shared logins. Every service and AI agent has its own credential and role, and our design gives every person theirs too, as part 3 of this series describes.
- Named doors. Every way in is a named, deliberate door. Only systems the site has named and let in reach the controller itself, and cloud connections go outbound only.
- The baseline in every unit. The security the Act asks for is part of the product, never an extra. A licence may add capabilities, but it never takes security away and never holds back a security update.
- In the design from the start. Secure defaults, security updates and a software bill of materials are designed in, not bolted on at the end.
Each machine builder makes the case for its own machine. Our part is to make the controller a component you can build that case on.
Start with the controller
The Act turns security from a feature into a property of the product, carried for as long as the product is sold and supported. For a machine builder, the choice of controller is the earliest and simplest point to get that right.
If you build machines for European customers and want to talk through what the Act means for the controller inside them, get in touch.
About CATIM. CATIM - Creating Automation Technology In Motion - empowers people to engineer automation solutions that solve hard technical problems. CATIM Nimbus, the CODESYS edge controller with advisory AI, is the next generation of the Nimbus platform it has built since 2019.