Sind bestimmte grundlegende Cybersicherheitsanforderungen auf ein Produkt mit digitalen Elementen nicht anwendbar, sollte der Hersteller dies in der Risikobewertung für die Cybersicherheit eindeutig begründen, die der technischen Dokumentation beigefügt ist. Dies könnte der Fall sein, wenn eine grundlegende Cybersicherheitsanforderung mit der Art eines Produkts mit digitalen Elementen unvereinbar ist. So kann es beispielsweise aufgrund der Zweckbestimmung eines Produkts mit digitalen Elementen erforderlich sein, dass der Hersteller weithin anerkannte Interoperabilitätsnormen befolgt, selbst wenn seine Sicherheitsmerkmale nicht mehr dem Stand der Technik entsprechen. Auch andere Rechtsvorschriften der Union verlangen, dass die Hersteller spezifischen Interoperabilitätsanforderungen genügen. Wenn eine grundlegende Cybersicherheitsanforderungen nicht für ein Produkt mit digitalen Elementen anwendbar ist, der Hersteller jedoch Cybersicherheitsrisiken im Zusammenhang mit dieser grundlegenden Cybersicherheitsanforderung ermittelt hat, sollte er Maßnahmen ergreifen, um diesen Risiken mit anderen Mitteln zu begegnen, beispielsweise indem er die Zweckbestimmung des Produkts auf vertrauenswürdige Umgebungen beschränkt oder die Nutzer über diese Risiken informiert.
Erwägungsgrund 55
Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026
Schnellantwort für Hersteller
Erwägungsgrund 55 erlaubt es Herstellern, bestimmte Anhang-I-Anforderungen als nicht anwendbar zu deklarieren — vorausgesetzt, dies wird in der Risikobewertung in der Technischen Dokumentation begründet. Beispiel: Ein Produkt ohne Authentifizierungsfunktion benötigt keine Authentifizierungs-Sicherheitsmaßnahme.
Diese Schnellantwort + FAQ ergänzen den Original-Rechtstext mit praxisorientierter Auslegung. Rechtsverbindlich ist allein der Originaltext.
Auslegung der EU-Kommission
Guidance vom 27. Juli 2026Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.
Abschnitt 2.6Komplexe Systeme und Interoperabilitäts-Constraints
Komplexe Systeme mit langen Entwicklungszyklen, Alt-Komponenten und Interoperabilitätszwängen sind nicht vom CRA ausgenommen — ihre Constraints fließen aber in den risikobasierten Ansatz ein. Wo einzelne wesentliche Anforderungen nicht oder nicht voll umsetzbar sind (vgl. Erwägungsgrund 55), müssen Hersteller die Constraints dokumentieren, die Risiken bewerten und kompensierende Maßnahmen treffen.
Kernaussagen
- Ein unsicheres Legacy-Protokoll darf implementiert werden, wenn es für Interoperabilität nötig ist und die Risiken anderweitig mitigiert werden; unterstützt das Produkt beide Protokolle, muss das sichere der Default sein (Beispiel 10).
- Constraints, Risiken und Mitigationen gehören transparent in die technische Dokumentation (Art. 31, Anhang VII) und die Nutzerinformationen (Anhang II).
- Constraints sind während des Supportzeitraums regelmäßig neu zu bewerten; entfallen sie, muss das Produkt entsprechend nachgezogen werden.
- Vor CRA-Geltung beschaffte Komponenten dürfen integriert werden, wenn die Risikobewertung keine spezifischen Risiken ergibt und das Gesamtprodukt die Anforderungen erfüllt (Beispiel 11).
Für die Praxis
Legen Sie für jede nicht (voll) erfüllbare Anforderung ein Constraint-Dossier an: Warum nicht umsetzbar (z. B. Interoperabilitätszwang), welches Risiko entsteht, welche Kompensationsmaßnahme greift — und terminieren Sie die Neubewertung. Genau diese Dokumentation wird die Marktüberwachung sehen wollen.
EU-Kommissions-Guidance (C(2026) 5252 final) — Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.
Häufige Hersteller-Fragen
Kann ich Anhang-I-Anforderungen einfach ignorieren?
Nein. „Nicht anwendbar“ ist nur zulässig, wenn die Anforderung der Funktion des Produkts widerspricht oder dem Schutzziel des Produkts nicht dient. Die Begründung muss in der Risikobewertung dokumentiert sein.
Wer prüft die Nicht-Anwendbarkeits-Begründung?
Bei Selbstbewertung der Hersteller selbst — mit Risiko bei Marktüberwachungs-Audit. Bei notifizierter-Stelle-Verfahren prüft diese die Begründung mit. Eine schwache Begründung ist ein Compliance-Risiko.
Beispiel für eine zulässige Nicht-Anwendbarkeit?
Ein Sensor ohne Authentifizierungsfunktion, der nur Daten an die Steuerung sendet, braucht keine Anhang-I-Authentifizierungsanforderung umzusetzen. Aber: Die Risikobewertung muss erklären, dass keine sensiblen Daten gehandhabt werden und kein Manipulationsrisiko besteht.
Verwandte Artikel
(1)Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex