From CRA Compliance Anxiety to Confident Decisions

With CRA, you are responsible. That’s good news.

2025 has ended with a cybersecurity incident. In Poland, hackers attacked energy infrastructure, trying to cause a blackout while it was freezing outside.

The energy infrastructures successfully defended against the attack, there was no blackout. But of course, cybersecurity experts wanted to know what happened.

Answers came quickly: Default usernames and passwords, no multi-factor authentication. Consequently, the Polish CERT was quick to recommend energy utilities should implement better OT security controls.

The story, it seems, is clear, and very familiar. Another example of an asset owner who failed to implement cybersecurity.

Here’s the thing:

If a similar incident happens in 2028, after the Cyber Resilience Act (CRA) has entered into force, public discourse will look different.

Questions will arise. “Wait, what product was it that had default credentials?” “Isn’t that a violation of CRA requirements?”

Maybe market surveillance would ask these questions, but more likely it would be people like you and me. A customer, a competitor, a security researcher — all those are entitled to ask these questions (and file nonconformity complaints) once the CRA is in place.

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. I don’t need to explain to you that every manufacturer will likely care about suchlike questions, or, preferably: try to avoid them.

You should be more afraid of customers, competitors and the general public asking questions about your product than of market surveillance authorities.

Because the CRA is different than some regulations you may be familiar with. You don’t comply with the CRA by passing an audit or creating beautiful documentation. You comply by having a secure product and continuously prove it to your customers and everyone else who cares.

In other words: CRA is about taking responsibility, not about passing an audit.

Its core shift is not in specific requirements. It’s a shift of responsibility.

Manufacturers are now legally responsible for the cybersecurity of their products.

YOU are now responsible for the cybersecurity of your products. Full stop.

You can’t shift responsibility to legislators

How do you live up to that responsibility?

The key word is this: Risk.

You are responsible for the cybersecurity of your products, or more precisely: For the cybersecurity risk of your products. The CRA really breathes the risk-based approach out of every pore.

The CRA is part of the New Legislative Framework. This is the legal framework defining ground rules for all product regulations in the European Union — all products that need to carry a CE marking. The CE marking has existed for decades before the CRA for products like cranes, pressure vessels, sunglasses, and children’s toys.

What do all these products have in common? If they don’t meet certain requirements, they can harm users.

This isn’t a coincidence. It’s a legal prerequisite. Even if this doesn’t fit in with the common stereotype, the EU has indeed carefully crafted rules to prevent overregulation. And one of these rules is: You can only regulate product characteristics if they’re absolutely necessary to prevent risk. Everything else must be left to the free market to decide.

Back to the CRA: Consequently, its authors have taken great care to make sure there are no restrictions to product design if there’s no risk.

There are essential requirements in Annex I, but they are described generically.

Who determines how to implement essential requirements in your product?

You. Based on risk.

There is a requirement that you cannot ship a product with exploitable vulnerabilities. Who determines what an exploitable vulnerability is?

You. Based on risk.

A legacy product only falls under CRA if there is a substantial modification. Who determines what a substantial modification is?

You. Based on risk.

This isn’t bad regulation because it’s so vague. This also isn’t a bug, leaving loopholes for manufacturers.

This is a feature.

If the CRA contained very specific requirements to meet for products, this would shift all the responsibility for product’s cybersecurity to legislators (and likely suffocate all product innovation along the way).

This way, the responsibility stays with the manufacturer, with you. And it forces you to become damn good at making risk-based decisions — because that’s the only way to live up to this responsibility.

You can’t shift responsibility to standardization bodies

But what about harmonized standards? Aren’t they exactly what I have just described: A precise list of things to do for specific products in order to be compliant?

Isn’t that what the presumption of conformity for harmonized standards is all about? If a standard carries a presumption of conformity, it means you comply with CRA if you comply with the standard. Doesn’t that give you a shortcut to CRA compliance?

Well, first of all, for most products, there won’t be a harmonized standard with a presumption of conformity anytime soon, certainly not early enough before the December 2027 deadline.

But for the sake of clarity, let’s assume for a moment that harmonized standards were available in time and that there were harmonized standards perfectly tailored to each of your products.

Who determines if the presumption of conformity of a harmonized standard applies to your product?

You probably expected this by now: It’s You. Based on risk: The presumption of conformity applies if the harmonized standard addresses all relevant cybersecurity risks associated with your product.

The CRA already points that out, but the EU Commission repeated it even more clearly in their latest CRA implementation guidance — clauses 134 and 138, if you want to look it up.

When using a harmonized standard, you are still required to carry out a risk assessment. You’re still required to check whether that standard really covers all risks associated with your individual product.

The risk assessment stays mandatory if you apply a harmonized standard. And that, again, is not a coincidence.

Because otherwise, the responsibility for your product’s cybersecurity risk would shift to standardization bodies drafting standards. It doesn’t.

The responsibility for your product’s cybersecurity — more precisely, the product’s cybersecurity risk — always stays with you.

You can’t shift responsibility to suppliers

Maybe some of you remember the Ripple 20 incident in 2020. 19 vulnerabilities in a widely used TCP/IP library maintained by a small US manufacturer. It was a mess — and it took many manufacturers weeks or months to find out if they were affected.

If the same incident happens in 2028, expectations will be different. If you take months to find out if your product used a specific TCP/IP library, once again uncomfortable questions would arise:

Why does it take this manufacturer so long to find out? Don’t they have a SBOM as the CRA requires? Why haven’t they published an advisory and patch yet for this vulnerability? Don’t they consider it exploitable? Are they even allowed to still ship their products that way?

“But it’s really hard to find out” is no longer an excuse. Manufacturers are responsible for the cybersecurity risk of their products — and that includes third-party components. If you’re responsible, you must know which third-party components you have BEFORE one of them blows up.

Otherwise, you would shift the responsibility for the cybersecurity risk of your product to your suppliers. You can’t.

Who decides if you can still use components like that TCP/IP library from a small supplier? You would have guessed it: It’s you. You decide. Based on risk.

Before you freeze in shock, I would encourage you to shift your attention to constructive ways to manage that risk. Of course, it’s unrealistic to expect that you will be able to find and patch all vulnerabilities in all your third-party components.

But you can select third-party components carefully, open-source or not.

For commercial components, you can pass CRA requirements on to your suppliers. For open-source components, you can support its maintainers to build up the infrastructure to find and address vulnerabilities, or even become a contributor yourself.

And, back to our Ripple 20 example: you can invest into the ecosystem needed for passing on SBOM and vulnerability information up and down the supply chain fast. The CRA gives you a good financial incentive to do that, because you and your supply chain, you now sit in the same boat. You all have the responsibility for all components your products use.

Nuances to your responsibility

You see it clearly by now: CRA is about risk. No matter what you do, you are responsible for the cybersecurity risk of your products.

If you wonder if you can do something and still be compliant with the CRA, just imagine the CRA asking back: If you do the thing you’re wondering about — have you addressed all cybersecurity risks associated with your product?

If yes — you’re good to go, happily showing off your CE marking. If no — your compliance fails.

Before you jump at me now: I know it’s not always that easy in practice. Let’s look at an example that’s giving many OT manufacturers a headache, and that’s well-suited to add some nuance: Insecure legacy protocols.

We all know much of OT still operates on insecure legacy protocols: No authentication. No encryption.

The problem has been well-known the latest since Dale Peterson’s Project Basecamp back in 2012, and earlier this year, CISA has just released a whitepaper “Why Johnny Can’t Authenticate” making clear this is still a problem. The paper also points out how manufacturers and asset owners can both contribute to solving the authentication problem, which is worth a read — but not our topic here.

The fact is that insecure protocols are still status quo in OT.

Now, who decides if you can sell a product using an insecure legacy protocol? I’m sure you know the answer: Of course it’s you. Based on risk.

And of course it’s not that simple. Because of course, there’s risk associated with insecure protocols. Depending on where exactly the component is used, even considerable risk.

Does this mean you can’t sell OT products with insecure legacy protocols?

No. It just means you’re responsible for the risk. Being responsible means: You need to assess and address it.

Once again, before you freeze in awe, let’s look at what your options are.

Ideally, addressing risk means you implement essential requirements that fix the risk. Which in this case means: You implement a secure protocol instead of the insecure one.

But you can take into account the operational environment of your product, and constraints that might come up. That’s the first important nuance to your cybersecurity risk responsibility.

One constraint could be interoperability. Maybe the older protocol is needed because your product is meant to talk to existing components in a plant which only understand that legacy protocol. In that case, it still stays your responsibility to address the risk — but maybe not with an essential requirement, but taking compensating or alternative measures. The CRA never said that explicitly, but the EU Commission’s implementation guidance does; see clause 29 if you want to look it up.

But: the responsibility for the cybersecurity risk of your product stays with you over the lifetime of the product. So if there’s an interoperability constraint right now, this doesn’t necessarily mean it will exist for all times. It’s your responsibility to monitor that risk and constraint and adjust accordingly.

As it became clear when we talked about new vulnerabilities coming up, responsibility for a product risk isn’t a do-and-forget effort, but something you need to do continuously.

The second nuance to your cybersecurity risk responsibility is the intended purpose of your product.

You could also address your legacy protocol risk by defining the product’s intended purpose more precisely. Maybe the risk associated with the legacy protocol would be lowered if you could make sure the component was only used in industrial automation settings and not in, let’s say, building automation where it’s more likely to interact with commercial off the shelf IT components connected to the internet.

Bottom line:

You can’t shift responsibility to customers or insurers

At this point, we need to make one thing abundantly clear: Being responsible for the cybersecurity risk of your products means that you do something about the risk until it’s lowered to an acceptable level.

This has two parts. First: you need to DO something. If there is a cybersecurity risk for your customers, you cannot just accept it and move on.

Remember what we said about the New Legislative Framework which defines why CE markings exist on products? It’s about ensuring the product user can use the product safely.

Who decides what an acceptable level of risk is? You do, and you do it based on risk. BUT: not based on your own organization’s risk appetite, but from your customers’ perspective. You need to make sure the risk for them is lowered to an acceptable level. Residual risk is fine, but it implies you have DONE something before. You cannot accept risk on behalf of your customers, which would mean shifting the responsibility to your customers.

You can’t. You are responsible for the cybersecurity risk of your products.

So being responsible for the cybersecurity risk of your products means that you DO something about the risk until it’s acceptable — emphasis on DO.

The second part places the emphasis on YOU: Being responsible for cybersecurity risk of your product also means that YOU do something, emphasis on YOU.

If the only measure you take to address risk is have your customers do more, think again. Because that again would be shifting responsibility of the cybersecurity risk to your customers.

You also cannot transfer the risk by taking out cyber insurance. This would mean you shift the responsibility to an insurer, which, as you know by now, is not the CRA’s intention. The responsibility for the cybersecurity risk of your product always stays with you.

You are free to decide how these cybersecurity risks are best addressed, but they are your responsibility to address. YOU must DO your part.

Bottom line:

Communicating risk

There is one last aspect that matters when we talk about taking the responsibility for cybersecurity risk.

Let’s look at the options for addressing the legacy protocol risk again:

If you take compensating measures, that’s fine — as long as you communicate it clearly to your customers.

Maybe some of your compensating measures can’t implement in the product but need to rely on your customers to implement them in the product environment. That’s fine — as long as you communicate those expectations clearly.

If you decide to restrict your product’s intended purpose, that’s fine — as long as you communicate it transparently to your customers and it is in line with how they actually use the product (reasonably foreseeable use), you’re living up to your responsibility.

Also, there will be residual risk. That’ fine — as long as you communicate it clearly to your customers.

Transparent communication is one integral part of being responsible for cybersecurity risk.

In other regulations, compliance is a thing between you and some authority. Customers or the public typically don’t notice if you’re not compliant.

Under the CRA, compliance is public. Taking responsibility for your product’s cybersecurity also means taking responsibility for communicating cybersecurity to customers and suppliers.

Bottom line:

You need to become a good risk-based decision-maker

If we look at all this, it becomes clear that the CRA is all about putting the guardrails in place to make sure you, the product manufacturer is responsible for their product’s cybersecurity. And there’s no way of wiggling out of this responsibility.

Whenever you try to shift responsibility to legislators, standardization bodies, suppliers, customers, or insurers….it backfires.

The upside is: As soon as you’ve understood this, your CRA journey is becoming much simpler.

If you have a difficult question regarding CRA implementation, always imagine the CRA asking back: “have you addressed all risks?”.

You’re free to do anything….as long as all cybersecurity risks for your products are addressed. That’s a powerful tool in your hands.

So your number one priority for CRA implementation should be to become a successful risk-based decision maker — and communicator.

So let’s turn you into one.

This is how you take responsibility: 6 steps

First, let’s define what we mean by successful: You’re successful at making risk-based CRA decisions if you achieve three things:

• You address all risk.

• You comply with CRA.

• You find the leanest possible requirements to do both — the most economical way to your CRA compliance.

There are three success factors that help you achieve this:

Success factor 1: Understanding business and cyber context

It’s clear that you need to understand your product (the cyber system) to understand cyber risk.

But the first step is also understanding the business context — the business context of your customers, that is. This makes sure your risk-based decision-making stays in line with what the CRA demands. Remember: It is all about making sure your customers can use your products safely.

Therefore, the first success factor is understanding not only the cyber system, but also its context.

If you can clearly answer the question how the cyber system can contribute to the (real-world) risk for your customers, you can prioritize risks that matter. These are typically only a subset of ALL cybersecurity risk (an endless list). Thus, having a clear view of your business and cyber context saves you lots of work.

Success factor 2: Systematic risk logic

As you have learned today, the CRA doesn’t give you a suck-it-up-or-die list of cybersecurity requirements to meet. It gives you essential requirements you must consider, maybe there are additional harmonized standards you can use if you want. But ultimately, you have to decide which measures you need to take. Based on risk.

This means that a systematic risk logic is key to identifying only the security requirements that matter — for your product’s cybersecurity, and your CRA compliance. A systematic risk logic draws a clear line of argumentation from business context over cybersecurity risk straight to cybersecurity requirements. The clearer your risk logic, the leaner your cybersecurity requirement list.

Success factor 3: Confident, explainable compliance

As we have learned before, taking responsibility for cybersecurity risk also includes communicating it transparently. To your customers, to market surveillance upon request, or in case of a third-party conformity assessment, conformity assessment bodies.

Of course the CRA requires written evidence for your compliance.

The written evidence is critical to make sure your systematic risk logic is understood, and therefore your path to legal certainty. The good news: If you have mastered success factors 1 and 2, you have a solid foundation: You know you’re addressing the real-world risks the regulation asks for, and you have a clear line of argumentation from these real-world impacts to your security measures.

Only thing you need to make sure: To have it documented in a way authorities (and yourself in 3 years) can easily understand.

Next, I’ll give you a clear sequence of six steps that out of experience work best to nail these three success factors. Here’s your six steps to becoming a successful risk-based decision-maker:

Step 1: Business goals

It all starts with the Business Goals. This is the “business” part of success factor 1.

Most important: Damage scenarios. These real-world impacts that matter for your customers are typically only one to two hands full and have nothing to do with your cyber systems. Don’t overcomplicate it.

The damage scenarios are your first of five filters to make sure you focus on the requirements that matter. Set them clearly, and you save lots of efforts down the road.

You will also set protection goals and your risk matrix in this step.

Step 2: Cyber system model

This is the “cyber” part of success factor 1. You need to clearly define which cyber systems are in or out of scope and know how they connect to your business context.

In my experience, thinking in functions / use cases is a good way to describe the cyber system while maintaining the connection to the business context. Also, don’t forget to model humans that interact with your system. A good example for a function is “programming a PLC”.

The cyber model should fit on one page and you should be able to take in the whole system at a glance. This is NOT the drawing your admins use to build / operate the whole cyber network. It is the drawing that you will later use to identify cyber attack scenarios.

Step 3: Business impact

This is the first step for success factor 2, and it combines business and cyber contexts. You want to systematically answer the question which parts / functions of the cyber systems can lead to which business impact if integrity, availability, or confidentiality are violated.

Don’t give in to the temptation to analyze business impact for each cyber asset individually. Looking at cyber functions or services is more suitable. You will find that it’s much easier to answer the question which business impact a failed cyber function or service has than a failed cyber asset.

This is your second of five filters to make sure you end up with the leanest-possible requirements: It rates your function criticality and helps you focus on your most critical functions, and for each function, on the most critical protection goal. For example, the PLC programming function is critical — but only its integrity. If it’s not available for a while, that’s not critical.

Also, you only look at worst-case impacts here, and you don’t care about how they can be brought about.

Step 4: Cyber risk assessment

This is where your systematic risk logic unfolds — but the three steps before are essential, because otherwise, your risk logic begins in the cyber system and fails to draw the connection to real-world / business impact.

The risk assessment includes selecting the most relevant business impacts, modeling threat scenarios detailing how abusing your cyber system can lead to one of these impacts, assessing likelihood and impact resulting in risk, and defining the security requirements that mitigate the risk.

Now you see why your first two filters — the most relevant damage scenarios and the most critical functions — were so important: Threat modeling can be a real time sink. There’s always one more threat to model. If you feed a large number of damage scenarios and functions into your threat model, efforts quickly explode.

Also, there are two more filters built into the risk assessment making sure you end up with the leanest-possible security measures: So far, we’ve primarily looked at impact. Now that you have the likelihood assessed, you can focus on the most likely risk scenarios — and of course the highest overall risk — and choose precisely the most effective security requirements addressing each risk scenario step you have identified during threat modeling.

The result of step 4: you are able to trace each security requirement all the way back to the cyber system function and your relevant business goals. This is the foundation to confidently explain any security requirement you have or have not selected. This is how you successfully make and defend risk-based cybersecurity decisions.

One more remark on threat modeling. Threat modeling and risk assessment are often used interchangeably, but now you can clearly see the difference: Threat modeling is a part of a risk assessment. An important one — but not the whole story. Making a risk-based decision requires threat modeling, but it also requires the business context before threat modeling and the security requirements after it.

If you begin your threat model in the bits and bytes of your cyber system, you will not only waste time, but also fail to live up to your CRA responsibility.

Because, remember: The core of the CRA is that you are responsible for addressing the cybersecurity risks of your product — the risks for your customers. You need a systematic line of argumentation from the risk of your customers all the way through to the cybersecurity requirements and measures you chose.

Think of your customers’ damage scenarios and your security requirements as the bookends for your risk-based decision. Remove one of them, and your threat model will be worthless for CRA compliance.

Step 5: Compliance check

The last success factor is confident compliance.

After Steps 1–4, you can be confident you have addressed the relevant risks for CRA.

Step 5 has the simple goal of making you absolutely confident you have considered all essential requirements. “Considered” doesn’t necessarily mean you have implemented them all, but at a minimum, you need to look at them one by one and decide if they apply to you. If yes, you want to document which of your cybersecurity requirements contribute to its implementation. If no, you want to document why not. Think of it as a completeness check.

This is also your last of five filters to ensure you end up with the leanest-possible security requirements. There’s a reason why I recommend placing the compliance check at the end of the risk assessment, and not at the beginning. Here, you should only end up with an absolute minimum of additional security measures: only those that are truly indispensable for compliance.

Step 6: Reports

The risk-based decision is now made — but there is a good reason why your path to becoming a successful risk-based decision-maker doesn’t stop here: Your excellent risk-based decision is not worth much if you cannot confidently explain it to authorities and your customers. Remember, your responsibility for the cybersecurity risk of your products also includes the transparent communication of this risk.

You need technical documentation for authorities and information and instructions to the user for your customers that meet all of the formal CRA requirements and that translate your crystal-clear line of risk-based argumentation into a language authorities and your customers will understand.

A good report is one you proudly pull up when asked, because all your cybersecurity decisions are well thought-out and logical, and you are confident you meet all regulation requirements.

This doesn’t appear out of nowhere.

You need to know which real-world risks CRA requires you to address (step 1).

You need to be confident you have sufficiently understood your cyber system (step 2).

You need to know how your cyber system can contribute to the real-world risks (step 3).

You need to have a clear line of argumentation explaining which security requirements you applied to mitigate that risk (step 4).

And you need to be confident you haven’t overlooked any essential CRA requirement (step 5).

But if you have all this in place, you will know what to put into your report in step 6, and confidently explain every word in it.

You will even be able to put your entire risk-based decision on one page. Here’s an example:

You see the relevant damage scenarios — your customers’ risk.

You see your cyber system; we’re looking at the PLC programming function here.

You see the risk, including the threat model in these three red steps, and the assessment of likelihood, impact, and risk.

You see security requirements you have taken — and where in your cyber system you need to implement them.

And you see the CRA essential requirements that address this risk.

CRA makes you responsible for the cybersecurity risk of your products. Full stop. If you can provide a crystal-clear line of argumentation like this for all your cybersecurity risks and do your part in addressing them — you are living up to this responsibility.

That way, CRA compliance becomes really simple.

Have courage to use your own risk assessments

You don’t comply with CRA by creating documents and passing audits. If you look at CRA as something for which you need to tick off checklists, create documents and pass audits, it will always be overwhelming and bureaucratic to you. No harmonized standard will be specific enough. No commission guidance will be practical enough.

The only way to solve this is to change your attitude. You will get a grip on your CRA compliance journey once you accept that you need to take responsibility for your product’s cybersecurity. Full stop.

Nobody will tell you what exactly to do to be above the bar.

Nobody will tell you what’s the right security for your product.

Just as nobody is telling you what features matter most in your product.

Once you accept that cybersecurity will ultimately stay your responsibility, you can calm down. CRA compliance becomes simple. You just need to become a successful risk-based decision-maker. Focus on making these risk-based decisions, not on compliance.

Ironically, nothing makes you more compliant than good, transparent, well-documented, risk-based cybersecurity decisions.

So you have no choice but do what responsible people do since 1784: Have courage to use your own reason.

**“Have courage to use your own reason” ** — Immanuel Kant in “Answering the question: What is Enlightenment?”, Berlinische Monatsschrift, 1784

Or for CRA: Have courage to use your own risk assessment.

This article was written as part of my monthly “Security Briefing for Hard Hats.” Subscribe here (English) or here (German).

With the Security Engineering Tool, we have built a software that guides you through the 3 success factors and 6 steps to comply with any EU cybersecurity regulation.**