The new technical guideline BSI TR-03183-1

The CRA requires manufacturers to assess cybersecurity risks but does not prescribe a detailed methodology for doing so.

TR-03183-1 describes a process based on ISO 31000, ranging from establishing the risk context and identifying assets and threats to risk analysis, risk treatment, and documentation.

In this context, the BSI distinguishes, among other things, between:

• data assets, such as personal or business-related data,
• functional assets, such as essential product or safety functions, and
• security assets, such as passwords, cryptographic keys, or log data.

Confidentiality, integrity, and availability are assessed for these assets. The impact of a security incident can be rated on a scale from 1 – negligible – to 5 – very high. The Technical Guideline thus provides a concrete basis for a reproducible risk assessment that the CRA itself does not specify.
 

The CRA also does not prescribe a specific method for assessing the likelihood of a cyber incident. For this purpose, the BSI considers factors including:

• Interface Restriction: Through which interfaces can the product be accessed?
• Access Restriction: To what extent is access to the product restricted?
• User Capability: Is the product operated by qualified personnel, instructed users, or laypersons?

This approach takes particular account of the intended operating environment. A product operating within a protected industrial network may therefore be assessed differently from a comparable product with a direct connection to external networks.

This is particularly relevant for machinery and plant manufacturers, as the cyber risk may depend heavily on the specific installation environment and intended use.
 

The Technical Guideline also proposes criteria for determining when a risk can be accepted and when additional measures are required.

Factors considered include the potential severity of damage, the accessibility of the product, and the capabilities of its users.

However, the BSI makes clear that these criteria are only intended as a starting point. Manufacturers must adapt them to the specific product, industry, and application.

Adaptable Risk-based Controls: From Risk to Security Measures

A central element of the Technical Guideline is the concept of Adaptable Risk-based Controls (ARC). The basic idea is that security measures are not prescribed uniformly but selected on the basis of specific risk scenarios.

Factors considered include, for example:

• assets requiring protection,
• potential impacts,
• accessible interfaces,
• the operating environment, and
• user capabilities.

This creates a direct link between risk analysis and technical security measures.

The Technical Guideline illustrates this using automatic updates as an example: depending on the product, network connection, and user group, the same measure may be assessed differently.

Architecture Model for Products with Digital Elements

The Technical Guideline also uses a generic architecture model to structure the scope of the product under assessment. Factors considered include:

• hardware and software components on the user side,
• remote data processing solutions,
• external components and services,
• communication interfaces, and
• the product’s system boundaries.

For machinery incorporating control systems, HMIs, remote maintenance, cloud services, or apps, this can help manufacturers systematically determine which components and communication relationships must be included in the cybersecurity risk assessment.

Evaluator and Assessment Report

The Technical Guideline also describes a structured assessment procedure. A designated evaluator assesses the implementation of the requirements or controls. The evaluator may be an internal or external person. The BSI recommends appropriate expertise as well as an assessment that is as independent as possible.

Controls can, for example, be assessed as PASS, FAIL, or N/A. However, receiving a PASS for all applicable controls does not automatically demonstrate compliance with the CRA. Likewise, a FAIL does not necessarily constitute a violation of the CRA.

The results can be documented in a structured assessment report. This report may include, among other things, product identification, architecture, assets, threats, risks, security measures, and verification of those measures, and can therefore form part of the technical documentation.

Experimental Risk Scoring

Appendix D additionally contains an experimental scoring method. The so-called Environment Indicator takes particular account of interfaces, access restrictions, and user capabilities and is intended to make the assessment of likelihood more objective.

The BSI explicitly describes this approach as experimental. It is intended to be further developed on the basis of practical experience.

Practical Example: SNC X5 Network Camera

A complete example provided in the appendix is particularly illustrative. Using a fictional SNC X5 network camera, the Technical Guideline walks through the key steps of a cybersecurity risk assessment: from intended use and operating environment to assets and threats and, finally, the selection of specific security measures.

The example covers topics such as the protection of video and audio data, Wi-Fi access data, and user credentials, as well as measures such as HTTPS, encryption, and authentication. Naturally, this kind of practical walkthrough is not included in the CRA itself.

Security Measures in OSCAL Format

In addition, the BSI provides technical controls in OSCAL (Open Security Controls Assessment Language) format. This is intended to enable security measures to be systematically filtered, reused, and documented.

Looking ahead, this creates opportunities for more tool-supported CRA processes.

The CRA requires the “state of the art” to be taken into account in various contexts without prescribing specific technologies.

The Technical Guideline provides guidance on how to interpret this requirement: what matters is not necessarily the latest available technology, but rather the use of established methods and technologies that are appropriate for the specific use case.

For cryptography, for example, the BSI refers to relevant cryptographic recommendations such as BSI TR-02102.