BSI TR-03183-1: The Official Entry Aid Into the Cyber Resilience Act — What Must Be in Place by 11 September 2026

What the BSI published on 5 August — and what it explicitly is not

The German Federal Office for Information Security has published Technical Guideline TR-03183 Part 1 "General Requirements" in version 1.0.0 and positions it as an entry aid into the Cyber Resilience Act. Its stated target audience is specifically manufacturers that have not yet established mature IT security processes for their development and vulnerability handling (see https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/TR-03183_Einstiegshilfe_CRA_260805.html). That is a remarkably precise scoping statement: the guideline is not written for organisations that already run a mature product security programme, but for the much larger remainder.

Equally important is what TR-03183-1 explicitly is not. The BSI states that the document has no mandatory or binding character and cannot be used to establish a presumption of conformity. It is designed as a living document and will be superseded by the corresponding harmonised European standards once those are available (see https://www.bsi.bund.de/dok/TR-03183). Reading the guideline as a compliance certificate builds on sand — using it as a structured map through the essential requirements of the CRA saves several months of independent research.

That is precisely where its practical value for delivery organisations sits. TR-03183-1 assembles the requirements from the articles and annexes of the CRA into assessable controls, assigns assessment procedures to them and offers an approach to the risk-based selection of security measures. In addition, the BSI provides an initial selection of generic security measures in the machine-readable OSCAL format. That is the difference between a regulation that states objectives and a document that tells you what an assessment demonstrating those objectives looks like.

Whether your reporting processes will hold up on 11 September 2026 is what our free CRA reporting readiness check shows in about three minutes — no login, with a result you can lift straight into a steering deck.

By 11 September 2026: what Article 14 actually demands

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies in principle from 11 December 2027 under Article 71. Article 14, however, applies from 11 September 2026, and Chapter IV with Articles 35 to 51 from 11 June 2026 (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj). That makes 11 September 2026 the only deadline this quarter that genuinely switches on new operational duties across NIS2, DORA, CRA and the AI Act.

Article 14 has two triggers, each with its own three-stage cascade. Trigger one is any actively exploited vulnerability contained in the product: an early warning without undue delay and in any event within 24 hours of the manufacturer becoming aware, stating the member states in whose territory the product has been made available. Then, within 72 hours, the vulnerability notification covering the general nature of the exploit and the corrective or mitigating measures taken. And no later than 14 days after a corrective or mitigating measure becomes available, the final report with severity, impact, information on known malicious actors and on the security update provided.

Trigger two is any severe incident having an impact on the security of the product. Again 24 hours for the early warning, again 72 hours for the notification — but here the final report is due within one month of submitting the 72-hour notification. Under Article 14(5) an incident counts as severe if it negatively affects, or is capable of affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or is capable of leading to the introduction or execution of malicious code.

The reporting route is set out in paragraph 7 and is routinely planned wrongly in practice: reporting runs through the single reporting platform established under Article 16, to the electronic reporting endpoint of the CSIRT designated as coordinator of the member state in which the manufacturer has its main establishment in the Union — simultaneously accessible to ENISA. The main establishment is the member state where decisions relating to the cybersecurity of the products are predominantly taken. Anyone with engineering in Poland, a group headquarters in the Netherlands and security decisions in Germany should have answered and documented that question before 11 September, not during their first early warning.

The trap almost everyone misses: legacy products are in scope from day one

The most common misconception in roadmaps is that the CRA only concerns products placed on the market from December 2027 onwards. For the essential requirements that is broadly right — products placed on the market before 11 December 2027 are subject to them only where they undergo a substantial modification. For the reporting duties, however, an explicit derogation applies: the obligations laid down in Article 14 apply to all products with digital elements within the scope of the regulation that were placed on the market before 11 December 2027 (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj).

Operationally that means from 11 September 2026 your entire shipped portfolio sits under the 24-hour clock — including the 2021 firmware generation, the on-premise module three customers still run, and the white-label variant sold under someone else's brand. The question "which artefacts have we ever actually placed on the market, and who watches their vulnerability exposure?" therefore stops being an inventory chore and becomes the precondition for meeting the deadline at all.

For the next few weeks that implies an uncomfortable but clear order. First the product inventory with a per-artefact verdict of "in scope — yes, no, unclear", then the named owner per product who takes the reporting decision, and only after that the substantive work on Annex I. Starting with the technical documentation instead means working on a deadline that lands in 16 months while leaving the one that bites in five weeks wide open. We described the general shape of this reporting duty in Cyber Resilience Act: the 24-hour reporting duty from September 2026; this article picks up where the concrete implementation aid begins.

The four parts of TR-03183 and what each one delivers

TR-03183 is not a single guideline but a series. Part 1 "General Requirements" in version 1.0.0 assembles the requirements for manufacturers and products in line with the articles and annexes of the CRA. Part 2 "Software Bill of Materials" is available in version 2.1.0 and describes formal and substantive requirements for SBOMs. Part 3 "Vulnerability Reports and Notifications" has been released in version 1.0.0 and governs how incoming vulnerability reports are handled. Part H "Conformity based on full quality assurance" is available in version 1.1.0 (see https://www.bsi.bund.de/dok/TR-03183).

Part H deserves particular attention from any organisation that already runs an information security management system. In it the BSI describes the option of realising full quality assurance under Module H via an ISO/IEC 27001-conformant ISMS — such as the German IT-Grundschutz — and thereby demonstrating conformity with the CRA. Organisations that are already certified therefore do not need to build a second management system; they extend their existing cybersecurity processes to product development and vulnerability handling. That is the single largest efficiency lever in the entire series.

Part 2 carries the hardest technical determinations and is the one that touches your build pipeline directly. A newly generated or updated SBOM must be in JSON or XML format and valid against one of the named specifications: CycloneDX version 1.6 or higher, or SPDX version 3.0.1 or higher, and only in officially released versions. The CycloneDX specification overview is at https://cyclonedx.org/specification/overview/. Version 2.1.0 of the guideline adds, among other things, a mapping recommendation between the data fields of the guideline and both SBOM formats, plus a reworked licensing chapter.

At data-field level it becomes pleasingly concrete: every SBOM must contain at least the creator — as an email address or, failing that, a URL — and a timestamp of data compilation, recommended in UTC. For each component the component creator must be provided, among other fields. Anyone generating an SBOM today as a scanner by-product without populating these fields holds an artefact that will not serve as evidence when it matters. The BSI has additionally registered its own CycloneDX namespace and published its taxonomy in the BSI GitHub account.

Part 3: the intake channel you need before your first notification

Article 14 governs what you report outward. Part 3 of TR-03183 governs the opposite direction — and in practice that is what decides whether the 24-hour clock even starts in time. Manufacturers usually do not learn about an actively exploited vulnerability through their own monitoring, but because an external reporter tells them. An intake channel that sits in a support mailbox for a week turns a met deadline into a missed one.

The guideline is unusually concrete here. It requires a security.txt file in accordance with RFC 9116 with a canonical URI, contact information, OpenPGP keys, preferred languages, a pointer to the CVD policy and an expiry date — discoverable by web crawlers and digitally signed. On top of that: a published coordinated vulnerability disclosure policy, a web form for vulnerability reports, named security contacts with an encryption option, and identification of the corresponding national CSIRT.

The sharpest requirements are the guaranteed response times. A simple response to a vulnerability report or an update to an existing one must be provided within five working days, and that response must explicitly not be an automated one. Detailed feedback after further analysis is due within ten working days and must contain either a statement confirming or rejecting the reported vulnerability, meaningful queries to understand it, or an explanation why the investigation is taking longer together with a commitment to provide an update within ten working days. The guideline also requires an easy-to-find option for anonymous reporting.

For delivery governance these are not web-editing tasks but capacity commitments. Five working days to a personal first response means a named role with deputisation — not a distribution list. Publishing a security.txt without staffing that role publishes a promise you cannot keep. The corresponding process and role artefacts can be produced in days with our governance templates rather than drafted from scratch.

The assessable core of Part 1: controls, verdicts and an independent evaluator

Part 1 is designed for a self-assessment by the manufacturer or by a third party acting on the manufacturer's behalf. The guideline sets out a role model that governance leads will recognise instantly: the evaluator needs sufficient technical and methodological knowledge, access to all information required for the assessment, and must be impartial — ideally not involved in developing the product under assessment. Where that is not achievable, the guideline at least demands an explicitly independent mindset.

Every control consists of defined parts: a normative statement, optionally a risk scenario, inputs and outputs for activities, a target, assessment and implementation guidance, a possible compensation, and a reference to the CRA requirement it supports. Each control is rated PASS, FAIL or N/A, where N/A is only permissible if a referenced compensation is met instead, the target mechanism does not exist in the product, an "if" condition does not apply, or the control conflicts with other regulations. The overall verdict is PASS if all controls are PASS or N/A — otherwise FAIL.

Important for internal communication: the BSI qualifies that overall verdict itself. A FAIL does not necessarily mean the product is non-compliant with the CRA, and a PASS does not mean it is compliant, because the product may pose risks the guideline does not cover. Selling the verdict as a traffic light in management reporting sells a certainty the source explicitly withholds. The honest phrasing is: demonstrated coverage of the guideline, not demonstrated conformity.

The methodological core is a risk-based approach spanning risk assessment, risk analysis, risk evaluation, risk treatment, documentation and periodic updating — complemented by adaptable risk-based controls selected via risk scenarios and predefined risk profiles. The BSI explicitly recommends integrating the assessment into development and continuous quality assurance processes, in an automated manner where possible. That is the bridge into delivery practice: the assessment belongs in the pipeline, not in an annual special event. How such a control catalogue sits methodologically alongside established frameworks is covered in our piece on the NIST Cybersecurity Framework 2.0.

Readiness checklist for 11 September 2026: artefact, owner, evidence

From the regulation and the guideline a short list can be derived that must be in place before the deadline. It is deliberately not complete in the sense of the CRA — it is complete in the sense of the question of what has to work on 11 September so that a notification actually goes out on time. Assign each item to a named role, not a team; a 24-hour deadline does not tolerate collective ownership.

The most effective test of that list is not a document review but a drill. Set a realistic scenario: an external reporter tells you on a Friday afternoon about a vulnerability that is demonstrably being exploited and affects a firmware generation two releases old. Measure how long it takes for someone with decision authority to hear about it, whether the "are we affected?" question is answerable from existing SBOMs, and whether the early warning can be populated with the known member states. Whatever fails in that drill will not work better under real pressure.

And document the drill. Market surveillance authorities may, on a reasoned request, demand all information and documentation necessary to demonstrate the conformity of the product and of the processes. A dated record of a rehearsed reporting process is the piece of evidence with the best effort-to-effect ratio there is — it demonstrates process maturity without a single real incident having occurred.

Context: one process instead of four compliance silos

The CRA is not the only framework demanding reporting routes in 2026, and not the only one with deadlines measured in hours. The European Commission situates the CRA within its overall system of horizontal cybersecurity requirements (see https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), and the BSI maintains the German framing together with pointers to the accompanying guidelines (see https://www.bsi.bund.de/dok/cyber-resilience-act). For organisations that both manufacture products and operate regulated services, the reporting routes run in parallel but are not identical.

The construction that holds is a shared detection and assessment process with several output paths: one detection, one reporting decision, then a branch by addressee and deadline. Four separate runbooks create gaps at exactly the interfaces where the shortest deadline tears. Where the frameworks overlap in detail and where they genuinely diverge is broken down in our 2026 regulatory collision piece; the German NIS2 duties with their own reporting route to the BSI are covered in the article on the NIS2 implementation act. Where your organisation stands there is what the NIS2 readiness check shows.

Concretely for the remaining weeks: use TR-03183-1 as a working template, not as reading material. Take the five preparation steps the BSI itself names — an honest cybersecurity risk assessment of the product including the assets to be protected and the threats to them, mitigation of identified risks to an acceptable level using appropriate controls, open and transparent communication in the users' best interest, maintaining product security throughout the lifecycle and cooperating with the authorities on vulnerabilities, and using existing best practices instead of reinventing the wheel. That is not a convenience simplification by the BSI but the order in which the work actually holds.

If you want to walk those steps with support — from taking stock through to a rehearsed reporting process — the scope and terms of our delivery governance engagements are set out under services and pricing. The fastest first step, though, remains your own: the product inventory, this week, one line per artefact.