Der EU Cyber Resilience Act: ein Praxisleitfaden für KMU

Eine sicherere digitale Zukunft für KMU

Was wäre, wenn jedes Werkzeug, auf dem Ihr Unternehmen läuft, vom CRM über die Lohnabrechnung bis zur Chat-App Ihres Teams, erst beweisen müsste, dass es sicher ist, bevor Sie es kaufen?

Genau das bringt der EU Cyber Resilience Act (CRA) auf den Markt. Er verändert, wie kleine und mittlere Unternehmen (KMU) in ganz Europa ihre Software und vernetzten Geräte auswählen, kaufen und ihnen vertrauen.

Sie müssen kein Cybersicherheitsexperte sein, um davon zu profitieren. Sie müssen wissen, welche Fragen Sie stellen, welche Warnsignale Sie erkennen und wie aus CRA-Compliance statt eines rechtlichen Häkchens ein Wettbewerbsvorteil werden kann. Dieser Leitfaden liefert alle drei.

Noch immer werden zu viele Produkte mit schwacher Sicherheit ausgeliefert: veraltete Komponenten, Standardpasswörter, keine langfristige Unterstützung. Wenn Angreifer diese Lücken ausnutzen, zahlen KMU oft den höchsten Preis durch Ausfallzeiten, Datenverlust und Rufschaden.

Der CRA dreht das um. Hersteller müssen zeigen, dass ihre Produkte sicher sind, bevor sie auf den EU-Markt kommen. Für Sie heißt das stärkere Zusagen von Lieferanten und eine feste Grundlage, Nachweise zu verlangen, bevor Sie unterschreiben.

Denken Sie an die CE-Kennzeichnung auf physischen Produkten. So wie dieses Zeichen Sicherheit signalisiert, wird die CRA-Konformität zum Vertrauenssignal für digitale Produkte. Sicherheit ist nicht mehr optional.

Was dieses Gesetz anders macht

Die DSGVO schützt personenbezogene Daten. Beim CRA geht es um die Sicherheit des Produkts selbst, von Anfang an und über seine gesamte Lebensdauer. Er verpflichtet Hersteller,

• Schwachstellen schnell zu beheben und Sicherheitsupdates kostenlos bereitzustellen
• offen über Sicherheitsupdates zu informieren und darüber, wie lange ein Produkt unterstützt wird
• die Komponenten Dritter in ihren Produkten zu dokumentieren
• die Konformität nachzuweisen, bevor das Produkt verkauft wird

Für KMU bedeutet das: Sie können Ihre Lieferanten in die Pflicht nehmen und sicherere Produkte erwarten.

KMU als Hersteller

Der CRA ist nicht nur etwas, das Sie von Ihren Lieferanten erwarten können. Er gilt auch für Sie, wenn Sie Produkte mit digitalen Elementen herstellen und in der EU verkaufen. Wenn Ihr Unternehmen Hardware baut, Software in Geräte einbettet oder Software entwickelt, die Sie verkaufen, haben Sie dieselben Pflichten wie große Hersteller. Einführer und Händler, die Produkte weiterverkaufen, haben eigene, leichtere Pflichten, es sei denn, sie verkaufen das Produkt unter eigenem Namen.

Der erste Schritt ist Ihre Lieferkette. Als Hersteller müssen Sie bei jeder Komponente, die Sie integrieren, Sorgfalt walten lassen, Open-Source-Bibliotheken eingeschlossen. Ist die Komponente eines Lieferanten unsicher, wird sein Risiko zu Ihrem Risiko.

Der zweite Schritt ist der Blick nach innen. Der CRA macht Security by Design von guter Praxis zur gesetzlichen Pflicht. Dazu gehört,

• Ihre Entwicklungs- oder Integrationsprozesse zu bewerten
• Schwachstellen schnell zu finden und zu patchen
• zu dokumentieren, wie Sicherheit in jede Phase Ihres Produktlebenszyklus eingebaut ist

Die praktischen Schritte folgen weiter unten.

Der CRA auf einen Blick

Zeitplan

Für KMU als Käufer: Fragen Sie Ihre Lieferanten jetzt, wie sie sich vorbereiten. Ab dem 11. Dezember 2027 dürfen Produkte, die den CRA nicht erfüllen, nicht mehr in der EU in Verkehr gebracht werden.

Wer betroffen ist

Der CRA erfasst Produkte mit digitalen Elementen: Software und Hardware, die sich mit einem Gerät oder einem Netzwerk verbinden. Viele Werkzeuge, die KMU täglich nutzen, fallen darunter:

• installierte Unternehmenssoftware wie Buchhaltungs-, CRM- und Office-Anwendungen
• Clients für Zusammenarbeit und Videokonferenzen
• Laptops, Telefone, Router und Drucker
• Sicherheitssoftware wie VPN-Clients und Passwortmanager

Reines SaaS liegt außerhalb des CRA; viele Cloud-Anbieter fallen stattdessen unter NIS2. Ein Cloud-Backend, das ein Produkt zum Funktionieren braucht, etwa der Server hinter der App eines smarten Schlosses, zählt aber zum Produkt. Herunterladbare Apps und Agenten, die zu einem SaaS-Dienst gehören, fallen in der Regel ebenfalls unter den CRA.

Diese Beteiligten betrifft der CRA:

Produktklassen

Der CRA teilt Produkte mit digitalen Elementen in vier Kategorien ein. Je höher das Risiko, desto strenger die Konformitätsbewertung. Hier ein Überblick, jeweils mit dem, was Sie Ihren Lieferanten fragen sollten:

Standard: die Kategorie mit dem geringsten Risiko

Die Europäische Kommission schätzt, dass etwa 90% der vom CRA erfassten Produkte in die Standardkategorie fallen. Sie bergen weniger inhärentes Risiko als die gelisteten Kategorien, müssen aber trotzdem alle grundlegenden Cybersicherheitsanforderungen des CRA erfüllen.

Beispiele für Standardprodukte, die KMU kaufen:

• allgemeine Software: Office-Pakete, Notiz- und Projektmanagement-Werkzeuge, Buchhaltungs- und Rechnungssoftware, E-Mail-Clients, Chat- und Videokonferenz-Apps, Foto- und Videobearbeitung sowie installierte CRM-, HR- und ERP-Software
• Bürohardware: Laptops, Desktops, Tablets, Smartphones, Monitore, Mäuse, Tastaturen und Webcams
• smarte Bürogeräte ohne Sicherheitsfunktion: smarte Beleuchtung, Thermostate, Klimasteuerungen, Drucker und vernetzte Projektoren
• verbraucherähnliche Geräte im Arbeitsumfeld: Smart-TVs, vernetzte Whiteboards und Konferenzsysteme sowie Digital Signage

Ein Standardprodukt kann trotzdem Komponenten der Klasse I enthalten. Ein Laptop ist ein Standardprodukt, das Betriebssystem darauf aber ist selbst ein Produkt der Klasse I.

Hersteller von Standardprodukten bewerten die Konformität selbst. Das senkt die Latte nicht: Ihre Lieferanten brauchen trotzdem Security by Design, Schwachstellenbehandlung und Dokumentation. Nutzen Sie die Lieferanten-Checkliste unten, um Nachweise zu verlangen.

Wichtig, Klasse I: erhöhtes Risiko

Produkte der Klasse I (Anhang III Teil I) erfüllen Sicherheitsfunktionen oder steuern den Zugang zu Netzwerken und Systemen, eine Kompromittierung hat also weitreichendere Folgen als bei einem Standardprodukt. Die Liste:

• Software und Hardware für Identitätsmanagement und privilegiertes Zugriffsmanagement, einschließlich Authentifizierungslesern wie Ausweis- und biometrischen Lesern
• Browser, Passwortmanager und Anti-Malware-Software
• VPN-Produkte, Netzwerkmanagementsysteme und SIEM-Systeme
• Bootmanager, PKI und Software zur Ausstellung von Zertifikaten, physische und virtuelle Netzwerkschnittstellen sowie Betriebssysteme
• Router, Modems und Switches
• Mikroprozessoren, Mikrocontroller, ASICs und FPGAs mit Sicherheitsfunktionen
• virtuelle Assistenten für das Smart Home und Sicherheitsprodukte für das Smart Home wie smarte Schlösser, Sicherheitskameras, Babyfone und Alarmanlagen
• vernetztes Spielzeug mit sozialer Interaktion oder Standortverfolgung sowie Wearables, die die Gesundheit überwachen oder für Kinder bestimmt sind

Ein Hersteller kann ein Produkt der Klasse I nur selbst bewerten, wenn er harmonisierte Normen, gemeinsame Spezifikationen oder eine europäische Cybersicherheitszertifizierung vollständig anwendet. Andernfalls muss eine notifizierte Stelle beteiligt werden. Bisher sind nur wenige harmonisierte Normen genannt (siehe unsere Übersicht der harmonisierten CRA-Normen), rechnen Sie also damit, dass viele Produkte der Klasse I zunächst über eine notifizierte Stelle laufen.

Wenn Sie ein Produkt der Klasse I kaufen, prüfen Sie, ob sich der Lieferant verpflichtet, es auf Dauer sicher zu halten: eine CE-Kennzeichnung und EU-Konformitätserklärung, regelmäßige Sicherheitsupdates, ein klarer Unterstützungszeitraum und eine End-of-Life-Regelung sowie sichere Voreinstellungen wie starke Authentifizierung und Verschlüsselung. Fragen Sie, wo Ihre Geschäftsdaten gespeichert werden, wie lange das Produkt unterstützt wird und wie schnell der Lieferant Probleme in der Vergangenheit behoben hat. Wählen Sie Lieferanten, die Verantwortung für Sicherheit übernehmen, nicht nur für Funktionen.

Wichtig, Klasse II: hohes Risiko

Klasse II (Anhang III Teil II) ist eine kurze Liste:

• Hypervisoren und Container-Laufzeitsysteme
• Firewalls sowie Systeme zur Angriffserkennung und -verhinderung, darunter Next-Generation-Firewalls und UTM-Appliances
• manipulationssichere Mikroprozessoren und Mikrocontroller

Hersteller können diese Produkte nicht selbst bewerten, auch nicht, wenn sie harmonisierte Normen anwenden. Sie brauchen eine notifizierte Stelle oder ein europäisches Cybersicherheitszertifikat mit Vertrauenswürdigkeitsstufe “substanziell” oder höher.

Wenn Sie ein Produkt der Klasse II kaufen, verlangen Sie die CE-Kennzeichnung, die EU-Konformitätserklärung und die Angaben zur notifizierten Stelle. Die Erklärung zeigt, dass der Hersteller die Cybersicherheitsrisiken des Produkts bewertet hat und sich verpflichtet, es mit Updates sicher zu halten. Kann ein Lieferant sie nicht vorlegen, sobald der CRA gilt, suchen Sie ein anderes Produkt.

Kritische Produkte: die höchste Vertrauenswürdigkeit

Anhang IV nennt drei Produktarten:

• Hardwaregeräte mit Sicherheitsboxen
• Smart-Meter-Gateways und andere Geräte für fortgeschrittene Sicherheitszwecke, einschließlich sicherer Kryptoverarbeitung, etwa Hardware-Sicherheitsmodule (HSMs)
• Smartcards und ähnliche Geräte, einschließlich Secure Elements

Die Kommission kann für diese Produkte per delegiertem Rechtsakt ein europäisches Cybersicherheitszertifikat vorschreiben, zum Beispiel nach EUCC, dem auf Common Criteria basierenden Schema. Wo das nicht geschehen ist, folgen kritische Produkte dem Verfahren der Klasse II.

Kaufen Sie kritische Produkte nur, wenn der Lieferant eine gültige Zertifizierung vorweisen kann. Prüfen Sie, ob das Zertifikat aktuell ist, ob das Produkt über den gesamten Unterstützungszeitraum Sicherheitsupdates bekommt und ob der Lieferant einen Plan hat, Probleme schnell zu beheben. Diese Geräte schützen Ihre sensibelsten Daten und Geschäftsfunktionen.

CRA-konforme Produkte auswählen

Lieferanten-Checkliste für KMU

Nutzen Sie diese Checkliste in Gesprächen mit Lieferanten. CRA-Konformität, regelmäßige Updates und Schwachstellenbehandlung sind nicht verhandelbar. Der Rest stärkt Ihre Position.

1. CRA-Konformität

• Der Lieferant stellt eine EU-Konformitätserklärung bereit und das Produkt trägt die CE-Kennzeichnung.
• Die Kategorie des Produkts ist klar: Standard, Klasse I, Klasse II oder kritisch.
• Wo ein Zertifikat vorgeschrieben ist, ist es aktuell und deckt die Version ab, die Sie kaufen.

2. Sicherheitsupdates

• Sicherheitsupdates kommen regelmäßig und kostenlos.
• Der Unterstützungszeitraum ist angegeben. Für die meisten Produkte verlangt der CRA mindestens fünf Jahre.
• Updates lassen sich automatisch installieren und sind digital signiert.

3. Schwachstellenbehandlung

• Der Lieferant hat einen formellen Prozess, um Schwachstellen zu melden und zu beheben.
• Eine Richtlinie zur koordinierten Offenlegung von Schwachstellen und ein Sicherheitskontakt sind veröffentlicht.
• Schwachstellen werden zügig kommuniziert und gepatcht.
• Bonus: Der Lieferant betreibt ein Bug-Bounty-Programm.

4. Datenschutz und Privatsphäre

• Es ist klar, wo Ihre Geschäftsdaten gespeichert werden.
• Das Produkt unterstützt Ihre Pflichten nach der DSGVO.
• Daten werden im Ruhezustand und bei der Übertragung verschlüsselt.

5. Eingebaute Sicherheitsfunktionen

• Sichere Voreinstellungen: keine Standardpasswörter, Mehr-Faktor-Authentifizierung verfügbar, Verschlüsselung aktiv.
• Rollenbasierte Zugriffskontrolle ist verfügbar.
• Es gibt Protokollierung und Audit-Trails.

6. Verantwortung und Dokumentation

• Der Lieferant stellt Sicherheitshinweise und Benutzeranleitungen bereit.
• Die End-of-Life-Regelung ist klar.
• Der Lieferant übernimmt Verantwortung für Sicherheit, nicht nur für Funktionen.

7. Interoperabilität und Portabilität

• Das Produkt unterstützt offene Standards.
• Sie können Ihre Daten exportieren, wenn Sie den Lieferanten wechseln.
• Das Produkt arbeitet mit Ihren bestehenden IT-Systemen zusammen.

8. Unabhängige Nachweise (optional, aber empfohlen)

• Der Lieferant hat Zertifizierungen Dritter wie ISO/IEC 27001, SOC 2 oder, bei Industrieprodukten, IEC 62443.
• Der Lieferant teilt Berichte von Penetrationstests oder Sicherheitsaudits.
• Ergebnisse von Sicherheitstests sind veröffentlicht oder überprüfbar.

Einen Schritt weiter: Secure-by-Design-Praktiken prüfen

Wenn Sie mehr als die grundlegende CRA-Konformität wollen, verlangen Sie weitere Nachweise, dass das Produkt nach Security by Design gebaut wurde:

• Fragen Sie nach der Richtlinie des Lieferanten für den sicheren Softwareentwicklungslebenszyklus (SSDLC). Sie sollte die Sicherheitsaktivitäten im Detail beschreiben. Verlangen Sie für jede Aktivität einen Nachweis, dass sie im vergangenen Jahr durchgeführt wurde.
• Fragen Sie, wie Bedrohungen im Design erkannt und gemindert werden. Threat Modeling sollte Teil der SSDLC-Richtlinie sein.
• Verlangen Sie die Software Bill of Materials (SBOM) und laden Sie sie in ein kostenloses Werkzeug wie OWASP Dependency-Track, um bekannte Schwachstellen in den aufgeführten Komponenten zu sehen. Hersteller müssen eine SBOM erstellen, aber nicht veröffentlichen, manche teilen sie also nur unter NDA.
• Verlangen Sie den Plan zur Vorfallsbehandlung, einschließlich der Frage, wie der Lieferant die Frühwarnung innerhalb von 24 Stunden erfüllt, die der CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle verlangt.
• Fragen Sie, ob das Produkt bekannte kritische Schwachstellen hat und wie damit umgegangen wird. Der CRA verlangt, dass Produkte ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden.

Diese Prüfungen zeigen Ihnen, ob Sicherheit von Anfang an Teil des Produkts war oder nachträglich angeschraubt wurde.

Warnsignale

Behandeln Sie ein Produkt als hohes Risiko und sehen Sie sich Alternativen an, wenn Sie eines dieser Signale bemerken:

Kein Nachweis der CRA-Konformität

• Der Lieferant kann keine EU-Konformitätserklärung oder CE-Kennzeichnung vorlegen, sobald der CRA gilt.
• Die Zertifizierung ist veraltet, unvollständig oder unklar.

Keine Transparenz

• Es gibt keine Dokumentation dazu, wie Schwachstellen behandelt werden.
• Es gibt keinen veröffentlichten Sicherheitskontakt, etwa eine security@-Adresse, ein PSIRT oder eine Offenlegungsrichtlinie.
• Es gibt keine klare Aussage zur CRA-Konformität.

Veraltete oder nicht unterstützte Software und Hardware

• Geräte werden mit einem Betriebssystem am Ende seiner Lebensdauer oder mit ungepatchten Bibliotheken ausgeliefert.
• Es gibt keine Zusage für Sicherheitsupdates über den Unterstützungszeitraum des Produkts.
• Release Notes fehlen oder sind vage.

Ein schlechter Update-Prozess

• Updates müssen von Hand eingespielt werden, kommen von einer beliebigen Website oder sind nicht digital signiert.
• Es gibt keinen automatischen oder sicheren Update-Mechanismus.
• Der Lieferant sagt nicht, wie lange es Updates geben wird.

Schwache oder unsichere Voreinstellungen

• Das Produkt wird mit Standardpasswörtern ausgeliefert, die sich nicht ändern lassen.
• Mehr-Faktor-Authentifizierung wird nicht unterstützt.
• Das Produkt nutzt veraltete Protokolle wie SSL oder TLS 1.0.

Keine sicheren Entwicklungspraktiken

• Es gibt keinen Nachweis für Security by Design oder sichere Programmierung.
• Der Lieferant kann nicht erklären, wie er auf Schwachstellen testet.
• Penetrationstests, Code-Reviews oder Threat Modeling werden nirgends erwähnt.

Keine unabhängigen Nachweise

• Es gibt weder ISO/IEC 27001 noch, bei Industrieprodukten, IEC 62443, und keine Sicherheitsbewertung durch Dritte, nicht einmal eine freiwillige.
• Der Lieferant tut Compliance-Fragen als “nicht nötig” oder “zu teuer” ab.

Riskantes Geschäftsgebaren

• Es gibt keinen klaren Prozess für die Behandlung von Vorfällen oder Datenpannen.
• Der Lieferant hat in der Vergangenheit Schwachstellenmeldungen ignoriert oder Behebungen verzögert.

Pflichten für KMU, die vernetzte Produkte herstellen

Wie in der Einleitung erklärt, gilt der CRA für jeden Hersteller, der Produkte mit digitalen Elementen in der EU verkauft, nicht nur für Softwareanbieter. KMU, die Hardware bauen, Software in Geräte einbetten oder eigene Software verkaufen, haben dieselben Pflichten wie große Hersteller. Und es geht weit über den Einkauf hinaus: Betroffen sind Design, Entwicklung, Fertigung und Wartung nach dem Verkauf.

Der Rest dieses Leitfadens geht für Produktentwicklungsteams stärker ins technische Detail.

Zentrale Sicherheitspflichten

Ziel des CRA ist, dass jedes Produkt mit digitalen Elementen auf dem EU-Markt nach Security by Design gebaut und nach dem Verkauf für einen angemessenen Zeitraum unterstützt wird. Hersteller müssen Nachweise für ihre Sicherheitsaktivitäten vorlegen können, von Governance und Design bis zum Lebensende.

Der CRA erwartet etablierte Sicherheitspraktiken über den gesamten Entwicklungslebenszyklus. Hier ein Beispiel für einen sicheren Softwareentwicklungslebenszyklus (SSDLC) mit den zugehörigen Sicherheitsaktivitäten:

Security by Design

Sicherheit muss vom ersten Entwurf an Teil des Produkts sein und darf nicht später ergänzt werden. Hersteller wenden die Prinzipien Secure by Design und Secure by Default über den gesamten Entwicklungslebenszyklus an. Dazu gehört,

• in Planung und Architektur eine Cybersicherheitsrisikobewertung durchzuführen und Sicherheitsanforderungen festzulegen, zum Beispiel per Threat Modeling
• sichere Programmierpraktiken und automatisierte Tests anzuwenden
• mit sicheren Standardkonfigurationen auszuliefern, die die Angriffsfläche minimieren

Diese Praktiken dokumentieren Sie in der technischen Dokumentation für Ihre Konformitätsbewertung.

Schwachstellenbehandlung

Sicherheit nach dem Release zählt genauso viel wie sichere Entwicklung. Hersteller brauchen einen Prozess zur Schwachstellenbehandlung, der Folgendes umfasst:

• die Komponenten des Produkts identifizieren und auf bekannte Schwachstellen überwachen, im eigenen Code und in Komponenten Dritter
• Sicherheitshinweise veröffentlichen und Schwachstellen unverzüglich beheben
• Sicherheitsupdates kostenlos verteilen, wo möglich getrennt von Funktionsupdates

Der Unterstützungszeitraum muss widerspiegeln, wie lange das Produkt voraussichtlich genutzt wird, und mindestens fünf Jahre betragen, es sei denn, das Produkt wird voraussichtlich kürzer genutzt. Jedes Sicherheitsupdate muss mindestens zehn Jahre verfügbar bleiben, oder für den Rest des Unterstützungszeitraums, wenn dieser länger ist.

Transparenz

Hersteller müssen Folgendes bereitstellen:

• eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt. Sie ist Teil der technischen Dokumentation, Sie müssen sie also nicht veröffentlichen.
• technische Dokumentation, die die Sicherheitsfunktionen des Produkts beschreibt und darlegt, wie die Konformität bewertet wurde
• eine EU-Konformitätserklärung
• Informationen für Nutzer, einschließlich des Enddatums des Unterstützungszeitraums und einer zentralen Anlaufstelle für Schwachstellenmeldungen

Produkte tragen die CE-Kennzeichnung nach den üblichen CE-Regeln: auf dem Produkt, wo möglich, sonst auf der Verpackung und in der Dokumentation. Bei Software steht die CE-Kennzeichnung in der EU-Konformitätserklärung oder auf der Website, die zur Software gehört.

Die Transparenz erstreckt sich auf die Lieferkette: Sie müssen Sorgfalt walten lassen, damit Komponenten Dritter, Open Source eingeschlossen, die Sicherheit des Produkts nicht gefährden.

Meldepflichten

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die zentrale Meldeplattform der ENISA melden. Die Meldung geht an das nationale CSIRT, das als Koordinator benannt ist, und an die ENISA:

• eine Frühwarnung innerhalb von 24 Stunden, nachdem Sie Kenntnis erlangt haben
• eine ausführlichere Meldung innerhalb von 72 Stunden
• ein Abschlussbericht innerhalb von 14 Tagen, nachdem eine Behebung für eine Schwachstelle verfügbar ist, oder innerhalb eines Monats bei einem schwerwiegenden Vorfall

Sie müssen außerdem betroffene Nutzer informieren und ihnen sagen, wie sie das Problem eindämmen können. Diese Pflichten gelten für alle Produkte mit digitalen Elementen, auch für reine Softwareprodukte und für Produkte, die schon vor Dezember 2027 auf dem Markt waren.

Der CRA verschiebt Cybersicherheit von reaktiv zu proaktiv. Security by Design, strukturierte Schwachstellenbehandlung, Transparenz und schnelle Meldungen werden zum Standard für den Verkauf digitaler Produkte in der EU.

Ein praxisnaher Compliance-Fahrplan

Einzelne Sicherheitskorrekturen bringen Sie nicht zur CRA-Compliance. Sie brauchen einen strukturierten, messbaren Ansatz für sichere Softwareentwicklung. Reifegradmodelle für den SSDLC sind einer der wirksamsten Wege dorthin, zum Beispiel:

• OWASP SAMM (Software Assurance Maturity Model)
• BSIMM (Building Security In Maturity Model)

Diese Frameworks helfen Ihnen,

• den aktuellen Stand Ihrer Softwaresicherheit zu bewerten
• realistische Verbesserungsziele zu setzen
• Ihre Entwicklungspraktiken an den Kernpflichten des CRA auszurichten: Security by Design, Schwachstellenbehandlung, Transparenz und Meldepflichten

Mit einem Reifegradmodell in Ihrem Fahrplan werden diese Prinzipien Teil der Arbeitsweise Ihrer Engineering-Teams statt einer Reihe regulatorischer Häkchen.

OWASP SAMM: strukturierte Anleitung für sichere Entwicklung

Das Diagramm unten zeigt die Sicherheitspraktiken, die OWASP SAMM definiert.

Das OWASP-SAMM-Modell. Quelle: owaspsamm.org, CC BY-SA 4.0.

Der modulare Aufbau von SAMM unterstützt:

• eine Ausgangsbewertung des aktuellen Sicherheitsreifegrads Ihrer Organisation
• Zielreifegrade auf Basis von Risiko, Geschäftszielen und CRA-Anforderungen
• einen maßgeschneiderten Fahrplan, um die gefundenen Lücken zu schließen
• konkrete Anleitungen für Aktivitäten in Governance, Design, Implementierung, Verifikation und Betrieb

Diese Flexibilität macht SAMM gut geeignet für die CRA-Vorbereitung: Sie können Verbesserungen nach Produktklasse, Marktexposition und vorhandenen Fähigkeiten priorisieren.

Schritt 1: Ihr Produktportfolio am Anwendungsbereich des CRA messen

Ermitteln Sie zunächst, welche Ihrer Produkte Produkte mit digitalen Elementen im Sinne des CRA sind.

• Beziehen Sie reine Softwareprodukte ebenso ein wie Hardware mit eingebetteter Software.
• Ordnen Sie jedes Produkt einer Kategorie zu: Standard, Klasse I, Klasse II oder kritisch.
• Legen Sie fest, welche Produkte eine notifizierte Stelle brauchen und für welche die interne Kontrolle (Modul A) genügt.

Das definiert Ihren Compliance-Rahmen und zeigt, worauf Sie sich zuerst konzentrieren sollten, nach Risiko und regulatorischer Exposition.

Schritt 2: Die Lücken in Entwicklungs- und Nachverkaufsprozessen finden

Nutzen Sie SAMM, um den Stand Ihrer Softwaresicherheit in den fünf Geschäftsfunktionen zu bewerten: Governance, Design, Implementation, Verification und Operations.

• Führen Sie mit dem Bewertungssystem von SAMM eine Ausgangsbewertung des Reifegrads durch.
• Identifizieren Sie fehlende oder schwache Praktiken, etwa kein Threat Modeling, langsames Patchen oder unklare Rollen bei der Vorfallsbehandlung.
• Achten Sie besonders auf Pflichten nach dem Verkauf wie die Überwachung von Schwachstellen und Unterstützungszeiträume, die oft übersehen werden.

Die Website von OWASP SAMM bietet Anleitungen für den Einstieg sowie kostenlose Werkzeuge, um Ihren Softwaresicherheitsreifegrad zu bewerten, zu visualisieren und zu kommunizieren. Damit finden Sie Lücken leichter, planen Verbesserungen und verfolgen den Fortschritt. Das Diagramm unten zeigt eine Beispielbewertung mit den aktuellen Stärken und dem geplanten Fortschritt über vier Quartale.

Schritt 3: Sichere Entwicklungspraktiken einführen

Legen Sie auf Basis Ihrer Gap-Analyse für jede Geschäftsfunktion einen Zielreifegrad fest und beginnen Sie mit den Verbesserungen mit der höchsten Priorität.

• Beginnen Sie mit den Bereichen, die direkt an CRA-Pflichten geknüpft sind, etwa Standards für sichere Programmierung, SBOM-Erzeugung und sichere Update-Mechanismen.
• Nutzen Sie die Anleitungen von SAMM, um Sicherheit in die tägliche Entwicklungsarbeit einzubauen.
• Passen Sie die Tiefe der Maßnahmen und der Dokumentation an die Produktklasse an. Kritische Produkte brauchen von beidem mehr.

Schritt 4: Offenlegung von Schwachstellen und Patch-Management vorbereiten

Der CRA verlangt einen Prozess zur Schwachstellenbehandlung und zeitnahe Updates.

• Veröffentlichen Sie eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD).
• Definieren Sie interne Abläufe für Triage, Behebung und Kommunikation, einschließlich der Meldefrist von 24 Stunden.
• Sorgen Sie dafür, dass die Auslieferung Ihrer Patches sicher, zuverlässig und dokumentiert ist.

Die Geschäftsfunktion Operations von SAMM beschreibt Praktiken für Vorfallsmanagement und Patchen im Detail.

Schritt 5: Ihre Teams für die laufenden Pflichten schulen

Compliance ist kein einmaliges Ereignis. Sie braucht kontinuierliches Bewusstsein und klare Zuständigkeiten.

• Schulen Sie Engineering-, Produkt- und Support-Teams zu den CRA-Pflichten und zu sicheren Entwicklungspraktiken.
• Nehmen Sie CRA-Themen wie CE-Kennzeichnung, Meldefristen und Dokumentation in Onboarding und laufende Schulungen auf.
• Nutzen Sie die Geschäftsfunktion Governance von SAMM, um Rollen, Zuständigkeiten und Kennzahlen festzuschreiben.

Unser EU CRA Practitioner Training behandelt diese Pflichten für Engineering-, Produkt- und Compliance-Teams. Wenn Sie das nicht allein angehen wollen, geht die EU CRA Compliance Journey diese Schritte mit Ihnen gemeinsam, von der Produktklassifizierung bis zur EU-Konformitätserklärung.

Open-Source-Software

Der CRA reguliert nicht die Entwicklung von Open Source an sich. Seine Pflichten greifen, wenn Software im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird. Freiwillige und Communities, die Code ohne kommerzielle Absicht teilen, sind nicht direkt betroffen.

Nicht kommerzielle Open Source

Open-Source-Software, die ohne kommerzielle Absicht entwickelt und geteilt wird, etwa Hobbyprojekte, Forschungswerkzeuge oder Community-Bibliotheken auf GitHub, liegt außerhalb des CRA. Mitwirkende brauchen weder Konformitätsbewertungen noch Dokumentation.

Kommerzielle Nutzung von Open Source

Ein Unternehmen, das Open Source in ein Produkt integriert, das es in der EU verkauft, ist für die CRA-Compliance des gesamten Produkts verantwortlich, die Open-Source-Teile eingeschlossen. Es muss bei diesen Komponenten Sorgfalt walten lassen, ihre Schwachstellen behandeln und sie dokumentieren. Die Haftung liegt beim Unternehmen, das das Produkt in Verkehr bringt, nicht beim einzelnen Mitwirkenden. Wenn Sie eine Schwachstelle in einer Open-Source-Komponente finden und beheben, müssen Sie sie außerdem melden und die Behebung mit den Maintainern des Projekts teilen.

Verwalter quelloffener Software

Der CRA führt den Verwalter quelloffener Software (Open-Source Software Steward) ein: eine juristische Person, die kein Hersteller ist und die die Entwicklung von Open-Source-Software für die kommerzielle Nutzung systematisch unterstützt und ihre Tragfähigkeit sichert. Stiftungen wie die Eclipse Foundation und die Linux Foundation sind typische Beispiele, ebenso Unternehmen, die Open-Source-Projekte hosten und pflegen.

Verwalter haben ein leichtes Regime. Sie müssen

• eine Cybersicherheitsrichtlinie einführen und dokumentieren, die die Schwachstellenbehandlung abdeckt
• mit den Marktüberwachungsbehörden zusammenarbeiten
• aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, soweit sie an der Entwicklung beteiligt sind

Verwalter führen keine Konformitätsbewertungen durch und bringen keine CE-Kennzeichnung an. Das ändert sich, wenn eine Organisation die Software selbst im Rahmen einer Geschäftstätigkeit bereitstellt, zum Beispiel gegen Entgelt. Sie wird dann zum Hersteller, mit allen Pflichten.

Nicht jedes Open-Source-Projekt hat einen Verwalter. Der CRA legt einzelnen Mitwirkenden keine Pflichten auf, macht Unternehmen aber voll verantwortlich für die Open Source, die sie ausliefern. Deshalb werden Qualität, Transparenz und Pflege von Open-Source-Komponenten bei der Auswahl stärker ins Gewicht fallen.

Häufige Fehler und wie Sie sie vermeiden

Der CRA setzt klare Erwartungen an sichere Entwicklung und Lebenszyklusmanagement, doch viele Organisationen stolpern bei der Umsetzung. Die meisten Fehltritte entstehen, weil der CRA als Checkliste behandelt wird statt als Veränderung in der Art, wie Software gebaut, gepflegt und gesteuert wird. Hier sind drei häufige Fehler und wie OWASP SAMM hilft, sie zu vermeiden.

1. Den CRA als einmaliges Projekt behandeln

Viele Teams gehen den CRA als Compliance-Sprint vor einer Frist an, ohne langfristige Sicherheitspraktiken aufzubauen. Das führt zu oberflächlichen Korrekturen, die mit der Zeit verfallen und Produkte nach dem Release angreifbar lassen.

SAMM baut kontinuierliche Verbesserung ein. Mit den Reifegradwerten verfolgen Sie den Fortschritt über die Zeit, setzen Ziele, die mit Ihren Produkten wachsen, und bewerten Ihre Praktiken neu, wenn sich Produkte und Bedrohungen ändern. Mit SAMM in Ihrem SSDLC wird CRA-Compliance zu einem laufenden Prozess.

2. Alles dem Engineering überlassen

Sicherheit landet oft allein beim Engineering, ohne Rechtsabteilung, Einkauf oder Produktmanagement. Das schafft blinde Flecken bei Haftung, Lieferantenrisiko und Marktpflichten.

Die Geschäftsfunktion Governance von SAMM macht Sicherheit zu einer abteilungsübergreifenden Aufgabe. Sie hilft Ihnen, Rollen und Zuständigkeiten über Abteilungen hinweg festzulegen, Rechts-, Einkaufs- und Produktteams auf die Sicherheitsziele auszurichten und jeder CRA-Pflicht, etwa CE-Kennzeichnung, Meldepflichten und Lieferantennachweisen, einen klaren Verantwortlichen zu geben. Sicherheit ist eine Aufgabe des ganzen Unternehmens, und das Engineering ist ein Teil davon.

3. Die Dokumentation unterschätzen

Teams konzentrieren sich oft auf technische Maßnahmen und vernachlässigen die Dokumentation, die der CRA verlangt, darunter die Risikobewertung, SBOMs, Verfahren zur Schwachstellenbehandlung und die Konformitätserklärung.

SAMM verknüpft Dokumentation mit jeder Geschäftsfunktion:

• Design und Implementation halten Architekturentscheidungen und sichere Programmierpraktiken fest.
• Verification dokumentiert Testergebnisse und Nachweise für die Konformitätsbewertung.
• Operations führt Patch-Protokolle, Vorfallsberichte und Unterstützungszeiträume.

Die Dokumentation wächst dann mit der Arbeit, statt kurz vor einer Bewertung unter Druck geschrieben zu werden.

Ausblick

Der CRA ist Teil eines größeren Pakets von EU-Regeln. NIS2 regelt die Cybersicherheit wesentlicher und wichtiger Einrichtungen, und der AI Act regelt vertrauenswürdige künstliche Intelligenz. Sie greifen auch ineinander: Bei einem Hochrisiko-KI-System, das die grundlegenden Anforderungen des CRA erfüllt, wird davon ausgegangen, dass es die Cybersicherheitsanforderung des AI Act erfüllt.

Für Unternehmen ist diese Verzahnung eine Chance. Wer CRA-Praktiken früh einführt, mit eingebauter Sicherheit, Transparenz und Lebenszyklusmanagement, kann sich als vertrauenswürdiger Lieferant positionieren, während die Konkurrenz vor Dezember 2027 noch aufholen muss.

Das Wichtigste in Kürze

Der CRA entscheidet über Ihren Zugang zum EU-Markt

• Ab dem 11. Dezember 2027 ist CRA-Konformität Voraussetzung, um Produkte in der EU in Verkehr zu bringen.
• Nicht konformen Produkten drohen Rücknahme, Rückrufe und Bußgelder von bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes.
• Die Meldepflichten gelten schon heute.
• Frühe Vorbereitung gibt Ihnen Zeit, Secure-by-Design-Praktiken aufzubauen, statt in letzter Minute Korrekturen durchzupeitschen.

Setzen Sie auf einen strukturierten Ansatz und ein Reifegradmodell wie SAMM

• Ad-hoc-Sicherheitsmaßnahmen bestehen keine Konformitätsbewertung. Der CRA verlangt systematische, nachweisbare Praktiken.
• OWASP SAMM hilft Ihnen, Ihren aktuellen Stand zu bewerten, Verbesserungsziele zu setzen und einen Fahrplan entlang der CRA-Pflichten aufzubauen.
• Ein Reifegradmodell verteilt Sicherheit auf Teams und den gesamten Lebenszyklus, statt sie einem Team zu überlassen oder nur auf Vorfälle zu reagieren.

Wählen Sie Komponenten und Lieferanten neu aus

• Sie sind für jede Komponente in Ihrem Produkt verantwortlich, einschließlich Open Source und Software Dritter.
• Bewerten Sie Lieferanten und Bibliotheken nach Sicherheitsniveau, Wartungsaktivität und Ausrichtung am CRA.
• Rechnen Sie mit mehr Fragen zu SBOMs, Lizenzen und der Offenlegung von Schwachstellen, sowohl von Ihren Kunden als auch an Ihre Lieferanten.

Sie wollen wissen, wo Sie stehen? Nutzen Sie die kostenlose EU-CRA-Selbstbewertung oder vereinbaren Sie ein kostenloses EU-CRA-Strategiegespräch.

Glossar

Nützliche Ressourcen

• Rechtstext des CRA auf EUR-Lex: die amtliche Veröffentlichung der Verordnung.
• EU-Cybersicherheitspolitik: der Überblick der Europäischen Kommission, einschließlich CRA und NIS2.
• CRA-FAQ im CRA-Hub der ORC WG: eine von der Community gepflegte FAQ zu häufigen CRA-Fragen.
• CRA-Überblick der ORC WG: Ressourcen der Open Regulatory Compliance Working Group.
• OWASP SAMM: das Modell, die Werkzeuge und die Anleitungen.