The Cyber Resilience Act (CRA) is an EU regulation covering every digital product that is able to interact with another device or a network. For machine builders, that means connectivity features such as remote support, a cloud connection or a Bluetooth interface trigger obligations, including cyber risk assessments, an incident response team and a CE declaration of conformity.
Key Takeaways
- The Cyber Resilience Act applies to every digital product that is able to interact with another device or network. It kicks in as soon as that capability exists, not only once the product is actually connected.
- Companies that bring in external consultants and CISOs early get better terms, because demand from the many affected companies is pushing up market rates for security experts.
- Machine builders that use remote support, cloud connectivity or over-the-air updates are just as affected by the CRA as pure software companies, because what counts is whether the machine is connected.
- The biggest obstacle to CRA compliance usually isn’t the development team, which tends to back the topic, but management, which balks at the extra cost, even though a missing CE declaration of conformity blocks sales in the European market.
- A well-kept security backlog of known weaknesses makes the cyber risk assessment easier to start, because the team can judge right away which weaknesses actually matter when a vulnerability is reported.
Who the Cyber Resilience Act Applies To
The Cyber Resilience Act applies to every digital product that can interact with another device or a network. What counts is not whether a product actually communicates, but whether it is able to.
That puts almost anything with software inside under the regulation: from the smart coffee maker and the washing machine with an app to the networked industrial machine. A woodworking machine hooked up to the customer’s network or the internet is covered just as much as a Bluetooth caliper or a barcode scanner with a wireless connection.
There are exceptions, but they are narrower than they look. Pure web services and websites that aren’t embedded in an app are out of scope. Open source is partly exempt. But as soon as you use open source software in your company, the responsibility is back with you. Expect changes here, too, over the long run.
Why Connectivity Turns Machine Building into a Software Topic
Once a machine goes online, security becomes mandatory. That holds even in places where software was long seen as a side issue.
In traditional machine building, software was often a necessary evil. That is exactly what’s shifting. Networked machines, data collection in the cloud and remote support change the picture completely. For some machines, support now happens exclusively through remote solutions, and nobody has to drive out anymore. That saves effort, but it also means the machine is permanently connected to the internet.
That permanent connection opens up concrete attack surfaces: operating system, firewall, antivirus software, all of it has to be thought through. Christoph Ranalter, who is responsible for quality at a machine building company in Tyrol, puts the driving force down to user convenience, without any drama:
“Why can I control my fridge remotely? It’s a convenience. And it’s the same with our machines.”
(Christoph Ranalter)
For a small carpentry shop, the benefit lies less in productivity than in information: seeing how far along the machine is, noticing that material is running low, and planning for both on the way to the machine.
How to Find Out Whether the Regulation Affects You
The first step is a screening, ideally with an advisor at your side. When it comes to legislation, and to a later self-assessment or audit, the classification has to be right.
The screening answers two questions: Does the regulation affect us? And how much time do we have? For a manufacturer of networked machines, the first answer is almost always “yes.” The second answer shifted during the legislative process. Originally, the plan was twelve months after adoption to set up the incident response team and meet the reporting obligation to ENISA. The final regulation turned that into 21 months: the Cyber Resilience Act has been in force since December 2024, the reporting obligations apply from September 2026, and the remaining obligations from December 2027.
More time doesn’t mean less pressure, though. Many companies will be taking action at the same time, and the number of security experts on the market is limited. If you sort things out early with partners and outside support, you lock in capacity before rising demand drives up day rates.
The CRA and NIS2 Often Come as a Package
Anyone working on the Cyber Resilience Act soon runs into NIS2. The two topics often come up together, even in companies that don’t think they’re affected at first.
The usual reflex goes: We’re not critical infrastructure, so NIS2 doesn’t concern us. But extending the scope to “essential” and “important” entities draws the circle much wider. Manufacturing is broadly covered. Even supplier relationships can matter: if a company supplies a hospital and works with it on the software side, NIS2 can apply.
In practice, the two topics can be bundled. An external CISO as a service can drive NIS2 first, and the same person can take on CRA consulting as well.
A Pragmatic Roadmap for CRA Compliance
A sensible order starts with training, moves on to the cyber risk assessment and ends with the incident response team. There’s a clear reason for that order.
Only once the risk assessment is in place for every machine can you evaluate a reported vulnerability at all. Without that basis, you can’t tell whether a vulnerability is urgent or can be ignored.
The rough timeline looks like this:
| Phase | Content |
|---|---|
| Start | Training for developers and software architects |
| Next | Cyber risk assessment for all machines |
| Following year | Set up the incident response team |
| In parallel | External CISO handles NIS2, advises on the CRA |
The incident response team raises the staffing question: hire new people or train the ones you have. Since good security experts are scarce and expensive, it often comes down to training in-house. The price is speed. If you move developers into training and new responsibilities, you lose noticeable momentum on features.
Developers Usually Have the Right Mindset Already
The bigger hurdle usually sits in management, rarely in the development team. Among developers, security more often meets agreement than resistance.
Many bring prior experience and training from university. Statements like “hard-coded passwords aren’t cool” aren’t new material to learn, they’re already an accepted attitude. What’s missing is routine: in teams like these, usually nobody has ever carried out a risk assessment themselves. The mindset is right, the process still has to settle in.
In management, the discussion revolves around money. More effort for the same machine price is a hard sell. An honest calculation helps: without CRA compliance, some of the first machines may not be sellable at all, because they’re tied to funding guidelines that require this standard. And since a CE declaration of conformity is at the end of the road, in the extreme case the whole European market is at stake.
A Security Backlog Instead of a Fire Alarm
Keeping a running security backlog makes more sense than waiting for the first penetration test. Weaknesses spotted during development go there, together with the question of how much damage they could cause.
One example is the inter-process communication between the PC software and the machine controller. That communication should be encrypted to protect its integrity. The consequence of missing encryption, such as a man-in-the-middle attack, is technically conceivable but unlikely at the end customer’s site. An attacker would first have to gain access and then invest a lot of time.
That risk assessment is exactly the point. A backlog keeps issues like this visible without every theoretical weakness blowing up a sprint right away. When the regulation forces the effort, the backlog can be worked through in a targeted way, with the extra time it needs.
Which Tools Help with Secure Development
Static code analysis is a realistic starting point, because many vendors of these tools now build in security guidelines. The trend is clearly toward expanding these checks further.
There are also tools that warn you right in the IDE, for example when a package you use has a vulnerability, and point you straight to the version with the fix. Tools like these kick in early, while you’re still writing code.
One caveat remains: not every tool covers every environment. In a company with a big Windows world and a big Linux world, some tools only work on one side. If you support several platforms, check the coverage before you choose, instead of being dazzled by the feature list.
Software Becomes the Differentiator
In machine building, competition is shifting from mechanics to software. Plenty of suppliers can weld sheet metal, including in the low-price segment. In a high-cost location like Tyrol, you can’t win on price.
That leaves quality and innovation. And most new features today either are software or need software to work. That also raises the standing of software in industries where it played second fiddle for a long time.
So the advice to anyone who comes into contact with the topic is clear: get to grips with it early, because it’s coming either way. Whether the CRA will lose its buzz over time, as the GDPR did, remains to be seen. The cyber damage won’t, and better tools make attackers more capable too.
Frequently Asked Questions
Does a machine fall under the Cyber Resilience Act even if its network functionality is never used?
Yes. What matters is the ability to interact with another device or network, not the actual connection. This means that almost anything containing software falls under the regulation: networked industrial machines as well as a Bluetooth caliper or a barcode scanner with a wireless connection. For machine builders, even remote support or a cloud connection is enough to trigger compliance obligations.
Which digital products are exempt from the Cyber Resilience Act?
The exemptions are narrower than they appear. Pure web services and websites that are not embedded in an app are excluded. Open-source software is partially exempt, but companies that use open-source software in-house remain responsible for it. In the long term, changes to these definitions are to be expected; no one should count on a permanent exemption.
How much time do companies have to establish an incident response team?
Originally, companies were given twelve months after the law’s enactment to form an incident response team and fulfill their reporting obligation to ENISA. The final regulation extended this to 21 months, and the reporting obligations apply from September 2026. This does not mean there is less pressure: Many affected companies are implementing measures simultaneously, and the availability of security experts on the market is limited.
Does NIS2 also apply to businesses that are not critical infrastructure?
Often, yes. The instinct to assume one is not affected simply because one lacks critical infrastructure falls short, because the expansion to include essential and important entities significantly broadens the scope. The manufacturing sector falls broadly under this category. Supply chain relationships can also be relevant: Anyone who supplies a hospital and collaborates with it on software matters may fall under NIS2.
In what order should CRA measures be addressed?
It makes sense to start with training for developers and software architects, followed by a cyber risk assessment for all systems, and then, in the following year, the establishment of an incident response team. The reason for this sequence: Only once the risk assessment is complete can a reported vulnerability be evaluated at all. Without this foundation, it remains unclear whether a vulnerability is urgent or can be ignored.
What is the most common reason for the failure to implement security requirements in companies?
Rarely is it the development team’s fault; it’s usually management. Developers come with the necessary background knowledge: hard-coded passwords have long been considered unacceptable in their circles; what’s missing is routine, since often no one has actually conducted a risk assessment themselves. Among management, the discussion revolves around the additional effort required while the price of the machines remains the same. On the other hand: Without a CE Declaration of Conformity, the entire European market could be blocked in extreme cases.
What are the benefits of a continuous security backlog compared to a penetration test?
The backlog keeps vulnerabilities visible that are identified during development, each accompanied by an assessment of the expected damage. Example: unencrypted inter-process communication between PC software and machine control systems. A man-in-the-middle attack is technically conceivable, but unlikely for the end customer because an attacker would first need access and would have to invest a lot of time. Thus, not every theoretical vulnerability derails a sprint.
What tools help with secure development, and where do they reach their limits?
Static analysis is a realistic starting point because many vendors of such tools have integrated security guidelines. In addition, there are tools that issue warnings directly within the IDE if a package being used has a vulnerability, and immediately specify the fixed version. The limitation lies in coverage: In organizations with both extensive Windows and Linux environments, some tools only work for one platform.
