Der CRA in Kürze: Cybersicherheit wird zur Produktanforderung

Der CRA macht Cybersicherheit zu einer Eigenschaft des Produkts. Wer ein „Produkt mit digitalen Elementen“ in der EU auf den Markt bringt, muss es sicher konzipieren und entwickeln, während der erwarteten Nutzungsdauer mit Sicherheitsupdates versorgen, ein Schwachstellenmanagement betreiben, die Konformität mit den strengen Cybersicherheits-Vorgaben des CRA bewerten und dokumentieren (lassen) und das Produkt mit der CE-Kennzeichnung versehen. Der CRA greift damit auf das vertraute Instrumentarium des EU-Produktrechts zurück und erweitert es um die Cybersicherheit.

Erfasst sind Hardware und Software gleichermaßen, vom Router über die Industriesteuerung bis zur Desktop-Anwendung, zur mobilen App und zur ausgelieferten Firmware. Entscheidend ist die Begriffsbestimmung in Art 3 Z 1 CRA – ein Produkt, dessen bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt (Leitfaden, Seite 8 Rz 17 f). Die Hauptlast tragen Hersteller. Importeure und Händler haben eigene, abgestufte Prüfpflichten.

Spannenderweise gilt der CRA eben nicht nur für physische Produkte. Auch wer Software entwickelt und in der EU kommerziell anbietet, ist Hersteller im Sinne des CRA – ohne ein einziges Gerät im Portfolio.

Die Pflichten greifen gestaffelt. Der CRA ist am 10.12.2024 in Kraft getreten, seit 11.06.2026 können Konformitätsbewertungsstellen benannt werden, am 11.09.2026 beginnen die Meldepflichten, ab 11.12.2027 gilt die Verordnung vollständig.

Der Sanktionsrahmen ist (wer die Digitalrechts-Gesetzgebung der letzten Jahre nicht ganz ausgeblendet hat, wird das nicht überraschen) ein weiteres Mal beachtlich: Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen sind Geldbußen von bis zu EUR 15 Mio oder 2,5 % des weltweiten Jahresumsatzes vorgesehen (Art 64 CRA).

Der CRA als Baustein des EU-Digitalrechts

Die EU reguliert Cybersicherheit auf mehreren Ebenen. Der CRA ist Teil der größeren Idee, Unternehmen und Konsumenten in der EU resilienter zu machen und vor Cyberangriffen zu schützen. Die Regulierungslandschaft lässt sich grob so beschreiben:

Neben dem CRA ist zunächst die NIS-2-Richtlinie zu erwähnen. In Österreich durch das NISG 2026 umgesetzt, richtet sich dieses Regime an Organisationen in bestimmten kritischen Sektoren. Wer in einem erfassten Sektor tätig ist, muss spezifische Risikomanagementmaßnahmen treffen und Vorfälle melden. CRA und NISG 2026 können ohne Weiteres nebeneinander anwendbar sein: Ein Industriebetrieb kann zugleich Einrichtung nach dem NISG 2026 und Hersteller nach dem CRA sein, mit zwei getrennten Meldewegen und zwei getrennten Dokumentationslinien.

Daneben stehen weitere Bausteine, die dieselben Produkte betreffen können:

• die DSGVO für die Verarbeitung personenbezogener Daten;
• die KI-VO, deren Cybersicherheitsanforderungen für Hochrisiko-KI-Systeme unter bestimmten Voraussetzungen durch CRA-Konformität als erfüllt gelten (Art 12 CRA);
• die neue Produkthaftungsrichtlinie, die Software ausdrücklich als Produkt erfasst und unterlassene Sicherheitsupdates in den Blick nimmt; sowie
• sektorspezifische Regime wie DORA im Finanzsektor.

Der CRA schließt in diesem Gefüge die Lücke auf der Produktebene: Er sorgt dafür, dass das, was Unternehmen einkaufen und einsetzen, ein Mindestmaß an Sicherheit mitbringt und macht Cybersicherheit damit zum Einkaufsfaktor und Vertragsthema.

Der neue Leitfaden zum CRA: nicht verbindlich, aber maßgeblich

Das Papier wurde am 27.07.2026 als Anhang zur Mitteilung C(2026) 5252 veröffentlicht. Es umfasst rund 80 Seiten und arbeitet mit zahlreichen Praxisbeispielen, Anwendungsfällen und Ablaufdiagrammen. Gegenüber dem Konsultationsentwurf von Anfang März 2026 fällt die finale Fassung detaillierter und in mehreren Punkten spürbar verhältnismäßiger aus. Der veröffentlichte Leitfaden ist rechtlich nicht verbindlich, eine verbindliche Auslegung des CRA kann nur der EuGH vornehmen. Für die Praxis ist er nichtsdestoweniger der wichtigste Referenzpunkt, weil sich Marktüberwachungsbehörden und notifizierte Stellen daran orientieren werden. Ergänzend hält die EU-Kommission ein laufend aktualisiertes FAQ-Dokument zur CRA-Umsetzung bereit.

Wir haben die für Unternehmen relevanten Punkte aufbereitet und jeweils eingeordnet, was daraus praktisch folgt.

1. Software, Web-Applikationen und Websites

Wann fällt Software als eigenständiges Produkt unter den CRA? Der Leitfaden stellt auf den Ort der Ausführung ab. Software, die Nutzer:innen bereitgestellt und lokal auf deren System ausgeführt wird, ist ein „Produkt mit digitalen Elementen“ im Sinne des Art 3 Z 1 CRA. Das gilt für Downloads und installierte Clients ebenso wie für Browser-Erweiterungen und für Anwendungen, die mit Web-Technologien entwickelt, aber lokal ausgeführt werden (Leitfaden, Seite 8 Rz 20).

Software, die rein remote ausgeführt und lediglich über einen Browser abgerufen wird, ist für sich genommen kein solches Produkt. Dasselbe gilt für Websites, die bloß Informationen bereitstellen (Leitfaden, Seite 8 Rz 21, unter Verweis auf ErwGr 11 und 12 CRA). Erfasst wird solche Software erst, wenn sie als „Remote Data Processing Solution“ („RDPS“, zu Deutsch etwas sperrig: „Datenfernverarbeitungslösungen“; vgl Art 3 Z 2 CRA und sogleich unten) für eine Funktion eines anderen Produkts notwendig ist.

Die EU-Kommission grenzt noch etwas spezifischer ab. Erfasst sind jene Module, die für die Funktionalität des Produkts verantwortlich sind, samt der von ihnen genutzten Schnittstellen. Nachgelagerte Back-End-Systeme, mit denen das Produkt nicht unmittelbar interagiert, sind keine RDPS (Leitfaden, Seiten 63 ff). Für SaaS-Anbieter ist das von erheblicher praktischer Bedeutung. Wer ausschließlich eine browserbasierte Lösung betreibt, wird nicht schon deshalb Hersteller im Sinne des CRA. Wer daneben ein Installationspaket, ein Plug-in, einen Agenten oder eine Desktop-App ausliefert, sehr wohl, und zwar für diese Komponente.

Praktisch ebenso relevant ist die Aussage im Leitfaden zum Inverkehrbringen von Software. Identische Kopien derselben Version gelten als in Verkehr gebracht, sobald diese Version erstmals in der Union zum Vertrieb oder zur Nutzung angeboten wird. Varianten, die sich in Komponenten, Konfiguration oder freigeschalteter Funktionalität unterscheiden, sind hingegen eigene Produkte mit eigenem Stichtag (Leitfaden, Seite 7 Rz 14). Das betrifft Versions- und Release-Management unmittelbar.

2. Remote Data Processing: Wo verläuft die Grenze?

Der CRA erfasst nicht nur das Gerät selbst, sondern auch jene Fernverarbeitung, ohne die es seine Funktion nicht erfüllen könnte. Die Cloud hinter dem smarten Thermostat ist Teil des Produkts, nicht bloß ein Dienst daneben. Der Leitfaden arbeitet dafür mit drei kumulativen Prüffragen und ergänzt sie um ein Ablaufdiagramm sowie um Anwendungsfälle von der Mobile-Banking-App bis zum Industrieroboter (Leitfaden, Seiten 63 ff, zu Anwendungsfällen Seiten 70 ff).

Die Prüfungsfragen lauten wie folgt:

1. Findet die Datenverarbeitung aus der Ferne statt?
2. Würde ihr Fehlen das Produkt daran hindern, eine seiner Funktionen auszuführen?
3. Wurde die Software vom Hersteller oder unter dessen Verantwortung entwickelt?

Reine SaaS-, IaaS- oder PaaS-Leistungen von Drittanbietern, die ein Hersteller lediglich nutzt, sind nach dem Leitfaden grundsätzlich keine eigenen RDPS (Datenfernverarbeitungslösungen). Sie sind aber als externe Abhängigkeit in der Cybersicherheits-Risikobewertung nach Art 13 Abs 2 CRA zu berücksichtigen und unterliegen der Sorgfaltspflicht des Art 13 Abs 5 CRA (Leitfaden, Seiten 68 f). Für Hersteller bedeutet das eine Überprüfung der Verträge und Beziehungen auch mit solchen Diensten in der Lieferkette.

3. Ersatzteile: funktionale Betrachtung, strengerer Kontextnachweis

Der CRA macht auch Ersatzteile zum Thema. Jede Komponente mit digitalen Elementen, die einzeln auf den Markt kommt, ist grundsätzlich selbst ein Produkt im Sinne des CRA, mit eigener Risikobewertung, eigener Konformitätsbewertung und eigener CE-Kennzeichnung. Für Reparaturen wäre das unpraktikabel. Art 2 Abs 6 CRA nimmt deshalb Ersatzteile aus, die identische Komponenten ersetzen und nach denselben Spezifikationen gefertigt sind (dazu auch ErwGr 29 CRA). Wo diese Ausnahme endet, entscheidet in der Praxis darüber, ob ein Ersatzteil ohne Weiteres ausgeliefert werden darf oder ob es zum gesonderten CRA-Fall wird.

Der Leitfaden legt die Ersatzteil-Ausnahme flexibel und damit grundsätzlich gut kontrollierbar aus. „Identisch“ meint nicht zwingend physisch oder technisch in jeder Hinsicht gleich. Maßgeblich sind die funktionale Rolle und die cybersicherheitsrelevanten Eigenschaften (Leitfaden, Seite 32 Rz 99). Geringfügige Abweichungen bleiben daher unschädlich, solange sie das Cybersicherheitsprofil des Bauteils nicht verändern. Unterschiede bei Algorithmen, Kommunikationsprotokollen, kryptografischen Mechanismen oder Zugriffskontrollen sprechen hingegen gegen eine gemeinsame Identität (Leitfaden, Seite 32 Rz 100). Dann ist das neue Ersatzteil als eigenes Produkt mit digitalen Elementen zu behandeln.

Maßgeblich ist außerdem der Kontext. Das Teil muss spezifisch zur Reparatur oder zur Verlängerung der Lebensdauer eines identifizierten Produkts oder einer Produktfamilie geliefert werden, technische Kompatibilität allein genügt nicht. Der Reparaturzweck soll sich aus den Umständen der Lieferung ergeben, etwa aus Bestellung, Angebot oder After-Sales-Kanal, und die Nachweise sind für die Marktüberwachung aufzubewahren (Leitfaden, Seiten 31 f, Rz 97). Auch ein vollständiges Produkt, das in ein größeres integriert wird, etwa eine speicherprogrammierbare Steuerung in einer Automatisierungsanlage, kann unter die Ausnahme fallen (Leitfaden, Seite 33 Rz 102).

4. Free and Open-Source Software (FOSS)

Open-Source-Software stellt den CRA vor ein Grundproblem. Die Verordnung knüpft ihre Pflichten an das Inverkehrbringen im Rahmen einer kommerziellen Tätigkeit. Ein Großteil quelloffener Software entsteht aber ohne jeden Verkaufsvorgang, sie wird veröffentlicht und nicht verkauft. Der Leitfaden arbeitet die Frage daher in drei Schritten ab und widmet ihr mit rund 14 Seiten einen der längsten Abschnitte (Leitfaden, Seiten 16 ff).

Der erste Schritt betrifft den Begriff. Als FOSS gilt nach Art 3 Z 48 CRA nur Software, die kumulativ zwei Bedingungen erfüllt: Sie steht unter einer freien und quelloffenen Lizenz, die sämtliche Rechte auf Zugang, Nutzung, Veränderung und Weiterverbreitung einräumt, und ihr Quellcode wird offen geteilt. Wird der Quellcode nur zahlenden Kund:innen oder einem begrenzten Kreis zugänglich gemacht, handelt es sich trotz freier Lizenz nicht um FOSS im Sinne des CRA (Leitfaden, Seite 17 Rz 44 ff).

Im zweiten Schritt ist zu klären, wer für die Software verantwortlich ist. Das ist, wer sie veröffentlicht und über Entwicklung, Releases und Verbreitung entscheidet, in der Praxis also die „Maintainer“ (zum Begriff: Leitfaden, Seite 18 Rz 49). Wer bloß Code beisteuert, bleibt Contributor und trifft keine CRA-Pflichten – auch dann nicht, wenn er über Commit-Rechte verfügt. Technische Berechtigungen allein begründen keine Verantwortlichkeit (Leitfaden, Seite 18 Rz 49, sowie ErwGr 18 CRA).

Der dritte Schritt ist die kommerzielle Tätigkeit. Wer für die Software selbst einen Preis verlangt, etwa für vorkompilierte Binaries, bringt sie in Verkehr und ist Hersteller (Leitfaden, Seite 18, Rz 51). Dasselbe gilt, wenn über die kostenlose Software andere Produkte oder Dienste monetarisiert werden, etwa über Werbung, Provisionen oder Abonnements, oder wenn die Nutzung an die Verarbeitung personenbezogener Daten zu anderen Zwecken als der Verbesserung von Sicherheit, Kompatibilität oder Interoperabilität geknüpft ist (Leitfaden, Seite 19 Rz 54).

• Bezahlte Support- und Beratungsleistungen rund um eine frei verfügbare Software machen diese für sich genommen nicht kommerziell. Entscheidend ist, ob der Zugang zur Software oder deren Wartung an eine Zahlung gebunden ist (Leitfaden Seite 20 Rz 55 ff). Bei Spenden geht der Leitfaden weiter, als es ErwGr 15 CRA nahelegt: Der bloße Spendenlink begründet keine Gewinnerzielungsabsicht, und zwar auch dann nicht, wenn die Einnahmen die Kosten von Konzeption, Entwicklung und Bereitstellung übersteigen. Eine ausschließlich über Spenden getragene FOSS wird daher regelmäßig nicht in Verkehr gebracht (Leitfaden, Seite 21 Rz 61).
• Anders liegt der Fall, wenn Downloads, aktuelle Versionen oder Sicherheitsupdates faktisch nur Spender:innen zur Verfügung stehen. Dann wirkt die Spende wie ein Preis (Leitfaden, Seiten 21 f, Rz 62 samt Bsp 21 & 22). Wer die Entwicklung finanziert, ändert an der Einstufung dagegen nichts: Sponsoring, Förderungen oder bezahlte Entwicklungsarbeit machen eine frei verfügbare FOSS nicht zum Marktprodukt (Leitfaden, Seite 22, Rz 63 ff). Auch gemeinnützige Organisationen, deren Überschüsse ausschließlich gemeinnützigen Zwecken dienen, bringen die von ihnen veröffentlichte FOSS nicht in Verkehr (Leitfaden, Seite 22, Rz 66).

Bemerkenswert ist die Behandlung von Doppelmodellen. Eine Community Edition bleibt ein eigenständiges, nicht monetarisiertes Produkt, auch wenn derselbe Anbieter eine kostenpflichtige Edition auf demselben Code aufsetzt oder ihn in ein größeres Produkt einbaut. Beurteilt wird produktbezogen und nicht anhand des Geschäftsmodells insgesamt (Leitfaden, Seite 19 Rz 52). Ist der Anbieter eine juristische Person, treffen ihn für die kostenlose Version allerdings die Pflichten eines Verwalters quelloffener Software (Leitfaden, Seite 19 Rz 53).

Für Projekte, die nicht in Verkehr gebracht werden, kennt der CRA eine eigene Rolle mit abgeschwächten Pflichten. Verwalter quelloffener Software („open-source software steward“, Art 3 Z 14 CRA) ist eine juristische Person, die FOSS dauerhaft trägt, ohne sie zu monetarisieren, etwa durch Hosting, Governance oder eigene Entwicklungsressourcen. Sie unterliegt nur den Pflichten des Art 24 CRA, und wie weit die Meldepflichten reichen, hängt nach Art 24 Abs 3 CRA von der Art der Unterstützung ab. Wer ausschließlich nicht-technisch unterstützt, etwa mit Branding, Governance-Regeln oder Community-Arbeit, trifft keine Meldepflicht. Wer die IT-Infrastruktur des Projekts bereitstellt, muss schwerwiegende Vorfälle in dieser Infrastruktur nach Art 14 Abs 3 CRA melden. Erst wer eigene Entwicklungsressourcen einbringt, etwa durch Release-Management oder die Bearbeitung von Schwachstellenmeldungen, muss auch aktiv ausgenutzte Schwachstellen nach Art 14 Abs 1 CRA melden (Leitfaden, Seiten 25 f, Rz 79 ff). Der typische Fall ist die Stiftung hinter einem großen Projekt.

Für Unternehmen, die quelloffene Komponenten lediglich einsetzen, bleibt die Lage überschaubar. Wer FOSS in sein eigenes Produkt integriert, wird dadurch nicht Hersteller der Komponente. Er bleibt aber für sein eigenes Produkt verantwortlich, schuldet die Sorgfalt nach Art 13 Abs 5 CRA und muss Schwachstellen in integrierten Komponenten melden sowie Sicherheitsfixes an das Projekt zurückspielen (Art 13 Abs 6 CRA; Leitfaden, Seite 26, Rz 86 ff).

5. Updates und wesentliche Änderungen

Software wird laufend weiterentwickelt. Der CRA muss daher beantworten, wann aus einem Update rechtlich ein neues Produkt wird. Der Begriff dafür ist die wesentliche Änderung nach Art 3 Z 30 CRA, also eine Änderung nach dem Inverkehrbringen, die entweder die Einhaltung der grundlegenden Anforderungen des Anhangs I Teil I berührt oder den bewerteten Verwendungszweck verändert.

Die Abgrenzung entscheidet über Aufwand, Zeitplan und Auslieferbarkeit. Ein wesentlich geändertes Produkt gilt als neu in Verkehr gebracht, mit neuer Konformitätsbewertung, aktualisierter technischer Dokumentation und neuer Konformitätserklärung. Wer ein fremdes Produkt wesentlich ändert und bereitstellt, wird selbst zum Hersteller (Art 21 und 22 CRA), und wer ein vor dem 11.12.2027 in Verkehr gebrachtes Produkt danach wesentlich ändert, ebenfalls (Art 69 Abs 2 CRA; Leitfaden, Seite 30, Rz 91).

Der Maßstab ist das Risiko und nicht der technische Umfang. Ein Sicherheitsupdate ist in aller Regel keine wesentliche Änderung, selbst wenn es tief in den Code eingreift (ErwGr 39 CRA; Leitfaden, Seite 36, Rz 108). Umgekehrt kann schon eine kleine Funktion genügen. Der Leitfaden nennt als Beispiel eine „Remember me“-Funktion, die Anmeldetoken lokal speichert: technisch unscheinbar, aber mit neuen Risiken für Tokendiebstahl und Session Hijacking und damit eine wesentliche Änderung (Leitfaden, Seite 35, Bsp 44).

Der Leitfaden nennt vier Fragen, an denen sich die Beurteilung ausrichten lässt (Leitfaden, Seite 37, Rz 110). Führt das Update neue Angriffsvektoren ein, etwa zusätzliche Schnittstellen, Kommunikationskanäle oder externe Abhängigkeiten? Ermöglicht es neue Angriffsszenarien? Verändert es die Wahrscheinlichkeit bereits bekannter Szenarien? Oder verändert es deren Auswirkungen? Lautet die Antwort durchgehend Nein und tragen die Annahmen der Risikobewertung weiter, liegt in aller Regel keine wesentliche Änderung vor.

Eine Erleichterung wird dabei häufig übersehen. Funktionen, die der Hersteller in seiner Risikobewertung bereits vorgesehen und bewertet hat, dürfen später freigeschaltet werden, ohne dass daraus eine wesentliche Änderung wird (Leitfaden, Seiten 34 f, Rz 106 samt Bsp 42 & 43). Wer geplante Roadmap-Funktionen früh in die Risikobewertung aufnimmt, erspart sich später Konformitätsarbeit.

Die Konsequenzen fallen verhältnismäßiger aus als im Entwurf. Führt der Originalhersteller die Änderung durch, bleibt er Hersteller, kann aber bestehende Tests und Unterlagen für unveränderte Aspekte weiterverwenden und die Konformitätsbewertung auf die geänderten Teile konzentrieren (Leitfaden, Seite 40 f). Modifiziert ein Dritter das Produkt wesentlich und stellt es bereit, treffen ihn nach Art 22 CRA die Herstellerpflichten grundsätzlich nur für den geänderten Teil, anders dann, wenn die Änderung die Cybersicherheit des Produkts insgesamt berührt (Leitfaden, Seite 39 f).

Damit entschärft die Kommission die im Entwurf angelegte Lesart, wonach eine wesentliche Änderung an einem vor Geltungsbeginn in Verkehr gebrachten Produkt stets das gesamte Produkt in die volle CRA-Compliance zwingt. Unberührt bleibt, dass das wesentlich geänderte Produkt als neu in Verkehr gebracht gilt.

Unabhängig von der Einstufung bleibt die Schwachstellenbehandlung nach Anhang I Teil II CRA bestehen, und Risikobewertung wie technische Dokumentation sind laufend aktuell zu halten (Art 13 Abs 7 und Art 31 Abs 2 CRA; Leitfaden, Seite 38, Rz 113).

Im Alltag lassen sich drei Fälle unterscheiden. Ein Bugfix oder Sicherheitsupdate ändert weder an der Konformitätsbewertung noch an der Support-Periode etwas. Ein neues Feature mit neuen Risiken ist eine wesentliche Änderung, löst die Bewertung aber nur für die geänderten Teile aus und startet die Support-Periode nicht automatisch neu. Ein Ersatzteil ohne geänderte cybersicherheitsrelevante Eigenschaften bleibt nach Art 2 Abs 6 CRA außerhalb des CRA, solange der Reparaturkontext nachweisbar ist.

6. Die Support-Periode: Neubewertung ja, Neustart nein

Die Support-Periode ist jener Zeitraum, in dem Sie Schwachstellen behandeln und Sicherheitsupdates bereitstellen müssen. Sie richtet sich nach der erwarteten Nutzungsdauer des Produkts und ist den Kund:innen beim Kauf bekanntzugeben (Art 13 Abs 8 CRA; Leitfaden, Seite 42 ff). Damit ist sie auch ein Vertriebs- und Kalkulationsthema und nicht nur eine technische Größe.

Eine wesentliche Änderung löst eine Neubewertung der Support-Periode aus, führt aber weder automatisch zu deren Neubeginn noch zu einer Verlängerung. Maßgeblich ist, ob die Änderung jene Faktoren berührt, die die erwartete Nutzungsdauer ursprünglich bestimmt haben. Bleiben sie gleich, läuft für das geänderte Produkt lediglich die verbleibende Zeit der ursprünglichen Periode weiter (Leitfaden, Seite 44 ff).

Zwei weitere Klarstellungen verdienen Beachtung. Die fünf Jahre sind eine Untergrenze und kein Regelwert, denn wo eine längere Nutzungsdauer zu erwarten ist, ist die Periode länger anzusetzen. Und bei iterativ entwickelter Software soll jede in Verkehr gebrachte Version eine eigene deklarierte Support-Periode haben. Art 13 Abs 10 CRA erlaubt es zwar, Schwachstellen nur in der jeweils aktuellen Version zu beheben, jedoch nur, wenn das Upgrade kostenlos und ohne zusätzliche Kosten möglich ist. Darunter fällt nach dem Leitfaden nicht, was über das bei Software-Updates Übliche hinausgeht, etwa erzwungene Hardware-Neuanschaffungen (Leitfaden, Seite 42 ff).

7. Kernfunktionalität und modulare Produkte

Die Einstufung als wichtiges oder kritisches Produkt (Art 7 und 8 iVm Anhang III und IV CRA) richtet sich nach der Kernfunktionalität des Produkts als Ganzem. Die technischen Beschreibungen der Kategorien finden sich in der Durchführungsverordnung (EU) 2025/2392. Von der Einstufung hängt der Weg zur Konformität ab. Standardprodukte dürfen intern bewertet werden, wichtige Produkte der Klasse I nur dann, wenn eine einschlägige harmonisierte Norm, eine gemeinsame Spezifikation oder ein europäisches Cybersicherheitszertifizierungsschema vollständig angewendet wird. Für Klasse II und für kritische Produkte ist eine externe Stelle einzubinden (Leitfaden, Seiten 47 ff und Seiten 52 ff).

Zusätzliche Funktionen, die die Kernfunktionalität lediglich ergänzen oder erweitern, ändern die Klassifizierung nicht. Auch die Integration einer höher eingestuften Komponente färbt nicht ab. Ein Smartphone, das ein Betriebssystem enthält, ist deshalb noch kein Betriebssystem. Für die Wahl des Konformitätsbewertungsverfahrens wird einem Produkt eine einzige Kernfunktionalität zugeordnet, die in der technischen Dokumentation zu benennen ist. Vorsicht ist bei modularen Plattformen geboten. Module mit eigener Funktionalität, die separat erworben, lizenziert oder abonniert werden können, sind eigenständige Produkte und gesondert zu klassifizieren (Leitfaden, Seiten 47 ff).

8. Meldepflichten: bereit für den 11.09.2026?

Ab dem 11.09.2026 greifen die Meldepflichten nach Art 14 CRA für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Gemeldet wird einmalig über die Single Reporting Platform der ENISA. Die Meldung geht gleichzeitig an jenes CSIRT, also an das zuständige nationale Computer-Notfallteam, das für den Ort der Hauptniederlassung als Koordinator benannt ist, und an die ENISA. Eine zusätzliche Meldung nach dem CRA ist daneben nicht vorgesehen. Meldepflichten aus anderen Rechtsakten, etwa nach dem NISG 2026 oder nach Art 33 DSGVO, bleiben davon unberührt (Leitfaden, Seiten 74 ff).

Der Zeitplan ist eng getaktet. Die Frühwarnung ist binnen 24 Stunden ab Kenntnis zu erstatten, weitere Informationen folgen binnen 72 Stunden, der Abschlussbericht bei Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme und bei Sicherheitsvorfällen binnen eines Monats (Art 14 Abs 2 bis 4 CRA).

Der Leitfaden präzisiert den Anwendungsbereich in mehrfacher Hinsicht. Die Pflichten erfassen auch Produkte, die vor dem 11.09.2026 in Verkehr gebracht wurden, und bestehen nach Ablauf der Support-Periode fort. Eine rückwirkende Meldung von Schwachstellen, die vor dem Stichtag bereits bekannt und ausgenutzt waren, verlangt der CRA nicht, wohl aber eine Meldung, wenn die Ausnutzung erst danach erfolgt oder bekannt wird (Leitfaden, Seiten 78 f). Bei Schwachstellen in Drittkomponenten besteht die Meldepflicht des Endprodukt-Herstellers nur, wenn die Schwachstelle in seinem Produkt aktiv ausgenutzt wird. Pflichten zur Schwachstellenbehandlung und zur Meldung an den Upstream-Anbieter bleiben davon unberührt (Art 13 Abs 6 CRA; Leitfaden, Seite 77). Die Information der Nutzer:innen nach Art 14 Abs 8 CRA hat risikobasiert und verhältnismäßig zu erfolgen. Eine ungefilterte Offenlegung technischer Details ist nicht verlangt, wo sie das Risiko erhöhen würde.

Vorbereiten lässt sich das mit wenigen Schritten. Ein EU-Login-Konto für die Registrierung einrichten, die Anleitungen der ENISA zu Registrierung und Meldung durcharbeiten, das zuständige CSIRT identifizieren und die interne Eskalation so aufsetzen, dass die 24-Stunden-Frist auch am Freitagabend hält. Wer erst im Ernstfall zum ersten Mal auf die Plattform zugreift, verliert genau jene Stunden, die die Frist ausmachen.

Fazit und nächste Schritte

Der Leitfaden ist mehr als ein redaktionelles Update. Er ist an den Realitäten moderner Softwareentwicklung und industrieller Systeme deutlich näher dran als der Entwurf aus dem Frühjahr 2026. Verbindlich ist er nicht. Wer von ihm abweicht, handelt nicht per se rechtswidrig, trägt aber die Argumentationslast gegenüber Marktüberwachungsbehörden und notifizierten Stellen. Hersteller sollten daher lokal ausgeführte Software und Webanwendungen neu abgrenzen, für Ersatzteile eine dokumentierte Äquivalenzprüfung der cybersicherheitsrelevanten Eigenschaften einführen, Support-Perioden je Version festlegen und den Prozess für wesentliche Änderungen schriftlich aufsetzen. Ansonsten bleibt es beim allgemeinen Appell: Prüfen Sie Ihre Lieferketten und Open-Source-Komponenten und bauen Sie belastbare Meldeprozesse für den 11.09.2026 auf.

Häufige bzw. relevante Fragen (FAQs)

Sind Sie auf den CRA vorbereitet?

ATB.LAW unterstützt Sie bei der Herstellung und Aufrechterhaltung von CRA-Compliance, prüft Ihre Verträge und steht Ihnen als Partner in allen Fragen des EU-Digitalrechts zu Seite. Kontaktieren Sie Stefan Knotzer und Roman Taudes jederzeit unter office@atb.law bzw. telefonisch unter 01 39 12345 für ein unverbindliches Erstgespräch.