BSI TR-03183
Die Technische Richtlinie des BSI zum Cyber Resilience Act, in vier Teilen: allgemeine Anforderungen, SBOM, Schwachstellen-Reports und Modul H. Stand: 2026-08-13.
Einordnung
Warum eine Technische Richtlinie, wenn es doch eine Verordnung gibt?
Der Cyber Resilience Act formuliert in Anhang I, welche Eigenschaften ein Produkt haben und welche Prozesse ein Hersteller betreiben muss - aber nicht, wie das technisch aussieht. Die dafür vorgesehenen harmonisierten Normen (allen voran die EN-40000-1-x-Serie) sind noch in Arbeit; keine davon ist bislang im EU-Amtsblatt zitiert, sodass für kein Produkt eine Konformitätsvermutung nach Art. 27 besteht.
Genau diese Lücke füllt die TR-03183: eine kostenlose, konkrete Umsetzungshilfe des BSI. Sie ist kein Gesetz und wird die EU-Normen nicht ersetzen, sobald diese vorliegen - aber wer heute anfängt, sammelt Praxiserfahrung an einem Katalog, der inhaltlich auf dieselben CRA-Anforderungen zielt wie die spätere Norm.
Zeitplan
- 10.12.2024CRA tritt in Kraft
- 11.09.2026Meldepflichten nach Art. 14 werden anwendbar (24h-Frühwarnung, 72h-Meldung, 14-Tage-Abschlussbericht)
- 11.12.2027Vollanwendung - alle Produkte mit digitalen Elementen müssen die Anforderungen erfüllen
Die vier Teile
TR-03183-1 bis TR-03183-3 und TR-03183-H
Risikobasierter Ansatz, Bewertungsverfahren und Entscheidungskriterien für die Umsetzung von Anhang I Teil I - kein fertiger Control-Katalog, sondern die Methode dahinter.
Deckt: Anhang I Teil I Nr. 1 · Anhang I Teil I Nr. 2 Buchst. a-m (methodisch)
Risikobasierter Ansatz nach ISO 31000
- Risikoidentifikation, -analyse, -bewertung, -behandlung, -dokumentation und -aktualisierung als durchlaufender Prozess
- Impact-Skala 1-5 mit Asset-Kategorien: Daten-Assets, Funktions-Assets, Sicherheits-Assets
- Umgebungsparameter zur Einordnung: Interface Restriction, Access Restriction, User Capability
- Akzeptanzkriterien nach Kap. 5.14.3 - welche Risiken ohne weitere Maßnahme tragbar sind
Bewertungsverfahren und Zeitpunkt
- Kontrollen werden mit PASS, FAIL oder N/A bewertet - N/A nur mit einem von vier zulässigen Gründen
- Bewertet wird der Werkszustand nach Erstkonfiguration laut Handbuch, auf der aktuellsten Softwareversion
- Pflichtinhalt des Assessment-Reports nach Kap. 4.8: Risikobewertung, Kontrollauswahl, Testnachweise, offene Punkte
ARC-Konzept (Adaptable Risk-based Controls)
- Kontrollen werden nicht pauschal, sondern abhängig vom Risikoprofil des konkreten Produkts ausgewählt
- Die konkreten Kontrollen selbst liegen als OSCAL-Katalog auf GitHub, Zugang nur auf Anfrage beim BSI
Pflichtfelder, zulässige Formate und Detailtiefe einer CRA-konformen SBOM - konkretisiert Anhang I Teil II Nr. 1.
Deckt: Anhang I Teil II Nr. 1
Format und Pflichtfelder
- CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, als JSON oder XML
- Zwei Pflichtfelder auf Ebene der SBOM insgesamt: Ersteller, Zeitstempel
- Elf Pflichtfelder je Komponente: Ersteller, Name, Version, Dateiname, Abhängigkeiten inkl. Vollständigkeitsangabe, Distributionslizenzen, SHA-512-Prüfsumme der auslieferbaren Komponente, Executable-, Archive- und Structured-Property
Detailtiefe und Klassen
- Detailtiefe: Top-Level-, n-Level-, transitive, Lieferumfang- oder vollständige SBOM - je nach Reifegrad wählbar
- SBOM-Klassen nach Entstehungszeitpunkt: Design, Source, Build, Analysed, Deployed, Runtime
Lizenzen und Abgrenzung zu Schwachstellendaten
- Lizenz-Identifikation über die Kaskade SPDX-Lizenzliste -> Scancode LicenseDB -> eigener LicenseRef-Bezeichner
- Eine TR-konforme SBOM darf keine Schwachstelleninformationen enthalten - dafür sind CSAF und VEX vorgesehen
Aufbau der security.txt, Rollen für die Meldestelle, Reaktionszeiten und Offenlegungsfristen - konkretisiert Anhang I Teil II und die Meldepflichten aus Art. 14 CRA.
Deckt: Anhang I Teil II Nr. 2, 4, 5, 6 · Art. 14 CRA (Meldepflichten)
security.txt nach RFC 9116
- Datei unter /.well-known/security.txt, signiert nach RFC 9580
- Feld Expires maximal ein Jahr in der Zukunft, Preferred-Languages muss en enthalten
- Reihenfolge der Kontakte: PSIRT-Mailbox, CSIRT-Mailbox, Meldeseite
- Auffindbarkeit für Web-Crawler sicherstellen
PSIRT und CSIRT als getrennte Rollen
- Zwei getrennte Rollen für die Schwachstellenannahme - außer bei Kleinstunternehmen nicht in einer Person
- Anonymes Webformular ohne Drittkomponenten und ohne Tracking
- Meldeseite ohne JavaScript und ohne Login erreichbar
Reaktionszeiten und Offenlegung
- Erste Reaktion binnen 5 Arbeitstagen, detaillierte Rückmeldung binnen 10 Arbeitstagen
- Öffentliche Offenlegung binnen 90 Tagen, einmalig um weitere 90 Tage verlängerbar
- Meldung mindestens über die European Vulnerability Database (EUVD) der ENISA; nationales CSIRT in Deutschland: CERT-Bund
Weg zur CRA-Konformität über ein bestehendes ISO/IEC-27001-ISMS statt über eine benannte Stelle je Produkt - relevant für Klasse-I- und Klasse-II-Produkte.
Deckt: Art. 32 CRA (Modul H) · Anhang VIII CRA
Geltungsbereich des ISMS
- Muss Design, Entwicklung und Produktion des Produkts umfassen
- Muss zusätzlich die Schwachstellenbehandlung und etwaige RDPS (Remote Data Processing Solutions) einschließen
- Risikoakzeptanzkriterien: Nichtkonformität mit dem CRA ist nicht akzeptabel; Risiken für betroffene Dritte nur bei angemessenem Sicherheitsniveau
Sechs CRA-spezifisch erweiterte Annex-A-Controls
- A.5.7 Threat Intelligence, A.5.8 Informationssicherheit im Projektmanagement
- A.8.8 Management technischer Schwachstellen, A.8.25 Sicherer Entwicklungslebenszyklus
- A.8.29 Sicherheitstests in Entwicklung und Abnahme, A.8.32 Änderungsmanagement
- Ergänzt um ISO-9001-Abschnitte 6.3 (Planung von Änderungen) und 8.3-8.7 (Entwicklung, Beschaffung, Produktion, Freigabe, Fehlerhafte Ergebnisse)
Dokumentation
- Technische Dokumentation nach Anhang VII CRA und Anhang VIII Nr. 3.2
- Strukturierte, maschinenlesbare Ablage (OSCAL) wird empfohlen
Anwendung
Wo die TR-03183 in diesen Tools ankommt
Die TR-03183 ist kein separates Werkzeug, sondern eine Referenz, die in den bestehenden CRA-Tools an den richtigen Stellen auftaucht.
Hintergrund
BSI TR-03183 und der Cyber Resilience Act
Die BSI TR-03183 („Cyber Resilience Requirements for Manufacturers and Products") übersetzt die abstrakt formulierten Anforderungen des Cyber Resilience Act in prüfbare technische Vorgaben. Sie ist in vier eigenständige Teile gegliedert, die jeweils einen anderen Abschnitt der Verordnung konkretisieren.
Formal begründet eine Technische Richtlinie keine Rechtspflicht. Für CRA-pflichtige Hersteller ist sie praktisch dennoch maßgeblich, solange keine harmonisierte EU-Norm im Amtsblatt zitiert ist: Sie ist die konkreteste verfügbare Auslegung dessen, was der CRA technisch verlangt, und wird zunehmend in Ausschreibungen und Lieferverträgen vorausgesetzt.
Häufige Fragen
Ist die BSI TR-03183 verpflichtend?
Formal ist sie eine Technische Richtlinie und kein Gesetz. Für Hersteller im Geltungsbereich des Cyber Resilience Act ist sie praktisch dennoch maßgeblich: Sie ist die konkreteste verfügbare Auslegung der CRA-Anforderungen, solange keine harmonisierte EU-Norm im Amtsblatt zitiert ist.
Ersetzen die EN-40000-Normen die TR-03183?
Ja, perspektivisch. Die TR-03183 wird sukzessive durch die entsprechenden harmonisierten europäischen Normen (vor allem die EN-40000-1-x-Serie) abgelöst, sobald diese fertiggestellt und im EU-Amtsblatt zitiert sind. Bis dahin bleibt sie der praktikabelste Einstieg.
Was ist neu an TR-03183-H?
TR-03183-H beschreibt Modul H nach Art. 32 CRA über ein bestehendes ISO/IEC-27001-ISMS - eine Alternative zur produktweisen Prüfung durch eine benannte Stelle (Modul B+C) für Hersteller, die bereits ein zertifiziertes ISMS betreiben.
Mehr dazu: BSI TR-03183 im Glossar · EN-40000-Serie im Glossar · Konformitätsbewertung im Glossar