CRA 2/5: Der Backbone des CRA: Warum ohne korrekte Cyber-Risikobewertung gar nichts läuft

Die Bewertung des Cybersicherheitsrisikos ist im Cyber Resilience Act nicht ein Kapitel unter vielen, sondern die Klammer über die gesamte Verordnung. Sie entscheidet, mit welcher Tiefe und Ausgestaltung die Anforderungen aus Annex I Teil I (dazu mehr in unserem dritten CRA-Artikel) für ein konkretes Produkt umzusetzen sind. Ob eine Anforderung überhaupt anwendbar ist, ergibt sich dagegen primär aus der Produktarchitektur — nicht aus der Risikobewertung selbst. Und sie ist die Voraussetzung dafür, dass ein Hersteller gegenüber Marktüberwachungsbehörden begründen kann, warum er bestimmte Maßnahmen ergriffen hat — und andere nicht für erforderlich hielt. So einfach der Gesetzestext klingt: Die drei Verben „konzipiert, entwickelt und hergestellt” markieren drei Phasen mit je eigenen Anforderungen.

Dieser Artikel konzentriert sich auf die erste, die Konzipierung — und sie beginnt mit der Identifikation der Risiken. Darüber hinaus erklärt er die Methodik von Grund auf: Begriffe, Vorgehen, Werkzeuge, typische Fehler.

Und es soll dargelegt werden, warum Security by Design keine Option ist, die sich nachträglich nachrüsten lässt.

Alle Begriffe zur CRA-Cybersicherheits-Risikobewertung erklärt

Eine Risikobewertung ist nur so gut wie die gemeinsame Sprache des Teams, das sie erstellt. Das liegt nicht nur an der Rolle, sondern auch am Hintergrund: Automotive, Luftfahrt und klassische Softwareentwicklung sprechen jeweils ihre eigene Sprache — und selbst Product-Security und IT-Security verwenden für dieselben Sachverhalte teils unterschiedliche Begriffe.

Die folgenden Begriffe sind die Grundbausteine jeder CRA-konformen Risikobewertung:

• Asset — Die BSI TR-03183 (Abschnitt 5.8.1.1.1) fasst Assets als alles am PwDE Schützenswerte: das Produkt selbst, seine Komponenten und Funktionen sowie alle Daten, die es erhebt, speichert oder anderweitig verarbeitet. Entscheidend ist dabei auch die mitgelieferte Einschränkung: Die Asset-Liste soll nichts außerhalb des PwDE enthalten, weil das Produkt es nicht direkt schützen kann und jeder relevante externe Wert ohnehin ein korrespondierendes Asset im Produkt hat. Diese Grenze wird in der Praxis oft missachtet: Es geht nicht um alle denkbaren Werte, die das Produkt irgendwie beeinflusst, sondern um das, was es selbst enthält, verarbeitet oder steuert — und damit selbst schützen kann.

Die TR-03183 unterscheidet drei Asset-Typen, die sich für die meisten Produkte als tragfähige Gliederung erwiesen haben:

• Daten-Assets sind alle Daten, die das Produkt erzeugt, speichert, überträgt oder verarbeitet — von personenbezogenen Daten (PII) über Konfigurationsdaten bis zu Telemetrie ohne Personenbezug. Die TR-03183 liefert je Daten-Typ vorgefertigte C/I/A-Basiswerte (Skala 1–5) als Ausgangspunkt der Impact-Bewertung.
• Funktionale Assets sind die Kernfunktionen — das, wofür das Produkt gebaut wurde. Ein Router hat die Routing-Funktion, ein Passwortmanager die sichere Speicherung und Wiedergabe von Zugangsdaten. Funktionale Assets sind primär in der Verfügbarkeitsdimension (Availability) relevant.
• Security Assets sind Mechanismen und Daten, die andere Assets schützen — Schlüssel, Zertifikate, Credentials, kryptografische Mechanismen, Authentifizierungsfunktionen. Ihr Impact leitet sich aus dem der geschützten Assets ab: Ein Schlüssel, der die Vertraulichkeit von Gesundheitsdaten (Impact Confidentiality: 4) sichert, trägt denselben Confidentiality-Impact wie die Gesundheitsdaten selbst.

Profis dürfen weiter scrollen: Das CIA-Modell fix erklärt — drei Schutzdimensionen pro Asset

Jedes Asset wird entlang von drei Achsen bewertet:

• Confidentiality (Vertraulichkeit): Darf das Asset nur Berechtigten zugänglich sein? Ein Verlust bedeutet unbefugten Zugang zu Daten oder Funktionen — durch Datenlecks, abgefangene Kommunikation oder kompromittierte Zugangsdaten.
• Integrity (Integrität): Darf das Asset nur autorisiert verändert werden? Ein Verlust bedeutet unautorisierte Manipulation von Daten, Konfigurationen oder Firmware — durch Tampering, Man-in-the-Middle-Angriffe oder kompromittierte Update-Kanäle.
• Availability (Verfügbarkeit): Muss das Asset zuverlässig nutzbar bleiben? Ein Verlust bedeutet, dass Funktionen oder Daten nicht mehr zugänglich sind — durch Denial-of-Service-Angriffe, Ransomware oder angriffsbedingte Hardwareausfälle.

Der in der Praxis oft übersehene Punkt: Ein einzelnes Asset kann in allen drei Dimensionen gleichzeitig schutzbedürftig sein. Jede Dimension verlangt dabei möglicherweise eigene, unterschiedliche Schutzmaßnahmen.

Am Beispiel von Nutzer-Credentials in einem vernetzten Gerät:

• Confidentiality: Gespeicherte Passwörter dürfen nicht ausgelesen werden

→ Verschlüsselung der Credential-Speicherung, Schutz vor Speicherauslesung

• Integrity: Das Passwort darf nicht unbefugt verändert werden

→ Zugriffskontrollen auf die Credential-Verwaltung, Audit-Logging von Änderungen

• Availability: Der Login-Mechanismus muss auch unter Last oder Angriff funktionieren

→ Rate Limiting gegen Brute-Force, Resilienz gegen DoS auf den Authentifizierungsendpunkt

Ein einzelner Mechanismus, etwa nur starke Verschlüsselung, adressiert allein die Confidentiality. Security by Design heißt aber, für jedes Asset alle drei Dimensionen systematisch durchzudenken und mit passenden Maßnahmen zu belegen.

In der Praxis wird die CIA-Trias häufig um eine vierte Dimension ergänzt: Authenticity — die Gewissheit über die Echtheit einer Datenquelle oder eines Kommunikationspartners. Gerade beim Austausch kryptografischer Schlüssel ist entscheidend, dass man der Identität des Senders vertrauen kann; je nach Anwendungsfall kommt Non-Repudiation (die Nachweisbarkeit, dass eine Aktion tatsächlich von einem bestimmten Akteur stammt) hinzu. Der CRA-Text führt Authenticity nicht als eigene Kategorie, adressiert sie aber über die Anforderungen an Integrität und Zugriffsschutz — in methodischen Rahmenwerken wird sie dagegen meist explizit als eigene Schutzdimension geführt.

Was sind Threat, Risk und Incident im Cyber Resilience Act? Drei Begriffe, drei Funktionen

Die CRA-Risikobewertung arbeitet mit drei im Gesetzestext (s. Art. 3) definierten Kernbegriffen, die methodisch sauber zu trennen sind.

Kurzer Einschub: Die Beschäftigung mit diesen Cybersecurity-Grundlagen ist längst mehr als Compliance. Cybersicherheit entwickelt sich vom nachgelagerten Kostenfaktor zum Produktmerkmal. Wer sie beherrscht, verschafft sich einen Vorsprung, der weit über die Erfüllung regulatorischer Mindestanforderungen hinausreicht.

Also, einmal erklärt:

• Eine Bedrohung (Threat) ist nach Art. 3 Nr. 46 (i. V. m. Art. 2 Nr. 8 der Verordnung (EU) 2019/881) jede potenzielle Situation, jedes potenzielle Ereignis oder jede potenzielle Handlung, die ein Netz- und Informationssystem, dessen Nutzer oder andere Personen schädigen, stören oder anderweitig beeinträchtigen kann. Sie beschreibt das Potenzial für einen negativen Ausgang — ohne Aussage über Wahrscheinlichkeit oder Ausmaß. Sie ist Ausgangspunkt der Analyse, nicht ihr Ergebnis. Diese Legaldefinition stammt aus dem Cybersecurity Act und ist auf Netz- und Informationssysteme gemünzt — im CRA-Kontext ist sie auf das Produkt zu lesen: Die Bedrohung richtet sich gegen das PwDE, seine Komponenten, Funktionen und Daten. Näher am Produkt denkt die ISO/SAE 21434, die (streng genommen für das Threat Scenario) die potenzielle Ursache der Kompromittierung von Cybersecurity-Eigenschaften eines oder mehrerer Assets beschreibt — genau die asset-zentrierte Denkweise, die im Produktkontext trägt.
• Ein Risiko (Risk) ist nach Art. 3 Nr. 37 das Potenzial für Verluste oder Störungen durch einen Sicherheitsvorfall, ausgedrückt als Kombination aus dem Ausmaß des Verlusts und der Eintrittswahrscheinlichkeit. Das Risiko ist damit das Produkt aus Impact und Likelihood — und genau diese Kombination entscheidet, ob es behandelt werden muss oder akzeptiert werden kann.
• Ein Sicherheitsvorfall (Incident) ist nach Art. 3 Nr. 43 ein tatsächlich eingetretenes Ereignis mit negativem Effekt auf die Sicherheit von Netz- und Informationssystemen. Der Incident ist der Auslöser der CRA-Meldepflichten aus Artikel 14 — also die Realisierung eines Risikos, nicht das Risiko selbst.

Die Abgrenzung hat operative Konsequenzen: Eine bekannte Schwachstelle in einer verwendeten Komponente ist zunächst eine Bedrohung. Ob und wie dringend sie behandelt werden muss, folgt aus der Risikobewertung (Impact × Likelihood). Wird sie aktiv ausgenutzt, wird sie zum Incident — und löst die CRA-Meldepflicht nach Art. 14 Abs. 1 (vorgestellt in unserem ersten CRA-Artikel) aus.

Auch zeitlich liegen die drei Begriffe auseinander: Threats und Risiken werden vorausschauend betrachtet, beginnend in der Entwicklung und fortlaufend über den gesamten Lebenszyklus. Von einem Incident spricht man dagegen erst, wenn sich ein Risiko am ausgelieferten Produkt im Feld realisiert — und genau dieser Übergang ins Feld ist es, der die Meldepflicht auslöst.

STRIDE — strukturierte Bedrohungsidentifikation

Für die systematische Identifikation von Bedrohungen empfiehlt sich ein strukturiertes Modell. Das in der Praxis verbreitetste ist STRIDE, ursprünglich von Microsoft entwickelt, heute Standard der Threat-Modellierung:

• Spoofing — Identitätsvortäuschung: Ein Angreifer gibt sich als legitimer Nutzer, System oder Dienst aus
• Tampering — Manipulation: unbefugte Veränderung von Daten, Code oder Konfiguration
• Repudiation — Abstreitbarkeit: Ein Akteur kann eine Handlung bestreiten, weil ausreichende Audit-Logs fehlen
• Information Disclosure — Datenleck: Zugriff auf Daten, die nicht für den Angreifer bestimmt sind
• Denial of Service — Verfügbarkeitsangriff: Beeinträchtigung oder Ausfall von Funktionen durch Überlastung oder gezielte Sabotage
• Elevation of Privilege — Rechteausweitung: Ein Angreifer erlangt höhere Berechtigungen, als ihm zustehen

STRIDE gibt Entwicklungsteams eine schnelle, vollständige Checkliste: Für jede Komponente und jede Schnittstelle wird durchgefragt, welche der sechs Angriffsklassen relevant ist. Kein Ersatz für eine tiefe Bedrohungsanalyse, aber ein effektiver Startpunkt, der verhindert, dass eine grundlegende Bedrohungsklasse übersehen wird.

Die Brücke zur CIA-Trias ergibt sich fast von selbst: Spoofing und Information Disclosure treffen primär Confidentiality; Tampering und Repudiation treffen Integrity; Denial of Service trifft Availability; Elevation of Privilege kann alle drei Dimensionen betreffen, weil erweiterte Rechte die Ausnutzung aller übrigen Schwachstellen erst ermöglichen. Der Wert des STRIDE-Modells liegt genau hier: Es denkt vom Angriff her und deckt so systematisch auf, über welche Wege sich welche CIA-Eigenschaft verletzen lässt.

Hallo DIN EN 40000 — die kommende Normenfamilie, und warum sie jetzt schon zählt

Wer die CRA-Risikobewertung praktisch umsetzt, stößt mittelfristig auf die EN 40000-Normenfamilie, den ersten horizontalen europäischen Normensatz, der direkt unter dem CRA-Normungsauftrag M/606 von CEN/CENELEC entsteht.

Zwei Teile sind für die Risikobewertung besonders relevant:

• EN 40000-1-2 definiert die übergeordneten Risikomanagement-Prinzipien und Lifecycle-Aktivitäten — der methodische Kern, konzeptionell deckungsgleich mit dem, was dieser Artikel beschreibt.
• TR 40000-1-5 ist ein ergänzender technischer Bericht zu Threats und Security Objectives für die Risikobewertung — ein Hilfsdokument für die praktische Anwendung von EN 40000-1-2. Anders als die übrigen Teile ist es ein Technical Report, kein normativer Standard: Es begründet keine Konformitätsvermutung und liegt nach aktuellem Stand nur als Entwurf vor, ohne veröffentlichte Fassung.

Sobald EN 40000-1-2 im EU-Amtsblatt referenziert ist, begründet ihre Anwendung Konformitätsvermutung nach Art. 27. Klingt kompliziert, bedeutet letztlich nur: Wer die Norm anwendet, muss nicht mehr separat nachweisen, dass seine Risikobewertung die CRA-Anforderungen erfüllt; es wird vermutet.

Alle Teile der EN 40000-Normenreihe sind noch Entwürfe, aber unterschiedlich weit: 1-1 bis 1-3 liegen bereits als kommentierbare Drafts vor (Public Enquiry durchlaufen), 1-4 und der TR 1-5 sind früher dran. Referenziert im EU-Amtsblatt — und damit für die Konformitätsvermutung wirksam — ist noch keiner.

Bis zur Finalisierung eignet sich die vom BSI veröffentlichte BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products als pragmatischste Arbeitsgrundlage — und der inhaltliche Abstand zwischen beiden ist gering genug, dass ein späterer Wechsel keine Neuerfindung bedeutet.

Also weiter im Text, mit dem Ziel:

Die Grundlagen der CRA-Cybersicherheits-Risikobewertung verstehen

Beginnen wir mit der einfachen Frage: Was soll überhaupt bewertet werden? Oder formaler ausgedrückt: Es gilt, den Bewertungsgegenstand festzulegen.

Bevor die Bewertung beginnt, muss feststehen, was überhaupt bewertet wird. Bereits daran scheitern (auch versierte!) Teams häufiger, als man vermuten würde. Einfach, weil Entwickler, Produktmanager und Security-Verantwortliche fundamental unterschiedlich definieren, was überhaupt „das Produkt” ist.

Ausgangspunkt ist ein Kontextdiagramm, das das Produkt als Black Box in seiner Umgebung zeigt. Es beantwortet die zentrale Frage der gesamten Risikobewertung: Was gehört zum Bewertungsgegenstand, was nicht? Diese Grenzen heißen Item Boundaries.

Dabei gilt: Erfasst werden alle datenfähigen Schnittstellen — physisch wie logisch —, ob genutzt oder nicht. Besonders bei zugekauften COTS-Komponenten werden Debug-Ports, ungenutzte Funkschnittstellen oder standardmäßig offene Dienste leicht übersehen — und werden so zur unerkannten Angriffsfläche.

Zum besseren Verständnis hier konkrete Grenzentscheidungen, die in der Regel explizit zu treffen sind:

• Gehört der OTA-Update-Server des Herstellers zum PwDE? Das kommt auf die Modellierung an — und ist regulatorisch nicht abschließend geklärt. Zwingend zum PwDE gehört das Update-Interface im Produkt selbst: der Mechanismus, der Updates abruft, per TLS überträgt, Signaturen prüft und Rollbacks verhindert (Annex I Teil I, Integrität). Den Server dahinter kann man sauber als externen Endpunkt jenseits der Produktgrenze behandeln — seine Sicherheit wird dann nicht über den Produkt-Scope, sondern über die Pflicht zu sicheren Update-Verteilungsmechanismen (Annex I Teil II Nr. 7) und ggf. NIS2 erfasst. Zum vollwertigen RDPS — und damit in die Produktgrenze — wird der Server erst, wenn er über die reine Update-Auslieferung hinaus eine operative Kernfunktion trägt (z. B. Geräteverwaltung oder funktional notwendige Fernverarbeitung), ohne die das Produkt nicht funktioniert.
• Gehört die Weboberfläche zur Produktkonfiguration dazu? Wenn vom Hersteller entwickelt und für die Konfiguration notwendig — ja.
• Gehört die Netzinfrastruktur, über die das Produkt kommuniziert, dazu? Nein — sie liegt außerhalb der Herstellerverantwortung und damit außerhalb der Item Boundaries.
• Gehören Drittanbieter-Apps, die Nutzer selbst installieren, dazu? Der App-Code selbst nie. Aber es kommt darauf an, wo sie läuft: auf einem fremden Gerät (Handy) → nur die Kommunikationsschnittstelle ist im Scope; auf dem Produkt selbst → das Produkt ist Ausführungsplattform, und Sandboxing, Isolation, Berechtigungsmodell und lokale APIs gehören vollständig in die Bewertung. Verantwortet wird nicht die App, sondern die Isolation um sie herum.

Wichtig ist: Ein generelles Richtig oder Falsch gibt es hier in der Item Definition nicht.

Aber die Entscheidungen müssen getroffen, dokumentiert und konsequent angewendet werden. Eine Marktüberwachungsbehörde, die die technische Dokumentation prüft, erwartet auch an dieser Stelle nachvollziehbare Begründungen, keine impliziten Annahmen.

Auf Basis des Kontextdiagramms wird die Produktarchitektur beschrieben: Welche Komponenten enthält das Produkt, über welche Schnittstellen kommunizieren sie intern und extern, welche Kommunikationsbeziehungen bestehen zu RDPS-Komponenten? Ein Funktionsdiagramm ergänzt die Kernfunktionen und ihre Abhängigkeiten. Dafür braucht es nicht jedes Implementierungsdetail, aber genug, um Angriffspfade zu identifizieren.

Mindestens ebenso wichtig ist die Beschreibung der Betriebsumgebung: In welchem Kontext und unter welchen Rahmenbedingungen läuft das Produkt? Ein industrielles Steuergerät in abgeschotteter OT-Umgebung ohne Internetverbindung, bedient von geschulten Operatoren, hat ein fundamental anderes Risikoprofil als dieselbe Hardware im Consumer-Heimnetz, verbunden mit einem WLAN-Router und bedient von einem Laien. Diese Umgebungsparameter fließen direkt in die Likelihood-Bewertung ein.

Was sich der CRA vorstellt, wie ein Produkt genutzt wird: Intended Purpose, Reasonably Foreseeable Use und Misuse

Der CRA kennt drei Nutzungsszenarien mit unterschiedlichen Implikationen für die Bewertung.

• Die Zweckbestimmung (Intended Purpose) ist die vom Hersteller vorgesehene Verwendung — definiert durch Gebrauchsanleitung, Marketing-Material, technische Dokumentation und Herstellererklärungen (s. Art. 3 Nr. 23). Die Bewertung muss alle Risiken abdecken, die bei bestimmungsgemäßer Nutzung entstehen.
• Die vernünftigerweise vorhersehbare Verwendung (Reasonably Foreseeable Use) entspricht nicht zwingend der Zweckbestimmung, ergibt sich aber wahrscheinlich aus vorhersehbarem menschlichem Verhalten oder technischen Vorgängen (s. Art. 3 Nr. 24). Beispiel: Ein für eine abgesicherte OT-Umgebung vorgesehenes Industriegerät wird versehentlich mit dem Unternehmensnetzwerk verbunden. Nicht die Zweckbestimmung, aber vorhersehbar, und die damit verbundenen Risiken muss der Hersteller berücksichtigen.
• Die vernünftigerweise vorhersehbare Fehlanwendung (Reasonably Foreseeable Misuse) entspricht nicht der Zweckbestimmung und kann aus vorhersehbarem Verhalten oder Interaktionen mit anderen Systemen resultieren (s. Art. 3 Nr. 25). Der entscheidende Unterschied: Vorhersehbare Fehlanwendungen muss der Hersteller in der Nutzerdokumentation dokumentieren — er ist aber nicht verpflichtet, das Produkt gegen vorsätzlichen Missbrauch zu sichern. Jailbreaking, absichtliche Deaktivierung von Sicherheitsfunktionen oder der Einsatz eines Consumer-Geräts in militärischer Umgebung fallen nicht in seine Verantwortung.

Für die Praxis heißt das: Die Risikoanalyse muss Intended Purpose und Reasonably Foreseeable Use abdecken; Reasonably Foreseeable Misuse ist zu dokumentieren, aber nicht vollständig zu mitigieren.

Wir predigen es immer wieder: Die Cyber-Risikobewertung ist nicht einmalig

Weit verbreitet — und falsch — ist die Vorstellung, die Bewertung werde einmal vor dem Inverkehrbringen erstellt und danach abgeheftet.

Der CRA macht das Gegenteil explizit.

Der Art. 13 Abs. 3 verpflichtet Hersteller, die Risikobewertung zu dokumentieren und gegebenenfalls zu aktualisieren.

„Gegebenenfalls” heißt in der Praxis:

• bei jeder produktrelevanten Änderung,
• bei neu bekannten Schwachstellen,
• bei veränderter Bedrohungslage.

Der Art. 13 Abs. 8 verknüpft das mit dem Unterstützungszeitraum: Die Bewertung läuft über die gesamte Support Period, also mindestens fünf Jahre.

Was das konkret für die Cybersicherheits-Risikobewertung bedeuten kann:

• Eine neue CVE in einer verwendeten Open-Source-Bibliothek

→ Bewertung für die betroffene Komponente aktualisieren, Auswirkungen auf das Gesamtprodukt bewerten

• Ein Firmware-Update mit neuen Funktionen

→ Bewertung für die neuen Funktionen und deren Schnittstellen ergänzen

• Eine neue, für die Produktkategorie relevante Angriffsmethode

→ Threat-Katalog aktualisieren, betroffene Risikoszenarien neu bewerten

Die Risikobewertung ist damit kein Projektartefakt, sondern ein lebendes Dokument, das die Sicherheitslage über die gesamte Lebensdauer abbildet.

End of Software Support vs. Decommissioning — ein oft übersehener Cyber-Risikomoment

Der Unterstützungszeitraum (s. Art. 13 Abs. 8) bemisst sich nach der voraussichtlichen Nutzungsdauer des Produkts und beträgt mindestens fünf Jahre — bei kürzerer erwartbarer Nutzung entsprechend weniger, bei erwartbar längerer Nutzung entsprechend mehr. Die fünf Jahre sind also eine Untergrenze, kein Standardwert.

Geräte laufen oft Jahre oder Jahrzehnte ohne Sicherheitsupdates weiter — vom Smartphone, dessen Betriebssystem aus dem Support fällt, bis zu Industrie- und Medizintechnik mit noch längeren Lebenszyklen.

Für den Anwender möglicherweise praktisch. Aber aus Cybersecurity-Sicht ist das in der Regel kritisch: Ab dem Support-Ende bleiben bekannte Schwachstellen dauerhaft ungepatcht.

Das Produkt wird dadurch zur statischen Angriffsfläche. Es gefährdet dann nicht nur seinen Betreiber, sondern potenziell alle Systeme und Netze, mit denen es verbunden ist.

Der CRA adressiert das auf zwei Ebenen:

1. Hersteller müssen Nutzer rechtzeitig über das Support-Ende informieren (s. Art. 13 Abs. 19)
2. und — wo technisch möglich — eine sichere Löschung aller Nutzerdaten ermöglichen (s. Annex I Teil I lit. m). Eine Mindestanforderung, keine vollständige Lösung.

Für die Risikobewertung folgt daraus: Der gesamte Produktlebenszyklus, inklusive geplantem Support-Ende und absehbarem Weiterbetrieb danach, gehört von Anfang an in die Risikoüberlegungen.

Wer ein Produkt mit erwarteter Lebensdauer von zehn Jahren und einem Unterstützungszeitraum von fünf Jahren auf den Markt bringt, sollte die Risiken der letzten fünf Jahre ohne Updates bereits in der Produktkonzeption berücksichtigen — und transparent kommunizieren, welche Risiken Nutzer nach Support-Ende selbst tragen.

Praktisches Vorgehen in der CRA-Cyberrisikobewertung: Schritt für Schritt

Wir haben die BSI TR-03183 bereits kennengelernt. Und auch die EN 40000 Normenreihe, die korrekt derzeit noch prEN 40000 heißt (aus dem Französischen projet de norme européenne, der offizielle Statusmarker für den Entwurfsstatus).

Also stellt sich für die Cyberrisikobewertung gemäß CRA zunächst die wichtige Frage:

TR-03183 vs. prEN 40000-1-2 oder ISO/SAE 21434 — Welche Methodik als Grundlage für die CRA-Risikobewertung?

Vor dem Start steht die Methodenfrage. Der CRA ist ausdrücklich in Bezug auf die Cybersicherheits-Risikobewertung bewusst methodenneutral.

Das heißt, er schreibt keinen spezifischen Ansatz vor, solange Asset-Identifikation, Bedrohungsanalyse und Risikoakzeptanz nachvollziehbar dokumentiert sind.

Zum gegenwärtigen Zeitpunkt scheinen derzeit hierfür zwei Referenzdokumente maßgeblich:

• Die BSI TR-03183 (v1.0.0, Stand Juli 2026) ist der pragmatische Einstieg: entwickelt vom BSI, orientiert an ISO 31000, mit konkreten Asset-Katalogen samt vorgefertigter C/I/A-Basiswerte, definierten Likelihood-Indikatoren und einem durchgerechneten Praxisbeispiel (Netzwerkkamera). Sie begründet keine Konformitätsvermutung, ist aber heute das zugänglichste und am weitesten ausgearbeitete Werkzeug.
• Die prEN 40000-1-2 ist der entstehende europäische Horizontalstandard unter M/606. Konzeptionell deckungsgleich mit der TR-03183, beide folgen ISO 31000, beide strukturieren in Identification, Analysis, Evaluation und Treatment. Der Unterschied liegt in der normativen Präzision: EN 40000-1-2 definiert Input- und Output-Anforderungen pro Lifecycle-Aktivität und bietet ein explizites Mapping auf Annex I. Sobald im Amtsblatt referenziert, begründet ihre Anwendung Konformitätsvermutung nach Art. 27. Der Abstand zur TR-03183 ist gering. Wer heute mit ihr arbeitet, beginnt bei der späteren Umstellung nicht von vorne.
• Für die tausenden Hersteller, die für die Automobilindustrie und Fahrzeugentwicklung produzieren, und bereits mit der TARA nach ISO/SAE 21434 arbeiten: Die Methodik ist konzeptionell übertragbar und vom CRA akzeptiert. Die Unterschiede liegen im Fokus (TARA zielt auf Fahrzeugsysteme) und in der Granularität des Attack-Potential-Ratings (ISO/SAE 21434 ist deutlich feiner als die TR-03183-Indikatoren). Wer TARA beherrscht, ist für den CRA gut aufgestellt: Safety, Operational und Privacy bewertet die TARA über ihr SFOP-Impact-Schema bereits, und Financial ist ebenfalls abgedeckt. Zu ergänzen ist im Kern nur die systemisch-gesellschaftliche Dimension. Also die Auswirkung auf andere Geräte, Netze und wesentliche Einrichtungen, eine Dimension die im klassischen Automotive-Geschäft (mit Fokus auf Schäden am Fahrzeug und seinen Nutzern/Umgebung) weniger prominent ist.

Der Cyber-Risikobewertungsprozess, wie ihn der CRA fordert, im Überblick

Der Prozess folgt einem iterativen Vier-Schritte-Modell, das TR-03183 und EN 40000-1-2 gleichermaßen zugrunde liegt.

1. Schritt 1: Risk Identification — Assets und Bedrohungen identifizieren. Zuerst werden alle Assets identifiziert und kategorisiert (Daten-, funktionale, Security Assets), wie im Vorangegangenen erörtert. Dann werden je Asset die relevanten Bedrohungen identifiziert, strukturiert über STRIDE oder einen vergleichbaren Ansatz. Ergebnis ist eine Liste von Risikoszenarien: Kombinationen aus Asset, Bedrohungsklasse und betroffenem Umgebungskontext.
2. Schritt 2: Risk Analysis — Likelihood und Impact bewerten. Für jedes Szenario werden potenzieller Impact und Likelihood bewertet. Der Impact ergibt sich aus den C/I/A-Werten der betroffenen Assets. Die TR-03183 gibt Basiswerte (Skala 1–5) für definierte Asset-Typen vor: ein Datenleck generischer personenbezogener Daten (Generic) hat einen Confidentiality-Basiswert von 3, ein Leck von Gesundheitsdaten (PII.Important) einen von 4. Amplifikatoren können diese Werte erhöhen, etwa bei sehr vielen betroffenen Datensätzen oder langandauerndem Schaden. Die Likelihood approximiert die TR-03183 über drei Umgebungsindikatoren: Interface Restriction (von Physical über Local und Known Network bis External Network), Access Restriction (von Restricted bis Non-Restricted) und User Capability (von Skilled über Instructed bis Layman). Daraus entsteht ein Umgebungsindikator, der die Schutzwirkung der Betriebsumgebung abbildet. Beispiel: Ein nur physisch zugängliches, von geschultem Personal bedientes Produkt hat eine fundamental andere Risikolage als ein Consumer-Produkt mit Internetzugang.
3. Schritt 3: Risk Evaluation — Akzeptanz entscheiden. Für jedes analysierte Risiko wird entschieden: akzeptabel oder behandlungsbedürftig? Die TR-03183 gibt qualitative Akzeptanzkriterien vor: Risiken mit moderatem oder höherem Impact bei Netzwerkzugriff durch unbekannte Akteure sind grundsätzlich nicht akzeptabel; ebenso Risiken mit moderatem oder höherem Impact bei Fehlkonfiguration durch Laien-Nutzer. Diese Kriterien sind Ausgangspunkt, keine feste Vorgabe — sie sollen auf den spezifischen Produktkontext angepasst werden. (Deswegen erfordert die gewissenhafte Cyberrisikobewertung trotz KI und Softwarelösungen auch immer noch Expertise, Fachwissen und Erfahrung.)
4. Schritt 4: Risk Treatment — Maßnahmen auswählen und umsetzen. Nicht akzeptierte Risiken müssen behandelt werden. Der CRA schreibt keine spezifischen Maßnahmen vor. Maßnahmen werden dabei konsequent aus dem Risikoassessment abgeleitet, nicht nach Gefühl gewählt — anderenfalls entstehen schnell hohe, am tatsächlichen Risiko vorbei investierte Kosten. Die Essential Requirements aus Annex I Teil I geben den Rahmen, innerhalb dessen der Hersteller Kontrollen auswählt. (Dazu mehr im dritten Artikel dieser Serie.) Die TR-03183 arbeitet mit Adaptable Risk-Based Controls (ARC): Jede Security-Maßnahme ist an ein Risikoszenario geknüpft und gilt nur, wenn das Produkt tatsächlich in diesem Szenario operiert. Ein automatischer Update-Mechanismus als Standard ist etwa nur dann erforderlich, wenn das Produkt Assets mit moderatem oder höherem Impact über ein externes Netz verarbeitet und von Laien-Nutzern bedient wird. Risiken, die der Hersteller nicht allein tragen kann, lassen sich teilen — mit Lieferanten über Compliance-Anforderungen oder Vertragsklauseln, mit Nutzern über transparente Kommunikation und Dokumentation der Restrisiken (sofern diese im Rahmen der vernünftigerweise vorhersehbaren Nutzererwartung liegen).

Das gängige CRA-Praxisbeispiel: Die Netzwerkkamera „Simple Network Camera (SNC) X5 – Everyday Made Easy“

Die BSI TR-03183 enthält unter Anhang C ein durchgerechnetes Beispiel für das Risk Assessment eines PwDE, eine einfache Consumer-Netzwerkkamera:

• Das Produkt erfasst Video- und Audiodaten,
• speichert sie auf einer SD-Karte
• und streamt sie über ein WLAN-Heimnetz.
• Es hat keine Backend-Anbindung des Herstellers — keine RDPS, kein Cloud-Dienst.

Die Asset-Identifikation ergibt unter anderem:

• Video- und Audiodaten (PII.Generic, C:3/I:2/A:3),
• WLAN-Zugangsdaten (Security.Secrets.NetworkCredentials, C:4/I:3/A:3),
• Konfigurationsdaten (Other.Configuration, C:1/I:3/A:1)
• und die essentielle Streaming-Funktion (Functions.Essential, A:3).

Die Betriebsumgebung ist klar: Laien-Nutzer, beschränkter Heimbereich (Restricted), Known Network (Heimnetz mit geteilten Geräten). Der resultierende Environment-Indikator weist Netzwerkrisiken als real aus: Das Heimnetz ist kein isoliertes, dediziertes Netz, sondern geteilt und potenziell mit kompromittierten anderen Geräten.

Die Risikoauswertung zeigt: Risiken für Assets mit moderatem oder höherem Impact über das Heimnetz — also Video-/Audiodaten und WLAN-Credentials — sind nicht akzeptabel. Daraus folgen konkrete Controls, die erforderlich werden: TLS-Verschlüsselung für Web-Schnittstelle und Streaming-Protokoll, starke Authentifizierung ohne Default-Passwörter, geschützter Speicher für WLAN-Credentials mit exklusivem Lesezugriff für den WLAN-Dienst.

Das Beispiel zeigt die Methodik im Kleinen.

Die Übertragung auf komplexere Produkte kann denselben Schritten folgen. Nur mit mehr Assets, mehr Schnittstellen und mehr Risikoszenarien.

Common Mistakes im CRA-Risk-Assessment für Produkte mit digitalen Elementen

Da die Bewertung von Cyberrisiken (z. B. in Automotive- und Fahrzeugentwicklungsprojekten) schon seit vielen Jahren Standard ist, lassen sich daraus und aus den ersten CRA-spezifischen Implementierungen bereits wiederkehrende Muster und mögliche Fehlerquellen ableiten:

1. Fehler 1: Lösungen vor Risiken. Teams diskutieren konkrete Maßnahmen, bevor Risiko und Risikoursache verstanden sind. Das Ergebnis ist technisch korrekt, geht aber am eigentlichen Problem vorbei. Die Frage „Brauchen wir eine Firewall?” darf nicht fallen, bevor „Welche Assets müssen wir gegen welche Bedrohungen schützen?” beantwortet ist. Die Folge sind nicht nur Schutzlücken, sondern auch hohe Kosten für Maßnahmen, die aus Sicherheitssicht gar nicht nötig gewesen wären.
2. Fehler 2: Komplexität statt Konservativismus. Eine zu granulare Tiefenbewertung einzelner Angriffsszenarien verliert das große Bild und macht aus der Risikobewertung ein monatelanges Projekt. Die TR-03183 empfiehlt ausdrücklich einen konservativen, allgemeinen Ansatz als Ausgangspunkt. Lieber ein Risiko überschätzen und eine unnötige Maßnahme implementieren als ein Risiko unterschätzen und eine kritische Schwachstelle offenlassen. Die Erfahrung aus der Automotive-Entwicklungsarbeit zeigt: Sehr aufwändige, detailtiefe TARAs führen allzu oft zu denselben Maßnahmen wie eine schlanke, konservative Bewertung. Die zusätzliche Tiefe kostet dann vor allem Zeit, ohne das Ergebnis zu verändern.
3. Fehler 3: Schlechte Asset-Wahl. Zu viele Assets (jeder Datenpunkt einzeln), zu wenige (nur „die Daten” als Kategorie) oder falsch abgegrenzte (Assets außerhalb des Produkts, die nicht direkt geschützt werden können) machen die gesamte nachfolgende Bedrohungsanalyse unbrauchbar. Assets müssen weder die ganze Systemarchitektur abbilden noch beliebig abstrakt sein. Sie müssen die schützenswerten Einheiten auf einem Granularitätsniveau beschreiben, auf dem sinnvolle Schutzmaßnahmen definierbar sind. Häufig ist auch die Doppelzählung: dasselbe Element als Daten-Asset und als Schnittstelle zu führen. Sauberer: Das Signal ist das Asset, die Schnittstelle der Angriffsvektor. Doppelte Listung bläht die Bewertung auf und erhöht mit der Komplexität die Fehlergefahr.
4. Fehler 4: Impact-Bewertung ohne Unternehmensperspektive. Der Schaden wird technisch bewertet (Datenleck = Impact 3), aber nicht gegen die tatsächliche Tragweite für das Unternehmen gespiegelt. Übersteht das Unternehmen einen Reputationsschaden dieser Größe? Zieht der Vorfall regulatorische Konsequenzen nach sich — etwa DSGVO-Bußgelder zusätzlich zum CRA? Die Impact-Kriterien müssen von Anfang an mit den Unternehmensrealitäten kalibriert sein, nicht nur mit abstrakten Schadensklassen. Praktisch gehört diese Kalibrierung nicht allein in die Security-Funktion: Der Cybersecurity-Engineer bewertet die technische Schadenshöhe, hat aber oft keinen Einblick in Reputations-, Vertrags- und Regulierungsfolgen oder den Vergleich zu anderen Unternehmensrisiken. Legal, Datenschutz und Produkt-/Risikoverantwortung sollten die Impact-Einordnung deshalb mittragen.

Der unterschätzte Zusammenhang zwischen organisatorischen Security-Maßnahmen und der Product-Security

Nicht jede relevante Schutzmaßnahme ist technischer Natur. Bereits implementierte organisatorische Maßnahmen können die Likelihood-Bewertung direkt positiv beeinflussen, weil sie Angriffspfade einschränken oder deren Ausnutzung erschweren. Dazu lassen sich anführen:

• Cybersecurity-Awareness-Training senkt die Wahrscheinlichkeit erfolgreicher Phishing-Angriffe, die zum ungewollten Abfluss von Schlüsseln, Credentials oder Sourcecode führen können
• Access Management auf Entwicklungssysteme, Build-Infrastruktur und Produktionsdaten begrenzt, welche Systeme und Daten bei einer Kompromittierung erreichbar sind — und senkt die mögliche Schadenswirkung
• Klassifizierung und Markierung sensibler Daten ermöglicht gezielte, risikobasierte Absicherung statt pauschalen Schutzes aller Daten gleichermaßen

Im Prozess heißt das: Wer solche Maßnahmen nachweislich betreibt und dokumentiert, kann die Eintrittswahrscheinlichkeit bestimmter Szenarien begründet niedriger ansetzen.

„Nachweislich” ist der Schlüsselbegriff — eine vor drei Jahren einmalig durchgeführte Awareness-Schulung senkt die Likelihood nicht nachhaltig. Regelmäßig durchgeführte, dokumentierte Maßnahmen dagegen sind ein legitimer Faktor.

Dazu sei auch empfohlen unser weiterführender Artikel: Warum sich das Cybersecurity-Konzept (ISO/SAE 21434) nicht nur auf das Fahrzeug beschränken darf: Impulse für Cybersecurity Manager

Vorteile von Re-Use und Impact Analysis im CRA-Risk-Assessment — Skalierbarkeit durch Modularität

Ein vollständiges Assessment von Grund auf für jedes einzelne Produkt ist weder skalierbar noch notwendig.

In der Praxis empfiehlt sich ein modularer Ansatz. Gemeinsame Komponenten, Plattformen oder Architekturen (eine wiederverwendete Kommunikationsschicht, ein geteiltes RDPS-Backend, eine gemeinsame Authentifizierungskomponente) werden einmal bewertet und als Baseline für alle darauf aufbauenden Produkte genutzt.

Das Assessment dieser Basiskomponente muss nicht je Produkt wiederholt, sondern nur referenziert und auf Aktualität geprüft werden.

Bei neuen Produktvarianten oder Folgeversionen genügt dann eine gezielte Impact Analysis: Was hat sich geändert? Welche neuen Assets oder Schnittstellen kommen hinzu? Welche bestehenden Bewertungen sind betroffen? Ist die Likelihood bekannter Angriffe beim heutigen Technologiestand noch plausibel?

Das ist erheblich weniger Aufwand als ein Neu-Assessment und hält das Assessment zugleich aktuell.

Wichtig beim Re-Use: Marktüberwachungsbehörden erwarten Nachvollziehbarkeit, keine Copy-Paste-Dokumentation ohne Begründung. Wer Teile eines bestehenden Assessments übernimmt, muss dokumentieren, welche Teile auf welcher Grundlage übernommen wurden und warum sie für das neue Produkt weiterhin gültig sind.

Wann mache ich die CRA-Risikobewertung? Warum die Risikobewertung von Anfang an mitlaufen muss

Der CRA formuliert bewusst drei Verben: Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten (Annex I Teil I Nr. 1). Sie beschreiben drei Phasen des Produktentstehungsprozesses, in denen Cybersicherheit aktiv zu berücksichtigen ist — nicht nach der Entwicklung, nicht als letzter Schritt vor dem Release, sondern in Konzeption, Entwicklung und Herstellung.

Der Grund liegt in einer oft unterschätzten Abhängigkeit: Viele technische Cybersicherheitsmaßnahmen setzen Hardware- oder Systemvoraussetzungen voraus, die sich nachträglich nicht nachrüsten lassen.

Secure Boot ist das klassische Beispiel: Beim Start nur kryptografisch signierte Firmware zu akzeptieren, ist ohne vertrauenswürdige Hardware-Basis — etwa ein Hardware Security Module (HSM) oder ein Trusted Platform Module (TPM) — nicht wirksam umsetzbar. Wer Secure Boot implementieren will, aber kein HSM vorgesehen hat, steht vor einer Hardware-Revision, die in der Produktion teuer oder praktisch unmöglich ist.

Zweites Beispiel: Die kryptografische Signaturprüfung beim Flashen von Software bringt nichts, wenn der interne Zugriff auf die Firmware-Dateien nicht kontrolliert wird. Können beliebige Mitarbeiter ohne Logging und Autorisierungsprozess auf die Build-Pipeline zugreifen? Dann ist die Signaturprüfung beim Endnutzer wirkungslos — der Angreifer setzt früher an.

Diese Abhängigkeit zwischen Produktsicherheit und interner Infrastruktur-Sicherheit ist ein typischer blinder Fleck, der sich nur in der frühen Konzeptionsphase adressieren lässt.

Wer diese Abhängigkeiten erst im Nachhinein erkennt, steht vor einer binären Wahl: teure Hardware-Revisionen oder wirkungslose Sicherheitsmaßnahmen auf ungeeigneter Basis. Beides ist vermeidbar, wenn Risikobewertung und Architekturentscheidungen von Anfang an gemeinsam gedacht werden.

CRA Risk Assessment und die Frage: Was ist mit Produkten, die bereits im Markt sind?

Für die meisten Hersteller gilt: Ihre CRA-pflichtigen Produkte sind längst entwickelt und verkauft. Security by Design ab der ersten Konzeptionsphase ist für sie keine Option, vielmehr eine rückwirkende Anforderung an bereits getroffene Architekturentscheidungen.

Das ist eine der größten praktischen Herausforderungen des CRA, und es wäre unehrlich, eine einfache Lösung zu behaupten.

Aber es gibt einen pragmatischen Weg: keinen Neustart, sondern eine strukturierte Gap-Analyse auf Basis einer nachträglichen Risikobewertung. Das sieht so aus:

1. Risikobewertung für das bestehende Produkt durchführen — was sind die kritischsten Assets, was die wahrscheinlichsten und folgenreichsten Bedrohungen?
2. Identifizieren, welche Risiken mit vertretbarem Aufwand noch mitigierbar sind: Software-Updates können bekannte Schwachstellen schließen, Konfigurationsänderungen die Angriffsfläche reduzieren, organisatorische Maßnahmen die Likelihood senken.
3. Identifizieren, welche Risiken aufgrund von Hardware-Beschränkungen nicht vollständig mitigierbar sind — und diese als begründete Restrisiken dokumentieren und transparent gegenüber Nutzern kommunizieren.

Nicht jede Hardware-Lücke lässt sich softwareseitig schließen. Das ist akzeptabel, vorausgesetzt, die Entscheidung ist dokumentiert, begründet und nachvollziehbar.

Eine ehrliche, dokumentierte Risikobewertung mit begründeten Akzeptanzentscheidungen ist regulatorisch tragfähiger als gar keine Dokumentation.

Für Bestandsprodukte gilt eine wichtige Ausnahme: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den vollständigen CRA-Anforderungen nur, wenn sie nach diesem Datum wesentlich geändert werden (s. Art. 69 Abs. 2).

Das schafft zwar Spielraum aber keinen Freifahrtschein.

Denn die CRA-Meldepflichten nach Art. 14 gelten bereits ab September 2026 für alle Produkte im Scope (wie im ersten Artikel dieser Serie beschrieben), unabhängig vom Zeitpunkt des Inverkehrbringens.

Und eine Risikobewertung ist die Voraussetzung dafür, überhaupt beurteilen zu können, ob ein Sicherheitsereignis meldepflichtig ist.