Der EU Cyber Resilience Act: was er bedeutet und wer sich vorbereiten muss

Der CRA in einem Absatz

Der Cyber Resilience Act (CRA), auf Deutsch die Cyberresilienzverordnung, ist das erste Gesetz der Europäischen Union, das Sicherheitsanforderungen an fast jedes Produkt stellt, in dem Software steckt.¹ Er ist "horizontal", gilt also nicht nur für eine Branche wie Medizin oder Banken. Wenn das, was du verkaufst, Code ausführt und sich direkt oder indirekt mit einem Gerät oder einem Netz verbindet, fällt es sehr wahrscheinlich darunter.²

Vor dem CRA war Produktsicherheit in Europa ein Flickenteppich. Einzelne Branchen hatten eigene Regeln, aber eine smarte Türklingel, eine Buchhaltungssoftware oder ein Desktop Client ließ sich in der EU verkaufen, ohne irgendeine gemeinsame Sicherheitsgrundlage zu erfüllen. Der CRA ändert das. Er legt die Verantwortung auf die Unternehmen, die diese Produkte herstellen, einführen und verkaufen, nicht auf die Menschen, die sie kaufen.

Ich habe diesen Artikel im November 2026 überarbeitet, weil ein Teil des Gesetzes nicht mehr kommt. Er ist da. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.¹ Der Rest der Verordnung gilt ab dem 11. Dezember 2027.

Die Termine, und wo wir heute stehen

Der CRA wurde am 20. November 2024 im Amtsblatt veröffentlicht und trat 20 Tage später in Kraft, am 10. Dezember 2024.¹ Danach schaltet er sich in drei Stufen ein.

• 11. Juni 2026: Die Regeln für Konformitätsbewertungsstellen, also die unabhängigen Prüfer, die manche Produkte brauchen, gelten seitdem.¹
• 11. September 2026: Die Meldepflicht hat begonnen. Das Datum liegt hinter uns. Bist du ein Hersteller im Anwendungsbereich, gilt die Pflicht heute.¹
• 11. Dezember 2027: Alles Übrige gilt, darunter die Sicherheitsanforderungen selbst, die Dokumentation und die CE Kennzeichnung.¹

Ein Detail erwischt viele. Die Meldepflicht ist nicht auf neue Produkte beschränkt. Sie gilt für jedes Produkt im Anwendungsbereich, auch für solche, die vor Dezember 2027 in Verkehr gebracht wurden.³ Die Software, die du 2025 ausgeliefert hast, zählt mit.

Durchgerechnetes Beispiel: welche Termine einen Hamburger Thermostathersteller treffen

Ein Beispiel: Alsterwärme, ein erfundenes Unternehmen aus Hamburg, verkauft ein smartes Heizkörperthermostat, eine App zur Steuerung und eine Cloud API, mit der die App spricht. Das erste Modell kam 2025 in der EU auf den Markt.

1. Heute, am 8. November 2026, gilt die Meldepflicht bereits für dieses Modell von 2025, denn Artikel 69 Absatz 3 erstreckt die Meldepflicht auf Produkte, die vor Dezember 2027 in Verkehr gebracht wurden.³
2. Die vollen Sicherheitsanforderungen gelten für das Modell von 2025 noch nicht. Nach Artikel 69 Absatz 2 erreichen sie ältere Produkte nur, wenn diese ab dem 11. Dezember 2027 wesentlich geändert werden.³
3. Ein zweites Modell, geplant für das Frühjahr 2028, muss jede Anforderung erfüllen, bevor es in den Verkauf geht, weil es nach dem 11. Dezember 2027 in Verkehr gebracht wird.

Alsterwärme braucht also jetzt einen Meldeprozess und für alles, was ab Dezember 2027 startet, ein vollständiges Compliance Programm.

Was als Produkt mit digitalen Elementen zählt

Der Begriff der Verordnung lautet "Produkt mit digitalen Elementen": ein Software oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich Software oder Hardwarekomponenten, die getrennt in Verkehr gebracht werden.² Erfasst sind Produkte, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung mit einem Gerät oder Netz einschließt.²

Die "Datenfernverarbeitung" ist der Teil, den viele übersehen. Gemeint ist Datenverarbeitung auf Entfernung, deren Software vom Hersteller selbst oder unter seiner Verantwortung entwickelt wird und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte.² Die Erwägungsgründe nennen ein direktes Beispiel: Braucht eine App eine API oder Datenbank, die der Hersteller über seinen eigenen Dienst bereitstellt, fällt dieser Dienst als Datenfernverarbeitung in den Anwendungsbereich.⁴

Die Leitlinien der Kommission, veröffentlicht am 27. Juli 2026, ziehen die Grenze klar.⁵ Software, die heruntergeladen, installiert oder dem Nutzer geliefert wird und auf seiner Seite läuft, ist ein Produkt mit digitalen Elementen, und dazu gehören Browsererweiterungen und Desktop Apps, die mit Webtechnologien gebaut sind.⁶ Eine Webanwendung, die nur über den Browser genutzt wird, ist keines, es sei denn, sie unterstützt die Funktion eines Produkts mit digitalen Elementen.⁶ Eine Website, die einfach Informationen zeigt, ist ebenfalls kein Produkt.⁶

Manche Produkte sind ausgenommen, weil andere EU Gesetze sie schon abdecken, etwa Medizinprodukte, In vitro Diagnostika, Kraftfahrzeuge, zertifizierte Luftfahrtprodukte und Schiffsausrüstung, dazu Produkte, die ausschließlich für die nationale Sicherheit oder Verteidigung gebaut sind.⁷

Durchgerechnetes Beispiel: drei Unternehmen, drei Antworten

Ein Beispiel: Drei erfundene Unternehmen fragen, ob der CRA sie erreicht.

1. Belegwerk, eine Buchhaltungssoftware aus Leipzig, die nur im Browser läuft. Beim Kunden wird nichts installiert, und sie unterstützt kein physisches Produkt. Nach dem eigenen Beispiel der Leitlinien ist sie kein Produkt mit digitalen Elementen.⁶ Sie liegt außerhalb des CRA.
2. Belegwerk bringt dann einen Desktop Client zur Synchronisierung heraus, den die Kunden installieren. Dieser Client läuft auf dem Rechner des Kunden, ist also ein Produkt mit digitalen Elementen.⁶ Die Server API, die der Client braucht, ist Datenfernverarbeitung und kommt mit ihm in den Anwendungsbereich.²
3. Alsterwärme aus dem ersten Beispiel. Das Thermostat (Hardware mit eingebetteter Software), die App und die Cloud API, die das Thermostat steuert, fallen alle darunter, die API als Datenfernverarbeitung.⁴

Ein und dasselbe Unternehmen kann also Produkt für Produkt außerhalb und innerhalb des CRA liegen. Die Frage ist nie "sind wir eine Softwarefirma". Sie lautet "was genau liefern wir, und wo läuft es".

Reines SaaS, NIS2 und die Lücke dazwischen

Ein reines Web SaaS, bei dem der Nutzer nichts installiert, ist in der Regel kein Produkt mit digitalen Elementen.⁶ Die Erwägungsgründe verweisen Cloud Dienste, auch Software as a Service, stattdessen auf die NIS2 Richtlinie.⁴

Hier gibt es eine Feinheit, die die alte Fassung dieses Artikels ausgelassen hat. NIS2 gilt für Anbieter von Cloud Computing Diensten ab mittlerer Größe.⁴ Ein kleines SaaS, das nur im Browser läuft, kann deshalb außerhalb von beiden liegen. Das ist kein Freibrief für Nachlässigkeit, denn für die personenbezogenen Daten darin gilt weiterhin die Datenschutz Grundverordnung (DSGVO), aber die regulatorische Frage ist eine andere. NIS2 selbst behandle ich in der NIS2 Richtlinie erklärt.

Sobald ein SaaS etwas auf das Gerät des Nutzers liefert, ändert sich das Bild. Eine App, ein Desktop Client, eine Browsererweiterung oder ein Plugin ist ein Produkt mit digitalen Elementen, und das Backend, das es braucht, kommt als Datenfernverarbeitung mit.⁴⁶

Wer welche Pflicht trägt

Der CRA verteilt die Pflichten nach der Rolle in der Lieferkette.⁸

• Der Hersteller entwickelt oder fertigt das Produkt oder lässt es fertigen und vermarktet es unter eigenem Namen oder eigener Marke, gegen Bezahlung, zur Monetarisierung oder unentgeltlich. Er trägt die Hauptpflichten.⁸
• Der Einführer ist in der EU niedergelassen und bringt ein Produkt unter dem Namen oder der Marke von jemandem außerhalb der EU auf den EU Markt. Er muss prüfen, ob der Hersteller die Konformitätsbewertung durchgeführt und die Anforderungen erfüllt hat.⁸
• Der Händler stellt das Produkt ohne Änderung bereit, mit der gebotenen Sorgfalt, und prüft unter anderem, ob es die CE Kennzeichnung trägt.⁸

Was das für ein Unternehmen in Deutschland heißt

Der CRA ist eine Verordnung. Er gilt in Deutschland unmittelbar, ohne dass ein deutsches Gesetz ihn erst umsetzen müsste.¹ Ein Unternehmen in Hamburg oder Köln, das eine App, ein Gerät oder ein installierbares Plugin an Kunden in der EU verkauft, steht für diese Produkte unter denselben Regeln wie jedes andere in der EU, und das gilt auch für Hersteller außerhalb der EU, die hier verkaufen.⁹

Was der deutsche Gesetzgeber regelt, ist der Vollzug. Die Bundesregierung hat im Mai 2026 einen Gesetzentwurf zur Durchführung der Cyberresilienzverordnung vorgelegt, Drucksache 21/6134. Er soll die Rechtsgrundlage schaffen, damit das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Marktüberwachungsbehörde und als notifizierende Behörde unter der Verordnung tätig werden kann.¹⁰ Der Innenausschuss des Bundestags hat den Entwurf am 14. Oktober 2026 in geänderter Fassung gebilligt, die abschließende Beratung im Plenum stand für den folgenden Tag auf der Tagesordnung, und der Entwurf enthält auch die Vorschriften für das Bußgeldverfahren.¹¹ Wann die einzelnen Regeln in Kraft treten, prüfst du am besten im Bundesgesetzblatt. An den Pflichten aus der Verordnung selbst ändert das deutsche Gesetz nichts.

Durchgerechnetes Beispiel: ein Kölner Shop, der vernetzte Geräte verkauft

Ein Beispiel: Domstecker, ein erfundener Onlineshop aus Köln, verkauft smarte Zwischenstecker eines Herstellers aus einem anderen EU Land an Kunden in Deutschland und Österreich. Die Stecker sind Produkte mit digitalen Elementen. Domstecker hat sie nicht hergestellt, seine Pflichten sind also die der Lieferkette: Bevor ein Produkt in den Shop kommt, sollte Domstecker die CE Kennzeichnung und die Unterlagen sehen, die die Verordnung verlangt, und ein Produkt aus dem Verkauf nehmen, wenn es Grund zu der Annahme gibt, dass es die Anforderungen nicht erfüllt.⁸

Welche Rolle Domstecker genau hat, Einführer oder Händler, hängt davon ab, wo die Beteiligten niedergelassen sind und wie die Ware zum Kunden kommt. Die Begriffe hängen an der Niederlassung in der EU. Kauft Domstecker eines Tages direkt bei einem Hersteller außerhalb der EU ein und verkauft unter dessen Marke, kann aus dem Händler ein Einführer werden, und dafür gehört eine anwaltliche Einschätzung her. Ich würde das für einen Kunden nicht raten, und ich rate es auch hier nicht.

Open Source: wer drin ist, wer draußen

Open Source wird sorgfältig behandelt. Freie und quelloffene Software fällt nur dann unter die Verordnung, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird.¹² Software, die ihr Hersteller nicht monetarisiert, gilt nicht als Geschäftstätigkeit, und Spenden oder Beiträge von Unternehmen machen sie für sich allein nicht kommerziell.¹²

Die Verordnung schafft eine leichtere Rolle, den Verwalter quelloffener Software: eine juristische Person, etwa eine Stiftung, die quelloffene Produkte für den kommerziellen Einsatz systematisch und nachhaltig unterstützt.¹² Verwalter brauchen eine dokumentierte Cybersicherheitsstrategie und arbeiten mit den Behörden zusammen, Geldbußen gelten für sie nicht.¹²¹³

Für die meisten Unternehmen zählt die andere Seite. Baust du ein kommerzielles Produkt auf Open Source Komponenten, musst du beim Einbinden die gebotene Sorgfalt walten lassen, damit sie dein Produkt nicht gefährden, ausdrücklich auch bei Komponenten, die nicht kommerziell bereitgestellt wurden.¹⁴ Findest du eine Schwachstelle in einer davon, meldest du sie demjenigen, der sie wartet.¹⁴ Die Gems in deinem Gemfile sind Teil deines Produkts.

Was der CRA tatsächlich verlangt

Die grundlegenden Anforderungen stehen in Anhang I, in zwei Teilen.¹⁵

Teil I betrifft das Produkt selbst. Auf Grundlage einer dokumentierten Risikobewertung muss ein Produkt ohne bekannte ausnutzbare Schwachstellen auf den Markt kommen, mit sicherer Standardkonfiguration, mit einem Weg, Schwachstellen über Sicherheitsaktualisierungen zu beheben, mit Schutz vor unbefugtem Zugriff, mit verschlüsselten oder anderweitig geschützten Daten, nur mit den Daten, die es braucht, mit kleiner Angriffsfläche und mit einer Möglichkeit für die Nutzer, ihre Daten und Einstellungen zu löschen, neben weiteren Punkten, 13 insgesamt.¹⁵

Teil II regelt, wie du mit Schwachstellen umgehst, in acht Punkten.¹⁵ Du musst:

• Komponenten ermitteln und dokumentieren, auch mit einer Softwarestückliste (Software Bill of Materials, SBOM) "in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen"
• Schwachstellen unverzüglich beheben und Sicherheitsaktualisierungen, soweit technisch machbar, getrennt von Funktionsaktualisierungen bereitstellen
• die Sicherheit regelmäßig testen und überprüfen
• Informationen über behobene Schwachstellen veröffentlichen, sobald das Update draußen ist
• eine Strategie für die koordinierte Offenlegung von Schwachstellen haben und eine Kontaktadresse für Meldungen angeben
• Updates sicher verteilen, und Sicherheitsaktualisierungen kostenlos, sofern mit einem gewerblichen Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart ist

Außerdem musst du eine zentrale Anlaufstelle benennen, über die dich Nutzer schnell erreichen, auch um Schwachstellen zu melden.¹⁶

Der Unterstützungszeitraum ist ein Minimum, kein Maximum

Die alte Fassung dieses Artikels sagte, der Unterstützungszeitraum betrage höchstens fünf Jahre. Das war falsch, und ich habe es korrigiert. Der Unterstützungszeitraum muss widerspiegeln, wie lange das Produkt voraussichtlich genutzt wird, und er beträgt mindestens fünf Jahre, es sei denn, das Produkt ist voraussichtlich kürzer im Einsatz.¹⁷ Jede Sicherheitsaktualisierung muss dann mindestens zehn Jahre nach ihrer Bereitstellung verfügbar bleiben, oder für den Rest des Unterstützungszeitraums, wenn der länger ist.¹⁷

Durchgerechnetes Beispiel: der Unterstützungszeitraum für ein Thermostat

Ein Beispiel: Alsterwärme geht davon aus, dass ein Heizkörperthermostat etwa zehn Jahre an der Wand bleibt. Diese Erwartung ist die Annahme des Beispiels, gewählt, weil Heizungsregler seltener ersetzt werden als Handys.

1. Die gesetzliche Untergrenze liegt bei fünf Jahren.¹⁷
2. Die voraussichtliche Nutzungsdauer ist länger, etwa zehn Jahre, und der Unterstützungszeitraum muss sie widerspiegeln.¹⁷
3. Alsterwärme legt deshalb zehn Jahre ab dem Verkauf jedes Geräts fest und nennt den Nutzern das Enddatum, wie es die Informationen für den Nutzer in Anhang II verlangen.¹⁸
4. Ein Sicherheitsupdate aus dem achten Jahr muss dann mindestens bis zum 18. Jahr herunterladbar bleiben, denn zehn Jahre nach Bereitstellung sind länger als die zwei Jahre, die vom Unterstützungszeitraum noch übrig sind.¹⁷

Die Meldepflicht, die schon gilt

Seit dem 11. September 2026 muss ein Hersteller, der von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, sie melden, und dasselbe gilt für einen schwerwiegenden Sicherheitsvorfall, der die Sicherheit des Produkts beeinträchtigt.¹⁹ "Aktiv ausgenutzt" heißt, es gibt verlässliche Nachweise, dass jemand die Schwachstelle ohne Zustimmung des Systemeigners ausgenutzt hat.²

Im alten Artikel stand, du meldest "an die ENISA". Genauer: Du meldest über die einheitliche Meldeplattform der EU an das nationale Computer Security Incident Response Team (CSIRT), das als Koordinator benannt ist, und die Meldung ist gleichzeitig der ENISA zugänglich, der Cybersicherheitsagentur der EU.¹⁹ Laut Kommission ist die Plattform seit dem 11. September 2026 in Betrieb.²⁰

Für eine aktiv ausgenutzte Schwachstelle gibt es drei Schritte.¹⁹

Das Diagramm liest sich von oben nach unten. Die ersten drei Fristen laufen ab dem Moment, in dem du davon erfährst, nicht ab dem Ende deiner Untersuchung. Der Abschlussbericht läuft ab dem Moment, in dem eine Korrektur existiert. Bei einem schwerwiegenden Sicherheitsvorfall ist der Ablauf derselbe, nur ist der Abschlussbericht innerhalb eines Monats nach der Meldung aus der 72 Stunden Frist fällig.¹⁹ Die ganze Zeit über informierst du außerdem die betroffenen Nutzer.¹⁹

Kleinst und Kleinunternehmen behalten die Pflicht. Der Unterschied: Die Geldbußen der Verordnung gelten für sie nicht, wenn sie die 24 Stunden Frist für die Frühwarnung verpassen.¹³ Jeder andere Teil der Meldepflicht gilt weiter.

Durchgerechnetes Beispiel: die Uhr bei Alsterwärme

Ein Beispiel: Am Dienstag, dem 10. November 2026, um 9:40 Uhr bestätigt die Rufbereitschaft von Alsterwärme, dass Angreifer eine Lücke in der Cloud API des Thermostats nutzen, um in fremden Wohnungen die Heizung einzuschalten.

1. Kenntnis: Dienstag, 10. November, 9:40 Uhr.
2. Frühwarnung fällig bis Mittwoch, 11. November, 9:40 Uhr (24 Stunden später).
3. Schwachstellenmeldung fällig bis Freitag, 13. November, 9:40 Uhr (72 Stunden nach Kenntnis).
4. Die Korrektur geht am Montag, 16. November, raus.
5. Abschlussbericht fällig bis Montag, 30. November (14 Tage, nachdem die Korrektur bereitsteht).
6. Alsterwärme schreibt den betroffenen Kunden, was sie tun sollen, sobald feststeht, was sie tun können.

Nichts davon funktioniert, wenn die erste Frage um 9:40 Uhr lautet "wem sagen wir das". Der Prozess muss existieren, bevor der Vorfall es tut.

Produktklassen und Konformitätsbewertung

Die meisten Produkte brauchen nur eine Selbstbewertung durch den Hersteller, das bestätigt die Kommission.²¹ Die alte Fassung dieses Artikels nannte dafür einen Anteil von rund 90 %. Diese Zahl habe ich weder in der Verordnung noch auf den Seiten der Kommission gefunden, also habe ich sie gestrichen.

Manche Produkte trifft mehr. Anhang III listet "wichtige" Produkte in zwei Klassen, Anhang IV "kritische" Produkte, die technischen Beschreibungen stehen in der Durchführungsverordnung (EU) 2025/2392.²²²³

• Klasse I umfasst Betriebssysteme, Browser, Passwortmanager, VPNs, Router und Modems sowie Smart Home Sicherheitsprodukte wie Türschlösser und Kameras.²²
• Klasse II umfasst Hypervisoren und Container Laufzeitumgebungen, Firewalls und Systeme zur Angriffserkennung sowie manipulationssichere Mikroprozessoren.²²
• Zu den kritischen Produkten gehören Hardware Sicherheitsboxen, Smart Meter Gateways und Chipkarten.²²

Der alte Artikel führte auch industrielle Automatisierungssysteme als wichtig oder kritisch. In den endgültigen Anhängen stehen sie nicht, also ist auch das raus.

Produkte der Klasse I dürfen nur dann selbst bewertet werden, wenn der Hersteller harmonisierte Normen oder gleichwertige Spezifikationen angewendet hat. Klasse II und kritische Produkte brauchen eine notifizierte Stelle oder einen Zertifizierungsweg.²⁴ Besteht ein Produkt, trägt es die CE Kennzeichnung, angebracht vor dem Inverkehrbringen, und der Hersteller bewahrt eine technische Dokumentation samt SBOM auf, die eine Marktüberwachungsbehörde anfordern kann.²⁵

Die Sanktionen

Die Geldbußen legt jeder Mitgliedstaat fest, innerhalb der Obergrenzen der Verordnung.²⁶ Für Verstöße gegen die grundlegenden Anforderungen oder die Herstellerpflichten aus den Artikeln 13 und 14 liegt die Obergrenze bei:

$$F_{\max} = \max\left(15.000.000,\ 0{,}025 \times T\right)$$

Dabei ist $F_{\max}$ die höchstmögliche Geldbuße in Euro, $15.000.000$ die feste Obergrenze von 15 Millionen €, $0{,}025$ sind 2,5 % als Dezimalzahl, $T$ ist der gesamte weltweite Jahresumsatz des Unternehmens im vorangegangenen Geschäftsjahr in Euro, und $\max$ bedeutet "je nachdem, welcher Betrag höher ist". Grundlagen: Prozent

Für andere Verstöße gelten niedrigere Stufen: bis zu 10 Millionen € oder 2 %, und bis zu 5 Millionen € oder 1 % für falsche, unvollständige oder irreführende Angaben gegenüber Behörden.²⁶ Die Behörden müssen die Größe des Unternehmens berücksichtigen, insbesondere bei Kleinst, kleinen und mittleren Unternehmen.²⁶ Marktüberwachungsbehörden können außerdem verlangen, dass ein Produkt, das die Anforderungen nicht erfüllt, vom Markt genommen oder zurückgerufen wird.²⁷

Durchgerechnetes Beispiel: die Obergrenze bei zwei Unternehmensgrößen

Ein Beispiel: Die Verordnung nennt ihre Obergrenzen in Euro, also rechnet das Beispiel den Umsatz ebenfalls in Euro.

1. Ein mittelgroßer Hersteller mit 40.000.000 € weltweitem Umsatz. 2,5 % davon sind $0{,}025 \times 40.000.000 = 1.000.000$, also 1 Million €. Der höhere Betrag von 15 Millionen € und 1 Million € sind 15 Millionen €.
2. Ein großer Konzern mit 800.000.000 € Umsatz: $0{,}025 \times 800.000.000 = 20.000.000$. Der höhere Betrag von 15 Millionen € und 20 Millionen € sind 20 Millionen €.

Die Obergrenze steigt erst mit dem Umsatz, wenn 2,5 % des Umsatzes über 15 Millionen € liegen, und das passiert bei 600 Millionen €, denn $15.000.000 \div 0{,}025 = 600.000.000$.

Die waagerechte Achse zeigt den weltweiten Jahresumsatz des Unternehmens, die senkrechte die höchstmögliche Geldbuße der obersten Stufe, beides in Euro. Die Linie bleibt bei 15 Millionen €, bis der Umsatz 600 Millionen € erreicht, dann steigt sie. Für fast jedes kleine oder mittlere Unternehmen sind 15 Millionen € die Obergrenze, die zählt. Das ist ein Höchstbetrag, kein Tarif, aber es ist eine Zahl, an der Unternehmen enden.

Wo Unternehmen stolpern

Den Anwendungsbereich unterschätzen. Es geht nicht nur um Gadgets. Eine installierbare App, ein Plugin, das du an andere Unternehmen verkaufst, oder eine Browsererweiterung kann darunter fallen.⁶

Die Lieferkette ignorieren. Das ungepflegte Gem oder das vergessene npm Paket in deinem Abhängigkeitsbaum ist über die Sorgfaltspflicht jetzt deine Verantwortung.¹⁴

Kein Prozess für Schwachstellen. Kein Sicherheitskontakt, kein Weg, Meldungen zu empfangen, keine Einordnung. Der CRA macht all das zur Pflicht.¹⁵¹⁶

Keine SBOM. Wenn du nicht weißt, was in deiner Software steckt, kannst du auf das nächste Log4Shell nicht antworten, die Lücke von 2021 in der weit verbreiteten Java Bibliothek Log4j, wenn sie in einer Abhängigkeit auftaucht, von der du nichts wusstest.²⁸

"Wir sind zu klein." Die Größe ändert die Geldbußen bei einer verspäteten Frühwarnung und wie Behörden Sanktionen gewichten.¹³²⁶ Die Pflichten schaltet sie nicht ab.

CRA und DSGVO verwechseln. Das sind zwei verschiedene Gesetze. Der CRA übernimmt zwar die Datenminimierung als eine seiner Produktanforderungen, aber wer das eine erfüllt, hat das andere nie bewiesen.¹⁵

Die Sicherheitsarbeit hinter der Compliance

CRA Compliance ist nicht nur Papier. Sie ruht auf echter Sicherheitspraxis, und auf einem Rails Stack ist das meiste davon mit vorhandenen Werkzeugen gut abgedeckt.

Bedrohungsmodell und Risikobewertung. Bevor du auslieferst, bewerte die Risiken: die Angriffswege, die Daten, die das Produkt verarbeitet, was passiert, wenn es kompromittiert wird. Artikel 13 verlangt, dass diese Bewertung dokumentiert und aktuell gehalten wird.²⁹

Statische Analyse und Prüfung der Abhängigkeiten. Für Rails durchsucht Brakeman den Anwendungscode nach Sicherheitsproblemen, und bundler-audit prüft dein Gemfile.lock gegen bekannte verwundbare Gem Versionen.³⁰³¹ Dependabot von GitHub kann Pull Requests anlegen, wenn eine Abhängigkeit eine bekannte Schwachstelle hat.³²

Dynamische Tests. OWASP ZAP testet eine laufende Anwendung so, wie ein Angreifer es tun würde, und die OWASP Top 10 sind eine vernünftige Liste dessen, wonach du zuerst suchst.³³³⁴ Ich nutze Kali Linux regelmäßig, um die Sicherheit der Systeme zu prüfen, die ich baue und betreue, vom Netzwerkscan mit Nmap bis zum Test von Webanwendungen mit Burp Suite.³⁵

Eine SBOM aus der Lock Datei. CycloneDX ist ein weit verbreiteter SBOM Standard, und das Gem cyclonedx-ruby erzeugt aus einem Ruby Projekt eine CycloneDX SBOM.³⁶³⁷

Durchgerechnetes Beispiel: SBOM und Sicherheitskontakt für eine Rails App

Ein Beispiel: Die Thermostat API von Alsterwärme ist eine Rails App. Zwei kleine Arbeiten decken zwei Anforderungen aus Teil II ab.

Erstens eine SBOM bei jedem Deploy, als Schritt in der CI:

gem install cyclonedx-ruby
cyclonedx-ruby -p . -f json -o sbom/alsterwaerme-api.json
bundle-audit check --update

Der erste Befehl installiert den Generator, der zweite schreibt eine SBOM der Gems der App als JSON nach sbom/, und der dritte lässt den Build scheitern, wenn ein Gem mit bekannter Schwachstelle in der Lock Datei steht.³⁷³¹ Die SBOM wird mit jedem Release archiviert, so kann Alsterwärme einer Behörde für jede Version die genaue Liste geben.

Zweitens ein veröffentlichter Kontakt für Schwachstellenmeldungen. Der Standard security.txt legt ihn an eine feste Adresse der Website:³⁸

# https://alsterwaerme.example/.well-known/security.txt
Contact: mailto:security@alsterwaerme.example
Expires: 2027-10-31T00:00:00.000Z
Policy: https://alsterwaerme.example/security/disclosure-policy
Preferred-Languages: de, en

Contact und Expires sind die beiden Pflichtfelder, und Policy verweist auf die Strategie zur koordinierten Offenlegung, die der CRA verlangt.³⁸¹⁵ Die zentrale Anlaufstelle muss trotzdem auch in den Informationen für den Nutzer stehen und darf sich nicht auf automatisierte Werkzeuge beschränken.¹⁶¹⁸

Was du jetzt tun solltest

Erstens, kläre deinen Anwendungsbereich. Liste alles auf, was du lieferst, und frag bei jedem Teil, wo es läuft und was es zum Funktionieren braucht. Nimm das Beispiel mit den drei Unternehmen als Vorlage.

Zweitens, richte die Meldungen heute ein. Das ist die Pflicht, die schon gilt. Leg fest, wer Bereitschaft hat, wer entscheidet, ob eine Schwachstelle aktiv ausgenutzt wird, und wer über die einheitliche Meldeplattform meldet.¹⁹²⁰ Spiel es einmal mit einem erfundenen Vorfall durch.

Drittens, erzeuge für jedes Produkt eine SBOM. Mit transitiven Abhängigkeiten, und markiere alles, was nicht mehr gepflegt wird.

Viertens, schreib den Prozess für Schwachstellen auf. Eine Offenlegungsstrategie, ein Sicherheitskontakt, eine Routine zur Einordnung und ein Kanal für Updates.¹⁵

Fünftens, leg den Unterstützungszeitraum fest. Fünf Jahre sind die Untergrenze, die voraussichtliche Nutzungsdauer ist die eigentliche Antwort.¹⁷

Sechstens, bau Sicherheit in die Pipeline. Statische Analyse und Prüfung der Abhängigkeiten bei jedem Commit, damit ein verwundbares Gem den Build scheitern lässt, bevor es ausgeliefert wird.

Siebtens, fang mit der technischen Dokumentation an. Risikobewertung, Architektur, SBOM, Updatestrategie. Du brauchst sie für Dezember 2027, und nebenbei geschrieben ist sie viel leichter.

Wo ich ins Spiel komme

Ich baue Rails SaaS Produkte und Solidus eCommerce Shops, und Sicherheit ist Teil des Baus, kein späterer Anbau. Bei meinen SaaS Projekten durchläuft jedes Projekt auf Staging einen Durchgang mit Kali Linux, bevor es ins Internet geht, Endpunkte werden mit Burp Suite und OWASP ZAP getestet, Nmap und SQLmap prüfen, was erreichbar ist und ob sich die Datenbank per Injection angreifen lässt, und Brakeman und bundler-audit laufen bei jedem Commit in der CI, sodass ein verwundbares Gem den Build scheitern lässt.

Für die Arbeit am CRA richte ich die SBOM Erzeugung mit CycloneDX ein, sodass jedes Deployment eine aktuelle SBOM liefert. Alle meine Produktivsysteme laufen auf Linux, wie ich in meinem Text über Europas digitale Unabhängigkeit beschrieben habe, und ich härte sie nach den CIS Benchmarks: Firewallkonfiguration, SSH Härtung, regelmäßiges Patchen, kleine Angriffsflächen und laufendes Monitoring.³⁹ Für Rails und Solidus Deployments heißt das Nginx oder Caddy mit sauberer TLS Konfiguration, Docker Container mit minimalen Basisimages und automatische Sicherheitsupdates.

Verkauft dein Solidus Shop vernetzte Produkte in die EU, gelten die Lieferkettenpflichten oben auch für den Shop, und die Datenseite muss weiterhin die DSGVO erfüllen, dazu mehr in DSGVO konforme KI Features in deinem SaaS bauen. Wo die Frage rechtlich ist, etwa deine genaue Rolle als Einführer oder Händler, gehört die Antwort zu einer Anwältin oder einem Anwalt. Ich bringe die Technik mit, die diese Antwort wahr macht.

Footnotes

1. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847 (Cyberresilienzverordnung), Artikel 71 und Fundstelle ABl. L, 2024/2847, 20.11.2024, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

2. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 2 Absatz 1 und Artikel 3 Nummern 1, 2 und 42, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

3. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 69 Absätze 2 und 3, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

4. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Erwägungsgründe 11 und 12, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

5. Europäische Kommission, Commission publishes new guidance to support timely Cyber Resilience Act implementation, 2026, https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

6. Europäische Kommission, Commission guidance on the application of Regulation (EU) 2024/2847, Anhang zu C(2026) 5252, Abschnitt 2, Randnummern 18 bis 21 und Beispiele 3 bis 6, 2026, https://ec.europa.eu/newsroom/dae/redirection/document/131456

7. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 2 Absätze 2 bis 7, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

8. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 3 Nummern 13, 16 und 17 sowie Artikel 19 und 20, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

9. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 14 Absatz 7 und Artikel 18, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

10. Deutscher Bundestag, Gesetzentwurf zur Umsetzung der Cyberresilienz Verordnung, heute im bundestag 431/2026, 27. Mai 2026, https://www.bundestag.de/presse/hib/kurzmeldungen-1182464

11. Deutscher Bundestag, heute im bundestag 822/2026, Meldung aus dem Innenausschuss zum Gesetzentwurf 21/6134 (Cyberresilienz Verordnung), 14. Oktober 2026, https://www.bundestag.de/presse/hib/kurzmeldungen-1224738

12. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Erwägungsgründe 18 und 19, Artikel 3 Nummer 14 und Artikel 24, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

13. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 64 Absatz 10, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

14. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 13 Absätze 5 und 6, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

15. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Anhang I, Teile I und II, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

16. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 13 Absatz 17, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

17. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 13 Absätze 8 und 9, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

18. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Anhang II, Nummern 2 und 7, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

19. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 14 Absätze 1 bis 8, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

20. Europäische Kommission, Cyber Resilience Act reporting obligations, Shaping Europe's digital future, 2026, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

21. Europäische Kommission, Cyber Resilience Act conformity assessment, Shaping Europe's digital future, 2026, https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment

22. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 7 und 8, Anhänge III und IV, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

23. Europäische Kommission, Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 zur technischen Beschreibung der Kategorien wichtiger und kritischer Produkte mit digitalen Elementen, EUR Lex, 2025, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32025R2392

24. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 32, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

25. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 30 und Anhang VII, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

26. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 64 Absätze 1 bis 5, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

27. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 54 Absatz 1, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

28. NIST National Vulnerability Database, CVE-2021-44228 (Apache Log4j2), 2021, https://nvd.nist.gov/vuln/detail/CVE-2021-44228

29. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847, Artikel 13 Absätze 2 und 3, EUR Lex, 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R2847

30. Brakeman, Brakeman: static analysis security scanner for Ruby on Rails, 2026, https://brakemanscanner.org/

31. RubyGems.org, bundler-audit, 2026, https://rubygems.org/gems/bundler-audit

32. GitHub, Dependabot documentation, GitHub Docs, 2026, https://docs.github.com/en/code-security/dependabot

33. ZAP, OWASP ZAP (Zed Attack Proxy), 2026, https://www.zaproxy.org/

34. OWASP Foundation, OWASP Top Ten, 2026, https://owasp.org/www-project-top-ten/

35. OffSec, Kali Linux, 2026, https://www.kali.org/

36. OWASP Foundation, CycloneDX specification overview, 2026, https://cyclonedx.org/specification/overview/

37. RubyGems.org, cyclonedx-ruby, 2026, https://rubygems.org/gems/cyclonedx-ruby

38. E. Foudil und Y. Shafranovich, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, RFC Editor, 2022, https://www.rfc-editor.org/rfc/rfc9116

39. Center for Internet Security, CIS Benchmarks, 2026, https://www.cisecurity.org/cis-benchmarks