Specifying the Intended Purpose of a CRA product

For manufacturers who master this, everything falls into place

11 min readJan 27, 2026

Why you should care about the intended purpose

The intended purpose is a core concept of the Cyber Resilience Act (CRA) / (EU 2024/2847). It is the basis for almost all CRA requirements and other key concepts. Master intended purpose, and everything else falls into place — or at least becomes much clearer.

Need evidence? Let’s do a quick tour de CRA to see where intended purpose plays a role:

Scope

The product’s intended purpose defines if it’s in scope of the CRA or not: Only if the intended purpose includes a data connection, it’s in scope.

See Article 2: The CRA “applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.”

Substantial modification

Want to find out if a change to a legacy product qualifies as a substantial modification (and thus leads to the legacy product being subject to CRA)? A substantial modification is defined as a modification to the intended purpose.

See Article 3 (30): “‘substantial modification’ means a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed;”

Condition under which the essential requirements apply

If the product is in scope, the essential requirements of the CRA apply — under the condition that the product is used for its intended purpose.

See Article 6: “Products with digital elements shall be made available on the market only where: (a) they meet the essential cybersecurity requirements set out in Part I of Annex I, provided that they are properly installed, maintained, used for their intended purpose or under conditions which can reasonably be foreseen, and, where applicable, the necessary security updates have been installed […];”

Scope of the cybersecurity risk assessment

Cybersecurity risk assessments can quickly turn into bottomless pits: There will always be one more risk to describe. How do you know which scenarios to take into account? Right, you assume the product is used according to its intended purpose (and reasonably foreseeable use).

See Article 13 (3): “[…] That cybersecurity risk assessment shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use. […]”

Reasonably foreseeable use

Speaking of reasonably foreseeable use — let’s see how that one is defined: Well, that is what humans can be expected to do with the product beyond its intended purpose.

See Article 3 (24): “‘reasonably foreseeable use’ means use that is not necessarily the intended purpose supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation, but which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions;”

Support period

Defining the support period — the period during which the product gets free security updates — typically gives manufacturers a headache. By now, it probably comes at no surprise to you that one of the criteria for defining a reasonable support period is the intended purpose.

See Article 13 (8): “[…] Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. […]”

Data minimisation

When have manufacturers minimised the use of (personal) data enough? Simple: When they only process what’s necessary for the intended purpose of the product.

See Annex I Part I (g): “process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);”

Information and instructions to the user

Of course, such a fundamental specification as the intended purpose needs to be communicated to the user. It’s referenced in two places in the requirements for the mandatory user information.

First, the intended purpose itself needs to be communicated.

See Annex II (4): “the intended purpose of the product with digital elements, including the security environment provided by the manufacturer, as well as the product’s essential functionalities and information about the security properties;”

Second, circumstances leading to risk must be communicated — but only those that are in accordance with the intended purpose of the product (or reasonably foreseeable misuse — see above).

See Annex II (5): “any known or foreseeable circumstance, related to the use of the product with digital elements in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to significant cybersecurity risks;”

Technical documentation

The technical documentation is the proof that a product is in conformity with CRA. It goes without saying that the intended purpose needs to be documented there. And after all the evidence above, you’re probably not surprised any more that its not only on the list of things to be documented, but actually leads that list.

See Annex VII (1a): “The technical documentation referred to in Article 31 shall contain at least the following information, as applicable to the relevant product with digital elements: 1. a general description of the product with digital elements, including: (a) its intended purpose;”

How the CRA defines “intended purpose”

As you can see by now, nailing the intended purpose makes your life easier as a manufacturer because it answers a whole bunch of difficult questions during CRA implementation.

For customers, keeping a a close eye on intended also makes sense: the intended purpose is the only wiggle room for manufacturers to shift some of the product liability to its customers.

So what does a good intended purpose definition look like?

The term is clearly defined in the CRA. Article 3 (23) says: “‘intended purpose’ means the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation;”

There are three key terms in this definition:

use: how does the manufacturer intend the product to be used?
specific context: in what environment does the manufacturer assume the product to be used?
conditions of use: what restrictions has the manufacturer defined to limit the use of the product?

How not to specify the intended purpose

Chances are that every manufacturer will take their own shot at specifying the above. Most likely, legal departments will have the final say. Quite likely, this is going to end up being a few paragraphs in small print that nobody takes seriously. The “don’t put your cat into the microwave” kind of small print.

What a missed opportunity!

The manufacturer’s engineering / CRA teams need a clear, workable intended purpose specification for so many derived concepts, as we’ve seen. The manufacturer’s clients need a clear, understandable intended purpose specification to know how to use a product securely and what security they can expect under which circumstances.

The whole industry would benefit from a pragmatic, clear, easy-to-use and standardized way of specifying the intended purpose of a product with digital elements.

Manufacturers would gain clarity in virtually all areas of their CRA implementation.

Product buyers would gain clarity on how to use a product with digital elements securely. This is especially critical for B2B customers who often need to integrate the product securely into larger systems, often subject to cybersecurity regulation like NIS-2.

How to do it better

Imagine we took a more structured approach to defining intended purpose!

Based on the three intended purpose components according to the CRA — use, specific context, and conditions of use — the core of the intended purpose should be explicitly defining use.

1. Use: Product functions

The most explicit way to define use is explicitly listing the product’s functions. These split into two categories:

Core functions: the reason why the product exists. Sometimes just one function, rarely more than a handful. For a printer, it’s printing documents. For a digital camera, it’s taking pictures and browsing through them on the screen. For an engineering PC, it’s creating new PLC logic and flashing it onto the PLC.
Supporting functions: additional functions that are intended by the manufacturer, but are not the reason why the product exists. Popular examples are administration or remote maintenance — and definitely some kind of security update installation mechanism (mandatory for CRA compliance).

Once that’s done, each function briefly needs to be explained. How does it work? Are humans involved? What skills do they require? What do they do with the product? Which product components are involved? How do they need to interact to fulfill the function? Which protocols are being used?

This can be done only in prose. But often, a simple drawing sketching the relevant humans, product components and their interaction is incredibly helpful. Often, the most efficient way is to combine prose and a diagram — the prose can be vetted by legal and provide the necessary detail, the diagram aids quick understanding for the user.

Depending on the number of interfaces the product has, it might make sense to list all interfaces required for each specific function. That way, users don’t just know which interfaces the product has, but also for which purpose each is required (or not required) — and thus can for example adjust their firewall settings accordingly.

Here is an example for a function list and description for one of the functions for a fictional product (an engineering PC):

2. Context: Installation environment variants

Context is difficult. Every single manufacturer struggles defining context for their products — after all, they don’t know in what context (operating environment) the user will put it, right?

Right — and that’s exactly why taking a structured, explicit approach to defining context is desperately needed. Creating language to talk about the context in which a product is used is crucial to make sure the manufacturer’s assumptions align to the users’ realities and needs.

Of course, manufacturers can’t specify ALL potential contexts for their products. But that doesn’t mean explicitly defining two to five potential contexts while making the differences clear can’t be incredibly helpful. I’ve yet to see a manufacturer where that didn’t work.

For example, an engineering PC could be used to program a PLC in a point-to-point-connection, plugging it directly into the PLC. Or it could be put into the same network as the PLC, thus communicating via this network. Or there could be separate network segments, one for PLCs, one for the engineering PC — and maybe other devices too. These would be three to four different contexts.

As a rule of thumb: Only differentiate between contexts if the differences between them lead to different conditions of use, risks, or security requirements.

As with functions, contexts can be described in prose — but supporting drawings provide additional clarity, so it makes sense to combine them.

To illustrate the concept, let’s look at the engineering PC example again:

3. Conditions of use: Restrictions

Once use and context have been defined, the conditions of use are a walk in the park. Conditions of use are all the restrictions a manufacturer needs to make in order to ensure the security (and CRA conformity) of the product. Examples are limiting internet access or restricting the use to humans with a certain skillset. The conditions typically result from a cybersecurity risk assessment.

There can be two kinds of conditions of use:

General conditions of use that apply regardless of product context.
Context-specific conditions of use that only apply to the product being used in a certain context.

Conditions might apply to the product itself or to components in the product context. Especially the latter are important to communicate to product users. To be as specific as possible, each condition should explicitly specify the affected components. The conditions can also be marked in the diagrams so the reader can gain a quick overview where conditions apply.

(Almost) everything’s falling into place

Specifying the intended purpose of a product is something every manufacturer of a product with digital elements according to the Cyber Resilience Act (CRA) will need to do until 2027. Doing it early and using a structured approach (functions, contexts, conditions) pays off.

Once manufacturers gain clarity on the intended purpose, many hard CRA questions become easy to answer:

a substantial modification can easily be identified — everything that adds / changes product functions.
the scope of the risk assessment can be outlined; and the risk assessment itself becomes easier because the product has clearly been defined.
data minimisation and hardening requirements become easier to manage, since it’s becoming simple to answer which piece of data contributes to which core function (or not).
drafting the information & instructions to the user is halfway done, since manufacturers can reference the intended purpose components (functions, contexts, conditions) in almost all other sections of the document.