Ab 11. September 2026 müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden gemeldet werden — auch für Produkte, die längst ausgeliefert sind. Wir bringen vernetzte Produkte, Plattformen und ihre Prozesse in den regulatorischen Rahmen.
11. September 2026 — Meldepflichten
24 h Frühwarnung, 72 h vollständige Meldung, Abschlussbericht binnen 14 Tagen. Über die ENISA Single Reporting Platform. Gilt auch für Altprodukte (Art. 14, 16, 69 Abs. 3).
11. Dezember 2027 — alle übrigen Pflichten
Anhang-I-Anforderungen, Risikobewertung, Konformitätsbewertung, EU-Konformitätserklärung, CE-Kennzeichnung, technische Dokumentation nach Anhang VII.
Vom Anwendungsbereich über die Produktklasse bis zum Meldeprozess — die vier Fragen, an denen die Umsetzung in der Praxis hängt.
Der häufigste Planungsfehler ist, den CRA als Zertifizierungsthema für 2027 zu behandeln. Die erste harte Pflicht ist operativ, nicht dokumentarisch: ab dem 11.9.2026 müssen Sie eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden melden können — auch samstags um 22:00, auch für ein Produkt, das Sie 2021 ausgeliefert haben. CE-Kennzeichnung, Konformitätsbewertung und technische Dokumentation folgen erst 15 Monate später.
Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Produktsicherheit — etwa ein kompromittiertes Build-System, ein Signaturschlüssel oder ein Update-Kanal. Gemeldet wird einmalig über die ENISA Single Reporting Platform an das Koordinator-CSIRT und die ENISA.
Maßgeblich ist die Kernfunktion, nicht die Feature-Liste: Ein Smartphone mit Passwortmanager wird kein Passwortmanager. Rund 90 % der erfassten Produkte bleiben Standardprodukte mit Selbstbewertung. Für Klasse I fehlt derzeit die harmonisierte Norm — damit bleibt faktisch die Drittbewertung mit entsprechender Vorlaufzeit.
Teil I beschreibt, wie das Produkt gebaut sein muss — angewandt auf Basis einer dokumentierten Risikobewertung. Teil II verlangt die Schwachstellenbehandlung über den gesamten Supportzeitraum: SBOM je Release, unverzügliche Behebung, Tests, Advisories, koordinierte Offenlegung und eine sichere Update-Verteilung.
Es gilt jeweils der höhere der beiden Beträge. Eine größenabhängige Ausnahme gibt es nicht — die Bandbreite trifft auch KMU und Einzelunternehmen. Ausgenommen von Geldbußen sind Verwalter quelloffener Software; Kleinst- und Kleinunternehmen werden für ein Versäumen der 24-Stunden-Frühwarnung nicht mit Geldbußen belegt.
Der CRA gilt als Verordnung unmittelbar — es gibt kein österreichisches Umsetzungsgesetz, das den Inhalt erst anwendbar macht. National geregelt werden nur Behördenzuständigkeit und Sanktionsvollzug, und genau dort ist der Stand noch unvollständig. Auf die Fristen hat das keinen Einfluss.
Der Anwendungsbereich ist bewusst weit gefasst — und die Rolle, in der Sie ihn betreten, entscheidet über den Pflichtenumfang. Beides wird pro Produkt geprüft, nicht pro Unternehmen.
Nach Art. 3 Nr. 1 jedes Software- oder Hardwareprodukt samt seiner Datenfernverarbeitungslösungen, dessen bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine Datenverbindung mit einem Gerät oder Netz einschließt — auch getrennt in Verkehr gebrachte Komponenten.
Auch reine Software ohne jede Hardware ist erfasst.
| Rolle | Kern |
|---|---|
| Hersteller Art. 13 | Trägt die Hauptlast: Secure-by-Design, Risikobewertung, technische Dokumentation, Konformitätsbewertung, Schwachstellenmanagement, Meldung. |
| Einführer Art. 19 | Schuldet inhaltliche Konformität, nicht nur das Vorhandensein von Papieren — Anhang I Teil I und die Herstellerverfahren nach Teil II. |
| Händler Art. 20 | Prüft CE-Kennzeichnung und Herstellerunterlagen, informiert über bekannt gewordene Schwachstellen — und bei eingestellter Herstellertätigkeit Behörde und Nutzer. |
| OSS-Verwalter Art. 24 | Eigenes, deutlich leichteres Regime. Keine Konformitätsbewertung, keine Geldbußen — CE-Kennzeichnung sogar ausdrücklich untersagt. |
Sie werden zum Hersteller, ohne etwas entwickelt zu haben: bei Eigenmarke oder White-Labeling (Art. 21) und bei einer erheblichen Veränderung (Art. 21/22) — als Integrator oder Systemhaus für den geänderten Teil, bei Auswirkung auf die Cybersicherheit für das gesamte Produkt.
Es gibt keine größenabhängige Ausnahme. Wer im Rahmen einer Geschäftstätigkeit ein Produkt mit digitalen Elementen auf dem Unionsmarkt bereitstellt, ist erfasst — auch als Ein-Personen-Unternehmen.
Erleichterungen gibt es nur punktuell:
Art. 2 nimmt aus, was bereits anderweitig reguliert ist — und einiges, das in der Praxis regelmäßig übersehen wird. Die Ausnahme für die Luftfahrt hängt an der Zertifizierung nach VO (EU) 2018/1139, nicht am Sektor allein.
Hier entscheidet sich in der Praxis am häufigsten die Betroffenheit — und hier sitzt auch der häufigste Denkfehler.
Sondern zwischen in Verkehr gebrachtem Produkt und erbrachter Dienstleistung. Ein eigenständiger SaaS-Dienst fällt grundsätzlich nicht unter den CRA — ein herstellereigenes Backend, ohne das ein ausgeliefertes Produkt eine Funktion nicht erfüllt, dagegen schon, als Datenfernverarbeitungslösung.
| Fall | Einordnung |
|---|---|
| Installierbare App, mobil oder Desktop | Erfasst. Eigenständiges Softwareprodukt; die Kommissionsleitlinien nennen mobile Apps ausdrücklich. |
| Webanwendung, nur im Browser | In der Regel kein Produkt mit digitalen Elementen. |
| Rein informative Website | Nicht erfasst — sie stützt keine Produktfunktionalität. |
| Backend, ohne das eine Produktfunktion fehlt | Erfasst als Datenfernverarbeitungslösung — gemeinsam mit dem Produkt. |
| Eigenständiges SaaS, PaaS, IaaS | Nicht erfasst — dafür gegebenenfalls NIS2. |
| Selbst-gehostete Edition, die der Kunde installiert | Erfasst — eigenständiges Produkt. |
Der häufigste Denkfehler: „Unsere App ist nur ein Client für unsere Cloud, also nicht erfasst." Das gilt für eine Browser-Webanwendung — nicht für eine installierbare App. Wer eine App über Store oder Download bereitstellt, bringt ein Produkt in Verkehr, unabhängig davon, wie viel Logik im Backend liegt.
Prüffrage: Erfüllt das ausgelieferte Produkt ohne diesen Dienst eine seiner Funktionen nicht — und wurde der Dienst von Ihnen oder unter Ihrer Verantwortung entwickelt? Zwei Mal ja bedeutet: im Anwendungsbereich. Ihre allgemeine Unternehmens-IT wird über den CRA dagegen nicht mitreguliert.
Nicht das Entwicklungsmodell. Nicht monetarisierte freie Software gilt nicht als auf dem Markt bereitgestellt — weder finanzielle Unterstützung durch Hersteller noch regelmäßige Releases machen ein Projekt für sich kommerziell.
Nein. Erheblich ist eine Veränderung nach Art. 3 Nr. 30 nur, wenn sie die Konformität mit Anhang I Teil I berührt oder die Zweckbestimmung ändert.
Maßgeblich ist die Auswirkung auf das Risikoprofil, nicht der Umfang des Diffs. Ob gebündelt mit einem Sicherheitsupdate ausgeliefert wird, spielt keine Rolle.
Alle Klassen erfüllen dieselben Anhang-I-Anforderungen. Die Klasse bestimmt nur den Nachweisweg — nicht das Schutzniveau.
Jedes Modul prüft zwei Dinge gleichzeitig — und das ist der Unterschied zu klassischen CE-Regimen: das Produkt gegen Anhang I Teil I und Ihre Prozesse gegen Teil II. Deshalb ist eine CRA-Bewertung ohne funktionierende Post-Market-Organisation nicht zu bestehen.
| Klasse | Verfahren |
|---|---|
| Standard | Selbstbewertung, interne Kontrolle — Modul A (Art. 32 Abs. 1) |
| Klasse I | Interne Bewertung nur, soweit harmonisierte Normen, gemeinsame Spezifikationen oder ein EU-Zertifikat mindestens Stufe „mittel" die Anforderungen abdecken; sonst Modul B+C oder H (Art. 32 Abs. 2) |
| Klasse II | Immer Drittbewertung: Modul B+C oder H, oder EU-Zertifikat mindestens Stufe „mittel" (Art. 32 Abs. 3) |
| Kritisch | Europäisches Cybersicherheitszertifikat, sofern per delegiertem Rechtsakt vorgeschrieben; sonst das Verfahren für Klasse II (Art. 32 Abs. 4) |
Modul A für ein Klasse-II-Produkt ist keine schwache Bewertung, sondern eine ungültige. Das Produkt darf dann nicht in Verkehr gebracht werden.
Praktischer Engpass: Solange keine CRA-harmonisierte Norm im Amtsblatt zitiert ist, gibt es keine Konformitätsvermutung nach Art. 27 — für Klasse I bleibt damit faktisch die Drittbewertung. Bei Klasse II und kritisch die notifizierte Stelle früh kontaktieren; Kapazitätsengpässe vor Dezember 2027 sind ein plausibles Planungsrisiko.
Das ist die eigentliche Arbeit. Sie fällt identisch an, ob Modul A oder H.
Die Risikobewertung ist das Herzstück, keine Formalie am Rand. Sie begründet, welche Anforderungen in welcher Tiefe greifen. Eine notifizierte Stelle liest sie zuerst — ist sie dünn, wird der Rest des Projekts teuer.
Pflicht sind das Verfahren zur koordinierten Offenlegung und eine leicht auffindbare Kontaktstelle, die den Nutzern die Wahl des Kommunikationsmittels lässt — rein automatisiert darf sie nicht sein.
Für Advisories empfiehlt sich CSAF 2.0 mit VEX: dokumentiert Nicht-Ausnutzbarkeit, senkt das Meldungsrauschen und erspart Diskussionen mit Kunden, die Ihre SBOM durch eigene Scanner schicken.
NIS2, bestehende Zertifizierungen, KI-Anteile im Code — drei Fragen, die in fast jedem Projekt früh auftauchen.
NIS2 regelt Organisationen, der CRA regelt Produkte. Ein Softwarehersteller kann beidem unterliegen — als Einrichtung dem NISG, als Hersteller dem CRA.
Das österreichische NISG 2026 tritt am 1.10.2026 in Kraft und gilt für rund 4.000 Einrichtungen ab mittlerer Größe aus 18 Sektoren. Zuständig ist das Innenministerium mit dem neuen Bundesamt für Cybersicherheit.
Bauen Sie einen Erkennungs- und Triage-Prozess mit Verzweigung am Ende — nicht drei parallele für CRA, NISG und DSGVO Art. 33. Sonst wird im Ernstfall der falsche befolgt.
Als Vorarbeit und Nachweisgrundlage: erheblich. Als Konformitätsnachweis: nein.
Führen Sie den Abgleich anforderungsweise gegen Anhang I, nicht zertifikatsweise.
Rechtlich gilt dasselbe wie für jeden anderen Code: die Anhang-I-Anforderungen, ohne Abstriche. Zwei praktische Besonderheiten:
Bei Hochrisiko-KI-Systemen, die zugleich wichtige oder kritische Produkte sind, lässt sich die Drittbewertung nicht über die KI-Verordnung umgehen. Die Risikobewertung darf aber gemeinsam geführt werden — ein Dokument, sofern die cyberbezogenen Inhalte vollständig enthalten sind.
Die Reihenfolge, die sich bewährt hat — erst Klarheit über den Anwendungsbereich, dann die operative Fähigkeit für 2026, danach der Nachweis für 2027.
Produktinventar erstellen und je Produkt entscheiden: erfasst nach Art. 3 Nr. 1 oder ausgenommen nach Art. 2? Auch Negativentscheidungen werden begründet festgehalten.
Kernfunktion bestimmen, gegen Anhang IV und III abgleichen — verifiziert an der DVO (EU) 2025/2392 — und den Konformitätsweg samt Begründung dokumentieren.
Triage-Kriterien, Rufbereitschaft, Produktregister mit SBOM je Release, security.txt, feste Advisory-URL und EU-Login. Bis 11.9.2026 muss der Prozess laufen.
Anforderungsmatrix zu Anhang I, Risikobewertung, technische Dokumentation nach Anhang VII, Konformitätserklärung und CE — rechtzeitig vor dem 11.12.2027.
Wir begleiten die digitale Transformation von Unternehmen — und dazu gehört, dass vernetzte Produkte und Plattformen die regulatorischen Anforderungen erfüllen: Scope-Abgrenzung, Produktklassifizierung, Meldeprozesse, Secure-Development-Lifecycle.
Kontakt aufnehmen