← Commission worked examplesRisk assessment

How does the CRA cybersecurity risk assessment justify design decisions?

5 worked examples from Commission guidance C(2026) 5252 final, reproduced word for word.

Also asked

  • Do I have to redesign a product designed before the CRA applied?
  • Can I still support an insecure legacy protocol under the CRA?
  • Do I need to recreate old design documentation for the CRA?
  • Can I rely on the operating system's encryption instead of my own?
  • Can I limit a product's intended purpose to reduce cybersecurity risk?

The Commission's risk assessment examples all turn on the same move. The Article 13(2) assessment decides what a product needs, and it can justify choices that look like gaps. Supporting a legacy protocol for interoperability, integrating a component bought before the CRA applied, placing an older design on the market without redesign, limiting a sensor's intended purpose instead of hardening it, and relying on the operating system's cryptography rather than writing your own are each defensible where the assessment carries them.

The assessment has to be documented and kept under review under Article 13(3). An undocumented judgement call is not a treated risk.

At a glance

Legal basis
Article 13(2) and Annex I, Part I, point (2)
Legacy protocols
Allowed for interoperability, with the secure one implemented and default (Example 10)
Pre-CRA designs
No redesign where a current assessment shows the design already complies (Example 12)
Historical paperwork
Not required to be recreated (Example 12)
Limiting intended purpose
A valid treatment where the limitation reaches the user (Example 66)

Last reviewed 27 July 2026

Verified against The Annex to Commission Communication C(2026) 5252 final of 27 July 2026, and Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

Interoperability can justify a weaker protocol, but not as the default

Example 10 is the one manufacturers of industrial equipment reach for. Where the intended purpose includes talking to systems that only speak an older protocol, that protocol may be implemented, provided the risks are identified and mitigated by other means.

The condition is the part that gets missed. Where the product can technically support both, the manufacturer is expected to implement the secure protocol and enable it by default. The weaker one is allowed only where interoperability requires it. Shipping the legacy protocol as the default and calling it interoperability does not survive this example.[1]

CRA referenceArticle 13(2), Annex I, Part I, point (2)

Older designs and older components do not force a redesign

Examples 11 and 12 answer the question every hardware manufacturer asked during the transition. Components purchased before the CRA applied can be integrated, provided the assessment finds no specific risk in doing so and the finished product meets the essential requirements as a whole.

Example 12 goes further for products designed before the date of application. Where a current assessment shows the existing design already incorporates appropriate measures, the product may be placed on the market without redesign. The manufacturer documents a current assessment explaining how the existing design mitigates the identified risks. It is not required to recreate historical design or test documentation, because doing so would not make the product any safer. Representative evidence may cover a family of variants sharing a risk profile.[1]

CRA referenceArticle 13(2) and (3), Annex I, Part I

Two ways to treat a risk without building a control for it

Examples 66 and 67 sit in the section on evaluating and treating cybersecurity risks, and both describe treatments that add no security feature to the product.

In Example 66 the manufacturer of an industrial sensor cannot protect against physical attack without breaking the sensor's function, so it limits the intended purpose to trusted environments and says so clearly in the information and instructions to users. The limitation is the mitigation, and it only works because it reaches the user.

In Example 67 the manufacturer of a professional application declines to write its own encryption and relies on the operating system's native encryption and key management, on the reasoning that those services are mature and regularly maintained. Both are ordinary risk treatment, documented as such.[1]

CRA referenceAnnex I, Part I, point (2), and Annex II

The Commission’s examples, word for word

5 examples, reproduced exactly as published. Each carries the section, guidance point and page it comes from. The bold line above each quotation is our summary of the outcome and is not part of the source.

Example 10

Section 2.6 Complex systems, point 32, page 13

A legacy protocol may be supported for interoperability, but the secure one is implemented and on by default

A manufacturer places on the market a product with digital elements that communicates with external systems using a network protocol. As part of the application of the essential requirements, the manufacturer determines, on the basis of the cybersecurity risk assessment, that the use of a secure communication protocol is necessary to ensure the confidentiality and integrity of data exchanged by the product with digital elements.

However, its intended purpose includes interoperability with existing systems that only support an older or less secure protocol. In such cases, the manufacturer may implement that protocol where this is necessary to achieve interoperability, provided that the associated cybersecurity risks are identified and mitigated through other means.

Where it is technically feasible for the product with digital elements to support both the secure protocol and the less secure protocol, the manufacturer is expected to implement the secure protocol and to enable its use by default. The less secure protocol would be allowed only where required for interoperability.

Example 11

Section 2.6 Complex systems, point 32, page 14

Components bought before the CRA applied can be integrated, provided the whole product meets the essential requirements

A manufacturer of an industrial automation system purchases some microcontrollers before the CRA enters into application. The manufacturer undertakes the cybersecurity risk assessment for its industrial automation system to be placed on the market after the CRA enters into application. On the basis of that cybersecurity risk assessment, the manufacturer does not identify specific cybersecurity risks associated with using one of those microcontrollers. The manufacturer integrates it into its industrial automation system and ensures that the product with digital elements as a whole (the industrial automation system) meets the essential requirements.

New in the adopted text. It has no counterpart in the earlier consultation draft.

Example 12

Section 2.7 Products with digital elements designed before the CRA entered into application, point 39, page 16

No redesign, and no recreated historical paperwork, where a current risk assessment shows the existing design already meets the requirements

A manufacturer places on the market a microcontroller that was designed and developed before the date of application of the CRA. The microcontroller is intended to be integrated into a range of electronic products with digital elements, including products with digital elements with connectivity functionalities.

Before placing new units of the microcontroller on the market after the CRA applies, the manufacturer carries out a cybersecurity risk assessment in accordance with Article 13(2). On the basis of the intended purpose of the microcontroller and its reasonably foreseeable use, the manufacturer identifies relevant cybersecurity risks, such as unauthorised access, manipulation of software or data, and misuse of available interfaces.

The outcome of the risk assessment shows that the microcontroller, as originally designed, already incorporates appropriate and effective security measures addressing the identified risks. The manufacturer therefore concludes that the product with digital elements meets the relevant essential requirements set out in Part I of Annex I and that no redesign or introduction of additional security functionalities is necessary.

Where it is not possible to demonstrate how a cybersecurity risk assessment was taken into account during the original design and development phase, the manufacturer documents a current cybersecurity risk assessment and explains how the existing design and measures mitigate the identified risks. The manufacturer is not required to recreate historical design or test documentation, as this would not contribute to enhancing the cybersecurity of the product with digital elements. Where several variants of the microcontroller are based on the same design and share the same cybersecurity risk profile, the manufacturer may also rely on representative evidence covering the relevant product family.

The manufacturer also ensures compliance with the vulnerability handling requirements laid down in Part II of Annex I, including by maintaining processes to address and remediate vulnerabilities and by keeping the cybersecurity risk assessment under review in accordance with Article 13(3).

In these circumstances, the microcontroller designed before the date of application of the CRA may be placed on the market without redesign, provided that the manufacturer can demonstrate, through the cybersecurity risk assessment and the technical documentation, that it achieves an appropriate level of cybersecurity in light of its intended purpose and reasonably foreseeable use and complies with the applicable essential requirements.

Example 66

Section 7.1 On the evaluation and treatment of cybersecurity risks, point 162, page 59

Risk treated by limiting the intended purpose, with the limitation stated in the user information

A manufacturer develops an industrial sensor for use in trusted environments. For the sensor to perform its functionality correctly, the manufacturer does not implement measures to protect against physical attacks on the sensor itself. To mitigate the associated risks identified in the risk assessment, the manufacturer limits the sensor's intended purpose to use only in trusted environments where unauthorised physical access to the product with digital elements is prevented. Information and instructions to the users provide clear information on these limitations on the sensor's use, in a manner that is appropriate to the nature of the product with digital elements and its intended users.

New in the adopted text. It has no counterpart in the earlier consultation draft.

Example 67

Section 7.1 On the evaluation and treatment of cybersecurity risks, point 162, page 59

Relying on mature operating system cryptography rather than rolling your own

A manufacturer develops a software application for professional use on managed desktop and mobile devices. The application processes locally stored sensitive data and user-generated content. During the risk assessment, the manufacturer identifies the risk of unauthorised access to such data if they are stored in clear text on the device. Rather than designing and implementing a proprietary encryption mechanism within the application itself, the manufacturer chooses to rely on the encryption and key management functions provided natively by the operating system on which the application is intended to run, as the operating system's built-in cryptographic services are mature and regularly maintained.

New in the adopted text. It has no counterpart in the earlier consultation draft.

Sources

Every claim above traces to one of these. Items marked Binding are law in force. Everything else is interpretive and is labelled as such.

  1. [1]

    European Commission · Sections 2.6, 2.7 and 7.1, points 32, 39 and 162 · C(2026) 5252 final · Final, adopted 27 July 2026

    Article 26 guidance sets out the Commission's interpretation of the CRA. It does not bind economic operators, and only the Court of Justice of the European Union can give an authoritative interpretation of the Regulation.

    Accessed 2026-07-27

  2. [3]

    European Union · Annex I, Part I, point (2) · CELEX:32024R2847

    Accessed 2026-07-27

Further reading on this site

Turn the guidance into an audit-ready file

Free CRA classification for your product, a vulnerability disclosure portal on your own domain, and Article 14 deadline tracking. Receiving and tracking reports is free for every manufacturer placing products with digital elements on the EU market.