Von Redaktion codAIx | April 2026

**Die meisten Diskussionen über den Cyber Resilience Act (CRA) behandeln die Frage binär: Ist mein Produkt CRA-pflichtig oder nicht? Diese Vereinfachung übersieht eine entscheidende Realität der Verordnung — und kostet Hersteller teure Compliance-Fehler.**

Der im vorherigen Artikel beschriebene Drei-Elemente-Test (das RDPS-Klassifikationsverfahren) produziert drei verschiedene Pflichtniveaus. Teil 2 konzentriert sich auf das vollständige RDPS-Szenario. Dieser Artikel behandelt die beiden schnell übersehenen Kategorien: Hersteller, deren Produkte Komponenten von Drittanbietern integrieren (Stufe B), und jene, die nur dem Risikobewertungs-Minimum unterliegen (Stufe C).

Das ist der Punkt, an dem viele Hersteller scheitern. Sie interpretieren „Keine RDPS" als „Keine Compliance-Pflicht" — und landen dann mit unvollständiger Dokumentation und fehlender Supplier-Verifizierung vor einem CRA-Audit.

Die drei Pflichtniveaus des CRA

Der RDPS-Test aus Teil 2 klassifiziert jede relevante Netzwerkkomponente eines Produkts in eine von drei Kategorien (Rn. 186 der Draft Communication):

| Stufe | Kriterium | Pflicht | Beispiele | |-----------|--------------|-----------|-------------| | A: RDPS | Datenfernverarbeitungslösung — serverseitige Datenverarbeitung, deren Wegfall eine Produktfunktion verhindert (Element 2) und die vom Hersteller entworfen/entwickelt wurde oder unter seiner Verantwortung steht (Element 3); Verarbeitung auf Distanz (Element 1) als Vorbedingung (Art. 3 Nr. 2 CRA) | Vollständige CRA-Compliance: SBOM, Anhang-I-Bewertung, Konformitätsbewertung, Vulnerability Management | z. B. Smart-Thermostat mit Hersteller-App und -Cloud-Backend | | B: Komponente | Funktional notwendig für eine Produktfunktion (Element 2 erfüllt), aber nicht vom Hersteller entwickelt (Element 3 verneint) | Risikobewertung (Art. 13 Abs. 2) und Due Diligence (Art. 13 Abs. 5): Komponenten-Risiken in die Produkt-Risikobewertung einbeziehen und verifizieren, dass Drittanbieter die CRA-Anforderungen erfüllen | z. B. E-Reader mit Cloud-Speicher oder SaaS-Zahlungsgateway | | C: Weder RDPS noch Komponente | Nicht funktionsnotwendig — Element 2 verneint: Die Datenverbindung dient keiner Produktfunktion. Ob sie vom Hersteller entwickelt wurde (Element 3), siehe auch Teil 2, ist hier unerheblich. Typischerweise reine Telemetrie- oder Statistikverbindung | Art. 13 Abs. 2 Mindestpflicht: Risikoanalyse und produktseitige Mitigationen | z. B. herstellereigene Telemetrie für anonyme Nutzungsstatistik (Element 2 verneint, Element 3 bejaht) |

Der zentrale Punkt: Der CRA ist nicht binär. Auch Hersteller in Stufe B und C haben echte, dokumentierbare Pflichten. Nicht einzuhalten kann einen Verstoss gegen die Verordnung darstellen — mit den in Art. 64 CRA vorgesehenen Sanktionen.

Was bei Nichteinhalten droht

Die Konsequenzen sind für alle drei Stufen identisch geregelt. Art. 64 CRA etabliert eine dreistufige Bussgeldstruktur [1]:

Höchste Stufe (Art. 64 Abs. 2 CRA): Verstösse gegen die grundlegenden Cybersicherheitsanforderungen in Anhang I sowie gegen die Herstellerpflichten nach Art. 13 und Art. 14 — bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist.

Mittlere Stufe (Art. 64 Abs. 3 CRA): Verstösse gegen ausgewählte Pflichten von Wirtschaftsakteuren und Konformitätsbewertungsstellen — der Katalog des Art. 64 Abs. 3 CRA umfasst die Pflichten aus Art. 18–23, Art. 28, Art. 30 Abs. 1–4, Art. 31 Abs. 1–4, Art. 32 Abs. 1–3, Art. 33 Abs. 5 sowie Art. 39, 41, 47, 49 und 53 CRA — bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes.

Unterste Stufe (Art. 64 Abs. 4 CRA): Unrichtige, unvollständige oder irreführende Angaben gegenüber notifizierten Stellen oder Marktüberwachungsbehörden auf Auskunftsverlangen — bis zu 5 Millionen Euro oder 1 % des weltweiten Jahresumsatzes.

Das entscheidende Detail: Art. 13 steht in der höchsten Bussgeldstufe. Das umfasst sowohl die Risikobewertungspflicht nach Art. 13 Abs. 2 (relevant für Stufe C) als auch die Due-Diligence-Pflicht nach Art. 13 Abs. 5 (relevant für Stufe B). Ein Hersteller, der seine Drittanbieter-Komponenten nicht verifiziert (bei Kategorie B) oder keine Risikobewertung für nicht-funktionale Datenverbindungen durchführt (bei Kategorie C), riskiert dieselben Maximalbussgelder wie ein Hersteller, der eine vollständige RDPS-Compliance ignoriert.

Bemessungsgrundlage „weltweiter Jahresumsatz": Nach der EuGH-Rechtsprechung zu Art. 101/102 AEUV bezieht sich der Begriff auf die wirtschaftliche Einheit — typischerweise also den Konzernumsatz, nicht den Umsatz der einzelnen rechtlich selbständigen Tochtergesellschaft [4, § 7 Rn. 57]. Im deutschen Ordnungswidrigkeiten­recht wirkt der Grundsatz „in dubio pro reo" als Korrektiv: Die Konzernzurechnung ist hier nur ein widerlegbarer Erfahrungssatz [4, § 7 Rn. 57 in der Fussnote]. Für Hersteller mit Konzernstruktur bedeutet das: Die maximale Bussgeldhöhe kann auch bei kleinen Tochter­gesellschaften am Konzernumsatz der Muttergesellschaft gemessen werden.

Hinzu kommen operative Konsequenzen: Marktüberwachungsbehörden können nach Art. 52 ff. CRA i. V. m. VO (EU) 2019/1020 Korrekturmassnahmen anordnen, Produkte vom Markt nehmen oder deren Bereitstellung untersagen. Im Extremfall bedeutet das: Verkaufsstopp in der gesamten EU.

Stufe A — Volle RDPS-Compliance

Zum Kontextverständnis ein kurzer Überblick (Detailbehandlung siehe Teil 2 dieser Serie):

Eine Datenfernverarbeitungslösung (RDPS) liegt vor, wenn die entscheidenden Elemente des Drei-Elemente-Tests erfüllt sind (Art. 3 Nr. 2 CRA): Das Fehlen der Datenverarbeitung würde verhindern, dass das Produkt eine seiner Funktionen ausführt (Element 2 — Funktionsnotwendigkeit), und die serverseitige Software wurde vom Hersteller des Produkts entworfen und entwickelt oder steht unter seiner Verantwortung (Element 3 — Herstellerverantwortung). Die Verarbeitung auf Distanz (Element 1) ist dabei Vorbedingung. Entscheidend ist nicht die Art der verarbeiteten Daten, sondern die funktionale Abhängigkeit und die Herstellerverantwortlichkeit. Die klassischen Beispiele sind herstellereigene Cloud-Backends für Synchronisierung, Steuerung oder KI-basierte Funktionen.

Pflichten:

  • Software Bill of Materials (SBOM) nach Anhang I Teil II Nr. 1
  • Konformitätsbewertung nach Art. 32 CRA
  • Vulnerability Management für das gesamte System (Produkt + Server)
  • Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle nach Art. 14 CRA über die zentrale Meldeplattform nach Art. 16 CRA

Diese Stufe ist eng, aber klar definiert. Wer hier nicht passt, ist nicht automatisch compliance-frei.

Stufe B — Die Komponentenpflicht (Art. 13 Abs. 5)

Dies ist das Herzstück dieses Artikels. Hier sitzen viele Hersteller — und wissen es häufig nicht.

Was Art. 13 Abs. 5 CRA verlangt

Kurz gefasst: Art. 13 Abs. 5 CRA verpflichtet den Hersteller, zugekaufte Drittkomponenten vor der Integration auf ihre CRA-Tauglichkeit zu prüfen — als eigene Pflicht, nicht als blosse Weitergabe an den Zulieferer. Die nachfolgend zitierten Randnummern der Draft Communication (Rn. 151 sowie 154–156) buchstabieren diese Due-Diligence-Pflicht gemeinsam aus.

Art. 13 Abs. 5 CRA besagt, dass der Hersteller „angemessene Massnahmen" ergreifen muss, um sicherzustellen, dass in sein Produkt integrierte Komponenten Dritter die CRA-Anforderungen erfüllen. Dies ist nicht optional. Es ist eine direkte Pflicht des Herstellers, nicht eine Pass-Through-Verpflichtung.

Die Draft Communication konkretisiert das in Rn. 151–157:

Rn. 151: Der Hersteller hat zwei voneinander unterschiedliche Verpflichtungen:

  1. Eine Risikobewertung gemäss Art. 13 Abs. 2 für alle Komponenten (einschliesslich Drittanbieter-Komponenten)
  2. Für Komponenten, die funktional notwendig sind: eine spezifische Due-Diligence zur Überprüfung, dass der Drittanbieter die Sicherheitsanforderungen erfüllt

Rn. 154: Der Hersteller muss „angemessene Vorkehrungen treffen", um zu überprüfen, dass die Drittkomponente die CRA-Konformität des Gesamtprodukts nicht gefährdet. „Angemessen" heisst nicht „perfekt", aber es heisst auch nicht „vertraue dem Verkaufsversprechen".

Rn. 155: Welche Evidenz ist ausreichend?

  • Technische Spezifikationen des Drittanbieters
  • Sicherheitsdokumentation
  • Konformitäts- oder Sicherheitszertifikate (ISO 27001, SOC 2, etc.)
  • Funktionale Tests durch den Hersteller
  • Evaluierung des Sicherheitsstands des Drittanbieters

Rn. 156: Die Due Diligence muss auch externe Faktoren berücksichtigen: Auf welchen Infrastrukturen läuft der Dienst? Welche Netzwerk-Abhängigkeiten entstehen? (Beispiel: Ein cloudbasierter Service hinter einem CDN mit unbekannter Sicherheitspraxis.)

Die zweite Meldekette: Art. 13 Abs. 6 CRA — Hersteller an Lieferant

Neben der bekannten Meldepflicht nach Art. 14 CRA gegenüber Behörden (B2A) etabliert Art. 13 Abs. 6 CRA eine eigenständige B2B-Meldepflicht: Wer in einer integrierten Drittanbieter-Komponente eine Schwachstelle feststellt, muss diese dem Hersteller der Komponente melden [4, § 6 Rn. 20]. Ein blosser Verdacht löst die Meldepflicht allerdings noch nicht aus; bei einem begründeten Verdacht muss der Hersteller zunächst nähere Untersuchungen und Tests vornehmen, um dem Verdacht auf den Grund zu gehen — gemeldet wird die so bestätigte Schwachstelle [4, § 6 Rn. 20].

Konsequenz für die Praxis: Hersteller benötigen zwei parallele Meldeprozesse:

  1. B2A (an Behörden, Art. 14 CRA über die Plattform nach Art. 16 CRA): Bei aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen
  2. B2B (an den Komponentenhersteller, Art. 13 Abs. 6 CRA): Bei festgestellter Schwachstelle in der gelieferten Komponente — ein begründeter Verdacht löst zunächst die Pflicht zu näheren Untersuchungen und Tests aus

Diese Meldekette ist in der Drittanbieter-Inventur (siehe unten) als eigenständiger Workflow zu führen — die Meldewege, Ansprechpartner und Reaktionszeiten gehören in die Vertragsdokumentation.

Mindest-Unterstützungszeitraum und Aufbewahrungsfristen — drei Fristen, die zu unterscheiden sind

Art. 13 CRA enthält drei Zeit-Pflichten, die in der Praxis häufig verwechselt werden. Hersteller müssen sie alle drei sauber dokumentieren — sie greifen ineinander, aber sie sind nicht identisch.

1. Mindest-Unterstützungszeitraum (Art. 13 Abs. 8 CRA) — typischerweise 5 Jahre. Art. 13 Abs. 8 CRA verpflichtet den Hersteller, Sicherheitsupdates über einen bestimmten Zeitraum bereitzustellen — regelmässig mindestens fünf Jahre nach Inverkehrbringen [4, § 6 Rn. 25–27]. Eine Verkürzung ist nur ausnahmsweise möglich, wenn die voraussichtliche Nutzungsdauer des Produkts nachweislich kürzer ist (Art. 13 Abs. 8 UAbs. 3 S. 2 CRA). Erwägungsgrund 60 CRA nennt umgekehrt typische Produkte mit längerer Lebensdauer — neben Hardware (Hauptplatinen, Mikroprozessoren, Router, Modems, Switches) auch Softwareprodukte wie Betriebssysteme und Videobearbeitungstools; daneben nennt Erwägungsgrund 60 Produkte für die Verwendung in industriellen Umgebungen wie industrielle Steuerungssysteme [4, § 6 Rn. 27].

2. Verfügbarkeit von Sicherheitsupdates (Art. 13 Abs. 9 CRA) — mindestens 10 Jahre. Davon zu unterscheiden ist eine eigenständige Frist: Eine einmal bereitgestellte Sicherheitsaktualisierung muss danach für mindestens 10 Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben — je nachdem, welcher Zeitraum länger ist [4, § 6 Rn. 35]. Operativ heisst das: Ein Update-Repository, das nach Ablauf des 5-Jahres-Unterstützungszeitraums gelöscht würde, wäre ein eigenständiger CRA-Verstoss.

3. Aufbewahrung der technischen Dokumentation (Art. 13 Abs. 13 CRA) — mindestens 10 Jahre. Schliesslich verpflichtet Art. 13 Abs. 13 CRA den Hersteller, die technische Dokumentation und die EU-Konformitätserklärung mindestens 10 Jahre nach dem Inverkehrbringen des Produkts bzw. für die Dauer des Unterstützungszeitraums (je nachdem, was länger ist) für die Marktüberwachungsbehörden bereitzuhalten. Da Komponenten-Bezüge, Sorgfaltsnachweise, Lieferantenkommunikation und die SBOM (vgl. Artikel 07) zu dieser technischen Dokumentation gehören, müssen sie über den vollen 10-Jahres-Horizont reproduzierbar bleiben — auch dann, wenn der eigene Unterstützungszeitraum nach 5 Jahren ausläuft.

Vertraglicher Gleichlauf mit Zulieferern: Der Hersteller muss sicherstellen, dass die für seinen Unterstützungszeitraum relevanten Drittanbieter-Komponenten ebenfalls über diesen Zeitraum mit Sicherheitsupdates versorgt werden — sonst kann er seine eigene Pflicht aus Art. 13 Abs. 8 CRA nicht erfüllen [4, § 6 Rn. 27 a. E.]. Wo ein Individualvertrag mit dem Zulieferer möglich ist, sollte der zugesicherte Support-Zeitraum daher mindestens dem eigenen Mindest-Unterstützungszeitraum entsprechen. Bei Komponenten, die nur über Standard-AGB oder als Open-Source-Software bezogen werden und sich vertraglich nicht verhandeln lassen, muss der Hersteller den Gleichlauf anders absichern — durch die Auswahl ausreichend langfristig gepflegter Komponenten, laufendes Monitoring, produktseitige Mitigationen und gegebenenfalls eine Exit-Strategie — und dies dokumentieren.

Verwalter quelloffener Software (Art. 24 CRA)

Eine Sonderkategorie ist relevant, wenn das Produkt auf Open-Source-Komponenten setzt: der „Verwalter quelloffener Software" (Open-Source Software Steward). Art. 3 Nr. 14 CRA definiert ihn als eine juristische Person, bei der es sich nicht um einen Hersteller handelt, die den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen — die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind — systematisch und nachhaltig zu unterstützen, und die die Brauchbarkeit dieser Produkte sicherstellt. Erwägungsgrund 19 CRA nennt als typische Beispiele bestimmte Stiftungen sowie Einrichtungen — auch gemeinnützige —, die freie und quelloffene Software im wirtschaftlichen Kontext entwickeln und veröffentlichen.

Für diese Kategorie gilt nach Art. 24 CRA eine vereinfachte, massgeschneiderte Regelung: Der Verwalter unterliegt nicht den vollen Hersteller-Pflichten [4, § 4 Rn. 38]. Er muss aber auf überprüfbare Weise eine Cybersicherheitsstrategie entwickeln und dokumentieren (Art. 24 Abs. 1 CRA), auf Verlangen mit den Marktüberwachungsbehörden zusammenarbeiten (Art. 24 Abs. 2 CRA) und unterliegt den Meldepflichten nach Art. 14 CRA, soweit er an der Entwicklung beteiligt ist (Art. 24 Abs. 3 CRA); die CE-Kennzeichnung darf er nicht anbringen (Erwägungsgrund 19 CRA).

Für die Drittanbieter-Inventur eines Herstellers heisst das: Open-Source-Komponenten, die nicht von einem klassischen Hersteller, sondern von einem solchen Verwalter stammen, sind separat zu kategorisieren — die eigene Due-Diligence-Pflicht des Herstellers bleibt davon unberührt.

Praktische Beispiele

1. E-Reader mit Cloud-Speicher (Abschnitt 8.3.3 der Draft Communication)

Ein Hersteller bringt einen E-Reader auf den Markt — ein Hardwareprodukt und damit von sich aus ein Produkt mit digitalen Elementen (Art. 3 Nr. 1 CRA); eine gesonderte lokale Softwarekomponente ist nicht erforderlich, das Gerät selbst ist der Anknüpfungspunkt. Der E-Reader bietet ein optionales Cloud-Backup über einen externen Speicherdienst, der nicht vom E-Reader-Hersteller entwickelt wurde.

  • Element 1 (Distanz): erfüllt — der Speicherdienst läuft auf den Servern des SaaS-Anbieters, ausserhalb der Umgebung des Nutzers.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den Speicherdienst kann der E-Reader das Backup-Feature nicht ausführen. Dass dieses Feature optional ist, ändert daran nichts: Der CRA-Funktionsbegriff erfasst auch Zusatzfunktionen.
  • Element 3 (Herstellerverantwortung): verneint — der Speicherdienst ist eine Standard-SaaS eines Drittanbieters, nicht vom E-Reader-Hersteller entworfen und entwickelt.

Klassifikation: Element 2 erfüllt, Element 3 verneint → Komponente (Stufe B), keine RDPS.

Due-Diligence-Anforderungen:

  • Sicherheitsdokumentation des Cloud-Anbieters einsehen.
  • Verifizieren, dass der Anbieter eine angemessene Verschlüsselung und Zugriffskontrolle bietet.
  • Das Ergebnis in der Produktrisikobewertung dokumentieren.

Produktseitige Mitigationen:

  • Verschlüsselung der Daten vor der Übertragung an den Speicherdienst.
  • Im Produkthandbuch offenlegen, dass der Backup-Service extern ist und unter der Verantwortung des Anbieters liegt.

2. Zahlungsgateway als SaaS-Integration

Ein Hersteller liefert seinen Händlern eine lokal installierte Kassen- und Bestell-App (Desktop oder Mobile) aus — eine lokale Komponente und damit ein Produkt mit digitalen Elementen. Für die Zahlungsabwicklung bindet die App einen Payment Service Provider (PSP) ein — etwa Stripe oder Square.

  • Element 1 (Distanz): erfüllt — der PSP wickelt die Zahlungen auf seiner eigenen Infrastruktur ab, ausserhalb der Umgebung des Nutzers.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den PSP kann die App ihre Kernfunktion, die Zahlungsabwicklung, nicht ausführen.
  • Element 3 (Herstellerverantwortung): verneint — Stripe bzw. Square sind Standard-Drittanbieterdienste, nicht vom App-Hersteller entworfen und entwickelt.

Klassifikation: Komponente (Stufe B).

Due-Diligence-Anforderungen:

  • Einsicht in die Sicherheitsdokumentation des PSP (etablierte PSP wie Stripe oder Square veröffentlichen Security-Whitepapers).
  • Überprüfung: Verfügt der PSP über ein ISO-27001-Zertifikat oder einen SOC-2-Report? Ist er DSGVO-konform?

Produktseitige Mitigationen:

  • Token-basierte Zahlungsverarbeitung (kein direkter Kartenzugriff im Produkt).
  • TLS 1.2+ für die Integration; Integritätsprüfung der API-Anfragen.

3. KI-API eines Drittanbieters, integriert in ein Produkt

Ein Hersteller bietet ein Produktivitäts-Tool mit lokal installierter Desktop-App an — eine lokale Komponente und damit ein Produkt mit digitalen Elementen. Die App nutzt für ihre Textgenerierungs-Funktion eine KI-API eines Drittanbieters, etwa von OpenAI oder Anthropic.

  • Element 1 (Distanz): erfüllt — die KI-API verarbeitet die Anfragen auf der Infrastruktur des API-Anbieters.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die KI-API kann die App ihre Textgenerierungs-Funktion nicht ausführen.
  • Element 3 (Herstellerverantwortung): verneint — die KI-API wurde nicht vom App-Hersteller entworfen und entwickelt; OpenAI bzw. Anthropic stellen sie als Standardprodukt bereit.

Klassifikation: Komponente (Stufe B). Massgeblich ist Element 3: Die API-Software wurde nicht vom Produkt-Hersteller entworfen und entwickelt — damit ist sie eindeutig keine RDPS, sondern eine Drittanbieter-Komponente. Dass dabei Nutzerdaten an den API-Anbieter übermittelt werden, ändert daran nichts; entscheidend ist allein, wer die Software entwickelt hat, nicht der Datenfluss.

Due-Diligence-Anforderungen:

  • Sicherheitsdokumentation des API-Anbieters einholen.
  • Klären, ob Eingabedaten zu Trainings- oder Verbesserungszwecken verwendet werden.

Produktseitige Mitigationen:

  • Daten-Masking im Produkt, bevor Daten an die API übermittelt werden.
  • Datenminimierung — nur die für das Feature notwendigen Daten übertragen.

4. Video-Dienst eines Drittanbieters in einer Kollaborations-App

Ein Hersteller bietet eine Team-Kollaborations-App mit Desktop- und Mobile-Client an — lokal installierte Komponenten und damit ein Produkt mit digitalen Elementen. Für die integrierte Videokonferenz bindet die App den Video-Dienst eines Drittanbieters ein, den dieser entwickelt und betreibt.

  • Element 1 (Distanz): erfüllt — die Video-Verbindung wird über die Server des Drittanbieters vermittelt, ausserhalb der Umgebung des Nutzers.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne den Video-Dienst kann die App die Funktion „Videokonferenz" nicht ausführen.
  • Element 3 (Herstellerverantwortung): verneint — der Video-Dienst wurde vom Drittanbieter entworfen und entwickelt und wird von ihm betrieben, nicht vom App-Hersteller.

Klassifikation: Komponente (Stufe B).

(Ein CDN bzw. eine Web Application Firewall wäre demgegenüber gerade kein eindeutiges Stufe-B-Beispiel: Ob ihr Wegfall eine Produktfunktion verhindert — Element 2 — oder lediglich die Verfügbarkeit unter Last beeinträchtigt, ist ein Grauzonenfall. Solche Abgrenzungen behandelt der Folgeartikel zur CRA-Grauzone.)

Due-Diligence-Anforderungen:

  • Sicherheitsdokumentation des Video-Anbieters einholen; Konformitätsnachweise und Zertifikate (z. B. ISO 27001, SOC-2) prüfen.
  • Prüfen, wie der Dienst die Verbindungen verschlüsselt und wie er mit Schwachstellen umgeht.

Produktseitige Mitigationen:

  • Verschlüsselung der Signalisierungs- und Mediendaten, soweit vom Dienst unterstützt.
  • Im Produkthandbuch offenlegen, dass die Videokonferenz über einen externen Dienst läuft und unter dessen Verantwortung steht.

Konkrete Handlungsschritte für Hersteller (Stufe B)

  1. Inventur: Erstelle eine Datei aller Drittanbieter-Services, die dein Produkt nutzt.

- Spalten: Service-Name, Anbieter, Funktion, Klassifikation (RDPS / Komponente / Risk Assessment), Akteurs-Typ (Hersteller / Verwalter quelloffener Software nach Art. 24 CRA) - Diese Datei ist deine erste CRA-Dokumentation

  1. Klassifikation: Wende den Test aus Teil 2 an. Werden Daten fernverarbeitet? Ist der Service funktional notwendig?
  1. Dokumentation-Request: Fragen Sie jeden Drittanbieter nach:

- Sicherheitszertifizierungen (ISO 27001, SOC 2) - Security Whitepaper oder Datasheet - Vulnerability Disclosure Policy - Incident Response Time - Compliance mit relevanten Regulierungen (DSGVO, NIS-2-Richtlinie, etc.) - Zugesicherter Support- und Update-Zeitraum (Gleichlauf mit eigenem Art. 13 Abs. 8 CRA-Zeitraum)

  1. Produktseitige Mitigationen (Rn. 153–154):

- Kryptographische Authentifizierung zwischen Produkt und Service - Integritätsprüfungen (Signatures, HMAC) - Fallback-Mechanismen, falls der Service ausfällt - Verschlüsselung sensitiver Daten vor dem Versand - Minimale Datenweitergabe (Privacy by Design)

  1. Vertragliche Absicherung: Verträge mit Drittanbietern müssen enthalten:

- Verpflichtung des Anbieters, Sicherheitsdokumentation zu pflegen - Verpflichtung zur Mitteilung bei bekannten Sicherheitslücken - Recht des Herstellers, Sicherheitsaudits durchzuführen - Versicherung, dass der Anbieter selbst CRA-konform ist (oder zumindest den Sicherheitsanforderungen folgt) - Mindest-Support-Zeitraum, der dem eigenen Unterstützungszeitraum nach Art. 13 Abs. 8 CRA entspricht

  1. Laufendes Monitoring:

- Monats- oder quartalsweise Überprüfung: Gibt es neue Sicherheits-Breaches beim Drittanbieter? - Abonnement auf Security-Mailing-Listen des Anbieters - Kontinuierliche Risikobewertung des Lieferanten in der Produktrisikoanalyse - Eigener B2B-Meldekanal nach Art. 13 Abs. 6 CRA für identifizierte Schwachstellen in Komponenten

Unterstützung durch die crAIready-Plattform: Die Plattform begleitet diese Schritte funktional: Sie unterstützt die Inventur und die Klassifikation der Drittanbieter-Dienste (Schritte 1 und 2), die Erstellung der komponentenbezogenen Software-Stückliste (SBOM) und das laufende Schwachstellen-Monitoring der erfassten Abhängigkeiten mit Alerting noch vor Ablauf der Meldefristen (Schritt 6); Nachweise und Compliance-Dokumentation werden mit Audit-Log abgelegt (Schritte 3 und 5). Die Behörden-Meldung nach Art. 14 CRA (B2A) wird über einen strukturierten Meldeworkflow unterstützt; der B2B-Meldeweg an Komponentenhersteller nach Art. 13 Abs. 6 CRA ist demgegenüber als Lieferantenprozess zu führen. Produktseitige Mitigationen (Schritt 4) bleiben eine Engineering-Aufgabe, die die Plattform nachhält, aber nicht ersetzt.

Stufe C — Die Risikobewertungspflicht (Art. 13 Abs. 2)

Nicht alles, was sich mit dem Internet verbindet, ist eine „Komponente". Manche Verbindungen sind rein informativer Natur und erfüllen weder die RDPS-Kriterien noch sind sie funktional notwendig. Das sind die Fälle für Stufe C.

Die Herleitung über die drei Elemente

Stufe C ergibt sich spiegelbildlich zu A und B aus dem Drei-Elemente-Test. Die Datenverarbeitung findet zwar auf Distanz statt (Element 1), aber sie ist nicht funktionsnotwendig — Element 2 ist verneint: Fällt die Verbindung weg, läuft das Produkt unverändert weiter. Damit ist sie weder RDPS noch Drittanbieter-Komponente, denn beide setzen eine bejahte Funktionsnotwendigkeit voraus. Auf Element 3 — die Herstellerverantwortung, also ob die Software vom Hersteller entwickelt wurde — kommt es dann gar nicht mehr an.

Was Art. 13 Abs. 2 CRA verlangt

Auch ohne RDPS und ohne Komponente ist Stufe C kein regelungsfreier Raum. Anker ist Art. 13 Abs. 2 CRA — so, wie Art. 13 Abs. 5 CRA der Anker der Stufe B ist: Der Hersteller muss eine Cybersicherheits-Risikobewertung für sein Produkt durchführen, und in diese müssen auch die nicht-funktionalen Datenverbindungen einfliessen. Denn auch eine Telemetrie- oder Analytics-Verbindung schafft Angriffsfläche.

Was fällt hier hinein?

  • Telemetrie (Nutzungsstatistiken: „Wie oft wird dieses Feature verwendet?")
  • Crash-Reporting (Bug-Diagnose: „Welche Stack Trace hatte der Fehler?")
  • Analytics (Aggregierte Nutzungsmuster)
  • Update-Checks (nur Versionsnummern-Abfrage, nicht die Daten selbst)
  • Logging-Services für Debugging

Rn. 176–177: Telemetrie und die Funktionsfrage

Rn. 176 ist keine eigenständige Ausnahmeregel, sondern die ausdrückliche Anwendung von Element 2 auf den Telemetrie-Fall: Datenverarbeitung, die keine Produktfunktion ermöglicht, ist keine RDPS. Rein statistische Telemetrie — Daten, die nur zu statistischen Zwecken oder für die künftige Produktentwicklung erhoben werden — ist deshalb per definitionem nie eine RDPS: „Rein statistisch" bedeutet, dass ihr Wegfall keine Produktfunktion verhindert, Element 2 also verneint ist. Der Grund ist somit die fehlende Funktionsnotwendigkeit, nicht eine Sonderregel für Telemetrie.

Das Etikett „Telemetrie" entscheidet dabei nichts. Speist derselbe Datenstrom eine Produktfunktion — etwa eine KI-basierte Personalisierung —, ist er nicht mehr „rein statistisch": Element 2 ist dann bejaht, und die Verarbeitung kann RDPS oder Komponente sein (entschieden über Element 3). Massgeblich ist stets die Funktionsfrage — nicht, dass Daten „Telemetrie" heissen oder auf einem Server des Herstellers verarbeitet werden.

Rn. 177: Auch wenn Telemetrie nicht RDPS ist, bedeutet das nicht „keine Pflicht". Der Hersteller muss dennoch:

  1. Analysieren: Welche Angriffsfläche schafft diese Datenverbindung?
  2. Produktseitige Schutzmassnahmen implementieren
  3. In der Risikobewertung dokumentieren, warum Telemetrie akzeptabel ist

Das Telemetrie-Graustufen-Problem

Eine häufige Frage: Ab wann wird Telemetrie zur Komponente oder gar zu RDPS?

Beispiel 1: Reine Nutzungsstatistiken `` Benutzer öffnet Feature X → Hersteller erhält: {eventId: "feature_x_opened", timestamp: "2026-04-06T10:30Z"} ``

  • Element 1 (Distanz): erfüllt — die Statistik wird auf einem Server des Herstellers verarbeitet.
  • Element 2 (Funktionsnotwendigkeit): verneint — das Feature läuft auch ohne die Telemetrie unverändert weiter.
  • Element 3 (Herstellerverantwortung — ob die Software vom Hersteller entwickelt wurde): nicht mehr zu prüfen, da Element 2 bereits verneint ist.

Ergebnis: Stufe C — Berücksichtigung in der Risikobewertung nach Art. 13 Abs. 2 CRA, abgesichert durch produktseitige Massnahmen (Verschlüsselung in Transit, Datenminimierung, Anonymisierung).

Beispiel 2: Telemetrie, die eine Produktfunktion ermöglicht `` Hersteller sammelt Telemetrie → Nutzt sie für eine KI-basierte Personalisierung → Diese Personalisierung ist ein Feature des Produkts ``

  • Element 1 (Distanz): erfüllt — die Verarbeitung findet beim Hersteller statt.
  • Element 2 (Funktionsnotwendigkeit): erfüllt — ohne die ferne Verarbeitung fehlt dem Produkt die Personalisierungs-Funktion.
  • Element 3 (Herstellerverantwortung): entscheidet die Stufe — hat der Hersteller den Personalisierungs-Dienst selbst entwickelt, liegt eine RDPS vor (Stufe A); ist es ein Standard-Drittanbieter-Dienst, ist es eine Komponente (Stufe B).

Ergebnis: Stufe A oder B — sobald die Telemetrie eine Produktfunktion trägt, greift die Stufe-C-Einordnung nicht mehr.

Beispiel 3: Sicherheitsbezogene Telemetrie `` Produkt sammelt Telemetrie zu Sicherheitsereignissen → Hersteller nutzt sie, um kritische Sicherheitspatches zu priorisieren ``

  • Element 1 (Distanz): erfüllt — die Sicherheitsereignisse werden beim Hersteller verarbeitet.
  • Element 2 (Funktionsnotwendigkeit): verneint — die Telemetrie speist die Patch-Priorisierung des Herstellers; das ist ein Prozess des Herstellers, keine Funktion des Produkts. Fällt die Verbindung weg, bleiben alle Produktfunktionen erhalten.
  • Element 3 (Herstellerverantwortung — ob die Software vom Hersteller entwickelt wurde): nicht mehr zu prüfen, da Element 2 bereits verneint ist.

Ergebnis: Stufe C — auch sicherheitsbezogene Telemetrie ist nicht automatisch RDPS; massgeblich bleibt allein, ob eine Produktfunktion ausfällt, nicht das Thema der Daten.

Meldepflichten gelten produktweit — unabhängig von der Stufe

Ein verbreitetes Missverständnis ist, die Meldepflichten nach Art. 14 CRA — für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle — seien an die Stufe gebunden. Das trifft nicht zu. Art. 14 CRA knüpft am Produkt als Ganzes an, nicht an der A/B/C-Einstufung einzelner Datenströme. Ein Hersteller, dessen Produkt nur Stufe-C-Verbindungen hat, unterliegt den Meldepflichten des Art. 14 CRA genauso wie jeder andere. Die A/B/C-Abstufung betrifft die produktbezogenen Sorgfalts- und Due-Diligence-Pflichten — nicht die Meldepflichten. Ausführlich dazu der Artikel zu den CRA-Meldepflichten.

Vertragliche Absicherung der Drittanbieter-Komponenten (Schwerpunkt Stufe B)

Ein häufiges Problem: Der Hersteller möchte Sicherheitsdokumentation vom Drittanbieter anfordern, der Anbieter sagt „Nein, das ist proprietär" oder „Dafür brauchst du ein NDA".

Die CRA ändert die Spielregeln. Der Hersteller muss diese Informationen haben, um gesetzlich konform zu sein. Inwieweit dies bereits durchgängige Praxis ist, kann an dieser Stelle nicht beantwortet werden.

Diese vertragliche Absicherung betrifft vor allem Stufe B: Dort integriert der Hersteller fremdentwickelte Komponenten, deren Sicherheitseigenschaften er vertraglich greifbar machen muss. Bei Stufe A gibt es für die RDPS selbst keinen Dritten, mit dem zu kontrahieren wäre — herstellereigene Server-Software verantwortet der Hersteller unmittelbar; Verträge sind hier nur für Unterlieferanten und Infrastruktur (etwa den IaaS-Anbieter) relevant. Bei Stufe C genügt im Regelfall eine leichtere Behandlung; im Vordergrund steht die eigene Risikobewertung. Die folgenden Vertragsklauseln richten sich daher an Stufe-B-Konstellationen — und auch dort gilt: Wo ein Drittanbieter vertraglich nicht verhandelbar ist, treten an die Stelle individueller Klauseln die sorgfältige Komponentenauswahl, das Monitoring und produktseitige Mitigationen.

Vertragsklauseln für Drittanbieter

1. Sicherheitsdokumentation-Klausel ``` Der Anbieter erklärt sich bereit, auf Anfrage die folgenden Informationen bereitzustellen:

  • Security Whitepaper oder Sicherheitszertifikate (ISO 27001, SOC 2)
  • Informationen zu Patch-Management und Vulnerability-Disclosure-Richtlinien
  • Compliance-Status gegenüber relevanten Regulierungen

```

2. Vulnerability Notification Clause `` Der Anbieter verpflichtet sich, den Hersteller unverzüglich (innerhalb von 24–72 Stunden) über Sicherheitslücken oder Incident-Response-Aktivitäten zu informieren. ``

3. SLA-Anforderungen aus CRA-Perspektive ``` Der Anbieter verpflichtet sich:

  • Sicherheits-Patches innerhalb von X Tagen nach Verfügbarkeit bereitzustellen
  • Ein Incident-Response-Team mit dokumentierter Reaktionszeit zu unterhalten
  • Regelmässige (mind. jährliche) Sicherheitsaudits durchzuführen
  • Sicherheitsupdates über mind. den eigenen Mindest-Unterstützungszeitraum

des Herstellers nach Art. 13 Abs. 8 CRA bereitzustellen ```

4. Auditierungs-Recht `` Der Hersteller behält sich das Recht vor, die Sicherheitsmassnahmen des Anbieters zu überprüfen, entweder direkt oder durch einen unabhängigen Auditor, um CRA-Compliance zu gewährleisten. ``

5. Keine Sicherheitsdokumentation verfügbar? ``` Falls der Anbieter die erforderliche Sicherheitsdokumentation nicht bereitstellt, kann der Hersteller:

  • Die Integration des Services neu bewerten
  • Den Service durch ein alternatives Produkt mit besserer Dokumentation ersetzen
  • Den Service deaktivieren und die Risiken in der Produktbewertung dokumentieren

```

Die operative Umsetzung — Checkliste

Für Stufe A (RDPS)

Dies wird in Teil 2 dieser Serie behandelt. Kurz: Vollständige CRA-Compliance mit SBOM, Zertifizierung, Vulnerability Management.

Für Stufe B (Komponente)

  • [ ] Inventur: Alle funktional notwendigen Drittanbieter-Dienste dokumentiert?
  • [ ] Akteurs-Typ erfasst: Klassischer Hersteller oder Verwalter quelloffener Software (Art. 24 CRA)?
  • [ ] Klassifikation: Jeder Service wurde dem RDPS-Test unterzogen?
  • [ ] Sicherheitsdokumentation: Vom Drittanbieter erhalten?

- [ ] ISO 27001 oder SOC 2 Zertifikat? - [ ] Security Whitepaper oder Data Sheet? - [ ] Patch-Management-Policy? - [ ] Vulnerability Disclosure Policy? - [ ] Zugesicherter Support- und Update-Zeitraum?

  • [ ] Risikobewertung: Integriert in die Produktrisikoanalyse?

- [ ] Welche Daten gehen an den Drittanbieter? - [ ] Wie würde ein Compromised Drittanbieter das Produkt gefährden? - [ ] Welche Angriffsfläche entsteht?

  • [ ] Produktseitige Mitigationen implementiert:

- [ ] Kryptographische Authentifizierung? - [ ] Daten-Verschlüsselung vor Versand? - [ ] Integritätschecks (HMAC, Signatures)? - [ ] Fallback-Mechanismen bei Service-Ausfällen? - [ ] Minimale Datenweitergabe (Principle of Least Privilege)?

  • [ ] Verträge aktualisiert:

- [ ] Sicherheitsdokumentation-Anforderung? - [ ] Vulnerability Notification? - [ ] SLA für Patch-Management? - [ ] Auditierungs-Recht? - [ ] Mindest-Support-Zeitraum (Gleichlauf mit Art. 13 Abs. 8 CRA)?

  • [ ] Meldekanäle:

- [ ] B2A-Meldeprozess nach Art. 14 CRA über Plattform Art. 16 CRA? - [ ] B2B-Meldeprozess nach Art. 13 Abs. 6 CRA an Komponentenhersteller?

  • [ ] Monitoring eingerichtet:

- [ ] Subscription zu Security-Updates des Anbieters? - [ ] Quartalsmässige Überprüfung der Anbieter-Sicherheitslage? - [ ] Dokumentation im Produkt-RiskLog?

Für Stufe C (weder RDPS noch Komponente)

  • [ ] Identifikation: Alle nicht-funktionalen Datenverbindungen katalogisiert?
  • [ ] Risikoanalyse: Welche Angriffsflächen schaffen diese?

- [ ] Man-in-the-Middle-Risiken? - [ ] Datenleck-Risiken? - [ ] Service-Ausfalls-Risiken?

  • [ ] Produktseitige Schutzmassnahmen:

- [ ] TLS/HTTPS für alle Verbindungen? - [ ] Certificate Pinning (falls möglich)? - [ ] Daten-Minimierung (nur notwendige Daten senden)? - [ ] Optionaler Opt-Out (für Telemetrie, etc.)?

  • [ ] Dokumentation in Risikobewertung:

- [ ] Warum ist dieser Service akzeptabel? - [ ] Welche Residual-Risiken verbleiben? - [ ] Wie werden diese mitigiert?

  • [ ] Kontinuierliche Überprüfung:

- [ ] Jährliche Überprüfung in der Risikoanalyse? - [ ] Werden neue Risiken identifiziert?

Hinweis zur Methodik

*Die in diesem Beitrag zitierten Rechtsnormen, Erwägungsgründe und Randnummern wurden anhand der folgenden Primärquellen geprüft:

  • Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 3 Nr. 14 (Definition Verwalter quelloffener Software), Art. 13 Abs. 2, 5, 6, 8, 9 und 13, Art. 14 (Meldepflichten), Art. 16 (zentrale Meldeplattform), Art. 24 (Verwalter quelloffener Software), Art. 32 (Konformitätsbewertung), Art. 52 ff. CRA i. V. m. VO (EU) 2019/1020 (Marktüberwachung), Art. 64 Abs. 2/3/4 (Bussgelder), Erwägungsgrund 19 (Verwalter quelloffener Software) und Erwägungsgrund 60 (Hardware- und Software-Lebenszyklen jenseits von 5 Jahren)
  • Draft Communication Ares(2026)2319816, insbesondere:

- Rn. 151–157 (Due Diligence und Risikobewertung) - Rn. 176–177 (Telemetrie und nicht-funktionale Datenverarbeitung) - Abschnitt 8.3.3 (E-Reader-Beispiel) - Rn. 186 (die Drei-Klassen-Klassifikation)

  • CRA-Kommentar Wiebe (Nomos 2025) als juristischen Kommentar zur Auslegung, insbesondere zur B2B-Meldekette nach Art. 13 Abs. 6 CRA, zum Mindest-Unterstützungszeitraum nach Art. 13 Abs. 8 CRA, zur 10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA, zur Konzern-Bemessungsgrundlage bei Art. 64 CRA und zur Sonderkategorie des Verwalters quelloffener Software nach Art. 24 CRA. Stand: 26.05.2026 (v9 — den Abschnitt zum Mindest-Unterstützungszeitraum zu einem Drei-Fristen-Block ausgebaut: Art. 13 Abs. 8 (typischerweise 5 Jahre Unterstützungszeitraum) sauber von Art. 13 Abs. 9 (mind. 10 Jahre Verfügbarkeit von Sicherheitsupdates) und Art. 13 Abs. 13 (mind. 10 Jahre Aufbewahrung der technischen Dokumentation und EU-Konformitätserklärung) abgegrenzt; Erwgr. 60 CRA um die ausdrücklich genannten Software-Beispiele aus Wiebe § 6 Rn. 27 erweitert (Betriebssysteme, Videobearbeitungstools, industrielle Steuerungssysteme); Quellen [4] und Methodik um Rn. 27 und Rn. 35 ergänzt. v8 (23.05.2026) — Bezeichnung der Stufe C in der Übersichtstabelle und in der Umsetzungs-Checkliste von „Risikobewertung" auf „weder RDPS noch Komponente" geändert — damit benennen alle drei Stufen-Labels einheitlich die Einstufung der Datenverbindung, nicht die daraus folgende Pflicht; Legaldefinition des Verwalters quelloffener Software nach Art. 3 Nr. 14 CRA sowie dessen Pflichten nach Art. 24 CRA im gleichnamigen Abschnitt ergänzt; die vier Praxisbeispiele der Stufe B einheitlich entlang der drei Elemente strukturiert und um die Produkt-Vorfrage ergänzt, das CDN/WAF-Beispiel als Grenzfall durch ein eindeutiges Komponenten-Beispiel ersetzt; im Sanktionsabschnitt die vertauschten Kategorie-B/C-Klammern korrigiert; die Plattform-Modulnamen auf die Website-Benennung M1–M5 abgeglichen; den CTA vom nur angedachten „CRA Quick Assessment" auf den realen „CRA-Quick-Check" umgestellt; den Telemetrie-Abschnitt zu Rn. 176 präzisiert — Rn. 176 ist keine eigenständige Ausnahme, sondern die Anwendung von Element 2; die Kategorie-B-Pflicht in der Übersichtstabelle auf Art. 13 Abs. 2 und Abs. 5 CRA ergänzt).*

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyber Resilience Act). ABl. L, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj.

[2] Europäische Kommission, Draft Communication Ares(2026)2319816, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)", März 2026. Konsultationsfrist: 31. März 2026 (abgeschlossen). Verfügbar unter: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959.

[3] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 (NIS-2-Richtlinie). ABl. L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj.

[4] Wiebe (Hrsg.), Cyber Resilience Act. Kommentar, Nomos 2025; insbesondere § 4 Rn. 38 (Verwalter quelloffener Software, Art. 24 CRA), § 6 Rn. 20 (B2B-Meldekette, Art. 13 Abs. 6 CRA), § 6 Rn. 25–27 (Mindest-Unterstützungszeitraum, Art. 13 Abs. 8 CRA), § 6 Rn. 27 (Erwägungsgrund 60 — auch Software wie Betriebssysteme, Videobearbeitungstools und industrielle Steuerungssysteme typischerweise länger als 5 Jahre genutzt), § 6 Rn. 35 (10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA), § 7 Rn. 57 nebst Fussnote (Konzernumsatz als Bemessungsgrundlage, EuGH-Rechtsprechung zu Art. 101/102 AEUV; Modifikation im deutschen OWi-Recht).

Unsicher, welches Pflichtniveau für Ihr Produkt gilt? Der CRA-Quick-Check unterstützt Sie bei der orientierenden Einordnung Ihres Produkts und zeigt mögliche nächste Schritte auf. Die abgestufte Einordnung der einzelnen Drittanbieter-Abhängigkeiten — RDPS, Komponente oder reine Risikobewertung — erfolgt anschliessend in der crAIready-Plattform; die endgültige Klassifikation erfordert eine Einzelfallprüfung.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Veröffentlicht am: 03.04.2026. Zuletzt geprüft am: 03.07.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Im nächsten Artikel dieser Serie: Die CRA-Grauzone — fünf Praxisfälle zwischen Feature-gated SaaS, Electron-Apps und Browser-Extensions, die der Test nicht eindeutig löst. Wie navigieren Sie, wenn die Klassifikation unklar ist? (Artikel 04)