CRA-Umsetzung - Cyber Resilience Act für vernetzte Produkte, prüffest umgesetzt

Der CRA (Verordnung (EU) 2024/2847) ist eine horizontale EU-Verordnung, die Cybersicherheits-Anforderungen für „Produkte mit digitalen Elementen“ - also Hard- und Software - auf dem EU-Markt festlegt. Er ist seit Dezember 2024 in Kraft.

In Kraft ist er seit Dezember 2024. Die Melde-Pflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle greifen ab dem 11. September 2026, die übrigen Pflichten - inklusive CE-Kennzeichnung - ab dem 11. Dezember 2027. Wer Produkte entwickelt, sollte jetzt anfangen: Security-by-Design lässt sich nicht kurz vor Schluss nachrüsten.

Für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen - also Software ebenso wie vernetzte Hardware. Ausgenommen sind Produkte, die bereits unter sektorspezifische Regeln fallen (z. B. Medizinprodukte, Kraftfahrzeuge, Luftfahrt).

Jedes Hard- oder Softwareprodukt (und dessen Datenfernverarbeitungslösungen), das direkt oder indirekt mit einem Gerät oder Netz verbunden werden kann. Das reicht von der Maschinensteuerung über IoT-Geräte bis zur Business-Software.

Für Verstöße gegen die grundlegenden Anforderungen bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, was höher ist - dazu können Marktrücknahme-Anordnungen kommen.

Ja, sobald Deine Maschinen oder Steuerungen Software enthalten oder vernetzt sind. CRA und Maschinenverordnung greifen ineinander; wir denken beides zusammen mit IEC 62443 für die OT-Seite. Details auf unserer Maschinenbau-Seite.

NIS2 betrifft den sicheren Betrieb Deiner Organisation, der CRA die Sicherheit Deiner Produkte. Wer Produkte herstellt und zugleich NIS2-pflichtig ist, braucht beides - die technischen Maßnahmen überschneiden sich aber erheblich.

Eine Software Bill of Materials listet alle Software-Komponenten und Abhängigkeiten Deines Produkts. Der CRA verlangt sie, damit bei einer neuen Schwachstelle in einer Fremdkomponente sofort klar ist, welche Produkte betroffen sind. Wir bauen die SBOM in Deinen Build-Prozess ein, statt sie einmalig von Hand zu pflegen.

Der CRA knüpft an die Bereitstellung auf dem EU-Markt an. Eine reine Eigenentwicklung für den internen Gebrauch, die Du weder verkaufst noch mit einem Produkt mitlieferst noch als Dienst anbietest, ist damit in der Regel nicht erfasst. Sobald sie Teil eines Produkts wird oder an Kunden geht, ändert sich das. Die Einordnung Deiner konkreten Software gehört in die Betroffenheitsanalyse, die rechtsverbindliche Bewertung zu Deiner Rechtsberatung.

Der CRA zielt auf Produkte, die ab Geltungsbeginn in Verkehr gebracht werden; für Bestandsprodukte wird er vor allem dann relevant, wenn sie wesentlich verändert werden. Bei laufend weiterentwickelten Produktlinien ist deshalb genau das die entscheidende Frage: Wo endet normale Pflege, wo beginnt die wesentliche Änderung? Wir ziehen diese Linie produktbezogen in der Betroffenheitsanalyse, damit Du sie nicht im Nachhinein begründen musst.

Maßstab ist der Unterstützungszeitraum, den Du an der erwarteten Nutzungsdauer Deines Produkts ausrichtest und der in der Regel mindestens fünf Jahre beträgt; er muss für Käufer klar erkennbar sein. Der eigentliche Aufwand liegt selten im ersten Patch, sondern darin, alte Produktstände über Jahre bauen, testen und sicher ausrollen zu können. Genau das planen wir mit Dir in den Entwicklungs- und Release-Prozess ein.

Für Standard-Produkte, also die große Mehrheit, genügt die Selbstbewertung durch Dich als Hersteller. Für wichtige Produkte der Klassen I und II sowie für kritische Produkte gelten strengere Verfahren, die je nach gewähltem Weg eine notifizierte Stelle einbinden. Seraph IT ist weder notifizierte Stelle noch Zertifizierer - wir erstellen die technischen Nachweise, bereiten das Verfahren vor und begleiten es.

Im Kern: Beschreibung des Produkts und seines vorgesehenen Einsatzes, Design- und Architekturinformationen, die Bewertung der Cybersicherheitsrisiken, der Nachweis, wie die grundlegenden Anforderungen erfüllt werden, die Prozesse der Schwachstellenbehandlung samt SBOM, Prüf- und Testberichte sowie die EU-Konformitätserklärung. Wir bauen die Doku so auf, dass sie mit jedem Release fortgeschrieben wird, statt sie kurz vor einer Prüfung zu rekonstruieren.

Ein veröffentlichter, verlässlicher Weg, über den Sicherheitsforscher und Kunden Dir Schwachstellen melden können: eine erreichbare Kontaktstelle, eine veröffentlichte Policy mit Erwartungen an beide Seiten, Eingangsbestätigung und Bearbeitungsfristen sowie ein definierter Weg zur Veröffentlichung und Kundeninformation. Der CRA verlangt einen solchen Prozess. Wir richten ihn ein und binden ihn an Dein Ticketing und den Melde-Prozess an, damit eine Meldung nicht im Postfach liegen bleibt.

Die Treiber sind die Zahl der Produktlinien, ihre Klasse und der Reifegrad Deines Entwicklungs- und Release-Prozesses. Wir starten mit Betroffenheitsanalyse und Gap-Analyse; erst danach gibt es eine belastbare Schätzung statt einer Hausnummer. Auf den Beratungsanteil sind als BAFA-gelisteter Berater bis zu 50 % möglich (Bemessungsgrundlage 3.500 €, Zuschuss also max. 1.750 €; bis zu zwei geförderte Beratungen pro Jahr), den Antrag übernehmen wir.