Security-by-Design im CRA umsetzen

Security-by-Design im CRA: ein prüfbarer Anforderungskatalog

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) macht „Security-by-Design" und „Security-by-Default" von einem Best-Practice-Wunsch zu einem prüfbaren Pflichtenheft. Die konkreten Vorgaben stehen in Anhang I Teil 1 der Verordnung. Sie gelten produktbezogen und müssen aus der Risikobewertung nach Artikel 13 heraus begründet angewendet werden, in der Tiefe, die das jeweilige Produkt und sein Einsatzkontext erfordern. Wer diese Anforderungen erfüllt und nachweisen kann, hat den fachlichen Kern der CRA-Konformität in der Hand; Verstöße gegen Anhang I fallen unter die höchste Bußgeldstufe der Verordnung (Art. 64 Abs. 2).

Wichtig für die Einordnung der Fristen: Seit dem 11.09.2026 greifen die Melde- und Berichtspflichten nach Artikel 14 als erste harte Herstellerpflicht. Die vollständige Anwendbarkeit sämtlicher Produktanforderungen aus Anhang I - und damit auch die durchgängige Security-by-Design-Pflicht - tritt zum 11.12.2027 ein. Der scheinbar lange Vorlauf ist trügerisch: Sicheres Produktdesign lässt sich nicht kurz vor einem Stichtag nachrüsten, weil es Architektur, Entwicklungsprozess und Lieferkette betrifft. Dieser Beitrag ist eine fachliche Einordnung und ersetzt keine Rechtsberatung im Einzelfall.

Was Anhang I Teil 1 konkret verlangt

Die Cybersicherheitsanforderungen lassen sich in einen prüfbaren Katalog übersetzen. Kernpunkte:

• Auslieferung ohne bekannte ausnutzbare Schwachstellen - der Zustand bei der Bereitstellung auf dem Markt muss „sauber" sein.
• Sichere Standardkonfiguration (Security-by-Default) inklusive Rücksetzbarkeit auf einen sicheren Ausgangszustand.
• Schutz vor unbefugtem Zugriff durch Authentifizierung und Zugriffsverwaltung (Least-Privilege).
• Schutz der Vertraulichkeit - Verschlüsselung ruhender und übertragener Daten - und der Integrität von Daten, Befehlen und Konfiguration.
• Datenminimierung: nur verarbeiten, was für die Funktion nötig ist.
• Verfügbarkeit wesentlicher Funktionen und Resilienz gegen Denial-of-Service.
• Minimierung der Angriffsfläche und Defense-in-Depth.
• Protokollierung und Überwachung sicherheitsrelevanter Ereignisse.
• Update-Fähigkeit inklusive sicherer Update-Mechanismen - signiert, authentisiert, möglichst automatisierbar.

Diese Liste ist die Grundlage der Risikobewertung, die nach Artikel 13 und Anhang I dokumentationspflichtig ist. Threat-Modeling ist eine etablierte Methode, um zu begründen, welche dieser Anforderungen in welcher Tiefe greifen. Mehr dazu im Überblick zum Cyber Resilience Act.

Vom Katalog zum Prozess: der sichere Entwicklungslebenszyklus

Anhang I Teil 1 beschreibt das „Was". Das „Wie" liefert ein sicherer Produktentwicklungslebenszyklus (Secure SDLC), für den sich etablierte Referenzen wie IEC 62443-4-1 anbieten. Der Prozess besteht aus vier Bausteinen:

• 1. Risikobewertung als Ausgangspunkt. Threat-Modeling (z. B. STRIDE über Datenflussdiagramme) bestimmt Schutzbedarf und Angriffspfade. Ergebnis ist eine nachvollziehbare Ableitung, welche Anforderung durch welche Maßnahme abgedeckt wird.
• 2. Sichere Architektur und Implementierung. Härtung, sichere Defaults, Secrets-Management, Secure-Coding-Guidelines und Abhängigkeits-Governance mit SBOM von Anfang an.
• 3. Verifikation. SAST, DAST und SCA in der Pipeline, ergänzt um Produkt-Pentest und Security-Reviews - jeweils mit dokumentierten Ergebnissen für die technische Dokumentation.
• 4. Betrieb und Wartung. Schwachstellen-Handling, eine Coordinated-Vulnerability-Disclosure-Policy (CVD) und Update-Bereitstellung über den gesamten Support-Zeitraum, der die voraussichtliche Nutzungsdauer widerspiegelt (mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8).

Für Unternehmen mit bestehender Entwicklung lässt sich der SSDLC in den vorhandenen Prozess integrieren, als Ergänzung von Gates, Checklisten und Automatisierung. Was fehlt, zeigt der Abgleich mit Anhang I.

Security-by-Default - der leicht übersehene Teil

Das Produkt muss im Auslieferungszustand sicher sein, ohne dass der Kunde erst nachkonfigurieren muss. Konkret heißt das: keine Standardpasswörter (stattdessen erzwungene Einrichtung individueller Zugangsdaten beim ersten Start), minimale offene Ports und Dienste, deaktivierte Debug- und Wartungsschnittstellen, sichere kryptografische Voreinstellungen und ein definierter, sicherer Reset-Zustand. An diesen Punkten setzt Anhang I Teil I Nr. 2 Buchst. b, d und j an.

Ein durchgespieltes Beispiel: das vernetzte Steuergerät

Ein Hersteller vertreibt ein netzwerkfähiges Steuergerät mit Web-Oberfläche und Firmware-Update. Wie ließe sich Security-by-Design schematisch umsetzen?

• Threat-Modeling: Datenflussdiagramm zeigt drei Vertrauensgrenzen (Web-UI, Update-Kanal, Feldbus). STRIDE identifiziert u. a. Spoofing am Update-Kanal und Elevation of Privilege über die Web-UI.
• Sichere Defaults: kein Auslieferungspasswort; beim ersten Login wird ein individuelles Passwort erzwungen. Telnet und offene Debug-Ports sind ab Werk deaktiviert.
• Least-Privilege & Angriffsflächenreduktion: Web-UI-Prozess läuft mit minimalen Rechten; nicht benötigte Dienste sind aus der Firmware entfernt.
• Secrets-Management: keine hartkodierten Schlüssel in der Firmware; gerätebezogene Schlüssel im Secure Element.
• Sicherer Update-Mechanismus: signierte Firmware, Signaturprüfung vor dem Flashen, Rollback-Schutz.
• Verifikation: SCA erzeugt die SBOM, DAST prüft die Web-UI, ein Produkt-Pentest bestätigt die Maßnahmen. Alle Ergebnisse fließen in die technische Doku.

Nachweis in der technischen Dokumentation (Anhang VII)

Security-by-Design entfaltet regulatorisch nur Wirkung, wenn es belegt ist. Die technische Dokumentation nach Anhang VII bündelt den Nachweis: Risikobewertung, Design- und Architekturentscheidungen, Verifikationsergebnisse und die Software-Stückliste (SBOM). Die SBOM ist in einem gängigen maschinenlesbaren Format zu erstellen und muss zumindest die obersten Abhängigkeiten enthalten (Anhang I Teil II Nr. 1); die BSI TR-03183-2 (v2.1.0) nennt CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1. Eine allgemeine Veröffentlichungspflicht besteht nicht. Die technische Dokumentation ist mindestens zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, welcher Zeitraum länger ist.

Diese Nachweiskette verbindet Security-by-Design mit der Pflichtenlage, die seit dem 11.09.2026 greift: Wer die Melde-Kaskade nach Artikel 14 bedienen muss, braucht ein funktionierendes Schwachstellen-Handling. Zur Erinnerung, die Meldung ist gestaffelt: Frühwarnung unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnis; Meldung mit den verfügbaren allgemeinen Informationen unverzüglich, in jedem Fall innerhalb von 72 Stunden; Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist (aktiv ausgenutzte Schwachstelle), bzw. innerhalb eines Monats nach der Meldung (schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Sicherheit des Produkts).

Der Einsatz lohnt die Sorgfalt: Verstöße gegen Anhang I sowie Artikel 13/14 können mit bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes geahndet werden (der jeweils höhere Betrag). Für sonstige Pflichten liegt die Stufe bei bis zu 10 Mio. € oder 2 %, für falsche Angaben gegenüber Behörden bei bis zu 5 Mio. € oder 1 %. Art. 64 gehört nicht zu den vorgezogenen Vorschriften und gilt ab dem 11.12.2027 (Art. 71 Abs. 2); das deutsche Durchführungsgesetz (Bundestag-Drucksache 21/6134), das Behörde und Bußgeldverfahren regeln soll, ist zum 9. Oktober 2026 weder beschlossen noch verkündet.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) unterstützt Hersteller dabei, Security-by-Design nachweisbar zu machen: Risikobewertung je Produkt mit Bedrohungsmodell, Abgleich eines bestehenden Entwicklungsprozesses mit Anhang I (etwa gegen IEC 62443-4-1), SBOM-Kette aus dem Build und die Aufbereitung der technischen Dokumentation. Penetrationstests gehören nicht zu unserem Angebot.

Sinnvoller Startpunkt ist die Klärung der eigenen Betroffenheit und Produktklasse. Nutzen Sie dafür den Betroffenheits-Check, informieren Sie sich zum passenden Vorgehen für kleine und mittlere Unternehmen oder für Ihre Branche - oder nehmen Sie direkt Kontakt zum CRA-Team auf. Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.