Cyber Resilience Act 2026: CRA-Meldeprozess vorbereiten

Der Cyber Resilience Act 2026 wird für viele österreichische Unternehmen früher praktisch relevant, als der allgemeine Anwendungstermin vermuten lässt. Die EU-Verordnung gilt zwar überwiegend erst ab 11. Dezember 2027. Die Meldepflichten für bestimmte Sicherheitsereignisse starten jedoch bereits am 11. September 2026. Für Hersteller von Produkten mit digitalen Elementen bedeutet das: Wer erst nach einem Vorfall klärt, welches Produkt betroffen ist, wer entscheiden darf und wo die nötigen Informationen liegen, verliert wertvolle Zeit.

Die Vorbereitung ist keine Aufgabe nur für große Hardwarekonzerne. Auch ein österreichisches KMU kann Hersteller im Sinn der Verordnung sein, wenn es Software, ein vernetztes Gerät oder eine digitale Produktlösung unter dem eigenen Namen oder der eigenen Marke auf den EU-Markt bringt. Gleichzeitig ist nicht jeder Händler automatisch Hersteller und nicht jede technische Störung automatisch meldepflichtig. Genau deshalb beginnt eine brauchbare Vorbereitung mit einer sauberen Rollen- und Produktprüfung statt mit einer pauschalen Checkliste.

Dieser Leitfaden zeigt, wie Unternehmen Produktinventar, Eingangskanäle, Triage, Fristen, Zuständigkeiten und Website-Informationen für den September 2026 ordnen können. Er bietet allgemeine organisatorische Orientierung, ersetzt aber keine rechtliche Einzelfallprüfung, keine technische Sicherheitsanalyse und keine behördliche Auskunft.

Was am 11. September 2026 beginnt und was erst 2027 gilt

Die zeitliche Trennung ist wichtig. Laut Artikel 71 der Verordnung (EU) 2024/2847 gilt der Cyber Resilience Act grundsätzlich ab 11. Dezember 2027. Artikel 14 über Meldungen gilt jedoch bereits ab 11. September 2026. Die Europäische Kommission und ENISA nennen für diesen früheren Termin zwei Ereignisarten: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die Produkte mit digitalen Elementen betreffen.

Damit wird im September 2026 nicht automatisch jede spätere Produkt-, Dokumentations- und Konformitätsanforderung gleichzeitig voll wirksam. Der Termin ist aber auch kein unverbindlicher Probelauf. Die Meldefristen beginnen, sobald ein betroffener Hersteller von einem entsprechend einzuordnenden Ereignis Kenntnis erlangt. Zudem erfassen die Meldepflichten laut Verordnung grundsätzlich auch Produkte im CRA-Anwendungsbereich, die bereits vor dem allgemeinen Anwendungstermin auf dem EU-Markt bereitgestellt wurden.

Für die Praxis folgt daraus eine klare Priorität: Zuerst muss der Meldeprozess funktionieren. Parallel sollte das Unternehmen den größeren CRA-Fahrplan bis Dezember 2027 planen, etwa für Risikobewertung, technische Dokumentation, Schwachstellenbehandlung, Nutzerinformationen und Supportzeiträume. Beides gehört zusammen, darf organisatorisch aber nicht vermischt werden.

Schritt 1: Die eigene Rolle und den Produktumfang klären

Der CRA unterscheidet mehrere Wirtschaftsakteure. Als Hersteller gilt vereinfacht, wer ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet. Ein Importeur bringt ein Produkt eines außerhalb der EU ansässigen Herstellers auf den Unionsmarkt. Ein Distributor stellt ein Produkt in der Lieferkette bereit, ohne dessen Eigenschaften zu verändern. Für diese Rollen gelten unterschiedliche Aufgaben.

Ein österreichischer Betrieb sollte deshalb nicht nur fragen: „Verkaufen wir Technik?“, sondern genauer dokumentieren:

Welche Hardware, Software, Apps, Plug-ins, Steuerungen oder vernetzten Komponenten werden kommerziell angeboten?
Unter wessen Name oder Marke erscheint das Produkt?
Wer hat Entwicklung, Herstellung und wesentliche Produktentscheidungen beauftragt?
Wer importiert aus einem Drittstaat und wer vertreibt lediglich unveränderte Produkte?
Welche Drittanbieter-Komponenten sind in einem eigenen Produkt integriert?
Welche Produkte werden in welchen EU-Mitgliedstaaten bereitgestellt?

Produkte mit digitalen Elementen fallen nach der Zusammenfassung der Kommission grundsätzlich dann in den CRA-Bereich, wenn sie im Rahmen einer geschäftlichen Tätigkeit auf dem Markt bereitgestellt werden und ihr vorgesehener oder vernünftigerweise vorhersehbarer Gebrauch eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Es gibt Ausnahmen und Abgrenzungen, insbesondere zu Produkten, die bereits durch andere spezielle EU-Regeln erfasst sind. Grenzfälle sollten daher fachlich und rechtlich geprüft werden.

Schritt 2: Ein Produktregister statt einer losen Geräteliste anlegen

Ein Meldeprozess kann nur so schnell sein wie das Produktwissen dahinter. Eine einfache Tabelle ist für den Anfang oft ausreichend, wenn sie verbindlich gepflegt wird. Für jedes potenziell betroffene Produkt sollten mindestens Produktname, Modell oder Version, verantwortliche Rechtseinheit, Rolle im CRA-Sinn, zuständige Produktperson, technische Ansprechperson, eingesetzte Hauptkomponenten, Vertriebsländer und aktuell unterstützte Versionen erfasst sein.

Zusätzlich helfen drei Felder, die bei Sicherheitsereignissen häufig fehlen: das Ende des Supportzeitraums, der Ort der technischen Dokumentation und die Kontaktstelle für externe Schwachstellenmeldungen. Bei Cloud- oder Softwareprodukten sollten auch relevante Betriebsumgebungen und Release-Kanäle nachvollziehbar sein. Bei Geräten sind Chargen, Serienbereiche oder Firmwarestände nützlich, damit ein Ereignis nicht vorschnell auf das gesamte Portfolio ausgeweitet oder zu eng begrenzt wird.

Das Register sollte kein einmaliges Compliance-Dokument sein. Verknüpfen Sie seine Pflege mit Produktfreigaben, neuen Versionen, Lieferantenwechseln und dem Ende von Supportzeiträumen. So bleibt es im Ernstfall verwendbar.

Welche Ereignisse in die CRA-Triage gehören

ENISA beschreibt eine aktiv ausgenutzte Schwachstelle als Schwachstelle, für die verlässliche Hinweise vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis des Systeminhabers ausgenutzt hat. Ein schwerwiegender Vorfall muss die Sicherheit eines Produkts mit digitalen Elementen erheblich betreffen. Als Sicherheitsdimensionen nennt ENISA unter anderem Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit; die genauen Kriterien ergeben sich aus Artikel 14.

Nicht jeder Bug, jeder ausgefallene Server und jeder Kundenhinweis ist damit automatisch eine Pflichtmeldung. Umgekehrt darf eine Nachricht nicht allein deshalb im normalen Support liegen bleiben, weil Ausmaß und Ursache noch unklar sind. Ein sinnvoller Eingangskanal unterscheidet mindestens zwischen:

gewöhnlichem Produkt- oder Bedienungsfehler,
potenzieller Schwachstelle ohne bestätigte aktive Ausnutzung,
Hinweisen auf aktive Ausnutzung,
möglichem schwerwiegendem Sicherheitsvorfall,
freiwillig relevantem Hinweis oder Beinahe-Ereignis.

Die endgültige Einordnung kann technische Forensik und rechtliche Bewertung erfordern. Operativ zählt zunächst, dass potenziell relevante Hinweise sofort die richtigen Personen erreichen und der Zeitpunkt der Kenntniserlangung nachvollziehbar festgehalten wird.

24 Stunden, 72 Stunden und Abschlussbericht: Die Uhr sichtbar machen

Die EU-Kommission nennt eine Frühwarnung binnen 24 Stunden und eine ausführlichere Meldung binnen 72 Stunden nach Kenntniserlangung. Für aktiv ausgenutzte Schwachstellen folgt ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist. Bei schwerwiegenden Vorfällen ist der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung vorgesehen.

Diese Fristen verlangen nicht, dass binnen 24 Stunden bereits jede Ursache abschließend bewiesen ist. Sie verlangen aber einen Prozess, der verfügbare Fakten, Unsicherheiten, betroffene Produkte und erste Maßnahmen strukturiert zusammenführt. ENISA veröffentlicht in seiner aktuellen FAQ bereits Felder für die Meldestufen, darunter Meldeart, Produkt, Zeitpunkte, allgemeine Beschreibung, erste Bewertung sowie Korrektur- und Minderungsmaßnahmen.

Ein einfaches internes Ereignisblatt kann diese Struktur vorwegnehmen. Es sollte automatisch den Zeitpunkt des Eingangs, der internen Eskalation und der angenommenen Kenntniserlangung protokollieren. Zusätzlich braucht es klar sichtbare Zielzeiten für 24 und 72 Stunden. Verlassen Sie sich nicht darauf, dass eine einzelne Person die Fristen im Kalender behält.

Ein praxistauglicher CRA-Meldeprozess in sieben Bausteinen

1. Überwachter Eingangskanal

Richten Sie eine dauerhaft betreute Sicherheitskontaktstelle ein. Das kann eine funktionsbezogene E-Mail-Adresse oder ein abgesichertes Formular sein. Legen Sie Vertretungen, Weiterleitungen und Reaktionszeiten fest. Ein Postfach ohne Urlaubsvertretung ist kein belastbarer Prozess.

2. Sofortige Sicherung der Ausgangsinformationen

Bewahren Sie Originalmeldung, Zeitstempel, Anhänge, Logauszüge und Kontaktdaten geschützt auf. Verändern Sie Beweismittel nicht unnötig und geben Sie sensible technische Details nur an Personen weiter, die sie für Analyse und Entscheidung benötigen.

3. Technische und rechtliche Triage

Benennen Sie vorab, wer Produktbetroffenheit, aktive Ausnutzung, Schweregrad und Meldepflicht beurteilt. Kleine Unternehmen können dafür externe Sicherheits- und Rechtsberatung einplanen. Entscheidend ist, dass Verträge und Erreichbarkeit vor dem Vorfall geklärt sind.

4. Verbindliche Eskalationsrollen

Definieren Sie eine entscheidungsverantwortliche Person, eine technische Leitung, Kommunikation, Datenschutz sowie Stellvertretungen. Datenschutzvorfälle können zusätzliche Pflichten auslösen; ebenso können bei betroffenen Unternehmen Meldewege nach NIS2 beziehungsweise dem österreichischen NISG relevant sein. Diese Prüfungen laufen parallel und ersetzen die CRA-Einordnung nicht.

5. Faktenpaket für die Meldeplattform

Stellen Sie Produktidentifikation, betroffene Versionen, bekannte Vertriebsländer, Art des Ereignisses, Zeitpunkte, Auswirkungen, Gegenmaßnahmen und Nutzerhinweise zusammen. Die CRA-Meldung soll über die von ENISA betriebene Single Reporting Platform einmalig eingebracht und an die zuständigen Stellen verteilt werden. Laut ENISA soll die Plattform bis 11. September 2026 betriebsbereit sein; die konkrete öffentliche URL wird vor dem Start bekannt gegeben.

6. Korrektur, Kundeninformation und Versionierung

Dokumentieren Sie Patches, Konfigurationsänderungen, Rücknahmen oder andere Minderungsmaßnahmen mit Freigabezeitpunkt und Zielgruppe. Kundeninformationen müssen verständlich sein, dürfen aber keine unnötigen Angriffshinweise offenlegen. Halten Sie fest, welche Version wann und über welchen Kanal aktualisiert wurde.

7. Abschluss und Nachbereitung

Nach dem Abschlussbericht sollte eine kurze Ursachen- und Prozessanalyse folgen: Wurde der Hinweis rechtzeitig erkannt? Waren Produkt- und Komponenteninformationen vollständig? Haben Vertretungen funktioniert? Die Antworten fließen in Produktregister, Supportprozess und nächste Übung ein.

Welche Rolle die Unternehmenswebsite spielt

Die Website ist nicht die CRA-Meldeplattform. Sie kann aber ein wichtiger Teil des operativen Sicherheitsprozesses sein. Ein klar auffindbarer Sicherheitskontakt hilft Forschenden, Kunden und Partnern, Hinweise nicht im allgemeinen Verkaufspostfach zu verlieren. Eine kurze Richtlinie für verantwortungsvolle Schwachstellenmeldungen kann erklären, welche Informationen benötigt werden, wie vertrauliche Details geschützt übermittelt werden und wann mit einer Eingangsbestätigung zu rechnen ist.

Produktseiten und Supportbereiche sollten Produkte und Versionen eindeutig benennen. Wo passend, können unterstützte Versionen, verfügbare Sicherheitsupdates, sichere Installationshinweise und das Ende eines Supportzeitraums verständlich bereitgestellt werden. Veröffentlichen Sie keine sensiblen Schwachstellendetails, bevor Schutzmaßnahmen und Kommunikationsplan geprüft sind.

Auch die grundlegende Website-Sicherheit für KMU bleibt relevant: Ein Sicherheitskontakt oder Downloadbereich hilft wenig, wenn Formulare, Administratorzugänge oder Updateprozesse selbst schlecht geschützt sind. Für Unternehmen, die zusätzlich unter NIS-Regeln fallen könnten, bietet der Beitrag NISG 2026 für KMU eine getrennte erste Orientierung.

Lieferanten und Drittkomponenten in den Prozess einbinden

Viele digitale Produkte bestehen aus Bibliotheken, Modulen, Firmware, Chipsätzen oder Cloud-Diensten verschiedener Anbieter. Ein Hersteller bleibt trotzdem darauf angewiesen, Ereignisse dem eigenen Produkt zuordnen zu können. Erfassen Sie daher pro kritischer Komponente Lieferant, Version, Updatekanal, Sicherheitskontakt und vertragliche Informationspflichten.

Prüfen Sie außerdem, wie schnell Lieferanten technische Informationen liefern, wer einen Patch testen darf und wie Kunden bei einer Abhängigkeit informiert werden. Eine Software Bill of Materials kann die Analyse unterstützen, ist aber allein noch kein funktionierender Incident-Prozess. Für Webshops und Händler ist zusätzlich die Abgrenzung zur allgemeinen Produktsicherheit nach der GPSR sinnvoll: Die GPSR und der CRA haben unterschiedliche Schwerpunkte, Rollen und Prüfpfade.

30-Tage-Plan für österreichische KMU

Woche 1: Verantwortliche Rechtseinheiten, mögliche CRA-Rollen und digitale Produkte inventarisieren. Unsichere Abgrenzungen kennzeichnen, nicht stillschweigend entscheiden.
Woche 2: Sicherheitskontakt, Vertretung, Triagekriterien und Eskalationsmatrix festlegen. Externe Fachstellen vertraglich und organisatorisch einbinden.
Woche 3: Ereignisblatt, Fristenuhr und Faktenpaket an den von ENISA veröffentlichten Meldefeldern ausrichten. Produkt- und Komponentenregister vervollständigen.
Woche 4: Einen realistischen Testfall durchspielen: Hinweis am Freitagnachmittag, betroffene Firmware in mehreren EU-Ländern, zunächst unklare aktive Ausnutzung. Zeiten, Entscheidungen und Informationslücken protokollieren.

Das Ergebnis sollte kein umfangreiches Handbuch sein, das im Notfall niemand öffnet. Eine Seite mit Rollen und Telefonnummern, ein gepflegtes Produktregister, eine verständliche Triage und ein vorbereitetes Meldepaket sind für den Start wertvoller.

Checkliste vor dem 11. September 2026

Unsere Rolle als Hersteller, Importeur oder Distributor ist je Produkt dokumentiert.
Produkte, Versionen, Komponenten, Supportzeiträume und EU-Vertriebsländer sind auffindbar.
Ein überwachter Sicherheitskontakt mit Vertretung ist eingerichtet.
Potenzielle aktive Ausnutzung und schwerwiegende Vorfälle werden sofort eskaliert.
Kenntniszeitpunkt und 24-/72-Stunden-Ziele werden nachvollziehbar protokolliert.
Technische, rechtliche und kommunikative Verantwortlichkeiten sind vorab geklärt.
Ein Faktenpaket orientiert sich an den aktuellen ENISA-Meldefeldern.
Lieferanten können Sicherheitsinformationen und Updates zeitnah bereitstellen.
Website und Supportkanäle nennen eindeutige Produkt- und Sicherheitskontakte.
Ein Testlauf wurde durchgeführt und dokumentierte Lücken wurden geschlossen.

Fazit: Meldefähigkeit ist ein konkretes Betriebsziel

Der Cyber Resilience Act 2026 lässt sich für KMU am besten in ein überprüfbares Ziel übersetzen: Das Unternehmen kann einen sicherheitsrelevanten Hinweis innerhalb kurzer Zeit einem Produkt und einer Rolle zuordnen, fachlich eskalieren, die Fristen starten und ein belastbares Faktenpaket zusammenstellen. Wer diesen Ablauf bis September übt, schafft zugleich eine Grundlage für die umfassenderen CRA-Anforderungen ab Dezember 2027.

Beginnen Sie mit dem Produktregister und einem überwachten Sicherheitskontakt. Prüfen Sie danach Rollen, Triage und Vertretung an einem realistischen Testfall. Eine gepflegte öffentliche Unternehmensdarstellung kann Kunden und Partnern außerdem helfen, den richtigen Kontakt zu finden. Auf firmenwebseiten.at können österreichische Betriebe ihr Firmenprofil eintragen und aktualisieren.

Hinweis: Dieser Beitrag bietet allgemeine organisatorische Informationen und keine individuelle Rechts-, Compliance- oder Cybersicherheitsberatung. Ob ein Produkt, Unternehmen oder Ereignis unter den CRA fällt und welche Meldung erforderlich ist, muss anhand des konkreten Falls geprüft werden.

Cyber Resilience Act 2026: Meldeprozess für digitale Produkte jetzt vorbereiten