Why CRA will improve cybersecurity in the EU and beyond
The power of making manufacturers responsible
At S4x26, I took the pro side of the Great Debate: Resolved: In three years, the CRA will have significantly increased OT cyberseecurity posture and reduced OT cyber risk in the EU countries.
Here’s my five-minute opening statement to the deabte. I also collected the most common arguments and misconceptions I heard during and after the debate — see this blog post. The full debate has been recorded and the video will be released on the S4 YouTube channel.
Last year ended with hackers targeting energy infrastructure in Poland.
The blackout in freezing winter was prevented, but what did investigators find?
Default usernames and passwords. No multi-factor authentication.
The Polish CERT was quick to issue recommendations for energy utilities to implement better OT security.
Case closed?
Not so fast.
Why does our search for root causes end at the asset owners?
If a car crashes because wheel nuts weren’t tightened, we don’t blame the driver. We turn to the manufacturer or the garage.
Every OT cybersecurity incident involves a product.
Someone designed it.
Someone shipped it.
Someone decided insecure defaults were acceptable.
And yet: the manufacturer disappears from the story.
The Cyber Resilience Act ends that.
Its core shift is not in the technical requirements.
It’s a shift of responsibility. Manufacturers are now legally responsible for the cybersecurity of their products. Full stop.
Now imagine the Poland incident with the CRA already in force.
The manufacturer of the involved product must file a report to authorities.
Questions arise. Maybe by market surveillance, maybe by you and me. Every customer, every security researcher, every competitor can file non-compliance complaints and ask “why didn’t the product have secure defaults implemented?”
And under CRA, that’s not just a polite question. It can trigger fines up to 15 million € or 2.5 % of global annual turnover. Or, much worse: The product is taken off market.
This is the power of making manufacturers responsible for cybersecurity.
And CRA doesn’t leave much wiggle room.
Manufacturers are responsible for their product, including third-party components.
In 2020, Ripple20 exposed nineteen vulnerabilities in a TCP/IP stack. Many manufacturers needed weeks just to answer the basic question: “Are we affected?”
Under CRA, that is indefensible. Manufacturers must know what’s in their products, must have a Software Bill of Materials, must inform users of vulnerabilities.
That also applies to open source.
In 2024, when the xz utils backdoor surfaced, we learned how many products depended on a project maintained by a single overworked individual.
Under CRA, manufacturers must perform due diligence. Rely on an open-source component? You have two options: contribute to its security — or stop using it.
That’s the power of making manufacturers responsible.
And yes, living up to this responsibility is incredibly hard. You need a foundation to build upon: standards, evaluation schemes, machine-readable advisories and SBOMs.
All things we have endlessly discussed in the last years — but now, they’re finally getting done. I’m witnessing it daily in conversations with manufacturers, at the EU Commission, and in standardization.
Manufacturers suddenly have an incentive to invest in the ecosystem that makes their products easier to defend.
This is why the CRA will not just improve cybersecurity in the future — it already does, right now.
Three years from now, incidents will still happen.
But after every incident, at least one insecure product will change for the better.
Instead of repeating the same asset owner recommendations over and over, we will work with the manufacturer to eliminate security problems at their root cause.
Not because manufacturers suddenly care more. Not because they haven’t cared before. But because the cost of not caring finally lands where it belongs.
This article was written as part of my monthly “Security Briefing for Hard Hats.” Subscribe here.
Need a helpful hand leading you through your CRA journey, from threat modeling to conformity assessment? Take a look at the Security Engineering Tool (SET).
