Die neue CRA-Leitlinie in der Praxis: Fünf Produktentscheidungen, die Hersteller jetzt dokumentieren sollten

CRA-Leitlinie der EU-Kommission (C(2026) 5252): Produktgrenze und Datenfernverarbeitung, Produktrisiko, wesentliche Änderung, Supportzeitraum und Meldepflichten ab 11. September 2026: fünf Entscheidungen für Hersteller.

9. September 2026

preview-image for CRA-Leitlinie 2026: Fünf Produktentscheidungen

Am 27. Juli 2026 hat die Europäische Kommission eine Leitlinie zur Anwendung des Cyber Resilience Act (CRA) veröffentlicht. Der 84-seitige Anhang zu C(2026) 5252 beantwortet anhand von 67 Beispielen, Use Cases und Flussdiagrammen viele der Fragen, die Hersteller seit Verabschiedung der Verordnung (EU)2024/2847 wiederholt stellen. Besonderes Augenmerk liegt dabei auf Kleinstunternehmen sowie kleinen und mittleren Unternehmen. Am Zeitplan ändert die Leitlinie nichts: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab dem 11. September 2026, die übrigen wesentlichen Pflichten ab dem 11. Dezember 2027. Einen Überblick über Geltungsbereich, Produktklassen und Fristen gibt unsere CRA-Seite .

Die Leitlinie ist eine praktische Auslegungshilfe der Kommission und nicht bindend. Sie zeigt, wie die Kommission die Verordnung versteht, ersetzt aber weder eine produktbezogene Risikobewertung noch eine Konformitätsbewertung oder rechtliche Prüfung.

Über die 84 Seiten hinweg wiederholt sich dasselbe Muster. Produktteams suchen meist nach einer pauschalen Antwort wie „die Cloud ist ausgenommen“, „ein Minor Release ist unkritisch“ oder „ein CVE ist meldepflichtig“. Doch die Leitlinie gibt eine solche Antwort nicht. Sie verweist stattdessen jede Frage zurück auf die Gegebenheiten des konkreten Produkts und auf eine dokumentierte Begründung des Ergebnisses. Deshalb sind die Fragen, die in Architektur-Reviews, Release-Boards und PSIRT-Runden immer wieder auftauchen, Varianten einer einzigen Aufgabe: Produktgrenze, Lebenszyklus und Nachweise je Produkt belastbar festzulegen.

Dieser Beitrag ist deshalb entlang von fünf Entscheidungsunterlagen aufgebaut, die im Rahmen einer Produktorganisation jetzt entstehen sollten. Sie geben dem nächsten Produkt-, Architektur- oder Release-Meeting eine konkrete Arbeitsagenda.

Als durchgängiges Beispiel dient ein fiktives, aber realistisches Produkt: eine kommerziell angebotene Monitoring- und Steuerungslösung mit Desktop- und Mobile-App, Cloud-Dienst für Onboarding und Konfiguration, Over-the-Air-Updates (OTA), Datenablage bei einem Drittanbieter sowie mehreren unterstützten und älteren Versionen im Feld.

Entscheidung 1, Produktgrenze: Ist der Cloud-Anteil automatisch außerhalb des CRA?

Die Leitlinie beantwortet diese Frage mit dem Begriff der Datenfernverarbeitung (Remote Data Processing). Eine Fernverarbeitungslösung gehört nur dann zum Produkt, wenn drei Bedingungen zusammen erfüllt sind (Leitlinie, Rn. 178 bis 202):

Daten werden aus der Ferne verarbeitet,
ohne diese Verarbeitung könnte das Produkt eine seiner Funktionen nicht ausführen, nicht nur die Kernfunktion, und
die Software wurde vom Hersteller oder unter seiner Verantwortung entwickelt.

Auf das Beispielprodukt angewendet: Der herstellereigene Cloud-Dienst für Onboarding und Konfiguration erfüllt voraussichtlich alle drei Merkmale und ist damit als Teil des Produkts zu analysieren. Dasselbe gilt voraussichtlich für den vom Hersteller betriebenen OTA-Update-Dienst. Wer die Software betreibt, ist nicht entscheidend; auch eine Hersteller-Anwendung auf der Infrastruktur von Drittanbietern (IaaS/PaaS) kann Datenfernverarbeitung sein. Bei der generischen Speicherlösung eines Drittanbieters liegt der Fall anders, denn sie ist normalerweise keine vom Hersteller entwickelte Software. Die Speicherlösung bleibt aber eine sicherheitsrelevante Abhängigkeit und ist wie eine Komponente mit risikoangemessener Sorgfalt zu bewerten. Die Mobilfunk- oder WLAN-Konnektivität selbst ist zunächst ein Kommunikationsweg, nicht automatisch Datenfernverarbeitung. Und eine manuelle Alternative zur Fernfunktion ändert an dieser Einordnung nicht zwangsläufig etwas.

Entscheidungsunterlage in der Praxis: eine einseitige Übersicht der Fernfunktionen. Je Funktion: Verhalten des Produkts ohne die Funktion, Verantwortlichkeit für die Software, Datenfluss, Abhängigkeiten von Dritten, umgesetzte Sicherheitsmaßnahmen und Ablageort der technischen Dokumentation.

Entscheidung 2, Produktrisiko: Kann der Kunde das Restrisiko einfach übernehmen?

Im Unternehmensrisikomanagement ist ein definierter Risikoappetit legitim und nützlich. Die CRA-Risikobewertung beantwortet jedoch eine andere Frage, und die Leitlinie ist darin deutlich (Rn. 156 bis 163): Das Restrisiko ist am angemessenen Cybersicherheitsniveau des Produkts zu messen, bezogen auf Zweckbestimmung, vernünftigerweise vorhersehbare Verwendung, Einsatzbedingungen, betroffene Nutzer und Werte sowie die erwartete Nutzungsdauer. Kostenerwägungen, Geschäftsstrategie oder interne Risikotoleranz allein begründen nicht, dass ein Risiko angemessen behandelt wurde.

Betriebsumgebung und Anwenderhinweise werden dadurch nicht bedeutungslos. Eine geschützte Einsatzumgebung kann Teil der Zweckbestimmung sein, sofern sie real ist, dokumentiert wird und die Produkt- und Anwenderdokumentation den sicheren Betrieb tatsächlich unterstützt. Ein vager Disclaimer, der ein ungelöstes Designproblem zum Kunden verschiebt, trägt dagegen nicht. Im Beispielprodukt ersetzt der Hinweis „nur in vertrauenswürdigen Netzen betreiben“ keine Authentisierung an der Steuerungsschnittstelle. Er kann eine dokumentierte Einsatzannahme ergänzen, deren Restrisiko bewertet wurde, und das ist eine deutlich engere Aussage.

Entscheidungsunterlage in der Praxis: ein Risiko-Maßnahmen-Register. Je Eintrag: Bedrohung, betroffene Produktfunktion oder Schnittstelle, Einsatzannahme aus der Zweckbestimmung, technische oder organisatorische Maßnahme, Wirksamkeitsnachweis wie etwa ein Testergebnis, Restrisiko-Entscheidung und zugehörige Anwenderinformation. Methodisch lässt sich das mit einer produktbezogenen Bedrohungs-und Risikoanalyse aufbauen.

Entscheidung 3, Sicherheitsdelta: Kann ein kleines Release überhaupt „wesentlich“ sein?

Ob eine Änderung eine wesentliche Änderung im Sinne des CRA ist, hängt von ihrer Wirkung ab. Die Versionsnummer entscheidet das nicht, die Menge geänderten Codes ebenso wenig. Die Frage lautet: Beeinflusst die Änderung die Konformität mit den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I, oder ändert sie den bestimmungsgemäßen Zweck, für den das Produkt geprüft wurde (Leitlinie, Rn. 90 sowie 103 bis 113)? Ein kleines Komfort-Feature wie ein persistenter Login oder ein Diagnose-Export kann eine neue Schnittstelle einführen, neue Token oder Daten offenlegen oder eine neue Abhängigkeit hinzufügen und genau deshalb relevant sein. Ein gewöhnliches Sicherheitsupdate, das Risiken senkt und die Zweckbestimmung unverändert lässt, ist in der Regel keine wesentliche Änderung.

In der Praxis folgt daraus eine Prüfung des sicherheitsrelevanten Deltas vor dem Release. Diese Prüfung ist ausdrücklich kein automatisches juristisches Urteil, und sie bedeutet nicht, dass jedes Update eine neue Konformitätsbewertung erfordert:

Welche Schnittstellen, Datenflüsse, Berechtigungen, Ausführungsumgebungen oder Abhängigkeiten hat das Release geändert?
Welche neuen Missbrauchsszenarien oder relevanten Änderungen von Eintrittswahrscheinlichkeit und Auswirkung ergeben sich daraus?
Ist die Bedrohungs- und Risikoanalyse des Produkts noch zutreffend?
Welche dieser Änderungen müssen in Tests und technischer Dokumentation festgehalten werden?
Gibt es Anhaltspunkte, die eine Eskalation an die Rechtsabteilung beziehungsweise die Konformitätsverantwortlichen rechtfertigen?

Unabhängig vom Ergebnis gilt: Risikobewertung und technische Dokumentation müssen aktuell, korrekt und vollständig bleiben.

Entscheidungsunterlage in der Praxis: eine Sicherheitsdelta-Bewertung je Release, mit aktualisiertem Bedrohungsmodell, Komponenten-Delta (SBOM), Testergebnissen, Freigabeentscheidung und Dokumentations-Delta.

Entscheidung 4, Supportzeitraum: Reichen fünf Jahre immer, und darf die alte Version dann auslaufen?

In der Leitlinie wird der Supportzeitraum (im deutschen Verordnungstext: Unterstützungszeitraum) zu einer Lebenszyklus-Entscheidung (Rn. 125 bis 131):

Fünf Jahre sind eine Untergrenze und kein automatisches Maximum, sofern die erwartete Nutzungsdauer nicht nachweislich kürzer ist. Produkte, die erwartbar länger genutzt werden, brauchen einen längeren Supportzeitraum.
Das Support-Ende muss beim Kauf klar sein, mindestens als Monat und Jahr. Soweit technisch machbar, sollen Nutzer beim Ablauf benachrichtigt werden.
Für eine wesentlich geänderte Softwareversion ist ein eigener Supportzeitraum anzugeben.
Die Schwachstellenbehebung für eine ältere Version einzustellen, also der Weg über Artikel 13 Absatz 10 CRA, setzt voraus, dass Nutzer kostenlos und ohne zusätzliche Kosten auf die neueste Version wechseln können. Neue Hardware, ein Infrastruktur-Austausch oder grundlegende Umgebungsänderungen sind solche zusätzlichen Kosten. Üblicher Test- und Konfigurationsaufwand ist es nicht.

Für das Beispielprodukt bedeutet das: Die Frage „Können wir Kunden der Version 3 auf Version 5 migrieren und Version 3 abkündigen?“ ist mehr als eine Vertriebsentscheidung. Die Antwort darauf braucht eine belegte Migrations- und Kompatibilitätsbewertung und im Einzelfall eine rechtliche Prüfung, bevor Supportzusagen beendet werden.

Entscheidungsunterlage in der Praxis: ein Versions- und Supportregister. Je Version: Support-Ende, Kommunikation beim Kauf, Update-Verteilweg, Migrationspfad mit Kosten- und Voraussetzungsbewertung sowie ein benannter Verantwortlicher für Altversionen.

Entscheidung 5, Meldefall: Startet ein Komponenten-CVE die 24-Stunden-Frist?

Nicht automatisch. Die Leitlinie trennt den Befund einer Schwachstelle in einer Komponente von den produktbezogenen Voraussetzungen einer Meldung (Rn. 209 bis 224). Ab dem 11. September 2026 sind zwei Dinge meldepflichtig: aktiv ausgenutzte Schwachstellen im Produkt des Herstellers und schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts. Das ist ein engerer Maßstab als „alle kritischen CVEs“.

Ein Verdachtshinweis, etwa ein öffentlich gewordenes CVE zu einer Komponente aus der eigenen SBOM, ist unverzüglich zu bewerten. „Kenntnis“ im Sinne der Meldefristen entsteht, sobald die Erstbewertung mit hinreichender Sicherheit ergibt, dass eine aktive Ausnutzung im eigenen Produkt vorliegt oder ein schwerwiegender Vorfall dessen Sicherheit beeinträchtigt hat. Ab diesem Zeitpunkt laufen die gestaffelten Fristen: 24 Stunden für die Frühwarnung, danach 72 Stunden und schließlich der Abschlussbericht. Das BSI hat die Schwelle in seinem Webinar „CRAsh-Kurs“ vom 8. September 2026 mit zwei Gegenbeispielen geschärft: Ein veröffentlichter Exploit ohne beobachtete Ausnutzung macht eine Schwachstelle noch nicht zu einer aktiv ausgenutzten, und ein Ransomware-Vorfall bei einem Kunden ist nicht automatisch ein schwerwiegender Sicherheitsvorfall, wenn er sich nicht auf die Sicherheit des Produkts auswirken kann. Bei Drittkomponenten sind drei Fragen entscheidend. Ist der verwundbare Code im Produkt enthalten? Ist er dort erreichbar? Und wird er dort tatsächlich ausgenutzt? Ist die Ausnutzung im eigenen Produkt nicht gegeben, besteht insoweit keine Meldepflicht. Eine freiwillige Meldung bleibt möglich, und Pflichten zur Schwachstellenbehandlung sowie zur Information des Komponenten-Maintainers können dennoch greifen.

Häufig übersehen wird, dass die Meldepflichten auch für Bestandsprodukte gelten. Nach Artikel 69 Absatz 3 CRA erfasst Artikel 14 alle in den Geltungsbereich fallenden Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, also sowohl Produkte, die heute bereits im Markt sind, als auch solche, die bis Dezember 2027 noch folgen. Für diese Bestandsprodukte greifen die übrigen Anforderungen der Verordnung dagegen erst, wenn sie nach dem 11. Dezember 2027 wesentlich geändert werden (Artikel 69 Absatz 2). Die Meldepflichten bestehen zudem auch nach dem Ende des Supportzeitraums fort. Die Pflichten zur Behandlung von Schwachstellen in Anhang I Teil II sind dagegen an den Supportzeitraum gebunden.

Die zentrale Meldeplattform (SRP): Meldeweg, Registrierung, Meldefelder

Die ENISA betreibt die Single Reporting Platform (SRP) , die zentrale Meldeplattform, über die CRA-Meldungen laufen. Die FAQ und Anleitungen der ENISA (Stand 8. September 2026) klären die für die Vorbereitung wichtigsten Punkte:

Gemeldet wird einmal über die Plattform: an das als Koordinator benannte CSIRT am Ort der Hauptniederlassung des Herstellers und im Regelfall zugleich an die ENISA. Das Koordinator-CSIRT leitet die Meldung bei Bedarf an weitere betroffene CSIRTs und Marktüberwachungsbehörden weiter.
Die Plattform ist unter portal.cra-srp.enisa.europa.eu erreichbar. Gemeldet wird in der Rolle des Assigned Representative, also der Person, die für den Hersteller meldet; eine zweite Person lässt sich als Vertretung einladen.
Benannte Vertreter melden sich per EU Login an. Das Koordinator-CSIRT prüft die Berechtigung nach dem ersten Zugriff parallel zur Meldung, die Prüfung blockiert eine Einreichung also nicht. Die ENISA empfiehlt, Registrierung und Validierung erst anzustoßen, wenn eine konkrete Meldung ansteht; nach Angaben des BSI dauern Registrierung und Meldungsabgabe wenige Minuten.
Eine API ist nach Angaben der ENISA derzeit nicht geplant. Die FAQ beschreiben die je Stufe (24 Stunden / 72 Stunden / Abschlussbericht) erwarteten Datenfelder.

Die ENISA-Unterlagen ergänzen die Leitlinie um den Meldeweg. Sie ersetzen nicht die produktbezogene Prüfung, ob überhaupt ein meldepflichtiger Fall vorliegt. Die Vorbereitung muss weder umfangreich noch aufwendig sein, solange sie konkret ist: Verantwortliche für Meldezugang und Vertretung benennen und die eigene PSIRT-Fallakte gegen die veröffentlichten Meldefelder abgleichen.

Entscheidungsunterlage in der Praxis: eine PSIRT-Fallakte, mit Eingang und Quelle des Hinweises, Produkt und Version samt Supportstatus, Analyse zu Komponente, betroffener Funktionalität und Erreichbarkeit, Belegen für Ausnutzung oder Vorfall, Zeitstempel der „hinreichenden Sicherheit“, Entscheidung über Behebung oder Risikominderung, Anwenderinformation sowie der Entscheidung über den Meldeweg zwischen CRA und gegebenenfalls NIS-2 .

Randbemerkung: „Open Source“ ist keine pauschale Antwort

Auch hier ersetzt die Leitlinie ein Etikett durch eine Analyse (Abschnitt 3 der Leitlinie). Freie und Open-Source-Software im Sinne des CRA setzt öffentlich verfügbaren Quellcode und die entsprechenden Lizenzfreiheiten voraus, weshalb ein Repository, das nur zahlenden Kunden offensteht, diese Definition nicht erfüllt. Verantwortlich ist, wer Entwicklung, Releases und Verteilung tatsächlich kontrolliert; wer lediglich Code beiträgt oder Commit-Rechte hat, wird dadurch nicht automatisch verantwortlich. Eine monetarisierte Variante, also eine Bezahlversion, Open Core oder FOSS zur Vermarktung anderer Produkte oder Dienste, kann anders zu bewerten sein als die freie Community-Version. Der Satz „Unsere Community-Edition ist kostenlos, also ist der CRA für uns irrelevant“ hält dieser Analyse nicht ohne Weiteres stand. Wer Open-Source-Bestandteile vertreibt oder als Steward betreut, sollte Release-Kontrolle und Geschäftsmodell dokumentieren und Grenzfälle der Einordnung rechtlich prüfen lassen.

Der nächste Schritt: ein repräsentatives Produkt durchspielen

Beginnen Sie mit einem repräsentativen Produkt statt mit dem gesamten Portfolio und erstellen Sie die fünf Entscheidungsunterlagen: Übersicht der Fernfunktionen, Risiko-Maßnahmen-Register, Sicherheitsdelta-Bewertung, Versions- und Supportregister, PSIRT-Fallakte. Die offenen Punkte zeigen anschließend deutlich präziser, wo Architekturarbeit, Lebenszyklus-Planung, eine PSIRT-Übung oder eine rechtliche Klassifizierung fehlt.

Gerne unterstützen wir dabei: mit einem gemeinsamen Produktsicherheits-Workshop entlang der fünf Entscheidungen, einer produktbezogenen Bedrohungs-und Risikoanalyse sowie der technischen Validierung durch Penetrationstests und Embedded Security Assessments . Für Fragen der Betroffenheit und Produktklassifizierung arbeiten wir mit einem auf IT- und Cyber-Regulierung spezialisierten Fachanwalt zusammen; Details dazu finden Sie auf unserer CRA-Seite .

Kontaktieren Sie uns für ein kostenfreies Erstgespräch, wenn Sie die fünf Entscheidungen für eines Ihrer Produkte durchspielen möchten.

Die Leitlinie der Europäischen Kommission ist eine praktische, nicht bindende Auslegungshilfe. Dieser Beitrag übersetzt sie in Fragen für Produkt- und Sicherheitsentscheidungen; er ersetzt weder die produktbezogene Risikobewertung und Konformitätsbewertung noch eine rechtliche Prüfung.