Von Redaktion codAIx | 30. März 2026

**„Keine RDPS“ klingt zunächst wie Entwarnung. Für viele Hersteller beginnt an diesem Punkt jedoch erst die eigentliche Arbeit. Denn der Cyber Resilience Act (CRA) kennt nicht nur die binäre Frage: Ist mein Produkt CRA-pflichtig oder nicht? Wer so prüft, übersieht die abgestuften Pflichten der Verordnung — und riskiert kostspielige Lücken in der Compliance.**

Der im vorherigen Artikel beschriebene Drei-Elemente-Test — das RDPS-Klassifikationsverfahren — führt zu drei verschiedenen Behandlungen der untersuchten Datenverarbeitung. Teil 2 konzentriert sich auf das vollständige RDPS-Szenario. Hier geht es vor allem um die beiden Kategorien, die leicht übersehen werden: funktional notwendige Drittanbieter-Ferndienste (Stufe B) und nicht-funktionale Datenverbindungen, die in der Risikobewertung zu berücksichtigen sind (Stufe C).

Gerade die Gleichsetzung von „Keine RDPS“ und „Keine Compliance-Pflicht“ erweist sich im Audit als problematisch. Zurück bleiben eine unvollständige Dokumentation und fehlende Nachweise zur Prüfung der Lieferanten.

Drei Behandlungen der Datenverarbeitung

Der RDPS-Test aus Teil 2 klassifiziert jede relevante Netzwerkkomponente eines Produkts in eine von drei Kategorien (Rn. 202 der veröffentlichten Guidance [2]):

| Stufe | Kriterium | Behandlung der Datenverarbeitung | Beispiele | |-----------|--------------|-----------|-------------| | A: RDPS | Datenfernverarbeitungslösung — serverseitige Datenverarbeitung, deren Wegfall eine Produktfunktion verhindert (Element 2) und die vom Hersteller konzipiert und 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: Software-Stückliste (englisch software bill of materials, SBOM), Anhang-I-Bewertung, Konformitätsbewertung, Schwachstellenmanagement | z. B. Smart-Thermostat mit Hersteller-App und -Cloud-Backend | | B: Drittanbieter-Ferndienst, keine RDPS | Funktional notwendig für eine Produktfunktion (Element 2 erfüllt), aber nicht vom Hersteller entwickelt (Element 3 verneint) | Verbindlich: Produktrisikobewertung nach Art. 13 Abs. 2 und Anforderungen an das eigene Produkt. Zusätzlich erwartet die Guidance eine risikoproportionale Sorgfalt entsprechend Art. 13 Abs. 5 (Rn. 201, 202 lit. c, 207 f.). Unmittelbar gilt Art. 13 Abs. 5 jedenfalls für tatsächlich integrierte Komponenten, etwa ein lokal eingebundenes SDK. | z. B. E-Reader-Software mit Cloud-Speicher oder SaaS-Zahlungsgateway | | C: Weder RDPS noch Drittanbieter-Ferndienst mit Produktfunktion | 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 | Mindestpflicht nach Art. 13 Abs. 2: Risikoanalyse und produktseitige Minderungsmassnahmen | z. B. herstellereigene Telemetrie für anonyme Nutzungsstatistik (Element 2 verneint, Element 3 bejaht) |

Was daraus folgt: Der CRA ist nicht binär. Auch bei Verbindungen der Stufen B und C bleiben konkrete Pflichten des Produktherstellers bestehen und müssen dokumentiert werden. Sanktioniert werden Verstösse gegen verbindliche CRA-Normen, nicht die Missachtung der unverbindlichen Guidance als solche.

Wichtig: Die Stufen beschreiben, wie eine einzelne Datenverbindung zu behandeln ist — nicht, welche Pflichten das Produkt insgesamt hat. Das bereitgestellte Produkt unterliegt in allen drei Stufen vollständig dem CRA, unter anderem den einschlägigen Anforderungen aus Anhang I, der SBOM-Pflicht, der Konformitätsbewertung, der CE-Kennzeichnung und Art. 14 CRA. Die Stufe entscheidet nur, ob die ferne Verarbeitung als RDPS Teil des Produkts ist (A), als Drittanbieter-Ferndienst nach Art. 13 Abs. 2 zu bewerten und nach der Guidance mit einer Sorgfalt entsprechend Art. 13 Abs. 5 zu behandeln ist (B) oder als nicht funktionsnotwendige Verbindung in der Risikobewertung zu berücksichtigen ist (C).

Was bei Nichteinhalten droht

Verstösse gegen die in den drei Stufen jeweils einschlägigen Pflichten können unter die Sanktionen des Art. 64 CRA fallen. Die ab dem 11. Dezember 2027 geltende Vorschrift unterscheidet drei Stufen von Geldbussen [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.

Eng begrenzte Ausnahmen (Art. 64 Abs. 10 CRA): Gegen Kleinst- und kleine Hersteller dürfen keine Geldbussen allein wegen einer versäumten 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 Buchst. a oder Abs. 4 Buchst. a CRA verhängt werden. Gegen Verwalter quelloffener Software dürfen wegen Verstössen gegen den CRA keine Geldbussen verhängt werden. Diese Ausnahmen betreffen die Geldbussen; die jeweiligen materiellen Pflichten bleiben bestehen. Dabei ist die Berichtigung vom 2. Juli 2025 zu Art. 64 Abs. 10 berücksichtigt [1][8].

Für die Einordnung besonders wichtig ist, dass Art. 13 zur höchsten Stufe der Geldbussen gehört. Erfasst sind sowohl die Risikobewertungspflicht nach Art. 13 Abs. 2 als auch die Due-Diligence-Pflicht nach Art. 13 Abs. 5 für tatsächlich integrierte Komponenten. Bei einem Drittanbieter-Ferndienst der Stufe B folgt die verbindliche Pflicht jedenfalls aus Art. 13 Abs. 2 und 3 und den Anforderungen an das eigene Produkt. Ob Art. 13 Abs. 5 auf eingebundene Ferndienste unmittelbar anwendbar ist, lässt der Wortlaut offen; die Guidance erwartet jedenfalls eine entsprechende Sorgfalt (Rn. 201, 202 lit. c, 207 f.). Wer sie unterlässt, wird die Risikobewertung nach Art. 13 Abs. 2 kaum belastbar nachweisen können.

Bemessungsgrundlage „weltweiter Jahresumsatz“: Nach einer in der Kommentarliteratur vertretenen Auffassung ist in Anlehnung an die EuGH-Rechtsprechung zu Art. 101/102 AEUV die wirtschaftliche Einheit massgeblich — typischerweise also der Konzernumsatz, nicht der Umsatz der einzelnen rechtlich selbständigen Tochtergesellschaft [4, Jossen, § 7 Rn. 57]; zweifelnd NK-CRA/Kühne Art. 64 Rn. 34 [7]. Im deutschen Ordnungswidrigkeitenrecht ist die unionsrechtliche Vermutung des bestimmenden Einflusses der Muttergesellschaft wegen des Grundsatzes „in dubio pro reo“ nicht anwendbar; sie reduziert sich auf einen Erfahrungssatz [4, Jossen, § 7 Rn. 57 Fn. 44]. Für Hersteller mit Konzernstruktur bedeutet das: Die maximale Höhe der Geldbusse kann auch bei kleinen Tochtergesellschaften 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 konzipiert 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.

(Die Nummerierung der Elemente folgt der Guidance, die die Funktion vor der Herstellerverantwortung prüft (Rn. 184 ff.); der Wortlaut des Art. 3 Nr. 2 CRA nennt die Herstellerverantwortung — „konzipiert und entwickelt“ — zuerst, näher im Beitrag zum Drei-Elemente-Test.)

Was das bedeutet: Die RDPS ist Teil des Produkts (Art. 3 Nr. 1 CRA). Die Produktpflichten erstrecken sich deshalb auf sie, insbesondere:

  • Software-Stückliste (SBOM) nach Anhang I Teil II Nr. 1
  • Konformitätsbewertung nach Art. 32 CRA
  • Schwachstellenmanagement für das gesamte System (Produkt + Server)
  • Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Art. 14 CRA über die einheitliche Meldeplattform nach Art. 16 CRA

Der Anwendungsfall ist eng und klar umrissen. Wer nicht darunterfällt, ist damit allerdings noch lange nicht von sämtlichen Compliance-Pflichten befreit.

Stufe B — Drittanbieter-Ferndienst: verbindliche Risikobewertung, erwartete Sorgfalt

Stufe B verdient besondere Aufmerksamkeit. Viele Hersteller sind ihr zuzuordnen, ohne sich dessen bewusst zu sein.

Was der CRA verlangt — und was die Guidance zusätzlich erwartet

Kurz gefasst: Für einen funktional notwendigen Drittanbieter-Ferndienst sind die Produktrisikobewertung nach Art. 13 Abs. 2 und die Anforderungen an das eigene Produkt verbindlich. Die Guidance erwartet darüber hinaus eine risikoproportionale Sorgfalt entsprechend Art. 13 Abs. 5 und behandelt solche Dienste ähnlich wie Drittanbieter-Komponenten (Rn. 201, 202 lit. c, 207 f.). Ob Art. 13 Abs. 5 auf eingebundene Ferndienste unmittelbar anwendbar ist, lässt der Wortlaut offen. Unmittelbar greift die gesetzliche Pflicht des Art. 13 Abs. 5 jedenfalls, wenn der Hersteller eine von einem Dritten bezogene Software- oder Hardwarekomponente tatsächlich in sein Produkt integriert — etwa ein lokal eingebundenes SDK oder eine Bibliothek.

Nach Art. 13 Abs. 5 CRA lassen Hersteller „die gebotene Sorgfalt walten“, wenn sie von Dritten bezogene Komponenten integrieren, „sodass solche Komponenten die Cybersicherheit des Produkts mit digitalen Elementen nicht beeinträchtigen“ — auch bei nicht kommerziell bereitgestellter quelloffener Software. Für solche tatsächlich integrierten Komponenten ist dies eine direkte Pflicht des Herstellers. Eine eigenständige CRA-Konformität jeder integrierten Komponente verlangt die Vorschrift dagegen nicht. Ein entfernter Dienst wird durch seine funktionale Notwendigkeit allein nicht zu einer integrierten Komponente.

Die veröffentlichte Guidance konkretisiert das in Kapitel 7.3 (Rn. 167–173):

Rn. 167: Der CRA begründet zwei eigenständige, aber komplementäre Verpflichtungen im Cybersicherheits-Risikomanagement: Art. 13 Abs. 2 CRA verpflichtet den Hersteller zur Risikobewertung des Produkts mit digitalen Elementen selbst; Art. 13 Abs. 5 CRA verpflichtet ihn zur Due Diligence hinsichtlich tatsächlich integrierter Komponenten. Für funktional notwendige Drittanbieter-Ferndienste erwartet die Guidance eine entsprechende Sorgfalt (Rn. 201–202: „similar obligation“).

Rn. 170: Die Due Diligence betrifft Elemente, die Bestandteil des Produkts selbst sind — insbesondere integrierte Software- oder Hardwarekomponenten eines Drittanbieters. Der Hersteller muss „angemessene Vorkehrungen treffen“, damit solche Komponenten die Konformität des Produkts mit den grundlegenden Anforderungen nicht untergraben. Das lässt sich nur erreichen, indem der Hersteller bestimmt, was das Produkt von seinen Komponenten benötigt, um seine Cybersicherheitsziele zu erreichen, und risikobasiert verifiziert, dass die Komponenten diesen Bedarf erfüllen (vgl. auch Erwägungsgrund 34 CRA). Einordnung der Redaktion: „Angemessen“ heisst nicht „perfekt“, aber auch nicht, sich auf das Verkaufsversprechen des Lieferanten zu verlassen.

Rn. 171: Im Einklang mit seiner Risikobewertung muss der Hersteller die Anforderungen identifizieren, die eine integrierte Komponente erfüllen soll — etwa wenn das Produkt auf kryptographische Funktionen, Update-Mechanismen oder sichere Kommunikation einer Komponente angewiesen ist. Als Evidenz kommen danach in Betracht:

  • Dokumentation des Komponentenherstellers, etwa technische Spezifikationen
  • Sicherheitsdokumentation
  • einschlägige Konformitäts- oder Assurance-Dokumentation
  • funktionale Tests durch den Hersteller, soweit angemessen

Die FAQ der Kommissionsdienststellen nennt in Ziff. 4.4.2 über die in Erwägungsgrund 34 CRA aufgeführten Massnahmen hinaus weitere Beispiele, die je nach Art und Höhe des Risikos der Komponente in Betracht kommen [5]:

  • Software Composition Analysis der Komponente
  • Sandboxing bzw. Isolierung hochkritischer Komponenten
  • Durchsicht der SBOM der Komponente, soweit verfügbar
  • Prüfung des Unterstützungszeitraums der Komponente
  • Prüfung, ob die Zweckbestimmung der Komponente zur eigenen Verwendung passt
  • Bewertung der Sicherheitslage des Komponentenherstellers

Für quelloffene Komponenten, die selbst nicht in den Anwendungsbereich des CRA fallen, weist dieselbe FAQ ergänzend darauf hin, dass die Kommission ermächtigt ist, freiwillige Sicherheitsattestierungsprogramme einzurichten — sobald solche Programme verfügbar sind, würden sie die Due Diligence erleichtern (Ziff. 4.4.4) [5].

Für Komponenten im Zusammenhang mit Datenfernverarbeitungsdiensten Dritter ergänzt Kapitel 8.2 der Guidance (Rn. 207) eine nicht abschliessende Liste konkret wiederverwendbarer Nachweis-Artefakte, die im Rahmen der Konformitätsbewertung und/oder der Due-Diligence-Pflicht herangezogen werden können:

  • Nachweis der Erfüllung von Pflichten nach der Durchführungsverordnung (EU) 2024/2690 (NIS-2-Durchführungsverordnung)
  • Nachweis der Erfüllung von Pflichten nach Verordnung (EU) 2022/2554 (DORA)
  • Konformitätserklärung oder Zertifikat nach einem europäischen Cybersicherheits-Zertifizierungsschema gemäss Verordnung (EU) 2019/881 (Cybersecurity Act)
  • Konformitätsnachweis nach ISO/IEC 27017:2015 oder ISO/IEC 27001:2022

Rn. 172: Bei der Risikobewertung des Produkts als Ganzes müssen auch produktexterne Elemente berücksichtigt und, soweit relevant, durch produktseitige Massnahmen adressiert werden. Physisch oder logisch integrierte Komponenten eines Drittanbieters sind ebenfalls Teil der Risikobewertung; ihre Eigenschaften verifiziert der Hersteller bei der Integration durch die gesetzliche Due Diligence. Einordnung der Redaktion: Für Drittanbieter-Ferndienste gilt die oben dargestellte Abgrenzung (Rn. 201).

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 tatsächlich in das Produkt integrierten Drittanbieter-Komponente eine Schwachstelle feststellt, muss diese der Person oder Einrichtung melden, die die Komponente herstellt oder wartet [4, Wiebe, § 6 Rn. 20]. Ein blosser Verdacht genügt nicht; bei begründetem Verdacht muss der Hersteller den Sachverhalt zunächst durch eigene Untersuchungen und Tests klären — gemeldet wird die so bestätigte Schwachstelle [4, Wiebe, § 6 Rn. 20]. Für einen Drittanbieter-Ferndienst als solchen gilt Art. 13 Abs. 6 nicht; dort sind vertragliche Vulnerability- und Incident-Mitteilungen als Risikomassnahme zu empfehlen.

Weitergabe des selbst entwickelten Patches. Mit der Meldung ist die Pflicht nicht erfüllt. Entwickelt der integrierende Hersteller selbst eine Softwareänderung, um die Schwachstelle in der Komponente zu beheben, muss er diesen Sicherheitsfix nach Art. 13 Abs. 6 CRA auch mit der Person oder Einrichtung teilen, die die Komponente herstellt oder pflegt — so ausdrücklich auch die FAQ der Kommissionsdienststellen (Ziff. 4.3.6) [5]. Die veröffentlichte Guidance konkretisiert das in Kapitel 9.2.1 (Rn. 226–227): Der Fix ist, soweit angemessen, in einem maschinenlesbaren und leicht überprüfbaren Format bereitzustellen; handelt es sich um eine quelloffene Komponente, muss die Weitergabe mit deren Lizenz vereinbar sein — etwa unter derselben Lizenz oder unter einer Lizenz, die dem Maintainer die Weiterverbreitung erlaubt. Einen Anspruch darauf, dass der Maintainer den Fix übernimmt, hat der Hersteller nicht (Rn. 228).

Was die Meldepflicht begrenzt. Dieselbe Guidance zieht auch Grenzen: Hersteller sollten vor einer Meldung öffentlich zugängliche Schwachstellendatenbanken, projektspezifische Sicherheits-Advisories und etablierte Issue-Tracker konsultieren, um Doppelmeldungen zu vermeiden — die Guidance formuliert das als Empfehlung, nicht als Pflicht (Rn. 223). Die Meldepflicht entfällt, wenn der Hersteller bestätigen kann, dass der Maintainer die Schwachstelle bereits kennt, oder wenn die Komponente keinen Maintainer mehr hat (Rn. 223 und 225).

Für den internen Ablauf folgt daraus: 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 schwerwiegenden Sicherheitsvorfällen
  2. B2B (an die Person oder Einrichtung, die eine tatsächlich integrierte Komponente herstellt oder wartet, 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; ein selbst entwickelter Sicherheitsfix ist zusätzlich weiterzugeben. Für den entfernten Dienst selbst sollte ein vertraglicher Meldeweg eingerichtet werden; er ist keine Art.-13-Abs.-6-Pflicht.

In der Drittanbieter-Inventur (siehe unten) sollte diese Meldekette als eigenständiger Workflow geführt werden. Meldewege, Ansprechpartner und Reaktionszeiten gehören dabei 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. Unterstützungszeitraum (Art. 13 Abs. 8 CRA) — grundsätzlich mindestens fünf Jahre, festzulegen als Enddatum. Art. 13 Abs. 8 CRA verpflichtet den Hersteller, während des Unterstützungszeitraums sicherzustellen, dass Schwachstellen des Produkts einschliesslich seiner Komponenten wirksam und im Einklang mit Anhang I Teil II behandelt werden — grundsätzlich über mindestens fünf Jahre [4, Wiebe, § 6 Rn. 25–27]. Beträgt die voraussichtliche Nutzungsdauer weniger als fünf Jahre, entspricht der Unterstützungszeitraum dieser kürzeren Dauer. Der Massstab ist dabei streng: Für die Pflicht genügt bereits die abstrakte Gefahr in Gestalt einer Schwachstelle, unabhängig von deren möglicher Schwere (NK-CRA/Mehnert Art. 13 Rn. 21 [7]). Der CRA verlangt also keine schwachstellenfreie Software, wohl aber, dass jede Schwachstelle bewertet und risikogerecht behandelt wird; einen Patch für jede Schwachstelle verlangt der CRA nicht [5, Ziff. 4.3.1]. 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, Wiebe, § 6 Rn. 27].

Festgelegt wird ein Datum, nicht bloss eine Zeitspanne. Intern wird der Unterstützungszeitraum häufig als Dauer gedacht: „fünf Jahre“. Die Pflicht ist damit noch nicht erfüllt. Die Kommentierung von Mehnert im NK-CRA bestimmt den Unterstützungszeitraum über ein festes Enddatum und nicht über eine Dauer. Die Verordnung regelt nirgends, wann ein Zeitraum zu laufen begänne; Herstellungsende, Abgabe an den Endnutzer und Inverkehrbringen scheiden jeweils aus eigenen Gründen als Anknüpfungspunkt aus. Nur ein Enddatum lässt sich mit der Angabepflicht in Einklang bringen (NK-CRA/Mehnert Art. 13 Rn. 25 [7]; anders noch NK-CRA/Mehnert Art. 3 Rn. 121: „festen Zeitraum oder ein Enddatum“). Das bestätigt der Verordnungstext: Nach Art. 13 Abs. 19 CRA ist das Enddatum des Unterstützungszeitraums zum Zeitpunkt des Kaufs klar, verständlich und leicht zugänglich anzugeben — mindestens mit Monat und Jahr. Eine interne Planung von „mindestens fünf Jahren“ legt also noch nichts fest, was dieser Angabepflicht genügt.

Woran sich das Datum bemisst. Nach Art. 13 Abs. 8 UAbs. 2 CRA muss der Unterstützungszeitraum die Dauer der voraussichtlichen Nutzung widerspiegeln; zu berücksichtigen sind insbesondere die angemessenen Erwartungen der Nutzer, die Art des Produkts einschliesslich seiner Zweckbestimmung sowie einschlägige Unionsvorschriften zur Lebensdauer von Produkten. Ergänzend darf der Hersteller die Unterstützungszeiträume vergleichbarer Produkte anderer Hersteller, die Verfügbarkeit der Betriebsumgebung, die Unterstützungszeiträume integrierter Drittkomponenten mit Kernfunktion sowie Leitlinien der Verwaltungszusammenarbeitsgruppe (ADCO) und der Kommission heranziehen — alles in einer Weise, die die Verhältnismässigkeit wahrt. Belastbare Referenzwerte fehlen bislang, der Spielraum ist entsprechend gross (NK-CRA/Mehnert Art. 13 Rn. 23 [7]). Das ändert sich absehbar: Die ADCO veröffentlicht nach Art. 52 Abs. 16 UAbs. 2 CRA Statistiken über die durchschnittlich festgelegten Unterstützungszeiträume je Produktkategorie samt indikativen Leitlinien, und die Kommission kann nach Art. 13 Abs. 8 UAbs. 4 CRA Mindestunterstützungszeiträume für bestimmte Produktkategorien durch delegierte Rechtsakte festlegen — die dann nur für danach in Verkehr gebrachte Produkte gelten [7].

Die Abwägung gehört in die technische Dokumentation. Die bei der Festlegung berücksichtigten Informationen sind nach Art. 13 Abs. 8 UAbs. 5 CRA und Anhang VII Nr. 4 CRA in die technische Dokumentation nach Art. 31 CRA aufzunehmen. Das ist keine Formalie: Die Dokumentationspflicht soll sicherstellen, dass die Abwägung tatsächlich stattfindet und später überprüfbar ist (NK-CRA/Mehnert Art. 13 Rn. 27 [7]). Ein Enddatum ohne dokumentierte Herleitung erfüllt die Pflicht daher nur halb.

Die FAQ der Kommissionsdienststellen präzisiert das in Ziff. 4.5.2 [5]: Fünf Jahre sind eine Untergrenze, aber nicht automatisch genug — wird das Produkt voraussichtlich länger genutzt, muss der Unterstützungszeitraum entsprechend länger sein. Kürzer als fünf Jahre darf er nur ausfallen, wenn die Lebensdauer des Produkts tatsächlich kürzer ist. Das kann auch bei Abonnement-Software der Fall sein, die dem Nutzer nach Ablauf des Abonnements schlicht nicht mehr zur Verfügung steht — die FAQ nennt als Beispiel eine Antivirenlösung für Unternehmen, die ohne aktives Abonnement nicht mehr nutzbar ist; Begründung ist, dass manche Anwendungen ihrer Natur nach nur im Abonnementmodell bereitgestellt werden können. Ebenso behandelt die FAQ quelloffene Software, die ihr Hersteller nur über kostenpflichtige Supportleistungen im Abonnement monetarisiert: Weil die Software auch nach Ende des Abonnements weiter genutzt werden kann, muss der Hersteller einen Unterstützungszeitraum sicherstellen, der der Dauer des aktiven Abonnements entspricht.

Nach Ziff. 4.5.3 derselben FAQ dürfen Produkte auch nach Ablauf des Unterstützungszeitraums weiter auf dem Markt bereitgestellt werden — der vorhandene Lagerbestand darf also abverkauft werden. Für Einheiten, die neu in Verkehr gebracht werden (etwa eine spätere Produktionscharge desselben Modells), ist aber ein neuer Unterstützungszeitraum nach Art. 13 Abs. 8 CRA festzulegen [5]. Dahinter steht eine allgemeinere Regel: Der Unterstützungszeitraum wird für eine Produktserie festgelegt, nicht für jedes einzelne ausgelieferte Exemplar (NK-CRA/Mehnert Art. 13 Rn. 26 [7]). Das widerspricht der exemplarbezogenen Betrachtung des Inverkehrbringens nicht, sondern knüpft an etwas anderes an: Ob ein Produkt in Verkehr gebracht wurde, entscheidet sich je Exemplar; der Unterstützungszeitraum wird für die Serie bestimmt. Praktisch folgt daraus: Wer eine Serie von vornherein über einen langen Zeitraum vertreiben will, erhöht damit die angemessene Nutzererwartung — und muss den Unterstützungszeitraum entsprechend länger ansetzen.

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, Wiebe, § 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 sollte möglichst sicherstellen, dass die für seinen Unterstützungszeitraum relevanten Drittanbieter-Komponenten ebenfalls über diesen Zeitraum mit Sicherheitsupdates versorgt werden; andernfalls muss er die Schwachstellenbehandlung auf anderem Weg gewährleisten [4, Wiebe, § 6 Rn. 27, Praxishinweis; 5, Ziff. 4.3.7]. Wo ein Individualvertrag mit dem Zulieferer möglich ist, sollte der zugesicherte Unterstützungszeitraum daher mindestens dem eigenen Unterstützungszeitraum entsprechen. Bei Komponenten, die nur über Standard-AGB oder als Open-Source-Software bezogen werden und sich vertraglich nicht verhandeln lassen, kann der Hersteller die Pflicht insbesondere durch die Auswahl ausreichend langfristig gepflegter Komponenten, laufendes Monitoring, produktseitige Massnahmen und gegebenenfalls eine Exit-Strategie absichern — und dies dokumentieren.

Wenn der Fall dennoch eintritt: Läuft der Unterstützungszeitraum einer integrierten Komponente vor dem eigenen ab und lässt sich eine Schwachstelle deshalb weder über den Komponentenhersteller noch durch Minderungsmassnahmen ausreichend beheben, entfällt die Pflicht des Herstellers nicht. Er muss die Schwachstelle dann auf anderem Weg beseitigen — etwa durch Austausch der Komponente oder durch Entwicklung eines eigenen Patches (FAQ der Kommissionsdienststellen, Ziff. 4.3.7) [5].

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 Herstellerpflichten [4, Wiebe, § 4 Rn. 38; § 6 Rn. 4]. Er muss aber auf überprüfbare Weise eine Cybersicherheitsstrategie entwickeln und dokumentieren (Art. 24 Abs. 1 CRA) und auf Verlangen mit den Marktüberwachungsbehörden zusammenarbeiten (Art. 24 Abs. 2 CRA). Ab dem 11. Dezember 2027 unterliegt er der Meldepflicht für aktiv ausgenutzte Schwachstellen, soweit er an der Entwicklung beteiligt ist, sowie den Meldepflichten für schwerwiegende Sicherheitsvorfälle, soweit von ihm für die Entwicklung bereitgestellte Netz- und Informationssysteme betroffen sind (Art. 24 Abs. 3 i. V. m. Art. 71 Abs. 2 CRA; FAQ Ziff. 5.5) [5]. 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. Wie weit die Verantwortung für integrierte Open-Source-Komponenten reicht, behandelt Teil 12 dieser Serie.

Praktische Beispiele

1. E-Reader-Software mit Cloud-Speicher (Abschnitt 8.3.3 der veröffentlichten Guidance)

Ein Hersteller bringt eine E-Reader-Software auf den Markt — ein Produkt mit digitalen Elementen (Art. 3 Nr. 1 CRA). Die Software nutzt einen externen SaaS-Speicherdienst, um die von Kunden gekauften E-Books zu speichern und zugänglich zu machen — dieser Dienst wurde nicht vom Hersteller der E-Reader-Software entwickelt.

  • 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 eine seiner Funktionen (Speicherung und Zugriff auf gekaufte Bücher) nicht ausführen.
  • Element 3 (Herstellerverantwortung): verneint — der Speicherdienst ist eine Standard-SaaS eines Drittanbieters, nicht vom E-Reader-Hersteller konzipiert und entwickelt.

Klassifikation: Element 2 erfüllt, Element 3 verneint → Drittanbieter-Ferndienst (Stufe B), keine RDPS; zur Rechtsnatur der Sorgfalt siehe oben.

Sorgfaltsmassnahmen gegenüber dem Anbieter (entsprechend Art. 13 Abs. 5):

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

Produktseitige Minderungsmassnahmen:

  • Sichere Authentifizierung, Verschlüsselung und Integritätsschutz der Kommunikation mit dem Speicherdienst (Abschnitt 8.3.3).
  • In den Nutzerinformationen darauf hinweisen, dass die Speicherung über einen externen Dienst erfolgt; die Verantwortung des Herstellers für sein Produkt bleibt davon unberührt (Rn. 161).

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 typischerweise Standard-Drittanbieterdienste, nicht vom App-Hersteller konzipiert und entwickelt.

Klassifikation: Typischerweise Drittanbieter-Ferndienst (Stufe B), keine RDPS; zur Rechtsnatur der Sorgfalt siehe oben.

Sorgfaltsmassnahmen gegenüber dem Anbieter (entsprechend Art. 13 Abs. 5):

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

Produktseitige Minderungsmassnahmen:

  • 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 konzipiert und entwickelt; OpenAI bzw. Anthropic stellen sie als Standardprodukt bereit.

Klassifikation: Drittanbieter-Ferndienst (Stufe B), keine RDPS. Massgeblich ist Element 3: Die API-Software wurde nicht vom Produkthersteller konzipiert und entwickelt. Dass dabei Nutzerdaten an den API-Anbieter übermittelt werden, ändert daran nichts. Zur Rechtsnatur der Sorgfalt siehe oben.

Sorgfaltsmassnahmen gegenüber dem Anbieter (entsprechend Art. 13 Abs. 5):

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

Produktseitige Minderungsmassnahmen:

  • 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 konzipiert und entwickelt und wird von ihm betrieben, nicht vom App-Hersteller.

Klassifikation: Drittanbieter-Ferndienst (Stufe B), keine RDPS; zur Rechtsnatur der Sorgfalt siehe oben.

(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.)

Sorgfaltsmassnahmen gegenüber dem Anbieter (entsprechend Art. 13 Abs. 5):

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

Produktseitige Minderungsmassnahmen:

  • Verschlüsselung der Signalisierungs- und Mediendaten, soweit vom Dienst unterstützt.
  • Im Produkthandbuch offenlegen, dass die Videokonferenz über einen externen Dienst läuft; die Herstellerverantwortung für das Produkt bleibt unberührt.

Konkrete Handlungsschritte für Hersteller (Stufe B)

  1. Inventur: Erstellen Sie eine Datei mit allen Drittanbieter-Ferndiensten, die Ihr Produkt nutzt.

- Spalten: Dienst, Anbieter, Funktion, Klassifikation (RDPS / Drittanbieter-Ferndienst / Risikobewertung), Akteurstyp (Hersteller / Verwalter quelloffener Software nach Art. 24 CRA) - Diese Datei ist Ihre erste CRA-Dokumentation

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

- Sicherheitsnachweise (ISO-27001-Zertifikat oder SOC-2-Prüfbericht) - Security-Whitepaper oder Datenblatt - Richtlinie zur Schwachstellenoffenlegung - Reaktionszeit bei Sicherheitsvorfällen - Einhaltung relevanter Regulierungen (DSGVO, NIS-2-Richtlinie [3] etc.) - Zugesicherter Support- und Update-Zeitraum (Gleichlauf mit eigenem Art. 13 Abs. 8 CRA-Zeitraum) - Bei Drittanbietern von Fernverarbeitungsdiensten zusätzlich: Nachweise nach der NIS-2-Durchführungsverordnung (EU) 2024/2690, nach DORA (Verordnung (EU) 2022/2554), eine Zertifizierung nach dem Cybersecurity Act (Verordnung (EU) 2019/881) oder ein Konformitätsnachweis nach ISO/IEC 27017:2015 bzw. ISO/IEC 27001:2022 — diese Nachweise lassen sich nach Rn. 207 der veröffentlichten Guidance unterstützend für die eigene Bewertung heranziehen

  1. Produktseitige Minderungsmassnahmen (Rn. 168–169):

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

  1. Vertragliche Absicherung: Verträge mit Drittanbietern sollten, soweit risikoadäquat und verhandelbar, insbesondere folgende Punkte abdecken:

- Verpflichtung des Anbieters, Sicherheitsdokumentation zu pflegen - Verpflichtung zur Mitteilung bei bekannten Sicherheitslücken - Recht des Herstellers, Sicherheitsaudits durchzuführen - Nachweise zu den für die sichere Integration erforderlichen Eigenschaften und Sicherheitsmassnahmen des Anbieters - Mindest-Unterstützungszeitraum, der dem eigenen Unterstützungszeitraum nach Art. 13 Abs. 8 CRA entspricht

  1. Laufendes Monitoring:

- Monats- oder quartalsweise Überprüfung: Gab es neue Sicherheitsvorfälle 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 tatsächlich integrierten Komponenten; für entfernte Dienste vertragliche Vulnerability- und Incident-Mitteilungen als Risikomassnahme

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

Nicht alles, was sich mit dem Internet verbindet, ist funktional notwendig. Manche Verbindungen dienen nur Informations- oder Statistikzwecken und erfüllen weder die RDPS-Kriterien noch die Voraussetzungen der Stufe B. 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 funktional notwendiger Drittanbieter-Ferndienst. 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 funktional notwendigen Drittanbieter-Ferndienst ist Stufe C kein regelungsfreier Raum. Anker ist Art. 13 Abs. 2 CRA: 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: „Welchen Stack-Trace hatte der Fehler?“)
  • Analytics (Aggregierte Nutzungsmuster)
  • Versionsabfragen nur, soweit ohne sie keine Produktfunktion entfällt; dienen sie der Benachrichtigung über verfügbare oder der automatischen Verteilung von Sicherheitsupdates, ist die Funktionsfrage regelmässig zu bejahen (Rn. 190 Ziff. v; Anhang I Teil I Nr. 2 Buchst. c CRA)
  • Logging-Services für Debugging

Rn. 192–193 (Kapitel 8 der Guidance): Telemetrie und die Funktionsfrage

Anders als die oben behandelten Due-Diligence-Randnummern stehen diese beiden Passagen im RDPS-Kapitel 8 der veröffentlichten Guidance und nicht in Kapitel 7.3. Inhaltlich ziehen sie unmittelbar die Grenze für Stufe C.

Rn. 192 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. Dient Telemetrie nur statistischen Zwecken oder der künftigen Produktentwicklung und beeinträchtigt ihr Wegfall keine Produktfunktion, verneint die Guidance deshalb Element 2. Der Grund ist 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 Drittanbieter-Ferndienst sein (entschieden über Element 3). Massgeblich ist stets die Funktionsfrage — nicht, dass Daten „Telemetrie“ heissen oder auf einem Server des Herstellers verarbeitet werden.

Rn. 193: Auch wenn Telemetrie keine RDPS ist, bedeutet das nicht „keine Pflicht“. Nach Art. 13 Abs. 2 CRA muss der Hersteller die Cyberrisiken des Produkts bewerten; die Guidance weist ergänzend darauf hin, dass dabei gegebenenfalls weitere Massnahmen für solche Datenverbindungen zu erwägen sind. Für die Praxis empfiehlt es sich daher, die Angriffsfläche der Verbindung zu analysieren, risikogerechte produktseitige Schutzmassnahmen festzulegen und das Ergebnis in der Risikobewertung zu dokumentieren.

Das Telemetrie-Graustufen-Problem

Eine häufige Frage: Ab wann wird Telemetrie zum funktional notwendigen Drittanbieter-Ferndienst oder gar zur 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 Personalisierungsdienst selbst entwickelt, liegt eine RDPS vor (Stufe A); ist es ein Standard-Drittanbieterdienst, liegt ein Drittanbieter-Ferndienst der Stufe B vor.

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.

Zwei Abgrenzungen sind mitzudenken. Erstens: Bietet das Produkt eine ferne Sicherheitsfunktion als Produktfunktion an (etwa eine Live-Bedrohungserkennung auf Basis dieser Telemetrie), ist Element 2 zu bejahen; der Fall läuft wie Beispiel 2 über Stufe A oder B (Rn. 190–192). Zweitens: Dient eine Versionsabfrage der Benachrichtigung über Sicherheitsaktualisierungen oder ihrer Verteilung (Anhang I Teil I Nr. 2 Buchst. c CRA), ist die Funktionsfrage regelmässig zu bejahen (siehe „Was fällt hier hinein?“).

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 Behandlung einzelner Datenverbindungen in Risikobewertung und Sorgfalt — nicht die Meldepflichten. Ausführlich dazu der Artikel zu den CRA-Meldepflichten.

Vertragliche Absicherung bei Drittanbieter-Ferndiensten (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“.

Der CRA erhöht die Anforderungen an belastbare Nachweise. Der Hersteller benötigt genügend Informationen, um die Auswirkungen des Ferndienstes auf die Sicherheit des eigenen Produkts risikobasiert zu bewerten. Welche Unterlagen dafür erforderlich und angemessen sind, hängt von Art und Risiko der Abhängigkeit ab.

Vertragliche Absicherung ist vor allem in Stufe B gefragt. Der Hersteller nutzt hier einen fremdentwickelten, funktional notwendigen Ferndienst und muss dessen Sicherheitseigenschaften für die Produktrisikobewertung greifbar machen. Bei Stufe A gibt es für die RDPS selbst keinen Dritten, mit dem zu kontrahieren wäre: Für herstellereigene Server-Software trägt der Hersteller unmittelbar Verantwortung; Verträge werden nur bei Unterlieferanten und Infrastruktur, etwa einem IaaS-Anbieter, relevant. In Stufe C genügt regelmässig eine leichtere Behandlung, weil die eigene Risikobewertung im Vordergrund steht. Die folgenden Vertragsklauseln richten sich daher an Stufe-B-Konstellationen. Wo der Drittanbieter keinen verhandelbaren Vertrag anbietet, treten sorgfältige Dienstauswahl, Monitoring und produktseitige Minderungsmassnahmen an die Stelle einer individuellen Klauselgestaltung.

Wesentliche Änderungen beim Drittanbieter — keine automatische Neubewertung des Produkts, aber Update der Risikobewertung

Ein häufiger Irrtum: Ändert ein Drittanbieter-Ferndienst grundlegend seine Lösung, löst das nach Rn. 208 der veröffentlichten Guidance nicht automatisch eine „wesentliche Änderung“ des Herstellerprodukts im Sinne des CRA aus — denn diese Elemente unterliegen nicht der Verantwortung des Herstellers. Der Hersteller ist gleichwohl gehalten, in seinen Vereinbarungen mit Drittanbietern von Fernverarbeitungsdiensten die am besten geeigneten Sicherheitsmassnahmen umzusetzen und darauf hinzuwirken, dass ihn der Anbieter über Änderungen angemessen informiert. Wird der Hersteller über eine solche Änderung informiert, kann das Anlass sein, seine eigene Risikobewertung zu überarbeiten. Eine entsprechende Informationspflicht des Anbieters gehört deshalb in die Klausel zur Sicherheitsdokumentation der folgenden Vertragsmuster.

Vertragsklauseln für Drittanbieter

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

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

Der Anbieter informiert den Hersteller mit angemessenem Vorlauf über wesentliche Änderungen der Lösung, die die Sicherheit des integrierenden Produkts berühren können. ```

2. Klausel zur Mitteilung von Sicherheitslücken `` 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, mindestens jährliche Sicherheitsaudits durchzuführen
  • Sicherheitsupdates mindestens während des Unterstützungszeitraums

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

4. Auditierungsrecht `` 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 Datenverarbeitungen der Stufe A (RDPS)

Dies wird in Teil 2 dieser Serie behandelt. Kurz: vollständige CRA-Compliance mit SBOM, Konformitätsbewertung nach Art. 32 CRA und Schwachstellenbehandlung.

Für tatsächlich integrierte Komponenten (Art. 13 Abs. 5 und 6 CRA)

  • [ ] SBOM: Komponente in der SBOM erfasst? (siehe Artikel 07)
  • [ ] Sorgfaltsniveau: Risikobasiert festgelegt (FAQ Ziff. 4.4.2)?
  • [ ] Schwachstellen und Updates: Bekannte Schwachstellen und Update-Historie der Komponente geprüft (Erwägungsgrund 34 CRA)?
  • [ ] Unterstützungszeitraum: Unterstützungszeitraum der Komponente mit dem eigenen abgeglichen (FAQ Ziff. 4.3.7)?
  • [ ] Meldeweg: Meldeweg zur Person oder Einrichtung, die die Komponente herstellt oder wartet, nach Art. 13 Abs. 6 CRA festgelegt — einschliesslich der Weitergabe selbst entwickelter Sicherheitsfixes?
  • [ ] Vertiefung: Teil 12 dieser Serie (Bundles, Komponenten und Open Source)

Für Datenverarbeitungen der Stufe B (Drittanbieter-Ferndienst)

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

- [ ] ISO-27001-Zertifikat oder SOC-2-Prüfbericht? - [ ] Security-Whitepaper oder Datenblatt? - [ ] Patch-Management-Policy? - [ ] Richtlinie zur Schwachstellenoffenlegung? - [ ] Zugesicherter Support- und Update-Zeitraum? - [ ] Bei Fernverarbeitungsdiensten: Nachweise nach NIS-2-DVO 2024/2690, DORA, Cybersecurity-Act-Zertifizierung oder ISO/IEC 27017:2015 / 27001:2022 (Rn. 207 der Guidance)? - [ ] Lieferanten-Kurzfragebogen an einem anerkannten Baseline-Katalog ausgerichtet (z. B. OWASP SCVS) statt Eigenentwicklung? (Praxisempfehlung der ENISA, Playbook 4.14 — unverbindlich [6])

  • [ ] Risikobewertung: Integriert in die Produktrisikoanalyse?

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

  • [ ] Produktseitige Minderungsmassnahmen implementiert:

- [ ] Kryptographische Authentifizierung? - [ ] Datenverschlüsselung vor dem Versand? - [ ] Integritätsprüfungen (HMAC, Signaturen)? - [ ] Fallback-Mechanismen bei Dienstausfällen? - [ ] Minimale Datenweitergabe (Datenminimierung)?

  • [ ] Verträge aktualisiert:

- [ ] Anforderung an die Sicherheitsdokumentation? - [ ] Mitteilung von Sicherheitslücken? - [ ] SLA für Patch-Management? - [ ] Auditierungsrecht? - [ ] Mindest-Unterstützungszeitraum (Gleichlauf mit Art. 13 Abs. 8 CRA)? - [ ] Informationspflicht des Anbieters bei grösseren Änderungen der Lösung (Rn. 208 der Guidance)?

  • [ ] Meldekanäle:

- [ ] B2A-Meldeprozess nach Art. 14 CRA über die Plattform nach Art. 16 CRA? - [ ] B2B-Meldeprozess nach Art. 13 Abs. 6 CRA für tatsächlich integrierte Komponenten? - [ ] Vertragliche Vulnerability- und Incident-Mitteilungen für den entfernten Dienst selbst?

  • [ ] Monitoring eingerichtet:

- [ ] Sicherheitsmitteilungen des Anbieters abonniert? - [ ] Quartalsmässige Überprüfung der Anbieter-Sicherheitslage? - [ ] Dokumentation im Risikoprotokoll des Produkts? - [ ] Ausnahmen-Log für akzeptierte Lieferketten-Risiken mit benanntem Verantwortlichen und Ablaufdatum? (Praxisempfehlung der ENISA, Playbook 4.14 — unverbindlich [6])

Für Datenverarbeitungen der Stufe C (weder RDPS noch funktional notwendiger Drittanbieter-Ferndienst)

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

- [ ] Man-in-the-Middle-Risiken? - [ ] Datenleck-Risiken? - [ ] Risiken eines Dienstausfalls?

  • [ ] Produktseitige Schutzmassnahmen:

- [ ] TLS/HTTPS für alle Verbindungen? - [ ] Certificate Pinning (falls möglich)? - [ ] Datenminimierung (nur notwendige Daten senden)? - [ ] Opt-out-Möglichkeit (für Telemetrie etc.)?

  • [ ] Dokumentation in Risikobewertung:

- [ ] Warum ist dieser Service akzeptabel? - [ ] Welche Restrisiken verbleiben? - [ ] Wie werden diese gemindert?

  • [ ] Kontinuierliche Überprüfung:

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

Das Wichtigste für Hersteller

  • Die Stufen A, B und C beschreiben, wie eine einzelne Datenverbindung zu behandeln ist. Das Produkt selbst unterliegt in jeder Stufe vollständig dem CRA, einschliesslich der Meldepflichten nach Art. 14.
  • Für jede relevante Datenverbindung ist die Risikobewertung nach Art. 13 Abs. 2 verbindlich. Für funktional notwendige Drittanbieter-Ferndienste (Stufe B) erwartet die Guidance zusätzlich eine entsprechende Sorgfalt (Rn. 201, 202 lit. c, 207 f.).
  • Für tatsächlich integrierte Komponenten gelten die Sorgfaltspflicht nach Art. 13 Abs. 5 und die Meldekette nach Art. 13 Abs. 6 unmittelbar — einschliesslich der Weitergabe selbst entwickelter Sicherheitsfixes.
  • Der Unterstützungszeitraum wird als Enddatum festgelegt; die Herleitung gehört in die technische Dokumentation. Davon zu unterscheiden sind die Verfügbarkeit von Sicherheitsupdates und die Aufbewahrung der technischen Dokumentation (jeweils mindestens zehn Jahre oder die längere Dauer des Unterstützungszeitraums).
  • Ausgangspunkt der Umsetzung ist eine Inventur aller Drittanbieter-Ferndienste mit Klassifikation, Nachweisen und Vertragsklauseln (siehe Checkliste).

Bei Ihrem Produkt können mehrere Datenverbindungen unterschiedlich zu behandeln sein. Der CRA-Quick-Check bietet eine kostenlose und unverbindliche Ersteinschätzung zur CRA-Anwendbarkeit, Produktklasse, CRA-Bereitschaft und möglichen Abdeckung durch crAIready. Für die endgültige Klassifikation ist eine Einzelfallprüfung erforderlich.

Hinweis zur Methodik

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

  • Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 3 Nr. 14 (Definition Verwalter quelloffener Software), Art. 13 Abs. 2, 5, 6, 8 (einschliesslich UAbs. 2 bis 5 — Abwägungsfaktoren, Fünf-Jahres-Untergrenze, delegierte Rechtsakte, Aufnahme in die technische Dokumentation), 9, 13 und 19 (Angabe des Enddatums des Unterstützungszeitraums), Art. 14 (Meldepflichten), Art. 16 (einheitliche Meldeplattform), Art. 24 (Verwalter quelloffener Software), Art. 31 und Anhang VII Nr. 4 (technische Dokumentation; einschlägige Informationen zur Festlegung des Unterstützungszeitraums), Art. 32 (Konformitätsbewertung), Art. 52 ff. CRA i. V. m. VO (EU) 2019/1020 (Marktüberwachung; darunter Art. 52 Abs. 16 — ADCO-Statistik und Leitlinien zu Unterstützungszeiträumen), Art. 64 Abs. 2–5 und 10 (Geldbussen, Bemessung und Ausnahmen), Art. 71 Abs. 2 (Geltungsbeginn), Anhang I Teil I Nr. 2 Buchst. c (Sicherheitsaktualisierungen) sowie Erwägungsgrund 19 (Verwalter quelloffener Software), Erwägungsgrund 34 (Sorgfalt bei der Integration von Komponenten) und Erwägungsgrund 60 (Hardware- und Software-Lebenszyklen jenseits von 5 Jahren). Für Art. 13 Abs. 8 UAbs. 1 und Art. 64 Abs. 10 wurde die Berichtigung vom 2. Juli 2025 berücksichtigt [8].
  • Communication C(2026) 5252 final mit Annex (von der Kommission am 27.07.2026 veröffentlichte, nicht verbindliche Guidance; sie schafft keine zusätzlichen Pflichten), insbesondere:

- Kapitel 7.3 „Risk assessment and due diligence in relation to external dependencies and integrated components“, Rn. 167–173 (Due Diligence und Risikobewertung) - Kapitel 8.2, Rn. 203–208 (RDPS-spezifische Umsetzungshinweise zur Due Diligence, inkl. der wiederverwendbaren Nachweis-Artefakte in Rn. 207 und der Klarstellung zu Drittanbieter-Änderungen in Rn. 208) - Rn. 190–193 (Funktionsbegriff einschliesslich Update-Verteilung; Telemetrie und nicht-funktionale Datenverarbeitung, Kapitel 8) - Abschnitt 8.3.3 (E-Reader-Beispiel) - Rn. 161 (keine Verlagerung der Verantwortung auf Nutzer oder Dritte) - Rn. 201–202 (Behandlung von Drittanbieter-Ferndiensten ähnlich Komponenten; die Drei-Klassen-Klassifikation) - Kapitel 9.2.1, Rn. 222–229 (Meldung an den Upstream-Maintainer und Weitergabe von Sicherheitsfixes nach Art. 13 Abs. 6 CRA)

  • FAQs on the Cyber Resilience Act, Version 1.4 vom 04.09.2026 (FAQ der Kommissionsdienststellen), insbesondere Ziff. 4.3.1 (Behandlung von Schwachstellen), 4.3.6 (Behandlung von Schwachstellen in integrierten Komponenten, Weitergabe des Sicherheitsfixes), 4.3.7 (Ende des Unterstützungszeitraums einer Komponente), 4.4.2 (angemessener Grad der Sorgfalt), 4.4.4 (freiwillige Sicherheitsattestierungsprogramme für quelloffene Komponenten), 4.5.2 (Mindest-Unterstützungszeitraum, Abonnementmodelle), 4.5.3 (Bereitstellung nach Ablauf des Unterstützungszeitraums) und 5.5 (Pflichten der Verwalter quelloffener Software). Die FAQ geben lediglich die Auffassung der Kommissionsdienststellen wieder und ausdrücklich keine offizielle Position der Europäischen Kommission. Die Kommissions-Guidance wurde dagegen als Communication C(2026) 5252 final veröffentlicht. Beide Dokumente sind nicht verbindlich; institutionell besitzen sie jedoch nicht dasselbe Gewicht.
  • ENISA, Secure by Design and Default Playbook, Version 1.0, Juli 2026, Kapitel 4.14 „Supply-chain controls“ — als unverbindliche technische Praxishilfe für zwei Checklistenpunkte (Lieferanten-Kurzfragebogen nach OWASP SCVS, Ausnahmen-Log mit Verantwortlichem und Ablaufdatum)
  • NK-CRA (Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026): juristischer Kommentar zur Auslegung des Art. 13 Abs. 8 CRA, insbesondere zur Bestimmung des Unterstützungszeitraums durch ein Enddatum statt durch eine Dauer, zu den Abwägungsfaktoren und zum Verhältnismässigkeitsgrundsatz, zum Serienbezug, zur Aufnahme der Abwägung in die technische Dokumentation sowie zum Massstab der abstrakten Gefahr (Mehnert, Art. 13 Rn. 21, 23, 25–27) sowie zur Bemessungsgrundlage bei Art. 64 CRA (Kühne, Art. 64 Rn. 34) [7]
  • CRA-Kommentar Wiebe (Nomos 2025): juristischer 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 Sonderkategorie des Verwalters quelloffener Software nach Art. 24 CRA (jeweils Wiebe) sowie zur Konzern-Bemessungsgrundlage bei Art. 64 CRA (Jossen) [4].

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, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, veröffentlicht am 27.07.2026. Die Guidance ersetzt für diese Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sie ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Rn. 161; Kapitel 7.3 (Rn. 167–173); Kapitel 8 (Rn. 190–208 einschliesslich Kapitel 8.2 und Abschnitt 8.3.3); Kapitel 9.2.1 (Rn. 222–229). Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation (Annex-Download: https://ec.europa.eu/newsroom/dae/redirection/document/131456).

[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, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 4 Rn. 38 (Verwalter quelloffener Software, Art. 24 CRA; kein Wirtschaftsakteur); Wiebe, § 6 Rn. 4 (Pflichtenprofil des Verwalters), Rn. 20 (B2B-Meldekette, Art. 13 Abs. 6 CRA), Rn. 25–27 (Mindest-Unterstützungszeitraum, Art. 13 Abs. 8 CRA; Rn. 27 zu Erwägungsgrund 60 — auch Software wie Betriebssysteme und Videobearbeitungstools sowie Produkte für industrielle Umgebungen wie industrielle Steuerungssysteme typischerweise länger als fünf Jahre genutzt; Praxishinweis zu Rn. 27 zum vertraglichen Gleichlauf), Rn. 35 (10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA); Jossen, § 7 Rn. 57 und Fn. 44 (Konzernumsatz als Bemessungsgrundlage, EuGH-Rechtsprechung zu Art. 101/102 AEUV; im deutschen OWi-Recht nur Erfahrungssatz).

[5] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026. Von den Kommissionsdienststellen erstellt; nach eigener Angabe keine offizielle Position der Europäischen Kommission und nicht verbindlich; lebendes Dokument, das fortlaufend aktualisiert wird. Insbesondere Ziff. 4.3.1, 4.3.6, 4.3.7, 4.4.2, 4.4.4, 4.5.2, 4.5.3 und 5.5. Verfügbar unter: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions.

[6] ENISA, „Secure by Design and Default Playbook — A Practical Guide to Secure by Design and Default Principles for SMEs“, Version 1.0, Juli 2026, Kapitel 4.14 „Supply-chain controls“. Unverbindliche technische Praxishilfe; nach eigener Angabe keine Rechtsberatung, und die Befolgung der Prinzipien stellt weder eine Zertifizierung nach Normen noch die Einhaltung regulatorischer Vorgaben sicher.

[7] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Mehnert, Art. 13 Rn. 21 (für die Pflicht aus Art. 13 Abs. 8 CRA genügt die abstrakte Gefahr in Gestalt einer Schwachstelle, unabhängig von deren möglicher Schwere), Rn. 23 (Abwägungsfaktoren, Verhältnismässigkeitsgrundsatz, fehlende Referenzwerte, ADCO-Statistik nach Art. 52 Abs. 16 CRA, delegierte Rechtsakte nach Art. 13 Abs. 8 UAbs. 4 CRA), Rn. 25 (Bestimmung des Unterstützungszeitraums durch ein Enddatum statt durch eine Dauer; Vereinbarkeit allein dieser Lösung mit der Angabepflicht aus Art. 13 Abs. 19 CRA), Rn. 26 (Festlegung für die Produktserie; längere Vertriebszeit führt über die Nutzererwartung zu einem längeren Unterstützungszeitraum) und Rn. 27 (Aufnahme der massgeblichen Informationen in die technische Dokumentation nach Art. 31 CRA und Anhang VII); anders noch Mehnert, Art. 3 Rn. 121 (fester Zeitraum oder Enddatum); Kühne, Art. 64 Rn. 34 (Zweifel an der Übertragung des Begriffs der wirtschaftlichen Einheit auf den CRA).

[8] Berichtigung der Verordnung (EU) 2024/2847, ABl. L 2025/90555 vom 2. Juli 2025, unter anderem zu Art. 13 Abs. 8 UAbs. 1 (statt „während der erwarteten Produktlebensdauer und des Unterstützungszeitraums“ nun „während des Unterstützungszeitraums“) und zu Art. 64 Abs. 10: Die Einleitung wurde von einer Abweichung von den Absätzen 3 bis 9 auf eine Abweichung von den Absätzen 2 bis 9 berichtigt. https://eur-lex.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj

[9] Stripe, „Integration Security Guide“; Square Developer, „Online payment options“ — Herstellerdokumentation, abgerufen am 12.10.2026.

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. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 30.03.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: CRA-Grauzone: Hybrid-SaaS, Plugins und fünf offene RDPS-Fälle — 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?