CRA-Normen werden konkret: Vier neue Bausteine für Hersteller

BSI TR-03183-1, prEN 40000-1-3, prEN 50742 und die Single Reporting Platform (SRP) der European Union Agency for Cybersecurity, kurz ENISA, machen die Vorbereitung auf den Cyber Resilience Act prüfbarer. Die neuen Veröffentlichungen zeigen nicht nur weitere Anforderungen, sondern vor allem, welche Entscheidungen und Nachweise Hersteller miteinander verbinden müssen.

Den Ausgangspunkt liefert unser Beitrag: Harmonisierte Standards für den CRA: Stand der Dinge. Dieser Artikel wiederholt weder den Normungsauftrag M/606 noch die allgemeinen CRA-Pflichten, sondern konzentriert sich auf die seitdem sichtbaren Veränderungen und ihre praktische Bedeutung.

Was seit dem letzten Normungsstand neu ist

Der Normungsauftrag M/606 umfasst weiterhin 41 Themen. Für die horizontalen Grundlagen und das Vulnerability Handling nennt er den 30. August 2026 als Liefertermin, doch dieser Termin ist nicht mit einer Referenz im Amtsblatt gleichzusetzen.

Genau diese Unterscheidung ist im August 2026 wichtig. Das Kürzel prEN kennzeichnet einen europäischen Norm-Entwurf. Eine Konformitätsvermutung entsteht erst, wenn die Referenz einer harmonisierten Norm im Amtsblatt der EU veröffentlicht wurde, und gilt nur für die von ihr abgedeckten Anforderungen nach Artikel 27 CRA. Das verschiebt keine CRA-Frist. Die Meldepflichten gelten ab dem 11. September 2026 und der CRA gilt nach Artikel 71 grundsätzlich ab dem 11. Dezember 2027. Hersteller sollten daher jetzt mit der Umsetzung beginnen und ihre Entscheidungen bis zur Veröffentlichung harmonisierter Normen unmittelbar anhand der CRA-Anforderungen dokumentieren.

Vier Veröffentlichungen schaffen trotzdem eine bessere Arbeitsgrundlage. Die BSI TR-03183-1 liegt seit dem 31. Juli 2026 in Version 1.0.0 vor, prEN 40000-1-3 beschreibt einen überprüfbaren Vulnerability-Handling-Prozess, prEN 50742 verbindet Manipulationsschutz mit Maschinensicherheit und ENISA hat konkrete Bedien- und Datenhinweise zur Single Reporting Platform veröffentlicht.

BSI TR-03183-1 wird zum Assessment-Gerüst

Die BSI TR-03183-1 in Version 1.0.0 bezeichnet sich weiterhin als Living Document. Das BSI stellt ausdrücklich klar, dass die Richtlinie keine Herstellerpflichten begründet, nicht immer den aktuellen Stand der europäischen Normung abbildet und keine Konformitätsvermutung erzeugt.

Die Richtlinie ist dennoch konkreter als eine Sammlung von Empfehlungen. Sie beschreibt eine Selbstbewertung oder Bewertung durch Dritte, verlangt dokumentierte Prüfschritte und unterscheidet zwischen Aktivitäten, technischen Mechanismen und Dokumentation. Verbindlich formulierte Controls, also einzeln prüfbare Anforderungen an Aktivitäten, technische Mechanismen oder Dokumentation, werden mit PASS, FAIL oder begründetem N/A bewertet.

Wenn du die Grundlagen und den Rechtsstatus der Richtlinie nachlesen möchtest, schau in unseren älteren Artikel: CRA umsetzen mit EUCC und BSI TR-03183. Neu ist jetzt vor allem, wie sich aus der Risikobewertung eine reproduzierbare Prüfung ableiten lässt.

Die neue Erkenntnis liegt damit nicht in einem weiteren Katalog solcher Prüfpunkte. Ein Hersteller kann die TR als Probe für die spätere Konformitätsbewertung nutzen und prüfen, ob aus jeder risikobasierten Entscheidung ein nachvollziehbares Ergebnis entsteht.

prEN 40000-1-3 verbindet den Schwachstellenfall

Der öffentlich diskutierte Entwurfsstand von prEN 40000-1-3 gliedert Vulnerability Handling in sechs Phasen. Die CEN/CENELEC-Unterlagen zum Entwurf nennen Preparation, Receipt, Verification, Remediation, Release und Post-Release.

Die einzelnen Tätigkeiten sind nicht neu. Eine Coordinated Vulnerability Disclosure Policy, eine erreichbare Meldestelle, eine Software Bill of Materials, kurz SBOM, Triage, Patches und Security Advisories behandeln wir bereits ausführlich in unserem Artikel: CVD-Policy unter dem CRA. Eine SBOM ist dabei eine maschinenlesbare Stückliste der in einem Produkt enthaltenen Softwarekomponenten, Versionen und Abhängigkeiten.

Neu ist die geschlossene Nachweiskette über alle sechs Phasen. Ein Schwachstellenfall sollte nicht als loses Bündel aus E-Mail, Entwicklungsticket, Testergebnis und Advisory enden, sondern über eine gemeinsame Fallkennung verbunden bleiben.

Sie haben noch keine belastbare SBOM oder keine durchgängige Fallkennung über Meldung, Analyse und Behebung hinweg? Unser Einstiegsworkshop für SBOM und Software-Lieferketten klärt Datenquellen, Formate und einen realistischen Pilotumfang.

Eine SBOM ist in diesem Modell kein isoliertes Compliance-Artefakt. Sie verbindet den Eingang einer Komponentenwarnung mit den betroffenen Produktversionen, der technischen Bewertung und dem späteren Update. Für Embedded- und OT-Produkte beschreiben wir die Datengrundlage separat: SBOM für Embedded-Systeme.

prEN 40000-1-3 bleibt ein Entwurf. Teams können die sechs Phasen für eine Gap-Analyse nutzen, sollten aber Entwurfsfassung, Annahmen und einen Termin zur Neubewertung dokumentieren.

prEN 50742 verbindet Safety und Security

Der DIN-Entwurf zu prEN 50742 behandelt den Schutz von Maschinen vor unbeabsichtigter und vorsätzlicher Manipulation, wenn daraus eine gefährliche Situation entstehen kann. Er bezieht Hardware, Software, Daten und externe Maschinenschnittstellen über die Lebenszyklusphasen von der Entwicklung bis zur Außerbetriebsetzung ein.

Die Rechtsgrundlage ist nicht der CRA, sondern die Maschinenverordnung (EU) 2023/1230. Deren Anhang III fordert in den Abschnitten 1.1.9 und 1.2.1 Schutz vor Manipulation sowie sichere und zuverlässige Steuerungssysteme. Einen breiteren Überblick zu den Regelungsschnittstellen bietet unser Artikel: Der CRA und angrenzende EU-Vorschriften.

Für Maschinenbauer entsteht daraus eine neue Verbindung. Die CRA-Risikobewertung fragt nach dem Cybersecurity-Risiko eines Produkts, während die Safety-Betrachtung prüft, ob eine Manipulation zu einer Gefährdung führen kann. Beide Bewertungen können dasselbe Architekturmodell, dieselben Schnittstellen und dieselben Datenflüsse verwenden, dürfen aber ihre unterschiedlichen Schutzziele nicht vermischen.

Bei einer Safety-SPS beginnt die gemeinsame Spur beispielsweise an der Engineering-Schnittstelle. Von dort führt sie über eine mögliche unautorisierte Konfigurationsänderung zur betroffenen Sicherheitsfunktion, zur Gefährdung, zur Security-Maßnahme und schließlich zu Security- und Safety-Tests.

Ein gemeinsames technisches Modell spart doppelte Pflege. Getrennte Freigaben und Akzeptanzkriterien bleiben trotzdem notwendig, weil Product Security und Functional Safety unterschiedliche Risiken bewerten und häufig unterschiedliche verantwortliche Rollen haben.

Die ENISA-Plattform verändert den Meldeprozess

Die Meldearten und Fristen aus Artikel 14 haben wir bereits beschrieben: CRA-Meldepflichten ab September 2026. Neu sind die im August veröffentlichten ENISA-Anleitungen zur Single Reporting Platform.

Die Plattform soll zum 11. September 2026 betriebsbereit sein. Der öffentlich zugängliche Produktiv-Link war zum Redaktionsstand dieses Artikels noch nicht veröffentlicht, aber Registrierung, Rollenmodell, Meldeablauf und Datenfelder sind inzwischen beschrieben.

Assigned Representatives authentisieren sich über EU-Login und wählen das zuständige nationale Computer Security Incident Response Team, kurz CSIRT. ENISA unterscheidet eine primäre und eine sekundäre Vertretung und weist darauf hin, dass eine ausstehende Validierung die Abgabe einer Meldung nicht verhindert.

Eine wichtige Feinheit widerspricht dem naheliegenden Vorgehen. ENISA empfiehlt, die SRP-Registrierung und Validierung nicht vorsorglich zu starten, sondern erst im konkreten Meldefall, um die CSIRTs nicht mit Vorabprüfungen zu belasten. Ein EU-Login sowie intern benannte Haupt- und Ersatzpersonen können dagegen schon heute vorbereitet werden.

Auch technisch ist Zurückhaltung nötig. Laut ENISA FAQ zur SRP wird zunächst keine Programmierschnittstelle bereitgestellt. Hersteller können ihren internen Ablauf automatisieren, müssen die Meldung aber vorerst manuell über die Plattform abgeben.

Eine öffentlich zugängliche Sandbox weist ENISA zum Redaktionsstand nicht aus. Zwar ist vor dem Start eine Testphase vorgesehen, für Hersteller sind bislang aber vor allem Leitfäden, weitere Lernmaterialien und ein Webinar angekündigt. Den Ablauf sollten Teams deshalb zunächst mit einer internen Meldevorlage und einem Tabletop-Test proben.

Der sinnvollste Vorbereitungsschritt ist deshalb kein Integrations-Projekt, sondern ein interner Meldedatensatz. Er sollte Hersteller, Produkt, Produktklasse, betroffene Mitgliedstaaten, CVE- oder EUVD-Kennung, technische Einordnung, Gegenmaßnahmen, Zeitpunkte und die Sensitivität der Informationen enthalten.

Dabei sollte die SRP nicht als gemeinsamer Arbeitsbereich eingeplant werden. Ein dort gespeicherter Entwurf ist laut aktueller ENISA-Anleitung nur für die Person sichtbar, die ihn angelegt hat. Das interne Fallmanagement muss daher alle freizugebenden Inhalte enthalten und auch bei Ausfall der primären Vertretung funktionieren.

Ein Nachweismodell statt vier Einzelprojekte

Die vier Veröffentlichungen greifen ineinander, wenn Produkt- und Fallkennungen konsistent sind. Die BSI TR bewertet den risikobasierten Produktzustand, prEN 40000-1-3 strukturiert einzelne Schwachstellenfälle, prEN 50742 ergänzt bei Maschinen die Verbindung zur Gefährdung und die SRP verwendet einen Teil dieser Informationen für die Behördenmeldung.

Das führende System kann ein Application-Lifecycle-Management-Werkzeug, ein Product-Lifecycle-Management-System oder zunächst eine kontrollierte Dokumentenstruktur sein. Entscheidend ist nicht das Tool, sondern dass eine prüfende Person von der Anforderung bis zum Produktzustand und vom Schwachstellenhinweis bis zur externen Meldung navigieren kann.

Was Hersteller bis September testen sollten

Die neuen Dokumente rechtfertigen keinen Neustart der CRA-Umsetzung. Sie liefern bessere Prüfpunkte für bereits vorhandene Prozesse.

1. Halte für jede verwendete Richtlinie und jeden Entwurf Version, Bezugsquelle, Annahmen und nächsten Review-Termin fest.
2. Spiele eine bereits behobene Schwachstelle durch die sechs Phasen von prEN 40000-1-3 und erfasse fehlende Übergaben oder Nachweise.
3. Prüfe bei Maschinen an einem sicherheitsrelevanten Interface, ob Threat Model, Manipulationsszenario und Safety-Gefährdung miteinander verknüpft sind.
4. Benenne Haupt- und Ersatzpersonen für die SRP, bereite deren EU-Login vor und überführe die ENISA-Datenfelder in eine interne Meldevorlage.
5. Prüfe am Ende, ob Produktakte, Vulnerability Case, Update und möglicher SRP-Datensatz dieselben Produkt- und Versionskennungen verwenden.

Ein solcher Probelauf zeigt mehr als eine weitere allgemeine CRA-Checkliste. Er macht sichtbar, ob Informationen unter Zeitdruck auffindbar, technisch belastbar und freigabefähig sind.

Der neue Maßstab ist die Verbindung der Nachweise

Der erste Fortschritt der CRA-Standardisierung besteht nicht darin, dass Hersteller ihre Verantwortung an eine Norm abgeben können. BSI TR-03183-1 und die Norm-Entwürfe erzeugen für sich genommen keine Konformitätsvermutung, während die Single Reporting Platform einen internen Incident-Prozess nicht ersetzt.

Sie machen aber deutlicher, wie spätere Prüfungen aussehen können. Risiken müssen zu Controls führen, Controls zu überprüfbaren Ergebnissen, Schwachstellen zu dokumentierten Entscheidungen und meldepflichtige Fälle zu einem freigegebenen Datensatz.

Wer diese Verbindungen jetzt an einem realen Produkt und einem realen Schwachstellenfall testet, gewinnt eine neue Qualität der Vorbereitung. Die Organisation sammelt nicht nur Dokumente, sondern kann ihre Entscheidungen über Produktentwicklung, Betrieb, Updates und Meldungen hinweg erklären.

Wie verbindest du Produktrisiken, Schwachstellenfälle und CRA-Meldungen zu einer belastbaren Nachweiskette? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.