CRA-Leitlinien Juli 2026: Grenzfälle durchgerechnet

Ihr Verkaufsautomat hat eine SIM-Karte eingebaut. Dieses Mobilfunkmodem gehört zu einer Produktkategorie, die der CRA einer strengeren Konformitätsbewertung unterwirft. Der Automat selbst bleibt in der Standardkategorie.

Diese Lücke entscheidet, ob Sie die Bewertung selbst durchführen können oder dafür eine notifizierte Stelle bezahlen müssen. Die Konformitätserklärung unterschreiben Sie so oder so. Sie hängt an einem einzigen Satz, den die meisten Hersteller nie gelesen haben.

Die Europäische Kommission hat am 27. Juli 2026 Leitlinien zur Umsetzung des CRA veröffentlicht. Sie umfassen 84 Seiten mit 67 Praxisbeispielen. Dieser Beitrag behandelt fünf davon, die die Antwort in der Praxis ändern, jeweils mit einem durchgerechneten Fall.

Kein Kategoriewechsel der Maschine durch ein reguliertes Bauteil

Ihr Konformitätsbewertungsweg hängt von einer einzigen Sache ab: der Kernfunktionalität Ihres Produkts. Liegen Sie hier falsch, zahlen Sie entweder zu viel an eine notifizierte Stelle, oder Sie versenden ohne eine gesetzlich vorgeschriebene Bewertung.

Der CRA definiert den Begriff Kernfunktionalität nirgends. Die Leitlinien tun es.

Ein Verkaufsautomat, ein Mobilfunkmodem und 25.000 EUR

Dieses Szenario ist hypothetisch.

Sie bauen Verkaufsautomaten. Ihr Modell macht drei Dinge:

• Akzeptiert Kartenzahlungen
• Erfasst den Bestand über Gewichtssensoren
• Trägt ein Mobilfunkmodem, damit die Zentrale nachts Verkaufsdaten abrufen und Preisänderungen aufspielen kann

Router und Modems für die Internetverbindung gelten unter dem CRA als wichtige Produkte der Klasse I. Ihr Automat enthält eines davon.

Anhand der oben genannten Richtwerte und unter der Annahme, dass Ihnen das Verfahren der internen Kontrolle sonst nicht offengestanden hätte, ist diese eine Zeile für Sie etwa 25.000 EUR wert. Die tatsächlichen Bewertungskosten hängen von Produkt und Stelle ab. Auch Produkte der Klasse I können weiterhin selbst bewerten, wenn eine einschlägige harmonisierte Norm vollständig angewendet wird, allerdings knüpfen die Leitlinien daran eine zweite Bedingung, dazu weiter unten mehr.

Ihre verbleibenden Pflichten für das Modem

Das Modem verlässt die Klassifizierungsfrage. Ihre Pflichten verlässt es nicht.

• Risikobewertung: Das Modem ist eine eingebaute Komponente und gehört in Ihre Produktrisikobewertung, einschließlich der Schnittstellen, die es offenlegt, und der Datenflüsse, die es trägt.
• Sorgfaltspflicht: Sie müssen geeignete Maßnahmen ergreifen, um zu bestätigen, dass die Komponente die Compliance Ihres Produkts nicht untergräbt. Technische Dokumentation und Sicherheitsdokumentation des Zulieferers können als Nachweis dienen.
• Das Netz gehört nicht Ihnen: Das Mobilfunknetz, mit dem Ihr Modem sich verbindet, ist ein Kommunikationskanal, kein Teil Ihres Produkts. Gegenüber dem Mobilfunkbetreiber schulden Sie keine Sorgfaltsprüfung.

Hier die vollständige Aufteilung, denn Teams bekommen routinemäßig eine Hälfte richtig und die andere falsch.

Die letzte Zeile erwischt Integratoren. Ein zertifiziertes Modul zu kaufen und einzulöten, ist eine Lieferkettenfrage. Die Firmware zu schreiben, die darauf läuft, kann Sie zum Hersteller dessen machen, was Sie in Verkehr bringen. Ob das bis zum Modem selbst reicht, hängt davon ab, wie es geliefert wird und was Sie daran geändert haben.

Wie die Kategorien im Detail funktionieren, erklärt unser Leitfaden zur Produktklassifizierung. Zu Modems als eigenständigen Produkten siehe Router und Modems.

Zwei ungenannte Lücken zu Ihren Lasten

• Kernfunktionalität ist nur in den Leitlinien definiert: Die Verordnung selbst definiert den Begriff nirgends, der über Ihren Konformitätsweg entscheidet. Die Definition, mit der Sie arbeiten, ist die Lesart der Kommission, und sie bindet niemanden.
• Die Hürde für die Selbstbewertung hat still eine zweite Bedingung bekommen: Das Gesetz verlangt eine Bewertung durch Dritte für ein wichtiges Produkt der Klasse I, wenn der Hersteller die einschlägigen harmonisierten Normen nicht vollständig angewendet hat. Das ist ein Test. Die Leitlinien fügen einen zweiten hinzu: Der Geltungsbereich der Norm muss auch jedes Cybersicherheitsrisiko abdecken, das mit Ihrer Kernfunktionalität verbunden ist. Dieser zweite Test steht so im Gesetzestext nicht ausformuliert. Die Kommission leitet ihn daraus ab, wie anwendbare Anforderungen und Konformitätsvermutung zusammenwirken, und engt damit per Auslegung ein, wer selbst bewerten darf, nicht durch den Wortlaut des Gesetzes.

Neue Klassifizierung bei separatem Modulverkauf

Bieten Sie die Module einer Suite einzeln zum Kauf, zur Lizenzierung oder im Abonnement an, wird jedes zu einem eigenständigen Produkt. Jedes wird dann nach seiner eigenen Kernfunktionalität klassifiziert, nicht nach der der Suite.

Die Kommission rechnet das an einer in Teile zerlegten Sicherheits-Suite durch, und die Teile landen in unterschiedlichen Regimen.

Eine Zeile auf der Preisliste verschiebt ein Modul in ein strengeres Regime

Dieses Szenario ist hypothetisch.

Sie verkaufen proprietäre Software an Industriebetreiber. Sie macht vier Dinge:

• Sammelt Daten aus Produktionslinien
• Zeigt Dashboards
• Löst Alarme aus
• Enthält ein Intrusion-Detection-Modul für das OT-Netz

Als eine einzige Plattform verkauft, ist die Kernfunktionalität die Produktionsüberwachung. Das ist ein Produkt der Standardkategorie. Sie bewerten selbst, Sie unterschreiben die Erklärung, Sie versenden.

Dann verlangt der Vertrieb, das Intrusion-Detection-Modul einzeln anzubieten, weil drei Interessenten es ohne den Rest wollen. Sie fügen eine Zeile zur Preisliste hinzu.

Dieses Modul ist jetzt ein eigenständiges Produkt. Seine Kernfunktionalität ist die Angriffserkennung. Systeme zur Angriffserkennung und -abwehr fallen unter die wichtige Kategorie Klasse II.

Klasse II verlangt eine Konformitätsbewertung durch Dritte. Diese Anforderung ist nicht optional und nicht abhängig von Normen. Produkte, die als freie Open-Source-Software gelten, haben einen eigenen Weg.

Am Code hat sich nichts geändert. Eine kaufmännische Entscheidung hat ein Modul in ein strengeres Regime verschoben, und nach typischen Werten bedeutet das deutlich höhere Bewertungskosten und einen längeren Weg bis zur Freigabe.

Niemand hat definiert, was separat verfügbar bedeutet

Die Leitlinien nennen den separaten Kauf, die Lizenzierung und das Abonnement namentlich und schließen Module aus, die nur als Teil eines integrierten Produkts geliefert werden. Damit bleibt ein Fall wirklich offen. Vier Situationen, drei beantwortet:

• Eine eigene Artikelnummer auf einer Preisliste. Beantwortet. Der separate Kauf ist ausdrücklich genannt, dieser Fall ist also erfasst.
• Ein Feature-Flag, das Ihr Vertrieb unabhängig lizenzieren kann. Beantwortet. Lizenzierung und Abonnement stehen neben dem Kauf in der Liste, eine eigene Artikelnummer ist also nicht nötig.
• Ein Add-on, das nur an bestehende Plattformkunden verkauft wird. Offen. Sie können es nicht allein kaufen, aber getrennt vom Rest der Suite. Die Leitlinien erfassen diesen Fall nicht.
• Ein Modul, das technisch trennbar ist, aber nie allein angeboten wird. Beantwortet. Module, die nur als Teil eines integrierten Produkts geliefert werden, sind ausgeschlossen, die Klassifizierung bleibt auf Ebene des gesamten Produkts.

Der Test folgt also der kaufmännischen Realität und nicht der Verpackungsbezeichnung, ein lizenzierbares Feature-Flag zählt auch ohne eigene Artikelnummer. Offen bleibt der kundengebundene Add-on-Fall, und die Antwort dort entscheidet, was Sie zahlen.

Das wiegt mehr, als es aussieht. Produktmanager ändern die Paketierung jedes Quartal und denken dabei nie an ein regulatorisches Ereignis. Bauen Sie jetzt eine Prüfung in diese Entscheidung ein, denn die Alternative ist, es zu bemerken, nachdem einem Kunden bereits ein Angebot vorliegt.

Was jedes Modul bedeutet und was es kostet, zeigen unsere Konformitätsbewertungswege.

Unveränderter Supportzeitraum trotz großem Update

Eine wesentliche Änderung zwingt Sie, den Supportzeitraum neu zu bewerten. Sie setzt ihn nicht automatisch zurück. Sie verlängert ihn auch nicht automatisch.

Die Frage ist enger gefasst, als die meisten Teams annehmen. Hat die Änderung die Faktoren verändert, die die erwartete Nutzungsdauer ursprünglich festgelegt haben?

Die Kommission nennt zwei Fälle: eine Softwareänderung, die das ursprüngliche Enddatum bestehen lässt, und eine Hardwareänderung, die eine Neuberechnung erzwingt.

Derselbe Controller, zwei Änderungen, zwei unterschiedliche Antworten

Dieses Szenario ist hypothetisch.

Sie bringen 2028 eine speicherprogrammierbare Steuerung auf den Markt. Die erwartete Nutzungsdauer beträgt zwölf Jahre, basierend auf der Haltbarkeit der Hardware und dem, was Industriekunden von dieser Geräteklasse vernünftigerweise erwarten. Sie erklären einen Supportzeitraum bis 2040.

2031. Sie liefern eine Firmware mit Fernwartungsdiagnose aus. Nehmen Sie an, dass die neuen Schnittstellen und Datenflüsse verändern, wie das Produkt die grundlegenden Anforderungen erfüllt, sodass es nach diesem Sachverhalt als wesentliche Änderung zählt. Das löst eine neue Konformitätsbewertung und eine aktualisierte technische Dokumentation aus. Neue Schnittstellen allein würden das nicht entscheiden.

Das Supportdatum verschiebt sich nicht. Die Haltbarkeit der Hardware hat sich nicht geändert. Die Kundenerwartungen haben sich nicht geändert. Der Support endet weiterhin 2040, und dass zu einem späteren Zeitpunkt weniger als fünf Jahre verbleiben, verlängert ihn nicht.

2033. Sie ersetzen das Rechenmodul durch eine neuere Generation, die für eine längere Betriebsdauer ausgelegt ist, und vermarkten die Maschine auf dieser Grundlage. Jetzt haben sich die Faktoren geändert. Kunden können vernünftigerweise mehr Jahre Nutzung erwarten. Sie berechnen den Supportzeitraum nach oben neu.

Eine Verkürzung des Supportzeitraums bleibt ungeklärt

Die Leitlinien zeigen den Zeitraum unverändert und den Zeitraum verlängert. Die Regel selbst verlangt, anhand der Kriterien neu zu rechnen, wenn sich die maßgeblichen Faktoren ändern, ohne das Ergebnis auf eine Verlängerung zu beschränken.

Verengt eine Änderung die realistische Nutzungsdauer eines Produkts, etwa weil der Support für die zugrunde liegende Hardwareplattform endet, sagt kein durchgerechneter Fall, ob der erklärte Zeitraum entsprechend sinken darf. Wir würden einen bereits kommunizierten Zeitraum nicht verkürzen, aber die Leitlinien klären das nicht.

Mehr dazu, wie Sie den Zeitraum ursprünglich festlegen: Grundlagen zum Supportzeitraum.

Ein Ersatzteil kann seinen Status verlieren, wenn sich seine Sicherheitsmerkmale ändern

Ersatzteile, die identische Komponenten ersetzen, fallen nicht unter den CRA. Das entscheidende Wort ist „identisch", und die Leitlinien definieren es enger, als die meisten Obsoleszenzprozesse annehmen.

Identisch bemisst sich an der Funktionsrolle des Teils zusammen mit seinen cybersicherheitsrelevanten Merkmalen, und die Leitlinien verlangen dafür immer eine Einzelfallbewertung. Die Liste der Kommission nennt Algorithmen, Protokolle, kryptografische Mechanismen und Zugangskontrollfunktionen, und sie ist nicht abschließend.

Die Kommission stellt zwei Ersatzfälle am Lebensende gegenüber. Der eine ändert die kryptografische Implementierung und den Secure-Boot-Mechanismus und verliert die Ausnahme. Der andere ändert den Chipsatz, behält aber dieselben Protokolle und Sicherheitsmechanismen, und behält die Ausnahme.

Zwei Ersatzmodule, eines davon ein neues Produkt

Dieses Szenario ist hypothetisch.

Sie haben 2029 Zutrittskontrollpaneele auf einem Firmengelände installiert. 2033 erreicht das Funkmodul darin das Ende seiner Lebensdauer, und Ihr Lieferant bietet zwei Ersatzteile an.

Ersatzteil A. Anderer Chipsatz, anderer Hersteller, gleiche Funkprotokolle, gleiche Schlüsselspeicherung, gleiche Secure-Boot-Kette. Nach diesem Sachverhalt sollte es weiterhin als Ersatzteil gelten, außerhalb des CRA, versendet über Ihren Servicekanal.

Ersatzteil B. Gleiches Funkmodul, aber ein neueres Secure Element mit anderer Schlüsselhierarchie und anderer Boot-Verifizierungssequenz. Diese Unterschiede betreffen die cybersicherheitsrelevanten Merkmale, nach diesem Sachverhalt ist es also nicht identisch. Es wird zu einem eigenständigen Produkt mit digitalen Elementen, das eine eigene Konformitätsbewertung, eigene technische Dokumentation und eine CE-Kennzeichnung braucht.

Gleiche Teilenummer in Ihrer Stückliste. Gleicher physischer Formfaktor. Zwei völlig unterschiedliche Compliance-Ergebnisse.

Die Konsequenz, auf die niemand vorbereitet ist

Ihr Obsoleszenzprozess vergleicht mit ziemlicher Sicherheit Datenblätter. Pin-Kompatibilität, Spannung, Formfaktor, Temperaturbereich, HF-Leistung.

Nichts davon beantwortet die Frage, die der CRA stellt. Sie brauchen einen Vergleich der Sicherheitsmerkmale neben dem elektrischen Vergleich. Diese Felder muss er enthalten.

Secure Boot und Schlüsselspeicherung lohnt es sich, früh zu prüfen, weil sich eine Änderung bei beiden im Datenblattvergleich leicht übersehen lässt. Die Leitlinien setzen keine Rangfolge unter den Merkmalen, keines davon darf übersprungen werden.

Die meisten Teams haben dieses Dokument nicht. Es jetzt zu erstellen ist überschaubarer Aufwand, gemessen an einem blockierten Versand und einer Notfall-Konformitätsbewertung später.

Noch eine Bedingung, die viele übersieht: Technisch austauschbar zu sein reicht allein nicht aus. Der Reparaturzweck muss erkennbar sein, wie das Teil geliefert wird, etwa durch die Kennzeichnung des Produkts in der Bestellung oder im kommerziellen Angebot, oder durch die Lieferung über Nachverkaufskanäle. Eine Komponente, die als eigenständiges Allzweckprodukt verkauft wird, bekommt die Ausnahme nicht allein dadurch, dass sie zufällig passt.

Wie diese Kategorie behandelt wird, zeigen Zutrittskontrollleser und biometrische Terminals.

Die Liste der Sicherheitsmerkmale bleibt offen

Die Liste der sicherheitsrelevanten Merkmale ist offen. Ob eine Firmware-Versionsänderung in einem sonst identischen Modul mitzählt, wird nirgends behandelt.

Begrenzter Anwendungsbereich bei Änderungen an alten Produkten

Der CRA gilt vollständig ab dem 11. Dezember 2027. Ab dem 11. September 2026 wird die Meldepflicht auch Produkte erfassen, die davor auf den Markt gebracht wurden. Den Rest des Regelwerks übernehmen diese Produkte aber nur, wenn sie danach wesentlich verändert werden.

Die Sorge, die das auslöst, ist nachvollziehbar: Einmal an einer fünfzehn Jahre alten Maschine etwas ändern, und das gesamte Gerät muss auf einen Standard gebracht werden, der beim Entwurf noch gar nicht existierte.

So läuft es nicht. Nimmt der ursprüngliche Hersteller die Änderung vor, knüpfen die Pflichten am geänderten Teil an. Das gesamte Produkt ist nur betroffen, wenn die Änderung die Sicherheit des Produkts als Ganzes beeinträchtigt.

Pflichten für eine 2026er-Maschine nach der Änderung 2029

Dieses Szenario ist hypothetisch.

Sie haben 2026 eine industrielle Verpackungslinie mit zwanzig Jahren Nutzungsdauer ausgeliefert. 2029 veröffentlichen Sie eine Firmwareänderung am Etikettierungs-Subsystem, die eine Netzwerkschnittstelle für die Druckauftragsverwaltung hinzufügt. Das ist eine wesentliche Änderung.

Ihre Pflichten: Konformität für das Etikettierungs-Subsystem, eine aktuelle Risikobewertung dafür und aktualisierte technische Dokumentation für das Geänderte.

Nicht erforderlich: die Nachrüstung der Bewegungssteuerungen, der Sicherheitsverriegelungen oder des Bedienterminals. Und Sie müssen keine Entwicklungs- und Testunterlagen aus 2025 rekonstruieren, die in dieser Form nie existiert haben. Die Leitlinien sind hier eindeutig. Produkte, die vor Geltungsbeginn des CRA entworfen wurden, brauchen keine Neukonstruktion, wenn eine aktuelle Risikobewertung zeigt, dass die vorhandenen Maßnahmen die Risiken abdecken, und eine Rekonstruktion historischer Dokumentation würde das Produkt nicht sicherer machen.

Die Asymmetrie, die niemand erwähnt

Die enge Anwendung gilt für den ursprünglichen Hersteller und für einen unabhängigen Dritten, der die Änderung sowohl vornimmt als auch das geänderte Produkt auf den Markt bringt. Sie gilt nicht für Einführer und Händler, für die eine eigene Regel ohne diese Begrenzung gilt.

Lesen Sie diese Zeilen noch einmal. Ein Konstruktionsdienstleister, der eine Maschine ändert und auf den Markt bringt, bekommt den engen Anwendungsbereich, solange die Änderung die Cybersicherheit des gesamten Produkts unberührt lässt. Ein Einführer, der genau dieselbe Änderung vornimmt, bekommt den weiten. Die Handlung ist identisch. Das Risiko nicht.

Die Verordnung behandelt die beiden Fälle schon vom Wortlaut her unterschiedlich. In der Praxis heißt das: Einführer, die etwas ändern, tragen mehr als Dritte, die dasselbe tun.

Den vollständigen Zeitplan und was wann gilt, zeigt unser CRA-Umsetzungszeitplan.

Der entscheidende Ausdruck ist nirgends definiert

Die Erleichterung hängt davon ab, ob die Änderung „die Cybersicherheit des Produkts als Ganzes negativ beeinträchtigt". Dieser Ausdruck entscheidet, ob Sie ein Subsystem oder alle aktualisieren, und er ist nirgends definiert.

Rechnen Sie damit, dass genau über diesen Satz die Diskussion mit einer notifizierten Stelle geführt wird.

Wie das zum Entwurf vom März passt

Die Kommission führte zwischen dem 3. März und dem 13. April 2026 eine öffentliche Konsultation zu einem Entwurf dieser Leitlinien durch. Wir haben diesen Entwurf bereits behandelt, in was der Entwurf vom März 2026 bedeutet.

Das Juli-Dokument ist das Ergebnis dieser Konsultation. Es deckt den CRA nicht vollständig ab. Das sagt die Kommission ausdrücklich.

Laut Absatz 9 kann die Kommission weitere Leitlinien nach Artikel 26 erwägen. Als mögliche Themen nennt sie das Zusammenspiel des CRA mit dem AI Act und mit DORA. Das ist eine Möglichkeit, keine Zusage für eine weitere Veröffentlichung.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Fragen konsultieren Sie qualifizierte Rechtsberatung.