Cyber Resilience Act: die Fragen, die österreichische Hersteller jetzt stellen

Der CRA ist die Verordnung (EU) 2024/2847 vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Rechtsgrundlage ist Art. 114 AEUV (Binnenmarkt). Veröffentlicht am 20.11.2024, in Kraft seit 10.12.2024.

Als Verordnung gilt sie unmittelbar in allen Mitgliedstaaten. Es gibt kein österreichisches „Umsetzungsgesetz“, das den Inhalt erst anwendbar macht — national geregelt werden nur Behördenzuständigkeit und Sanktionsvollzug.

Ziel: EU-weit einheitliche, verbindliche Cybersicherheitsanforderungen über den ganzen Produktlebenszyklus — von Secure-by-Design bis zum Schwachstellenmanagement im Supportzeitraum.

Quellen: Verordnungstext, deutschsprachige Fassung (EUR-Lex) · Zusammenfassung der Kommission · Bundeskanzleramt: Cyberresilienz-Verordnung

Datum	Was gilt
10.12.2024	Inkrafttreten, Beginn der Übergangsphase
11.06.2026	Kapitel IV anwendbar: Konformitätsbewertungsstellen können notifiziert werden und zu bewerten beginnen
11.09.2026	Meldepflichten nach Art. 14 verbindlich: 24 h Frühwarnung, 72 h Meldung, 14 Tage bzw. 1 Monat Abschlussbericht
11.12.2027	Volle Anwendbarkeit: Anhang-I-Anforderungen, Konformitätsbewertung, EU-Konformitätserklärung, CE-Kennzeichnung

Der häufigste Planungsfehler: Der CRA wird als „2027-Thema“ behandelt. Die operative Pflicht beginnt aber 2026 — und sie greift für Produkte, die längst ausgeliefert sind.

Quellen: Art. 69, Art. 71 CRA · WKO: Zeitplan

Nein. Die CRA-Kernfristen aus Art. 71 stehen unverändert.

Der Digital-Omnibus-Vorschlag vom 19.11.2025 will einen Single Entry Point für Meldungen nach NIS2, DSGVO, DORA, eIDAS und CER schaffen — nach dem Prinzip „einmal melden, vielfach verteilen“. Er soll auf den Erfahrungen beziehungsweise technischen Komponenten der CRA-Meldeplattform aufbauen; die CRA-Meldepflicht nach Art. 14 und die Plattform nach Art. 16 bleiben davon unberührt. Er soll 18 Monate nach Inkrafttreten des Omnibus laufen, verlängerbar auf 24 Monate.

Der Vorschlag ist noch im ordentlichen Gesetzgebungsverfahren und damit nicht verbindlich. Bis dahin gilt: melden über die CRA-Plattform, ab 11.9.2026.

Quelle: Kommission: CRA Implementation

• Leitlinien der Kommission C(2026) 5252 (27.7.2026, finale Fassung): 67 praktische Beispiele, Use Cases, Ablaufdiagramme, mit ausdrücklichem Fokus auf Kleinst- und Kleinunternehmen (Auftrag aus Art. 26(1)). Nicht bindend, aber die maßgebliche Auslegungshilfe.
• Durchführungsverordnung (EU) 2025/2392 (28.11.2025): verbindliche technische Beschreibung der wichtigen und kritischen Produktkategorien.
• Delegierte Verordnung (EU) 2026/881 vom 11.12.2025 (C(2025) 8407 final), im Amtsblatt veröffentlicht am 20.4.2026: Modalitäten und Bedingungen für die Geltendmachung von Cybersicherheitsgründen beim Aufschub der Verbreitung von Meldungen nach Art. 16 Abs. 2. Einer der vorgesehenen Gründe ist, dass die Meldeplattform kompromittiert oder zeitweise nicht betriebsfähig ist.
• Berichtigung (Juli 2025): Kleinst- und Kleinunternehmen werden bei Versäumen der 24-Stunden-Frühwarnung nicht mit Geldbußen belegt — die Meldepflicht selbst bleibt.

Quellen: DVO (EU) 2025/2392, deutschsprachige Fassung (PDF) · Kommission: CRA Implementation

Nach Art. 3 Nr. 1 ein Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen, einschließlich getrennt in Verkehr gebrachter Komponenten, dessen bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

Der Anwendungsbereich ist bewusst weit: IoT-Geräte, Steuerungen, Router, Betriebssysteme, Apps, Bibliotheken, Firmware, eingebettete Systeme — und reine Softwareprodukte ohne jede Hardware.

Quellen: Art. 3 Nr. 1, Erwägungsgrund 9 CRA · BKA: Fragen und Antworten

Ja. Es gibt keine größenabhängigen Ausnahmen. 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 punktuell: vereinfachte technische Dokumentation für Kleinst- und Kleinunternehmen, keine Geldbuße bei Versäumen der 24-Stunden-Frühwarnung, und eine ausdrücklich KMU-orientierte Leitlinie der Kommission.

Quellen: Art. 33, Art. 64 CRA · WKO: Gibt es Ausnahmen?

• Hersteller (Art. 13): trägt die Hauptlast — Secure-by-Design, Risikobewertung, technische Dokumentation, Konformitätsbewertung, Schwachstellenmanagement, Meldung.
• Einführer (Art. 19): bringt ein Produkt unter dem Namen oder der Marke einer außerhalb der Union niedergelassenen Person in der Union in Verkehr. Art. 19 Abs. 1 ist strenger als eine reine Formalprüfung: Einführer bringen nur Produkte in den Verkehr, die den grundlegenden Anforderungen in Anhang I Teil I genügen und bei denen die vom Hersteller festgelegten Verfahren den Anforderungen in Anhang I Teil II genügen. Sie schulden also inhaltliche Konformität, nicht nur das Vorhandensein von Papieren.
• Händler (Art. 20): stellt ein Produkt ohne Änderung seiner Eigenschaften auf dem Unionsmarkt bereit. Nach Art. 20 Abs. 1 befolgen Händler die Verordnung mit der gebührenden Sorgfalt. Nach Art. 20 Abs. 2 überprüfen sie vor der Bereitstellung, dass die CE-Kennzeichnung angebracht ist und dass Hersteller und Einführer die Anforderungen aus Art. 13 Abs. 15, 16, 18, 19 und 20 sowie Art. 19 Abs. 4 erfüllt und dem Händler alle erforderlichen Dokumente bereitgestellt haben. Weiter: Information des Herstellers über bekannt gewordene Schwachstellen, bei erheblichem Risiko zusätzlich der Marktüberwachungsbehörde. Art. 20 Abs. 6: Erfährt der Händler, dass der Hersteller die Betriebstätigkeit eingestellt hat und seine Pflichten deshalb nicht erfüllen kann, muss er unverzüglich die Marktüberwachungsbehörden und, mit allen verfügbaren Mitteln und soweit möglich, die Nutzer informieren.
• Verwalter quelloffener Software (Art. 24): eigenes, deutlich leichteres Regime.

Prüfen Sie die Rolle je Produkt, nicht je Unternehmen. Für jede tatsächlich erfüllte Rolle sind die einschlägigen Pflichten gesondert zu prüfen; nach Art. 21 kann ein Importeur oder Händler rechtlich zum Hersteller werden. Die verbreitete Kurzformel „es gilt die strengste Pflichtenlage“ ist eine Arbeitsregel, kein eigener Rechtssatz des CRA.

Quellen: Art. 13, 19, 20, 24 CRA · WKO: Pflichten der Händler

In zwei Fällen:

1. Eigenmarke / White-Labeling (Art. 21): Sie bringen ein fremdes Produkt unter Ihrem Namen oder Ihrer Marke in Verkehr. Dann treffen Sie die vollen Herstellerpflichten — unabhängig davon, wer es gebaut hat.
2. Erhebliche Veränderung. Für Einführer und Händler greift Art. 21: Wer eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt vornimmt, gilt als Hersteller und unterliegt den Pflichten aus Art. 13 und 14. Für alle anderen Personen — also auch Integratoren, Systemhäuser oder Betreiber — greift Art. 22: Wer eine wesentliche Änderung vornimmt und das Produkt bereitstellt, gilt ebenfalls als Hersteller, und zwar für den geänderten Teil oder für das gesamte Produkt, wenn die Änderung die Cybersicherheit des Produkts insgesamt betrifft.

Quellen: Art. 21, Art. 22 CRA

Nein. Nach Art. 3 Nr. 30 ist eine Veränderung erheblich, wenn sie die Konformität mit den Anhang-I-Teil-I-Anforderungen berührt oder die Zweckbestimmung ändert.

• Keine erhebliche Veränderung: Sicherheitsupdates zur Senkung des Cybersicherheitsrisikos, Bugfixes, geringfügige Funktionsanpassungen wie eine neue Sprache oder ein neues Piktogramm.
• Erheblich: Funktionsupdates, die die beabsichtigten Funktionen, die Art der Gefahr oder die Leistung verändern — etwa ein neues Eingabeelement, für das Eingabevalidierung nötig wird.

Maßgeblich ist die Auswirkung auf das Risikoprofil, nicht der Umfang des Diffs. Ob das Update separat oder gebündelt mit einem Sicherheitsupdate ausgeliefert wird, spielt keine Rolle.

Quellen: Art. 3 Nr. 30, Erwägungsgründe 38–39, 42 CRA · Leitlinien C(2026) 5252, Punkte 109 und 123

• Medizinprodukte und In-vitro-Diagnostika (VO (EU) 2017/745 und 2017/746)
• Kraftfahrzeuge (VO (EU) 2019/2144) und Schiffsausrüstung; in der Luftfahrt gilt die Ausnahme für Produkte, die nach VO (EU) 2018/1139 zertifiziert worden sind (Art. 2 Abs. 3) — die Zertifizierung ist die Bedingung, nicht der Sektor allein
• Produkte ausschließlich für nationale Sicherheit oder Verteidigung sowie für die Verarbeitung von Verschlusssachen
• Reine Dienstleistungen und Cloud-Dienste, die außerhalb der Verantwortung eines Produktherstellers entworfen wurden
• Nicht kommerzielle Bereitstellung
• Ersatzteile, die identische Komponenten ersetzen und nach denselben Spezifikationen hergestellt sind wie die Bauteile, die sie ersetzen sollen (Art. 2 Abs. 6). Die Ausnahme deckt sowohl Ersatzteile für Altprodukte als auch solche, die bereits ein CRA-Konformitätsbewertungsverfahren durchlaufen haben (Erwägungsgrund 29)
• Software, die eine öffentliche Verwaltungseinrichtung ausschließlich für den Eigenbedarf entwickelt
• Nach Art. 2 Abs. 8 umfassen die Pflichten der Verordnung nicht die Bereitstellung von Informationen, deren Offenlegung wesentlichen Interessen der Mitgliedstaaten in den Bereichen nationale Sicherheit, öffentliche Sicherheit oder Verteidigung zuwiderlaufen würde

Quellen: Art. 2, Erwägungsgründe 12, 16, 25–29 CRA · WKO: Ausnahmen

Grundsätzlich nicht: Ein eigenständiger Cloud- oder SaaS-Dienst, der nicht als Datenfernverarbeitungslösung unter der Verantwortung eines Produktherstellers Teil eines Produkts mit digitalen Elementen ist, fällt nicht als solcher unter den CRA. Ob für den Anbieter stattdessen NIS2 beziehungsweise in Österreich das NISG 2026 greift, ist gesondert zu prüfen — die Eigenschaft „SaaS“ allein entscheidet das nicht.

Erwägungsgrund 12 stellt klar: Die NIS-2-Richtlinie gilt für Cloud-Computing-Dienste und die Modelle SaaS, PaaS und IaaS. In ihren Anwendungsbereich fallen Einrichtungen, die solche Dienste in der Union erbringen und die als mittlere Unternehmen gelten oder die entsprechenden Schwellenwerte überschreiten. Kleinere Anbieter fallen damit regelmäßig weder unter den CRA noch unter NIS2 — vorbehaltlich der Sondertatbestände.

Aber: Ein herstellereigenes Backend oder API, ohne das ein ausgeliefertes Produkt eine seiner Funktionen nicht erfüllen kann, ist eine Datenfernverarbeitungslösung und fällt mit dem Produkt in den Anwendungsbereich. Erwägungsgrund 12 nennt die Cloud-Funktion eines Smart-Home-Herstellers, mit der Nutzer ihr Gerät fernsteuern.

Der einschlägige Satz für App-Anbieter steht in Erwägungsgrund 11: Eine Fernverarbeitung liegt vor, wenn eine mobile Anwendung den Zugang zu einer Anwendungsprogrammierschnittstelle oder zu einer Datenbank erfordert, die über einen vom Hersteller entwickelten Dienst bereitgestellt wird. In diesem Fall fällt der Dienst als Datenfernverarbeitungslösung in den Anwendungsbereich.

Und die Gegenausnahme: Die Anforderungen an Datenfernverarbeitungslösungen umfassen keine Maßnahmen zur Absicherung der Netz- und Informationssysteme des Herstellers insgesamt. Ihre allgemeine Unternehmens-IT wird über den CRA nicht mitreguliert — dafür ist gegebenenfalls NIS2 einschlägig.

• Fremde SaaS, die Sie nur konfigurieren oder integrieren: in der Regel keine Datenfernverarbeitungslösung.
• Eine selbst-gehostete Edition Ihrer Software, die der Kunde installiert: eigenständiges Produkt, im Anwendungsbereich.
• Eine Webanwendung, die nur im Browser läuft, sowie eine rein informative Website: in der Regel kein Produkt mit digitalen Elementen — außer sie gilt als Datenfernverarbeitung, die eine Produktfunktion stützt.
• Eine installierbare App dagegen ist ein in Verkehr gebrachtes Softwareprodukt und damit erfasst, auch wenn sie im Betrieb ein Cloud-Backend nutzt.

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.

Quellen: Art. 3 Nr. 1 und Nr. 2, Erwägungsgründe 11 und 12 CRA

Die Trennlinie verläuft nicht zwischen „Software“ und „Cloud“, sondern zwischen in Verkehr gebrachtem Produkt und erbrachter Dienstleistung.

Fall	Einordnung
Installierbare App — mobil oder Desktop	Erfasst. Eigenständiges Softwareprodukt; die Kommissionsleitlinien nennen mobile Apps ausdrücklich, samt Fitness-App als Beispiel.
Webanwendung, ausschließlich im Browser genutzt	In der Regel kein Produkt mit digitalen Elementen.
Website, die lediglich Informationen bereitstellt	Nicht erfasst — Erwägungsgrund 12 nennt Websites, die die Funktionalität eines Produkts mit digitalen Elementen nicht unterstützen.
Web-Oberfläche oder Backend, ohne das ein ausgeliefertes Produkt eine Funktion nicht erfüllt	Erfasst als Datenfernverarbeitungslösung — gemeinsam mit dem Produkt.
Eigenständiges SaaS, PaaS, IaaS außerhalb der Verantwortung eines Produktherstellers	Nicht erfasst, dafür NIS2.

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.

Praktische Folge bei einem Gerät mit App und Backend: Gerät und separat bereitgestellte App können zwei eigenständige Produkte sein. Ein herstellereigenes Backend ist dagegen typischerweise Bestandteil des Produkts als Datenfernverarbeitungslösung — nicht automatisch ein separat in Verkehr gebrachtes drittes Produkt.

Ob eine Komponente eigenständiges Produkt oder Bestandteil einer Produktkonfiguration ist, entscheidet die konkrete Vermarktungs-, Verantwortungs- und Funktionsstruktur. Die Zahl der zu bewertenden Einheiten ist daher architekturabhängig und in der Regel größer als eins.

Quellen: Art. 3 Nr. 1 und 2, Erwägungsgrund 12 CRA · Leitlinien der Kommission C(2026) 5252 · Kommission: CRA Implementation

Entscheidend ist die Geschäftstätigkeit, nicht das Entwicklungsmodell. Nicht monetarisierte freie und quelloffene Software gilt nicht als auf dem Markt bereitgestellt. Weder eine finanzielle Unterstützung durch Hersteller noch regelmäßige Releases machen ein Projekt für sich kommerziell.

Erwägungsgrund 15 nennt konkrete Anzeichen einer Geschäftstätigkeit — nicht nur einen Preis für das Produkt selbst:

• ein Entgelt für technische Unterstützungsleistungen, das über die Deckung der tatsächlichen Kosten hinausgeht
• Gewinnerzielungsabsicht, etwa über eine Softwareplattform, auf der andere Dienste gewinnorientiert angeboten werden
• Verarbeitung personenbezogener Daten als Nutzungsbedingung zu anderen Zwecken als der Verbesserung von Sicherheit, Kompatibilität oder Interoperabilität
• Spenden, die die Kosten von Konzeption, Entwicklung und Bereitstellung übersteigen — Spenden ohne Gewinnabsicht dagegen nicht

Bei Komponenten, die zur Integration durch andere Hersteller bestimmt sind, liegt eine Bereitstellung auf dem Markt nur vor, wenn die Komponente vom ursprünglichen Hersteller zu Geld gemacht wird. Gemeinnützige Organisationen gelten nicht als kommerziell tätig, sofern alle Einnahmen nach Abzug der Kosten gemeinnützigen Zielen dienen.

Auch nicht erfasst: natürliche und juristische Personen, die Quellcode zu Projekten beitragen, die nicht ihrer Verantwortung unterliegen. Und die bloße Bereitstellung in offenen Archiven oder über Paketverwaltung ist noch kein Inverkehrbringen.

Quellen: Erwägungsgründe 15, 17, 18, 20 CRA

Eine juristische Person — keine natürliche Person, kein Hersteller —, die die Entwicklung kommerziell genutzter FOSS dauerhaft und systematisch unterstützt und eine wichtige Rolle für deren Brauchbarkeit spielt (Art. 3 Nr. 14). Dazu zählen Stiftungen, die Plattformen und Quellcode hosten oder die Entwicklung steuern.

Es gilt ein vereinfachtes Regime (Art. 24):

• eine auf überprüfbare Weise entwickelte und dokumentierte Cybersicherheitsstrategie, die sichere Entwicklung und wirksamen Umgang mit Schwachstellen fördert — einschließlich der Förderung freiwilliger Meldungen nach Art. 15 durch die Entwickler (Art. 24 Abs. 1)
• Zusammenarbeit mit den Marktüberwachungsbehörden
• Meldepflicht nach Art. 14 Abs. 1 für aktiv ausgenutzte Schwachstellen, soweit sie an der Entwicklung des Produkts beteiligt sind
• zusätzlich Art. 14 Abs. 3 und 8 — schwerwiegende Vorfälle und Nutzerinformation —, soweit ein solcher Vorfall die vom Verwalter für die Entwicklung bereitgestellten Netz- und Informationssysteme betrifft (Art. 24 Abs. 3)

Nicht gefordert: Konformitätsbewertung und technische Dokumentation nach Art. 31. Die CE-Kennzeichnung ist Verwaltern nach Erwägungsgrund 19 sogar ausdrücklich untersagt — sie dürfen sie auf Produkten, deren Entwicklung sie unterstützen, nicht anbringen. Nach Art. 64 Abs. 10 sind Verwalter von Geldbußen ausgenommen. Zu den Verwaltern zählen ausdrücklich auch gemeinnützige Einrichtungen.

Quellen: Art. 3 Nr. 14, Art. 24, Art. 64 Abs. 10, Erwägungsgründe 19 und 21 CRA

Rechtsgrundlage ist Art. 7 mit Anhang III (wichtige Produkte, Klasse I und II) und Anhang IV (kritische Produkte), konkretisiert durch die Durchführungsverordnung (EU) 2025/2392. Deren Anhang I beschreibt die wichtigen, Anhang II die kritischen Produkte.

Entscheidend ist die Kernfunktion, nicht die Feature-Liste. Die bloße Integration einer wichtigen oder kritischen Komponente zieht das Gesamtprodukt nicht in die strengere Klasse.

Arbeitstest. Praxis „Ohne Funktion X erfüllt das Produkt seinen Zweck nicht.“ Nur X wird gegen Anhang III und IV abgeglichen. Eine Heuristik, keine gesetzliche Definition — maßgeblich bleibt Art. 7 mit der DVO 2025/2392.

Beispiele aus Verordnung und Leitlinien: Ein Smartphone mit integriertem Passwortmanager wird kein Passwortmanager. Ein Betriebssystem mit integriertem Browser bleibt ein Betriebssystem. Ein Produkt, das nur eine Firewall-Komponente enthält, wird kein Klasse-II-Firewall-Produkt.

Dahinter stehen die Risikokriterien der Erwägungsgründe 43, 44 und 46: Cybersicherheitsfunktion des Produkts, Potenzial zur Störung einer großen Zahl anderer Produkte, Beeinträchtigung von Gesundheit oder Sicherheit der Nutzer, Ausübung einer zentralen Systemfunktion (Netzverwaltung, Konfigurationskontrolle, Virtualisierung, Verarbeitung personenbezogener Daten) und — für Anhang IV — kritische Abhängigkeit wesentlicher NIS2-Einrichtungen.

Quellen: Art. 7, Erwägungsgründe 43–46 CRA · DVO (EU) 2025/2392 · BSI-Flyer: Produktklassen und Konformität (PDF)

Standardprodukte (Default). Alles, was nicht in Anhang III oder IV steht. Die Kommission schätzt rund 90 Prozent der erfassten Produkte. Beispiele: Festplatten, PC-Spiele, gewöhnliche Anwendungssoftware.

Wichtige Produkte Klasse I (Anhang III): Identitätsmanagement- und PAM-Systeme samt Authentifizierungs- und Zugangskontrollleser, auch biometrische; eigenständige und eingebettete Browser; Passwortmanager; Software zum Suchen, Entfernen oder Isolieren von Schadsoftware; VPN-Produkte; Netzwerkmanagementsysteme; SIEM; Boot-Manager; PKI- und Zertifikatsausstellungssoftware; physische und virtuelle Netzschnittstellen; Betriebssysteme; Router, Internet-Modems, Switches; Mikroprozessoren, Mikrocontroller sowie ASICs und FPGAs mit sicherheitsbezogenen Funktionen; Smart-Home-Sprachassistenten; Smart-Home-Produkte mit Sicherheitsfunktion wie Türschlösser, Sicherheitskameras, Babyphones, Alarmanlagen; vernetztes Spielzeug mit sozial-interaktiven Merkmalen oder Standortverfolgung; Wearables mit Gesundheitsüberwachungszweck oder für Kinder.

Wichtige Produkte Klasse II (Anhang III): Hypervisoren und Container-Runtime-Systeme; Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme; manipulationssichere Mikroprozessoren; manipulationssichere Mikrocontroller.

Kritische Produkte (Anhang IV): Hardwaregeräte mit Sicherheitsboxen; Smart-Meter-Gateways und weitere Geräte für fortgeschrittene Sicherheitszwecke einschließlich sicherer Kryptoverarbeitung; Chipkarten und ähnliche Geräte einschließlich Sicherheitselemente.

Planungssicherheit bei künftigen Listenänderungen: Fügt die Kommission per delegiertem Rechtsakt eine neue Kategorie in Anhang III ein oder verschiebt sie eine Kategorie von Klasse I nach Klasse II, sieht der Rechtsakt nach Art. 7 Abs. 3 gegebenenfalls einen Übergangszeitraum von mindestens zwölf Monaten vor, bevor die strengeren Verfahren greifen — außer bei äußerster Dringlichkeit.

Häufige Verwechslung: Chipkarten und Secure Elements stehen in Anhang IV (kritisch), nicht in Klasse II. Chipkartenleser fallen als Zugangskontrollleser unter Anhang III Klasse I. Maßgeblich ist immer der Anhangstext plus DVO, nicht die Beispielliste einer Übersichtsseite.

Quellen: Anhang III im Volltext · Anhang IV im Volltext · Kommission: Conformity assessment

Nein — und das ist derzeit der wichtigste praktische Engpass. Stand heute ist keine CRA-harmonisierte Norm im Amtsblatt zitiert. Damit besteht keine Konformitätsvermutung nach Art. 27, und Sie müssen direkt gegen den Anhang-I-Text entwickeln und dokumentieren.

Stand der Normung: Der Normungsauftrag (Durchführungsbeschluss C(2025) 618 vom 3.2.2025, rund 41 Normen) wurde am 3.4.2025 von CEN, CENELEC und ETSI angenommen. CEN und CENELEC arbeiten an den horizontalen Normen der EN-40000-Serie sowie an produktspezifischen Dokumenten, darunter die IEC-62443-basierten OT-Profile der EN 50770; ETSI brachte im August 2026 17 vertikale Entwürfe in das Public-Enquiry-Verfahren. Liefertermine einzelner Normen verschieben sich häufig — verlassen Sie sich auf das aktuelle M/606-Arbeitsprogramm und das jeweilige Work Item, nicht auf Termine in Sekundärquellen.

Folge für Klasse-I-Produkte: Der Selbstbewertungspfad des Art. 32 Abs. 2 setzt voraus, dass die einschlägigen Anforderungen durch harmonisierte Normen, gemeinsame Spezifikationen oder ein geeignetes EU-Zertifizierungsschema abgedeckt sind. Solange keiner dieser drei Wege verfügbar ist, bleibt faktisch die Drittbewertung — mit entsprechender Vorlaufzeit bei den notifizierten Stellen.

Quellen: Art. 27, Art. 32 Abs. 2 CRA · Kommission: CRA Implementation

Praxis Empfohlener Arbeitsablauf; der CRA gibt kein Verfahren in drei Schritten vor.

1. Scope prüfen: Produkt mit digitalen Elementen nach Art. 3 Nr. 1 und nicht nach Art. 2 ausgenommen?
2. Kernfunktion bestimmen und abgleichen: zuerst gegen Anhang IV, dann gegen Anhang III, jeweils verifiziert gegen die technischen Beschreibungen der DVO 2025/2392 — nicht nur gegen die Kategorienamen.
3. Konformitätsweg ableiten und begründen: Verfahren wählen und die Einstufungsentscheidung mit Begründung in der technischen Dokumentation nach Anhang VII festhalten.

Zwei Punkte, an denen es in der Praxis kippt:

• Konsistenz. Marketingmaterial, Benutzeranleitung und technische Dokumentation müssen dieselbe Kernfunktion beschreiben. Wer ein Produkt als Firewall bewirbt, kann es nicht als Standardprodukt einordnen.
• Negativentscheidungen dokumentieren. „Geprüft, keine Anhang-III-Kategorie, weil …“ ist gegenüber der Marktüberwachung deutlich mehr wert als ein leeres Feld.

Quellen: Art. 7, Art. 32, Anhang VII

Klasse	Verfahren
Standard	Selbstbewertung, interne Kontrolle (Modul A, Anhang VIII Teil I) — Art. 32 Abs. 1
Wichtig Klasse I	Interne Konformitätsbewertung möglich, soweit die einschlägigen grundlegenden Anforderungen durch vollständig angewandte harmonisierte Normen, anwendbare gemeinsame Spezifikationen oder ein einschlägiges europäisches Cybersicherheitszertifizierungsschema mindestens der Stufe „mittel“ abgedeckt sind; sonst Modul B+C oder H — Art. 32 Abs. 2
Wichtig Klasse II	Immer Drittbewertung: Modul B+C oder H, oder EU-Zertifikat mindestens Stufe „mittel“ — Art. 32 Abs. 3
Kritisch	Nachweis über ein europäisches Cybersicherheitszertifizierungsschema nach Art. 8 Abs. 1, sofern ein solches per delegiertem Rechtsakt vorgeschrieben ist; sind dessen Bedingungen nicht erfüllt, gilt eines der Verfahren für Klasse II — Art. 32 Abs. 4

Alle Klassen erfüllen dieselben Anhang-I-Anforderungen. Die Klasse bestimmt nur den Nachweisweg — nicht das Schutzniveau.

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.

Quellen: Art. 32, Anhang VIII · Kommission: Conformity assessment · BSI-Flyer: Produktklassen und Konformität (PDF)

Jedes Modul prüft zwei Dinge gleichzeitig — das ist der Unterschied zu klassischen CE-Regimen:

1. Das Produkt gegen Anhang I Teil I, die 13 Produkteigenschaften.
2. Ihre Prozesse gegen Anhang I Teil II: Schwachstellenbehandlung, SBOM, koordinierte Offenlegung, Update-Auslieferung.

Punkt 2 ist der Grund, warum eine CRA-Bewertung ohne funktionierende Post-Market-Organisation nicht zu bestehen ist. Ein sicheres Produkt vorzeigen und die Prozesse nachziehen funktioniert nicht.

Quellen: Art. 6, Art. 13, Anhang I

Das ist die eigentliche Arbeit. Sie fällt identisch an, ob Modul A oder H:

Artefakt	Grundlage
Scope-Entscheidung und Rollenbestimmung	Art. 2, 3, 13, 21, 22
Klassifizierung mit Begründung	Art. 7, Anhang III/IV, DVO 2025/2392
Cybersicherheits-Risikobewertung	Art. 13 Abs. 2 und 3
Anforderungsmatrix Anhang I Teil I: je Buchstabe Umsetzung, Nachweis oder begründete Nichtanwendbarkeit	Anhang I Teil I
Prozessnachweise: Vulnerability-Handling-Policy, CVD-Policy, Advisory-Prozess, Update-Mechanismus, Testregime	Anhang I Teil II
SBOM je ausgeliefertem Artefakt und Version	Anhang I Teil II Nr. 1
Testberichte: SAST, DAST, Dependency-Scan, Pentest, Fuzzing wo einschlägig	Anhang I Teil II Nr. 3
Festgelegter Supportzeitraum samt Begründung	Art. 13 Abs. 8
Benutzerinformationen	Anhang II
Technische Dokumentation, die alles zusammenbindet	Anhang VII

Die Risikobewertung ist das Herzstück, nicht eine Formalie am Rand. Sie begründet, welche Anhang-I-Anforderungen in welcher Tiefe greifen und welche nicht anwendbar sind. Eine notifizierte Stelle liest sie zuerst — ist sie dünn, wird der Rest des Projekts teuer.

1. Unterlagen aus der vorigen Frage fertigstellen.
2. Interne Prüfung gegen die Anforderungsmatrix. Praxis Eine organisatorisch unabhängige interne Prüfperson und ein datiertes, unterzeichnetes Prüfprotokoll sind bewährte Governance, aber keine ausdrückliche CRA-Vorgabe.
3. Sicherstellen, dass Serienfertigung bzw. Build- und Release-Prozess die geprüfte Konformität reproduzieren.
4. EU-Konformitätserklärung ausstellen und unterzeichnen.
5. CE-Kennzeichnung anbringen.
6. Dokumentation zehn Jahre bzw. für den Supportzeitraum aufbewahren, je nachdem, was länger ist.

Keine notifizierte Stelle, keine Gebühren, keine Wartezeit — die volle rechtliche Verantwortung bleibt bei Ihnen.

Der aktuelle Knackpunkt: Ohne zitierte harmonisierte Norm gibt es keine Konformitätsvermutung. Anhang VII Nr. 5 verlangt dann ausdrücklich Beschreibungen der Lösungen, mit denen die grundlegenden Cybersicherheitsanforderungen in Anhang I Teile I und II erfüllt werden, mit einer Aufstellung sonstiger angewandter einschlägiger technischer Spezifikationen. Bei nur teilweiser Anwendung einer Norm ist zudem anzugeben, welche Teile angewandt wurden.

Die Inhalte sind damit verpflichtend. Praxis Eine Mapping-Tabelle ist unsere empfohlene Darstellungsform: Anhang-I-Anforderung → verwendete Lösung beziehungsweise Norm → Nachweis. Vorgeschrieben ist die Form nicht. Praxis Als technische Orientierung tragfähig sind IEC 62443-4-1 und -4-2, EN 18031-1/-2/-3, ETSI EN 303 645, ISO/IEC 27034 — keine dieser Normen erzeugt derzeit eine CRA-Konformitätsvermutung. Entscheidend ist die Aussage, dass die Norm die Anforderung abdeckt — und wo sie es nicht tut, nicht die bloße Nennung.

Quellen: Art. 13 Abs. 13, Art. 32 Abs. 1, Anhang VIII Teil I

Das klassische CE-Verfahren, aufgeteilt in Design-Prüfung durch eine notifizierte Stelle (B) und anschließende Serienphase in Ihrer Verantwortung (C).

Modul B im Ablauf:

1. Antrag bei einer notifizierten Stelle Ihrer Wahl — aber nur bei einer. Parallelanträge für dasselbe Baumuster sind unzulässig.
2. Einreichung: technische Dokumentation nach Anhang VII, Beschreibung der Schwachstellenbehandlungsverfahren, zusätzliche Nachweise, plus Muster wichtiger Produktteile. Bei Software heißt das üblicherweise Build-Artefakt, Testumgebung, Quellcodezugang in vereinbartem Umfang, Zugang zur Referenzinstallation.
3. Prüfung: Die Stelle bewertet die Eignung der technischen Konzeption und Entwicklung anhand der Dokumentation und untersucht Muster — Kombination aus Bau- und Konzeptionsmuster. Sie prüft ausdrücklich auch, ob Sie die Anforderungen aus Anhang I Teil II erfüllen.
4. Feststellungen und Nachbesserung. Praxis Zwei Runden sind ein Erfahrungswert; die tatsächliche Zahl hängt von Produktreife und Prüfstelle ab.
5. EU-Baumusterprüfbescheinigung im Erfolgsfall, mit Geltungsdauer und Bedingungen. Bei Ablehnung ausführliche Begründung und Rechtsmittelweg.
6. Änderungsmitteilung: Jede Änderung am zugelassenen Baumuster ist der Stelle zu melden; sie entscheidet, ob die Bescheinigung weiter trägt oder eine ergänzende Prüfung nötig ist.

Modul C ist dann Ihre Arbeit: sicherstellen, dass ausgelieferte Produkte dem zugelassenen Baumuster entsprechen, laufende Erfüllung der Anhang-I-Teil-II-Pflichten, Konformitätserklärung, CE-Kennzeichnung.

Quellen: Art. 32 Abs. 2 und 3, Anhang VIII Teil II und III

Hier bewertet, genehmigt und überwacht die notifizierte Stelle Ihr Qualitätssicherungssystem für Konzeption, Entwicklung, Endprüfung und Schwachstellenbehandlung. Danach bescheinigen Sie die Konformität einzelner Produkte auf Basis des zugelassenen Systems — ohne dass jedes Produkt einzeln zur Prüfung geht.

Ablauf: Antrag mit QS-Dokumentation → Systembewertung inklusive Vor-Ort-Audit → Zulassung → laufende Überwachung mit periodischen Audits und Kontrollbesuchen → Meldung geplanter Systemänderungen.

Für Softwarehersteller ist die Modulwahl keine Formalie. Modul B ist baumusterbezogen. Bei Continuous Delivery mit wöchentlichen Releases wird „ist das noch das zugelassene Baumuster?“ zum Dauerthema und produziert fortlaufend ergänzende Prüfungen. Modul H ist prozessbezogen und passt zu einem CI/CD-Modell häufig besser: höhere Anfangsinvestition, planbarer im Betrieb, und mehrere Produkte laufen unter einem System. Praxis Das ist eine fachliche Einschätzung, keine Wertung des CRA — beide Module sind gleichwertig zulässig.

Wer bereits einen sicheren Entwicklungslebenszyklus nach IEC 62443-4-1 und ein ISMS nach ISO/IEC 27001 betreibt, hat große Teile dessen, was Modul H sehen will. Das ersetzt die Zulassung nicht, füllt sie aber.

Quellen: Art. 32, Anhang VIII Teil IV

Open-Source-Produkte in Anhang-III-Kategorien: Modul A bleibt offen. Nach Art. 32 Abs. 5 dürfen Hersteller von Produkten, die als freie und quelloffene Software gelten und in eine Kategorie des Anhangs III fallen, jedes der Verfahren nach Art. 32 Abs. 1 nutzen — also auch die interne Kontrolle nach Modul A —, sofern die technische Dokumentation nach Art. 31 zum Zeitpunkt des Inverkehrbringens öffentlich zugänglich gemacht wird. Damit lässt sich die Drittbewertung für ein Klasse-I- oder Klasse-II-Produkt vermeiden, wenn Sie die Dokumentation offenlegen.

Vereinfachte technische Dokumentation — mit Annahmepflicht. Nach Art. 33 erstellt die Kommission per Durchführungsrechtsakt ein vereinfachtes Formular für die technische Dokumentation, zugeschnitten auf Kleinst- und Kleinunternehmen. Entscheidet sich ein solches Unternehmen für die vereinfachte Bereitstellung der Anhang-VII-Informationen, verwendet es dieses Formular — und die notifizierten Stellen akzeptieren es für die Zwecke der Konformitätsbewertung. Sie können also nicht auf einer umfangreicheren Dokumentationsform bestehen.

Ergänzend: Die Kommission stellt nach Art. 26 KMU-Leitlinien bereit und informiert über verfügbare finanzielle Unterstützung im Rahmen bestehender Unionsprogramme.

Gebührensenkung für KMU. Nach Art. 32 Abs. 6 sind bei der Festlegung der Gebühren für die Konformitätsbewertung die besonderen Interessen und Bedürfnisse von Kleinstunternehmen sowie kleinen und mittleren Unternehmen einschließlich Start-ups zu berücksichtigen, und die Gebühren sind entsprechend zu senken. Praxis Sprechen Sie die Gebührenermäßigung bei der notifizierten Stelle aktiv an.

Quellen: Art. 31, Art. 32 Abs. 5 und 6, Art. 33 CRA

Kapitel IV ist seit 11.6.2026 anwendbar, die Stellen können also notifiziert werden und arbeiten. Suchen in der NANDO-Datenbank der Kommission, gefiltert nach CRA und dem passenden Notifizierungsumfang — eine auf Chipkarten notifizierte Stelle hilft Ihnen bei einem Hypervisor nicht. In Österreich akkreditiert Akkreditierung Austria; notifizierende Behörde ist das Bundeskanzleramt.

Auswahlfragen, die sich lohnen: Umfang der Notifizierung, Erfahrung mit reiner Software gegenüber Hardware, Bereitschaft zu Modul H, Umgang mit Änderungen am Baumuster bei häufigen Releases, aktuelle Kapazität und Wartezeit, Sprache, Einsatz von Unterauftragnehmern.

Zwei Hebel aus dem Verordnungstext: Nach Art. 47 Abs. 2 werden Konformitätsbewertungen unter Wahrung der Verhältnismäßigkeit durchgeführt, wobei unnötige Belastungen der Wirtschaftsakteure vermieden werden. Und nach Art. 44 erhält eine Stelle auch dann nur eine einzige Kennnummer, wenn sie nach mehreren Unionsrechtsakten notifiziert ist — die Kommission veröffentlicht das Verzeichnis samt Tätigkeiten.

Für Hochrisiko-KI-Systeme gilt zudem: Die nach der KI-Verordnung zuständigen notifizierten Stellen sind auch für die Prüfung der CRA-Anhang-I-Konformität zuständig, sofern im Notifizierungsverfahren geprüft wurde, dass sie die Anforderungen des Art. 39 CRA erfüllen.

Timing. Praxis Engpässe vor Dezember 2027 sind ein plausibles Planungsrisiko, keine belegte Tatsache. Wer Klasse II oder kritische Produkte im Portfolio hat, fragt trotzdem besser früh an — und prüft parallel, ob ein europäisches Zertifizierungsschema den Weg abkürzt.

Quellen: Art. 35–51, Art. 71 Abs. 2 CRA · NANDO: notifizierte Stellen · BKA: notifizierende Behörde

Pflichtinhalte der Erklärung (Anhang V): Name und Anschrift des Herstellers; Gegenstand der Erklärung — eine Produktbeschreibung, die die Rückverfolgbarkeit ermöglicht, bei physischen Produkten gegebenenfalls mit Bild oder Zeichnung; die Aussage, dass die Erklärung in alleiniger Verantwortung ausgestellt wird; Verweis auf den CRA und die weiteren einschlägigen Rechtsakte; angewandte harmonisierte Normen, gemeinsame Spezifikationen oder Zertifizierungsschemata; das angewandte Konformitätsbewertungsverfahren; gegebenenfalls Name, Nummer und Tätigkeit der notifizierten Stelle samt Bescheinigungsnummer; Ort und Datum der Ausstellung sowie Name und Funktion des Unterzeichners.

Sprachenpflicht — oft übersehen. Nach Art. 28 Abs. 2 wird die Erklärung in den Sprachen abgefasst, die der Mitgliedstaat vorschreibt, in dem das Produkt in den Verkehr gebracht oder auf dem Markt bereitgestellt wird. Wer in mehrere Mitgliedstaaten liefert, braucht die Erklärung entsprechend in mehreren Sprachen. Dasselbe gilt für die vereinfachte Erklärung, die im Aufbau dem Muster in Anhang VI folgt.

Mehrere Rechtsakte, eine Erklärung. Unterliegt das Produkt weiteren Unionsrechtsvorschriften, die je eine Konformitätserklärung verlangen, ist eine einzige Erklärung für sämtliche Vorschriften auszustellen, in der die betreffenden Rechtsakte samt ihren Fundstellen im Amtsblatt anzugeben sind (Art. 28 Abs. 3).

Und die Rechtsfolge in einem Satz: Mit der Ausstellung der EU-Konformitätserklärung übernimmt der Hersteller die Verantwortung für die Konformität des Produkts (Art. 28 Abs. 4). Die Erklärung ist keine Formalie am Ende, sondern der Akt, mit dem die Haftung zugewiesen wird.

Praxis Eine laufende Erklärungsnummer ist in Anhang V nicht vorgeschrieben, aber für Versionsverwaltung und Nachverfolgung dringend zu empfehlen.

Das Ausstellungsdatum muss nach Abschluss der Bewertung liegen, und der Unterzeichner muss den Hersteller rechtlich verpflichten können. Entscheidend ist die eindeutige Identifikation des abgedeckten Produkts und der abgedeckten Version oder Versionen — nicht zwingend ein separates Dokument je Build.

Dem Produkt ist entweder eine Kopie der EU-Konformitätserklärung oder eine vereinfachte EU-Konformitätserklärung beizufügen; im zweiten Fall muss darin die genaue Internetadresse der vollständigen Erklärung stehen (Art. 13 Abs. 20).

CE-Kennzeichnung (Art. 29, 30): gut sichtbar, leserlich und dauerhaft auf dem Produkt anzubringen. Lässt die Art des Produkts das nicht zu oder rechtfertigt es nicht, wird sie auf der Verpackung und auf der beigefügten EU-Konformitätserklärung angebracht — nicht wahlweise, sondern auf beidem (Art. 30 Abs. 1).

Angebracht wird sie vor dem Inverkehrbringen. Ihr kann ein Piktogramm oder ein anderes Zeichen folgen, das auf ein besonderes Cybersicherheitsrisiko oder eine besondere Verwendung hinweist; solche Zeichen werden erst durch Durchführungsrechtsakte festgelegt (Art. 30 Abs. 3).

Kennnummer der notifizierten Stelle — im Wortlaut geregelt. Nach Art. 30 Abs. 4 folgt der CE-Kennzeichnung die Kennnummer der notifizierten Stelle, sofern diese an dem Konformitätsbewertungsverfahren auf der Grundlage einer umfassenden Qualitätssicherung (auf der Grundlage von Modul H) beteiligt ist. Bei Modul A und Modul B+C entfällt sie also. Angebracht wird sie von der Stelle selbst oder nach ihren Anweisungen durch den Hersteller oder seinen Bevollmächtigten.

Quellen: Art. 28, 29, 30, Anhang V

Praxis Die folgenden Laufzeiten sind Projektannahmen aus der Beratungspraxis. Der CRA legt keine Fristen für die Bewertung fest; die tatsächliche Dauer hängt stark von Produkt, Reifegrad und Prüfstelle ab.

Phase	Inhalt	Dauer
1	Scope, Rollen, Klassifizierung	2–4 Wochen
2	Risikobewertung, Anforderungsmatrix, Gap-Analyse	4–8 Wochen
3	Lücken schließen: Produktänderungen, SBOM-Toolchain, CVD, Advisory-Prozess	3–9 Monate
4	Technische Dokumentation nach Anhang VII konsolidieren	4–6 Wochen
5	Modul A: interne Prüfung — Modul B/H: Einreichung und Prüfung	A: 2–4 Wochen · B/H: 3–9 Monate
6	Erklärung, CE, Ablage	1–2 Wochen

Phase 3 dominiert und entscheidet über das Gesamtergebnis. Wer sie unterschätzt, landet in Phase 5 mit Feststellungen, die Produktänderungen erfordern — der teuerste Moment dafür.

Wiederkehrende Fehler:

• Modul A für ein Klasse-II-Produkt — ungültige Bewertung, kein rechtmäßiges Inverkehrbringen.
• Zusammengesetzte Produkte: Für jedes separat in Verkehr gebrachte Produkt oder Komponente ist eine eigene Bewertung nötig — bloß intern integrierte Bauteile werden dadurch nicht zu eigenständigen CRA-Produkten. Sie dürfen sich auf die Konformitätserklärung einer integrierten Komponente stützen, müssen das Endprodukt aber als Ganzes bewerten.
• Anhang I Teil II wird vergessen, weil man an CE als reine Produktprüfung denkt. Die Prozesse werden in jedem Modul mitgeprüft.
• Konformitätserklärung vor Abschluss der Bewertung datiert oder von einer nicht vertretungsbefugten Person unterschrieben.
• Erhebliche Veränderung nach der Bewertung, ohne die Bewertung nachzuziehen.

Der Kopfsatz (Nr. 1) ist selbst eine Anforderung, keine Präambel: Produkte mit digitalen Elementen sind so zu konzipieren, zu entwickeln und herzustellen, dass sie ein den Risiken angemessenes Cybersicherheitsniveau gewährleisten. Das ist die Auffangnorm — wer alle 13 Buchstaben abhakt, aber ein erkennbares Risiko unbehandelt lässt, erfüllt Nr. 1 nicht.

Nr. 2 bindet die 13 Buchstaben an die Risikobewertung nach Art. 13 Abs. 2 und an „soweit anwendbar“. Beides ist zu dokumentieren, nicht zu behaupten.

a) Keine bekannten ausnutzbaren Schwachstellen bei der Bereitstellung auf dem Markt. Der Stichtag ist das Inverkehrbringen, nicht der Feature-Freeze — also Dependency-Scan im Release-Gate, nicht nur im Nightly Build.

b) Sichere Standardkonfiguration, einschließlich der Möglichkeit, das Produkt in den Ursprungszustand zurückzusetzen. Hier sitzt die B2B-Ausnahme. Nach Erwägungsgrund 64 dürfen Hersteller von den grundlegenden Cybersicherheitsanforderungen nur abweichen, wenn es sich um maßgeschneiderte Produkte handelt, die für einen bestimmten gewerblichen Nutzer auf einen bestimmten Zweck zugeschnitten sind und wenn sowohl Hersteller als auch Nutzer ausdrücklich anderen Vertragsbedingungen zugestimmt haben. Ausdrücklich heißt: nicht implizit über AGB, und nicht bei Standardprodukten mit Individualkonfiguration.

c) Behebbarkeit durch Sicherheitsupdates, gegebenenfalls durch automatische Updates, die in einem angemessenen Zeitraum installiert werden und standardmäßig aktiviert sind, mit klarem und einfachem Opt-out, Benachrichtigung über verfügbare Updates und der Option, sie vorübergehend aufzuschieben.

Für OT, Industrie und Komponenten gibt es hier eine ausdrückliche Einschränkung. Nach Erwägungsgrund 56 gelten die Anforderungen an automatische Aktualisierungen nicht für Produkte, die in erster Linie zur Integration als Komponente in andere Produkte bestimmt sind, und nicht für Produkte, bei denen Nutzer normalerweise keine automatischen Aktualisierungen erwarten würden — einschließlich Produkten für professionelle IKT-Netze und insbesondere für kritische und industrielle Umgebungen, in denen eine automatische Aktualisierung den Betrieb stören könnte.

Was dadurch nicht entfällt: Unabhängig davon, ob ein Produkt für automatische Aktualisierungen konzipiert ist, muss der Hersteller die Nutzer über Schwachstellen informieren und Sicherheitsupdates unverzüglich bereitstellen. Die Behebbarkeit durch Sicherheitsupdates nach Buchstabe c bleibt also Pflicht — nur der Automatismus ist für diese Produktgruppen nicht gefordert.

d) Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen — Authentifizierung, Identitäts- oder Zugriffsmanagement — und Meldung möglicher unbefugter Zugriffe. Der zweite Halbsatz wird regelmäßig überlesen: Es geht nicht nur um Verhinderung, sondern um Sichtbarmachung.

e) Vertraulichkeit gespeicherter, übermittelter oder anderweitig verarbeiteter Daten — personenbezogen oder nicht — etwa durch Verschlüsselung ruhender und übertragener Daten nach dem Stand der Technik.

f) Integrität von Daten, Befehlen, Programmen und Konfiguration gegen jede nicht vom Nutzer autorisierte Manipulation oder Änderung, und Meldung von Beschädigungen. Dass Konfiguration und Befehle mitgenannt sind, ist für Steuerungssysteme der eigentliche Kern.

g) Datenminimierung: Verarbeitung nur solcher Daten, die dem Verwendungszweck angemessen, dafür erheblich und darauf beschränkt notwendig sind.

h) Verfügbarkeit wesentlicher und grundlegender Funktionen, auch nach einem Vorfall, einschließlich Resilienz- und Abwehrmaßnahmen gegen Denial-of-Service.

i) Minimierung negativer Auswirkungen des Produkts selbst oder verbundener Geräte auf die Verfügbarkeit von Diensten anderer Geräte oder Netze. Das ist die Botnet-Klausel: Ihr Produkt darf nicht zur Waffe gegen Dritte werden.

j) Begrenzung der Angriffsflächen, einschließlich externer Schnittstellen.

k) Verringerung der Auswirkungen eines Vorfalls durch geeignete Mechanismen und Techniken zur Exploit-Minderung. Praxis ASLR, Stack-Canaries, Sandboxing, Least Privilege, Speichersicherheit und Prozesstrennung sind gängige Beispiele; der CRA nennt keine bestimmten Techniken.

l) Sicherheitsrelevante Informationen bereitstellen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge, einschließlich Zugriff auf oder Änderung von Daten, Diensten und Funktionen — mit Opt-out für den Nutzer.

m) Sichere und einfache dauerhafte Löschung aller Daten und Einstellungen durch den Nutzer; sind die Daten auf andere Produkte oder Systeme übertragbar, muss auch das sicher erfolgen.

„Soweit anwendbar“ ist keine Ausstiegsklausel — und das steht ausdrücklich im Text. Nach Art. 13 Abs. 3 muss die Risikobewertung angeben, ob und in welcher Weise die Anforderungen aus Anhang I Teil I Nr. 2 auf das Produkt anwendbar sind und wie sie umgesetzt werden. Nach Art. 13 Abs. 4 nimmt der Hersteller für nicht anwendbare Anforderungen eine klare Begründung in die technische Dokumentation auf. Bleibt dabei ein Risiko offen, braucht es eine Alternativmaßnahme: Beschränkung auf vertrauenswürdige Umgebungen, kompensierende Kontrolle oder klare Nutzerinformation nach Anhang II.

Bauen Sie die Matrix mit 14 Zeilen, nicht 13 — 13 Buchstaben a bis m plus der Risikosatz aus Nr. 1. Die Matrixform selbst ist nicht vorgeschrieben — der Inhalt aber schon: Anhang VII Nr. 3 verlangt die Angabe, inwieweit die Anforderungen aus Anhang I Teil I Anwendung finden, Nr. 5 die Beschreibung der gewählten Lösungen.
— Nr. 1 gehört als eigene Zeile dazu. Spalten: Anforderung, Anwendbarkeit mit Begründung, technische Umsetzung, Nachweis (Testbericht, Architekturdokument, Codestelle, Konfigurationsbaseline), Referenznorm. Diese Tabelle ist später das Rückgrat der technischen Dokumentation nach Anhang VII und das Erste, was eine notifizierte Stelle sehen will.

Zur Mapping-Spalte: Zu d, e, f, j, k und l lässt sich IEC 62443-4-2 sauber zuordnen, zu a und c eher 62443-4-1 in Verbindung mit den Release-Prozessen.

Quellen: Anhang I Teil I im Volltext · Art. 13 Abs. 2 und 3, Erwägungsgründe 55 und 56 CRA

Acht Anforderungen, zu erfüllen über den gesamten Supportzeitraum:

• Schwachstellen und Komponenten identifizieren und dokumentieren, einschließlich SBOM
• Schwachstellen unverzüglich beheben, unter anderem durch Sicherheitsupdates
• regelmäßige Tests und Überprüfungen der Sicherheit
• nach Bereitstellung einer Sicherheitsaktualisierung Informationen über die behobene Schwachstelle teilen und veröffentlichen, samt Auswirkung, Schwere und Abhilfehinweisen — die Veröffentlichung darf in hinreichend begründeten Fällen aufgeschoben werden, bis Nutzer den Patch anwenden konnten
• Politik zur koordinierten Offenlegung von Schwachstellen
• Maßnahmen zur Erleichterung der Meldung von Schwachstellen, auch für Dritte
• Mechanismen zur sicheren Verteilung von Updates
• Sicherheitsupdates unverzüglich und kostenlos verbreiten, samt Hinweisen zu möglichen Maßnahmen — bei maßgeschneiderten Produkten für einen gewerblichen Nutzer kann Abweichendes vereinbart werden

Sicherheitsupdates sind, soweit technisch machbar, getrennt von Funktionsupdates bereitzustellen, damit Nutzer nicht gezwungen sind, neue Funktionen mitzunehmen.

Quellen: Anhang I Teil II · Erwägungsgrund 57 CRA

Die SBOM ist nach Art. 3 Nr. 39 ein formaler Datensatz mit Angaben und Lieferkettenbeziehungen der Komponenten. Verpflichtend sind mindestens die Top-Level-Abhängigkeiten, in einem gängigen maschinenlesbaren Format. CycloneDX und SPDX sind die heute übliche Wahl; der CRA nennt derzeit kein Format namentlich — Art. 13 Abs. 24 erlaubt eine spätere Spezifizierung.

Keine Veröffentlichungspflicht. Die SBOM ist Teil der technischen Dokumentation und der Marktüberwachungsbehörde nach Anhang VII Nr. 8 auf begründetes Verlangen vorzulegen, soweit dies für die Prüfung der Anhang-I-Konformität erforderlich ist. Die Behörden können Abhängigkeitsinformationen anonymisiert und aggregiert an die Gruppe für administrative Zusammenarbeit weitergeben.

Praxis Erzeugen Sie die SBOM je ausgeliefertem Artefakt und Version automatisiert in der Pipeline und bewahren Sie sie unveränderlich auf. Der CRA verlangt die Identifikation der Komponenten, nicht diese konkrete Architektur. Eine SBOM des aktuellen Hauptbranches beantwortet die Ernstfallfrage nicht — die lautet: Welche im Feld befindlichen Versionen enthalten diese Komponente?

Quellen: Art. 3 Nr. 39, Anhang I Teil II Nr. 1, Anhang VII, Erwägungsgrund 22 CRA

Der Supportzeitraum muss die voraussichtliche Nutzungsdauer abbilden und beträgt mindestens fünf Jahre.

Fünf Jahre sind eine Untergrenze, kein Standardwert. Erwägungsgrund 60 nennt ausdrücklich längere Zeiträume für Hauptplatinen, Mikroprozessoren, Router, Modems, Switches, Betriebssysteme — und betont, dass Produkte für industrielle Umgebungen wie Steuerungssysteme häufig deutlich länger im Einsatz sind.

Kürzer als fünf Jahre ist nur zulässig, wenn die Natur des Produkts es rechtfertigt und die erwartete Nutzungsdauer kürzer ist — Beispiel aus der Verordnung: eine Kontaktnachverfolgungs-App für die Dauer einer Pandemie.

Weitere Regeln:

• Das Ende des Supportzeitraums ist beim Kauf klar anzugeben, mindestens mit Monat und Jahr (Art. 13 Abs. 19).
• Bei Software dürfen Sie sich auf die zuletzt in Verkehr gebrachte Version beschränken, wenn Nutzer ohne Zusatzkosten für Hardware- oder Softwareumgebung darauf wechseln können (Art. 13 Abs. 10). Die übrigen Anforderungen an die Schwachstellenbehandlung — etwa die koordinierte Offenlegung — gelten weiterhin für alle nachfolgenden wesentlich geänderten Versionen (Erwägungsgrund 40).
• Ist ein Hardwareprodukt nicht mit der neuesten Betriebssystemversion kompatibel, mit der es ursprünglich geliefert wurde, sind während des Supportzeitraums zumindest für die letzte kompatible Betriebssystemversion weiterhin Sicherheitsupdates bereitzustellen (Erwägungsgrund 40).
• Jede während des Supportzeitraums bereitgestellte Sicherheitsaktualisierung muss nach ihrer Bereitstellung mindestens zehn Jahre oder für die verbleibende Dauer des Supportzeitraums verfügbar bleiben, je nachdem, welcher Zeitraum länger ist (Art. 13 Abs. 9). Die Frist läuft je Update ab dessen Bereitstellung, nicht ab dem Inverkehrbringen des Produkts.
• Bei der Festlegung dürfen Sie nach Art. 13 Abs. 8 zusätzlich berücksichtigen: die Supportzeiträume vergleichbarer Produkte anderer Hersteller, die Verfügbarkeit der Betriebsumgebung, die Supportzeiträume zugekaufter Komponenten, die Kernfunktionen erbringen, sowie einschlägige Leitlinien der ADCO und der Kommission.
• Soweit technisch machbar, ist den Nutzern eine Mitteilung anzuzeigen, wenn der Supportzeitraum endet (Art. 13 Abs. 19).
• Öffentliche Softwarearchive mit historischen Versionen sind erlaubt — dann müssen Nutzer klar über die Risiken nicht unterstützter Software informiert werden (Art. 13 Abs. 11).
• Wer die Betriebstätigkeit einstellt und die Verordnung deshalb nicht mehr erfüllen kann, muss vorher die Marktüberwachungsbehörden und, soweit möglich, die Nutzer informieren (Art. 13 Abs. 23).
• Erwägen Sie am Ende des Supportzeitraums die Freigabe des Quellcodes, damit Schwachstellen weiter behandelt werden können (Erwägungsgrund 61).

Quellen: Art. 3 Nr. 20, Art. 13 Abs. 8–10 und 19, Erwägungsgründe 59–62 CRA

Art. 31 Abs. 1 setzt den Maßstab: Die technische Dokumentation enthält alle relevanten Daten oder Angaben zu den Mitteln, mit denen der Hersteller sicherstellt, dass das Produkt und die von ihm festgelegten Verfahren die grundlegenden Anforderungen des Anhangs I erfüllen. Anhang VII ist dabei das Minimum, nicht die Obergrenze — und die Dokumentation deckt ausdrücklich beides ab: Produkt und Prozesse.

Anhang VII verlangt acht Blöcke, jeweils soweit für das Produkt von Bedeutung:

1. Allgemeine Produktbeschreibung mit Zweckbestimmung, den Softwareversionen, die sich auf die Erfüllung der Anforderungen auswirken, bei Hardware Fotografien oder Abbildungen zu äußeren Merkmalen, Kennzeichnungen und innerem Aufbau, sowie den Nutzerinformationen nach Anhang II.
2. Beschreibung von Konzeption, Entwicklung, Herstellung und der Verfahren zur Schwachstellenbehandlung, einschließlich Systemarchitektur (wie Softwarekomponenten aufeinander aufbauen und zusammenwirken), SBOM, CVD-Konzept, Nachweis der Bereitstellung einer Kontaktadresse, Beschreibung der technischen Lösungen für die sichere Verbreitung von Aktualisierungen, sowie Herstellungs- und Überwachungsprozesse samt deren Validierung.
3. Die Risikobewertung, einschließlich der Frage, inwieweit die Anforderungen aus Anhang I Teil I Anwendung finden.
4. Die Informationen, die bei der Festlegung des Supportzeitraums berücksichtigt wurden.
5. Aufstellung der ganz oder teilweise angewandten harmonisierten Normen, gemeinsamen Spezifikationen oder Zertifizierungsschemata — oder, wenn keine angewandt werden, Beschreibungen der gewählten Lösungen samt sonstiger technischer Spezifikationen.
6. Test- und Prüfberichte zur Konformität des Produkts und der Verfahren zur Schwachstellenbehandlung mit Anhang I Teile I und II.
7. Ein Exemplar der EU-Konformitätserklärung.
8. Die SBOM auf begründetes Verlangen der Marktüberwachungsbehörde, soweit für die Prüfung erforderlich.

• EU-Konformitätserklärung (Anhang V) und CE-Kennzeichnung (Art. 29, 30) — ab 11.12.2027.
• Benutzerinformationen (Anhang II), dem Produkt beizufügen, in neun Punkten: Herstellername und Kontaktmöglichkeit; die zentrale Kontaktstelle, bei der Schwachstellen gemeldet werden können und wo das CVD-Konzept zu finden ist; eindeutige Produktidentifikation; Zweckbestimmung einschließlich des bereitgestellten Sicherheitsumfelds, Hauptfunktionen und Sicherheitseigenschaften; bekannte oder vorhersehbare Umstände inklusive vorhersehbarer Fehlanwendung, die zu erheblichen Risiken führen können; gegebenenfalls die Internetadresse der EU-Konformitätserklärung; Art der technischen Sicherheitsunterstützung und Enddatum des Supportzeitraums; ausführliche Anleitungen zu Inbetriebnahme, Auswirkungen von Änderungen, Installation von Updates, sicherer Außerbetriebnahme und Datenlöschung, zum Deaktivieren der automatischen Updates sowie dazu, wie ein Integrator Anhang I und VII erfüllen kann; und, falls die SBOM den Nutzern bereitgestellt wird, wo sie abrufbar ist.

Aufbewahrung: zehn Jahre nach dem Inverkehrbringen oder für die Dauer des Supportzeitraums, je nachdem, was länger ist. Benutzerinformationen sind entsprechend lange verfügbar zu halten.

Quellen: Art. 13 Abs. 13, Art. 28–30, Anhang V · Anhang VII

Sie müssen bei integrierten Drittkomponenten die gebotene Sorgfalt walten lassen, im Umfang abgestuft nach dem Risiko der Komponente. Erwägungsgrund 34 nennt als Maßnahmen: prüfen, ob der Komponentenhersteller Konformität nachgewiesen hat, etwa über CE-Kennzeichnung; prüfen, ob die Komponente regelmäßig Sicherheitsupdates erhält; Abgleich gegen die europäische Schwachstellendatenbank und andere öffentliche Quellen; zusätzliche Sicherheitsprüfungen.

Oft übersehen — Art. 13 Abs. 6: Finden Sie eine Schwachstelle in einer integrierten Komponente, auch einer Open-Source-Komponente, müssen Sie deren Ersteller oder Maintainer informieren, die Schwachstelle beheben und gegebenenfalls den eingesetzten Patch bereitstellen. Legen Sie fest, wer das tut.

Ihre Pflichten zum Umgang mit Schwachstellen gelten für das Produkt in seiner Gesamtheit, einschließlich aller integrierten Komponenten.

Quellen: Art. 13 Abs. 5 und 6, Erwägungsgründe 34 und 35 CRA

Zwei Auslöser, die regelmäßig verwechselt werden:

1. Aktiv ausgenutzte Schwachstelle in einem Ihrer in Verkehr gebrachten Produkte. Nach Erwägungsgrund 68: Sie stellen fest, dass eine Sicherheitsverletzung bei Nutzern oder Dritten darauf zurückgeht, dass ein böswilliger Akteur einen Fehler in Ihrem Produkt nutzt.

2. Schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit. Das ist ein Vorfall bei Ihnen: Entwicklungs-, Herstellungs- oder Wartungsprozesse sind so beeinträchtigt, dass das Risiko für Nutzer steigt. Lehrbuchfall der Verordnung: ein Angreifer schleust Schadcode in den Freigabekanal ein, über den Sie Sicherheitsupdates ausliefern.

Nicht nach Art. 14 zu melden: eine CVE ohne belegte Ausnutzung — und Schwachstellen, die ohne böswillige Absicht bei gutgläubigen Tests, Untersuchungen, Korrekturen oder Offenlegungen gefunden werden. Eine freiwillige Meldung nach Art. 15 bleibt möglich.

Ein Vorfall ist nach Art. 14 Abs. 5 schwerwiegend, wenn er

• sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, oder
• zur Einführung oder Ausführung böswilligen Codes im Produkt oder im Netz- und Informationssystem eines Nutzers geführt hat oder führen kann.

Praktisch heißt „Vorfall bei Ihnen“: Build-System, Signaturschlüssel, CI-Runner, Update-Server, Paket-Registry. Nicht jede Kompromittierung erfüllt die Schwelle — eines der beiden Kriterien muss zutreffen. Nehmen Sie diese Systeme trotzdem ins Monitoring: hier fallen Prävention und Meldepflicht zusammen.

Quellen: Art. 14, Erwägungsgründe 65–68 CRA · Kommission: Reporting obligations

• 24 Stunden — Frühwarnung nach Kenntniserlangung. Sie muss die Mitgliedstaaten angeben, in deren Hoheitsgebiet das Produkt nach Kenntnis des Herstellers bereitgestellt wurde; bei einem Vorfall zusätzlich, ob der Verdacht auf rechtswidrige oder böswillige Handlungen besteht.
• 72 Stunden — vollständige Meldung mit Beschreibung und ergriffenen Maßnahmen
• 14 Tage — Abschlussbericht bei Schwachstellen, gerechnet ab Verfügbarkeit einer Korrekturmaßnahme
• 1 Monat — Abschlussbericht bei Sicherheitsvorfällen, gerechnet ab Übermittlung der 72-Stunden-Meldung, nicht ab der Frühwarnung (Art. 14 Abs. 4 Buchst. c)

Die Uhr startet mit der Kenntnis der aktiven Ausnutzung. Art. 3 Nr. 42 definiert diese als Schwachstelle, zu der verlässliche Nachweise dafür vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat. Eine abgeschlossene Forensik ist nicht Voraussetzung — ein unbelegter Verdacht, ein hoher CVSS-Wert oder ein veröffentlichter Proof of Concept erfüllen die Definition aber nicht.

Zusätzlich kann das erstempfangende Koordinator-CSIRT einen Zwischenbericht über relevante Statusaktualisierungen anfordern (Art. 14 Abs. 6). Rechnen Sie das in Ihren Prozess ein — zwischen 72-Stunden-Meldung und Abschlussbericht kann Nachfrage kommen.

Nichts hält die Fristen an. In der 72-Stunden-Meldung kann angegeben werden, als wie sensibel der Hersteller die Informationen ansieht (Art. 14 Abs. 2 Buchst. b und Abs. 4 Buchst. b); die verzögerte Verbreitung solcher Meldungen richtet sich nach Art. 16 Abs. 2. Die Einreichungsfrist berührt das nicht. Und die 24-Stunden-Uhr läuft auch am Samstag um 22:00.

Quellen: Art. 14, Art. 16 Abs. 2 CRA · WKO: Fristen

Gemeldet wird einmal, über die von der ENISA eingerichtete und betriebene einheitliche Meldeplattform (Art. 16 Abs. 1). Deren Architektur muss es Mitgliedstaaten und ENISA ermöglichen, eigene Endpunkte für die elektronische Meldung einzurichten — es gibt also nicht ein Formular, sondern den Endpunkt Ihres Koordinator-CSIRT innerhalb der Plattform. Von dort geht die Meldung gleichzeitig an dieses CSIRT und an die ENISA. Das empfangende CSIRT informiert seine Marktüberwachungsbehörde und teilt die Meldung mit CSIRTs weiterer betroffener Mitgliedstaaten.

Stand der Dinge:

• Betriebsbeginn ist für den 11.9.2026 angesetzt — denselben Tag, an dem die Pflicht beginnt. Funktions- und Sicherheitstests laufen.
• ENISA veröffentlicht laufend aktualisierte Registrierungs- und Meldeanleitungen samt Bildschirmabfolge; die Dokumente tragen ein eigenes Änderungsdatum. Prüfen Sie vor einer Meldung die jeweils aktuelle Fassung. Die öffentliche URL der Plattform war zum Prüfstand nicht veröffentlicht.
• Registrierung über ein EU-Login-Konto.
• Keine Melde-API in dieser Phase: Interne Abläufe lassen sich bis zur Einreichung automatisieren, den letzten Schritt macht ein Mensch im Browser.
• Freiwillige Meldungen nach Art. 15 sind erst nach dem 11.9.2026 möglich.
• Support: cra-srp-helpdesk@enisa.europa.eu

Warten ist keine Option. Die Frist ist fix, unabhängig davon, wann das Portal erscheint. Was jetzt zählt, ist der interne Erkennungs- und Triage-Prozess — der funktioniert ohne Plattform.

Quellen: Art. 15, Art. 16 CRA · ENISA: Single Reporting Platform · ENISA: SRP-FAQ · Kommission: Reporting obligations

Das für CRA-Meldungen zuständige österreichische Koordinator-CSIRT ist noch offiziell zu bestätigen. CERT.at ist das nationale Computer-Notfallteam Österreichs. Die ENISA-Liste der gemäß CRA als Koordinatoren benannten CSIRTs war zum Prüfstand 1.9.2026 nicht veröffentlicht; ENISA kündigt sie für einen späteren Zeitpunkt an.

Maßgeblich ist daher die nach Art. 14 Abs. 7 ermittelte Stelle beziehungsweise die in der Meldeplattform angezeigte Koordinatorstelle. Halten Sie diesen Punkt in Ihrer Prozessbeschreibung als „zu bestätigen“ markiert.

Wo die Hauptniederlassung liegt, definiert Art. 14 Abs. 7 eigenständig: im Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Lässt sich das nicht bestimmen, gilt der Mitgliedstaat mit der höchsten Beschäftigtenzahl. Für Konzerntöchter ist das relevant: Der Sitz im Firmenbuch entscheidet nicht.

Ohne Hauptniederlassung in der Union gilt eine feste Reihenfolge: (1) Mitgliedstaat des Bevollmächtigten, der für die meisten Produkte des Herstellers handelt, (2) des Einführers, der die meisten Produkte in Verkehr bringt, (3) des Händlers, der die meisten Produkte auf dem Markt bereitstellt, (4) mit den meisten Nutzern. Im letzten Fall darf für spätere Meldungen dasselbe CSIRT gewählt werden.

Quellen: Art. 14 Abs. 7 CRA · CERT.at · WKO: Weiterleitung an das österreichische CSIRT

Ja. Art. 69 Abs. 3 erstreckt die Meldepflichten ab 11.9.2026 auf Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden. Die Verordnung unterscheidet zwischen Inverkehrbringen — der erstmaligen Bereitstellung — und der laufenden Bereitstellung auf dem Markt; Art. 69 knüpft an das Inverkehrbringen an. Ihr Meldeprozess muss also nicht nur künftige Produkteinführungen abdecken, sondern das Bestandsportfolio.

Die vollen Anhang-I- und Konformitätspflichten treffen Altprodukte dagegen nur, wenn nach dem 11.12.2027 eine erhebliche Veränderung erfolgt (Art. 69 Abs. 2).

Oft übersehen: Das Inverkehrbringen ist die erstmalige Bereitstellung auf dem Unionsmarkt und bezieht sich auf das einzelne Produkt, nicht auf die Produktreihe oder Serie. Eine Produktlinie, die vor dem Stichtag startete, ist deshalb nicht insgesamt Altbestand — jedes ab dem 11.12.2027 erstmals bereitgestellte Exemplar oder Release ist eigenständig zu betrachten.

Praktisch, wo keine SBOM existiert: letzte ausgelieferte Version identifizieren, SBOM aus dem Build-Tag rekonstruieren oder per Binäranalyse erzeugen, nach Installationsbasis und Netzexposition priorisieren — und für den Rest dokumentiert entscheiden, was überwacht wird.

Quellen: Art. 69 Abs. 2 und 3 CRA

Parallel zur Behördenmeldung sind die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall zu informieren und, soweit erforderlich, über Risikominderungs- und Korrekturmaßnahmen, die sie selbst ergreifen können — gegebenenfalls in einem strukturierten, maschinenlesbaren Format, das leicht automatisch zu verarbeiten ist (Art. 14 Abs. 8).

Ersatzvornahme: Versäumt der Hersteller die rechtzeitige Information, dürfen die Koordinator-CSIRTs die Nutzer selbst informieren, wenn sie das für verhältnismäßig und erforderlich halten. Die Nachricht geht dann ohne Ihre Beteiligung an Ihre Kunden.

Legen Sie den Kanal jetzt fest: Advisory-Seite unter fixer URL, Release Notes, Direktmail an Wartungskunden. Eine Advisory-Seite, die im Ernstfall erst angelegt wird, wird nicht rechtzeitig angelegt.

Quellen: Art. 14 Abs. 8, Erwägungsgrund 67 CRA

Bestätigt: Die notifizierende Behörde ist im Bundeskanzleramt angesiedelt und wird über die nationale Behörde für die Cybersicherheitszertifizierung wahrgenommen.

Noch offen: Die Marktüberwachungsbehörde ist offiziell nicht benannt. Das Bundeskanzleramt hält fest, dass weitere Zuständigkeiten im Rahmen der Durchführung festgelegt werden. In nicht-amtlichen Quellen kursierende Kandidaten — RTR, Fernmeldebehörden, BMK — sind nicht bestätigt und teils widersprüchlich. Eine verbreitete Behauptung, die RTR sei notifizierende Behörde, widerspricht der amtlichen Darstellung.

Zum Vergleich: Deutschland hat ein CRA-Durchführungsgesetz mit dem BSI als zentraler Markt­überwachungs- und notifizierender Behörde im Verfahren. In Österreich gibt es dazu Stand August 2026 keinen veröffentlichten Begutachtungsentwurf — weder im RIS noch auf parlament.gv.at.

Quellen: BKA: Cyberresilienz-Verordnung · BKA: Fragen und Antworten

Verstoß	Obergrenze
Grundlegende Anforderungen (Anhang I) bzw. Pflichten aus Art. 13 und 14	15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres
Andere Pflichten der Verordnung	10 Mio. € oder 2 %
Falsche, unvollständige oder irreführende Angaben gegenüber Behörden	5 Mio. € oder 1 %

Es gilt jeweils der höhere Betrag. Keine größenabhängige Ausnahme — die Bandbreite trifft auch KMU und Einzelunternehmen. Ausgenommen von Geldbußen sind Verwalter quelloffener Software (Art. 64 Abs. 10); Kleinst- und Kleinunternehmen werden für ein Versäumen der 24-Stunden-Frühwarnung nicht mit Geldbußen belegt.

Vollzug in Österreich: Der nationale Sanktionsvollzug — voraussichtlich als Verwaltungsstrafverfahren durch die noch zu benennende Behörde — ist gesetzlich noch nicht geregelt. Das ist der erwartete, nicht der festgelegte Weg.

Quellen: Art. 64 CRA · WKO: Sanktionen

Zwei verschiedene Regelungsebenen: NIS2 regelt Organisationen, der CRA regelt Produkte. Ein Softwarehersteller kann beidem unterliegen — als Einrichtung dem NISG, als Hersteller dem CRA.

Das österreichische NISG 2026 (BGBl. I Nr. 94/2025) tritt am 1.10.2026 in Kraft und gilt für rund 4.000 Unternehmen und Einrichtungen ab mittlerer Größe aus 18 Sektoren. Zuständig ist das Innenministerium mit dem neuen Bundesamt für Cybersicherheit. Gemeldet wird an das nach NISG jeweils zuständige CSIRT, das die Meldung an die Cybersicherheitsbehörde weiterleitet; je nach Sektor können das nationale CSIRT, GovCERT als Notfallteam der öffentlichen Verwaltung oder ein sektorspezifisches CSIRT einschlägig sein. Die Zahl von rund 4.000 betroffenen Einrichtungen ist eine Schätzung; der Scope ist grundsätzlich größenbasiert, kennt aber gesetzliche Ausnahmen.

Bauen Sie einen Erkennungs- und Triage-Prozess mit Verzweigung am Ende — nicht drei parallele Prozesse für CRA, NISG und DSGVO Art. 33. Sonst wird im Ernstfall der falsche befolgt.

Quellen: WKO: NISG 2026 und NIS-2 · WKO: Cybersicherheit in der Lieferkette

• WKO: CRA-Übersicht, FAQ, Webinare; Weiterbildung über incite, inklusive Zertifizierung „Certified NIS Expert“.
• SECURE (Digital Europe Programme, Grant Agreement 101190325, koordiniert von der italienischen ACN, mit österreichischer EDIH-Beteiligung): Gesamtbudget knapp 22 Mio. €, davon 16,5 Mio. € direkte KMU-Förderung. Der erste Open Call ist abgeschlossen — Einreichung 28.1. bis 29.3.2026, 5 Mio. €, maximal 30.000 € pro Projekt bei 50 % Kofinanzierung. Für neue Fördermöglichkeiten ist der jeweils aktuelle SECURE- beziehungsweise Digital-Europe-Aufruf zu prüfen. Die Schulungen und das Ressourcen-Repository bleiben frei zugänglich.
• FFG: Forschungsprojekt CRA-PRO zur Klärung der offenen nationalen Prozesse und Zuständigkeiten, dazu die allgemeinen FFG-Programme.
• NCC-AT, KMU.DIGITAL, Digital Innovation Hubs, Austrian Standards für Normen und Schulungen.
• ENISA: SME Cyber Resilience Maturity Assessment Model (Juli 2026) als Selbsteinschätzung.
• Reallabore für Cyberresilienz (Art. 33 Abs. 2): Mitgliedstaaten können kontrollierte Prüfumgebungen einrichten, die Entwicklung, Entwurf, Validierung und Erprobung innovativer Produkte vor dem Inverkehrbringen erleichtern — unter direkter Aufsicht, Leitung und Unterstützung der Marktüberwachungsbehörden, mit möglicher technischer Unterstützung durch Kommission und ENISA. Die Mitgliedstaaten müssen dabei einen offenen, fairen und transparenten Zugang sicherstellen und insbesondere Kleinst- und Kleinunternehmen einschließlich Start-ups den Zugang erleichtern. Ob Österreich davon Gebrauch macht, ist offen; für forschungsnahe Produktentwicklung wäre es der naheliegende Ansatzpunkt.

Quellen: NCC-AT: Förderungen für Cybersicherheit · WKO: Aus- und Weiterbildung

Praxis Ein empfohlener Projektplan — der CRA schreibt keine Reihenfolge vor.

1. Produkt- und Komponenteninventar — inklusive Altprodukte. Ergiebigste Quelle ist der Rechnungsverlauf der letzten fünf bis sieben Jahre: Produkte, die niemand mehr pflegt, verschwinden im Git, stehen aber in der Buchhaltung.
2. Rollen und Klassen bestimmen, je Produkt, mit namentlich verantwortlicher Person.
3. Meldebereitschaft bis 11.9.2026: Triage-Kriterien, benannte Meldeverantwortliche mit Stellvertretung, drei vorbereitete Meldetexte, EU-Login-Konten, Trockenübung.
4. Politik zur koordinierten Offenlegung veröffentlichen, samt security.txt nach RFC 9116 und überwachtem Postfach.
5. SBOM-Erzeugung automatisieren und kontinuierliches Schwachstellenmonitoring aufsetzen.
6. Sicheren Entwicklungslebenszyklus etablieren — IEC 62443-4-1 als Blaupause.
7. Technische Dokumentation, Risikobewertung, Benutzerinformationen aufbauen; Supportzeitraum festlegen und kommunizieren.
8. Bei Klasse II und kritisch: notifizierte Stelle früh kontaktieren — Kapazitätsengpässe vor Dezember 2027 sind ein plausibles Planungsrisiko.

Realistisch in kurzer Zeit machbar sind die Schritte 1 bis 3. SBOM-Automatisierung und vollständige Dokumentation sind Aufgaben bis 2027, nicht bis September 2026.

Pflicht ist das Verfahren zur koordinierten Offenlegung und eine leicht zugängliche Kontaktstelle. Praxis Die folgende Ausgestaltung — inklusive security.txt nach RFC 9116 — ist Empfehlung, nicht Wortlaut des CRA:

• Geltungsbereich: welche Produkte und Versionen
• Meldeweg: E-Mail, optional PGP-Schlüssel, Formular
• Reaktionszusagen: Empfangsbestätigung und Erstbewertung mit konkreten Fristen
• Safe-Harbour-Erklärung für gutgläubige Forschung innerhalb definierter Grenzen
• Offenlegungsfenster, Umgang mit Nennung von Findern, klare Aussage falls kein Bug-Bounty
• Ausschlüsse, etwa Social Engineering gegen Mitarbeiter oder DoS-Tests gegen Produktivsysteme

Intern: Intake, Triage, Service-Level nach Schweregrad, Fix, Advisory, CVE-Vergabe. Für Advisories empfiehlt sich CSAF 2.0 mit VEX-Aussagen — das dokumentiert Nicht-Ausnutzbarkeit, senkt das Meldungsrauschen und erspart Diskussionen mit Kunden, die Ihre SBOM durch eigene Scanner schicken.

Die zentrale Anlaufstelle muss von den Nutzern leicht ermittelt werden können, ist in die Benutzerinformationen nach Anhang II aufzunehmen und muss den Nutzern die Wahl des Kommunikationsmittels lassen — beschränkt auf automatisierte Instrumente darf sie nicht sein (Art. 13, Erwägungsgrund 63).

Quellen: Anhang I Teil II Nr. 5 und 6, Art. 13 (zentrale Anlaufstelle), Erwägungsgründe 63 und 75 CRA

Als Vorarbeit und Nachweisgrundlage: erheblich. Als Konformitätsnachweis: nein.

• IEC 62443-4-1 (Secure Development Lifecycle) deckt große Teile von Anhang I Teil II und Secure-by-Design ab; IEC 62443-4-2 adressiert technische Produktanforderungen aus Anhang I Teil I.
• Zentrale Lücke: Eine bestehende IEC-62443-4-1-Zertifizierung weist die CRA-Pflichten zur SBOM und zur Dokumentation von Schwachstellen in Drittkomponenten nicht automatisch vollständig nach. Ergänzen müssen Sie typischerweise die Post-Market-Prozesse: koordinierte Offenlegung, Art.-14-Meldung, Supportzeitraum, EU-Konformitätserklärung. Führen Sie den Abgleich anforderungsweise gegen Anhang I, nicht zertifikatsweise.
• ISO/IEC 27001 liefert das Managementsystem-Fundament, aber keine produktspezifischen Anhang-I-Anforderungen.
• ISO/IEC 42001 ist ergänzend relevant, wenn KI-Komponenten im Produkt stecken.

Sinnvolles Vorgehen: Gap-Analyse der vorhandenen 62443-Artefakte gegen die einzelnen Anhang-I-Punkte, dann gezielt die Lücken schließen. Solange keine harmonisierte Norm zitiert ist, verschafft ohnehin kein Standard eine Konformitätsvermutung.

Quellen: Art. 27 CRA · ENISA/JRC-Mapping grundlegender Anforderungen auf Normen

Rechtlich gilt für KI-generierten Code dasselbe wie für jeden anderen: die Anhang-I-Anforderungen, ohne Abstriche.

Zwei praktische Besonderheiten:

• Eine SBOM erfasst Paketabhängigkeiten, nicht eingefügte Codefragmente. Ergänzen Sie statische Analyse, Secret-Scanning und eine Provenance-Regel für generierten Code.
• Assistenten können veraltete oder unsichere Abhängigkeiten vorschlagen — was direkt in Anhang I Teil I Buchstabe a läuft: Bereitstellung ohne bekannte ausnutzbare Schwachstellen.

Für Hochrisiko-KI-Systeme, die zugleich Produkte mit digitalen Elementen sind, gilt: Erfüllen sie die grundlegenden CRA-Cybersicherheitsanforderungen, gelten insoweit auch die Anforderungen aus Art. 15 der KI-Verordnung als erfüllt, soweit die EU-Konformitätserklärung sie abdeckt.

Für das Verfahren gilt grundsätzlich Art. 43 der KI-Verordnung. Abweichend davon unterliegen Hochrisiko-KI-Systeme, die zugleich wichtige oder kritische Produkte im Sinne des CRA sind und für die nach der KI-Verordnung die interne Kontrolle nach deren Anhang VI gelten würde, hinsichtlich der Cybersicherheitsanforderungen den CRA-Konformitätsbewertungsverfahren — die Drittbewertung lässt sich also nicht über die KI-Verordnung umgehen (Erwägungsgrund 51).

Bei der Risikobewertung sind zusätzlich KI-spezifische Schwachstellen zu berücksichtigen, namentlich Data Poisoning und adversarial attacks, sowie gegebenenfalls Risiken für die Grundrechte.

Doppelarbeit ist vermeidbar: Nach Art. 13 Abs. 4 kann bei Produkten nach Art. 12, die auch anderen Unionsrechtsvorschriften unterliegen, die Cybersicherheits-Risikobewertung Teil der in diesen Rechtsvorschriften geforderten Risikobewertungen sein. Sie brauchen also kein zweites, separates Dokument — aber die cyberbezogenen Inhalte müssen darin vollständig enthalten sein.

Quellen: Anhang I Teil I Buchstabe a, Erwägungsgrund 51 CRA

• Individualsoftware und Auftragsentwicklung: im Anwendungsbereich, wenn im Rahmen einer Geschäftstätigkeit in Verkehr gebracht. Für maßgeschneiderte Produkte für einen bestimmten gewerblichen Nutzer sind Abweichungen von grundlegenden Anforderungen möglich, wenn beide Seiten ausdrücklich anderen Vertragsbedingungen zugestimmt haben.
• Interne Software, die nicht auf dem Markt bereitgestellt wird — internes CRM, HR-Tool, eigene CI-Pipeline: nicht erfasst.
• Apps: erfasst. Eine installierbare App ist ein eigenständiges Softwareprodukt und damit ein Produkt mit digitalen Elementen — die Kommissionsleitlinien führen mobile Apps ausdrücklich als Beispiel. Ein Cloud-Backend macht daran nichts anders; es kommt als Datenfernverarbeitungslösung gegebenenfalls noch hinzu. Nicht erfasst sind reine Browser-Webanwendungen und informative Websites.
• B2B und B2C: beide erfasst; Erleichterungen betreffen nur maßgeschneiderte B2B-Produkte.
• Alpha-, Beta- und Vorabversionen dürfen zum Testen und Sammeln von Rückmeldungen bereitgestellt werden, solange dies erforderlich ist — nur für einen begrenzten Zeitraum, der für Testzwecke erforderlich ist — und mit einer sichtbaren Kennzeichnung, die deutlich darauf hinweist, dass die Software der Verordnung nicht entspricht und außer zu Testzwecken nicht auf dem Markt verfügbar sein wird (Art. 4 Abs. 3). Die Freigabe erfolgt erst nach einer Risikobewertung; die Anforderungen sind so weit wie möglich zu erfüllen, und Nutzer dürfen nicht zum Wechsel auf Testversionen gezwungen werden (Erwägungsgrund 37).
• Messen, Ausstellungen und Vorführungen: Auch nicht konforme Produkte und Prototypen dürfen dort präsentiert oder verwendet werden — sofern eine sichtbare Kennzeichnung deutlich macht, dass das Produkt der Verordnung nicht entspricht und erst bereitgestellt werden darf, wenn es das tut (Art. 4 Abs. 2).

Quellen: Art. 2, Erwägungsgründe 15, 16, 37, 64 CRA · Anhang I Teil I Nr. 2

• Verordnung (EU) 2024/2847 — konsolidierte Fassung, deutschsprachig (EUR-Lex) Enthält Berichtigungen und Änderungen. Für Zitate diese Fassung verwenden.
• Verordnung (EU) 2024/2847 — Volltext der Erstveröffentlichung, deutschsprachig (EUR-Lex) Cyber Resilience Act. Maßgebliche Fassung für alle Aussagen dieser Seite.
• Anhang I — Grundlegende Cybersicherheitsanforderungen Teil I: 13 Produkteigenschaften plus Risikosatz. Teil II: 8 Anforderungen an die Schwachstellenbehandlung.
• Anhang III — Wichtige Produkte, Klasse I und II
• Anhang IV — Kritische Produkte
• Anhang V — Inhalt der EU-Konformitätserklärung
• Anhang VII — Inhalt der technischen Dokumentation
• Anhang VIII — Konformitätsbewertungsverfahren, Module A, B, C, H

• Durchführungsverordnung (EU) 2025/2392 vom 28.11.2025, deutschsprachige Fassung (PDF) Verbindliche technische Beschreibung der wichtigen und kritischen Produktkategorien. Anhang I: wichtige Produkte. Anhang II: kritische Produkte.
• Delegierte Verordnung (EU) 2026/881 vom 11.12.2025, veröffentlicht am 20.4.2026 Aufschub der Verbreitung von Meldungen, ergangen zu Art. 16 Abs. 2. Kommissionsdokument C(2025) 8407 final.
• Delegierte Verordnung (EU) 2025/1535 Schließt bestimmte Produkte mit digitalen Elementen, die unter die VO (EU) Nr. 168/2013 fallen, vom CRA aus.
• Delegierte Verordnung (EU) 2026/339 Hebt die cyber-relevanten Anforderungen der Funkanlagenrichtlinie (Delegierte VO (EU) 2022/30) mit Wirkung 11.12.2027 auf.
• Durchführungsbeschluss C(2025) 618 final vom 3.2.2025 Normungsauftrag M/606 an CEN, CENELEC und ETSI, angenommen am 3.4.2025.

Die Rechtsprüfung der zentralen Bestimmungen erfolgt gegen EUR-Lex. Die strukturierte deutschsprachige Wiedergabe von reuschlaw wird ausschließlich als Lese- und Navigationshilfe verwendet — sie ist keine amtliche Fassung.

Warum das hier ausdrücklich steht: Bei der Reihenfolge des Art. 14 Abs. 7 — welches CSIRT zuständig ist, wenn der Hersteller keine Hauptniederlassung in der Union hat — weicht die reuschlaw-Wiedergabe von der amtlichen Fassung ab: Sie nennt den Händler vor dem Einführer, EUR-Lex nennt den Einführer vor dem Händler. Wir haben diesen Punkt gegen die konsolidierte EUR-Lex-Fassung nachgeprüft und korrigiert. Für jedes Zitat, auf das Sie eine Rechtsfolge stützen, ist die EUR-Lex-Fassung heranzuziehen.

Zur Sprachfassung: Alle vierundzwanzig Sprachfassungen einer EU-Verordnung sind gleichermaßen verbindlich; die deutschsprachige ist keine Übersetzung eines Originals. Bei Auslegungszweifeln lohnt daher der Blick in die englische oder französische Fassung — abweichende Formulierungen sind ein Hinweis darauf, dass der Begriff auslegungsbedürftig ist.

• Anhang I — Wortlaut Teil I und Teil II
• Anhang II — Informationen und Anleitungen für den Nutzer
• Anhang III — Wortlaut Klasse I und Klasse II
• Anhang IV — Kritische Produkte
• Anhang VII — Inhalt der technischen Dokumentation
• Artikel 21 — Herstellerpflichten für Einführer und Händler
• Artikel 22 — Sonstige Fälle der Herstellerpflichten
• Erwägungsgründe im Wortlaut
• Artikel 13 — Pflichten der Hersteller
• Artikel 14 — Meldepflichten der Hersteller
• Artikel 24 — Pflichten der Verwalter quelloffener Software
• Artikel 32 — Konformitätsbewertungsverfahren
• Artikel 69 — Übergangsbestimmungen

Hinweis zur Absatznummerierung: Strukturierte Wiedergaben fassen Unterabsätze teils als Unterpunkte zusammen. Für Zitate mit Absatzangabe in Verträgen oder Schriftsätzen ist die EUR-Lex-Fassung zu verwenden.

• CRA Implementation — Umsetzungsstand Sammelseite zu Leitlinien, Rechtsakten und Normung. Erster Anlaufpunkt für Aktualisierungen.
• EUR-Lex — amtliche Zusammenfassung mit Liste der Folgerechtsakte Nennt die delegierten und Durchführungsverordnungen zum CRA an einer Stelle.
• Zusammenfassung des Legislativtexts Auch auf Deutsch verfügbar.
• Reporting obligations Meldepflichten und Meldeplattform.
• Conformity assessment Quelle der Schätzung, dass rund 90 Prozent der erfassten Produkte per Selbstbewertung nachweisen können.
• Leitlinien C(2026) 5252 vom 27.7.2026 Finale Fassung mit 67 Beispielen, Fokus Kleinst- und Kleinunternehmen. Nicht bindend, Auftrag aus Art. 26 Abs. 1. Erreichbar über die Implementation-Seite.
• NANDO — Verzeichnis notifizierter Stellen Nach CRA und Notifizierungsumfang filtern.

• Single Reporting Platform (SRP) Registrierungs- und Meldeanleitungen mit eigenem Änderungsdatum. Vor jeder Meldung die aktuelle Fassung prüfen.
• SRP — Häufige Fragen Enthält den Hinweis, Registrierung und CSIRT-Validierung erst bei konkretem Meldebedarf anzustoßen.
• cra-srp-helpdesk@enisa.europa.eu Support zur Meldeplattform.

• Bundeskanzleramt — Cyberresilienz-Verordnung Amtliche Quelle für die notifizierende Behörde und den Stand der weiteren Zuständigkeiten.
• Bundeskanzleramt — Fragen und Antworten zum CRA
• WKO — Cyber Resilience Act Österreichischer Einstieg mit Zeitplan, Ausnahmen, Sanktionen und Weiterbildungsangeboten.
• WKO — NISG 2026 und NIS-2 Abgrenzung zum organisationsbezogenen Regime, Inkrafttreten 1.10.2026.
• WKO — Cybersicherheit in der Lieferkette
• CERT.at Nationales Computer-Notfallteam. Benennung als CRA-Koordinator-CSIRT noch zu bestätigen.
• NCC-AT — Förderungen für Cybersicherheit
• NISG 2026, BGBl. I Nr. 94/2025 Im Rechtsinformationssystem des Bundes (RIS) abrufbar.

Deutsche Quellen sind für österreichische Unternehmen nicht verbindlich, aber fachlich brauchbar, weil die Verordnung unmittelbar in beiden Staaten gilt.

• BSI — Flyer: Produktklassen und Konformität (PDF)
• CRA-Durchführungsgesetz (Entwurf, Deutschland) Weist das BSI als zentrale Marktüberwachungs- und notifizierende Behörde aus. In Österreich existiert kein veröffentlichtes Gegenstück.

• Normungsauftrag M/606 CEN, CENELEC und ETSI, rund 41 Normen. Arbeitsprogramm und Einzelstände über die Normungsorganisationen.
• EN-40000-Serie (CEN-CLC/JTC 13) Horizontale Normen: Principles, Vulnerability Handling, Generic Security Requirements.
• EN 50770 (CLC/TC 65X) IEC-62443-basierte Profile für OT-Umgebungen.
• Austrian Standards Nationaler Zugang zu Normen und Spiegelgremien.

Entscheidend bleibt die Zitierung im Amtsblatt. Erst dann entsteht eine Konformitätsvermutung nach Art. 27. Zum Prüfstand dieser Seite war keine CRA-harmonisierte Norm zitiert.

Bestimmung	Prüftiefe
Anhang I Teil I und Teil II	Wortlaut geprüft
Anhang III (Klasse I und II)	Wortlaut geprüft
Anhang VIII (Struktur, Modul B)	Wortlaut geprüft
Artikel 13, 14, 24, 32, 69	Wortlaut geprüft
Artikel 3 Nr. 42 (aktiv ausgenutzte Schwachstelle)	Wortlaut geprüft
Anhang V, Artikel 64, Stand der Meldeplattform	Gegen amtliche und Fachquellen geprüft
Anhänge II, IV und VII	Wortlaut geprüft
Artikel 21 und 22	Wortlaut geprüft
Erwägungsgründe 1–65	Wortlaut geprüft
Art. 2, Art. 7, Art. 8 Abs. 1, Art. 13, Art. 14 Abs. 7, Art. 30, Art. 33, Art. 44, Art. 47	Gegen EUR-Lex nachgeprüft
Art. 19 Abs. 1, Art. 20 Abs. 1 und 2	Gegen EUR-Lex nachgeprüft
Art. 20 Abs. 6 (Händlerpflicht bei Betriebseinstellung)	Auf zwei übereinstimmende strukturierte Wiedergaben gestützt; nicht gegen EUR-Lex geprüft
Art. 4, Art. 16, Art. 27 Abs. 8, Art. 28, Art. 31	Gegen EUR-Lex nachgeprüft
Artikel 14 Abs. 7 (Reihenfolge des Koordinator-CSIRT)	Gegen die konsolidierte EUR-Lex-Fassung nachgeprüft und korrigiert

Für Zitate in Verträgen, Angeboten oder Schriftsätzen immer die EUR-Lex-Fassung heranziehen und die Absatznummer dort verifizieren — nicht diese Seite zitieren.