Cyber Resilience Act (CRA): Was Shop-Betreiber, Plugin-Entwickler und Tool-Anbieter jetzt wissen müssen

Der Cyber Resilience Act, offiziell Verordnung (EU) 2024/2847, ist eine dieser Regelungen, bei denen die meisten Shop-Betreiber, mit denen wir sprechen, entweder abwinken ("betrifft mich nicht, ich bau ja keine Hardware") oder komplett blank sind. Beides ist meistens falsch.

Ehrlich gesagt: Wir haben uns das Thema auch erst richtig angesehen, als ein LinkedIn-Post auf unserem Radar aufgeschlagen ist und ein Kunde uns gefragt hat, ob sein selbstgebautes WooCommerce-Plugin darunter fällt. Die Antwort: ziemlich sicher ja. Und die Uhr tickt schneller, als man denkt.

Deshalb dieser Artikel. Wir gehen die Sache in Ruhe durch: Was der CRA ist, wann was gilt, wer betroffen ist, und - der Punkt, an dem die meisten falsch abbiegen - was "Inverkehrbringen" eigentlich bedeutet. Dann drei konkrete Beispiele aus unserem Alltag: ein Plugin für smarte Türschlösser, ein Website-Baukasten ohne Datenbank, und ganz normale WooCommerce-Erweiterungen. Am Ende: Kosten, Strafen, was du jetzt tun kannst.

Kurzfassung für Eilige

Und jetzt in Ruhe.

Was ist der CRA eigentlich?

Der Cyber Resilience Act ist die erste EU-weite Verordnung, die verbindliche Cybersicherheits-Anforderungen an Produkte mit digitalen Elementen festlegt. Er ist am 11. Dezember 2024 in Kraft getreten und gilt ab dem 11. Dezember 2027 vollständig.

Das Ziel ist einfach beschrieben: Kein vernetztes Produkt soll mehr auf den EU-Markt kommen, das grundlegende Sicherheitsanforderungen nicht erfüllt. Router, die sich mit Standardpasswort ausliefern lassen, Smart-Home-Geräte ohne Update-Pfad, IoT-Sensoren, die niemand mehr patcht - all das soll systematisch beendet werden.

Der Mechanismus ist dem CE-Regime nachempfunden. Wer ein Produkt in Verkehr bringt, muss nachweisen können, dass es die grundlegenden Cybersicherheits-Anforderungen erfüllt, muss eine EU-Konformitätserklärung ausstellen, technische Dokumentation vorhalten und über einen definierten Zeitraum hinweg Schwachstellen behandeln.

Die zwei Stichtage - was gilt wann?

Anders als bei der PPWR gibt es beim CRA nur zwei wirklich relevante Termine. Der erste kommt sehr früh und wird deutlich unterschätzt.

Zwischen den beiden Terminen greift ab Juni 2026 noch die Notifizierung von Konformitätsbewertungsstellen - das ist eher ein Behördenthema und für dich als Hersteller nicht direkt relevant.

Was heißt "Produkt mit digitalen Elementen"?

Hier fängt der eigentliche Anwendungsbereich an. Und er ist weiter, als die meisten denken.

Ein Produkt mit digitalen Elementen ist nach CRA jedes Hardware- oder Softwareprodukt, das - direkt oder indirekt - eine Datenverbindung zu Geräten oder Netzwerken herstellen kann. Diese Verbindung kann physisch sein (WLAN, Bluetooth, USB, Ethernet) oder logisch (API, Cloud-Schnittstelle, Update-Mechanismus).

Ausdrücklich auch erfasst sind:

• Software als eigenständiges Produkt - Apps, Plugins, Erweiterungen, Firmware, kommerzielle Bibliotheken
• Fernverarbeitungslösungen - also die Server und Backends, die zu einem vernetzten Produkt gehören
• Getrennt in Verkehr gebrachte Komponenten, die für die Funktion eines CRA-Produkts benötigt werden

Ausgenommen sind - grob zusammengefasst:

• Produkte, die schon durch spezielle sektorale Regime abgedeckt sind: Medizinprodukte, Fahrzeuge, In-vitro-Diagnostika, zivile Luftfahrt, Schiffsausrüstung
• Produkte im Kontext der nationalen Sicherheit
• Kostenfreie Open-Source-Software ohne Gewinnerzielungsabsicht

Der entscheidende Punkt: "Inverkehrbringen" heißt jedes einzelne Exemplar

Das ist der Irrtum, an dem die meisten Fachartikel und leider auch einige Beratungen scheitern. Wir haben ihn selbst am Anfang der Recherche gemacht.

Die naheliegende Annahme: "Der CRA gilt für Produkte, die ab dem 11.12.2027 neu entwickelt werden." Klingt logisch, ist aber falsch.

Artikel 69 Abs. 2 CRA sieht vor, dass die Anforderungen nur für Produkte gelten, die nach dem 11. Dezember 2027 in Verkehr gebracht werden. Und "Inverkehrbringen" ist ein festgelegter Rechtsbegriff aus dem europäischen Produktsicherheitsrecht. Er bezieht sich auf das einzelne Produkt, nicht auf die Produktreihe.

Der offizielle Blue Guide der EU-Kommission stellt klar: "Inverkehrbringen" und "Bereitstellen" beziehen sich auf jedes einzelne Produkt - nicht auf einen Produkttyp, und unabhängig davon, ob es als Einzelstück oder in Serie hergestellt wurde.

Praktische Konsequenz für Hardware

Ein IoT-Sensor, der seit 2022 unverändert produziert wird und im Katalog steht, ist nicht automatisch "grandfathered". Jedes Exemplar, das ab dem 11.12.2027 erstmals in der EU angeboten wird, muss die CRA-Anforderungen erfüllen. Das Modell ist alt - das einzelne Gerät nicht.

Praktische Konsequenz für Software

Bei rein digital vertriebener Software ist die Logik etwas anders. Nach Blue Guide gilt Software als "in Verkehr gebracht", sobald sie erstmals im Rahmen einer gewerblichen Tätigkeit auf dem EU-Markt angeboten wird. Spätere Downloads gelten als Bereitstellung desselben Produkts. Neue Versionen sind nur dann ein neues Inverkehrbringen, wenn sie eine wesentliche Änderung darstellen.

Für dich als Plugin-Entwickler heißt das konkret: Wenn dein Plugin im November 2027 in einer stabilen Version im Shop steht, und du machst danach nur Bugfixes, ist es ein "Bestandsprodukt". Sobald du aber ein neues Major-Feature veröffentlichst, das die Funktionsweise wesentlich verändert - egal ob 2028, 2029 oder später - triggerst du ein neues Inverkehrbringen, und der CRA greift voll.

Die drei Produktkategorien nach CRA

Nicht jedes Produkt wird gleich behandelt. Der CRA teilt Produkte in drei Kategorien ein - je nach Risiko und Kritikalität. Davon hängt ab, wie streng die Konformitätsbewertung ausfällt.

Für die meisten von uns ist die Standard-Kategorie relevant. Aber Vorsicht: Sobald ein Produkt "sicherheitskritische" Funktionen übernimmt - Zutrittskontrolle, Passwortverwaltung, Netzwerksicherheit - kann es in die "wichtige" Klasse rutschen. Und dann wird es deutlich aufwendiger.

Beispiel 1: Ein Shop-Betreiber, der fremde Ware verkauft

Fangen wir mit dem entspanntesten Fall an. Du betreibst einen WooCommerce- oder Shopify-Shop und verkaufst fremde Produkte - Wein, Kosmetik, Haushaltswaren, was auch immer. Kein Software-Vertrieb, keine Eigenmarken-Elektronik, keine Bundles mit selbstentwickelten Apps.

Dann bist du im CRA-Sinn nicht Hersteller, sondern höchstens Händler - und auch das nur, wenn du Produkte weiterverkaufst, die tatsächlich unter den CRA fallen (also selbst vernetzbare Geräte oder kommerzielle Software).

Was du als Händler tun musst

• Prüfen, ob deine gelisteten Produkte eine CE-Kennzeichnung tragen (die CE wird um Cybersicherheit erweitert)
• Prüfen, ob eine EU-Konformitätserklärung oder deren vereinfachte Version verfügbar ist
• Sicherstellen, dass die vom Hersteller vorgeschriebenen Nutzerinformationen (Support-Zeitraum, Kontakt für Schwachstellenmeldungen) mit dem Produkt weitergegeben werden
• Bei begründetem Verdacht auf Non-Compliance keine Weiterverbreitung, Meldung an Hersteller/Behörde

Für die meisten Shops mit "normalem" Sortiment ist das überschaubar. Wer aber Elektronik, IoT, Smart-Home-Zubehör oder digitale Produkte listet, sollte die Lieferantenprüfung ab 2027 systematisch aufsetzen.

Beispiel 2: Ein Plugin für Tedee- und Nuki-Schlösser

Jetzt wird es interessant. Wir hatten kürzlich die Frage, wie es sich mit einem WordPress-Plugin verhält, das an Tedee- und Nuki-Türschlösser andockt und Zugangscodes automatisch aus Online-Buchungen generiert - klassischer Use Case für Ferienwohnungen.

Kurze Antwort: Das ist ein glasklarer CRA-Fall. Und zwar keiner in der Standard-Kategorie.

Warum betroffen?

• Es ist Software, die kommerziell vertrieben wird (Lizenz, Abo, Support-Vertrag) - keine gemeinnützige Open-Source-Ausnahme
• Es kommuniziert mit vernetzten Produkten (Schlössern) über deren API
• Es verarbeitet sicherheitskritische Daten (Zugangscodes, Buchungsdetails, personenbezogene Daten)
• Es übernimmt eine sicherheitsrelevante Funktion: Zutrittskontrolle

Warum voraussichtlich Klasse I der wichtigen Produkte?

Nach Anhang III CRA fallen Produkte, die für die Zutrittskontrolle oder Identitätsverwaltung eingesetzt werden, in die Kategorie der wichtigen Produkte. Ein Plugin, das automatisch Türschlösser öffnet oder Codes generiert, erfüllt diese Beschreibung ziemlich klar - auch wenn das eigentliche Schloss ein fremdes Produkt ist.

Was das für den Entwickler heißt:

• Konformitätsbewertung nach strengerem Modul (nicht nur interne Kontrolle)
• Ggf. Anwendung harmonisierter Normen oder Einbindung einer notifizierten Prüfstelle
• Vollständige technische Dokumentation, Bedrohungsanalyse, Risikobewertung
• Definierter Support-Zeitraum (üblicherweise mindestens 5 Jahre nach Inverkehrbringen des letzten Exemplars)
• Schwachstellenmanagement mit Meldepflicht ab 11.09.2026
• EU-Konformitätserklärung, CE-Kennzeichnung (auf der Downloadseite und im Impressum des Plugins)

Realistischer Aufwand für ein professionelles Setup: mittlerer fünfstelliger Bereich für die Erstumsetzung, plus laufender Aufwand für Vulnerability-Handling. Für ein kleines Ein-Personen-Projekt ist das ein echter Kostenblock. Für kommerzielle Anbieter machbar, aber planungsrelevant.

Beispiel 3: Ein Website-Baukasten ohne Datenbank

Der spannende Grenzfall. Stell dir ein Tool vor, mit dem du Websites per Copy-und-Paste zusammenklickst - reine HTML-Ausgabe, keine Datenbank, kein Backend. Die generierten Seiten kannst du überall hochladen.

Ob der CRA greift, hängt an einer einzigen Frage: Wie wird das Tool ausgeliefert?

Variante A: Das Tool läuft komplett im Browser des Nutzers

Nutzer lädt eine HTML/JS-Datei runter, öffnet sie lokal, klickt seine Seite zusammen, exportiert das Ergebnis. Kein Login, keine Cloud, keine Nachladung von Assets, keine Update-Mechanismen. Reines Werkzeug, das offline funktioniert.

Nach aktueller juristischer Einschätzung: vermutlich nicht CRA-pflichtig. Es fehlt die Datenverbindung, die den CRA-Anwendungsbereich öffnet. Das Tool ist ein isoliertes Stück Software - vergleichbar mit einem Word-Dokument oder einer statischen PDF-Vorlage.

Variante B: Das Tool läuft als SaaS auf deinem Server

Nutzer meldet sich an, arbeitet in der Cloud, Assets werden nachgeladen, gespeichert wird beim Anbieter, Updates kommen automatisch. Das ist klar eine Fernverarbeitungslösung im Sinne des CRA - und damit erfasst.

Variante C: Das Tool wird lokal installiert, phont aber "nach Hause"

Sobald irgendwo ein Auto-Update, ein Telemetrie-Endpoint, ein Lizenz-Check oder ein Asset-CDN drinsteckt, wird aus dem "reinen lokalen Tool" ein vernetztes Produkt. Und dann greift der CRA.

Beispiel 4: Ein "normales" WooCommerce-Plugin

Der Fall, der viele in unserem Umfeld betrifft. Du entwickelst ein WooCommerce-Plugin, das eine Standardfunktion erweitert - Mengenrabatte, Bundle-Angebote, erweiterte Versandregeln, ein Checkout-Feature, ein Analytics-Add-on. Du verkaufst es über deine eigene Website, CodeCanyon, WooCommerce.com oder als Freemium.

Ergebnis: CRA-relevant, meist in der Standard-Kategorie.

Warum?

• Es ist Software, die kommerziell vertrieben wird
• Sie läuft in einer vernetzten Umgebung (WordPress → Web → APIs)
• Sie spricht mit externen Diensten (Payment, Versand, Marketing, Update-Server)
• Sie erhält regelmäßige Updates - allein das genügt als "digitales Element"

Was du konkret liefern musst

• Grundlegende Cybersicherheits-Anforderungen nach Anhang I CRA einhalten: sichere Voreinstellungen, Schutz vor unbefugtem Zugriff, Datenintegrität, minimaler Angriffsflächen-Ansatz, Update-Mechanismen, Logging
• Risikobewertung dokumentieren
• Technische Dokumentation nach Anhang VII - inklusive Bedrohungsmodell, Architekturbeschreibung, Testberichten
• EU-Konformitätserklärung ausstellen (Selbsterklärung reicht in Standardkategorie)
• CE-Kennzeichnung auf Verpackung/Downloadseite/README
• Support-Zeitraum festlegen und öffentlich kommunizieren
• Schwachstellenmanagement: Kontaktkanal für Sicherheitsmeldungen, Prozess zur Bewertung, Behebung, Kommunikation
• Meldung an ENISA bei aktiv ausgenutzten Schwachstellen innerhalb 24 Stunden - ab 11.09.2026

Die gute Nachricht: Für ein sauber entwickeltes Plugin ist der Erstaufwand überschaubar. Wer heute schon Semver, saubere Update-Kanäle, verantwortungsvolle Vulnerability-Disclosure und Dokumentation macht, hat 70 Prozent der CRA-Anforderungen erfüllt. Der Rest ist Formalismus.

Die schlechte Nachricht: Wer schnell mal ein Plugin zusammengestrickt, seit 2019 nicht mehr richtig gewartet und über Envato verkauft hat - der hat ab 11.12.2027 ein Problem.

Die zentralen Pflichten im Detail

Egal in welcher Kategorie du landest, die Grundstruktur der Pflichten ist gleich. Der Umfang und die Nachweistiefe unterscheiden sich.

1. Security by Design

Cybersicherheit muss von Anfang an in Konzeption, Entwicklung und Produktion mitgedacht werden. Das ist mehr als ein Buzzword - es bedeutet konkret: Bedrohungsanalyse vor der Entwicklung, sichere Defaults, minimale Angriffsfläche, keine Standard-Zugangsdaten, sichere Update-Mechanismen, saubere Logs.

2. Risikobewertung und grundlegende Anforderungen

Anhang I CRA listet die "essential requirements". Kurz zusammengefasst: Das Produkt muss sicher konfiguriert ausgeliefert werden, unbefugten Zugriff verhindern, Vertraulichkeit und Integrität schützen, nur die tatsächlich notwendigen Daten verarbeiten, Ausfälle verkraften, Angriffsfläche minimieren, sicherheitsrelevante Ereignisse protokollieren, sichere Updates ermöglichen.

3. Technische Dokumentation

Anhang VII beschreibt, was in der technischen Dokumentation stehen muss: allgemeine Beschreibung, Bedrohungsanalyse, Nachweis der grundlegenden Anforderungen, Architektur, Testberichte, Support-Zeitraum, SBOM (Software Bill of Materials). Das ist der Ordner, den du bei einer Marktüberwachungs-Prüfung vorlegen können musst.

4. Konformitätsbewertung und EU-Konformitätserklärung

In der Standard-Kategorie: Selbstbewertung, Modul A. In der wichtigen Kategorie: strengere Module, ggf. Prüfstelle. Am Ende steht eine EU-Konformitätserklärung nach Anhang V, die du 10 Jahre lang bereithalten musst - oder für die Dauer des Support-Zeitraums, je nachdem was länger ist.

5. CE-Kennzeichnung

Die CE-Kennzeichnung wird um Cybersicherheit erweitert. Ein Produkt ohne gültige CE darf ab 11.12.2027 nicht mehr in Verkehr gebracht werden. Bei Software erfolgt die Kennzeichnung digital - auf der Downloadseite, im Info-Dialog, in der Dokumentation.

6. Support-Zeitraum und Schwachstellenmanagement

Du musst einen Support-Zeitraum festlegen und kommunizieren. In der Regel mindestens fünf Jahre nach Inverkehrbringen des letzten Exemplars, kann aber je nach erwarteter Nutzungsdauer länger sein. Innerhalb dieses Zeitraums musst du:

• Schwachstellen aktiv identifizieren und behandeln
• Sicherheitsupdates zeitnah bereitstellen - kostenlos für die Nutzer
• Einen Kontaktkanal für Sicherheitsmeldungen vorhalten
• Eine Coordinated-Vulnerability-Disclosure-Policy dokumentieren

7. Meldepflichten ab 11.09.2026

Der zeitlich erste harte Termin. Ab diesem Datum gilt für alle Hersteller vernetzter Produkte - unabhängig davon, wann das Produkt entwickelt wurde:

• Aktiv ausgenutzte Schwachstellen: Frühwarnung an ENISA und CSIRT binnen 24 Stunden
• Vertiefte Meldung binnen 72 Stunden
• Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme
• Ähnliche Regelung für schwere Sicherheitsvorfälle
• Betroffene Nutzer sind unverzüglich zu informieren

Kosten und Strafen

Der CRA kennt keine Bagatellgrenze für Kleinunternehmen. Es gibt einige Erleichterungen für KMU - vereinfachte technische Dokumentation, angepasste Formen der Konformitätsbewertung - aber die Grundpflichten gelten für alle. Explizit auch für Ein-Personen-Anbieter, sobald sie kommerziell tätig sind.

Realistische Kosten

Diese Zahlen sind Größenordnungen aus dem Marktumfeld August 2026 und stark abhängig davon, wie ausgereift dein internes Sicherheits-Setup schon ist. Wer aus einer stabilen Software-Prozessreife kommt, liegt am unteren Rand. Wer bei null anfängt, am oberen.

Strafen

Der CRA sieht abgestufte Bußgelder vor. Für die schwersten Verstöße - also Missachtung der grundlegenden Anforderungen, Falscherklärung der Konformität, Verletzung der Meldepflicht - drohen Bußgelder bis 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem was höher ist. Bei weniger schweren Verstößen: bis 10 Mio. Euro oder 2 %. Bei fehlerhaften Angaben gegenüber Behörden: bis 5 Mio. Euro oder 1 %.

Zusätzlich möglich: Rückruf, Vertriebsverbot, Marktrücknahme durch die zuständige nationale Marktüberwachungsbehörde (in Österreich voraussichtlich RTR/BMLIT, in Deutschland BSI und Länderbehörden).

Was du jetzt konkret tun solltest

Nicht in Panik verfallen. Aber auch nicht auf 2027 warten. Was zwischen jetzt und Ende 2026 wirklich sinnvoll ist:

Ehrliche Einschätzung: Was der CRA für europäische Software-Anbieter bedeutet

Genau wie bei der PPWR bekommt man in den offiziellen Merkblättern die reine Regelungsseite. Was der CRA in der Praxis auslöst, ist wieder etwas anderes.

Der Grundgedanke ist richtig. Die Umsetzung trifft die Falschen zuerst.

1. Konsolidierung im Plugin- und App-Markt

Wir rechnen mit einer sichtbaren Bereinigung im Bereich kleiner kommerzieller WordPress- und WooCommerce-Plugins. Wer sein Plugin nebenbei gebaut hat und 500 Euro Umsatz pro Monat macht, wird sich den Compliance-Aufwand nicht antun. Das Ergebnis: Weniger Vielfalt, mehr Konzentration bei den etablierten Anbietern.

2. Aufwertung von "richtigen" Anbietern

Wer schon heute sauber entwickelt, dokumentiert und Sicherheit ernst nimmt, hat plötzlich einen echten Wettbewerbsvorteil. Compliance wird zum Verkaufsargument. Kunden werden - langsam, aber sichtbar - anfangen, nach CE-Kennzeichnung und Konformitätserklärung zu fragen.

3. Wettbewerbsverzerrung mit Nicht-EU-Anbietern

Anbieter außerhalb der EU haben keine direkte Pflicht, aber wer in die EU verkauft, braucht einen europäischen Bevollmächtigten. Die Durchsetzung gegenüber ausländischen Anbietern ist wieder das offene Fragezeichen. Wer im Zweifel gesetzestreu ist? Der österreichische oder deutsche Entwickler. Nicht der anonyme SaaS aus Übersee.

4. Chance für professionelle Anbieter

Genau wie damals bei DSGVO gibt es einen Übergangsschmerz und dann eine neue Normalität. Wer die Umsetzung sauber macht, gewinnt. Wer sich drücken will, verliert. Das ist bei Regulierung meist so.

5. Was wir bei SHOMUGO tun

Wir sehen den CRA pragmatisch: Er ist Realität, er kommt so wie er ist, und wir helfen unseren Kunden dabei, die Umsetzung machbar zu halten. Wir sind keine zertifizierte Prüfstelle - dafür gibt es Spezialisten. Aber wir helfen dabei, die richtigen Fragen zu stellen, die Produktarchitektur so aufzustellen, dass sie CRA-fähig bleibt, und die begleitenden Rechtstexte, Prozesse und Dokumentationen aufzusetzen. Wir arbeiten daran, dass in den nächsten Monaten hier auf shomugo.com ein CRA-Selbstcheck als kostenloses Tool, ein DoC-Vorlagengenerator und ein Vulnerability-Disclosure-Template-Paket verfügbar sind. Wenn du auf dem Laufenden bleiben willst, trag dich in unseren Newsletter ein.

Fazit

Der Cyber Resilience Act ist keine Nischenregelung. Er trifft praktisch jeden, der digitale Produkte kommerziell in Europa anbietet - vom WooCommerce-Plugin über SaaS-Tools bis zum smarten Türschlossadapter. Reiner Weiterverkauf fremder Ware ist entspannt. Alles, was du unter deinem Namen entwickelst und verkaufst, muss ab 11.12.2027 konform sein.

Was du jetzt tun kannst:

• Produkt-Inventar mit CRA-Einschätzung erstellen
• Meldeprozess für Schwachstellen bis 11.09.2026 aufsetzen
• Vulnerability-Disclosure-Policy veröffentlichen
• Support-Zeitraum je Produkt festlegen und kommunizieren
• Technische Dokumentation als lebendes Dokument aufsetzen
• Bei alten, kaum gepflegten Produkten ehrlich über End-of-Life nachdenken
• Nicht in Panik verfallen. Die Meldepflicht kommt in wenigen Wochen, die volle Anwendung erst in 16 Monaten.

Wenn du bei der Einordnung deiner Produkte, bei der Architektur, bei den Prozessen oder bei den Rechtstexten Unterstützung brauchst - melde dich. Wir sind ehrlich, wir sind direkt, und wir sagen dir auch, wenn du für die eigentliche Konformitätsbewertung besser zu einer spezialisierten Prüfstelle gehst.

Der CRA ist kein Weltuntergang. Aber er ist der nächste Punkt auf der langen Liste, die europäische Anbieter aktuell abarbeiten müssen. Und diesmal betrifft es genau die Menschen, die diesen Artikel wahrscheinlich lesen.

Dieser Artikel gibt den Recherchestand vom August 2026 wieder. Die harmonisierten Normen zum CRA sind teilweise noch in der Ausarbeitung. Alle Angaben ohne Gewähr. Dieser Beitrag ersetzt keine Rechtsberatung.

Häufige Fragen zum Cyber Resilience Act

Ab wann gilt der CRA?
Der Cyber Resilience Act (Verordnung EU 2024/2847) ist am 11. Dezember 2024 in Kraft getreten. Ab 11. September 2026 greifen die Meldepflichten für Hersteller. Ab 11. Dezember 2027 gilt der CRA vollständig - alle Produkte mit digitalen Elementen, die ab diesem Datum erstmals in der EU in Verkehr gebracht werden, müssen die Anforderungen erfüllen.

Was heißt "Inverkehrbringen" genau?
Inverkehrbringen bezieht sich auf das einzelne Produkt, nicht auf die Produktreihe. Ein Gerät oder Softwareexemplar gilt als in Verkehr gebracht, sobald es erstmals auf dem EU-Markt bereitgestellt wird. Bei Software zählt der erstmalige Vertrieb einer Version; spätere Downloads gelten als Bereitstellung derselben Software. Wesentliche Änderungen können ein neues Inverkehrbringen auslösen.

Ist mein WooCommerce-Plugin vom CRA betroffen?
Sobald du dein Plugin kommerziell vertreibst - egal ob per Direktverkauf, Abonnement, Freemium mit Pro-Version oder über einen Marktplatz - handelt es sich um ein Produkt mit digitalen Elementen im Sinne des CRA. Für die meisten Plugins gilt die Standard-Kategorie mit Selbstbewertung. Kostenlose Open-Source-Plugins ohne Gewinnerzielungsabsicht sind ausgenommen.

Wird ein Plugin für smarte Schlösser wie Tedee oder Nuki strenger behandelt?
Ja. Nach Anhang III CRA fallen Produkte mit Zutrittskontroll- oder Identitätsmanagement-Funktion in die Kategorie der wichtigen Produkte. Ein Plugin, das automatisch Zugangscodes für vernetzte Schlösser erzeugt, erfüllt diese Beschreibung. Konformitätsbewertung, Dokumentation und Prüfstelle sind aufwendiger als bei einem Standard-Plugin.

Muss ich als reiner Shop-Betreiber ohne Eigenmarken etwas tun?
Direkte Herstellerpflichten treffen dich nicht. Wenn du aber Elektronik, IoT-Geräte, Smart-Home-Zubehör oder digitale Produkte (Software, Apps) weiterverkaufst, hast du eingeschränkte Händlerpflichten: CE-Kennzeichnung prüfen, Konformitätserklärung des Herstellers vorhalten, Nutzerinformationen weitergeben, bei Verdacht auf Non-Compliance keine Weiterverbreitung.

Kann ich mein Website-Tool so bauen, dass es außerhalb des CRA bleibt?
Grundsätzlich ja - wenn es komplett lokal läuft, keine Netzwerkverbindung aufbaut, keine Auto-Updates zieht, keine Cloud-Anbindung hat und rein statische Ergebnisse produziert. Sobald irgendein Update-, Telemetrie- oder Cloud-Element dazukommt, greift der CRA. Diese Architekturentscheidung ist bewusst zu treffen und zu dokumentieren.

Was passiert bei Verstößen?
Bußgelder bis 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Bei weniger schweren Verstößen bis 10 Millionen Euro oder 2 Prozent. Zusätzlich sind Rückruf, Vertriebsverbot und Marktrücknahme möglich. In Österreich läuft die Marktüberwachung voraussichtlich über RTR/BMLIT, in Deutschland über BSI und Länderbehörden.

Wie lange muss ich Sicherheitsupdates bereitstellen?
Du legst den Support-Zeitraum selbst fest und kommunizierst ihn öffentlich. Als Richtwert nennt der CRA fünf Jahre nach Inverkehrbringen des letzten Exemplars, sofern die erwartete Nutzungsdauer nicht länger ist. Bei Produkten mit langer Lebensdauer (Smart-Home, Industrie) kann dieser Zeitraum deutlich länger sein.

Gilt der CRA auch für Software, die ich vor 2027 veröffentlicht habe?
Für die volle CRA-Konformität nicht - Bestandsprodukte, die vor dem 11.12.2027 in Verkehr gebracht wurden, sind nicht rückwirkend erfasst. Die Meldepflichten für aktiv ausgenutzte Schwachstellen ab 11.09.2026 gelten jedoch auch für diese Bestandsprodukte. Wesentliche Änderungen können zudem ein neues Inverkehrbringen und damit die volle Anwendung auslösen.

Ich baue mit WordPress und Plugins Websites für Kunden - bin ich betroffen?
Als reiner Dienstleister, der Kundenwebsites zusammenbaut und wartet, bist du kein Hersteller im CRA-Sinn. Du erbringst eine Werkleistung, die Plugin-Hersteller (Automattic, Yoast, WPML und andere) tragen die CRA-Pflichten. Sobald du aber eigene Individualentwicklungen als wiederverwendbares Produkt bei mehreren Kunden einsetzt oder eigene Plugins/Themes vertreibst, wirst du zum Hersteller und die CRA-Pflichten greifen für diese Produkte.

Meine Plugins nutzen nur fremde APIs (WooCommerce, Tedee, Nuki) - bin ich trotzdem betroffen?
Ja. Dein Plugin ist ein eigenständiges Produkt mit digitalen Elementen - unabhängig davon, welche APIs es intern nutzt. Der CRA betrachtet dein Plugin als Ganzes: die Speicherung von API-Tokens, die Verarbeitung von Webhooks, die Auslösung sicherheitsrelevanter Aktionen wie Türöffnungen oder Zahlungen, die Verkettung mehrerer APIs zu neuen Funktionen. Für all das bist du verantwortlich, auch wenn Teilfunktionen aus Fremd-APIs stammen. Die Verantwortung des API-Anbieters entlastet dich nicht.

Ich baue mit KI Websites und SaaS-Anwendungen (Builder, KI-Anrufbeantworter) - wie trifft mich das?
Sehr direkt. Der CRA unterscheidet nicht, wie Software entstanden ist - ob getippt oder KI-generiert ist rechtlich irrelevant. Website-Builder als SaaS sind klassische Fernverarbeitungslösungen und erfasst. KI-Anrufbeantworter sind aufgrund der Sprachverarbeitung, der Fremdsystem-Integration und der potenziellen Identitätsfunktion sehr wahrscheinlich in der Kategorie "wichtige Produkte". Zusätzlich greifen die Transparenzpflichten des AI Act parallel. Vorsicht bei schnellem Micro-SaaS-Bau: Jedes Produkt braucht seine eigene Konformitätserklärung und Dokumentation.

Wenn ich alles als Freemium anbiete - bin ich dann nicht betroffen?
Nein, das ist ein teurer Irrtum. Die Open-Source-Ausnahme greift nur bei kostenfreier Software ohne jede kommerzielle Tätigkeit. Freemium ist per Definition ein kommerzielles Vertriebsmodell - die kostenlose Version ist Marketing für die zahlungspflichtige. Damit gilt der CRA für das Gesamtprodukt. Auch die Konstellationen "gratis mit Pro-Modulen", "limitiert bis X Nutzer" oder "GPL-Plugin mit bezahltem Support als Vertriebsmodell" fallen unter den CRA.

Welche Auflagen gelten grundsätzlich für Plugins und SaaS? Muss ich etwas einreichen?
Für Standard-Produkte gibt es keine Vorab-Prüfung und keine Einreichung. Das System basiert auf Selbstbewertung nach Modul A. Deine Pflichten: grundlegende Cybersicherheits-Anforderungen einhalten (Anhang I), Risikobewertung durchführen, technische Dokumentation aufsetzen (Anhang VII inkl. SBOM), EU-Konformitätserklärung ausstellen (Anhang V, 10 Jahre aufbewahren), CE-Kennzeichnung digital anbringen, Support-Zeitraum festlegen und kommunizieren, Vulnerability-Handling-Prozess einrichten. Öffentlich müssen CE-Kennzeichnung, Meldekanal und Support-Zeitraum sein - der Rest wird nur bei behördlicher Prüfung vorgelegt. Für "wichtige Produkte" wird eine notifizierte Prüfstelle erforderlich, wenn du nicht die harmonisierten Normen vollständig anwendest.