Der EU Cyber Resilience Act kommt: Was er bedeutet, wer sich vorbereiten muss und wie ich helfen kann
Falls du bisher bei EU-Regulierungen gedacht hast "das betrifft nur die Großen," wird es Zeit aufzuwachen. Der Cyber Resilience Act, kurz CRA, ist am 10. Dezember 2024 in Kraft getreten, und er wird die Spielregeln für alle ändern, die Produkte mit digitalen Elementen in der Europäischen Union bauen, verkaufen, importieren oder vertreiben. Das schließt Software ein. Das schließt die herunterladbaren Komponenten deiner SaaS-Plattform ein. Das schließt die smarten Geräte ein, die dein Onlineshop verkauft. Das schließt die Plugins und Erweiterungen ein, die du vertreibst. Und die Strafen? Bis zu 15 Millionen Euro oder 2,5 % deines weltweiten Jahresumsatzes, je nachdem was höher ist. Das ist DSGVO-Niveau. Das ist kein Vorschlag. Das ist eine gesetzliche Pflicht. Aber hier ist die Sache: Der CRA ist kein unmöglicher bürokratischer Albtraum. Wenn du verstehst, was er tatsächlich verlangt und jetzt mit der Vorbereitung anfängst, ist Compliance absolut machbar. Und für Unternehmen, die dem Ganzen voraus sind, ist es sogar ein Wettbewerbsvorteil. Lass mich genau aufschlüsseln, was diese Verordnung tut, wen sie betrifft und was du tun musst.
Was ist der Cyber Resilience Act und warum sollte dich das interessieren?
Der Cyber Resilience Act (CRA) ist die erste horizontale Verordnung der Europäischen Union, die verpflichtende Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt. "Horizontal" heißt: Er gilt branchenübergreifend, nicht nur für bestimmte Sektoren wie Gesundheitswesen oder Finanzen. Wenn dein Produkt sich direkt oder indirekt mit einem Gerät oder Netzwerk verbindet, fällt es fast sicher in den Geltungsbereich.
Vor dem CRA war die Produktcybersicherheit in Europa ein Flickenteppich. Manche Branchen hatten eigene Regeln, aber die meisten Produkte mit digitalen Elementen hatten null verpflichtende Sicherheitsanforderungen. Eine smarte Türklingel, eine Buchhaltungssoftware, der herunterladbare Client einer Webanwendung: nichts davon musste irgendeinem Sicherheitsstandard genügen, bevor es in der EU verkauft werden durfte.
Der CRA ändert das komplett. Er führt 21 verpflichtende Cybersicherheitsanforderungen ein, die den gesamten Produktlebenszyklus abdecken, vom Design bis zum Ende der Lebensdauer. Und er legt die Verantwortung klar auf die Schultern von Herstellern, Importeuren und Distributoren, nicht auf die Verbraucher.
Die Verordnung wurde im Oktober 2024 verabschiedet und ist am 10. Dezember 2024 in Kraft getreten. Sie wird über drei Jahre stufenweise eingeführt, wobei die vollständigen Anforderungen ab 11. Dezember 2027 gelten.
Der Zeitplan: Wann greift was?
Hier wird es konkret. Der CRA nutzt einen stufenweisen Ansatz, und manche Fristen sind näher als du denkst.
10. Dezember 2024 ist der CRA in Kraft getreten. Die Uhr tickt.
11. Juni 2026 beginnen die Konformitätsbewertungsstellen unter CRA-Regeln zu arbeiten. Das ist relevant, wenn dein Produkt in die Kategorien "wichtig" oder "kritisch" fällt, die eine Drittbewertung brauchen.
11. September 2026 ist die erste große operative Frist. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb von 24 Stunden an ENISA (die EU-Agentur für Cybersicherheit) melden. Während ich das hier schreibe, sind das weniger als sieben Monate. Wenn du keinen Prozess zur Schwachstellenmeldung hast, bist du bereits im Rückstand.
11. Dezember 2027 ist der Tag der vollständigen Durchsetzung. Jedes Produkt mit digitalen Elementen, das in der EU verkauft wird, muss bis zu diesem Datum alle CRA-Anforderungen erfüllen. Nicht konforme Produkte dürfen nicht mehr auf den Markt gebracht werden.
Was verlangt der CRA konkret?
Lass mich die Kernanforderungen in verständlicher Sprache aufschlüsseln, denn der Gesetzestext ist dicht genug, um jeden einzuschläfern.
Secure by Design und by Default. Deine Produkte müssen von Anfang an mit Cybersicherheit im Blick entworfen werden. Das bedeutet minimale Angriffsflächen, verschlüsselte oder geschützte Daten, kein unberechtigter Zugriff und sichere Standardkonfigurationen. Dein Produkt sollte von Haus aus sicher funktionieren, ohne dass der Nutzer ein Sicherheitsexperte sein muss.
Software Bill of Materials (SBOM). Das ist ein großes Thema. Du musst eine maschinenlesbare SBOM erstellen und pflegen, die mindestens die Abhängigkeiten auf oberster Ebene deines Produkts dokumentiert. Stell dir das wie eine Zutatenliste für deine Software vor. Wenn du Ruby on Rails mit 200 Gems verwendest oder eine Solidus-E-Commerce-Plattform mit einem Dutzend Erweiterungen betreibst, musst du dokumentieren, was drinsteckt. Die SBOM muss nicht öffentlich sein, aber du musst sie auf Anfrage den Marktüberwachungsbehörden zur Verfügung stellen.
Schwachstellenmanagement. Du brauchst einen dokumentierten Prozess für den Umgang mit Schwachstellen über den gesamten Produktlebenszyklus. Das umfasst das Identifizieren, Dokumentieren und Beheben von Schwachstellen. Du musst Nutzern eine Möglichkeit bieten, Schwachstellen zu melden. Du musst Sicherheitsupdates zeitnah und kostenlos bereitstellen. Und das alles für eine maximale Supportdauer von fünf Jahren (oder die erwartete Produktlebensdauer, je nachdem was kürzer ist).
Meldepflichten. Ab September 2026 musst du ENISA über jede aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Bekanntwerden informieren, gefolgt von einem detaillierteren Bericht innerhalb von 72 Stunden und einem Abschlussbericht innerhalb von 14 Tagen. Wenn du ein kleines oder Kleinstunternehmen bist, bekommst du etwas mehr Flexibilität bei der 24-Stunden-Frist, aber die Pflicht besteht trotzdem.
Konformitätsbewertung. Rund 90 % der Produkte fallen in die "Standard"-Kategorie und können die Selbstbewertung nutzen. Aber Produkte, die als "wichtig" (Klasse I oder II) oder "kritisch" eingestuft werden, brauchen eine strengere Bewertung, möglicherweise einschließlich Zertifizierung durch Dritte. Anhang III und IV des CRA listen diese Kategorien auf, darunter Betriebssysteme, Firewalls, Router, Smart Meter und industrielle Automatisierungssysteme.
CE-Kennzeichnung. Produkte, die alle CRA-Anforderungen erfüllen, erhalten die CE-Kennzeichnung, die für das Inverkehrbringen auf dem EU-Markt erforderlich ist.
Technische Dokumentation. Du brauchst umfassende Dokumentation, die zeigt, wie dein Produkt die CRA-Anforderungen erfüllt. Dazu gehören Risikobewertung, SBOM, Schwachstellenbehandlungsprozess und Konformitätsnachweise.
Wen betrifft das?
Die kurze Antwort: fast jeden in der digitalen Produktlieferkette.
Hersteller tragen die Hauptverantwortung. Wenn du ein Produkt mit digitalen Elementen entwirfst, baust und auf den EU-Markt bringst, bist du Hersteller im Sinne des CRA. Das schließt Software-Publisher ein. Wenn du eine Ruby-on-Rails-Anwendung baust, die an Nutzer verteilt wird (kein reines SaaS, aber alles mit einer herunterladbaren Komponente), bist du im Geltungsbereich.
Importeure müssen überprüfen, ob der Hersteller die Anforderungen erfüllt hat. Wenn du smarte Geräte importierst, um sie in deinem Solidus-Onlineshop zu verkaufen, musst du sicherstellen, dass diese Produkte die CRA-Anforderungen erfüllen, bevor du sie listest.
Distributoren müssen prüfen, ob Produkte die CE-Kennzeichnung tragen und Hersteller sowie Importeure ihre Pflichten erfüllt haben. Wenn du Software oder vernetzte Produkte weiterverkaufst, ist das deine Pflicht.
Open-Source-Software wird besonders behandelt. Wenn du ohne kommerzielle Absicht zu Open Source beiträgst, unterliegst du nicht direkt den CRA-Pflichten. Aber, und das ist entscheidend, wenn du Open-Source-Komponenten in ein kommerzielles Produkt integrierst, bist du dafür verantwortlich, dass diese Komponenten konform sind. Der CRA führt auch das Konzept der "Open-Source-Stewards" für Organisationen ein, die systematisch kommerzielle Open-Source-Projekte unterstützen.
Die wichtige Ausnahme: Reines SaaS
Hier gibt es eine Nuance, über die viele stolpern. Reine Software-as-a-Service (SaaS) Produkte, bei denen keine herunterladbare Software an Nutzer verteilt wird, fallen generell nicht unter den CRA. Sie fallen stattdessen unter die NIS2-Richtlinie.
Aber hier ist der Haken: Wenn dein SaaS-Produkt irgendeine herunterladbare Komponente hat, einen Desktop-Client, eine mobile App, eine Browser-Erweiterung, ein Plugin, dann ist diese Komponente ein Produkt mit digitalen Elementen und fällt unter den CRA. Und wenn deine SaaS-Plattform "Fernverarbeitung" bereitstellt, die für die Funktion eines physischen Produkts essentiell ist (wie ein Smart-Home-Hub, der auf deinen Cloud-Service angewiesen ist), fällt deine Fernverarbeitungslösung ebenfalls in den Geltungsbereich.
Also: Wenn du ein Custom-SaaS auf Rails baust, das eine mobile App oder einen Desktop-Sync-Client beinhaltet, brauchst du CRA-Compliance für diese verteilten Komponenten. Die Web-App selbst fällt möglicherweise unter NIS2, aber alles, was du an den Nutzer auslieferst, fällt unter den CRA.
Wo sind die Stolperfallen?
Lass mich ehrlich sein, wo Unternehmen wahrscheinlich ins Straucheln geraten werden.
Unterschätzung des Geltungsbereichs. Der CRA ist breiter als die meisten denken. Er gilt nicht nur für IoT-Geräte und smarte Gadgets. Er umfasst jede Software, die sich mit einem Netzwerk verbindet. Wenn du eine herunterladbare Anwendung, Erweiterung oder ein Plugin in der EU verkaufst, bist du wahrscheinlich im Geltungsbereich.
Die Lieferkette ignorieren. Wenn dein Produkt auf Drittanbieter-Komponenten basiert (und seien wir ehrlich, das tut praktisch jede moderne Anwendung), bist du für die Sicherheit dieser Komponenten verantwortlich. Das fragwürdige npm-Paket oder das nicht mehr gepflegte Ruby-Gem in deinem Abhängigkeitsbaum? Jetzt dein Problem.
Kein Schwachstellen-Prozess. Viele kleinere Softwareunternehmen haben keinen formalen Schwachstellenbehandlungsprozess. Keinen Sicherheitskontakt, keine Möglichkeit, Meldungen entgegenzunehmen, keinen Prozess für Priorisierung und Behebung. Der CRA macht das verpflichtend.
Fehlende SBOMs. Die meisten Unternehmen haben noch nie eine SBOM generiert. Wenn du nicht genau weißt, was in deiner Software steckt, kannst du keine Compliance nachweisen und nicht schnell reagieren, wenn eine Schwachstelle wie Log4Shell eine Abhängigkeit trifft, von der du nicht mal wusstest, dass du sie nutzt.
Denken "wir sind zu klein." Der CRA gilt unabhängig von der Unternehmensgröße. Kleinstunternehmen bekommen etwas Flexibilität bei Meldefristen, aber die Kernpflichten gelten für alle.
CRA mit DSGVO verwechseln. Es sind unterschiedliche Verordnungen mit unterschiedlichen Anforderungen. CRA-Compliance bedeutet nicht automatisch DSGVO-Compliance und umgekehrt. Du musst möglicherweise beide erfüllen.
Der Cybersecurity-Aspekt: Welche Schritte musst du unternehmen?
CRA-Compliance ist nicht nur Papierkram. Es erfordert echte Sicherheitspraktiken. Hier ist, wie das in der Praxis aussieht.
Bedrohungsmodellierung und Risikobewertung. Bevor du irgendetwas auslieferst, musst du die Cybersicherheitsrisiken bewerten. Was sind die Angriffsvektoren? Welche Daten verarbeitet dein Produkt? Was passiert bei einer Kompromittierung? Das muss dokumentiert werden.
Sichere Entwicklungspraktiken. Code Reviews, statische Analyse, Dependency Scanning, Secrets Management, sichere CI/CD-Pipelines. Wenn du das noch nicht machst, fang jetzt an. Tools wie Brakeman für Rails, Bundler Audit für Gem-Schwachstellen und OWASP ZAP für dynamisches Testing sollten Teil deines Entwicklungs-Workflows sein.
Penetrationstests. Regelmäßige Pentests sind essentiell. Mit Tools wie Kali Linux kannst du reale Angriffe gegen deine Anwendungen simulieren. Ich nutze Kali regelmäßig, um die Sicherheitslage von Systemen zu testen, die ich baue und verwalte, von Netzwerk-Scanning mit Nmap bis zu Web-Application-Testing mit Burp Suite.
Dependency Management. Fixiere deine Abhängigkeiten, prüfe sie regelmäßig und hab einen Prozess für Updates, wenn Schwachstellen veröffentlicht werden. Für Ruby-on-Rails-Projekte automatisieren Tools wie bundler-audit und Dienste wie GitHubs Dependabot einen Großteil davon.
Automatisierte SBOM-Generierung. Tools wie CycloneDX und Syft können SBOMs automatisch aus deinen Projektdateien generieren. Für Rails-Projekte kann das CycloneDX-Ruby-Gem eine SBOM direkt aus deinem Gemfile.lock erzeugen.
Kontinuierliches Monitoring. Sicherheit ist keine einmalige Sache. Du brauchst laufendes Monitoring, Log-Analyse und Intrusion Detection. Richte automatisierte Alerts für auffälliges Verhalten in deinen Produktionssystemen ein.
Incident Response Plan. Wenn (nicht falls) etwas passiert, brauchst du einen dokumentierten Plan. Wer wird benachrichtigt? Wie bewertest du die Auswirkungen? Wie meldest du an ENISA innerhalb von 24 Stunden? Wie kommunizierst du mit betroffenen Nutzern? Schreib diesen Plan jetzt, bevor du ihn brauchst.
Wie ich helfen kann: Growth Hacking, SaaS, Solidus und sichere Systeme
Hier wird mein Hintergrund besonders relevant. Ich bin nicht nur ein Growth Hacker, der Marketingkampagnen optimiert. Ich baue und sichere die Systeme, auf denen diese Kampagnen laufen. So sieht das in der Praxis aus.
Sichere SaaS-Entwicklung auf Ruby on Rails. Ich baue Custom-SaaS-Plattformen auf Rails mit Sicherheit von Tag eins. Das bedeutet verschlüsselte Daten im Ruhezustand und bei der Übertragung, sichere Authentifizierung mit Multi-Faktor-Unterstützung, rollenbasierte Zugriffskontrollen, Input-Validierung, Schutz gegen die OWASP Top 10 und automatisierte Sicherheitsscans in der CI/CD-Pipeline. Rails hat exzellente eingebaute Schutzmechanismen gegen gängige Schwachstellen wie CSRF, XSS und SQL-Injection, aber sie müssen korrekt konfiguriert und gepflegt werden.
Solidus E-Commerce mit CRA im Blick. Wenn du einen Solidus-Shop betreibst, der vernetzte Produkte verkauft oder Software vertreibt, muss CRA-Compliance Teil deiner Plattformstrategie sein. Ich helfe Solidus-Händlern, ihre Pflichten als Distributoren und Importeure zu verstehen, stelle sicher, dass ihre Plattformen Produktdokumentation und CE-Kennzeichnung korrekt handhaben, und baue sichere Checkout- und Kundendatenflüsse, die sowohl CRA als auch DSGVO erfüllen.
SBOM-Generierung und -Management. Ich richte automatisierte SBOM-Generierungs-Pipelines für Rails- und Solidus-Projekte mit CycloneDX ein. Jedes Deployment generiert automatisch eine aktuelle SBOM, die auf Anfrage den Behörden vorgelegt werden kann. Das ist nicht nur Compliance, das ist gute Praxis. Genau zu wissen, was in deiner Software steckt, bedeutet, dass du sofort reagieren kannst, wenn die nächste Log4Shell-Schwachstelle auftaucht.
Schwachstellenmanagement-Workflows. Ich baue und implementiere Schwachstellenbehandlungsprozesse, die CRA-Anforderungen erfüllen. Das umfasst die Einrichtung von Sicherheitskontaktseiten (security.txt), Schwachstellen-Meldeformularen, Triage-Workflows, Patch-Management-Prozessen und den Benachrichtigungspipelines, die für die 24-Stunden-Meldepflicht an ENISA nötig sind.
Penetrationstests und Security Audits. Mit Kali Linux und branchenüblichen Tools führe ich Sicherheitsbewertungen von Webanwendungen, APIs und Infrastruktur durch. Das umfasst Netzwerkaufklärung, Schwachstellen-Scanning, Web-Application-Testing und Social-Engineering-Assessment. Jeder Fund wird mit Schweregradbeurteilung und Behebungsempfehlung dokumentiert, was direkt in deine technische CRA-Dokumentation einfließt.
Infrastruktur-Härtung auf Linux. Alle meine Produktionssysteme laufen auf Linux (wie in meinem vorherigen Post über europäische digitale Souveränität besprochen), und ich härte sie nach CIS-Benchmarks. Das bedeutet ordentliche Firewall-Konfiguration, SSH-Härtung, regelmäßiges Patching, minimale Angriffsflächen und laufendes Monitoring. Für Solidus- und Rails-Deployments heißt das Nginx oder Caddy mit korrekter TLS-Konfiguration, Docker-Container mit minimalen Base-Images und automatisierte Sicherheitsupdates.
Growth Hacking, das Sicherheit nicht kompromittiert. Das ist der Punkt, der meinen Ansatz anders macht. Viele Growth Hacker schrauben Tracking-Scripts, Drittanbieter-Widgets und Marketing-Tools drauf, ohne an die Sicherheitsauswirkungen zu denken. Ich baue Wachstumssysteme, die von Grund auf sicher sind: First-Party-Analytics, datenschutzfreundliches Tracking, sichere Formular-Handler und Marketing-Automatisierung, die sowohl DSGVO- als auch CRA-Anforderungen erfüllt.
Was solltest du jetzt sofort tun?
Wenn du bis hierhin gelesen hast, fragst du dich wahrscheinlich, wo du anfangen sollst. Hier ist meine empfohlene Prioritätenliste.
Erstens, bestimme deinen Geltungsbereich. Finde heraus, ob deine Produkte unter den CRA, NIS2 oder beides fallen. Wenn du irgendeine Software oder vernetzte Hardware in der EU vertreibst, geh davon aus, dass du im Geltungsbereich bist, bis das Gegenteil bewiesen ist.
Zweitens, prüfe deinen Software-Stack. Generiere eine SBOM für jedes Produkt. Identifiziere alle Abhängigkeiten, einschließlich transitiver. Markiere alles, was nicht gepflegt wird, bekannte Schwachstellen hat oder keinen klaren Sicherheitskontakt.
Drittens, etabliere einen Schwachstellenbehandlungsprozess. Erstelle eine Sicherheitsrichtlinie, richte einen Sicherheitskontakt ein (wie eine security.txt-Datei), definiere deinen Triage- und Behebungsworkflow und teste ihn mit einem simulierten Vorfall.
Viertens, bereite dich auf die Meldepflicht vor. Die September-2026-Frist kommt schnell. Du brauchst Prozesse und Tooling, um Schwachstellen innerhalb von 24 Stunden zu erkennen, zu bewerten und an ENISA zu melden. Das bedeutet Monitoring, Alerting und eine klare Befehlskette.
Fünftens, dokumentiere alles. Fang jetzt an, deine technische Dokumentation aufzubauen. Risikobewertungen, Sicherheitsarchitektur, SBOM, Schwachstellenmanagement-Verfahren, Update-Richtlinien. All das brauchst du für die Konformitätsbewertung.
Sechstens, integriere Sicherheit in deine Pipeline. Wenn Sicherheit etwas ist, das du "später" oder "vor dem Release" machst, wirst du Probleme bekommen. Baue automatisierte Sicherheitstests in deine CI/CD-Pipeline ein. Mach es unmöglich, Code auszuliefern, der nicht gescannt wurde.
Der CRA geht nicht mehr weg. Die Fristen sind real. Die Strafen sind erheblich. Aber die Chance ist genauso real: Unternehmen, die Security-by-Design-Prinzipien annehmen, werden bessere Produkte bauen, mehr Vertrauen gewinnen und einen echten Wettbewerbsvorteil auf dem europäischen Markt erzielen.
Wenn du Hilfe brauchst, besonders mit Ruby on Rails, Solidus oder Custom-SaaS-Plattformen, dann ist genau das mein Job. Lass uns reden.