Cyber Regulation: CRA in Development

The CRA distinguishes between four levels:

• Standard/Basic Products (Art. 6)
  • e.g. household appliances, measuring instruments, IoT (Internet of Things) devices, mobile or PC applications
• Important Products (Class I) (Art. 7, Annex III)
  • e.g. virtual assistants, smart door locks, baby monitors, wearables for health monitoring
• Important Products (Class II) (Art. 7, Annex III)
  • e.g. firewall appliance
• Critical Products (Art. 8, Annex IV)
  • e.g. HSM appliance (Hardware Security Module)

All assurance levels must comply with Annex I, i.e. all activities must always be carried out.

The difference between the assurance levels lies in the design of the product, which must guarantee a level of cybersecurity appropriate to the assurance level (Annex I Part I para. 1), and in the conformity assessment procedure (Annex VIII).

At present, there are no harmonized standards for the regulation. Harmonized standards are technical standards that are recognized by the EU Commission and enable a legally simplified conformity assessment.

Until such harmonized standards are published, manufacturers can fall back on established standards such as the IEC 62443 series of standards.

This is possible for products at the „Standard/Basic” security level (Art. 32 para. 1, Endnote 91). The associated procedure (Module A) is described in Annex VIII Part I and requires:

• ensuring that the design, development, manufacture and treatment of vulnerabilities correspond to the CRA
• drawing up the technical documentation in accordance with Annex VII
• affixing the conformity marking (CE marking) and drawing up the EU declaration of conformity

The manufacturer must ensure and declare on his own responsibility that the CRA is complied with. See also „Do I need processes for this? Why? Which ones?” and „What are the penalties for non-compliance with the CRA?”.

The proof of conformity depends on the safety level of the product.

Standard/Basic Products

• see above

All higher safety levels require the involvement of a notified body.

Important Products (Class I) (Art. 32 para. 2)

• EU type examination (module B) according to Annex VIII, part II and Conformity to type (module C) according to Annex VIII, part III.
  • This corresponds to the standard procedure for obtaining the CE marking.

or

• Conformity based on full quality assurance (module H) according to Annex VIII, part IV
  • The quality system must be approved and regularly inspected by a notified body.
  • This procedure allows the manufacturer to certify conformity based on the approved quality system on behalf of the notified body.

Important Products (Class II) (Art. 32 para. 3)

• According to module B and module C and module H (see Class I)

Critical Products (Art. 32 para. 4)

• Requires a European CybersecurityCertificate, at least assurance level “medium” according to Regulation EU 2019/881

The central element of the CRA is the assessment of cybersecurity risks. This document is created at the beginning of product development and then regularly updated (Art. 13 para. 2, 3).

The product development (planning, design, development phase) must take into account the results of the risk analysis in order to minimize the cybersecurity risks, prevent security incidents and minimize the impact of security incidents.

The product must be designed, developed and manufactured in such a way as to ensure an appropriate level of cybersecurity in view of the risks.

The cybersecurity requirements (Annex I Part I) must be met. Among other things, the following are required:

• Security by Design and best practices for a secure (software) development cycle
• Security by Default (e.g. secure standard configuration)
• Minimization of potential attack surfaces
• Protection against unauthorized access
• Confidentiality, integrity and availability (e.g. secure boot)
• Protection of personal data
• Logging of security-relevant data and events

The Technical Guideline TR-03183-1 of the BSI describes the state of the art in detail.

A software bill of materials (SBOM) is mandatory and must be provided in a machine-readable format (Annex I Part II para. 1). Possible formats are CycloneDX or SPDX (System Package Data Exchange).

Technical Guideline TR-03183-2 of the BSI describes the requirements for an SBOM in detail.

The CRA requires manufacturers to assess the cybersecurity risks of their products (Art. 12 para. 2). The BSI technical guidelines TR-03183 (“Cyber Resilience Requirements for Manufacturers and Products”) provide an approach (in accordance with ISO 31000) that can be summarized as follows:

1. Risk identification with structured threat modeling:
   1. Identification of the assets (components, data, functions, etc.) that need to be protected and their grouping into meaningful categories
   2. Recording of the potential threats to these assets and their assignment to the risks
2. Risk analysis: Assessment of the potential impact and frequency for each identified risk
3. Risk evaluation: Comparison of the impacts with predefined acceptance criteria and identification of the risks to be addressed; all risks with a perceptible negative effect on the user must be addressed

This analysis must be documented and maintained.

The following measures, among others, ensure that vulnerabilities are identified:

• Regular and effective testing and checking (para. 3)
  • Unit tests, penetration tests, etc.
• Analysis in relation to cybersecurity
  • Updating and maintaining the risk analysis
• Analysis of known vulnerabilities and their impact on your own product (e.g., OWASP)
• Analysis of vulnerabilities in components used in the product (this requires creating an SBOM and analyzing the associated known vulnerabilities)

The documentation is divided into two parts:

• Technical documentation
• User documentation

The technical documentation must contain all relevant data or details of how the manufacturer ensures that the product complies with the CRA (Art. 31 para. 1).

The technical documentation must be complete and written in easily understandable language and made available to the market surveillance authorities upon request (Articles 53, 58). It must enable the market surveillance authorities to understand the design, development, manufacture and handling of vulnerabilities (Article 31 (2)).

The technical documentation shall include at least (Annex VII):

• general description of the product
• Description of the design, development and manufacturing of the product
• Description of the vulnerability management process
• Cybersecurity risk assessment
• Information taken into account in determining the support period referred to in Art. 13 para. 8
• A list of the harmonized standards applied in full or in part, or a description of the solutions adopted to meet the essential cybersecurity requirements set out in Annex I
• Reports on the tests and inspections carried out
• EU declaration of conformity
• Software bill of materials

The documentation must be prepared before the product is placed on the market and updated throughout the entire life of the product (Art. 31 para. 2).

Chapter 6 of the Technical Guideline TR-03183-1 of the BSI goes into the documentation requirements in detail.

Yes, processes are required for all products with digital elements in accordance with CRA. Not having defined processes makes CRA compliance a huge challenge. The processes ensure that cybersecurity risks are systematically identified, assessed, remedied, and tracked throughout the product lifecycle, and they provide documented evidence that you are meeting the legal requirements (CRA, Art. 13(2–3)).

The CRA is not just a checklist for software features, but regulates the entire life cycle of a product. While technical security features are important, the EU regulation focuses heavily on how you as a company manage security in the long term, i.e. what working methods („processes”) you have established.

Even if a risk assessment only reveals acceptable risks, processes such as incident management, vulnerability handling, and secure updates are necessary, as new vulnerabilities and unexpected threats may arise after the product is released (CRA, Art. 13(6–8); Art. 14).

Here are the key process areas you need to establish or adapt:

• Risk assessment and design phase
• Software bill of materials (SBOM)
• Vulnerability management
• Conformity assessment procedures
• Support and lifecycle processes

More details on the processes for CRA

Risk assessment and design phase

Before a product is released to the market, the CRA requires you to:

• Security by Design: Documented processes that demonstrate that security was part of the development from the outset (“secure development”). Build security in from the start, including threat modeling and testing (CRA, Art. 13(1–2)).
• Risk analysis: A systematic assessment of the cyber risks to which your product is exposed. Identify assets to be protected, analyze and evaluate risks, and decide which ones require attention (CRA, Art. 13(3)).

Vulnerability management

This is one of the most important points of the CRA. Find, document, prioritize, and fix vulnerabilities. Maintain an up-to-date SBOM and support coordinated disclosure (CRA, Art. 13(6–8)).

• Monitoring: Continuously check your software for security vulnerabilities. This also includes third-party components that are used.
• Reporting: You are required to report actively exploited vulnerabilities to the relevant authorities within 24 hours. Identify, report, and address exploited vulnerabilities or cybersecurity incidents (CRA, Art. 14).
• Patch management: Structured processes to ensure that customers are informed quickly and a fix for the problem is available promptly.

Software Bill of Materials (SBOM)

You must be able to create and maintain an SBOM for each product.

• All libraries and dependencies used must be recorded in full.
• This list must be updated with every update.

Conformity assessment procedure

Depending on the risk class of your product, you must demonstrate that you meet the requirements:

• Internal control: For standard products, internal documentation of your processes is often sufficient.
• External audit: For critical products, you must establish processes for cooperation with the Notified Body.

Support and lifecycle processes

The CRA stipulates that you must provide security updates for a specified period of time. This period must be at least 5 years, but may be longer if the product has a longer expected lifespan. Monitor and update the product and its components throughout its expected lifespan (CRA, Art. 13(8–9)).

• You need processes in place to ensure that the update infrastructure remains stable over the years.
• End-of-life: A regulated process for communicating to customers when support ends.