Leitlinien der EU-Kommission zum CRA (Art. 26)
Am 27. Juli 2026 hat die Europäische Kommission den Inhalt ihrer Leitlinien zur Anwendung der Verordnung (EU) 2024/2847 (Cyber Resilience Act) gebilligt. Es handelt sich um die bislang detaillierteste Auslegung des CRA: Sie klärt Fragen zum Geltungsbereich, zu Open-Source-Software, zu wesentlichen Änderungen, zu Support-Zeiträumen, zur Produktklassifizierung und zur Fernverarbeitung, die die Verordnung selbst offenlässt.
Diese Seite hält fest, was das Dokument ist, welches rechtliche Gewicht es hat und an welchen Stellen sein Inhalt in dieses Handbuch eingearbeitet wurde. Die Inhalte selbst werden hier nicht wiederholt — sie sind in die operativen Kapitel eingeflossen, die in der Zuordnungstabelle unten aufgeführt sind.
Das Quelldokument
| Feld | Wert |
|---|---|
| Fundstelle | C(2026) 5252 final (Mitteilung an die Kommission) + C(2026) 5252 final ANNEX (die Leitlinien) |
| Titel | Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act) |
| Datum | Brüssel, 27. Juli 2026 |
| Rechtsgrundlage | Art. 26 Abs. 1 CRA — die Kommission ist verpflichtet, Leitlinien zu veröffentlichen, die Wirtschaftsakteure unterstützen, mit besonderem Fokus auf Kleinstunternehmen sowie kleine und mittlere Unternehmen |
| Umfang | 9 Kapitel, 257 nummerierte Randnummern, 67 ausgearbeitete Beispiele, 10 Abbildungen |
| Vorbereitung | Expertengruppe zur Cybersicherheit von Produkten mit digitalen Elementen; öffentliche Konsultation vom 3. März bis 13. April 2026 |
| Vorläufer | FAQ der Kommission zum CRA, veröffentlicht am 3. Dezember 2025 |
Art. 26 Abs. 2 CRA schreibt die Mindestaspekte vor, die die Leitlinien behandeln müssen. Alle vier sind abgedeckt: (i) der Geltungsbereich des CRA, insbesondere Fernverarbeitungslösungen und freie und quelloffene Software; (ii) der Begriff des Support-Zeitraums; (iii) das Zusammenspiel des CRA mit anderen EU-Rechtsvorschriften; und (iv) der Begriff der wesentlichen Änderung.
Rechtlicher Status — vor jeder Verwendung lesen
INHALT GEBILLIGT, FÖRMLICHE ANNAHME STEHT NOCH AUS
Die Mitteilung vom 27. Juli 2026 billigt den Inhalt des Leitlinienentwurfs. Die Leitlinien im Anhang „will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply."
Stand August 2026 ist diese förmliche Annahme noch nicht erfolgt. Der Inhalt ist stabil und kann zur Planung verwendet werden; jede Zitierung in technischer Dokumentation, in einer Konformitätserklärung oder im Schriftverkehr mit einer Marktüberwachungsbehörde sollte jedoch darauf hinweisen, dass die förmliche Annahme zum Zeitpunkt der Erstellung noch ausstand.
Drei weitere Einschränkungen gelten und werden von der Kommission selbst benannt:
| Einschränkung | Aussage der Leitlinien |
|---|---|
| Nicht verbindlich | Die Leitlinien „are not binding for economic operators or other actors subject to the CRA." Sie geben die Auslegung der Kommission wieder, um die Einhaltung zu unterstützen und eine harmonisierte Durchsetzung zu fördern. |
| Keine verbindliche Auslegung | „An authoritative interpretation of the CRA may only be given by the Court of Justice of the European Union." |
| Beispiele sind Illustrationen, kein Ersatz | Die 67 Beispiele „are not intended to replace a case-by-case assessment, which will always be necessary to account for the specifics of each individual case." |
WIE DIE BAUER GROUP DAMIT UMGEHT
Die Leitlinien werden als bestmöglicher Anhaltspunkt dafür behandelt, wie der CRA durchgesetzt werden wird — nicht als Recht. Wo dieses Handbuch nunmehr einer Auslegung aus den Leitlinien folgt, werden Entscheidung und Begründung in der Produktakte dokumentiert, damit die Argumentation auch dann nachvollziehbar bleibt, wenn der endgültig angenommene Text oder spätere Rechtsprechung davon abweicht.
Die Leitlinien richten sich zugleich an Marktüberwachungsbehörden, notifizierende Behörden und notifizierte Stellen. Ihre praktische Bedeutung ist damit höher, als der unverbindliche Status vermuten lässt: Sie sind die Auslegung, die die durchsetzenden Behörden voraussichtlich anwenden werden.
Aufbau der Leitlinien
| Kap. | Titel | Kernfrage |
|---|---|---|
| 1 | Einleitung | Zweck, Rechtsstatus, Verhältnis zu den FAQ |
| 2 | Geltungsbereich | Wann wird Software in Verkehr gebracht? Was ist ein Produkt mit digitalen Elementen? |
| 3 | Freie und quelloffene Software | Wann wird FOSS im Rahmen einer kommerziellen Tätigkeit bereitgestellt? Wer ist Steward? |
| 4 | Wesentliche Änderungen und Ersatzteile | Wann entsteht durch eine Änderung — physisch oder in Software — ein neues Produkt? |
| 5 | Support-Zeitraum | Wie lange, je Version, und was gilt nach einer wesentlichen Änderung? |
| 6 | Wichtige und kritische Produkte | Was ist die Kernfunktionalität, und welcher Konformitätsweg folgt daraus? |
| 7 | Risikobewertung und Integration | Restrisiko, Sorgfaltspflicht, Produktfamilien |
| 8 | Fernverarbeitung | Welche Cloud- und Backend-Elemente gehören zum Produkt? |
| 9 | Weitere Aspekte | Meldepflichten, Schwachstellenbehandlung, Zusammenspiel mit anderem EU-Recht |
Wo die Leitlinien in dieses Handbuch eingearbeitet wurden
| Abschnitt der Leitlinien | Eingearbeitet in |
|---|---|
| 2.1–2.5 Inverkehrbringen, Software, Computercode, Hardware+Software, Datenverbindung | 1.1 Geltungsbereich |
| 2.6 Komplexe Systeme | 1.1 Geltungsbereich · 3.4 Risikobewertung |
| 2.7 Vor Geltung des CRA entworfene Produkte | 1.1 Geltungsbereich |
| 3 Freie und quelloffene Software (alle Unterabschnitte) | 1.7 Open-Source-Steward |
| 4.1–4.2 Physische Reparaturen, Ersatzteile | 1.8 Wesentliche Änderungen |
| 4.3 Software-Updates als wesentliche Änderungen | 1.8 Wesentliche Änderungen |
| 4.4 Folgen einer wesentlichen Änderung | 1.8 Wesentliche Änderungen |
| 5 Support-Zeitraum, 5.1 und wesentliche Änderungen | 6.4 Support & Lifecycle |
| 6.1 Kernfunktionalität | 7.1 Produktklassifizierung |
| 6.2 Konformitätsbewertung wichtiger und kritischer Produkte | 7.2 Interne Kontrolle (Modul A) |
| 6.3 Auswirkungen auf die Konformitätsvermutung | 1.12 Harmonisierte Standards |
| 7.1–7.2 Bewertung und Behandlung von Cybersicherheitsrisiken | 3.4 Risikobewertung |
| 7.3 Sorgfaltspflicht bei externen Abhängigkeiten und Komponenten | 5.3 Drittanbieter-Bewertung |
| 7.4 Wiederverwendung für Produktfamilien | 3.4 Risikobewertung |
| 8 Fernverarbeitung (alle Unterabschnitte) | 1.15 Fernverarbeitung |
| 9.1 Meldepflichten | 4.3 ENISA-Meldeprozess |
| 9.2.1 Upstream-Meldung und Weitergabe von Sicherheitsfixes | 3.5 Anforderungen an die Schwachstellenbehandlung |
| 9.2.2 Bekannte ausnutzbare Schwachstellen | 3.5 Anforderungen an die Schwachstellenbehandlung |
| 9.2.3 Wirksame und regelmäßige Tests und Überprüfungen | 3.5 Anforderungen an die Schwachstellenbehandlung |
| 9.3 Zusammenspiel mit anderen Rechtsvorschriften | Sektorrecht & bestehende Zertifikate |
Was sich in diesem Handbuch geändert hat
Die Leitlinien haben nicht nur Details ergänzt — an mehreren Stellen haben sie eine hier bislang verwendete Auslegung korrigiert. Die Änderungen mit der größten operativen Wirkung:
| # | Änderung | Warum sie zählt |
|---|---|---|
| 1 | Der Test für eine wesentliche Änderung wurde durch den zweigliedrigen Test des Art. 3 Nr. 30 sowie die risikobasierten Kriterien der Leitlinien ersetzt | Der bisherige Drei-Bedingungen-Test war strenger als das Gesetz und hätte meldepflichtige Änderungen als nicht wesentlich eingestuft |
| 2 | Fünf Jahre sind eine Untergrenze, kein Standardwert für den Support-Zeitraum | Produkte mit längerer erwarteter Nutzungsdauer erfordern längere Zeiträume; „5 Jahre" pauschal zu erklären ist eine Compliance-Lücke |
| 3 | Jede wesentlich geänderte Softwareversion wird neu in Verkehr gebracht und benötigt einen eigenen erklärten Support-Zeitraum | Betrifft die Release-Planung iterativ entwickelter Software |
| 4 | Open-Source-Stewards müssen melden — aktiv ausgenutzte Schwachstellen nach Art. 24 Abs. 3, sofern sie Entwicklungsressourcen beisteuern; dies ist nicht freiwillig | Hier bislang als freiwillige Meldung beschrieben |
| 5 | Ausschließlich über den Browser genutzte Webanwendungen sind keine Produkte mit digitalen Elementen | Schärft die Abgrenzung für den Produktkatalog |
| 6 | Eine Schwachstelle in einer Drittkomponente ist nur meldepflichtig, wenn sie im eigenen Produkt aktiv ausgenutzt wird | Verhindert Über- und Untermeldung ab dem 11. September 2026 |
| 7 | Keine rückwirkende Meldung aktiver Ausnutzung, von der der Hersteller bereits vor dem 11. September 2026 Kenntnis hatte | Entfernt eine bislang angenommene Pflicht |
| 8 | Ein Produkt kann für Zwecke der Klassifizierung nur eine Kernfunktionalität haben | Löst die Einstufung multifunktionaler Produkte |
| 9 | Die Konformitätsvermutung reicht nur so weit, wie die harmonisierte Norm die Risiken tatsächlich abdeckt | Nebenfunktionen können außerhalb der Vermutung bleiben, auch wenn Modul A zulässig ist |
| 10 | Änderungen eines Cloud-Drittanbieters sind keine wesentliche Änderung des Produkts | Klärt die Grenze der Herstellerverantwortung |
Was die Leitlinien nicht abdecken
Die Leitlinien sind ausdrücklich kein vollständiger Kommentar zum CRA. Zwei Lücken benennt die Kommission selbst als Kandidaten für weitere Leitlinien nach Art. 26:
- Zusammenspiel des CRA mit der Verordnung (EU) 2024/1689 (KI-Verordnung)
- Zusammenspiel des CRA mit der Verordnung (EU) 2022/2554 (DORA)
Produkte mit KI-Komponenten und Produkte im Finanzsektor erfordern daher weiterhin eine individuelle rechtliche Bewertung der Überschneidung. Zu den bereits dokumentierten Schnittstellen siehe NIS2-Integration.
Verwandte Kapitel
- Klarstellungen & Missverständnisse — Übersicht dieses Bereichs
- Sektorrecht & bestehende Zertifikate — Art. 69 Abs. 1, RED, Maschinenverordnung, Fahrzeuge
- 1.3 Fristen & Zeitplan — die Geltungstermine, die die Leitlinien auslegen