Neu — veröffentlicht am 27. Juli 2026

EU-Kommissions-Guidance zum EU CRA

Die offizielle Auslegung der EU-Kommission im Überblick — veröffentlicht am 27. Juli 2026 (C(2026) 5252 final)

Dokument veröffentlicht: 27. Juli 2026 · Zusammenfassung zuletzt geprüft von Kunnus: 28. Juli 2026

84

Seiten

9

Kapitel

67

Praxisbeispiele

Nicht

rechtlich bindend

Original-Guidance als PDF herunterladenEuropäische Kommission — C(2026) 5252 final, 27. Juli 2026, 84 Seiten (Englisch)

Was ist die EU-Kommissions-Guidance zum Cyber Resilience Act?

Am 27. Juli 2026 hat die Europäische Kommission ihre Guidance zur Anwendung des Cyber Resilience Act veröffentlicht (C(2026) 5252 final). Artikel 26 Abs. 1 des EU CRA verpflichtet die Kommission zu dieser Guidance — mit besonderem Fokus auf die Erleichterung der Compliance für kleine und mittlere Unternehmen. Vorausgegangen waren eine Konsultation der Expert Group on Cybersecurity of Products with Digital Elements und eine öffentliche Konsultation (März–April 2026).

Das Dokument klärt die in der Praxis umstrittensten Fragen: Wann ist Standalone-Software „in Verkehr gebracht“? Wann fällt Open Source in den Scope? Wann ist ein Software-Update eine wesentliche Änderung? Wie wird der Supportzeitraum bestimmt? Und was zählt als Remote Data Processing? Auf dieser Seite fassen wir alle Kapitel zusammen — verlinkt mit den betroffenen CRA-Artikeln, Erwägungsgründen und Anhängen unserer Wissensdatenbank.

1

Kapitel 1: Einleitung

Abschnitt 1.1 – 1.2

Einleitung: Rechtsrahmen und Zweck der Leitlinien

Kapitel 1 ordnet das Dokument ein: Der CRA baut auf dem New Legislative Framework der EU auf; Marktüberwachung und Durchsetzung liegen bei den nationalen Behörden. Die Leitlinien erfüllen den Auftrag aus Artikel 26 Abs. 1 — mit besonderem Fokus auf KMU —, sind rechtlich nicht bindend und ersetzen keine Einzelfallprüfung. Verbindlich auslegen kann den CRA nur der Gerichtshof der Europäischen Union.

Kernaussagen

  • Pflichtthemen nach Art. 26 Abs. 2 — und genau die deckt das Dokument ab: Anwendungsbereich (insb. Remote Data Processing und FOSS), Supportzeiträume, Zusammenspiel mit anderem EU-Recht und der Begriff der wesentlichen Änderung.
  • Die Leitlinien ergänzen die Kommissions-FAQ vom 3. Dezember 2025; vorausgegangen sind die Konsultation der Expert Group on Cybersecurity of Products with Digital Elements und eine öffentliche Konsultation (3. März – 13. April 2026).
  • Adressaten sind Wirtschaftsakteure UND Behörden: Auch Marktüberwachung, notifizierende Behörden und notifizierte Stellen sollen sich für eine EU-weit einheitliche Durchsetzung daran orientieren.
  • Die zahlreichen Beispiele illustrieren nur — sie ersetzen nie die Bewertung des konkreten Einzelfalls.
  • Weitere Guidance ist ausdrücklich angekündigt, etwa zum Zusammenspiel des CRA mit dem AI Act (VO 2024/1689) und DORA (VO 2022/2554).
  • Hintergrund: Der CRA folgt dem New Legislative Framework (VO 765/2008, Beschluss 768/2008/EG); die Marktüberwachung richtet sich nach VO 2019/1020. Die Kommission plant mit dem „European Product Act“ eine Modernisierung des NLF.

Für die Praxis

Nutzen Sie die Leitlinien als Argumentationsgrundlage gegenüber Auditoren, notifizierten Stellen und Marktüberwachung — zitieren Sie konkret Abschnitt und Randnummer. Verlassen Sie sich aber nicht blind auf die Beispiele: Dokumentieren Sie immer Ihre eigene Einzelfallbewertung, denn rechtlich bindend sind die Leitlinien nicht. Und behalten Sie die angekündigte Folge-Guidance (AI Act, DORA) im Blick, wenn Ihre Produkte auch dort betroffen sind.

Verknüpfte CRA-Vorschriften

Art. 26
2

Kapitel 2: Anwendungsbereich

Abschnitt 2.1

Inverkehrbringen von Standalone-Software

Standalone-Software gilt als in Verkehr gebracht, sobald die Herstellungsphase abgeschlossen ist und die Software erstmals zum Vertrieb oder zur Nutzung auf dem EU-Markt angeboten wird. Alle Kopien derselben Version gelten als zum selben Zeitpunkt in Verkehr gebracht — unabhängig davon, wann einzelne Nutzer sie herunterladen.

Kernaussagen

  • Der Zeitpunkt des ersten Angebots zählt für alle Kopien einer Version — spätere Downloads sind nur ein „Bereitstellen auf dem Markt“ derselben Produkte.
  • Iterationen ohne wesentliche Änderung verschieben das Datum des Inverkehrbringens nicht; erst eine wesentliche Änderung gilt als neues Inverkehrbringen (vgl. Kapitel 4 der Leitlinien).
  • Varianten mit unterschiedlichen Komponenten, Konfigurationen oder Funktionsumfängen (z. B. Builds je Betriebssystem, unterschiedliche Feature-Bundles) sind eigenständige Produkte.

Beispiel aus der Guidance

Version 1.0.0 wird am 1. Januar 2028 erstmals über die Website angeboten. Kunde 1 kauft am selben Tag, Kunde 2 am 15. Januar. Beide Kopien gelten als am 1. Januar 2028 in Verkehr gebracht (Beispiel 1 der Leitlinien).

Für die Praxis

Halten Sie pro Software-Version das Datum des ersten Angebots fest — es bestimmt, ab wann die CRA-Pflichten für alle Kopien dieser Version laufen. Führen Sie außerdem eine Liste Ihrer Varianten (Builds je Betriebssystem, Feature-Bundles): Jede Variante ist ein eigenes Produkt mit eigenem Datum.

Verknüpfte CRA-Vorschriften

Art. 2Art. 3EG 41
Abschnitt 2.2

Software als Produkt — Web-Apps und Websites

Software ist nur dann ein Produkt mit digitalen Elementen, wenn sie dem Nutzer bereitgestellt und auf dessen System ausgeführt wird. Web-Apps, die ausschließlich über den Browser genutzt werden, und reine Informations-Websites sind selbst keine Produkte — sie fallen nur als Remote Data Processing in den Scope, wenn sie eine Funktion eines Produkts unterstützen.

Kernaussagen

  • Lokal installierte Anwendungen sind Produkte — auch Browser-Extensions und mit Web-Technologien gebaute Desktop-Apps, die lokal ausgeführt werden.
  • Web-Apps und Progressive Web Apps, die nur im Browser laufen, sind keine Produkte mit digitalen Elementen (Erwägungsgründe 11 und 12).
  • Ein lokal installierter Client plus die Datenverarbeitung „at a distance“, auf die er für seine Funktionen angewiesen ist, bilden zusammen das Produkt.

Für die Praxis

Sortieren Sie Ihr Portfolio in drei Körbe: (1) läuft lokal beim Nutzer (App, Desktop-Client, Browser-Extension) → Produkt im CRA-Sinn; (2) reine Browser-Anwendung oder Info-Website → kein Produkt; (3) Backend, das eine Produktfunktion trägt → als Remote Data Processing prüfen (Kapitel 8 der Leitlinien).

Verknüpfte CRA-Vorschriften

Art. 2Art. 3EG 11EG 12
Abschnitt 2.3

Computercode — Quellcode und Maschinencode

Sowohl Maschinencode als auch Quellcode sind „Software“ im Sinne von Artikel 3 Nr. 4. Entscheidend ist, ob die Bereitstellung im Rahmen einer Geschäftstätigkeit erfolgt: Öffentlich geteilter FOSS-Code, unfertiger Code in der Entwicklung sowie Demo- und Tutorial-Code gelten nicht als in Verkehr gebracht — kommerziell an Kunden lizenzierter Quellcode dagegen schon.

Kernaussagen

  • Wer Kunden Quellcode als Produkt liefert, bringt ihn in Verkehr — auch wenn der Kunde ihn erst anpassen und kompilieren muss (Beispiel 7).
  • Der Lizenzgeber ist nicht für die CRA-Konformität der nachgelagerten Anpassungen des Kunden verantwortlich.
  • Unfertige Software (Alpha, Beta, Release Candidate) darf nach Artikel 4 Abs. 3 zeitlich begrenzt zu Test- und Feedback-Zwecken bereitgestellt werden.

Für die Praxis

Prüfen Sie Ihre Lizenz- und Lieferverträge: Wo geben Sie Kunden Quellcode gegen Entgelt? Für diesen Code tragen Sie die vollen Herstellerpflichten — nicht aber für das, was der Kunde daraus macht. Demo-Code, Tutorials und Beta-Versionen zu Testzwecken bleiben außen vor.

Verknüpfte CRA-Vorschriften

Art. 3Art. 4
Abschnitt 2.4

Hardware + Software als ein Produkt

Ob Software Teil eines Produkts ist, bestimmt nicht der Auslieferungsweg, sondern ob die Software für die bestimmungsgemäßen Funktionen des Produkts erforderlich ist. Separat bezogene Treiber und Companion-Apps (z. B. aus dem App Store) bilden mit der Hardware ein einziges Produkt mit digitalen Elementen.

Kernaussagen

  • Netzwerkdrucker + zum Download bereitgestellte Treiber = ein Produkt, weil der Drucker ohne Treiber seinen Zweck nicht erfüllt (Beispiel 8).
  • Fitness-Wearable + Companion-App = ein Produkt, weil beide zusammenwirken sollen (Beispiel 9).
  • Das Inverkehrbringen der Software erfolgt zeitgleich mit dem der Hardware-Einheiten.

Für die Praxis

Ordnen Sie jede Companion-App und jeden Treiber dem zugehörigen Hardware-Produkt zu: Sie gehören in dessen Risikobewertung, SBOM, technische Dokumentation und Konformitätsbewertung — nicht in eine eigene. Der Auslieferungsweg (App Store, Download-Link) spielt keine Rolle.

Verknüpfte CRA-Vorschriften

Art. 3
Abschnitt 2.5

Datenverbindung — Abgrenzung zu bloßer Elektronik

Der CRA-Scope knüpft an eine Datenverbindung an, nicht an das bloße Vorhandensein von Elektronik. Eine Datenverbindung setzt voraus, dass binäre Zustände von einem Sender bewusst als Information codiert und vom Empfänger als Daten decodiert werden können. Elektrische Signale, die nur eine Funktion auslösen oder mit Strom versorgen, begründen keinen CRA-Scope.

Kernaussagen

  • Bloßes Ein-/Ausschalten eines Ausgangs (0/1) ist keine Datenverbindung, wenn die Zustände keine Information repräsentieren sollen.
  • Erforderlich: ein Sender, der digitale Symbole nach einem definierten Schema erzeugt, und ein Empfänger, der sie als Daten interpretieren kann.
  • Die Grenze trennt Produkte, die an digitaler Kommunikation teilnehmen (und Cyberrisiken ausgesetzt sind), von rein elektrisch angesteuerten Produkten.

Für die Praxis

Stellen Sie je Produkt eine einzige Frage: Sendet oder empfängt es bewusst codierte Daten (Protokoll, Bus, Funk, serielle Schnittstelle)? Nur dann ist es im CRA-Scope. Produkte, die Signale nur schalten oder Strom führen, können Sie mit dieser Begründung dokumentiert aussteuern.

Verknüpfte CRA-Vorschriften

Art. 2Art. 3
Abschnitt 2.6

Komplexe Systeme und Interoperabilitäts-Constraints

Komplexe Systeme mit langen Entwicklungszyklen, Alt-Komponenten und Interoperabilitätszwängen sind nicht vom CRA ausgenommen — ihre Constraints fließen aber in den risikobasierten Ansatz ein. Wo einzelne wesentliche Anforderungen nicht oder nicht voll umsetzbar sind (vgl. Erwägungsgrund 55), müssen Hersteller die Constraints dokumentieren, die Risiken bewerten und kompensierende Maßnahmen treffen.

Kernaussagen

  • Ein unsicheres Legacy-Protokoll darf implementiert werden, wenn es für Interoperabilität nötig ist und die Risiken anderweitig mitigiert werden; unterstützt das Produkt beide Protokolle, muss das sichere der Default sein (Beispiel 10).
  • Constraints, Risiken und Mitigationen gehören transparent in die technische Dokumentation (Art. 31, Anhang VII) und die Nutzerinformationen (Anhang II).
  • Constraints sind während des Supportzeitraums regelmäßig neu zu bewerten; entfallen sie, muss das Produkt entsprechend nachgezogen werden.
  • Vor CRA-Geltung beschaffte Komponenten dürfen integriert werden, wenn die Risikobewertung keine spezifischen Risiken ergibt und das Gesamtprodukt die Anforderungen erfüllt (Beispiel 11).

Für die Praxis

Legen Sie für jede nicht (voll) erfüllbare Anforderung ein Constraint-Dossier an: Warum nicht umsetzbar (z. B. Interoperabilitätszwang), welches Risiko entsteht, welche Kompensationsmaßnahme greift — und terminieren Sie die Neubewertung. Genau diese Dokumentation wird die Marktüberwachung sehen wollen.

Verknüpfte CRA-Vorschriften

Art. 13EG 55Anhang IAnhang IIAnhang VII
Abschnitt 2.7

Vor CRA-Geltung entwickelte Produkte — kein Redesign-Zwang

Produkte, die vor dem 11. Dezember 2027 entworfen, aber danach in Verkehr gebracht werden, müssen nicht zwingend neu designt werden. Der Hersteller führt eine aktuelle Risikobewertung durch; zeigt sie, dass vorhandene Maßnahmen die Risiken adressieren, kann er darauf die Konformität stützen. Historische Design- und Testdokumentation muss nicht rekonstruiert werden.

Kernaussagen

  • Konformitätsbewertungsverfahren, EU-Konformitätserklärung und CE-Kennzeichnung bleiben in jedem Fall Pflicht.
  • Keine Pflicht, Testnachweise aus der ursprünglichen Designphase nachzuliefern; Tests können über Produktfamilien gebündelt werden (Abschnitt 7.4 der Leitlinien).
  • Schwachstellenbehandlung (Anhang I Teil II), aktuelle Risikobewertung (Art. 13 Abs. 3) und Nutzerinformationen (Art. 13 Abs. 18) gelten uneingeschränkt.

Beispiel aus der Guidance

Ein vor CRA-Geltung entwickelter Mikrocontroller darf ohne Redesign weiter in Verkehr gebracht werden, wenn eine aktuelle Risikobewertung zeigt, dass die vorhandenen Sicherheitsmaßnahmen die identifizierten Risiken abdecken (Beispiel 12).

Für die Praxis

Planen Sie für Bestandsdesigns kein Redesign ein, bevor die Risikobewertung eines verlangt: Eine aktuelle Risikobewertung plus der Nachweis, dass vorhandene Maßnahmen die Risiken abdecken, genügt. Historische Design- und Testdoku müssen Sie nicht rekonstruieren — Konformitätserklärung und CE-Kennzeichnung bleiben aber Pflicht.

Verknüpfte CRA-Vorschriften

Art. 13Art. 32Anhang IAnhang VII
3

Kapitel 3: Freie und Open-Source-Software

Abschnitt 3.1 – 3.2

Open Source: Wann ist FOSS „in Verkehr gebracht“?

Entscheidend ist die Monetarisierung durch den Verantwortlichen (Maintainer), nicht die Finanzierung der Entwicklung: Preis für Binaries, Monetarisierung anderer Dienste über die Software, verpflichtende Datenverarbeitung oder kostenpflichtige Versionen mit Support-Vorteilen bedeuten Inverkehrbringen. Freiwillige Donations, optionale Beratung und Dritt-Sponsoring lösen für sich genommen keinen CRA-Scope aus.

Kernaussagen

  • FOSS-Definition (Art. 3 Nr. 48) verlangt kumulativ eine FOSS-Lizenz mit allen Rechten und öffentlich geteilten Quellcode — Code nur für zahlende Kunden ist kein FOSS.
  • Verantwortlich ist, wer Releases, Roadmap und Distribution kontrolliert; Contributors ohne diese Kontrolle unterliegen dem CRA nicht, selbst mit Commit-Rechten (Beispiel 13).
  • Community-Version und kostenpflichtige (Open-Core-)Version sind zwei verschiedene Produkte — die kostenlose Version bleibt außerhalb des Markts.
  • Optionale bezahlte Services (Consulting, Training, Deployment-Hilfe) sind unschädlich; kostenpflichtiger Zugang zu einer Version mit technischem Support ist dagegen Monetarisierung (Beispiele 17/18).
  • Donations sind erst kritisch, wenn sie de facto Zugangsbedingung sind — etwa Releases oder Security-Fixes nur für Spender (Beispiele 21/22); Kostendeckung inkl. angemessener Lebenshaltungskosten ist zulässig.
  • Dritt-Finanzierung (Grants, Bug Bounties, bezahlte Feature-Entwicklung) macht FOSS nicht kommerziell (Erwägungsgrund 18, Beispiel 23).

Für die Praxis

Gehen Sie Ihre Open-Source-Projekte einzeln durch und beantworten Sie zwei Fragen: Kontrollieren wir Releases und Distribution? Und verdienen wir an genau dieser Version (Preis, Monetarisierung über die Software, Pflicht-Datenverarbeitung, Bezahlversion mit Support)? Nur bei zweimal Ja sind Sie Hersteller. Donations-Link, Sponsoring und optionale Beratung ändern daran nichts.

Verknüpfte CRA-Vorschriften

Art. 2Art. 3EG 15EG 18
Abschnitt 3.3

Open-Source-Stewards — abgestufte Pflichten

Stewards sind juristische Personen, die FOSS mit kommerzieller Zweckbestimmung nachhaltig unterstützen, ohne es in Verkehr zu bringen (Art. 3 Nr. 14, Art. 24). Die Leitlinien staffeln die Melde-Pflichten nach Art der Unterstützung: rein nicht-technischer Support, Infrastruktur-Hosting oder aktive Engineering-Beiträge.

Kernaussagen

  • Die Rolle gilt pro FOSS-Projekt: Dieselbe Organisation kann für Produkt A Steward und für Produkt B Hersteller sein (z. B. Community- vs. Bezahlversion).
  • Nur nicht-technischer Support (Branding, Governance, Events, Donations): keine Meldepflicht für aktiv ausgenutzte Schwachstellen — Informationen aber an die Maintainer weitergeben; freiwillige Meldung nach Art. 15 erwägen.
  • Infrastruktur-Steward (Repos, Versionskontrolle, Signing Keys): schwerwiegende Vorfälle mit Auswirkung auf die Produktsicherheit an ENISA/CSIRT melden (Art. 14 Abs. 3), Nutzer ggf. informieren.
  • Engineering-Steward (Entwickler, Releases, Vulnerability-Handling): aktiv ausgenutzte Schwachstellen melden (Art. 14 Abs. 1) und Nutzer informieren (Art. 14 Abs. 8).
  • Not-for-Profit-Entitäten, deren Erträge satzungsgemäß gemeinnützigen Zwecken dienen, bringen ihre FOSS auch bei Monetarisierung nicht in Verkehr — es gelten Steward-Pflichten (Beispiel 24: Browser mit Suchmaschinen-Partnerschaft).

Für die Praxis

Klären Sie pro FOSS-Projekt, welche Art Unterstützung Sie leisten — nur Governance/Branding, Infrastruktur (Repos, Signing Keys) oder aktives Engineering. Daraus folgt direkt, welche Melde- und Informationspflichten aus Artikel 24 Sie treffen. Dieselbe Organisation kann für Projekt A Steward und für Projekt B Hersteller sein.

Verknüpfte CRA-Vorschriften

Art. 14Art. 15Art. 24EG 19
Abschnitt 3.4 – 3.5

Contributors, Integration und die FOSS-Szenarien

Wer FOSS-Komponenten in eigene Produkte integriert, wird dadurch nicht für deren eigene CRA-Konformität verantwortlich — auch nicht durch Code-Beiträge zu deren Pflege. Es gelten die Due-Diligence-Pflicht (Art. 13 Abs. 5) und die Upstream-Pflichten (Art. 13 Abs. 6). Acht Szenarien (Beispiele 27–34) spielen die typischen Konstellationen aus Entwicklern, Foundations und integrierenden Herstellern durch.

Kernaussagen

  • Einzelentwickler mit Donation-Link: keine CRA-Pflichten; integrierende Hersteller schulden Due Diligence (Beispiele 27, 34).
  • FOSS, das für die Integration durch andere Hersteller bestimmt ist und nicht monetarisiert wird, gilt nicht als in Verkehr gebracht — der Publisher ist ggf. Steward (Beispiele 25/26, 29).
  • Der CRA-Status einer FOSS-Komponente ändert sich nicht dadurch, dass Hersteller sie in monetarisierte Produkte integrieren.
  • Auch Paket-Repositories treffen keine CRA-Pflichten (Beispiel 34).

Für die Praxis

Führen Sie eine Liste aller integrierten FOSS-Komponenten mit Version, Bezugsquelle und Maintainer-Kontakt. Das ist die Arbeitsgrundlage für Ihre Due Diligence (Art. 13 Abs. 5) und für Upstream-Meldungen samt Fix-Sharing (Art. 13 Abs. 6) — für die Konformität der Komponente selbst sind Sie dagegen nicht verantwortlich.

Verknüpfte CRA-Vorschriften

Art. 13EG 18
4

Kapitel 4: Wesentliche Änderungen und Ersatzteile

Abschnitt 4.1 – 4.2

Reparaturen und Ersatzteile

Reparatur, Refurbishment und Wartung sind in der Regel keine wesentliche Änderung, solange Zweckbestimmung und Risikoniveau unverändert bleiben. Die Ersatzteil-Ausnahme (Art. 2 Abs. 6) greift nur, wenn das Teil erkennbar zur Reparatur eines bestehenden Produkts geliefert wird; „identisch“ bemisst sich an den sicherheitsrelevanten Eigenschaften, nicht an Bauteilgleichheit.

Kernaussagen

  • Austausch eines defekten Teils gegen ein besser performendes ist für sich keine wesentliche Änderung (Beispiel 35: schnellerer RAM im Server).
  • Neuer Chipsatz mit gleichen Protokollen und Sicherheitsmechanismen kann „identisch“ sein (Beispiel 38); geänderte Krypto-Implementierung oder Secure-Boot-Mechanismus dagegen nicht (Beispiel 37).
  • Der Reparaturzweck muss aus dem Lieferkontext hervorgehen (Produktbezug in Bestellung/Angebot, After-Sales-Kanal) — Nachweise für die Marktüberwachung vorhalten.
  • Die Ausnahme gilt auch für den Austausch ganzer Module oder Teilprodukte innerhalb größerer Systeme (Beispiel 39: CPU-Einheit oder komplette SPS).

Für die Praxis

Dokumentieren Sie bei jedem Ersatzteil den Reparaturbezug (Produkt in Bestellung/Angebot benannt, Lieferung über After-Sales-Kanal) und vergleichen Sie sicherheitsrelevante Eigenschaften — Krypto, Protokolle, Secure Boot, Zugriffskontrollen — statt Bauteilnummern. Nur so können Sie die Art.-2-Abs.-6-Ausnahme gegenüber der Marktüberwachung belegen.

Verknüpfte CRA-Vorschriften

Art. 2EG 29EG 42
Abschnitt 4.3

Software-Updates als wesentliche Änderung

Maßstab ist nicht der Umfang der Änderung, sondern ihre Wirkung auf das Risikoprofil: Ändert ein Update den bewerteten Verwendungszweck oder schafft es neue, nicht in der Risikobewertung erfasste Risiken, ist es eine wesentliche Änderung. Sicherheitsupdates sind es grundsätzlich nicht. Vier Prüfkriterien (Rn. 110) strukturieren die Einzelfallbewertung.

Kernaussagen

  • In der ursprünglichen Risikobewertung bereits antizipierte und bewertete Features lösen keine wesentliche Änderung aus — auch nicht das spätere Aktivieren vorhandener, bewerteter Funktionen (Beispiele 42/43).
  • Auch kleine Features können wesentlich sein: ein „Remember me“-Login mit lokal gespeicherten Tokens schafft neue Risiken (Token-Diebstahl, Session Hijacking — Beispiel 44).
  • Sicherheitsupdates sind nur ausnahmsweise wesentlich — etwa wenn sie Zweckbestimmung, Datenflüsse oder Abhängigkeitsstruktur grundlegend ändern (Beispiele 49/50: lokale Verschlüsselung wird Cloud-Service; externes Key-Management ersetzt internes).
  • Prüfkriterien (Rn. 110): neue Bedrohungsvektoren, neue Angriffsszenarien, veränderte Eintrittswahrscheinlichkeit, veränderte Auswirkungen bekannter Szenarien.
  • Unabhängig von der Einstufung: Risikobewertung und technische Doku sind laufend aktuell zu halten (Art. 13 Abs. 7, Art. 31 Abs. 2).

Für die Praxis

Verankern Sie im Release-Prozess eine feste Prüffrage mit dokumentierter Antwort: Schafft dieses Update neue Bedrohungsvektoren oder Angriffsszenarien, oder verändert es Wahrscheinlichkeit/Auswirkung bekannter Szenarien? Nein und in der Risikobewertung abgedeckt → kein neues Inverkehrbringen. Ja → Risikobewertung nachziehen und prüfen, ob eine neue Konformitätsbewertung fällig ist.

Verknüpfte CRA-Vorschriften

Art. 3Art. 13EG 39
Abschnitt 4.4

Folgen einer wesentlichen Änderung

Ein wesentlich geändertes Produkt gilt bei Bereitstellung als neu in Verkehr gebracht. Wer als Dritter wesentlich ändert, wird Hersteller (Art. 21/22) — bei komponentenbezogenen Änderungen aber nur für den geänderten Teil, sofern die Gesamt-Cybersicherheit nicht beeinträchtigt ist. Der Originalhersteller darf Dokumentation und Tests für unveränderte Teile wiederverwenden.

Kernaussagen

  • Abgrenzung zur Integration: Wer Komponenten zu einem neuen eigenen Produkt zusammenbaut, ist regulärer Hersteller des Gesamtprodukts — keine wesentliche Änderung fremder Produkte (Beispiel 51).
  • Alt-Produkte: Eine wesentliche Änderung nach dem 11. Dezember 2027 an einem davor in Verkehr gebrachten Produkt macht den Ändernden zum Hersteller (Art. 69 Abs. 2) — die Pflichten beschränken sich aber auf die geänderten Teile, solange die Gesamt-Cybersicherheit unberührt bleibt.
  • Die Pflichten des Originalherstellers für das ursprüngliche Produkt (Schwachstellenbehandlung, Konformität der unveränderten Teile) laufen weiter.
  • Konformitätsbewertung fokussiert auf die geänderten Teile; für unveränderte Teile dürfen vorhandene Tests und Doku wiederverwendet werden.

Für die Praxis

Zwei Fälle sauber trennen: Verändern Sie ein fremdes, bereits vermarktetes Produkt wesentlich, treffen Sie Herstellerpflichten — aber nur für den geänderten Teil, solange die Gesamt-Cybersicherheit unberührt bleibt. Bauen Sie dagegen Komponenten zu einem eigenen Produkt zusammen, sind Sie regulärer Hersteller des Gesamtprodukts. Vorhandene Tests und Doku für unveränderte Teile dürfen Sie weiterverwenden.

Verknüpfte CRA-Vorschriften

Art. 21Art. 22Art. 69EG 41
5

Kapitel 5: Supportzeitraum

Abschnitt 5 – 5.1

Supportzeitraum — Bestimmung, Art. 13 Abs. 10 und wesentliche Änderungen

Fünf Jahre sind Untergrenze, nicht Default: Der Supportzeitraum richtet sich nach der erwarteten Nutzungsdauer; länger genutzte Produkte brauchen längeren Support. Artikel 13 Abs. 10 erlaubt, die Schwachstellenbehebung auf die zuletzt in Verkehr gebrachte Version zu konzentrieren, wenn Nutzer kostenlos und ohne Zusatzkosten upgraden können. Eine wesentliche Änderung setzt den Supportzeitraum nicht automatisch zurück.

Kernaussagen

  • „Zusatzkosten“ im Sinne von Art. 13 Abs. 10 meint Hardware-Neukauf oder Infrastrukturwechsel — nicht normalen Update-Aufwand wie Personalzeit, Tests oder Konfigurationsanpassungen.
  • Jede wesentlich geänderte Version braucht bei Inverkehrbringen einen eigenen deklarierten Supportzeitraum nach Art. 13 Abs. 8.
  • Bestimmen unveränderte Faktoren (z. B. Hardware-Lebensdauer) weiterhin die Nutzungsdauer, bleibt der ursprüngliche Supportzeitraum maßgeblich — auch wenn die Restlaufzeit unter fünf Jahren liegt (Beispiele 54/55: Saugroboter, Industriemaschine mit neuem Cloud-Backend).
  • Verändert die Modifikation die Nutzungsdauer-Faktoren selbst (z. B. neue Rechenplattform verlängert Lebensdauer einer SPS), ist der Supportzeitraum neu zu berechnen (Beispiel 56).
  • Enddatum des Supports beim Kauf angeben (mindestens Monat/Jahr) und EOL-Benachrichtigung anzeigen, wo technisch machbar (Art. 13 Abs. 19).
  • Hersteller dürfen ältere Versionen freiwillig weiter patchen — auch kostenpflichtig; der CRA verlangt dafür keine Gratis-Updates.

Für die Praxis

Leiten Sie den Supportzeitraum dokumentiert aus der erwarteten Nutzungsdauer ab — pauschal „5 Jahre“ ist angreifbar, wenn Ihr Produkt erkennbar länger genutzt wird. Nennen Sie das Enddatum schon im Kaufprozess (mindestens Monat/Jahr). Bei Software: Prüfen Sie, ob Sie mit der Art.-13-Abs.-10-Regel nur die jeweils letzte Version patchen müssen — das setzt kostenlose Upgrades ohne Hardware-/Infrastrukturzwang voraus.

Verknüpfte CRA-Vorschriften

Art. 13EG 40EG 60Anhang I
6

Kapitel 6: Wichtige und kritische Produkte

Abschnitt 6.1

Kernfunktionalität — der Schlüssel zur Produktklassifizierung

Ob ein Produkt „wichtig“ (Anhang III) oder „kritisch“ (Anhang IV) ist, bestimmt allein seine Kernfunktionalität — die Hauptmerkmale, ohne die es seinen Zweck nicht erfüllen könnte. Zusatzfunktionen und integrierte Komponenten ändern die Einstufung nicht; jedes Produkt hat genau eine Kernfunktionalität, die in der technischen Dokumentation klar zu benennen ist.

Kernaussagen

  • Integration ist keine Einstufung: Ein Smartphone mit integriertem Betriebssystem hat nicht die Kernfunktionalität eines Betriebssystems (Beispiel 58).
  • Deutliches Über- oder Unterschreiten einer Kategorie fällt heraus: SOAR-Software ist kein SIEM (Beispiel 59), einfache Log-Sammel-Tools ohne Korrelation auch nicht (Beispiel 60).
  • Keine Gestaltung über Marketing: Widersprüche zwischen Werbematerial, Nutzungsanleitung und technischer Doku dürfen nicht genutzt werden, um dem strengeren Verfahren zu entgehen.
  • Auch separat vermarktete Module eines Produkts werden je eigenständig eingestuft (Beispiel 61: Security-Suite mit SIEM-, IDS- und Analytics-Modul).
  • Die technischen Beschreibungen der Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392.

Für die Praxis

Formulieren Sie für jedes Produkt einen Satz: „Ohne Funktion X erfüllt das Produkt seinen Zweck nicht.“ X ist die Kernfunktionalität — gleichen Sie nur X mit den Kategorien in Anhang III/IV (bzw. der Durchführungsverordnung 2025/2392) ab, nicht Ihre Feature-Liste. Achten Sie darauf, dass Werbematerial, Anleitung und technische Doku dieselbe Geschichte erzählen.

Verknüpfte CRA-Vorschriften

Art. 7Art. 8Anhang IIIAnhang IV
Abschnitt 6.2

Konformitätsbewertung wichtiger und kritischer Produkte

Klasse-II- und kritische Produkte brauchen eine Drittbewertung. Wichtige Produkte der Klasse I dürfen ins interne Kontrollverfahren (Modul A), wenn eine harmonisierte Norm vollständig angewendet wird, die mindestens alle Risiken der Kernfunktionalität abdeckt — Risiken darüber hinaus sind mit zusätzlichen, dokumentierten Maßnahmen zu adressieren.

Kernaussagen

  • FOSS-Ausnahme: Wichtige Produkte der Klassen I/II, die als FOSS in Verkehr gebracht werden, dürfen die Verfahren der Default-Kategorie nutzen (Art. 32 Abs. 5).
  • Antivirus mit Zusatzfunktionen (Disk-Cleaning, Anti-Tracking): Selbstbewertung möglich, wenn die Norm die Risiken der Kernfunktionalität abdeckt und die Zusatzrisiken dokumentiert behandelt werden (Beispiel 62).
  • Eine integrierte kritische Komponente zwingt das Gesamtprodukt nicht in deren strengeres Verfahren — maßgeblich bleibt die Kernfunktionalität des Gesamtprodukts (Beispiel 63: Router mit Firewall-Komponente).
  • Verstöße gegen Art. 32 können Bußgelder nach Art. 64 Abs. 3 auslösen.

Für die Praxis

Prüfen Sie für Klasse-I-Produkte zuerst, ob eine harmonisierte Norm alle Risiken der Kernfunktionalität abdeckt — davon hängt ab, ob Sie selbst bewerten dürfen (Modul A) oder eine notifizierte Stelle brauchen. Risiken von Zusatzfunktionen außerhalb der Norm müssen Sie mit eigenen, dokumentierten Maßnahmen schließen. FOSS-Produkte der Klassen I/II dürfen immer selbst bewerten.

Abschnitt 6.3

Konformitätsvermutung — nur soweit die Norm reicht

Harmonisierte Normen (sowie gemeinsame Spezifikationen und EU-Cybersicherheitszertifikate) begründen die Konformitätsvermutung nur für die von ihnen abgedeckten Risiken. Zusatzfunktionen außerhalb des Norm-Scopes profitieren nicht — für sie muss der Hersteller die Konformität separat nachweisen. Die Gesamtverantwortung für die Bewertung aller Produktrisiken bleibt beim Hersteller.

Kernaussagen

  • Deckt die Norm alle Risiken der Kernfunktionalität ab und gibt es keine risikoträchtigen Zusatzfunktionen, greift die Vermutung für das ganze Produkt.
  • Deckt die Norm nur einen Teil ab, gilt die Vermutung partiell — z. B. für Kernfunktionalität und Disk-Cleaning, nicht aber für eine Anti-Tracking-Funktion (Beispiele 64/65).
  • Auch mit angewendeter Norm bleibt die vollständige Risikobewertung nach Art. 13 Abs. 2 Pflicht (Blue Guide, Abschnitt 4.1.2.2).

Für die Praxis

Führen Sie eine Abdeckungs-Matrix: Welche Ihrer Produktrisiken deckt die angewendete Norm ab, welche nicht? Die Konformitätsvermutung gilt nur für die abgedeckten Risiken — für die Lücken brauchen Sie eigene Maßnahmen samt Nachweis. Die Norm ersetzt nie die vollständige Risikobewertung nach Art. 13 Abs. 2.

Verknüpfte CRA-Vorschriften

Art. 27
7

Kapitel 7: Risikobewertung und Komponenten-Integration

Abschnitt 7.1 – 7.2

Risikobewertung: kein eigener Risikoappetit, kein Risikotransfer

Anders als im organisatorischen Risikomanagement zählt nicht der eigene Risikoappetit: Restrisiken sind am Maßstab des „angemessenen Cybersicherheitsniveaus“ des Produkts zu messen. Kosten oder kommerzielle Erwägungen rechtfertigen keine unbehandelten Risiken — notfalls sind Design, Funktionsumfang oder Zweckbestimmung zu ändern. Ein Transfer von Risiken auf Nutzer oder Dritte ist keine zulässige Compliance-Strategie.

Kernaussagen

  • Zulässige Mitigationen umfassen auch Zweckbeschränkung plus klare Nutzerinformation — etwa ein Industriesensor, der nur für vertrauenswürdige Umgebungen bestimmt ist (Beispiel 66).
  • Hersteller dürfen auf reife Plattform-Funktionen setzen, z. B. native Verschlüsselung und Key-Management des Betriebssystems statt Eigenbau (Beispiel 67).
  • Anhang I Teil I Nr. 1 („angemessenes Cybersicherheitsniveau“) wirkt als Auffangnorm: erfüllt, wenn alle Risiken über die übrigen wesentlichen Anforderungen adressiert sind — sonst sind zusätzliche produktseitige Maßnahmen nötig.

Für die Praxis

Streichen Sie „akzeptiertes Restrisiko aus Kosten-/Geschäftsgründen“ aus Ihren Risiko-Templates — dieses Argument trägt unter dem CRA nicht. Zulässige Hebel sind: technische Maßnahmen, Zweckbeschränkung plus klare Nutzerinformation, Rückgriff auf reife Plattform-Funktionen (z. B. OS-Verschlüsselung) — und notfalls Änderung von Design oder Funktionsumfang.

Verknüpfte CRA-Vorschriften

Art. 13Anhang I
Abschnitt 7.3

Externe Abhängigkeiten vs. Due Diligence für Komponenten

Zwei komplementäre Pflichten: Die Risikobewertung (Art. 13 Abs. 2) erfasst auch externe Risiken — Backends, Infrastruktur, Umgebung —, die produktseitig zu mitigieren sind; der CRA regelt nicht, wie fremde Infrastruktur betrieben wird. Die Due Diligence (Art. 13 Abs. 5) betrifft integrierte Dritt-Komponenten: Der Hersteller definiert, was die Komponente leisten muss, und verifiziert das risikobasiert.

Kernaussagen

  • Beispiele produktseitiger Mitigation externer Risiken: kryptografische Authentisierung von Remote-Kommandos, Integritätsprüfung von Konfigurationsänderungen, sichere Zustände bei Ausfall externer Dienste.
  • Due-Diligence-Nachweise: technische Spezifikationen und Sicherheitsdokumentation des Komponenten-Herstellers, Konformitäts-/Assurance-Doku, ggf. eigene Tests.
  • Integrierte Dritt-Komponenten gehören in die Risikobewertung, werden aber als extern gelieferte Teile behandelt, deren Eigenschaften bei Integration verifiziert werden (Erwägungsgrund 34).

Für die Praxis

Trennen Sie Ihre Risikoliste in zwei Spalten: externe Abhängigkeiten (fremde Backends, Netze, Umgebung) → produktseitig mitigieren, etwa durch authentisierte Remote-Kommandos und sichere Fail-States; integrierte Dritt-Komponenten → Anforderungen definieren und Nachweise einsammeln (Hersteller-Doku, Zertifikate, eigene Tests). Wie der externe Anbieter seinen Betrieb organisiert, ist nicht Ihr CRA-Problem.

Verknüpfte CRA-Vorschriften

Art. 13EG 34Anhang I
Abschnitt 7.4

Produktfamilien — eine Risikobewertung, eine Doku, eine Erklärung

Varianten mit gleicher Architektur, gleichem sicherheitsrelevantem Design, gleicher Zweckbestimmung und gleichem Risikoprofil dürfen eine gemeinsame Risikobewertung, technische Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung teilen. Entscheidend ist allein, ob die Unterschiede zwischen den Varianten cybersicherheitsrelevant sind.

Kernaussagen

  • Unerheblich: Farbe, Formfaktor, Speichergröße und andere nicht sicherheitsrelevante Merkmale.
  • Relevant: abweichende Kommunikationsschnittstellen, Software-Stacks, Update-Mechanismen oder Remote-Konnektivität — solche Unterschiede müssen sich in Risikobewertung und Doku niederschlagen.
  • Die gemeinsame Konformitätserklärung muss die abgedeckten Varianten eindeutig identifizieren; neue Varianten mit neuen Risiken erfordern eine Aktualisierung.

Für die Praxis

Gruppieren Sie Ihre Produktvarianten nach sicherheitsrelevanten Unterschieden: Alles, was Architektur, Schnittstellen und Risikoprofil teilt, kann eine gemeinsame Risikobewertung, Doku und EU-Konformitätserklärung bekommen — Farbe, Formfaktor und Speichergröße trennen nicht. Das reduziert den Aufwand pro Variante drastisch; die Erklärung muss die abgedeckten Varianten nur eindeutig benennen.

Verknüpfte CRA-Vorschriften

Art. 13Art. 28Anhang VII
8

Kapitel 8: Remote Data Processing

Abschnitt 8.1

Was zählt als Remote Data Processing Solution (RDPS)?

Remote-Datenverarbeitung ist Teil des Produkts, wenn drei Kriterien kumulativ erfüllt sind: Verarbeitung „at a distance“, Funktionsnotwendigkeit (ohne sie könnte das Produkt eine Funktion nicht erfüllen) und Entwicklung durch den Hersteller oder unter seiner Verantwortung. Die Leitlinien übersetzen das in zwei Prüffragen mit Entscheidungsbaum.

Kernaussagen

  • „Wer betreibt“ ist unerheblich: On-Premises- oder Private-Cloud-Lösungen können genauso RDPS sein wie Public-Cloud-Lösungen.
  • „Funktionen“ meint mehr als Kernfunktionalität: auch Onboarding, Datei-Sync, Konfiguration, automatische Update-Verteilung und Identity/Access Management zählen.
  • Telemetrie rein für Statistik oder Produktentwicklung ist kein RDPS — die Risiken solcher Remote-Komponenten gehören aber trotzdem in die Risikobewertung.
  • IaaS/PaaS: Läuft die eigene (oder beauftragte) Software auf fremder Infrastruktur, kann sie RDPS sein; Standard-SaaS von Dritten ist kein RDPS, wird aber wie eine Dritt-Komponente behandelt (Risiken mitigieren + Due Diligence).
  • „Unter Verantwortung des Herstellers“ = maßgeschneidert für den Hersteller nach dessen Designs/Spezifikationen — nicht das bloße Lizenzieren eines bestehenden Dienstes.
  • Interne Systeme (HR, CRM, CI/CD-Pipelines, Update-Verteilung an Edge-Standorte, Pentest-/Red-Team-Infrastruktur) sind kein RDPS.
  • Websites nur bei Funktionsbeitrag: ein Auth-Portal, das Tokens für das Produkt ausstellt, kann RDPS sein — eine Info-Website nicht, selbst wenn das Produkt auf sie verlinkt.

Für die Praxis

Beantworten Sie je Cloud-/Backend-Dienst zwei Fragen: (1) Fällt ohne ihn eine Produktfunktion aus (auch Onboarding, Sync, Updates, Login)? (2) Wurde die Software von uns oder nach unseren Vorgaben entwickelt? Zweimal Ja → Teil Ihres Produkts, gehört in Risikobewertung und Konformitätsbewertung. Nur Frage 1 Ja (z. B. Standard-SaaS) → wie Dritt-Komponente behandeln: Risiken mitigieren plus Due Diligence.

Verknüpfte CRA-Vorschriften

Art. 2Art. 3EG 11EG 12
Abschnitt 8.2

RDPS in Doku, Risikobewertung und Konformitätsbewertung

RDPS gehören in Risikobewertung, technische Dokumentation und Konformitätsbewertung des Produkts — beschränkt auf die Software-Module, die die Produktfunktion tragen, und deren Schnittstellen. Nachgelagerte Backend-Systeme ohne direkte Produkt-Interaktion sind kein RDPS, bleiben aber externe Abhängigkeiten, deren Risiken produktseitig zu mitigieren sind.

Kernaussagen

  • Ein RDPS, das mehrere Produkte bedient, ist in jeder Produkt-Doku zu deklarieren — die RDPS-Dokumentation darf über Konformitätsbewertungen hinweg wiederverwendet werden.
  • Wiederverwendbare Assurance-Nachweise für Dritt-Services: NIS-2-Nachweise (DVO (EU) 2024/2690), DORA-Nachweise, Zertifikate nach EU-Cybersicherheits-Schemata, ISO/IEC 27001/27017.
  • Änderungen an Dritt-Services sind keine wesentliche Änderung des Produkts — Hersteller sollten sich aber vertraglich (SLAs) Informationen und Sicherheitsgarantien zusichern lassen und die Risikobewertung nachziehen.

Für die Praxis

Legen Sie ein zentrales RDPS-Dossier an — betroffene Software-Module, Schnittstellen, genutzte Provider samt Nachweisen (ISO 27001/27017, NIS-2-, DORA-Evidenz, EUCC-Zertifikate) — und referenzieren Sie es aus jeder Produkt-Doku. Verankern Sie in Provider-SLAs, dass Sie über wesentliche Änderungen informiert werden: Die lösen zwar keine neue Konformitätsbewertung aus, wohl aber ein Update Ihrer Risikobewertung.

Verknüpfte CRA-Vorschriften

Art. 13Art. 31EG 11Anhang IAnhang VII
Abschnitt 8.3

Fünf RDPS-Use-Cases: Banking-App, Thermostat, e-Reader, Roboter, Mobilfunk

Fünf durchgespielte Fälle zeigen die Abgrenzung: Bei der Mobile-Banking-App ist das selbst entwickelte Banking-Interface RDPS, nachgelagerte Ledger-/Kontensysteme nicht, der Support-Chat (Dritt-SaaS) ist eine Dritt-Komponente. Smart Thermostat und Industrieroboter: eigene Cloud-Software auf Dritt-IaaS ist RDPS. e-Reader: Dritt-SaaS-Storage ist kein RDPS, aber als Komponente zu behandeln. Das Mobilfunknetz ist reiner Kommunikationskanal — kein RDPS, keine Due Diligence nötig.

Kernaussagen

  • Der CRA erfasst nur die Systemteile, mit denen das Produkt direkt interagiert — Risiken dahinterliegender Systeme (z. B. kompromittiertes Ledger) sind produktseitig zu mitigieren (starke Backend-Authentisierung, Integritätsschutz, sichere Kanäle).
  • Bei Dritt-IaaS: RDPS und IaaS-Nutzung in der technischen Doku dokumentieren; vom Provider z. B. NIS-2-Nachweise einholen.
  • Netz-Infrastruktur (5G, Ethernet, WLAN, Router) ist Kommunikations-Enabler, nicht Datenverarbeitung, deren Fehlen eine Produktfunktion verhindert.

Für die Praxis

Ordnen Sie Ihr eigenes Setup dem nächstliegenden der fünf Kommissions-Use-Cases zu (Banking-App, Smart Thermostat, e-Reader, Industrieroboter, Mobilfunknetz) und übernehmen Sie dessen Logik: Was direkt mit dem Produkt interagiert und von Ihnen entwickelt wurde, ist RDPS; dahinterliegende Systeme sind externe Abhängigkeiten; reine Netzinfrastruktur ist gar nichts davon. Meist ersetzt das ein teures Einzelgutachten.

Verknüpfte CRA-Vorschriften

Art. 3Art. 13EG 11EG 12
9

Kapitel 9: Meldepflichten, Schwachstellenbehandlung und andere Rechtsakte

Abschnitt 9.1

Meldepflichten: ab 11.09.2026, „Bewusstwerden“ und Nutzerinformation

Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 für alle Produkte im CRA-Scope — auch für vor dem 11. Dezember 2027 in Verkehr gebrachte und für Produkte nach Supportende. „Bewusstwerden“ heißt: hinreichende Gewissheit nach unverzüglicher Erstbewertung — ab dann laufen die Fristen (24 h Frühwarnung, 72 h Meldung, 14 Tage bzw. 1 Monat Abschlussbericht).

Kernaussagen

  • Keine retroaktive Meldung: Aktive Ausnutzung, die dem Hersteller schon vor dem 11.09.2026 bekannt war, ist nicht meldepflichtig; wird die Ausnutzung erst danach bekannt, greift die Pflicht.
  • Dritt-Komponenten: Meldepflichtig ist nur eine aktiv ausgenutzte Schwachstelle, die im eigenen Produkt ausnutzbar ist bzw. ausgenutzt wurde — sonst nur freiwillige Meldung (Art. 15) plus Upstream-Meldung an den Komponenten-Maintainer (Art. 13 Abs. 6).
  • Der Begriff „Bewusstwerden“ ist bewusst konsistent mit der NIS-2-Durchführungsverordnung und den GDPR-Guidelines ausgelegt.
  • Nutzerinformation (Art. 14 Abs. 8) ist risikobasiert: keine indiskriminierte Veröffentlichung — bei sensiblen Umgebungen darf die Detailinformation auf betroffene Nutzer beschränkt werden; breitere Offenlegung nach Behebung, Pflicht-Veröffentlichung fixer Schwachstellen nach Anhang I Teil II Nr. 4.
  • Die Meldepflichten laufen — anders als die Schwachstellenbehandlung — auch nach Ende des Supportzeitraums weiter.

Für die Praxis

Definieren Sie jetzt, wer Verdachtsfälle wie schnell erstbewertet — ab „hinreichender Gewissheit“ läuft die 24-Stunden-Frist. Der Prozess muss zum 11. September 2026 stehen und deckt auch Altprodukte und Produkte nach Supportende ab. Legen Sie zusätzlich fest, wie Sie Nutzer risikobasiert informieren: erst betroffene Kunden gezielt, breite Veröffentlichung nach der Behebung.

Verknüpfte CRA-Vorschriften

Art. 14Art. 15Art. 16Art. 69Anhang I
Abschnitt 9.2

Schwachstellenbehandlung: Upstream-Meldung, bekannte Schwachstellen, Tests

Die Leitlinien präzisieren drei Pflichten: das Upstream-Melden von Komponenten-Schwachstellen und Teilen von Security-Fixes (Art. 13 Abs. 6), das Verbot, Produkte mit bekannten ausnutzbaren Schwachstellen in Verkehr zu bringen (Anhang I Teil I), und die „effektiven und regelmäßigen Tests“ (Anhang I Teil II Nr. 3) — die keine mechanische Testwiederholung verlangen, sondern anlassbezogene Review und Anpassung.

Kernaussagen

  • Upstream nur für die tatsächlich integrierte Version und gemäß CVD-Prozessen des Maintainers; keine Pflicht bei bereits bekannter Schwachstelle (Duplikate vermeiden: Datenbanken/Advisories prüfen) oder bei verwaisten Projekten ohne Maintainer.
  • Nur Schwachstellen der Komponente selbst sind zu melden — nicht solche, die erst durch die eigene Integration entstehen.
  • Security-Fixes maschinenlesbar und lizenzkompatibel teilen; weder muss der Maintainer den Fix annehmen, noch der Hersteller den Fix des Maintainers übernehmen.
  • „Bekannt“ ist eine Schwachstelle bei Listung in relevanten öffentlichen Datenbanken (z. B. Europäische Schwachstellendatenbank), bei Coordinated Disclosure, eigenen Tests (inkl. KI-gestützter Analyse) oder prominenter Medienberichterstattung — eine kurze Prüf-/Verifikationszeit ist zulässig.
  • Kurz vor Release entdeckte Schwachstellen: risikobasierte Entscheidung, ob das Release verschoben wird — abwägen mit den Risiken der Verzögerung (z. B. wenn das Release andere Schwachstellen schließt).

Für die Praxis

Ergänzen Sie Ihren Schwachstellen-Prozess um drei Bausteine: (1) Datenbank-/Advisory-Check vor jeder Upstream-Meldung, um Duplikate zu vermeiden; (2) lizenzkonformes, maschinenlesbares Teilen eigener Fixes mit dem Maintainer; (3) ein dokumentierter Release-Entscheid für spät gefundene Schwachstellen — abwägen zwischen Fix-vor-Release und den Risiken der Verzögerung.

Verknüpfte CRA-Vorschriften

Art. 13Art. 15Anhang I
Abschnitt 9.3

Zusammenspiel mit anderem EU-Recht: Fahrzeuge, RED, Maschinenverordnung

Fahrzeug-Komponenten (VO (EU) 2019/2144, VO (EU) Nr. 168/2013) sind vom CRA ausgenommen, wenn sie ausschließlich für die Integration in solche Fahrzeuge bestimmt und geeignet sind — generische Komponenten über offene Vertriebskanäle fallen in den CRA, unabhängig von Intended-Use-Erklärungen. EU-Baumusterprüfbescheinigungen zu Cybersicherheitsanforderungen (z. B. RED Delegated Act, Maschinenverordnung) bleiben bis längstens 11. Juni 2028 als Konformitätsnachweis für die abgedeckten Risiken nutzbar.

Kernaussagen

  • Maßgeblich sind die objektiven Vertriebsbedingungen: Verkauf über allgemeine Retail-/Online-Kanäle an die Öffentlichkeit spricht gegen die Fahrzeug-Ausnahme; geschlossene B2B-Kanäle der Automobil-Lieferkette dafür.
  • Bestehende Zertifikate (RED DA, Maschinenverordnung Anhang III 1.1.9/1.2.1) ersetzen die CRA-Risikobewertung nicht — sie dienen nur als Nachweis für die dort abgedeckten Risiken.
  • Vom Zertifikat nicht abgedeckte CRA-Risiken (z. B. Schwachstellenbehandlungsprozesse, Datenminimierung, Angriffsflächenreduktion) sind zusätzlich zu adressieren.

Für die Praxis

Prüfen Sie Ihre Vertriebskanäle: Komponenten, die auch außerhalb der Automobil-Lieferkette verkauft werden (Retail, offener Online-Shop), fallen in den CRA — unabhängig davon, was im Datenblatt zur Zweckbestimmung steht. Inventarisieren Sie außerdem Ihre RED-/Maschinenverordnungs-Zertifikate: Sie gelten als CRA-Nachweis nur für die abgedeckten Risiken und längstens bis 11. Juni 2028 — planen Sie die Lückenschließung jetzt.

Verknüpfte CRA-Vorschriften

Art. 2Art. 69

Häufige Fragen zur EU-Kommissions-Guidance

Ist die EU-Kommissions-Guidance zum Cyber Resilience Act rechtlich bindend?

Nein. Die Guidance (C(2026) 5252 final) gibt die Auslegung der Europäischen Kommission wieder und ist für Wirtschaftsakteure nicht bindend — verbindlich auslegen kann den EU CRA nur der Gerichtshof der EU. In der Praxis orientieren sich aber Marktüberwachungsbehörden und notifizierte Stellen an ihr; wer davon abweicht, sollte das gut begründen und dokumentieren.

Was regelt die Kommissions-Guidance zum EU CRA?

Die von Artikel 26 EU CRA vorgeschriebenen Kernthemen: Anwendungsbereich (u. a. Inverkehrbringen von Software, Datenverbindung), Open-Source-Software und Stewards, wesentliche Änderungen und Ersatzteile, Supportzeitraum, wichtige und kritische Produkte (Kernfunktionalität), Risikobewertung und Due Diligence, Remote Data Processing sowie Meldepflichten — illustriert mit 67 Praxisbeispielen.

Wo kann ich die CRA-Guidance der EU-Kommission herunterladen?

Das Original-PDF (84 Seiten, Englisch) steht oben auf dieser Seite zum Download bereit; maßgeblich ist allein das Dokument der Kommission (C(2026) 5252 final vom 27. Juli 2026). Eine amtliche deutsche Sprachfassung liegt bisher nicht vor — diese Seite bietet eine nicht-amtliche deutsche Zusammenfassung aller Kapitel.

Für wen ist die Guidance gedacht?

Für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen — mit besonderem Fokus auf kleine und mittlere Unternehmen — sowie für Marktüberwachungsbehörden, notifizierende Behörden und notifizierte Stellen, die den EU CRA europaweit einheitlich durchsetzen sollen.

Kommt weitere Guidance der Kommission zum CRA?

Ja. Die Kommission kündigt ausdrücklich weitere Leitfäden an, etwa zum Zusammenspiel des EU CRA mit dem AI Act (Verordnung 2024/1689) und mit DORA (Verordnung 2022/2554). Bereits verfügbar sind außerdem die FAQ der Kommission vom 3. Dezember 2025, die diese Guidance ergänzt und vertieft.

CRA-Updates per E-Mail

Fristen, Guidance und Mythos-Faktenchecks rund um den Cyber Resilience Act — kompakt im Newsletter.

Newsletter ansehen

Rechtlicher Hinweis

Diese Seite fasst die EU-Kommissions-Guidance C(2026) 5252 final vom 27. Juli 2026 redaktionell zusammen (nicht-amtliche deutsche Zusammenfassung). Die Guidance ist für Wirtschaftsakteure rechtlich nicht bindend; eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen. Die Beispiele der Kommission ersetzen keine Einzelfallprüfung. Maßgeblich ist allein das Originaldokument der Kommission. Das zum Download angebotene PDF ist das unveränderte Originaldokument der Europäischen Kommission (© Europäische Union, Nachnutzung gemäß Beschluss 2011/833/EU).

Offizielle CRA-Seite der EU-Kommission