Betrifft mich der CRA? Fünf Fragen zur Selbst-Einstufung

CRA-Journey, Teil 1 von 4 · Lesezeit ca. 9 Minuten

Wer Software verkauft, hat den Cyber Resilience Act (CRA) bisher oft als Thema für Gerätehersteller abgelegt. Router, Kameras, vernetztes Spielzeug. Die öffentliche Debatte hat das lange so nahegelegt.

Seit dem 11. September 2026 gilt Artikel 14 der Verordnung: die Meldepflichten der Hersteller. Spätestens bei der Frage, wer eigentlich melden muss, wird es konkret. Sind wir Hersteller? Ist unser Produkt überhaupt erfasst?

Beim ersten Lesen hatte ich selbst Router und Maschinensteuerungen vor Augen. Dann stieß ich in Anhang III auf Identitätsmanagementsysteme. Ich hielt kurz inne: Benutzerkonten, Berechtigungen, Zugriffsprozesse - da war ich plötzlich mitten in meinem eigenen Arbeitsgebiet. Welche unserer Lösungen müssten wir uns genauer ansehen?

Genau bei dieser Frage setzt dieser Beitrag an. Mit fünf Fragen können Sie für ein Produkt einschätzen, ob der CRA greift, welche Rolle Ihr Unternehmen hat und welche Produktklasse zu prüfen ist.

Die fünf Fragen auf einen Blick

Hier sind die Fragen vorab. Die Abschnitte darunter erklären jede einzeln, am Ende steht, wie Sie Ihre Antworten auswerten. Die Fragen ersetzen keine Rechtsberatung, zeigen aber schnell, wo Sie stehen.

Datenverbindung: Hat Ihr Produkt bestimmungsgemäß oder vorhersehbar eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz?
Geschäftstätigkeit: Stellen Sie es im Rahmen einer Geschäftstätigkeit bereit, auch wenn es kostenlos ist?
Ausnahme: Fällt es unter eine der gesetzlichen Ausnahmen, etwa für Medizinprodukte oder Fahrzeuge?
Dienst oder Produkt: Läuft Software beim Kunden, installiert, als Agent, Client oder App? Oder ist es ein reiner Dienst im Browser?
Rolle und Klasse: Sind Sie Hersteller, Importeur oder Händler? Und steht die Kernfunktion in Anhang III oder IV?

Frage 1, Datenverbindung: der Hebel, nicht die Branche

Der CRA ist die Verordnung (EU) 2024/2847. Er gilt für „Produkte mit digitalen Elementen“, die auf dem EU-Markt bereitgestellt werden. Voraussetzung: Ihre bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung umfasst eine direkte oder indirekte, logische oder physische Datenverbindung zu einem Gerät oder Netz (Art. 2 Abs. 1).

Ein Produkt mit digitalen Elementen ist dabei Software oder Hardware samt ihrer Datenfernverarbeitung. Dazu zählen auch Komponenten, die getrennt in Verkehr gebracht werden (Art. 3 Nr. 1).

Die Kommission hat im Juli 2026 Leitlinien zur Anwendung veröffentlicht (C(2026) 5252, nicht bindend). Dort heißt es sinngemäß: Der Anwendungsbereich hängt nicht an der bloßen Elektronik, sondern an der Fähigkeit, digitale Informationen auszutauschen.

Die Leitlinien ziehen auch die Untergrenze. Ein Ausgang, der nur ein- und ausschaltet, ist an und für sich noch keine Datenverbindung. Es braucht einen Sender, der Daten nach einem festen Schema codiert, und einen Empfänger, der sie lesen kann.

Meine Auslegung daraus: Auf einen Internetzugang kommt es nicht an. Was das für eine Steuerung im abgeschotteten Werksnetz heißt, zeigt Fall 1 weiter unten.

Frage 2, Geschäftstätigkeit: „Kostenlos“ ist keine Ausnahme

Bereitstellen auf dem Markt heißt laut Art. 3 Nr. 22: im Rahmen einer Geschäftstätigkeit liefern, „entgeltlich oder unentgeltlich“. Auch der Hersteller ist so definiert, gleich ob er für Bezahlung, zur Monetarisierung oder kostenlos vermarktet (Art. 3 Nr. 13).

Ob eine Geschäftstätigkeit vorliegt, ist laut Leitlinien eine Einzelfallfrage. Die Kommission nennt Kriterien wie einen Preis für die Software, Support-Entgelte über die reine Kostendeckung hinaus, die Monetarisierung anderer Dienste über die Software oder Spenden, die die Kosten übersteigen.

Ein Beispiel aus dem Alltag von Softwarehäusern: Sie geben ein Reporting-Werkzeug für das Active Directory kostenlos zum Download heraus und verkaufen dazu Support-Verträge. Ein Preis für die Software fehlt. Liegen die Support-Entgelte über der reinen Kostendeckung, ist aber eines der Kriterien erfüllt, die die Kommission für eine Geschäftstätigkeit nennt.

Freie Open-Source-Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird, ist weitgehend draußen. Wie sie entstanden oder finanziert ist, spielt dabei keine Rolle. Quelloffenen Code unter freier Lizenz in einem öffentlichen Repository zu teilen, ist für sich genommen in der Regel noch kein Inverkehrbringen.

Für sogenannte Open-Source-Verwalter (Steward) gelten eigene, leichtere Pflichten. Gemeint sind etwa Stiftungen, die Open-Source-Projekte dauerhaft unterstützen, die für den Einbau in kommerzielle Produkte gedacht sind, ohne sie selbst in Verkehr zu bringen (Art. 3 Nr. 14).

Frage 3, Ausnahmen: was ausdrücklich draußen ist

Einige Sektoren haben ihr eigenes Regelwerk und sind deshalb ausgenommen (Art. 2 Abs. 2 bis 4):

Medizinprodukte und In-vitro-Diagnostika (Verordnungen (EU) 2017/745 und 2017/746)
Fahrzeuge im Anwendungsbereich der Verordnung (EU) 2019/2144
nach Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte
Schiffsausrüstung nach Richtlinie 2014/90/EU

Außerdem nicht erfasst sind Ersatzteile, die identische Komponenten ersetzen, und Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt oder geändert wurden oder speziell für die Verarbeitung von Verschlusssachen ausgelegt sind (Art. 2 Abs. 6 und 7).

Weitere Ausnahmen kann die Kommission später per delegiertem Rechtsakt schaffen, wo andere EU-Vorschriften dieselben Risiken abdecken (Art. 2 Abs. 5). Darauf zu warten, lohnt nicht. Wer nicht in eine der genannten Gruppen fällt, sollte nicht mit einer Ausnahme rechnen.

Frage 4, Dienst oder Produkt: Software im Browser, Software beim Kunden

Für Softwarehäuser ist das die wichtigste Abgrenzung. Die Leitlinien sind hier deutlich.

Software fällt unter den CRA, wenn sie dem Nutzer bereitgestellt wird und auf seiner Seite läuft. Das gilt für installierte Programme, aber ausdrücklich auch für Browser-Erweiterungen und für Anwendungen, die mit Webtechnik gebaut, aber lokal installiert werden.

Software, die entfernt läuft und nur aufgerufen wird, ist dagegen für sich allein kein Produkt mit digitalen Elementen. Das Beispiel der Kommission: Eine Webanwendung, die ausschließlich im Browser genutzt wird, fällt nicht unter den CRA. Es sei denn, sie unterstützt die Funktion eines Produkts.

Damit ist der Begriff Datenfernverarbeitung im Spiel. Gemeint ist Verarbeitung aus der Ferne, die der Hersteller selbst entwickelt hat oder verantwortet und ohne die das Produkt eine seiner Funktionen nicht erfüllen kann (Art. 3 Nr. 2). Sie gehört dann zum Produkt.

Die Leitlinien nennen einen Industrieroboter, der Kamerabilder an einen Clouddienst des Herstellers schickt. Der Dienst berechnet die Position der Teile und steuert den Greifer. Ohne ihn greift der Roboter nicht, also gehört der Dienst zum Produkt.

Für ein Softwarehaus sieht derselbe Mechanismus so aus: Ein Zeiterfassungs-Client auf dem PC des Kunden ist Software beim Nutzer, also ein Produkt. Läuft die Auswertung ausschließlich in Ihrer Cloud und kann der Client ohne sie seine Funktion nicht erfüllen, gehört die Cloud als Datenfernverarbeitung dazu.

Für reine Clouddienste verweisen die Leitlinien auf Erwägungsgrund 12 des CRA: Cloud-Computing-Dienste fallen unter die NIS2-Richtlinie. Wer nur Software as a Service (SaaS) anbietet, landet also eher bei NIS2, sofern das Unternehmen deren Schwellen erreicht.

Mein Praxishinweis: Sobald zum Dienst ein Agent, ein Client oder eine App beim Kunden gehört, lohnt sich ein zweiter Blick. Dann wird aus dem Dienst unter Umständen die Datenfernverarbeitung eines Produkts.

Frage 5, Rolle: Wer ist Hersteller?

Die meisten Pflichten treffen den Hersteller. Das ist, wer ein Produkt entwickelt oder herstellt, oder entwickeln lässt, und es unter eigenem Namen oder eigener Marke vermarktet (Art. 3 Nr. 13).

Importeure sind in der EU ansässig und bringen Produkte mit dem Namen oder der Marke eines Anbieters außerhalb der EU auf den Markt (Art. 3 Nr. 16). Händler stellen sie bereit, ohne ihre Eigenschaften zu verändern (Art. 3 Nr. 17). Beide haben Prüf- und Sorgfaltspflichten.

Zwei Fälle machen aus Importeur oder Händler einen Hersteller mit den Pflichten aus Art. 13 und 14 (Art. 21):

Er bringt das Produkt unter eigenem Namen oder eigener Marke in Verkehr.
Er verändert ein bereits in Verkehr gebrachtes Produkt wesentlich.

Art. 22 erweitert das auf alle anderen: Wer ein Produkt wesentlich verändert und bereitstellt, gilt ebenfalls als Hersteller. Die Pflichten betreffen dann den veränderten Teil, oder das ganze Produkt, wenn die Änderung dessen Sicherheit insgesamt berührt.

Für die Praxis heißt das: Wer ein zugekauftes Produkt mit eigenem Logo ausliefert, übernimmt die Herstellerpflichten aus Art. 13 und 14.

Frage 5, Klasse: Die Klasse entscheidet, wer prüft

Praktisch gibt es vier Produktklassen: wichtig (Klasse I), wichtig (Klasse II), kritisch und alles andere. Die wichtigen Produkte stehen in Anhang III, die kritischen in Anhang IV. Was in keiner Liste steht, nenne ich hier Standardprodukt; der CRA selbst hat dafür keinen eigenen Begriff.

Warum die Klasse so wichtig ist: Sie bestimmt, ob Sie die Konformität selbst bewerten dürfen oder eine notifizierte Stelle brauchen. Das ist der größte Hebel für Kosten und Zeitplan (Art. 32).

Klasse	Konformitätsbewertung
Standard	Selbstbewertung möglich (interne Kontrolle, Modul A)
Wichtig, Klasse I	Modul A nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein EU-Zertifizierungsschema (mindestens Stufe „substanziell“) vollständig angewendet werden; sonst Prüfung durch Dritte (Module B und C oder H)
Wichtig, Klasse II	immer Prüfung durch Dritte (Module B und C oder H) oder EU-Zertifizierung mindestens Stufe „substanziell“
Kritisch	EU-Cybersicherheitszertifizierung, sobald die Kommission sie per delegiertem Rechtsakt vorschreibt (Art. 8 Abs. 1); bis dahin Verfahren wie Klasse II

Maßgeblich ist die Kernfunktion des Produkts (Art. 7 Abs. 1). Die Leitlinien stellen klar: Nebenfunktionen ändern die Kernfunktion nicht. Ein Produkt, das nebenbei ein Passwort speichert, ist also noch kein Passwortmanager.

Übertragen auf mein Feld, nach meiner Auslegung: Eine Warenwirtschaft mit eigener Benutzer- und Rollenverwaltung ist deshalb noch kein Identitätsmanagementsystem. Ihre Kernfunktion ist die Warenwirtschaft.

Eine Ausnahme gilt für freie Open-Source-Software in Anhang-III-Kategorien. Sie darf die Verfahren für Standardprodukte nutzen, wenn die technische Dokumentation beim Inverkehrbringen öffentlich ist (Art. 32 Abs. 5).

Kritisch sind laut Anhang IV nur drei Kategorien: Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways und andere Geräte für fortgeschrittene Sicherheitszwecke sowie Smartcards und ähnliche Geräte einschließlich Secure Elements. Alle drei sind Hardware. Für Softwarehäuser bleiben damit in aller Regel Standard und Anhang III.

Identitätsmanagement steht ganz oben

Für mich als jemand, der aus dem Identitäts- und Zugriffsmanagement kommt, war Anhang III der eigentliche Fund. An erster Stelle der Klasse I stehen Identitätsmanagementsysteme sowie Software und Hardware für die Verwaltung privilegierter Zugänge (Privileged Access Management, PAM). Ausdrücklich eingeschlossen sind Authentifizierungs- und Zugangskontrollleser, auch biometrische.

Was das für ein Produkt aus der Praxis heißt, zeigt Fall 4 weiter unten.

In derselben Klasse finden sich weitere Kategorien aus dem Sicherheitsumfeld, etwa Passwortmanager (Nr. 3), Systeme für Security Information and Event Management (SIEM, Nr. 7), Software für Public-Key-Infrastruktur und die Ausstellung digitaler Zertifikate (Nr. 9) sowie Betriebssysteme (Nr. 11).

Für Hersteller solcher Produkte gilt die Klasse-I-Zeile aus der Tabelle oben. Und die hat einen Haken: Die Regeln für notifizierte Stellen gelten seit dem 11. Juni 2026 (Kapitel IV, Art. 71 Abs. 2). Laut dem Portal cyberresilienceact.eu war in der Datenbank NANDO (New Approach Notified and Designated Organisations) der Kommission bis September 2026 noch keine für den CRA benannt.

Bis zur vollen Anwendung am 11. Dezember 2027 ist nicht mehr viel Zeit. Wer auf eine notifizierte Stelle angewiesen ist, sollte die Frage nach Normen oder Prüfstelle früh klären.

So werten Sie Ihre Antworten aus

Mit dem Wissen aus den Abschnitten oben lassen sich die fünf Fragen jetzt auswerten:

Datenverbindung: Nein: Der CRA greift nicht.
Geschäftstätigkeit: Nein: Der CRA greift nicht.
Ausnahme (Medizin, Fahrzeuge, Luftfahrt, Schiffsausrüstung, identische Ersatzteile, ausschließlich Verteidigung oder nationale Sicherheit): Ja: Der CRA greift nicht.
Dienst oder Produkt: Reiner Browser-Dienst, der nicht die Funktion eines Produkts unterstützt: für sich allein kein Produkt, eher NIS2 prüfen. Hängt Software beim Kunden von Ihrer Cloud ab, gehört der Cloud-Teil zum Produkt.
Rolle und Klasse: Bestimmt, wer die Pflichten trägt und wer die Konformität prüft. Durch eigene Marke oder wesentliche Änderung können Sie selbst zum Hersteller werden.

Wer bei 1 und 2 Ja sagt, bei 3 Nein und bei 4 Software beim Kunden hat, ist sehr wahrscheinlich im Anwendungsbereich. Frage 5 bestimmt, wer die Pflichten trägt und was die Konformität kostet.

Vier Fälle zum Üben

Fall 1: Ein Maschinenbauer verkauft eine Steuerung mit Weboberfläche, die nur im abgeschotteten Werksnetz läuft. Nach meiner Auslegung ja, CRA-relevant: Auch ein geschlossenes Netz ist ein Netz. Der Maschinenbauer ist Hersteller.

Fall 2: Ein Softwarehaus bietet sein Produkt für Identitäts- und Zugriffsmanagement (IAM) ausschließlich als SaaS an, ohne Agent oder Client beim Kunden. In der Regel nein. Liefert es aber einen Agenten aus, dessen Funktion von der Cloud abhängt, sieht es anders aus. Für den Dienst selbst ist eher NIS2 zu prüfen, sofern das Unternehmen deren Schwellen erreicht.

Fall 3: Zurück zum Router aus dem ersten Absatz. Ein Händler vertreibt einen Router aus Asien unter eigener Marke. Er wird zum Hersteller (Art. 21). Router stehen außerdem in Anhang III, Klasse I (Nr. 12).

Fall 4: Eine Lösung übernimmt Personaldaten aus dem HR-System und legt damit Benutzerkonten im Active Directory an, ändert oder deaktiviert sie. Im Projektgespräch heißt sie einfach „die Schnittstelle“. Sie läuft auf einem Server des Kunden, also beim Nutzer: Die Fragen 1 bis 4 sind schnell beantwortet. Bei Frage 5 wird es interessant. Ist ihre Kernfunktion der Datentransport oder die Verwaltung von Identitäten und Zugängen (Anhang III, Nr. 1)? Das entscheidet nicht der Name, sondern der Funktionsumfang. Den würde ich als Erstes auf den Tisch legen.

In einem meiner Projekte hieß eine solche Lösung IDM-Portal. Sie legte Konten an und ordnete sie den passenden Organisationseinheiten (OUs) im Active Directory zu. Aus dem HR-Datenexport übernahm sie die Personalnummer, wies Kostenstellen zu oder aktualisierte sie und pflegte den Manager-Eintrag. Wechselte jemand die Niederlassung, verschob sie das Konto in die neue OU. Austritte behandelte sie in mehreren Stufen, bis zur tatsächlichen Löschung nach einem festgelegten Zeitraum. Dazu kamen Reports, zum einen zur Protokollierung, zum anderen, um Folgeaktivitäten über ein Ticketsystem anzustoßen.

Das ist deutlich mehr als Datentransport. Genau deshalb lohnt sich bei Frage 5 der genaue Blick.

Fazit

Ob der CRA Sie betrifft, entscheidet nicht Ihre Branche, sondern eine Datenverbindung. Für einen Teil der Hersteller entscheidet die Kernfunktion zusätzlich, ob sie ihre Konformität noch selbst bescheinigen dürfen.

Router stehen in Anhang III. Identitätsmanagement steht dort aber noch davor, an erster Stelle. Und wer im Anwendungsbereich ist, hat seit September bereits eine Pflicht: die Meldung nach Art. 14.

Frage	Worauf es ankommt	Grundlage
1 Datenverbindung	direkte oder indirekte Verbindung zu Gerät oder Netz	Art. 2 Abs. 1
2 Geschäftstätigkeit	Bereitstellung entgeltlich oder unentgeltlich	Art. 3 Nr. 22
3 Ausnahme	Medizin, Fahrzeuge, Luftfahrt, Schiff, Ersatzteile, Verteidigung, Verschlusssachen	Art. 2 Abs. 2 bis 4, 6 und 7
4 Produkt oder Dienst	läuft beim Kunden oder ist notwendige Datenfernverarbeitung	Art. 3 Nr. 1 und 2, Leitlinien
5 Klasse und Rolle	Kernfunktion in Anhang III oder IV; eigene Marke oder wesentliche Änderung macht zum Hersteller	Art. 7, 8, 21, 22, 32

Im nächsten Teil

Betroffen. Aber was heißt „sicher“ laut Gesetz eigentlich konkret? Anhang I ist überraschend handfest, und ein Punkt darin ist klassisches Identitäts- und Zugriffsmanagement. Darum geht es in Teil 2.

Wenn Sie die Serie nicht verpassen wollen: Folgen Sie mir auf LinkedIn.

Betrifft mich der CRA überhaupt? Fünf Fragen zur Selbst-Einstufung