Threat Modeling für den CRA
Threat Modeling und Bedrohungsanalyse: Risikobewertung nach CRA je Produkt
Wir erstellen mit Ihren Entwicklern das Bedrohungsmodell für jedes Produkt und daraus die dokumentierte Risikobewertung für die technische Dokumentation. Grundlage sind Quellcode, Deployment-Konfiguration und Dokumentation. Das Modell liegt als Code in Ihrem Repository und läuft bei einem geänderten Release erneut.
Was der CRA zur Risikobewertung verlangt
Hersteller führen eine Bewertung der Cybersicherheitsrisiken ihres Produkts durch und berücksichtigen das Ergebnis von der Planung bis zur Wartung (Art. 13 Abs. 2). Grundlage sind Zweckbestimmung und vernünftigerweise vorhersehbare Verwendung. Die Bewertung gibt an, ob und wie die Sicherheitsanforderungen aus Anhang I Teil I Nr. 2 auf das Produkt anwendbar sind und wie sie umgesetzt werden. Sie wird während des Unterstützungszeitraums dokumentiert und gegebenenfalls aktualisiert (Art. 13 Abs. 3).
Die Bewertung gehört in die technische Dokumentation (Art. 13 Abs. 4, Anhang VII Nr. 3). Ist eine grundlegende Anforderung nicht anwendbar, steht dort eine klare Begründung. Anhang I Teil I Nr. 2 beginnt mit „Auf der Grundlage der Bewertung der Cybersicherheitsrisiken“: Zugriffsschutz, Integrität oder Angriffsfläche leiten sich aus dieser Bewertung ab.
Leistungsbausteine
Wir beginnen mit einem Referenzprodukt und übertragen Modell und Ablauf danach auf die übrigen Produkte.
Modell und Bedrohungsanalyse
Architektur, Datenflüsse und Vertrauensgrenzen aus Code, Konfiguration und Dokumentation, als Modell im Repository; Aufzählung der Bedrohungen nach STRIDE je Element.
Anbindung an die SBOM-Kette
Bekannte Schwachstellen der verwendeten Komponenten fließen aus der Software-Stückliste in die Bewertung ein. Fehlt die SBOM-Kette noch, bauen wir sie mit Ihnen auf.
SBOM und SchwachstellenmanagementZuordnung zu Anhang I
Je Anforderung aus Anhang I Teil I Nr. 2: anwendbar oder nicht, wie umgesetzt, und bei Nichtanwendbarkeit eine klare Begründung.
Übernahme in die technische Dokumentation
Die Risikobewertung strukturiert für Anhang VII Nr. 3, abgestimmt mit den übrigen Unterlagen.
Technische DokumentationWas Sie in der Hand haben
Ein Dokument für die Akte und ein Modell, das weiterläuft.
01
Risikobewertung je Produkt
Dokumentiert und aufgebaut für die technische Dokumentation nach Anhang VII Nr. 3.
02
Bedrohungsmodell als Code
In Ihrem Repository, versioniert mit dem Produkt und für Ihr Team lesbar.
03
Wiederholbarer Lauf
Ein geändertes Release ergibt eine aktualisierte Bedrohungsliste; Ihre Entwickler prüfen, ob sich die Bewertung ändert. So halten Sie die Bewertung nach Art. 13 Abs. 3 aktuell.
So sieht ein Auszug der Risikobewertung aus
Schematisch, für ein vernetztes Gerät mit Weboberfläche und Cloud-Anbindung: Bedrohung am Modell, Anforderung aus Anhang I, Begründung.
| Element im Modell | Bedrohung (STRIDE) | Anhang I Teil I Nr. 2 | Risiko | Maßnahme und Begründung |
|---|---|---|---|---|
| Wartungszugang über die Weboberfläche | Spoofing: Anmeldung mit fremder Identität | Buchst. d | hoch | Authentifizierung je Gerät, kein gemeinsames Standardkennwort, Meldung fehlgeschlagener Anmeldungen |
| Update-Kanal zum Gerät | Tampering: manipulierte Firmware | Buchst. c und f | hoch | Signaturprüfung vor der Installation, Abbruch bei ungültiger Signatur |
| Telemetrie an den Cloud-Dienst | Information Disclosure: Mitlesen im Netz | Buchst. e | mittel | Verschlüsselte Übertragung; Restrisiko dokumentiert |
Fiktives Beispiel zur Veranschaulichung, kein Kundenprodukt. Die Bewertung und die Maßnahmen legen Sie für Ihr Produkt mit Ihren Entwicklern fest.
Vorgehen
Vom Quellcode zur Bewertung, die ein Prüfer nachvollziehen kann.
1
Kostenloses Erstgespräch
Produkte, Architektur, vorhandene Sicherheitsunterlagen. Danach ein Angebot mit klar abgegrenztem Umfang.
2
Zugang und Unterlagen
Lesezugriff auf Code, Konfiguration und Architekturdokumentation des Referenzprodukts.
3
Modell ableiten
Modell im Repository anlegen, Bedrohungen automatisch aufzählen.
4
Bewerten
Arbeitssitzung mit Ihren Entwicklern: reale Bedrohungen, Risiko, Maßnahmen, Begründung.
5
Dokumentieren und übertragen
Risikobewertung für die technische Dokumentation, danach Übertragung auf weitere Produkte.
Was das Werkzeug übernimmt und was Sie mit uns entscheiden
Das Bedrohungsmodell liegt als maschinenlesbares Modell in Ihrem Repository. Gegen dieses Modell läuft die Aufzählung der Bedrohungen automatisch und reproduzierbar, nach STRIDE für jedes Element und jeden Datenfluss. Bekannte Schwachstellen Ihrer Komponenten kommen aus der SBOM-Kette, wenn sie besteht; sonst bauen wir sie mit Ihnen auf.
Vier Dinge entscheidet das Werkzeug nicht: welche Vertrauensgrenzen in Ihrem Einsatz zählen, welche der aufgezählten Bedrohungen in der realen Umgebung Ihres Produkts bestehen, wie das Risiko bewertet wird und mit welcher Begründung ein Prüfer die Bewertung nachvollzieht. Das erarbeiten wir mit Ihren Entwicklern, und erst diese Arbeit macht aus einer Bedrohungsliste eine Risikobewertung.
Was wir von Ihnen brauchen
Ansprechpartner je Produkt
Eine benannte Person aus der Entwicklung, die das Produkt kennt.
Lesezugriff
Auf Quellcode, Deployment-Konfiguration, Architektur- und vorhandene Sicherheitsdokumentation.
Zeit Ihrer Entwickler
Für die Arbeitssitzungen, in denen Bedrohungen bewertet und begründet werden.
Abgrenzung
Damit die Erwartungen stimmen:
- Penetrationstests gehören nicht zu unserem Angebot. Das Bedrohungsmodell beschreibt mögliche Angriffe; es führt keine durch.
- Keine Rechtsdienstleistung: Wir schätzen technisch ein und markieren rechtlich zu entscheidende Fragen zur Prüfung durch Ihre Rechtsabteilung oder Kanzlei.
- Wir sind keine notifizierte Stelle und keine Zertifizierungsstelle und stellen weder Bescheinigungen noch Zertifikate aus.
- Code-Änderungen in Ihren Produkten setzen Ihre Entwickler um, sofern nicht gesondert vereinbart.
Die Pflichten aus dem CRA bleiben bei Ihrem Unternehmen. Wir unterstützen Sie dabei, sie zu erfüllen und nachzuweisen.
Häufige Fragen
Ist Threat Modeling für den CRA Pflicht?+
Der CRA schreibt keine bestimmte Methode vor. Er verlangt eine dokumentierte Bewertung der Cybersicherheitsrisiken je Produkt (Art. 13 Abs. 2 bis 4). Threat Modeling ist ein etabliertes Verfahren, diese Bewertung strukturiert und nachvollziehbar zu erstellen.
Was ist der Unterschied zwischen Bedrohungsanalyse und Risikobewertung?+
Die Bedrohungsanalyse ermittelt, was am Produkt angegriffen werden kann. Die Risikobewertung nach CRA stuft diese Bedrohungen für den vorgesehenen Einsatz ein und leitet daraus ab, welche Anforderungen aus Anhang I wie umgesetzt werden oder warum sie nicht anwendbar sind.
Brauchen wir dafür ein eigenes Threat-Modeling-Tool?+
Nein. Wir bringen Methode und Werkzeug mit; das Modell liegt danach als Code in Ihrem Repository, und Ihr Team kann es weiter nutzen. Einen Lizenzkauf auf Ihrer Seite braucht es dafür nicht.
Was passiert bei einem neuen Release?+
Das Modell läuft erneut. Geänderte Komponenten zeigen sich über die SBOM-Kette, Änderungen an der Architektur, sobald sie im Modell nachgezogen sind. Ihre Entwickler prüfen dann, ob sich die Bewertung ändert. So halten Sie die Risikobewertung während des Unterstützungszeitraums aktuell (Art. 13 Abs. 3).
Was kostet Threat Modeling für ein Produkt?+
Der Aufwand hängt von Architektur, Zahl der Produkte und vorhandenen Unterlagen ab. Nach einem kostenlosen Erstgespräch erhalten Sie ein Angebot mit klar abgegrenztem Umfang.
Zum Weiterlesen
- CRA-Risikobewertung und Threat Modeling: STRIDE, Attack-Trees, DFD
- Technische Dokumentation nach dem CRA
- CRA-Checkliste, Schritt 4
- IEC 62443 und der CRA
- CRA-Beratung: alle Leistungen
Diese Inhalte dienen der allgemeinen technischen und organisatorischen Information zum Cyber Resilience Act (Verordnung (EU) 2024/2847) und stellen keine Rechtsberatung dar (keine Rechtsdienstleistung i.S.d. RDG).
Stand: 2026-10-09
Kontakt aufnehmen
Threat Modeling für Ihre Produkte
Nennen Sie uns ein Produkt für den Anfang und skizzieren Sie seine Architektur. Das Erstgespräch ist kostenlos und unverbindlich.