CRA-Leitlinien 2026: Produktumfang und Support klären

Die Europäische Kommission hat am 27. Juli 2026 neue Hinweise zur praktischen Umsetzung des Cyber Resilience Act veröffentlicht. Die CRA Leitlinien 2026 behandeln genau jene Fragen, die in Produktteams häufig offenbleiben: Wann ist Software oder Hardware ein Produkt mit digitalen Elementen? Wann wird ein Update zur wesentlichen Änderung? Wie wird der Supportzeitraum festgelegt? Und welche Risiken müssen Hersteller für das gesamte Produkt dokumentieren?

Für österreichische KMU ist das mehr als ein juristisches Lesestück. Wer vernetzte Geräte, Apps, lokal installierte Programme, Softwarekomponenten oder digitale Steuerungen unter eigenem Namen auf den EU-Markt bringt, braucht belastbare Produktentscheidungen. Die Leitlinie liefert dafür 67 Beispiele, Abläufe und Grafiken. Sie ist jedoch nicht rechtsverbindlich und ersetzt keine Einzelfallprüfung. Verbindlich ist die Verordnung; eine maßgebliche Auslegung kann letztlich nur der Gerichtshof der Europäischen Union geben.

Dieser Beitrag übersetzt die neue Orientierung in einen Arbeitsplan. Der Schwerpunkt liegt nicht auf dem bereits separat erklärten CRA-Meldeprozess ab 11. September 2026, sondern auf Produktumfang, Änderungsbewertung, Support und Risikodokumentation.

Warum die neue Leitlinie gerade jetzt wichtig ist

Die meisten CRA-Pflichten gelten ab 11. Dezember 2027. Die Meldepflichten nach Artikel 14 beginnen bereits am 11. September 2026. Dazwischen müssen Unternehmen nicht nur einen Vorfallprozess aufsetzen, sondern auch verstehen, welche Produkte, Versionen, Rollen und Supportzusagen betroffen sind. Ohne diese Basis kann weder ein Sicherheitsereignis sauber zugeordnet noch eine technische Dokumentation konsistent aufgebaut werden.

Die Kommission richtet die Erläuterungen ausdrücklich auch an Kleinstunternehmen sowie kleine und mittlere Unternehmen. Das bedeutet nicht, dass für jedes KMU automatisch dieselben Pflichten gelten. Entscheidend bleiben Produkt, Bereitstellung auf dem EU-Markt, kommerzieller Zusammenhang und Rolle des Unternehmens. Ein Wiederverkäufer, ein Importeur, ein Entwickler und ein Hersteller unter eigener Marke können unterschiedliche Aufgaben haben.

Schritt 1: Den Produktumfang nicht nach Abteilungsnamen bestimmen

Der CRA knüpft an Produkte mit digitalen Elementen an. Dazu können eigenständige Software, Hardware mit eingebetteter Software, separat angebotene Hardwarekomponenten sowie Kombinationen aus Hard- und Software gehören. Voraussetzung ist unter anderem, dass der vorgesehene Zweck oder die vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.

Für die interne Bestandsaufnahme sollte daher nicht gefragt werden: „Ist das ein IT-Projekt?“ Besser sind konkrete Fragen:

Was wird Kundinnen und Kunden tatsächlich bereitgestellt?
Läuft Software auf einem System der Nutzer oder ausschließlich entfernt?
Welche Hardware-, Software- und Cloudbestandteile sind für eine Funktion erforderlich?
Wird das Produkt entgeltlich oder unentgeltlich im Rahmen einer kommerziellen Tätigkeit angeboten?
Unter wessen Namen oder Marke kommt es auf den Markt?
Welche Varianten unterscheiden sich in Komponenten, Konfiguration oder aktivierten Funktionen?

Gerade bei Software ist die Abgrenzung praktisch relevant. Laut Leitlinie kann eine lokal installierte App, Desktop-Anwendung oder Browser-Erweiterung ein Produkt mit digitalen Elementen sein. Eine Webanwendung, die ausschließlich im Browser genutzt und entfernt ausgeführt wird, ist dagegen nicht allein deshalb ein solches Produkt. Auch eine reine Informationswebsite fällt grundsätzlich nicht darunter. Entfernte Datenverarbeitung kann jedoch Teil eines Produkts werden, wenn sie für dessen Funktion erforderlich ist. Ein pauschales „SaaS ist immer draußen“ wäre deshalb ebenso ungenau wie „jede Website fällt unter den CRA“.

Ein brauchbares Produktregister anlegen

Erfassen Sie pro Produktfamilie mindestens Name, verantwortliche Gesellschaft, Marktrolle, Zielgruppe, Bereitstellungsart, Hardware- und Softwarebestandteile, entfernte Dienste, Versionen, vorgesehene Nutzung und geplantes Supportende. Ergänzen Sie eine Spalte „Begründung der CRA-Einordnung“. Dort gehört keine bloße Ja-Nein-Antwort hinein, sondern eine kurze nachvollziehbare Argumentation samt Quelle und Datum.

Varianten verdienen besondere Aufmerksamkeit. Wenn Builds für verschiedene Betriebssysteme, Produktpakete oder aktivierte Funktionen technisch deutlich voneinander abweichen, können sie für die Frage des Inverkehrbringens getrennt zu behandeln sein. Produktmanagement, Entwicklung, Vertrieb und Recht sollten daher dieselben Variantenbezeichnungen verwenden.

Schritt 2: Wesentliche Änderungen mit einem festen Prüftor bewerten

Eine „wesentliche Änderung“ ist nicht einfach jedes Update. Die Leitlinie knüpft an zwei Fragen an: Beeinflusst die Änderung die Konformität mit den grundlegenden Cybersicherheitsanforderungen? Und führt sie entweder zu einer Änderung des vorgesehenen Zwecks oder zu einer veränderten Gefahrenart beziehungsweise einem erhöhten Risikoniveau? Die Bewertung bleibt fallbezogen.

Das ist für laufend entwickelte Software wichtig. Fehlerkorrekturen, gewöhnliche Wartung und Sicherheitsupdates sind nicht automatisch wesentliche Änderungen. Ein Update, das Risiken reduziert und innerhalb der ursprünglich bewerteten Architektur bleibt, wird häufig anders zu beurteilen sein als eine neue Funktion, ein neuer Datenzugriff oder eine tiefgreifende Abhängigkeit, die in der ursprünglichen Risikobewertung nicht vorgesehen war. Selbst ein Sicherheitsupdate kann relevant werden, wenn es Architektur oder Abhängigkeitsstruktur auf eine nicht eingeplante Weise wesentlich verändert.

Fünf Fragen für jedes Release

Ändert sich der vorgesehene Zweck oder ein zentraler Anwendungsfall?
Entstehen neue Datenflüsse, Schnittstellen, Berechtigungen oder entfernte Dienste?
Verändert sich die Art einer Gefahr oder steigt das Risikoniveau?
Waren Funktion und Abhängigkeiten in der bisherigen Risikobewertung abgedeckt?
Sind Konformität, technische Dokumentation oder Supportzusage neu zu beurteilen?

Diese Prüfung gehört als verbindliches Gate in den Release-Prozess. Das Ergebnis sollte als kurze Entscheidung mit Produktversion, Datum, verantwortlicher Person, Begründung und betroffenen Unterlagen gespeichert werden. Ein Git-Commit oder ein Changelog allein beantwortet die regulatorische Frage nicht.

Schritt 3: Den Supportzeitraum aus der Nutzung ableiten

Hersteller müssen nach Artikel 13 Absatz 8 einen Supportzeitraum bestimmen. Grundsätzlich beträgt er mindestens fünf Jahre. Ist die erwartete Nutzungsdauer des Produkts kürzer, kann der Supportzeitraum dieser kürzeren Dauer entsprechen. Ist eine längere Nutzung zu erwarten, sollte der Support nicht reflexartig nach fünf Jahren enden. Die Leitlinie nennt unter anderem Produktart, Nutzererwartung, Verfügbarkeit der Betriebsumgebung und Supportzeiten integrierter Komponenten als relevante Gesichtspunkte.

Damit wird aus einer Marketingzeile eine Produktentscheidung. Für ein langlebiges Steuergerät, das in Gebäuden oder Maschinen eingesetzt wird, können andere Erwartungen bestehen als für eine kurzlebige Verbraucherkomponente. Auch Abhängigkeiten zählen: Wenn ein Produkt nur mit einem Betriebssystem, einer Bibliothek oder einem Cloudbestandteil funktioniert, muss deren Lebenszyklus in die Planung einfließen.

Eine Supportmatrix statt eines einzelnen Datums

Dokumentieren Sie pro Produkt und wesentlich geänderter Version mindestens Verkaufsstart, erwartete Nutzungsdauer, zugesagtes Supportende, unterstützte Umgebungen, kritische Abhängigkeiten und den Kanal für Sicherheitsupdates. Das Ende des Supportzeitraums soll klar und verständlich bekanntgegeben werden, zumindest mit Monat und Jahr. Wo technisch möglich, sieht der CRA außerdem eine Benachrichtigung der Nutzer am Supportende vor.

Vertrieb und Website dürfen dabei nicht mehr versprechen als Entwicklung und Support halten können. Formulierungen wie „lebenslange Updates“ oder „immer sicher“ sind ohne belastbares Konzept riskant. Präziser sind ein benanntes Supportende, der Umfang der Sicherheitsaktualisierungen und Hinweise für den Wechsel auf unterstützte Versionen.

Schritt 4: Die Risikobewertung auf das ganze Produkt ausdehnen

Die CRA-Risikobewertung soll relevante Cybersicherheitsrisiken identifizieren, ihre möglichen Auswirkungen beurteilen und geeignete Maßnahmen ableiten. Die neue Leitlinie betont den Blick auf das Produkt als Ganzes. Zusätzliche Funktionen, integrierte Komponenten und externe Abhängigkeiten verschwinden nicht aus der Verantwortung, nur weil ein Standard vor allem die Kernfunktion abdeckt.

Ein österreichischer Hersteller eines vernetzten Reglers muss daher nicht nur das Gehäuse oder die Firmware betrachten. Mobile App, Update-Mechanismus, Authentifizierung, Cloudanbindung, Bibliotheken und Kommunikationsschnittstellen können zum Sicherheitsprofil beitragen. Bei einer lokal installierten Business-Software zählen etwa Rechtekonzept, Updatekanal, Importfunktionen und eingebettete Komponenten.

Für die Dokumentation bietet sich ein wiederholbarer Aufbau an:

Produktgrenze und vorgesehene Nutzung,
vernünftigerweise vorhersehbare Fehlverwendung,
Werte, Daten, Funktionen und mögliche Angreifer,
Komponenten, externe Abhängigkeiten und Datenflüsse,
Risiko, Auswirkung und gewählte Schutzmaßnahme,
Restrisiko und Begründung der Akzeptanz,
Prüfnachweis sowie Anlass und Termin der nächsten Aktualisierung.

Die Bewertung ist kein einmaliges Dokument für die Ablage. Neue Schwachstellen, geänderte Abhängigkeiten, reale Nutzung und Produktänderungen können eine Aktualisierung auslösen. Wer Releases bereits mit einem Änderungs-Gate verbindet, kann Risikobewertung und technische Dokumentation im selben Ablauf nachziehen.

Drei Beispiele für österreichische KMU

Vernetzte Bewässerungssteuerung

Ein Betrieb verkauft eine eigene Steuerbox samt Firmware und App. Die Box, die lokal installierte App und eine für die Fernsteuerung notwendige Cloudfunktion müssen gemeinsam abgegrenzt werden. Für jede Produktgeneration sind vorgesehene Nutzung, Supportzeitraum und Abhängigkeiten zu dokumentieren. Eine neue Fernwartungsfunktion kann eine erneute Änderungs- und Risikoprüfung auslösen.

Lokal installierte Branchen-Software

Ein Softwarehaus bietet ein Desktop-Programm für österreichische Handwerksbetriebe an. Das Programm läuft beim Kunden und wird kommerziell bereitgestellt. Neue Module, Berechtigungen oder Schnittstellen werden vor jedem Release gegen die bestehende Produkt- und Risikodefinition geprüft. Eine reine Fehlerkorrektur ist anders zu behandeln als ein neues Zahlungs- oder Fernzugriffsmodul.

Reine Unternehmenswebsite mit Kundenportal

Die öffentliche Informationswebsite ist für sich genommen grundsätzlich kein Produkt mit digitalen Elementen. Beim Kundenportal muss genauer hingesehen werden: Wird lediglich ein entfernter Dienst im Browser angeboten, oder unterstützt er eine notwendige Funktion eines separat bereitgestellten digitalen Produkts? Die Antwort hängt von Architektur, Angebot und vorgesehener Nutzung ab, nicht vom Menüpunkt „Portal“.

Was auf Website und Supportseiten stehen sollte

Auch wenn eine Unternehmenswebsite nicht automatisch selbst in den CRA-Anwendungsbereich fällt, ist sie ein wichtiger Informationskanal. Produktseiten sollten Varianten eindeutig benennen und keine widersprüchlichen Supportzusagen enthalten. Eine Sicherheitsseite kann Kontaktweg, erwartete Angaben zu Schwachstellen, Verschlüsselungsoption und Reaktionsprozess erklären. Download- und Updatebereiche sollten erkennen lassen, welche Version unterstützt wird.

Die allgemeine technische Absicherung bleibt unabhängig von der Einordnung sinnvoll. Der Leitfaden zur Website-Sicherheit für österreichische KMU zeigt dafür operative Grundlagen. Für CRA-Produkte kommt die produktbezogene Dokumentation hinzu.

Ein umsetzbarer 30-Tage-Plan

Woche 1: Produkte, Varianten, Komponenten, entfernte Dienste und Marktrollen erfassen. Offene Einordnungsfragen markieren.
Woche 2: Pro Produkt eine begründete Produktgrenze, den vorgesehenen Zweck und eine vorläufige Supportlogik dokumentieren.
Woche 3: Ein Änderungs-Gate in den Release-Prozess einbauen und an zwei vergangenen Releases testen.
Woche 4: Risikobewertung, technische Unterlagen, Supportseite und Meldeprozess auf dieselben Produkt- und Versionskennungen abstimmen.

Am Monatsende sollte nicht bloß eine allgemeine CRA-Checkliste vorliegen. Das bessere Ergebnis ist ein entscheidungsfähiges Register: Für jedes Produkt ist sichtbar, warum es einbezogen oder ausgeschlossen wurde, wer die Entscheidung verantwortet, wann sie geprüft wurde, welche Version betroffen ist und welcher Anlass eine Neubewertung auslöst.

Entscheidungen zwischen den Teams übergeben

Offene Fälle sollten nicht mit einer vorschnellen Kategorie geschlossen werden. Legen Sie stattdessen eine Entscheidungsliste mit Frage, fehlender Information, zuständiger Person und Fälligkeitsdatum an. So wird sichtbar, ob beispielsweise eine Cloudfunktion technisch notwendig, eine Komponente separat vermarktet oder eine Software tatsächlich auf dem Kundensystem ausgeführt wird. Erst wenn diese Tatsachen geklärt sind, kann die rechtliche Einordnung sinnvoll geprüft werden.

Prüfen Sie auch die Übergaben: Der Vertrieb muss wissen, welcher Support zugesagt werden darf. Der Support braucht Produkt- und Versionskennungen für Meldungen. Die Entwicklung benötigt klare Auslöser für eine neue Risikobewertung. Die Geschäftsführung sollte offene Entscheidungen, Verantwortliche und Fristen sehen können. Erst diese gemeinsame Datenbasis verhindert, dass vier Abteilungen vier verschiedene Produktlisten pflegen.

Fazit: Aus Leitlinien werden belastbare Produktentscheidungen

Die neuen CRA-Leitlinien 2026 schaffen keine automatische Rechtssicherheit, aber sie machen viele Grenzfragen greifbarer. Für österreichische KMU liegt der größte Nutzen in einem gemeinsamen Arbeitsmodell für Produktmanagement, Entwicklung, Security, Support und Geschäftsführung.

Beginnen Sie mit einem vollständigen Produktregister, führen Sie für Releases ein dokumentiertes Änderungs-Gate ein und begründen Sie den Supportzeitraum aus der tatsächlichen Nutzung. Verknüpfen Sie diese Entscheidungen mit Risikobewertung, Website-Informationen und dem Meldeprozess. So entsteht eine belastbare Vorbereitung, ohne aus einer allgemeinen Checkliste eine ungesicherte Compliance-Garantie abzuleiten.

CRA-Leitlinien 2026: Produktumfang, Änderungen und Support richtig einordnen