CRA-Risikoanalyse: Schritt für Schritt

Warum die Risikoanalyse der Dreh- und Angelpunkt ist

Pflicht nach Anhang I und Anhang VII CRA: Anhang I der EU-Verordnung 2024/2847 stellt an erster Stelle: Produkte mit digitalen Elementen müssen „ohne bekannte ausnutzbare Schwachstellen” in Verkehr gebracht werden.¹ Diese Anforderung klingt schlicht. Ohne eine systematische Risikoanalyse ist sie aber nicht nachweisbar. Anhang VII schreibt die Risikoanalyse als Pflichtbestandteil der technischen Dokumentation vor.

Was viele übersehen: Eine CRA-konforme Risikoanalyse ist kein einmaliges Audit — sie ist ein lebendes Dokument, das Hersteller über den gesamten Produkt-Lebenszyklus pflegen müssen. Neue Features, neue Abhängigkeiten, neue Bedrohungslagen: Jede relevante Änderung erfordert eine Aktualisierung.

Ein Hersteller von industriellen MQTT-Gateways — typisches Industrie-4.0-Szenario — merkt das spätestens dann, wenn er einen neuen Cloud-Broker anbindet. Neue Vertrauensgrenze, neuer Datenfluss, neue Bedrohungen. Die Risikoanalyse muss mit. Andernfalls entsteht eine dokumentierte Lücke, die Marktaufsichtsbehörden bei einer Inspektion sofort erkennen.

Gleichzeitig ist die Risikoanalyse das Fundament für fast alle anderen Pflichtdokumente: Die technische Dokumentation nach Anhang VII verweist auf sie, das Schwachstellenmanagement setzt sie voraus, und Notified Bodies prüfen sie bei der Konformitätsbewertung als erstes.¹

Praxis-Einschätzung: Viele Teams unterschätzen den Aufwand. Eine Risikoanalyse, die in einem Nachmittag entsteht, überzeugt keine Notified Body und schützt nicht vor Behördensanktionen. Die eigentliche Arbeit beginnt beim Datenfluss-Diagramm. Wer sein Produkt noch nie systematisch aus Angreifer-Perspektive betrachtet hat, wird dabei Überraschungen erleben — und genau das ist der Sinn der Übung.

Welche Methode ist vorgeschrieben?

Keine. Der CRA schreibt keine spezifische Methodik vor. Er fordert eine „systematische” Analyse und verweist auf „den Stand der Technik” als Maßstab.¹ Die Wahl der Methode liegt beim Hersteller — wichtig ist, dass Hersteller die Analyse nachvollziehbar dokumentieren und auf das konkrete Produkt anwenden, nicht aus einer Vorlage kopieren. In der Praxis haben sich drei Methoden etabliert, die alle CRA-konform angewendet werden können:

STRIDE (Microsoft)

STRIDE ist eine strukturierte Bedrohungsmodellierungs-Methode, die in den 1990er Jahren bei Microsoft entwickelt wurde. Sie kategorisiert Bedrohungen nach sechs Typen:

Buchstabe	Bedrohungstyp	Englisch	Beispiel
S	Identitätsfälschung	Spoofing	Angreifer gibt sich als legitimer Nutzer aus
T	Manipulation	Tampering	Manipulation von Konfigurationsdateien
R	Abstreitbarkeit	Repudiation	Aktionen ohne Log-Nachweis ausführen
I	Informationsoffenlegung	Information Disclosure	Auslesen von Zugangsdaten aus dem Speicher
D	Dienstverweigerung	Denial of Service	Absturz durch manipulierte Eingabe
E	Rechteausweitung	Elevation of Privilege	Normaler Nutzer erhält Admin-Rechte

STRIDE eignet sich besonders für Software-Produkte, Web-Anwendungen und SaaS-Plattformen. Es ist gut dokumentiert, frei zugänglich und in vielen Entwicklungsteams bereits bekannt.

TARA (ISO 21434 / IEC 62443-3-2)

TARA (Threat Analysis and Risk Assessment) ist der in der Automobil- und Industrieautomatisierungs-Welt verbreitete Ansatz. Wer IEC 62443-3-2 für industrielle Steuerungen oder ISO 21434 für Automotive-Produkte anwendet, nutzt implizit TARA.

TARA eignet sich besonders für Embedded-Systeme, Industrie-Steuerungen und IoT-Produkte, weil sie explizit physische Angriffspfade und Hardware-Threats berücksichtigt. Der Nachteil: Die Methode ist komplexer und erfordert Erfahrung mit den zugrundeliegenden Standards.

Ein Hersteller von embedded-Software für Heizungssteuerungen — typisches Szenario für Gebäudeautomation im Maschinenbau — fährt mit TARA besser als mit STRIDE. Die physischen Angriffspfade (lokaler Zugriff auf das Gerät, manipulierte Sensordaten) bildet STRIDE schlicht nicht so sauber ab.

PASTA (Process for Attack Simulation and Threat Analysis)

PASTA ist ein geschäftsorientierter, siebenstufiger Ansatz, der Bedrohungen aus der Perspektive des Angreifers bewertet und direkt auf Geschäftsrisiken abbildet. Er eignet sich besonders für SaaS-Anbieter und API-Produkte, weil er explizit Angreiferprofile und Angriffs-Simulationen einbezieht.

Für die meisten KMUs ist STRIDE der empfohlene Einstiegspunkt: niedrige Hürde, klare Struktur, gut dokumentiert. Das ist eine Empfehlung, keine Vorschrift — wer bereits mit IEC 62443 oder ISO 21434 arbeitet, muss nicht auf STRIDE wechseln.

STRIDE-Risikoanalyse: Schritt für Schritt

Schritt 1: System modellieren

Erstellen Sie ein Datenfluss-Diagramm (DFD) Ihres Produkts. Ein DFD zeigt:

Prozesse — was Ihr System tut (z.B. Authentifizierungsservice, Datenbankabfrage)
Datenspeicher — wo Daten gespeichert werden (z.B. Datenbank, lokaler Dateispeicher)
Externe Entitäten — wer mit dem System interagiert (z.B. Nutzer, externe APIs)
Datenflüsse — wie Daten zwischen diesen Elementen fließen (z.B. API-Call, MQTT-Nachricht)
Vertrauensgrenzen — wo Sicherheitszonen wechseln (z.B. Grenze zwischen Internet und internem Netz)

Das Diagramm muss kein vollständiges technisches Architektur-Diagramm sein — es soll die Angriffspfade sichtbar machen. Ein einfaches Whiteboard-Bild mit den fünf DFD-Elementen reicht als Ausgangspunkt.

Gerade embedded-Software-Hersteller, die ihre Heizungssteuerungen oder Gebäudeautomation bislang isoliert betrachtet haben, stellen beim DFD-Erstellen fest, dass externe Update-Server oder Cloud-Dashboards längst Teil des Systems sind — und damit Teil des Angriffspfads. Das ist keine Ausnahme. Das ist die Regel.

Schritt 2: Assets identifizieren

Listen Sie alle schützenswerten Assets auf — alles, dessen Kompromittierung Schaden verursachen würde:

Zugangsdaten und Authentifizierungstoken
Konfigurationsdaten und Gerätezertifikate
Nutzerdaten und persönliche Informationen
Firmware und Software-Integrität
Produktionsprozesse und Betriebsgeheimnisse

Priorisieren Sie: Welche Assets sind geschäftskritisch? Welche betreffen die Sicherheit von Nutzern oder Dritten?

Schritt 3: STRIDE auf jeden Datenfluss anwenden

Gehen Sie jeden Datenfluss und jede Vertrauensgrenze systematisch durch und fragen Sie für jede STRIDE-Kategorie: „Wie könnte ein Angreifer hier angreifen?”

Beispiel für einen Datenfluss „Firmware-Update-Download”:

STRIDE-Kategorie	Bedrohung
Spoofing	Update-Server wird durch DNS-Hijacking auf einen bösartigen Server umgeleitet
Tampering	Update-Paket wird während der Übertragung manipuliert
Repudiation	Update-Download wird nicht protokolliert, kein Nachweis wer was wann heruntergeladen hat
Information Disclosure	Update-Paket enthält unverschlüsselte Konfigurationsdaten
Denial of Service	Angreifer blockiert Update-Server, Gerät erhält keine Sicherheitsupdates
Elevation of Privilege	Manipuliertes Update-Paket wird mit Root-Rechten ausgeführt

Das ist kein theoretisches Beispiel. Ein IoT-Startup, das Feldgeräte per OTA-Update versorgt, hat genau diesen Datenfluss — und genau diese sechs Angriffsvektoren. Konkret bedeutet das: Code-Signing ist kein Nice-to-have, sondern die direkte Antwort auf Spoofing und Tampering in diesem Szenario.

Schritt 4: Risiko bewerten

Bewerten Sie jede identifizierte Bedrohung nach zwei Dimensionen:

Eintrittswahrscheinlichkeit (1–3): Wie wahrscheinlich ist ein Angriff in der Praxis?
Auswirkung (1–3): Wie schwerwiegend wären die Folgen?

Risikoscore = Eintrittswahrscheinlichkeit × Auswirkung

Score	Risikostufe	Maßnahme
1–2	Niedrig	Akzeptieren oder langfristig adressieren
3–4	Mittel	Maßnahme planen, Zeitrahmen festlegen
6–9	Hoch	Sofortmaßnahme erforderlich, vor Release beheben

Schritt 5: Maßnahmen ableiten und dokumentieren

Für jedes Risiko mit Score ≥ 3 definieren Sie eine konkrete Gegenmaßnahme:

Technische Maßnahmen (bevorzugt): Signaturprüfung bei Updates, Verschlüsselung, Input-Validierung
Prozessuale Maßnahmen: regelmäßige Penetrationstests, Code-Reviews, Patch-Prozess
Akzeptierte Restrisiken: dokumentiert, begründet, genehmigt (z.B. durch Produktverantwortlichen)

Jede Maßnahme erhält einen Status (Geplant / In Umsetzung / Umgesetzt) und einen Verantwortlichen.

Schritt 6: Review-Zyklus festlegen

Legen Sie schriftlich fest, wann Hersteller die Risikoanalyse zwingend aktualisieren müssen:

Jährlich, mindestens
Bei wesentlichen Produktänderungen (neue Features, neue Komponenten, neue Integrations-Partner)
Bei neuen CVEs in verwendeten Komponenten mit CVSS ≥ 7.0
Nach einem Sicherheitsvorfall, der das Produkt betrifft

Vorlage: Risiko-Register

Die Ergebnisse der STRIDE-Analyse werden im Risiko-Register dokumentiert. Mindestspalten:

Asset	Datenfluss	Bedrohung (STRIDE)	Kategorie	Wahrschein-lichkeit	Auswirkung	Score	Maßnahme	Status	Verantwortlich
Firmware	Update-Download	Server-Identität gefälscht	Spoofing	2	3	6	Code-Signing für Updates	Umgesetzt	Entwicklung
Nutzerdaten	API-Response	Daten an falschen Empfänger	Info Disc.	1	3	3	mTLS erzwingen	Geplant	Security
Gerätekonfig	MQTT-Broker	Unberechtigte Änderung	Tampering	2	2	4	Write-Protect + Signatur	In Umsetzung	Embedded

Das Risiko-Register ist ein lebendes Dokument. Hersteller versionieren es bei jeder Analyse-Aktualisierung — Datum und verantwortliche Person gehören immer dazu.

Was in die technische Dokumentation gehört

Nach Anhang VII der EU-Verordnung 2024/2847 muss die technische Dokumentation folgende Inhalte aus der Risikoanalyse enthalten:¹

Beschreibung der angewendeten Methodik (z.B. STRIDE, IEC 62443-3-2)
System-Modell (DFD oder vergleichbar) als Anhang
Risiko-Register mit allen identifizierten Bedrohungen
Dokumentation der Restrisiken mit Begründung für die Akzeptanzentscheidung
Nachweis, dass Anhang-I-Anforderungen adressiert wurden (Mapping: Anforderung → Maßnahme)
Versionierungshistorie der Risikoanalyse

Hersteller müssen die technische Dokumentation 10 Jahre nach Inverkehrbringen aufbewahren und auf Anfrage an Marktaufsichtsbehörden vorlegen. Das klingt nach einem fernen Problem. Ist es nicht — wer heute released, muss 2035 noch auskunftsfähig sein.

Typische Fehler vermeiden

Fehler 1: Risikoanalyse als einmaliges Dokument behandeln Hersteller erstellen eine Analyse vor dem Release und aktualisieren sie nie wieder. Bei wesentlichen Änderungen oder neuen Bedrohungen entsteht eine dokumentierte Lücke — die Marktaufsichtsbehörde erkennt das bei einer Inspektion sofort.

Fehler 2: Nur technische Bedrohungen betrachten CRA-Anhang I umfasst auch Anforderungen zu Datenminimierung und Nutzerkommunikation. Prozessuale Bedrohungen (z.B. mangelhafte Dokumentation, fehlende Offenlegungsprozesse) gehören ebenfalls in die Analyse.

Fehler 3: Restrisiken nicht dokumentieren Nicht jede Bedrohung lässt sich beseitigen. Entscheidend ist die dokumentierte Begründung, warum Hersteller ein Restrisiko akzeptieren — und wer diese Entscheidung getroffen hat.

Fehler 4: Keine Verlinkung zu Anhang I Das ist der Punkt, den viele übersehen: Die Risikoanalyse ist Mittel zum Zweck. Jede der 10 Anhang-I-Anforderungen muss durch Maßnahmen adressiert sein, die sich aus der Risikoanalyse ergeben. Ohne explizites Mapping fehlt der Nachweis — und damit fehlt der Kern der Konformitätsbewertung.

Verhältnis zu etablierten Standards

Wer bereits nach bestehenden Standards arbeitet, kann diese als Grundlage nutzen:

IEC 62443-3-2 (Industrial Security): Sehr starkes CRA-Mapping für Embedded- und Industrieprodukte. Eine IEC-62443-konforme Risikoanalyse deckt die CRA-Anforderungen weitgehend ab.
ISO 21434 (Automotive Cybersecurity): Das TARA-Verfahren dieses Standards ist explizit CRA-kompatibel.
OWASP Threat Modeling: Ergänzende Methodik, besonders für Web- und API-Produkte.

Was viele CRA-Berater nicht sagen: Wer für den Maschinenbau bereits IEC 62443-3-2 betreibt, muss keine parallele CRA-Risikoanalyse aufbauen. Das bestehende Dokument muss Hersteller anpassen und mit Anhang I verlinken — das ist Aufwand, aber kein Neuanfang.

Nächste Schritte

Verstehen Sie zuerst, in welche Risikoklasse Ihr Produkt fällt — das bestimmt, wie aufwändig Hersteller die Risikoanalyse dokumentieren müssen:

CRA Risikoklassen erklärt: Default, Important, Critical

CRA-Pflichten für Hersteller — vollständige Übersicht

Kostenlosen CRA-Check starten — ermitteln Sie in 4 Schritten Ihre Risikoklasse und die zugehörigen Dokumentationspflichten.

Das CRA Evidence Pack enthält eine fertige Risiko-Register-Vorlage (Excel + PDF), ein ausgefülltes STRIDE-Beispiel und das vollständige Anhang-VII-Dokumentationspaket.

Quellen

EU-Verordnung 2024/2847 (Cyber Resilience Act), Anhang I, Anhang VII: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
IEC 62443-3-2: Security risk assessment for system design — https://www.iec.ch/store/p_iec62443-3-2
ENISA — Threat Landscape 2024: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024
Microsoft — Threat Modeling (STRIDE): https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
OWASP — Threat Modeling: https://owasp.org/www-community/Threat_Modeling
NIST — Cybersecurity Framework (ergänzend): https://www.nist.gov/cyberframework