Kein RDPS — und trotzdem CRA-pflichtig? Was die abgestuften Pflichten nach Art. 13 CRA konkret bedeuten

Von codAIx GmbH | April 2026

**Die meisten Diskussionen über die 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 ü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 jeden relevanten Netzwerk-komponenten eines Produkts in eine von drei Kategorien (Rn. 186 der Draft Communication):

Der zentrale Punkt: Der CRA ist nicht binär. Auch Hersteller in Stufe B und C haben echte, dokumentierbare Pflichten. Nicht einzuhalten ist nicht bloß unprofessionell — es verstößt gegen die Verordnung.

Was bei Nichteinhalten droht

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

Höchste Stufe (Art. 64 Abs. 2 Unterabs. 1): Verstöße gegen die wesentlichen 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. 2 Unterabs. 2): Verstöße gegen Konformitätsbewertungs-, CE-Kennzeichnungs- oder Dokumentationspflichten sowie gegen Anforderungen an Importeure und Händler — bis zu 10 Millionen Euro oder 2 % des Jahresumsatzes.

Unterste Stufe (Art. 64 Abs. 2 Unterabs. 3): Unrichtige oder irreführende Auskünfte gegenüber benannten Stellen und Marktüberwachungsbehörden — bis zu 5 Millionen Euro oder 1 % des Jahresumsatzes.

Das entscheidende Detail: Art. 13 steht in der höchsten Bußgeldstufe. 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 oder keine Risikobewertung für nicht-funktionale Datenverbindungen durchführt, riskiert dieselben Maximalbußgelder wie ein Hersteller, der eine vollständige RDPS-Compliance ignoriert.

Hinzu kommen operative Konsequenzen: Marktüberwachungsbehörden können nach Verordnung (EU) 2019/1020 Korrekturmaßnahmen anordnen, Produkte vom Markt nehmen oder deren Bereitstellung untersagen [1, Art. 52–58]. Im Extremfall bedeutet das: Verkaufsstopp in der gesamten EU.

Stufe A — Volle RDPS-Compliance

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

Eine Datenfernverarbeitungslösung (RDPS) liegt vor, wenn zwei kumulative Bedingungen erfüllt sind (Art. 3 Nr. 2 CRA): Erstens wurde die serverseitige Software vom Hersteller des Produkts entworfen und entwickelt oder unter seiner Verantwortung. Zweitens würde das Fehlen dieser Datenverarbeitung verhindern, dass das Produkt eine seiner Funktionen ausübt. 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 Annex I
• Conformity Assessment (Art. 16)
• Vulnerability Management für das gesamte System (Produkt + Server)
• Sicherheitsmitteilungen gemäß Art. 22

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

Art. 13(5) CRA besagt, dass der Hersteller „angemessene Maßnahmen" 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äß Art. 13(2) für alle Komponenten (einschließlich 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 nicht die Einhaltung durch das Gesamtprodukt gefährdet. „Angemessen" heißt nicht „perfekt", aber es heißt 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.)

Praktische Beispiele

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

Ein Hardware-Hersteller bietet einen E-Reader mit optionalem Cloud-Backup. Der Speicherdienst ist:

• Funktional notwendig für das Backup-Feature
• Nicht vom E-Reader-Hersteller entwickelt (externe SaaS)
• Daher: Komponente (Stufe B), nicht RDPS

Der Hersteller muss:

1. Die Sicherheitsdokumentation des Cloud-Anbieters einsehen
2. Verifikation, dass der Anbieter eine angemessene Verschlüsselung und Zugriffskontrolle hat
3. Dies im Rahmen der Produktrisikobewertung dokumentieren
4. Im Produkthandbuch offenlegen, dass der Backup-Service extern ist und unter der Verantwortung des Anbieters liegt

2. Zahlungsgateway als SaaS-Integration

Eine E-Commerce-Plattform integriert Stripe, Square oder einen anderen Payment Service Provider (PSP). Der Service ist funktional notwendig (Kernfunktion des Produkts), extern entwickelt.

Klassifikation: Komponente (Stufe B)

Due-Diligence-Anforderungen:

• Einsicht in Stripe/Square Sicherheitsdokumentation (beide veröffentlichen Security whitepapers)
• Überprüfung: Hat der PSP ein ISO-27001-Zertifikat? SOC-2-Report?
• Ist der PSP in eine Datenschutz-Grundverordnung (DSGVO) konform?
• Implementierung von produktseitigen Mitigationen: Token-basierte Zahlungsverarbeitung (kein direkter Kartenzugriff im Produkt), TLS 1.2+ für die Integration, Integrität der API-Anfragen überprüfen

3. KI-API (OpenAI, Anthropic, Claude) integriert in ein Produkt

Ein SaaS-Tool nutzt die OpenAI-API für Textgenerierung oder eine Anthropic-API für Code-Analyse. Beide sind:

• Extern entwickelt
• Funktional notwendig für das Feature
• Remote-verarbeitende Services (aber vom API-Anbieter betrieben, nicht vom Produkt-Hersteller)

Klassifikation: Komponente (Stufe B) oder möglicherweise RDPS-Hybrid (wenn Benutzerdaten an die API-Anbieter gehen)

Due-Diligence-Anforderungen:

• Sicherheitsdokumentation des API-Anbieters
• Klärung: Werden Eingabe-Daten zu Trainings-/Verbesserungszwecken verwendet?
• Implementierung von Daten-Masking im Produkt, bevor Daten an die API gehen
• Falls kritische Daten betroffen sind: Evaluierung, ob die API unter den CRA-Anforderungen selbst konform ist

4. CDN/WAF als Sicherheitskomponente

Ein SaaS-Produkt nutzt Cloudflare oder Akamai als CDN und Web Application Firewall. Diese sind funktional notwendig (ohne sie wäre das Produkt unter DDoS-Angriffen nicht verfügbar).

Klassifikation: Komponente (Stufe B)

Due-Diligence-Anforderungen:

• WAF-Sicherheitsdokumentation des Providers
• SLA-Anforderungen: Welches Patch-Management, welche Incident-Response?
• Überprüfung: Wie sichert der Provider seine eigenen Systeme?
• Produktseitige Mitigationen: Redundante Authentifizierung, Fallback-Mechanismen bei CDN-Ausfällen

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) - Diese Datei ist deine erste CRA-Dokumentation

1. Klassifikation: Wendet den Test aus Teil 2 an. Ist der Service funktional notwendig? Werden Daten fernverarbeitet?

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, etc.)

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)

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

Stufe C — Die Risikobewertungspflicht

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.

Was fällt hier hin?

• 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: Die Telemetrie-Ausnahme

Rn. 176: Der Test unterscheidet zwischen:

• Rein statistische Telemetrie (Daten, die zu statistischen Zwecken erhoben werden und deren Wegfall keine Produktfunktion verhindert): Nicht RDPS
• Funktional relevante Telemetrie (Daten, die eine Produktfunktion ermöglichen, z. B. KI-basierte Personalisierung): Möglicherweise RDPS, da funktional notwendig

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 Schutzmaßnahmen 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"}

• Keine Personenidentifikation
• Nicht funktional notwendig (Feature funktioniert auch ohne Telemetrie)
• Klassifikation: Stufe C (Risikobewertung)
• Anforderung: Datenschutz-Impact-Assessment, Verschlüsselung in Transit, Anonymisierung

Beispiel 2: Telemetrie, die eine Funktion steuert

Hersteller sammelt Telemetrie
→ Nutzt sie, um KI-basierte Personalisierung zu trainieren
→ Diese Personalisierung ist ein Feature des Produkts

• Funktional notwendig (für Personalisierung)
• Personenbezogen (um einzelnen Nutzer zu personalisieren)
• Klassifikation: Möglicherweise Stufe B oder A
• Anforderung: Vollständige Sicherheitsbewertung des Personalisierungs-Service

Beispiel 3: Security-Update über Telemetrie

Produkt sammelt Telemetrie zu Sicherheitsevents
→ Nutzt diese, um kritische Security Patches zu priorisieren

• Funktional notwendig (für die Sicherheit des Systems)
• Remote verarbeitet (zur Priorisierung auf Seite des Herstellers)
• Klassifikation: Stufe A oder B
• Anforderung: Vollständige RDPS-Compliance oder Component Due Diligence

Vertragliche Absicherung (Alle Stufen)

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 eine NDA".

Die CRA ändert die Spielregeln. Der Hersteller muss diese Informationen haben, um gesetzlich konform zu sein.

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äßige (mind. jährliche) Sicherheitsaudits durchzuführen

4. Auditierungs-Recht

Der Hersteller behält sich das Recht vor, die Sicherheitsmaßnahmen
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?
• [ ] 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?

• [ ] 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?

• [ ] Monitoring eingerichtet:

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

Für Stufe C (Risikobewertung)

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

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

• [ ] Produktseitige Schutzmaßnahmen:

- [ ] 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

*Alle Aussagen in diesem Artikel sind direkt gegen die Primärquellen verifiziert:

• Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 13 Abs. 2 und Abs. 5 sowie Erwägungsgrund (34)
• Draft Communication Ares(2026)2319816, insbesondere:

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

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: 13. April 2026. 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.

Unsicher, welches Pflichtniveau für Ihr Produkt gilt? Der crAIready Quick Check klassifiziert Ihre Drittanbieter-Abhängigkeiten systematisch — RDPS, Komponente oder Risikobewertung — und zeigt Ihnen die konkreten nächsten Schritte.

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?