Security-by-Design im CRA umsetzen

Security-by-Design im CRA ist kein Slogan, sondern ein 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 – nicht pauschal, sondern 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; wer sie ignoriert, riskiert die höchste Bußgeldstufe der Verordnung.

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 beim Inverkehrbringen 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 kein Wunschzettel, sondern die Grundlage der Risikobewertung, die nach Artikel 13 und Anhang I dokumentationspflichtig ist. Threat-Modeling ist die anerkannte 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. Vier Bausteine tragen den Prozess:

• 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 sich an der erwarteten Produktlebensdauer orientiert (Leitwert mindestens fünf Jahre).

Der entscheidende Punkt für die meisten Unternehmen: Das ist kein Greenfield-Projekt. Der SSDLC wird in einen bestehenden Entwicklungsprozess integriert – als Ergänzung von Gates, Checklisten und Automatisierung, nicht als Neubau.

Security-by-Default – der oft ü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. Genau an diesen Punkten scheitern in der Praxis viele IoT- und Embedded-Produkte – und genau hier setzt Anhang I 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 entfernt statt nur abgeschaltet.
• 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 muss maschinenlesbar sein – CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 (vgl. BSI TR-03183-2 v2.1.0), mindestens auf Ebene der Top-Level-Abhängigkeiten; eine allgemeine Veröffentlichungspflicht besteht nicht. Die technische Dokumentation ist zehn Jahre ab Inverkehrbringen aufzubewahren.

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 – der Abschlussbericht folgt zwei unterschiedlichen Fristen: 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme bei aktiv ausgenutzten Schwachstellen, ein Monat nach der 72-Stunden-Meldung bei schweren Sicherheitsvorfällen. Frühwarnung binnen 24 Stunden, vollständige Meldung binnen 72 Stunden.

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 %.

Was Blackfort tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Hersteller dabei, Security-by-Design in bestehende Entwicklung zu integrieren – nicht als Papier-Übung, sondern entlang eines belastbaren SSDLC: Threat-Modeling und Risikobewertung, Härtungs- und Default-Konzepte, SBOM-Aufbau, Verifikation per SAST/DAST/SCA und Produkt-Pentest sowie die Aufbereitung der technischen Dokumentation. Der Fokus liegt darauf, Aufwand risikobasiert dort zu bündeln, wo er den größten Schutzbeitrag leistet.

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.