CRA-Compliance für Engineering-Teams: Der vollständige Leitfaden
Der EU Cyber Resilience Act (CRA) führt verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen ein, die auf dem europäischen Markt verkauft werden. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden. Dieser Leitfaden behandelt alles, was Engineering-Teams wissen müssen — Fristen, Meldepflichten, Produktklassifizierung und wie Sie die Compliance-Nachweise generieren, die Auditoren erwarten.
Wichtige Fristen
Das 3-Stufen-Meldesystem
Hersteller müssen jede aktiv ausgenutzte Schwachstelle oder jeden schwerwiegenden Sicherheitsvorfall an ENISA und ihre nationale Behörde melden:
Eine kurze Meldung, sobald Sie Kenntnis von einem schwerwiegenden Vorfall oder einer aktiv ausgenutzten Schwachstelle erlangen. Muss angeben, ob grenzüberschreitende Auswirkungen vermutet werden. Dies ist ein Geschwindigkeitstest — Sie benötigen automatisierte Erkennung und vorgefertigte Meldevorlagen.
Eine detaillierte Aktualisierung mit einer ersten Bewertung des Vorfalls, des Schweregrads und der Kompromittierungsindikatoren (IoCs), sofern verfügbar.
Ein umfassender Bericht: Beschreibung der Schwachstelle oder des Vorfalls, ergriffene Abhilfemaßnahmen (veröffentlichte Patches, geänderte Konfigurationen) und das verbleibende Risikoniveau für Nutzer.
Alle Berichte gehen an ENISA über die Single Reporting Platform (SRP) und an die nationale Behörde — das BSI in Deutschland, das NCSC-NL in den Niederlanden, das CCB in Belgien oder die ANSSI in Frankreich. Das 24-Stunden-Fenster ist die größte Herausforderung. Manuelle Prozesse können es nicht zuverlässig einhalten.
Produktklassifizierung
Der CRA klassifiziert Produkte in vier Stufen basierend auf ihrem Cybersicherheitsrisiko:
CRA und NIS2: Wo sich die Anforderungen überschneiden
Engineering-Teams müssen CRA und NIS2 gleichzeitig bewältigen. Beide Verordnungen stammen aus der breiteren EU-Cybersicherheitsstrategie, zielen aber auf unterschiedliche Bereiche ab:
- CRA zielt auf Produkte ab — die Software und vernetzten Geräte selbst. Er verlangt Secure-by-Design-Entwicklung, Schwachstellenbehandlung und Vorfallmeldung.
- NIS2 zielt auf Organisationen ab — die Einrichtungen, die wesentliche und wichtige Dienste betreiben. Sie verlangt Risikomanagement, Vorfallmeldung und Lieferkettensicherheit.
Die Überschneidung ist erheblich: Beide erfordern Vorfallmeldefristen, Nachweise über Sicherheitspraktiken und schaffen Sanktionen bei Nichteinhaltung. Die Engineering-Praxis-Daten, die die Secure-by-Design-Anforderungen des CRA erfüllen, lassen sich häufig direkt auf die Risikomanagement-Nachweise der NIS2 abbilden.
Was „Secure-by-Design" in der Praxis bedeutet
CRA Artikel 10 verlangt, dass Produkte „so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Niveau an Cybersicherheit gewährleisten." Für Engineering-Teams bedeutet das nachweisbare Praktiken über den gesamten SDLC:
- CI/CD-Pipeline-Konfiguration als Nachweis sicherer Entwicklungsprozesse. Sind Builds automatisiert? Sind Sicherheitsprüfungen als Gates eingerichtet?
- Code-Review-Standards als Nachweis der Qualitätssicherung. Werden Pull Requests vor dem Merge geprüft? Werden Review-Anforderungen durchgesetzt?
- Branch-Protection-Richtlinien als Nachweis der Zugangskontrolle. Kann jeder auf den Hauptbranch pushen? Sind Force-Pushes blockiert?
- Testabdeckung als Nachweis der Schwachstellenbewertung. Gibt es automatisierte Tests? Laufen Tests bei jedem Commit?
- Abhängigkeitsmanagement als Nachweis der SBOM-Compliance. Können Sie jede Drittanbieter-Komponente auflisten? Werden Abhängigkeiten auf bekannte Schwachstellen gescannt?
Concordance adressiert dieses Problem, indem es 50 Engineering-Protokolle über 6 SDLC-Phasen bewertet und die Ergebnisse direkt auf CRA-, NIS2-, SOC-2- und ISO-27001-Anforderungen abbildet — aus einem einzigen Scan.
Häufig gestellte Fragen
Gilt der CRA für Open-Source-Software?
Der CRA gilt für Open-Source-Software nur, wenn sie im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Rein ehrenamtlich entwickelte Open-Source-Projekte sind grundsätzlich ausgenommen. Wenn Sie jedoch Open-Source-Komponenten in ein kommerzielles Produkt integrieren, sind Sie als Hersteller für die Sicherheit dieser Komponenten verantwortlich.
Was passiert bei Nichteinhaltung?
Verstöße gegen wesentliche Anforderungen können mit Geldbußen von bis zu 15 Millionen Euro oder 2,5% des weltweiten Jahresumsatzes geahndet werden — je nachdem, welcher Betrag höher ist. Wiederholte Verstöße können zum Rückruf des Produkts vom EU-Markt führen.
Wir haben bereits SOC 2 / ISO 27001. Wie viel davon gilt für den CRA?
Erhebliche Überschneidungen bestehen in den Bereichen Zugangskontrolle, Schwachstellenmanagement und Vorfallreaktion. Der CRA fügt jedoch Engineering-spezifische Anforderungen hinzu: Secure-by-Design-Nachweise aus den tatsächlichen Entwicklungspraktiken, SBOM-Anforderungen und produktbezogene Schwachstellenbehandlung. Bestehende Zertifizierungen decken etwa 40-60% der CRA-Anforderungen ab.
Verwandte Leitfäden
Prüfen Sie, wo Ihre Engineering-Praktiken in Bezug auf CRA-Anforderungen stehen. Kostenloser Foundation Scan — keine Registrierung erforderlich, Ergebnisse in unter 2 Minuten.
Hinweis: Concordance ist ein englischsprachiges Tool. Der Scan und die Ergebnisse sind auf Englisch verfügbar.
Kostenlosen Foundation Scan starten →