CRA-Risikobewertung: So erstellen Hersteller eine belastbare Cybersicherheitsrisikoanalyse

Die CRA-Risikobewertung ist die dokumentierte Analyse der Cybersicherheitsrisiken eines Produkts mit digitalen Elementen. Hersteller müssen sie für ihr Produkt erstellen, die Ergebnisse bereits bei Planung, Konzeption, Entwicklung, Produktion, Lieferung und Wartung berücksichtigen und die Bewertung in die technische Dokumentation aufnehmen. Sie ist damit kein nachträglicher Prüfbericht, sondern die Grundlage für zahlreiche technische und organisatorische CRA-Maßnahmen.

Wer den gesamten Rechtsrahmen zuerst einordnen möchte, findet im Überblick zum Cyber Resilience Act Pflichten, Fristen und Rollen. Die CRA-Herstellerpflichten zeigen, wo die Risikobewertung in den Gesamtprozess gehört. Dieser Beitrag konzentriert sich ausschließlich darauf, wie eine solche Bewertung aufgebaut, gepflegt und für die Konformitätsbewertung nutzbar gemacht wird.

Was verlangt der CRA bei der Risikobewertung?

Artikel 13 verlangt von Herstellern eine Bewertung der mit dem Produkt verbundenen Cybersicherheitsrisiken. Das Ergebnis muss im gesamten Produktlebenszyklus berücksichtigt werden. Der CRA nennt ausdrücklich Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung.

Die Bewertung muss mindestens auf der Zweckbestimmung und der vernünftigerweise vorhersehbaren Verwendung des Produkts beruhen. Dazu gehören auch Betriebsumgebung, zu schützende Werte und die voraussichtliche Nutzungsdauer. Im offiziellen CRA-Rechtstext auf EUR-Lex ist außerdem festgelegt, dass die Bewertung erläutern muss, welche Anforderungen aus Anhang I anwendbar sind und wie sie umgesetzt werden.

Ist eine allgemeine Unternehmens-Risikoanalyse ausreichend?

Nein. Eine allgemeine IT-Risikoanalyse des Unternehmens kann hilfreiche Methoden liefern, ersetzt aber nicht die produktbezogene CRA-Bewertung. Der CRA fragt nach den Risiken des konkreten Produkts mit digitalen Elementen und nach den Maßnahmen, mit denen dieses Produkt die grundlegenden Cybersicherheitsanforderungen erfüllt.

Wann muss die CRA-Risikobewertung erstellt werden?

Die Bewertung sollte beginnen, sobald Produktzweck und Architektur ausreichend klar sind. Wer erst kurz vor der CE-Kennzeichnung damit startet, muss häufig nachträglich rekonstruieren, warum bestimmte Architektur- und Sicherheitsentscheidungen getroffen wurden.

Ein besserer Ablauf ist, die erste Risikobewertung in der Konzeptphase anzulegen und anschließend mit dem Produkt weiterzuentwickeln. Änderungen an Architektur, Funktionen, Abhängigkeiten oder Einsatzumgebung können neue Risiken erzeugen und müssen daher berücksichtigt werden.

Muss die Risikobewertung aktualisiert werden?

Ja. Der CRA verlangt, dass die technische Dokumentation gegebenenfalls zumindest während des CRA-Supportzeitraums laufend aktualisiert wird. Wenn neue Schwachstellen, neue Bedrohungen, Änderungen an Komponenten oder neue Nutzungsweisen entstehen, muss geprüft werden, ob die bestehende Risikobewertung noch zutrifft.

Welche Informationen braucht man vor dem Start?

Eine Risikobewertung wird deutlich besser, wenn das Team zunächst die Produktgrenzen sauber beschreibt. Ohne diese Abgrenzung bleibt unklar, welche Komponenten, Schnittstellen und Remote-Funktionen überhaupt berücksichtigt werden müssen.

Vor der eigentlichen Risikoanalyse sollten mindestens folgende Grundlagen vorliegen:

• Produktname, Version und Produktfamilie,
• Zweckbestimmung und Hauptfunktionen,
• vernünftigerweise vorhersehbare Verwendung,
• typische Nutzergruppen,
• Betriebs- und Netzwerkumgebung,
• lokale und entfernte Schnittstellen,
• Software- und Hardwarekomponenten,
• externe Dienste und Datenfernverarbeitung,
• Update- und Wartungsmechanismen,
• relevante Schutzgüter und besonders sensible Funktionen.

Wer noch nicht sicher ist, welche Bestandteile überhaupt zum Produkt mit digitalen Elementen gehören, sollte zuerst den CRA-Anwendungsbereich prüfen.

Wie beschreibt man Zweckbestimmung und vorhersehbare Nutzung?

Die Zweckbestimmung beschreibt, wofür das Produkt vorgesehen ist. Die vernünftigerweise vorhersehbare Nutzung geht darüber hinaus: Sie betrachtet Nutzungsweisen, die zwar nicht ausdrücklich vorgesehen sind, aber realistisch zu erwarten sind.

Bei einem Router reicht es beispielsweise nicht, nur „Internetverbindung bereitstellen“ zu dokumentieren. Relevant sind auch Fernadministration, Standardkonfiguration, WLAN-Zugänge, mögliche Gastnetzwerke, Updatefunktionen, lokale Verwaltungsoberflächen und typische Einsatzorte.

Warum ist Fehlgebrauch wichtig?

Der Hersteller muss nicht jede denkbare missbräuchliche Handlung verhindern. Aber typische Fehlkonfigurationen, unsichere Standardpasswörter, leicht vorhersehbare Administrationswege oder häufige Fehlbedienungen dürfen in der Bewertung nicht ignoriert werden, wenn sie vernünftigerweise vorhersehbar sind.

Welche Schutzgüter sollte die Risikobewertung erfassen?

Schutzgüter sind die Werte und Funktionen, deren Beeinträchtigung zu Sicherheitsfolgen führen kann. Je nach Produkt können das Daten, Zugangsdaten, Steuerfunktionen, Updatekanäle, Kommunikationsverbindungen, Konfigurationen oder die Verfügbarkeit kritischer Funktionen sein.

Eine praxistaugliche Bewertung betrachtet mindestens:

• Vertraulichkeit: Welche Daten oder Geheimnisse dürfen Unbefugte nicht lesen?
• Integrität: Welche Daten, Software oder Konfigurationen dürfen nicht unbemerkt verändert werden?
• Verfügbarkeit: Welche Funktionen müssen zuverlässig nutzbar bleiben?
• Authentizität: Welche Nutzer, Geräte, Updates oder Server müssen eindeutig überprüfbar sein?
• Kontrolle: Welche Funktionen könnten bei Manipulation gefährliche oder erhebliche Folgen auslösen?

Wie identifiziert man Bedrohungen?

Bedrohungen sollten aus Sicht der realen Angriffsflächen betrachtet werden. Dazu gehören Netzwerkschnittstellen, APIs, Weboberflächen, lokale Ports, Updatekanäle, mobile Apps, Cloud-Komponenten, Authentifizierung, physische Zugriffe und Abhängigkeiten von Drittsoftware.

Typische Bedrohungsszenarien sind beispielsweise:

• unbefugter Zugriff durch schwache oder fehlende Authentifizierung,
• Manipulation von Updates,
• Ausnutzung einer Schwachstelle in einer Bibliothek,
• Übernahme eines Kontos oder Administrationszugangs,
• Abfluss sensibler Daten,
• Denial-of-Service gegen zentrale Produktfunktionen,
• unsichere Standardkonfiguration,
• Missbrauch offener Schnittstellen,
• Manipulation von Konfigurations- oder Protokolldaten,
• Angriffe auf Remote-Dienste, ohne die das Produkt nicht funktioniert.

Wie bewertet man Eintrittswahrscheinlichkeit und Auswirkungen?

Der CRA schreibt keine einzige feste Risikomatrix für alle Produkte vor. Das Unternehmen braucht aber eine konsistente Methode, mit der Risiken nachvollziehbar priorisiert werden können. Eine einfache Matrix aus Wahrscheinlichkeit und Auswirkung kann genügen, wenn sie zum Produkt passt und sauber dokumentiert wird.

Bei der Wahrscheinlichkeit können beispielsweise Erreichbarkeit der Angriffsfläche, erforderliche Kenntnisse, notwendige Berechtigungen, vorhandene Exploits und bisher bekannte Angriffsmuster berücksichtigt werden. Bei den Auswirkungen geht es um Schaden für Nutzer, Daten, Produktfunktion, Betrieb und gegebenenfalls andere Systeme.

Reicht eine Zahl wie „Risiko 7 von 10“?

Nein. Eine Zahl ohne Begründung hilft weder Entwicklung noch Prüfern. Die Bewertung sollte erklären, warum ein Szenario als hoch, mittel oder niedrig eingestuft wurde und welche Annahmen zugrunde liegen.

Wie werden Sicherheitsmaßnahmen aus der Risikobewertung abgeleitet?

Der eigentliche Wert der Bewertung liegt in den Maßnahmen. Für jedes relevante Risiko sollte klar sein, ob es vermieden, reduziert, kontrolliert oder in begründeten Grenzen akzeptiert wird.

Beispiele für Maßnahmen sind sichere Standardkonfigurationen, stärkere Authentifizierung, Verschlüsselung, Signaturprüfung von Updates, Eingabevalidierung, Rechtebegrenzung, Rate Limiting, Logging, Trennung von Komponenten, sichere Speicherung von Geheimnissen oder zusätzliche Security-Tests.

Die Maßnahmen müssen zu den grundlegenden Anforderungen aus Anhang I passen. Die Risikobewertung ist daher eine Brücke zwischen Rechtsanforderung und technischer Umsetzung.

Wie dokumentiert man Restrisiken?

Auch nach Sicherheitsmaßnahmen können Risiken verbleiben. Diese Restrisiken sollten bewusst dokumentiert werden. Wichtig ist, dass eine Akzeptanz nicht einfach behauptet wird, sondern begründet ist.

Ein sauberer Risikoeintrag enthält beispielsweise Szenario, betroffene Komponente, Schutzgut, Wahrscheinlichkeit, Auswirkung, bestehende Maßnahmen, geplante Maßnahmen, Restrisiko, Verantwortlichen und Status.

Welche Rolle spielen Drittkomponenten und Open Source?

Hersteller müssen bei der Integration von Komponenten Dritter die gebotene Sorgfalt walten lassen. Eine Risikoanalyse sollte deshalb nicht an der Grenze des eigenen Quellcodes enden.

Für Bibliotheken, Frameworks, Betriebssystemkomponenten, Firmware und andere Abhängigkeiten sollte geprüft werden:

• Welche Funktion übernimmt die Komponente?
• Ist sie sicherheitskritisch?
• Wie werden Schwachstellen bekannt?
• Wer pflegt die Komponente?
• Wie lange wird sie unterstützt?
• Kann sie bei Bedarf ersetzt werden?
• Welche Version ist im Produkt enthalten?

Die Sonderregeln für freie Software werden in unserem Beitrag zu CRA und Open Source vertieft.

Wie hängen Risikobewertung und SBOM zusammen?

Eine Software-Stückliste schafft Transparenz über enthaltene Komponenten. Sie ersetzt die Risikobewertung aber nicht. Eine SBOM kann zeigen, dass eine bestimmte Bibliothek enthalten ist; die Risikoanalyse muss zusätzlich klären, ob und wie eine bekannte Schwachstelle das konkrete Produkt betrifft.

Für gute CRA-Prozesse sollten Komponentenliste, Schwachstellenmanagement und Risikobewertung miteinander verbunden sein. So kann eine neue Sicherheitsmeldung automatisiert oder halbautomatisiert dem richtigen Produkt und der richtigen Bewertung zugeordnet werden.

Was gehört aus der Risikobewertung in die technische Dokumentation?

Die Risikobewertung selbst muss Bestandteil der technischen Dokumentation sein. Wenn bestimmte grundlegende Cybersicherheitsanforderungen für das Produkt nicht anwendbar sind, muss dies klar begründet werden.

Die technische Dokumentation sollte außerdem erkennen lassen, wie Architektur, Entwicklung, Tests, Schwachstellenbehandlung und Sicherheitsmaßnahmen aus den bewerteten Risiken abgeleitet wurden. Genau diese Nachvollziehbarkeit ist für die CRA-Konformitätsbewertung wichtig.

Wer sollte an der CRA-Risikobewertung beteiligt sein?

Eine reine Security- oder Rechtsabteilung kennt selten alle Produktdetails. Gute Bewertungen entstehen interdisziplinär.

Je nach Unternehmen sollten beteiligt sein:

• Produktmanagement für Zweckbestimmung und Nutzererwartungen,
• Architektur und Entwicklung für technische Angriffsflächen,
• IT-Security für Bedrohungsmodell und Maßnahmen,
• Qualitätssicherung für Tests und Nachweise,
• Support für reale Fehler- und Nutzungsmuster,
• Einkauf oder Lieferantenmanagement für Drittkomponenten,
• Compliance oder Recht für Anforderungen und Dokumentation.

Wie sieht ein praxistauglicher Ablauf aus?

Für viele Hersteller funktioniert ein strukturierter Ablauf in zehn Schritten:

1. Produktgrenzen und Version bestimmen.
2. Zweckbestimmung und vorhersehbare Nutzung beschreiben.
3. Architektur, Schnittstellen und Komponenten erfassen.
4. Schutzgüter identifizieren.
5. Bedrohungen und Angriffsszenarien sammeln.
6. Wahrscheinlichkeit und Auswirkungen bewerten.
7. Sicherheitsmaßnahmen zuordnen.
8. Restrisiken beurteilen und verantworten.
9. Nachweise und Tests verknüpfen.
10. Trigger für spätere Aktualisierungen festlegen.

Wann muss die Bewertung erneut geprüft werden?

Eine Überprüfung sollte nicht nur kalenderbasiert erfolgen. Bestimmte Ereignisse sollten automatisch eine Neubewertung auslösen.

Dazu gehören größere Releases, neue Schnittstellen, Austausch kritischer Komponenten, neue Remote-Funktionen, geänderte Betriebsumgebungen, wesentliche Schwachstellen, neue Angriffsmethoden oder Hinweise aus dem Feld. Auch eine CRA-meldepflichtige Schwachstelle oder ein schwerer Sicherheitsvorfall kann zeigen, dass bisherige Annahmen angepasst werden müssen.

Wie sieht eine CRA-Risikobewertung an einem einfachen Beispiel aus?

Ein Hersteller vertreibt einen vernetzten Temperaturregler mit Weboberfläche, mobiler App und Cloud-Anbindung. Das Gerät empfängt Sicherheitsupdates über das Internet und speichert Konfigurationsdaten lokal.

Schritt 1: Schutzgüter bestimmen

Wichtige Schutzgüter sind die Integrität der Steuerbefehle, die Verfügbarkeit der Regelungsfunktion, Zugangsdaten für Administratoren, Konfigurationswerte und der Updatekanal. Eine Manipulation könnte dazu führen, dass unberechtigte Personen Einstellungen ändern oder schädliche Firmware installieren.

Schritt 2: Angriffsszenario formulieren

Ein mögliches Szenario lautet: Ein Angreifer übernimmt ein schwach geschütztes Administratorkonto und verändert die Gerätekonfiguration. Ein zweites Szenario betrifft den Updateprozess: Ein manipuliertes Update könnte Schadcode auf viele Geräte verteilen.

Schritt 3: Risiko bewerten

Für jedes Szenario werden Eintrittswahrscheinlichkeit und mögliche Auswirkungen bewertet. Ist die Weboberfläche direkt aus dem Internet erreichbar und fehlt Mehrfaktor-Authentifizierung, kann das Risiko höher sein als bei einem rein lokalen Administrationszugang.

Schritt 4: Maßnahmen festlegen

Mögliche Maßnahmen sind sichere Standardpasswörter, verpflichtender Passwortwechsel, Rate Limiting, signierte Updates, verschlüsselte Kommunikation, Rollen- und Rechtekonzept sowie Protokollierung sicherheitsrelevanter Ereignisse. Danach wird bewertet, welches Restrisiko verbleibt.

Schritt 5: Nachweise verknüpfen

Die Risikobewertung sollte auf konkrete Nachweise zeigen: Architekturdiagramm, Testfälle für den Updateprozess, Penetrationstest, Authentifizierungsanforderungen und Freigaben. So wird aus einer abstrakten Risikoanalyse ein prüfbarer Bestandteil der technischen Dokumentation.

Wie verbindet man die Risikobewertung mit der SBOM?

Bei Softwareprodukten sollte die Bewertung nicht nur eigene Funktionen betrachten, sondern auch bekannte Abhängigkeiten. Eine gepflegte CRA-SBOM zeigt, welche Bibliotheken und Komponenten in welcher Version enthalten sind. Wird dort eine neue Schwachstelle bekannt, kann die Risikoanalyse gezielt aktualisiert werden.

Praxisvorlage: Das CRA Risikobewertung Starterpaket enthält editierbare DOCX-, XLSX- und PDF-Arbeitsvorlagen für Risikomatrix, Maßnahmen, Nachweise und Reviews.

Diese Verbindung verhindert zwei typische Fehler: Zum einen werden relevante Drittkomponenten nicht übersehen. Zum anderen wird eine CVE nicht automatisch als kritisches Produktrisiko bewertet, ohne die tatsächliche Nutzung und Erreichbarkeit im eigenen Produkt zu prüfen.

Wie dokumentiert man nicht anwendbare CRA-Anforderungen?

Wenn eine grundlegende Cybersicherheitsanforderung für ein konkretes Produkt nicht anwendbar ist, sollte sie nicht einfach mit „n/a“ abgehakt werden. Der Hersteller sollte erklären, warum die Anforderung aufgrund von Zweckbestimmung, Architektur oder fehlender Funktion nicht greift.

Eine gute Begründung nennt die betreffende Anforderung, den technischen Kontext und die Annahmen, auf denen die Nichtanwendbarkeit beruht. Ändert sich später das Produkt, muss geprüft werden, ob diese Begründung noch trägt.

Gerade bei neuen Schnittstellen, Remote-Funktionen oder geänderten Betriebsumgebungen können zuvor nicht relevante Anforderungen plötzlich anwendbar werden. Deshalb gehört auch dieser Teil in den regulären Aktualisierungsprozess der Risikobewertung.

Welche Fehler schwächen eine CRA-Risikobewertung?

• Zu allgemein: Die Bewertung könnte genauso für zehn andere Produkte gelten.
• Nur CVE-Listen: Komponenten-Schwachstellen werden erfasst, aber Produktfolgen nicht analysiert.
• Keine Nutzungsannahmen: Zweckbestimmung und reale Betriebsumgebung fehlen.
• Keine Verbindung zu Maßnahmen: Risiken werden beschrieben, aber die Architektur bleibt unverändert.
• Keine Verantwortlichen: Offene Maßnahmen haben keinen Besitzer.
• Einmal erstellt, nie aktualisiert: Das Dokument altert schneller als das Produkt.
• Keine Begründung nicht anwendbarer Anforderungen: Anforderungen werden lediglich als „n/a“ markiert.

Was sollten Hersteller jetzt konkret vorbereiten?

Unternehmen sollten für jedes relevante Produkt einen verantwortlichen Owner für die CRA-Risikobewertung benennen, eine einheitliche Methode definieren und vorhandene Security-Artefakte wiederverwenden. Bedrohungsmodelle, Penetrationstests, Architekturdiagramme, Schwachstellenlisten und bestehende Risikoregister können wertvolle Eingaben sein.

Wichtig ist, daraus keinen zweiten parallelen Papierprozess zu bauen. Die Bewertung sollte mit Entwicklungs- und Ticket-Systemen, Releaseprozessen, Komponentenmanagement und Sicherheitsprüfungen verbunden werden. Dann entsteht der Nachweis weitgehend aus der tatsächlichen Arbeit.