Is BSI TR-03183 binding for manufacturers?

No. The guideline says it establishes no obligations and gives no presumption of conformity; the CRA is the law. It helps to apply the CRA and to prepare for the harmonised standards that will replace it.

Why can the same control apply and not apply within one product?

Because controls are selected per part of the product. Each part has its own environment — who can access it, over which interfaces, operated by which kind of user — and a risk-based control applies only where that environment and the affected assets match its risk scenario.

What should a technical writer do with two recommendations that seem to conflict?

Note the version and control of each, ask the product's security experts which risk scenario applies to which component, and record the decision and its reason. Do not publish the conflict as a fact before that.

All context cards

Context card

BSI guidance on the CRA: context-dependent, not contradictory

When two pieces of BSI guidance on the Cyber Resilience Act seem irreconcilable, is the guidance contradictory?

By knowledge.aitechdoc.world

Reviewed 2 October 2026

Review log and changes

The short answer

Usually not. BSI TR-03183-1 builds its controls on risk scenarios: a control applies only where the product's assets, access, interfaces and users match its scenario, and is otherwise marked not applicable. Two recommendations can therefore point in different directions for two parts of the same product without contradicting each other. The manufacturer's cybersecurity risk assessment under Article 13 CRA decides which one applies where.

For: Product security managers, compliance managers and technical writers working on CRA topics

Key points

TR-03183-1 version 1.0.0 (Part 1: General requirements) is a living document of the BSI that helps manufacturers prepare for the CRA with requirements, recommendations, test actions and assessment criteria derived from Annexes I, II and VII.
By its own statement it establishes no obligations, gives no presumption of conformity, does not describe the only way to meet the essential requirements, and will be superseded once harmonised standards cover its content.
Controls carry an optional risk scenario (assets and impact plus the environment: access restriction, interface restriction, user capability); a control that does not match is "N/A", as is one whose target mechanism is missing, whose "if" condition does not apply, that is replaced by a compensation, or that conflicts with other regulations.
The guideline's own example applies the "automatic update mechanism" control to the component a layman administers, but not to the remote data processing operated by skilled staff — two answers for one product, by design.
A PASS or FAIL against the guideline is no direct statement of CRA compliance; the risk assessment and its documentation in the technical file remain the manufacturer's.

The context

What the guideline is

The German Federal Office for Information Security (BSI) publishes Technical Guideline TR-03183, Cyber Resilience Requirements for Manufacturers and Products, to prepare manufacturers for the Cyber Resilience Act. Part 1 (general requirements, version 1.0.0) turns the objectives of CRA Annex I (essential cybersecurity requirements), Annex II (information for the user) and Annex VII (technical documentation) into controls with test actions and assessment criteria. Further parts cover the software bill of materials, the handling of vulnerability reports and conformity through full quality assurance (Module H).

The guideline states plainly what it is not. It does not establish obligations, does not give presumption of conformity when applied, does not always reflect the state of standardisation, does not address other EU legislation and does not describe the only way to meet the essential requirements. It is a living document, feeds the work on harmonised standards and is to be superseded once those standards cover its content.

Context is built into every control

The CRA covers products as different as a sensor, a firmware component, an industrial controller and a consumer app. Article 13 therefore requires a cybersecurity risk assessment, and the guideline makes that assessment the switch for its controls:

Tailoring: the risk handling follows ISO 31000 and may be tailored to the product, its intended purpose and foreseeable use, as long as the general requirements are met. The acceptance criteria are an initial baseline to be tailored to the use case and sector.
Risk scenarios: a risk-based control names the assets and impact and the environment it addresses — access restriction, interface restriction and user capability. It applies only where the product, or a part of it, matches.
Not applicable: a control is marked N/A when a compensation is fulfilled instead, its target mechanism does not exist, its "if" condition does not apply or it conflicts with other regulations.
SHOULD: following RFC 2119, a recommendation leaves room for valid reasons to deviate, provided the implications are understood and weighed.
State of the art: terms such as state of the art are interpreted by the evaluator for the specific use case, not as "the latest technology".

One product, two answers

The guideline's own example is a consumer product that handles personal data and relies on remote data processing run by the manufacturer. The control "automatic update mechanism" applies to the component a layman administers over an external network. It does not apply to the remote data processing, because skilled staff operate it. Read without their risk scenarios, "update automatically" and "no automatic update needed" look irreconcilable. Read with them, each applies where its conditions hold.

That is how apparent conflicts in the guidance are resolved: map each recommendation to its risk scenario and environment, check which part of the product matches, and document the decision and its reason in the risk assessment that goes into the technical file.

What a verdict means

An assessment against the guideline ends with PASS (all controls PASS or N/A) or FAIL. The guideline itself says this is no direct statement of CRA compliance: a FAIL may concern controls that do not fit the product, and a PASS may leave risks the guideline does not cover. Neither the guideline nor any assessment against it replaces the manufacturer's conformity assessment.

An overview of all four parts

Readers who want the whole guideline on one page will find a well-structured German-language overview at CyberKlartext: BSI TR-03183 at a glance (as of August 13, 2026). It moves in four steps — why a technical guideline sits next to the CRA and how it relates to the harmonised standards still being written; one card per part with its version, the CRA provisions it supports and its main topics; how the parts are put to work in practice; and a short background section with FAQ. It is a good map before reading the BSI documents; the binding text remains the CRA, and the guideline's own wording remains the BSI publication.

Questions readers ask next

Is BSI TR-03183 binding for manufacturers?: No. The guideline says it establishes no obligations and gives no presumption of conformity; the CRA is the law. It helps to apply the CRA and to prepare for the harmonised standards that will replace it.
Why can the same control apply and not apply within one product?: Because controls are selected per part of the product. Each part has its own environment — who can access it, over which interfaces, operated by which kind of user — and a risk-based control applies only where that environment and the affected assets match its risk scenario.
What should a technical writer do with two recommendations that seem to conflict?: Note the version and control of each, ask the product's security experts which risk scenario applies to which component, and record the decision and its reason. Do not publish the conflict as a fact before that.

Sources

Technical Guideline TR-03183-1: Cyber Resilience Requirements for Manufacturers and Products, Part 1: General requirements, version 1.0.0 — Federal Office for Information Security (BSI), 31 July 2026
BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — Federal Office for Information Security (BSI), 2 October 2026
Regulation (EU) 2024/2847 (Cyber Resilience Act) — Official Journal of the European Union, 20 November 2024
BSI TR-03183: overview of the four parts — CyberKlartext, 13 August 2026

Review log and changes

Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.

Reviewed 2 October 2026

Corrections and additions

Every correction and addition to this card, with date and time (Berlin time).

Addition2 October 2026, 10:59 CEST
Explanation rebuilt on BSI TR-03183-1 version 1.0.0: how risk scenarios and "not applicable" decide where a control applies, the guideline's own example of one product with two answers, and what a PASS or FAIL means.
Addition2 October 2026, 10:59 CEST
Added a recommended overview of all four parts of BSI TR-03183 (CyberKlartext) and its structure.

Glossary terms on this card

Cyber Resilience Act (CRA)
The Cyber Resilience Act, Regulation (EU) 2024/2847, is EU legislation establishing cybersecurity requirements for products with digital elements across their lifecycle, from design through vulnerability handling and security updates during the support period. It entered into force on December 10, 2024.
Security risk assessment
In OT cybersecurity, a security risk assessment is the systematic identification of threats and vulnerabilities of an industrial automation and control system, the estimation of the likelihood and consequences of their exploitation, and the derivation of zones, conduits and target security levels. IEC 62443-3-2 describes the process.
Harmonized standard
In EU product law, a harmonized standard is a European standard adopted on the basis of a request from the European Commission for the application of EU harmonization legislation. Once its reference is cited in the Official Journal of the European Union, applying it may support presumption of conformity with the requirements it covers.
Presumption of conformity
In EU product law, presumption of conformity is the legal effect by which applying a harmonized standard whose reference is cited in the Official Journal of the European Union may support conformity with the legal requirements that the standard covers. The presumption is limited to those requirements and can be rebutted.
Software bill of materials (SBOM)
In software supply chain security, a software bill of materials (SBOM) is a formal, machine-readable inventory of the software components, libraries and their versions and suppliers contained in a software or firmware product, including dependency relationships. Common formats are SPDX and CycloneDX.
State of the art
In EU product safety law, the state of the art is the current level of technical development and accepted good practice relevant to risk reduction. Manufacturers must take it into account when applying the essential health and safety requirements.