The Cyber Resilience Act, explained: what machine builders should do now

For most consumer brands, cybersecurity rules are old news. For many machine builders, the Cyber Resilience Act (CRA) is the first cybersecurity law they have ever had to follow. If you ship a control unit, an industrial PC, or any product with a network connection, this one applies to you.

We sat down with Benjamin Becker, Director Trust and Innovation at abl solutions, to walk through it calmly. Here is the short version. The full conversation is on our podcast (in German), linked at the bottom.

What it is, and who it affects

The CRA is the first EU regulation that sets a minimum level of cybersecurity for almost every connected product sold on the EU market. The goal is simple: fewer products with easy security holes.

"Connected" covers a lot. A digital element is any network interface, so WLAN, LAN, Bluetooth even a USB port you use for updates, plus the software behind it. That includes consumer goods like smart TVs and washing machines. It also includes industrial systems: machine controls, edge PCs, IoT gateways, and the software that runs on them.

Enforcement uses a system you already know. The CE marking will include the CRA, and the same market surveillance authorities can demand fixes, force a recall, or ban a product that does not comply. Fines reach up to 15 million euros or 2.5 percent of global annual turnover for manufacturers, and up to 10 million euros or 2 percent for importers and distributors.

Two dates that matter

• 11 September 2026: reporting duties begin. You should have a reporting process and a responsible person in place by then.
• 11 December 2027: the full rules apply. New products from that date must comply. Products already on the market are exempt, unless they get a major change.

The second date sounds far off. But a product development cycle takes plenty of time on its own, so the work needs to start now.

What you actually have to do

The CRA is a way of working. It asks you to assess your product and write down your reasoning. The main themes:

1. Security by design and by default. No shared default passwords, no open ports, no outdated protocols, proper rights and role management, sensible logging, and privacy-friendly default settings.
2. A software bill of materials (SBOM). A list of every software component and version in your product, given to the buyer. When the next Log4j-style scare hits, an SBOM tells you in seconds whether you are affected.
3. A risk analysis. Identify the threats to your product, weigh them, and decide what to fix. You can use public sources like the BSI threat catalogs, and if you already run ISO 9001 or 27001, you have most of the skills in-house. As Benjamin put it, what is not documented does not exist.
4. Vulnerability management. Use the SBOM to find known and actively exploited weaknesses, and deal with them by how critical they are.
5. Update capability across the support period. You owe security updates for the lifetime you define, which for a machine can be ten years or more. Plan now for how you will patch a product many years from today.

The reporting clock is tight

Two things must be reported to ENISA through its Single Reporting Platform: actively exploited vulnerabilities and severe incidents. The deadlines are short. An early warning within 24 hours, a full report within 72 hours, and a final report within 14 days of a fix for vulnerabilities, or within a month of the 72 hour report for severe incidents. If your team has no reporting habit today, this part alone is worth building early.

How to start without overthinking it

• Get a clear yes from management, with a budget. Like any management system, it will not work without support from the top.
• Name a product security owner who connects development, product management, purchasing, support, sales, and leadership.
• Begin with an inventory. Write down your products and their properties, read out the SBOM, and understand your role in the supply chain. Then run a gap analysis, then the risk analysis.
• For real gray zones, bring in a specialized lawyer. If an incident ever puts you in front of an authority, a documented expert opinion will protect you.

One easy win: let an AI model review your existing code for security issues and outdated components. Modern AI models are good at this. Give them your most important files to check, and you will get useful flags quickly.

Why this is worth doing properly

It is tempting to do the minimum and hope nothing happens. That bet is getting worse. Attacks now hit mid-sized and smaller companies too, and a single breach is usually costly: fines, lawyers, and lost trust. The management system costs far less. Done well, the CRA also improves your products and makes them longer-lasting across their whole life.

Where Heisenware fits

Here is a point Benjamin made that stays with us. A low-code platform can look completely CRA-irrelevant, until someone uses it to monitor a bearing temperature or run predictive maintenance on a motor. At that moment, the software becomes a real part of the machine. That is why we build on current security standards, and why this topic is ours as much as it is yours.

There is a helpful flip side. The CRA now expects you to keep an eye on your connected machines and run clear reporting processes: dashboards, incident workflows, and a live view of your equipment. With Heisenware, you can build these apps quickly, without a long software project.

This article is a plain overview, not legal advice. For your specific products, get a qualified opinion.

Listen to the full episode with Benjamin Becker on our podcast Einfach Komplex (in German) on Spotify and Apple Podcasts.