How to answer (almost) every difficult CRA question
A simple framework, based on the EU commission’s CRA guidance
The EU Commission has published a draft guidance for the application of the Cyber Resilience Act (CRA). It’s open for comment until April 13, 2026.
The guidance is the result of the EU Commission trying to find pragmatic answers to hundreds of questions on CRA by different stakeholders.
It really is a pragmatic, helpful document. While you read it, you get a solid understanding of how the CRA is intended to work. The authors patiently repeat the same lines of reasoning again and again, consistently applying it to all the difficult real-life scenarios that come up when trying to apply the CRA.
I could now summarize the most important answers here, but for 70 pages of dense guidance, this would become a boring and lengthy read.
Rather, I’d like to teach you the basic principles the guidance masterfully lays out in almost every answer, and then show you how much sense the answers make once you’ve understood the basic principles. It truly becomes a simple framework to answer (almost) any difficult CRA question.
I’ll demonstrate that using the framework for some difficult CRA questions answered in the guidance.
As a bonus, the end of the article has a list of pragmatic answers that go beyond the introduced framework, but the answers are important to know.
3 Question Framework: How to answer every difficult CRA question
I’ve said it before and I’ll say it again: The CRA lives and breathes the risk-based approach. If the CRA original text hasn’t convinced you this is true, do read the EU commission’s application guidance.
Once you’ve read the first dozen pages in the guidance, a pattern becomes apparent.
You can answer almost every difficult CRA question using the same pattern.
You are in compliance with the CRA if you ensure an appriate level of cybersecurity for all products with digital elements — or, first really helpful concretization in the guidance: for all products that convey digital information — we’ll get to this later.
This is of course not specific enough. What is an appropriate level of cybersecurity?
It boils down to a 3 Question Framework:
- Are all cybersecurity risks addressed…
- …taking into account the intended purpose and reasonably foreseeable use?
- Does the product meet all essential requirements (Part I) if applicable and necessary based on questions 1 and 2?
Important: In that order. The primary goal of the CRA always is to address risk, NOT to meet specific essential requirements. You are compliant when you addressed all risks, NOT when you’ve met each of the specific essential requirements. (This also applies when you use harmonized standards). I’ll provide more details later.
Before, let’s add a few clarifications from the draft guidance to each of the three framework questions.
Cybersecurity risk
For cybersecurity risk, the guidance makes it clear that risk treatment according to the CRA is a bit different from what organizations are used to. Normally, risk is evaluated against an organization’s risk acceptance criteria. Under CRA, risk is evaluated against a regulatory threshold (see above: the appropriate level of cybersecurity for the product). This has a few implications (clause 141 in the draft guidance).
- risk according to the CRA is risk for the product user, not the manufacturer.
- risk acceptance is not an option, at least not at the discretion of the manufacturer. The manufacturer’s economic or strategic decisions or risk appetite does not matter for CRA. (clause 142, 143)
- risk transfer is not an option. The idea of the CRA is that every entity in a product’s supply chain does their part. (clause 145)
- having a residual risk is normal and okay. (clause 143)
Intended purpose
The intended purpose and reasonably foreseeable use appear in numerous places of the guidance. In combination with the operational environment and potentital constraints, they set the scope for the cybersecurity risk assessment.
At the same time, the intended purpose definition is a tool for addressing risk. The guidance explicitly names a “more precise definition” of the intended purpose as an option to address cybersecurity risk. (clause 144)
Also, a few more concepts matter for describing the product and its use as a basis for the cybersecurity risk assessment:
- core functionality: the guidance clearly states that each product should have only ONE core functionality. The core functionality is are the features and technical capabilities “without which the product would not be able to meet its intended purpose.” (clause 124). The core functionality determines if the product falls in one of the important or critical categories and thus needs to undergo a third-party conformity assessment. Once you’ve defined the core functionality, there is no more ambiguity even if your product has several ancillary functionalities.
- ancillary functionality: all other features and capabilities next to the core functionality
- operating context, conditions, and constraints: all three matter especially for complex products consisting of many interacting components and typically built over a long timespan — for example: industrial plants. The CRA guidance explicitly states that operating context, conditions, and constraints should be documented alongside the product’s intended purpose. They may (and must) be taken into account in the risk assessment and might lead to certain essential requirements not being compatible with the product. (clause 28, 29).
The guidance also makes it clear that the risk assessment must take into account risks that originate outside the product / in its operating environment (clause 152). Small, but important addition: users and operators must also be included in the risk assessment (Figure 9). - both CRA and guidance imply that both internal components and 3rd party components as well as remote data processing solutions need to be considered when describing and risk assessing the product.
Essential requirements
The essential requirements are all requirements in Annex I (both parts). The guidance also introduces the concept of alternative or compensatory or alternative measures (clause 29) that can be applied if a risk exists, but the relevant essential requirement cannot be implemented for example due to interoperability reasons.
This is an important addition since compensatory measures weren’t explicitly mentioned in the CRA original text, leaving many manufacturers insecure about how literal they need to take the essential requirements.
There’s an interesting portion in the guidance addressing the first essential requirement in Part I, stating “Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.”
This essential requirement (1) has sometimes been interpreted as “manfacturers must follow and document a secure design / secure development process”.
The guidance makes clear that this is an overinterpretation. Rather, this first requirement was intended to be a fallback in case that fulfilling the other essential requirements doesn’t address all cybersecurity risks. In these cases, additional measures beyond the other essential requirements are necessary. (clause 150).
Thus, this passage in the guidance clearly shows that CRA is, above all, about addressing cybersecurity risk, rather than just ticking off the more specific essential requirements (2) (a) to (m).
This leads us to the following simple “how to CRA” scheme (for the essential requirements Part I, excluding the vulnerability handling and reporting obligations which mostly don’t trigger as many questions).
It turns the three framework questions into a simple workflow, containing the same three basic elements
- risk,
- intended purpose, and
- essential requirements,
but setting them in relation with each other and adding the details and context introduced earlier:
To comply with CRA, describe the product and its use.
Make sure to include internal and 3rd party components, remote data processing solutions, users and operators, intended purpose specified by the core functionality, ancillary functionality, reasonably foreseeable use, as well we operating context, coniditions, and constraints.
This seems like a long list, but if you’ve explicitly define all of the above, CRA interpretation for your product becomes much more straightforward.
Now, for this product as a whole, you must ensure an appropriate level of cybersecurity. You find out what that means by performing a risk assessment and then addressing all risks. These are your options:
- defining intended purpose more precisely (mostly that means: restricting it)
- implementing essential requirements (if they are applicable to the product and necessary to address risk)
- implementing compensating or alternative measures (if essential requirements cannot be met because of operational constraints such as interoperability requirements)
- implementing additional measures (if the essential measures are not sufficient to address risk)
For 3rd-party components, you perform due diligence to ensure the components don’t undermine your appropriate level of cybersecurity for the overall product.
Document all of this in the technical documentation and all constraints, risks, and measures that users need to carry out or know about in the information & instructions to the user.
If you’ve understood this, you can use the three framework questions (risk? intended purpose? essential requirements?) to answer almost all difficult CRA questions. Plus, you’ll be surprised how rarely you need question 3 about the essential requirements.
Answering difficult CRA questions using the framework
Let’s put it into action by taking some of the diffiult questions from the guidance and see how they’re answered in the document:
Can I still use this insecure legacy protocol in my product?
The first two framework questions matter here:
- What’s the intended purpose of your product?
- Have you addressed the risk the legacy protocol introduces?
If using the legacy protocol is needed for the product to meet the intended purpose (and operating constraints), you’re fine, even though that means you don’t meet certain essential requirements. (clause 29)
However, you
- need to identify and address the risk associated with the legacy protocol (e.g. by taking compensating measures)
- describe the identified constraints, (residual) risks and compensating measures in the technical documentation and user information
- continuously monitor the risk and adjust accordingly
- continuously monitor if the operational constraint still exists and adjust accordingly
What qualifies as a substantial modification of my (software) product?
The first two framework questions matter here:
- Does your product’s cybersecurity risk change based on the modification?
- Or does the intended purpose change, and thus the basic assumptions of the risk assessment?
Quote: a substantial modification isn’t determined “based on the scale the complexity of the change, but on its potential effect on the product’s cybersecurity risk profile.” (clause 100)
If the change adds a risk that wasn’t addressed in the original risk assessment, that’s a substantial modification. (clause 97)
If the intended purpose is changed, the original risk assessment (assuming a different intended purpose) is no longer valid — thus: a substantial modification. (clause 98)
What is an exploitable vulnerability?
Only framework question 2 matters here:
- Is the vulnerability exploitable for my specific product with its specific intended purpose and operating conditions?
Not all vulnerabilities can be exploited under practical operational conditions. Quote: “The mere fact that a vulnerability is reported as exploitable does not, in itself, mean that it is exploitable in practice or applicable to the specific product”. (clause 209, 213)
What if a new exploitable vulnerability becomes known shortly before I want place my product on the market ?
Framework questions 1 and 2 matter here:
- What is the risk associated with the vulnerability if you place the product on the market anyway?
- Is the vulnerability exploitable for your product given its intended purpose and operating conditions?
The CRA doesn’t say you can’t place a product with an exploitable vulnerability on the market. It says you can’t place a product with an exploitable vulnerability on the market on the basis of a cybersecurity risk assessment and where applicable.
And yes, the CRA means it! If your risk assessment says placing the product on the market despite the vulnerability is fine — then it’s fine. If for your specific product, intended purpose, and operating conditions the vulnerability is not exploitable — then it’s fine, too. (clause 214, 215)
(See my CRA vulnerability FAQ for more on this)
When and how do I have to inform users of actively exploited vulnerabilites or severe incidents that I have reported to authorities?
Only the first framework question matters here:
- What is the risk for the users associated with the incident? Do they need to know in order to address risk?
You get the point by now. You’re the only one that can answer this. Using — of course — your risk assessment. (clause 199)
What if a harmonised standard doesn’t cover the entire product?
Framework questions 1 and 2 matter here:
2. Taking into account all of your products components and functionality, which parts are not covered by the standard?
- What risk is associated with these parts and how can we address it?
In short: For the product parts that are not covered (which you find based on your intended purpose / product description), you do the same thing you would do if there wasn’t a harmonised standard: do a risk assessment for the parts that are not covered and address those risks.
By the way, the risk assessment for the entire product is needed in any event, even if you apply a harmonised standard. Because — as we recall — the prime goal of CRA is addressing risks, not ticking off specific essential requirements. (clause 134)
Can I assume I am compliant with CRA if I meet the RED / machinery regulation requirements?
Only the first framework question matters here:
- Have you addressed all cybersecurity risks with your RED / machinery regulation implementation?
That won’t be the case since the scope of RED and machinery regulation is more narrow than that of CRA.
But: for the risks that have been assessed and addressed for CRA and RED, this assessment doesn’t have to be re-created for CRA. (clauses 229, 231)
Note: Once again, the guidance refers to addressed risks, not to fulfilled essential requirements. What determines the overlap with other cybersecurity regulation under the New Legislative Framework is risk, not essential requirements.
I could go on and on — but you get the idea by now. Once youu’ve understood the three core elements intended purpose, risk assessment, and essential requirements and how the interact, you can answer almost every difficult CRA question really fast.
Pragmatic answers to more specific questions
Beyond this incredibly useful decision framework, the guidance contains some very pragmatic answers to very specific questions. In many cases, it leans towards making life easier (and less bureaucratic) for manufacturers. The condition attached— you would have guessed by now: all cybersecurity risks must be addressed.
- Placing on the market of software: Software is regarded placed on the market with the first distribution — not with every subsequent download. This makes many things easier, for example defining the starting point for support periods. (clause 13)
- Definition of product with digital elements: What matters for the CRA is not the “presence of electronics”, but the “capacity to exchang digital information” (not just data). This is an important, pragmatic, and helpful distinction. (clause 23)
- Definition of data connection: A “data connection” according to the CRA only exists if the data is deliberately encoded to convey information — not if it just triggers or powers a function. This matters because it excludes many OT field devices from the scope. (clause 25)
- Introduction of compensatory measures: Those aren’t explicitly mentioned in the original CRA, but a commonly accepted concept in the industry. Mentioning them clarifies options for manufacturers especially when they can’t meet specific essential requirements. (clause 29)
- No problem if security wasn’t addressed in the design of the product: Often, legacy products haven’t been designed with security in mind. This isn’t a problem per se: Just carry out a risk assessment now and see if you address all risks and meet essential requirements where applicably and necessary. No need to recreate historical design documentation “as this would not enhance the cybersecurity of the product”. (clause 30)
- Assess similar products in bulk: It’s okay to carry out risk assessment and conformity assessments for a product family if the product variants are similar and subject to the same risks. (clause 36, 158, 159)
- How to find out if you’re the manufacturer or steward for open source software: There’s a really helpful flowchart (Figure 1) and many examples to illustrate.
- “No additional cost” definition for software updates: Manufacturers don’t have to keep fixing vulnerabilities for old software versions if users can update to the latest version at “no additional cost”, that’s not new. What’s new: “no additional cost” is also interpreted pragmatically — for example, personnell time and routine testing procedures don’t qualify as additional cost. (clause 119)
- Remote data processing solutions (RDPS): Figure 10 has a really helpful flowchart helping you find out if you have a RDPS and if it’s part of your product. Plus: clarification applies if your RDPS is operated as Platform as a Service (PaaS — qualifies as your RDPS), Infrastructure as a Service (IaaS — qualifies as your RDPS) or Sofware as a Service (SaaS — does not qualify as your RDPS).
