Von Redaktion codAIx | 30. März 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. 202 des veröffentlichten Guidance-Entwurfs):

| 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. Die Nichteinhaltung dieser Pflichten 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 des veröffentlichten Guidance-Entwurfs (Kapitel 7.3 „Risk assessment and due diligence in relation to external dependencies and integrated components“, Rn. 167 sowie 170–172) 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.

Der veröffentlichte Guidance-Entwurf 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 integrierter Komponenten. Gemeinsam sollen beide Pflichten sicherstellen, dass das Produkt sicher bleibt — auch dort, wo es auf Datenfernverarbeitungslösungen, Fernverarbeitungsdienste oder Software-/Hardwarekomponenten Dritter angewiesen ist.

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. „Angemessen“ heisst nicht „perfekt“, aber es heisst auch nicht „vertraue dem Verkaufsversprechen“: 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).

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. Welche Evidenz dafür ausreicht:

  • 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 neue, 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 — für Compliance-Zwecke behandelt der Hersteller sie jedoch als extern bezogene Komponenten, deren Eigenschaften er bei der Integration durch Due Diligence verifiziert (etwa hinsichtlich der Infrastruktur, auf der ein Dienst läuft, und der daraus entstehenden Netzwerk-Abhängigkeiten).

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

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]. Der veröffentlichte Guidance-Entwurf 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).

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; ein selbst entwickelter Sicherheitsfix ist zusätzlich weiterzugeben

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) — Untergrenze fünf Jahre, festzulegen als Enddatum. Art. 13 Abs. 8 CRA verpflichtet den Hersteller, Sicherheitsupdates über einen bestimmten Zeitraum bereitzustellen — regelmässig mindestens fünf Jahre [4, § 6 Rn. 25–27]. 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/Hofmann/Iffländer, 1. Aufl. 2026, CRA Art. 13 Rn. 21 [7]). Der CRA verlangt also keine schwachstellenfreie Software, wohl aber die Behandlung jeder Schwachstelle — unabhängig davon, wie kritisch sie im Einzelfall ist. 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].

Das Ergebnis dieser Festlegung ist ein Datum, keine Zeitspanne. In der Praxis wird der Unterstützungszeitraum meist als Dauer gedacht — „fünf Jahre“. Damit ist die Pflicht aber noch nicht erfüllt. Der juristische Kommentar von Schröder/Hartl bestimmt den Unterstützungszeitraum nicht über eine Dauer, sondern über ein festes Enddatum: Die Verordnung regelt nirgends, wann er zu laufen beginnt — Herstellungsende, Abgabe an den Endnutzer und Inverkehrbringen scheiden jeweils aus eigenen Gründen als Anknüpfungspunkt aus —, und nur ein Enddatum lässt sich mit der Angabepflicht in Einklang bringen (NK-CRA/Hofmann/Iffländer, 1. Aufl. 2026, CRA Art. 13 Rn. 25 [7]). Der Verordnungstext bestätigt das: 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. Wer intern „mindestens fünf Jahre“ plant, hat damit noch nichts festgelegt, was dieser Angabepflicht genügt.

Woran sich das Datum bemisst. Massgeblich sind nach Art. 13 Abs. 8 UAbs. 2 CRA die voraussichtliche Nutzungsdauer, die angemessenen Erwartungen der Nutzer und die Art des Produkts einschliesslich seiner Zweckbestimmung. 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. Für Stufe-B-Hersteller ist der Komponentenfaktor der praktisch wichtigste: Der eigene Unterstützungszeitraum lässt sich nicht belastbar länger ansetzen, als die integrierten Komponenten ihn tragen (dazu sogleich der vertragliche Gleichlauf). Belastbare Referenzwerte fehlen bislang, der Spielraum ist entsprechend gross (NK-CRA/Hofmann/Iffländer, 1. Aufl. 2026, CRA 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/Hofmann/Iffländer, 1. Aufl. 2026, CRA 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. Umgekehrt gilt für 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/Hofmann/Iffländer, 1. Aufl. 2026, CRA 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, § 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.

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 Mitigationsmassnahmen 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 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 des veröffentlichten Guidance-Entwurfs)

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 nutzt einen externen SaaS-Speicherdienst, um die von Kunden gekauften E-Books zu speichern und zugänglich zu machen — dieser Dienst wurde nicht vom E-Reader-Hersteller 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 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: Erstellen Sie eine Datei mit allen Drittanbieter-Services, die Ihr 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 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:

- 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) - 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 des veröffentlichten Guidance-Entwurfs unmittelbar für die eigene Due Diligence wiederverwenden

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

- 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 - Zusicherung, 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: „Welchen Stack-Trace hatte der Fehler?“)
  • Analytics (Aggregierte Nutzungsmuster)
  • Update-Checks (nur Versionsnummern-Abfrage, nicht die Daten selbst)
  • Logging-Services für Debugging

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

Diese beiden Randnummern stehen — anders als die Due-Diligence-Randnummern oben — im RDPS-Kapitel 8 des veröffentlichten Guidance-Entwurfs, nicht im Due-Diligence-Kapitel 7.3. Inhaltlich betreffen sie unmittelbar die Abgrenzung des Stufe-C-Falls.

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. 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. 193: 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.

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

Ein häufiger Irrtum: Ändert ein Drittanbieter-Fernverarbeitungsdienst grundlegend seine Lösung, löst das nach Rn. 208 des veröffentlichten Guidance-Entwurfs 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. Diese Informationspflicht gehört deshalb konsequent in die Sicherheitsdokumentation-Klausel und die Vulnerability-Notification-Klausel der folgenden Vertragsmuster.

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? - [ ] 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 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)? - [ ] 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 an Komponentenhersteller?

  • [ ] Monitoring eingerichtet:

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

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 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 (zentrale 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/3/4 (Bussgelder), Erwägungsgrund 19 (Verwalter quelloffener Software) und Erwägungsgrund 60 (Hardware- und Software-Lebenszyklen jenseits von 5 Jahren)
  • Communication C(2026) 5252 final, Annex (von der Kommission am 27.07.2026 inhaltlich gebilligter Guidance-Entwurf; die förmliche Annahme soll nach Vorliegen aller Sprachfassungen erfolgen. Erst danach soll die Guidance als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft keine zusätzlichen verbindlichen 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. 192–193 (Telemetrie und nicht-funktionale Datenverarbeitung, Kapitel 8) - Abschnitt 8.3.3 (E-Reader-Beispiel) - Rn. 202 (die Drei-Klassen-Klassifikation) - Kapitel 9.2.1, Rn. 222–228 (Meldung an den Upstream-Maintainer und Weitergabe von Sicherheitsfixes nach Art. 13 Abs. 6 CRA)

  • FAQs on the Cyber Resilience Act, Version 1.3 vom 01.07.2026 (FAQ der Kommissionsdienststellen), insbesondere Ziff. 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) und 4.5.3 (Bereitstellung nach Ablauf des Unterstützungszeitraums). Die FAQ geben lediglich die Auffassung der Kommissionsdienststellen wieder und ausdrücklich keine offizielle Position der Europäischen Kommission. Der Annex zu C(2026) 5252 enthält dagegen den von der Kommission inhaltlich gebilligten Entwurf ihrer Guidance nach Art. 26 CRA. Förmlich angenommen ist diese Guidance noch nicht. Beide Dokumente schaffen keine verbindlichen Pflichten; 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.), Nomos 2026) als juristischen 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 (Art. 13 Rn. 21, 23, 25–27) [7]
  • 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: 06.08.2026 (v15 — die Kommentierung zu Art. 13 CRA aus NK-CRA/Hofmann/Iffländer, 1. Aufl. 2026, Rn. 21–27, in den Drei-Fristen-Block eingearbeitet: Der Unterstützungszeitraum wird nicht als Dauer, sondern durch ein festes Enddatum bestimmt (Rn. 25) — passend zur Angabepflicht nach Art. 13 Abs. 19 CRA, die mindestens Monat und Jahr verlangt; Abwägungsfaktoren und Verhältnismässigkeitsgrundsatz nach Art. 13 Abs. 8 UAbs. 2 CRA ergänzt, einschliesslich des für Stufe B zentralen Faktors der Unterstützungszeiträume integrierter Komponenten, der künftigen ADCO-Statistik nach Art. 52 Abs. 16 UAbs. 2 CRA und möglicher delegierter Rechtsakte nach Art. 13 Abs. 8 UAbs. 4 CRA (Rn. 23); Pflicht zur Aufnahme der Abwägungsinformationen in die technische Dokumentation nach Art. 13 Abs. 8 UAbs. 5 CRA und Anhang VII Nr. 4 CRA ergänzt (Rn. 27); Serienbezug des Unterstützungszeitraums und die Wirkung einer von vornherein langen Vertriebszeit klargestellt, mit Abgrenzung zur exemplarbezogenen Betrachtung des Inverkehrbringens (Rn. 26); Hinweis ergänzt, dass für die Pflicht aus Art. 13 Abs. 8 CRA bereits die abstrakte Gefahr in Gestalt einer Schwachstelle genügt (Rn. 21). Quellenverzeichnis um [7] und Methodik entsprechend erweitert. v14 (06.08.2026) — belegte Ergänzungen aus der FAQ der Kommissionsdienststellen (Version 1.3 vom 01.07.2026) und dem ENISA-Playbook, keine Korrekturen: Drei-Fristen-Block um die Klarstellungen aus FAQ 4.5.2 zu Abonnement-Modellen ergänzt (fünf Jahre als Untergrenze, kürzerer Zeitraum bei Software, die nach Ablauf des Abonnements nicht mehr verfügbar ist, Gleichlauf mit der Abonnementdauer bei quelloffener Software) sowie um FAQ 4.5.3 (Abverkauf von Lagerbestand zulässig, neuer Unterstützungszeitraum für neu in Verkehr gebrachte Einheiten); Abschnitt zur B2B-Meldekette um die Weitergabepflicht für selbst entwickelte Sicherheitsfixes nach Art. 13 Abs. 6 CRA erweitert (FAQ 4.3.6, Guidance Kapitel 9.2.1, Rn. 223 und 225–228: maschinenlesbares, überprüfbares und lizenzkompatibles Format; Vermeidung von Doppelmeldungen; Wegfall der Meldepflicht bei bereits bekannter Schwachstelle oder fehlendem Maintainer); Fall des vorzeitigen End-of-Life einer integrierten Komponente nach FAQ 4.3.7 ergänzt; Due-Diligence-Abschnitt um die erweiterten Massnahmen aus FAQ 4.4.2 und den Hinweis auf freiwillige Sicherheitsattestierungsprogramme nach FAQ 4.4.4 ergänzt; Stufe-B-Checkliste um zwei Praxispunkte aus dem ENISA-Playbook 4.14 erweitert; Quellenverzeichnis um [5] und [6] ergänzt. v13 (05.08.2026) — Artikel auf die finale Guidance C(2026) 5252 final, Annex umgestellt, deren Inhalt die Kommission am 27.07.2026 gebilligt hat; sie ersetzt den bisher zitierten Entwurf Ares(2026)2319816 vom 03.03.2026. Die allgemeine Due-Diligence-Pflicht nach Art. 13 Abs. 5 CRA wird in der finalen Fassung in einem eigenen Kapitel 7.3 behandelt (Rn. 167–173) statt — wie im Entwurf — im RDPS-Kapitel; die bisher zitierten Rn. 151 sowie 154–156 wurden entsprechend auf Rn. 167, 170–172 umgestellt. Die RDPS-spezifischen Umsetzungshinweise zur Due Diligence, einschliesslich einer neuen Liste wiederverwendbarer Nachweis-Artefakte (NIS-2-Durchführungsverordnung (EU) 2024/2690, DORA, Cybersecurity-Act-Zertifizierung, ISO/IEC 27017:2015, ISO/IEC 27001:2022), stehen jetzt in Kapitel 8.2 (Rn. 203–208) und wurden im Due-Diligence-Abschnitt sowie in den Checklisten ergänzt. Die Telemetrie-Randnummern wurden von Rn. 176–177 auf Rn. 192–193 aktualisiert, die Drei-Klassen-Klassifikation von Rn. 186 auf Rn. 202. Neu ergänzt: die Klarstellung aus Rn. 208, wonach eine wesentliche Änderung bei einem Drittanbieter-Fernverarbeitungsdienst keine „wesentliche Änderung“ des Herstellerprodukts auslöst, der Hersteller aber seine Risikobewertung aktualisieren sollte, wenn er über solche Änderungen informiert wird. Quellenverzeichnis und Fussnote zur Guidance entsprechend aktualisiert. v9 (26.05.2026) — 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).

Versionshinweis (v17, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 30.03.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Versionshinweis (v16, 12.08.2026): Der Verfahrensstatus des im Annex zu C(2026) 5252 final veröffentlichten Guidance-Entwurfs wurde präzisiert; die Bezeichnung als finale Guidance wurde im aktuellen Artikeltext korrigiert. FAQ und Guidance werden nicht mehr als einfache Rangstufen dargestellt, sondern nach Urheber, Verfahrensstatus und institutionellem Gewicht unterschieden. Die historischen Versionshinweise bleiben unverändert.

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, Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“, Inhalt von der Kommission gebilligt am 27.07.2026. Der Annex ersetzt für die Auswertung den Entwurf Ares(2026)2319816 vom 03.03.2026. Sobald alle Sprachfassungen vorliegen, soll die Guidance förmlich angenommen werden. Erst ab dieser Annahme soll sie als offizielle Auslegungshilfe der Kommission verwendet werden. Sie schafft jedoch keine zusätzlichen verbindlichen Pflichten; diese ergeben sich aus dem CRA und anderen verbindlichen Rechtsakten (Stand 12.08.2026). Kapitel 7.3 (Rn. 167–173), Kapitel 8.2 (Rn. 203–208) und 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 (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).

[5] Europäische Kommission (Dienststellen), „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.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.6, 4.3.7, 4.4.2, 4.4.4, 4.5.2 und 4.5.3. 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, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 13 kommentiert von Hofmann und Iffländer. Herangezogen: CRA 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).

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: 30.03.2026. Zuletzt geprüft am: 13.08.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)

Stand: 13.08.2026 (v18 — freigegebene Schlusskorrektur: unvollständigen Satz, Anredewechsel, Kasus, Komposita und missverständliche Anglizismen korrigiert. Vorherige Fassung: v17; zeitabhängige Formulierungen unverändert.)