BSI TR-03183-1: Die offizielle Einstiegshilfe in den Cyber Resilience Act — was bis zum 11.09.2026 stehen muss

Was das BSI am 5. August veröffentlicht hat — und was ausdrücklich nicht

Das Bundesamt für Sicherheit in der Informationstechnik hat die Technische Richtlinie TR-03183 Teil 1 „General Requirements" in der Version 1.0.0 veröffentlicht und positioniert sie als Einstiegshilfe in den Cyber Resilience Act. Zielgruppe sind nach eigener Aussage insbesondere Hersteller, die noch keine ausgereiften IT-Sicherheitsprozesse im Rahmen ihrer Entwicklung und Schwachstellenbehandlung etabliert haben (siehe https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/TR-03183_Einstiegshilfe_CRA_260805.html). Das ist eine bemerkenswert präzise Zielgruppendefinition: Die Richtlinie ist nicht für Organisationen geschrieben, die bereits ein reifes Produktsicherheitsprogramm betreiben, sondern für den viel größeren Rest.

Ebenso wichtig ist, was die TR-03183-1 ausdrücklich nicht ist. Das BSI stellt klar, dass das Dokument keinen verpflichtenden oder verbindlichen Charakter besitzt und nicht für eine Konformitätsvermutung genutzt werden kann. Es ist als lebendes Dokument angelegt und wird durch die korrespondierenden harmonisierten europäischen Normen ersetzt, sobald diese vorliegen (siehe https://www.bsi.bund.de/dok/TR-03183). Wer die Richtlinie als Compliance-Zertifikat missversteht, baut auf Sand — wer sie als strukturierte Landkarte durch die grundlegenden Anforderungen des CRA nutzt, spart mehrere Monate Eigenrecherche.

Genau darin liegt der praktische Wert für Delivery-Organisationen. Die TR-03183-1 fasst die Anforderungen aus den Artikeln und Anhängen des CRA in prüfbare Controls, ordnet ihnen Bewertungsverfahren zu und liefert einen Ansatz zur risikobasierten Auswahl von Sicherheitsmaßnahmen. Ergänzend stellt das BSI eine initiale Auswahl generischer Sicherheitsmaßnahmen im maschinenlesbaren Format OSCAL bereit. Das ist der Unterschied zwischen einer Verordnung, die Ziele formuliert, und einem Dokument, das Ihnen sagt, wie eine Bewertung aussieht, die diese Ziele belegt.

Ob Ihre Meldeprozesse für den 11.09.2026 belastbar sind, zeigt unser kostenloser CRA-Melde-Readiness-Check in rund drei Minuten — ohne Login, mit einer Auswertung, die Sie direkt in ein Steering-Deck übernehmen können.

Bis zum 11. September 2026: Was Artikel 14 wirklich verlangt

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt nach Artikel 71 grundsätzlich ab dem 11. Dezember 2027. Artikel 14 gilt jedoch bereits ab dem 11. September 2026, Kapitel IV mit den Artikeln 35 bis 51 ab dem 11. Juni 2026 (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Der 11. September 2026 ist damit der einzige Stichtag, der in diesem Quartal quer über NIS2, DORA, CRA und AI Act hinweg tatsächlich neue operative Pflichten scharf schaltet.

Artikel 14 kennt zwei Auslöser mit jeweils eigener Dreistufigkeit. Auslöser eins ist jede aktiv ausgenutzte Schwachstelle im Produkt: Frühwarnung unverzüglich, in jedem Fall binnen 24 Stunden nach Kenntniserlangung, unter Angabe der Mitgliedstaaten, in deren Hoheitsgebiet das Produkt bereitgestellt wurde. Danach binnen 72 Stunden die Schwachstellenmeldung mit Art der Ausnutzung und ergriffenen Korrektur- oder Risikominderungsmaßnahmen. Und spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht, der Abschlussbericht mit Schweregrad, Auswirkungen, Angaben zu bekannten Angreifern und zur bereitgestellten Sicherheitsaktualisierung.

Auslöser zwei ist jeder schwerwiegende Sicherheitsvorfall mit Auswirkung auf die Sicherheit des Produkts. Auch hier 24 Stunden Frühwarnung, auch hier 72 Stunden Vorfallsmeldung — der Abschlussbericht ist hier jedoch innerhalb eines Monats nach Übermittlung der 72-Stunden-Meldung fällig. Als schwerwiegend gilt ein Vorfall nach Artikel 14 Absatz 5, wenn er die Fähigkeit des Produkts beeinträchtigt, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten und Funktionen zu schützen, oder wenn er zur Einführung beziehungsweise Ausführung von Schadcode geführt hat oder führen kann.

Der Meldeweg ist in Absatz 7 geregelt und wird in der Praxis regelmäßig falsch geplant: Gemeldet wird über die nach Artikel 16 eingerichtete einheitliche Meldeplattform, an den elektronischen Meldeendpunkt des als Koordinator benannten CSIRT desjenigen Mitgliedstaats, in dem der Hersteller seine Hauptniederlassung in der Union hat — gleichzeitig zugänglich für die ENISA. Hauptniederlassung ist dabei der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Wer Entwicklung in Polen, Konzernsitz in den Niederlanden und Sicherheitsentscheidungen in Deutschland hat, sollte diese Frage vor dem 11. September beantwortet und dokumentiert haben, nicht während der ersten Frühwarnung.

Die Falle, die fast alle übersehen: Bestandsprodukte sind ab Tag eins dabei

Die häufigste Fehlannahme in Roadmaps lautet: Der CRA betrifft erst Produkte, die ab Dezember 2027 in den Verkehr gebracht werden. Für die wesentlichen Anforderungen stimmt das im Grundsatz — Produkte, die vor dem 11. Dezember 2027 in den Verkehr gebracht wurden, unterliegen ihnen nur bei einer wesentlichen Änderung. Für die Meldepflichten gilt jedoch ausdrücklich eine Abweichung: Die in Artikel 14 festgelegten Pflichten gelten für alle Produkte mit digitalen Elementen im Anwendungsbereich der Verordnung, die vor dem 11. Dezember 2027 in den Verkehr gebracht wurden (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj).

Operativ heißt das: Ab dem 11. September 2026 fällt Ihr gesamtes ausgeliefertes Portfolio unter die 24-Stunden-Frist — auch die Firmware-Generation von 2021, auch das On-Premise-Modul, das nur noch drei Kunden betreiben, auch die White-Label-Variante, die unter fremdem Namen läuft. Die Frage „Welche Artefakte haben wir eigentlich jemals in Verkehr gebracht, und wer beobachtet deren Schwachstellenlage?" ist damit keine Inventarisierungs-Fleißaufgabe mehr, sondern die Voraussetzung dafür, die Frist überhaupt einhalten zu können.

Für die Priorisierung der nächsten Wochen folgt daraus eine unbequeme, aber klare Reihenfolge. Zuerst das Produktinventar samt Zuordnung „fällt unter den CRA — ja/nein/unklar", danach die Benennung je Produkt, wer die Meldeentscheidung trifft, und erst danach die inhaltliche Arbeit an Anhang I. Wer umgekehrt mit der technischen Dokumentation beginnt, arbeitet an einer Frist, die erst in 16 Monaten läuft, und lässt die in fünf Wochen scharfe Frist offen. Den allgemeinen Rahmen dieser Meldepflicht haben wir im Beitrag Cyber Resilience Act: Die 24-Stunden-Meldepflicht ab September 2026 beschrieben; dieser Artikel setzt dort an, wo es um die konkrete Umsetzungshilfe geht.

Die vier Teile der TR-03183 und was jeder davon liefert

Die TR-03183 ist keine einzelne Richtlinie, sondern eine Reihe. Teil 1 „General Requirements" in Version 1.0.0 stellt die Anforderungen an Hersteller und Produkte in Anlehnung an Artikel und Anhänge des CRA zusammen. Teil 2 „Software Bill of Materials" liegt in Version 2.1.0 vor und beschreibt formelle und fachliche Vorgaben für SBOM. Teil 3 „Vulnerability Reports and Notifications" ist in Version 1.0.0 erschienen und regelt den Umgang mit eingehenden Schwachstellenmeldungen. Teil H „Conformity based on full quality assurance" liegt in Version 1.1.0 vor (siehe https://www.bsi.bund.de/dok/TR-03183).

Teil H verdient dabei besondere Aufmerksamkeit von jeder Organisation, die bereits ein Informationssicherheits-Managementsystem betreibt. Das BSI beschreibt darin die Möglichkeit, die umfassende Qualitätssicherung nach Modul H über ein ISO/IEC-27001-konformes ISMS — etwa den IT-Grundschutz — zu realisieren und damit Konformität zum CRA zu demonstrieren. Wer also bereits zertifiziert ist, muss kein zweites Managementsystem aufbauen, sondern die bestehenden Cybersicherheitsprozesse auf Produktentwicklung und Schwachstellenbehandlung ausweiten. Das ist der größte einzelne Effizienzhebel in der gesamten Richtlinienreihe.

Teil 2 ist der Teil mit den härtesten technischen Festlegungen und damit der, den Ihre Build-Pipeline unmittelbar betrifft. Eine neu erzeugte oder aktualisierte SBOM muss im JSON- oder XML-Format vorliegen und einer der genannten Spezifikationen entsprechen: CycloneDX in Version 1.6 oder höher oder SPDX in Version 3.0.1 oder höher, jeweils nur in offiziell veröffentlichten Fassungen. Die Spezifikationsübersicht von CycloneDX finden Sie unter https://cyclonedx.org/specification/overview/. Version 2.1.0 der Richtlinie ergänzt unter anderem eine Zuordnungsempfehlung zwischen den Datenfeldern der Richtlinie und den beiden Formaten sowie ein überarbeitetes Lizenzkapitel.

Auf Datenfeldebene wird es angenehm konkret: Jede SBOM muss mindestens den Ersteller — als E-Mail-Adresse oder ersatzweise als URL — und einen Zeitstempel der Datenerhebung enthalten, empfohlen in UTC. Für jede Komponente ist unter anderem der Komponenten-Ersteller anzugeben. Wer heute eine SBOM als Nebenprodukt eines Scanners erzeugt, ohne diese Felder zu füllen, hat ein Artefakt, das im Ernstfall nicht als Nachweis taugt. Ergänzend hat das BSI einen eigenen CycloneDX-Namensraum registriert und dessen Taxonomie im BSI-GitHub-Account veröffentlicht.

Teil 3: Der Eingangskanal, den Sie vor der ersten Meldung brauchen

Artikel 14 regelt, was Sie nach außen melden. Teil 3 der TR-03183 regelt die Gegenrichtung — und die entscheidet in der Praxis darüber, ob die 24-Stunden-Uhr überhaupt rechtzeitig startet. Denn Kenntnis von einer aktiv ausgenutzten Schwachstelle erlangen Hersteller in den meisten Fällen nicht durch eigenes Monitoring, sondern weil ein externer Melder sie darauf hinweist. Ein Eingangskanal, der eine Woche im Support-Postfach liegt, verwandelt eine eingehaltene Frist in eine gerissene.

Die Richtlinie macht dafür ungewöhnlich konkrete Vorgaben. Verlangt wird eine security.txt-Datei nach RFC 9116 mit kanonischer URI, Kontaktangaben, OpenPGP-Schlüsseln, bevorzugten Sprachen, Verweis auf die CVD-Policy und Ablaufdatum — auffindbar für Web-Crawler und digital signiert. Dazu kommt eine veröffentlichte Policy zur koordinierten Offenlegung von Schwachstellen, ein Webformular für Meldungen, benannte Sicherheitskontakte mit Verschlüsselungsoption sowie die Nennung des zuständigen nationalen CSIRT.

Am schärfsten sind die zugesicherten Reaktionszeiten: Auf eine Schwachstellenmeldung oder deren Aktualisierung muss binnen fünf Arbeitstagen eine einfache Rückmeldung erfolgen, und diese Rückmeldung darf ausdrücklich keine automatisierte Antwort sein. Eine detaillierte Rückmeldung nach weiterer Analyse ist binnen zehn Arbeitstagen fällig und muss entweder eine Bestätigung oder Zurückweisung der Schwachstelle, inhaltliche Rückfragen oder eine Begründung für die längere Prüfung samt Zusage einer Aktualisierung binnen zehn Arbeitstagen enthalten. Zusätzlich verlangt die Richtlinie eine leicht auffindbare Möglichkeit zur anonymen Meldung.

Für die Delivery-Governance sind das keine Web-Redaktionsaufgaben, sondern Kapazitätszusagen. Fünf Arbeitstage bis zur persönlichen Erstantwort bedeuten eine benannte, vertretungsgeregelte Rolle — keine Verteilerliste. Wer diese Rolle nicht besetzt hat, veröffentlicht mit der security.txt lediglich ein Versprechen, das er nicht halten kann. Die entsprechenden Prozess- und Rollenartefakte lassen sich mit unseren Governance-Vorlagen in wenigen Tagen erstellen, statt sie von Grund auf zu formulieren.

Der prüfbare Kern von Teil 1: Controls, Verdikte und ein unabhängiger Bewerter

Teil 1 ist als Selbstbewertung durch den Hersteller oder durch einen beauftragten Dritten angelegt. Die Richtlinie beschreibt dafür ein Rollenmodell, das Governance-Verantwortliche sofort wiedererkennen werden: Der Bewerter braucht ausreichende technische und methodische Kenntnis, Zugang zu allen bewertungsrelevanten Informationen und muss unparteiisch sein — nach Möglichkeit nicht an der Entwicklung des bewerteten Produkts beteiligt. Wo das nicht darstellbar ist, verlangt die Richtlinie zumindest eine ausdrücklich unabhängige Haltung.

Jedes Control besteht aus definierten Bestandteilen: einem normativen Kern, optional einem Risikoszenario, Ein- und Ausgaben bei Aktivitäten, einem Ziel, Bewertungs- und Umsetzungshinweisen, einer möglichen Kompensation und einer Referenz auf die gestützte CRA-Anforderung. Bewertet wird je Control mit PASS, FAIL oder N/A, wobei N/A nur zulässig ist, wenn eine referenzierte Kompensation erfüllt ist, der Zielmechanismus im Produkt nicht existiert, eine Wenn-Bedingung nicht greift oder das Control mit anderen Regulierungen kollidiert. Das Gesamtverdikt lautet PASS, wenn alle Controls PASS oder N/A sind — sonst FAIL.

Wichtig für die interne Kommunikation: Das BSI ordnet dieses Gesamtverdikt selbst ein. Ein FAIL bedeutet nicht zwingend, dass das Produkt nicht CRA-konform ist, und ein PASS bedeutet nicht, dass es konform ist — die Richtlinie deckt möglicherweise nicht alle Risiken des konkreten Produkts ab. Wer das Verdikt im Management-Reporting als Ampel verkauft, verkauft eine Gewissheit, die die Quelle ausdrücklich nicht hergibt. Die ehrliche Formulierung lautet: belegte Abdeckung der Richtlinie, nicht belegte Konformität.

Der methodische Kern ist ein risikobasierter Ansatz mit Risikobewertung, Risikoanalyse, Risikoevaluierung, Risikobehandlung, Dokumentation und regelmäßiger Aktualisierung — ergänzt um anpassbare risikobasierte Controls, die über Risikoszenarien und vordefinierte Risikoprofile ausgewählt werden. Das BSI empfiehlt ausdrücklich, die Bewertung in die Entwicklungs- und Qualitätssicherungsprozesse zu integrieren, wenn möglich automatisiert. Genau das ist die Brücke zur Delivery-Praxis: Die Bewertung gehört in die Pipeline, nicht in eine jährliche Sonderveranstaltung. Wie sich ein solcher Kontroll-Katalog methodisch neben etablierte Rahmenwerke stellt, zeigt unser Beitrag zum NIST Cybersecurity Framework 2.0.

Readiness-Checkliste für den 11.09.2026: Artefakt, Verantwortung, Nachweis

Aus der Verordnung und der Richtlinie lässt sich eine kurze Liste ableiten, die vor dem Stichtag stehen muss. Sie ist bewusst nicht vollständig im Sinne des CRA — sie ist vollständig im Sinne der Frage, was am 11. September funktionieren muss, damit eine Meldung fristgerecht rausgeht. Ordnen Sie jedem Punkt eine namentlich benannte Rolle zu, nicht ein Team; eine Frist von 24 Stunden verträgt keine kollektive Zuständigkeit.

Der wirksamste Test dieser Liste ist keine Dokumentenprüfung, sondern eine Übung. Setzen Sie ein realistisches Szenario an: Ein externer Melder weist Sie am Freitagnachmittag auf eine Schwachstelle hin, die nachweislich ausgenutzt wird und eine zwei Generationen alte Firmware betrifft. Messen Sie, wie lange es dauert, bis eine entscheidungsbefugte Person das erfährt, ob die Betroffenheitsfrage aus vorhandenen SBOM beantwortbar ist, und ob die Frühwarnung mit den bekannten Mitgliedstaaten gefüllt werden kann. Was in dieser Übung nicht funktioniert, wird im Ernstfall nicht besser funktionieren.

Und dokumentieren Sie die Übung. Marktüberwachungsbehörden können auf begründetes Verlangen alle Informationen und Unterlagen anfordern, die zum Nachweis der Konformität von Produkt und Prozessen erforderlich sind. Ein datiertes Protokoll eines geprobten Meldeprozesses ist dabei der Nachweis mit dem besten Verhältnis von Aufwand zu Wirkung — er belegt Prozessreife, ohne dass ein einziger echter Vorfall stattgefunden haben muss.

Einordnung: Ein Prozess statt vier Compliance-Silos

Der CRA ist nicht das einzige Rahmenwerk, das 2026 Meldewege verlangt, und er ist nicht das einzige mit Fristen im Stundenbereich. Die Europäische Kommission ordnet den CRA in ihre Gesamtsystematik der horizontalen Cybersicherheitsanforderungen ein (siehe https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), das BSI führt die deutsche Einordnung samt Verweis auf die begleitenden Richtlinien (siehe https://www.bsi.bund.de/dok/cyber-resilience-act). Für Organisationen, die zugleich Produkte herstellen und regulierte Dienste betreiben, laufen die Meldewege parallel, aber nicht identisch.

Die belastbare Konstruktion ist ein gemeinsamer Erkennungs- und Bewertungsprozess mit mehreren Ausgabepfaden: eine Erkennung, eine Meldeentscheidung, dann verzweigt nach Adressat und Frist. Vier getrennte Runbooks erzeugen genau an den Schnittstellen Lücken, an denen die kürzeste Frist reißt. Wie sich die Rahmenwerke im Detail überschneiden und wo sie tatsächlich auseinanderlaufen, haben wir in der Regulierungs-Kollision 2026 aufgeschlüsselt; die deutschen NIS2-Pflichten samt eigenem Meldeweg an das BSI behandelt der Beitrag zum NIS2-Umsetzungsgesetz. Wo Ihre Organisation dort steht, zeigt der NIS2-Readiness-Check.

Konkret für die verbleibenden Wochen: Nutzen Sie die TR-03183-1 nicht als Lesestoff, sondern als Arbeitsvorlage. Nehmen Sie die fünf Vorbereitungsschritte, die das BSI selbst nennt — ehrliche Risikobewertung des Produkts samt schützenswerter Werte und Bedrohungen, Minderung der identifizierten Risiken auf ein akzeptables Niveau mit geeigneten Controls, offene und transparente Kommunikation im Interesse der Nutzer, Aufrechterhaltung der Produktsicherheit über den Lebenszyklus samt Zusammenarbeit mit den Behörden, und die Nutzung bestehender bewährter Verfahren statt Neuerfindung. Das ist keine Vereinfachung des BSI aus Bequemlichkeit, sondern die Reihenfolge, in der die Arbeit tatsächlich trägt.

Wenn Sie diese Schritte begleitet gehen wollen — von der Bestandsaufnahme bis zum geprobten Meldeprozess — finden Sie den Zuschnitt und die Konditionen unserer Delivery-Governance-Mandate unter Leistungen und Preise. Der schnellste erste Schritt bleibt aber der eigene: das Produktinventar, diese Woche, mit einer Zeile pro Artefakt.