CRA-Leitlinien der Kommission: Was C(2026) 5252 für Hersteller klärt

Am 27. Juli 2026 hat die Europäische Kommission ihre Leitlinien zur Anwendung des Cyber Resilience Act veröffentlicht, Dokument C(2026) 5252 mit Anhang. Artikel 26 der Verordnung (EU) 2024/2847 verpflichtet sie dazu, mit besonderem Blick auf KMU. Das Ergebnis sind 84 Seiten mit 67 Beispielen, Flussdiagrammen und Use Cases. Rechtlich bindend ist der Text nicht, verbindlich auslegen kann nur der EuGH. Praktisch ist er die Arbeitsgrundlage der Marktüberwachungsbehörden, in Deutschland künftig des BSI.

Scope: Websites raus, Cloud-Backends rein

Reine Websites und Web-Anwendungen, die ausschließlich im Browser genutzt werden, sind keine Produkte mit digitalen Elementen. Heruntergeladene Clients, Browser-Extensions, Desktop-Apps und lokal installierbare Web-Apps sind es dagegen.

Für Remote Data Processing nach Artikel 3 Nummer 2 gelten drei kumulative Bedingungen: Die Verarbeitung findet entfernt statt, ohne sie funktioniert das Produkt nicht, und die Software wurde vom Hersteller oder in seiner Verantwortung entwickelt. Das eigene Cloud-Backend eines IoT-Geräts gehört damit zum Produkt, samt Tests und Meldepflichten. Eingebundene SaaS-Dienste Dritter sind kein Teil des Produkts, sondern externe Komponenten mit Sorgfaltspflicht nach Artikel 13 Absatz 5.

Wesentliche Änderung: ein Test mit vier Fragen

Wann ein Software-Update eine wesentliche Änderung nach Artikel 3 Nummer 30 ist und eine neue Konformitätsbewertung auslöst, beantwortet Punkt 110 der Leitlinien liefert einen Test mit vier Fragen: Führt das Update neue Bedrohungsvektoren ein, etwa Schnittstellen, Kommunikationskanäle oder externe Abhängigkeiten? Ermöglicht es neue Angriffsszenarien? Verändert es die Wahrscheinlichkeit bekannter Szenarien? Verändert es deren Auswirkung? Lautet die Antwort viermal nein und bleiben die Annahmen der Risikobewertung gültig, ist die Änderung nach Punkt 111 nicht wesentlich.

Der Umfang der Änderung ist unerheblich. Ein persistenter Login, der Tokens speichert, ist wesentlich; das Freischalten einer bereits bewerteten Funktion nicht. Sicherheitsupdates sind grundsätzlich ausgenommen, auch wenn sie eine Bibliothek komplett austauschen. Die Ausnahme endet laut Punkt 109 dort, wo ein Sicherheitsupdate eine neue externe Abhängigkeit einführt. Gegenüber dem Entwurf hat die Kommission den Maßstab in Punkt 106 auf nachteilige Auswirkungen verengt: Änderungen, die das Risiko nicht erhöhen, sind nie wesentlich.

Support-Zeitraum: fünf Jahre sind die Untergrenze, nicht der Standard

Punkt 126 stellt klar, dass die fünf Jahre aus Artikel 13 Absatz 8 als Schutzschwelle gedacht sind, nicht als Voreinstellung. Der Zeitraum muss sich aus der erwarteten Nutzungsdauer ableiten, bestimmt über Nutzererwartung, Produktart, Zweckbestimmung und anwendbares Unionsrecht. Das Enddatum ist dem Käufer mindestens als Monat und Jahr mitzuteilen.

Eine wesentliche Änderung setzt den Zeitraum nach Punkt 133 nicht automatisch zurück. Neu berechnet wird nur, wenn die Änderung die erwartete Nutzungsdauer selbst beeinflusst, etwa durch eine Hardware-Revision. Für Software mit laufenden Releases genügt es, Schwachstellen nur in der aktuellen Version zu schließen, sofern das Upgrade für Nutzer ohne zusätzliche Kosten möglich ist. Personalaufwand gilt als zumutbar, neue Hardware nicht.

Open Source: Finanzierung entscheidet nicht, Monetarisierung schon

Für Free and Open Source Software gilt ein zweistufiger Test. Erst die Frage, wer als Maintainer die Kontrolle über Entwicklung, Releases und Verteilung hat; einzelne Contributors tragen keine Verantwortung. Dann die Frage der Monetarisierung: In Verkehr gebracht wird Software, wenn für sie oder ihre Binaries Geld verlangt wird, wenn die Plattform andere Produkte monetarisiert, wenn personenbezogene Daten über Sicherheitszwecke hinaus verarbeitet werden oder wenn bezahlte Editionen den Zugang an Entgelt knüpfen. Freiwillige Spenden, Grants und Sponsoring machen kein kommerzielles Produkt, solange Releases nicht Spendern vorbehalten bleiben. Wer als Open-Source-Steward nach Artikel 24 gilt, trägt nur reduzierte Pflichten und kann nicht mit Bußgeldern belegt werden.

Tests und Altprodukte

Bei der Testpflicht aus Anhang I Teil II rückt die Kommission von festen Intervallen ab: Verlangt ist die regelmäßige Prüfung, ob neue Bedrohungen bestehende Tests überholt haben; ohne neuen Input ist kein Retest nötig. Für Produkte, die vor dem 11. Dezember 2027 in Verkehr waren, gilt nach Artikel 69 Absatz 2 eine Proportionalitätsregel: Eine wesentliche Änderung verpflichtet den Hersteller nur für den geänderten Teil zur vollen CRA-Konformität, es sei denn, die Änderung verschlechtert die Sicherheit des Gesamtprodukts.

Fazit

Hersteller sollten den Vier-Fragen-Test als festen Schritt in ihren Release-Prozess aufnehmen, den Support-Zeitraum begründet dokumentieren und ihr Cloud-Backend in Risikobewertung und Pentest-Scope einbeziehen. Bis zur vollen Anwendung am 11. Dezember 2027 bleiben 15 Monate.