CRA 1/5: Die erste CRA-Pflicht greift nicht 2027 — sondern am 11. September 2026

Der Blick auf die Meldepflichten des CRA empfiehlt sich, weil sie den frühesten und unmittelbarsten Handlungsdruck erzeugen. Vor den Details, die Artikel 14 im CRA darlegt, steht jedoch erst einmal die Einordnung: Wer ist betroffen, was fällt unter den CRA, und was greift wann?

Bitte einmal verständlich: Wer ist betroffen und was fällt unter den CRA?

Der CRA knüpft an einem einzigen, bewusst weit gefassten Begriff an: dem Produkt mit digitalen Elementen (im Englischen „Products with Digital Elements“, abgekürzt: PwDE).

Ein PwDE ist jedes Software- oder Hardwareprodukt, dessen bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz einschließt (siehe: Art. 2 Abs. 1).

Erfasst sind physische Verbindungen über Schnittstellen, Kabel oder Funkwellen ebenso wie logische Verbindungen über Softwareschnittstellen.

Die hier gewählte Reichweite ist Absicht: Smartphones, Laptops, Router, Firewalls, industrielle Steuerungssysteme, Smart-Home-Geräte, IoT-Sensoren, Betriebssysteme, Passwortmanager, Antivirensoftware — all das sind PwDE im Sinne des CRA. Die kurz gefasste Faustregel dahinter: Sobald ein Produkt Daten verarbeitet und sich — direkt oder indirekt — mit einem Gerät oder Netz verbinden kann, ist es im Zweifel ein PwDE.

Aber auch kostenlos bereitgestellte Software mit kommerziellem Hintergrund fällt darunter, etwa eine Gratis-App für einen kostenpflichtigen Cloud-Dienst (s. Art. 3 Nr. 22). Der Nulltarif für den Nutzer ist kein Ausschlusskriterium; entscheidend ist stets der kommerzielle Kontext.

Zum PwDE-Begriff zählen auch Remote Data Processing Solutions (RDPS). Damit ist Software gemeint, die der Hersteller selbst entwickelt und remote betreibt und ohne die das Produkt eine seiner Kernfunktionen nicht erfüllen könnte. Eine mobile App, die zwingend ein herstellereigenes Cloud-Backend braucht, um ihre Kernfunktion zu erfüllen, ist damit als PwDE einzustufen, inklusive des Backend-Dienstes als RDPS.

Die Grenze verläuft hier sauber und ist praktisch relevant: Ein reiner SaaS-Dienst ohne lokalen Client fällt nicht in den CRA-Scope, sondern gegebenenfalls unter NIS2. Wer diese Trennung nicht früh zieht, ordnet Produkte dem falschen Regime (und der falschen Meldekette, dazu später mehr) zu.

CRA-Ausnahmen: Was klammert der CRA explizit aus?

Der CRA nimmt Produktkategorien aus, die bereits durch sektorspezifische EU-Regulierung abgedeckt sind. Dazu gehören derzeit:

• Medizinprodukte nach Verordnung (EU) 2017/745 und In-vitro-Diagnostika nach (EU) 2017/746
• Kraftfahrzeuge und ihre Systeme nach Verordnung (EU) 2019/2144 (Kenner wissen Bescheid, dass hier die UN R155 und die ISO/SAE 21434 zum Tragen kommen)
• Luftfahrtprodukte, die nach Verordnung (EU) 2018/1139 zertifiziert sind
• Schiffsausrüstung nach Richtlinie 2014/90/EU
• Ersatzteile, die identische Komponenten ersetzen
• Produkte für nationale Sicherheit oder Verteidigung sowie Produkte zur Verarbeitung von Verschlusssachen
• Freie und quelloffene Software (Free and Open Source Software, FOSS), die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird — also rein nicht-kommerzielle Open-Source-Projekte ohne Monetarisierungsabsicht

Das klingt erstmal klar formuliert, bringt für die Praxis aber Grauzonen.

Besonders bei FOSS ist die Abgrenzung nicht trivial: Eine Open-Source-Bibliothek, die in ein kommerzielles Produkt integriert wird, fällt nicht selbst unter den CRA. Die Sorgfaltspflicht für die integrierten Komponenten trägt jedoch der Hersteller des Endprodukts. (Mehr dazu in Artikel 4 dieser Serie.)

Wirtschaftsakteure aus Perspektive des CRA: nicht nur Hersteller sind betroffen

Ein hartnäckiges Missverständnis: Der CRA adressiert nicht ausschließlich den Hersteller im klassischen Sinne. Die Verordnung kennt vier Kategorien von Wirtschaftsakteuren, die jeweils eigene Pflichten tragen:

• Hersteller (Art. 3 Nr. 13) ist, wer PwDE entwickelt oder herstellen lässt und unter eigenem Namen oder eigener Marke vermarktet — ob gegen Bezahlung oder unentgeltlich. Wichtig: Das schließt White-Label-Modelle ein, bei denen ein Unternehmen Produkte eines anderen unter eigenem Namen vertreibt.
• Bevollmächtigter (Art. 3 Nr. 15) ist ein in der EU ansässiger Stellvertreter, den der Hersteller schriftlich benennt. Er springt vor allem dann ein, wenn der Hersteller selbst nicht in der EU sitzt: Der Bevollmächtigte ist dann für die Behörden ansprechbar, hält die technische Dokumentation bereit und übernimmt den Schriftverkehr mit den Marktüberwachungsbehörden (s. Art. 18). Die eigentliche Arbeit am Produkt bleibt aber beim Hersteller. Konformitätsbewertung, Sicherheitsupdates und alle anderen Kernpflichten kann er nicht abgeben, der Bevollmächtigte ist sein Vertreter vor Ort, nicht sein Ersatz.
• Importeure (Art. 3 Nr. 16) sind in der EU ansässige Unternehmen, die ein Produkt eines außerhalb der EU ansässigen Herstellers in den EU-Markt einführen. Ihre Pflichten reichen weit: Vor dem Inverkehrbringen müssen sie sicherstellen, dass der Hersteller die Konformitätsbewertung durchgeführt hat, die CE-Kennzeichnung vorliegt und die technische Dokumentation verfügbar ist (Art. 19).
• Händler (Art. 3 Nr. 17) sind alle weiteren Glieder der Lieferkette, die ein Produkt ohne Änderung seiner Eigenschaften bereitstellen — klassische Reseller und Distributoren. Auch sie tragen Sorgfaltspflichten und müssen vor dem Weitervertrieb prüfen, ob CE-Kennzeichnung und erforderliche Dokumentation vorhanden sind (Art. 20).

Die entscheidende Sonderregel steht in Art. 21 CRA: Wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt oder ein bereits platziertes Produkt wesentlich verändert, gilt automatisch als Hersteller — unabhängig von seiner eigentlichen Rolle in der Lieferkette. In der Praxis trifft das häufig Importeure und Händler, die rebranden oder modifizieren. Die Konsequenz ist vollumfassend: Herstellerpflichten inklusive der Meldepflichten nach Art. 14.

Der CRA ist damit keine reine Hersteller-, sondern eine Lieferkettenverordnung.

Wer Produkte aus Drittstaaten einführt und weiterverkauft, trägt als Importeur erhebliche Mitverantwortung für die Konformität — und kann sich nicht auf den Hersteller allein verlassen.

Die Produktklassifizierung im Cyber Resilience Act: vier Kategorien, unterschiedliche Konformitätspflichten

Der CRA teilt PwDE in vier Kategorien ein — das betrifft ausschließlich die Art der Konformitätsbewertung, nicht den Umfang der inhaltlichen CRA-Pflichten, die für alle Klassen gelten. Für die Meldepflichten nach Art. 14 ist diese Klassifizierung ohnehin ohne Belang; für den weiteren Verlauf der Serie ist sie es umso mehr.

• Die Default-Kategorie umfasst rund 90 % aller PwDE: alle Produkte ohne explizite Einstufung als wichtig oder kritisch. Sowas wie Smart-TVs, Netzwerkdrucker, Bluetooth-Lautsprecher, Media-Player-Software. Hier genügt die Selbstbewertung durch den Hersteller (Modul A).
• Die Kategorie „Wichtige Produkte (Important) Klasse I“ (s. Annex III) umfasst PwDE, die ein erhöhtes Cybersicherheitsrisiko tragen: Identity-Management-Systeme, Browser, Passwortmanager, Antivirensoftware, VPN-Produkte, Netzwerkmanagementsysteme, Betriebssysteme, Router, Modems, Switches, Mikroprozessoren mit sicherheitsrelevanten Funktionen sowie Smart-Home-Produkte mit Sicherheitsfunktionen und vernetztes Spielzeug. Für Klasse I ist die Selbstbewertung anhand harmonisierter Normen grundsätzlich auch möglich — künftig voraussichtlich über die EN 40000 (insb. EN 40000-1-4), sobald sie im EU-Amtsblatt referenziert ist. Ohne solche Normen wird eine Drittprüfung fällig.
• Die Kategorie „Wichtige Produkte Klasse II“ (s. Annex III) bezeichnet konkret Hypervisoren, Container-Runtime-Systeme, Firewalls, Intrusion-Detection- und Prevention-Systeme sowie manipulationssichere Mikroprozessoren und Mikrocontroller. Diese erfordern immer eine Drittprüfung durch eine notifizierte Stelle, unabhängig von der Normenanwendung.
• Die Kategorie „Kritische Produkte“ (s. Annex IV) umfasst Hardware-Sicherheitsboxen, Smart-Meter-Gateways und Chipkarten/Sicherheitselemente. Diese verlangen eine Zertifizierung nach einem europäischen Cybersicherheitszertifizierungsschema, etwa dem EUCC (European Common Criteria-based Cybersecurity Certification Scheme).

Noch einmal zum Mitschreiben: Die Timeline des Cyber Resilience Act und drei Stichtage, die zählen

Der CRA trat am 10. Dezember 2024 in Kraft, ist aber noch nicht in voller Breite verpflichtend. Drei Daten strukturieren den Übergang:

• 11. Juni 2026: Das Notifizierungsverfahren für Konformitätsbewertungsstellen (Kapitel IV, Art. 35–51) gilt. Ab hier lassen sich notifizierte Stellen für Drittprüfungen beauftragen.
• 11. September 2026: Die Meldepflichten nach Art. 14 gelten. Für alle PwDE im Scope, auch für Bestandsprodukte (s. Art. 69 Abs. 3). Das ist der Schwerpunkt dieses Artikels, dazu gleich mehr.
• 11. Dezember 2027: Alle CRA-Anforderungen gelten vollständig. Ab diesem Datum dürfen nur noch konforme Produkte mit CE-Kennzeichnung auf dem EU-Markt bereitgestellt werden.

Ein wichtiger Punkt liegt in Art. 69 Abs. 3: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den übrigen CRA-Anforderungen grundsätzlich nur, wenn sie nach diesem Datum wesentlich geändert werden. Die Meldepflichten nach Art. 14 gelten dagegen ausnahmslos für alle Produkte im Scope, auch für Altprodukte, die heute schon im Feld sind. Genau dieser Unterschied ist vielen Herstellern nicht bewusst.

Die Support Period im CRA und warum die Meldepflicht nicht beim Verkauf endet

Die gleich genauer beschriebenen Meldepflichten laufen nicht bis zum nächsten Release, sondern über den gesamten Unterstützungszeitraum des Produkts. Dieser beträgt mindestens fünf Jahre, sofern die voraussichtliche Nutzungsdauer nicht kürzer ist (s. Art. 13 Abs. 8).

Bei erfahrungsgemäß langlebigen Produkten (industrielle Steuerungssysteme, Netzwerkinfrastruktur, Betriebssysteme u.a.) ist er entsprechend länger anzusetzen.

Konkret heißt das: Wer heute ein Produkt in den Markt bringt, muss für mindestens fünf Jahre Schwachstellen und Sicherheitsvorfälle erkennen, bewerten und — bei erfüllten Kriterien — melden können.

Die Meldepflicht im Cyber Resilience Act ist also kein einmaliger Compliance-Akt, sondern ein dauerhafter operativer Prozess.

Der kurze Blick auf die stets dramatisch inszenierten CRA-Bußgelder

Es gilt sich auch mit Blick auf den 11. September 2026 klarzumachen: Verstöße gegen die Meldepflichten nach Art. 14 fallen unter die höchste Bußgeldstufe des CRA (s. Art. 64 Abs. 2): Geldbußen bis zu 15.000.000 EUR oder bei Unternehmen bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist.

Das ist dieselbe Sanktionshöhe wie für Verstöße gegen die grundlegenden Cybersicherheitsanforderungen aus Annex I. Es ist festzuhalten: Ein Meldeversäumnis wird regulatorisch also gleichrangig behandelt wie das Inverkehrbringen eines unsicheren Produkts.

Eine eng umrissene Ausnahme gilt für Kleinst- und Kleinunternehmen (s. Art. 64 Abs. 10): Sie sind von Geldbußen speziell für die Nichteinhaltung der 24-Stunden-Frühwarnfrist (s. Art. 14 Abs. 2 lit. a und Art. 14 Abs. 4 lit. a) befreit. Ausschließlich aber nur für diese eine Frist, nicht für die Meldepflicht insgesamt, nicht für die 72-Stunden-Frist, nicht für den Abschlussbericht. Für Open-Source-Software-Stewards entfallen bei Verstößen gegen die Verordnung insgesamt Geldbußen nach den genannten Absätzen (s. Art. 64 Abs. 10 lit. b CRA).

Was sich gegenwärtig natürlich noch nicht zuverlässig vorhersagen lässt: Ob Marktüberwachungsbehörden ab September 2026 sofort maximale Bußgelder verhängen, ist offen.

Aber: Die Erfahrung aus der Einführung der EU-Datenschutzgrundverordnung (DSGVO) spricht dafür, dass Behörden zunächst Kapazitäten aufbauen und anlassbezogen vorgehen. Die materielle Bußgeldfähigkeit besteht jedoch ab dem ersten Tag.

Der Meldeprozess nach Artikel 14 im Cyber Resilience Act im Detail

Der Artikel 14 definiert zwei voneinander unabhängige Auslöser. Beide präzise zu trennen ist entscheidend, weil in der Praxis erhebliche Unsicherheit darüber herrscht, was tatsächlich zu melden ist.

• Auslöser 1: Aktiv ausgenutzte Schwachstellen (s. Art. 14 Abs. 1). Meldepflichtig ist eine Schwachstelle, wenn sie aktiv ausgenutzt Wenn also verlässliche Nachweise vorliegen, dass ein böswilliger Akteur sie in einem realen System ohne Zustimmung des Systemeigners ausgenutzt hat (Art. 3 Nr. 42). Die Schlüsselwörter sind „aktiv” und „böswillig”: Die bloße Existenz einer bekannten, aber nicht ausgenutzten Schwachstelle (CVE ohne known exploitation) löst also keine Meldepflicht aus.
• Auslöser 2: Schwerwiegende Sicherheitsvorfälle (s. Art. 14 Abs. 3). Schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensitiver oder wichtiger Daten oder Funktionen zu schützen, negativ beeinträchtigt oder beeinträchtigen kann — oder wenn er zur Einführung oder Ausführung von Schadcode in einem Produkt oder im Netz-/Informationssystem eines Nutzers geführt hat oder führen kann (s. Art. 14 Abs. 5).

Im Nachfolgenden eine erste praktische Entscheidungshilfe wann melden oder nicht melden:

Die CRA-Meldepflicht im Detail: drei wichtige Fristen nach Kenntniserlangung

Die Meldepflicht des CRA ist in drei Stufen mit harten Fristen gegliedert. Alle Fristen starten mit der Kenntniserlangung des Herstellers. Nicht mit dem Auftreten des Vorfalls, nicht mit dem CVE-Eintrag in eine Datenbank, nicht mit einer internen Eskalation.

• Stufe 1: Frühwarnung — binnen 24 Stunden. Unverzüglich, spätestens 24 Stunden nach Kenntniserlangung. Bei Schwachstellen: Hinweis auf die aktiv ausgenutzte Schwachstelle und, soweit bekannt, die Mitgliedstaaten, in denen das Produkt bereitgestellt wurde. Bei schwerwiegenden Vorfällen: mindestens die Angabe, ob der Verdacht rechtswidriger oder böswilliger Handlungen besteht. Die Frist ist bewusst niedrigschwellig. Es geht nicht um eine fertige Analyse, sondern um die erste Signalisierung an die Behörden, dass etwas passiert ist.
• Stufe 2: Detailmeldung — binnen 72 Stunden. Soweit nicht bereits in der Frühwarnung enthalten: allgemeine Informationen zum betroffenen Produkt, Art der Ausnutzung und der Schwachstelle bzw. des Vorfalls, bereits ergriffene Korrektur- oder Risikominderungsmaßnahmen sowie Handlungsempfehlungen für Nutzer. Zusätzlich die Einschätzung des Herstellers, wie sensibel die gemeldeten Informationen sind.
• Stufe 3: Abschlussbericht. Für aktiv ausgenutzte Schwachstellen spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme; für schwerwiegende Vorfälle einen Monat nach der Detailmeldung. Inhalt: vollständige Beschreibung von Schwachstelle bzw. Vorfall inklusive Schweregrad und Auswirkungen, gegebenenfalls Informationen zu beteiligten böswilligen Akteuren sowie Details zur bereitgestellten Korrekturmaßnahme.

Ein konkretes Beispiel für die CRA-Meldepflicht: „der Montagmorgen-Incident“

Ein Kunde meldet am Montag um 09:15 Uhr, dass sein Gerät aktiv angegriffen wird und ein Angreifer offensichtlich Zugriff auf die Konfigurationsschnittstelle erlangt hat. Ab diesem Moment läuft die Uhr:

• Bis Dienstag 09:15 Uhr: Frühwarnung an CSIRT* und ENISA — „Wir haben Kenntnis von einer aktiv ausgenutzten Schwachstelle in Produkt X, das unserer Kenntnis nach in Deutschland und Österreich bereitgestellt wird.”
• Bis Donnerstag 09:15 Uhr: Detailmeldung — Produktversion, Art der Ausnutzung (z. B. Authentication Bypass über API-Schnittstelle), bereits ergriffene Maßnahmen (z. B. temporäre Abschaltung der betroffenen Schnittstelle), Handlungsempfehlung für Nutzer.
• Bis 14 Tage nach Patch-Bereitstellung: Abschlussbericht — vollständige CVE-Beschreibung, Schweregrad (z. B. CVSS-Score), Informationen zum Angreifer (soweit bekannt), Details zum Patch.

Was das Beispiel zeigt: Es braucht für so ein Szenario keinen 24/7-Bereitschaftsdienst im klassischen Sinne. Aber es erfordert einen definierten Eskalationsweg, der auch außerhalb der Bürozeiten trägt.

• Wer entscheidet, ob ein gemeldeter Vorfall die Meldepflicht auslöst?
• Wer hat Berechtigung und Information, die Frühwarnung zu verfassen?
• Wer meldet über welchen Kanal an die ENISA?

Diese Fragen müssen vor September 2026 beantwortet und dokumentiert sein. Nicht erst, wenn es brennt, denn dann dürfte es knapp werden.

*Was ist das CSIRT? Ein CSIRT (oder Computer Security Incident Response Team) ist eine spezialisierte Organisationseinheit, die für die Erkennung, Analyse und Koordination der Reaktion auf Cybersicherheitsvorfälle zuständig ist. Im CRA-Kontext ist der Begriff präziser gefasst: Der CRA bezieht sich immer auf “als Koordinator benannte CSIRTs” – das sind nationale CSIRTs, die von den Mitgliedstaaten explizit als Koordinatoren für die koordinierte Offenlegung von Schwachstellen benannt wurden.

Der Meldeweg im Cyber Resilience Act: einmal melden (zentral)

Meldungen nach Art. 14 gehen nicht an jede nationale Behörde einzeln. Der CRA sieht vor, dass eine Single Reporting Platform (SRP) der ENISA (s. Art. 16) als zentraler elektronischer Eingang dient. Von dort leitet die ENISA die Meldung automatisch an das zuständige nationale CSIRT weiter, das als Koordinator benannt ist.

Die SRP soll pünktlich zum 11. September 2026 in Betrieb gehen. Hersteller sollten sich vorab registrieren und den technischen Zugang testen. Auch hier wartet die 24-Stunden-Frist nicht auf das Onboarding.

Welches CSIRT ist zuständig?

Die Zuständigkeit richtet sich nach der Hauptniederlassung des Herstellers in der EU, also dann dem Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden (s. Art. 14 Abs. 7). Für Deutschland ist das zuständige CSIRT das BSI-CERT des Bundesamts für Sicherheit in der Informationstechnik (kurz BSI).

Für Hersteller ohne Hauptniederlassung in der EU gilt eine Rangfolge (s. Art. 14 Abs. 7):

1. Mitgliedstaat des Bevollmächtigten, der für die meisten Produkte des Herstellers handelt
2. Mitgliedstaat des Einführers mit den meisten Produkten des Herstellers
3. Mitgliedstaat des Händlers mit den meisten Produkten des Herstellers
4. Mitgliedstaat, in dem sich die meisten Nutzer der Produkte befinden

CRA-Meldepflicht und Abgrenzung zu NIS2: zwei Meldewege, zwei Organisationseinheiten

Wer bereits beide Abläufe kennt, sieht den Unterschied sofort: Unter NIS2 melden betroffene Organisationen Vorfälle an ihre jeweilige nationale Behörde — je nach Mitgliedstaat verschieden. Der CRA als EU-Verordnung läuft dagegen zentral über die ENISA.

Wer als Hersteller kritischer Infrastruktur beiden Regimen unterliegt (z.B. sowohl als NIS2-wesentliche Einrichtung als auch als CRA-Hersteller) bedient folglich zwei separate Meldewege, mit potenziell unterschiedlichen Fristen und Inhalten. Eine Meldung ersetzt dabei nicht die andere.

Sonderfall: Der Nicht-EU-Hersteller, den die CRA-Compliance nicht interessiert?

Einer der kritischsten Praxisfälle: Der eigentliche Produkthersteller sitzt außerhalb der EU und ignoriert CRA-Compliance faktisch. Das ist kein theoretisches Szenario sondern gerade bei günstiger Elektronikware aus Fernost ist es die Regel: Der Hersteller liefert, veröffentlicht keine CVEs, meldet nichts, reagiert nicht auf Schwachstellenmeldungen.

Dann steht der EU-Importeur im Obligo. Art. 19 Abs. 5 verpflichtet ihn, den Hersteller unverzüglich über bekannte Schwachstellen zu informieren; bei erheblichem Cybersicherheitsrisiko muss er die Marktüberwachungsbehörde einschalten. Im Extremfall — reagiert der Hersteller nicht und stellt das Produkt ein erhebliches Risiko dar — muss der Importeur selbst handeln, bis hin zur Rücknahme vom Markt.

Praktische Konsequenzen für Importeure:

• Aktives Monitoring von Schwachstellendatenbanken (NVD, BSI-Schwachstellendatenbank, europäische Schwachstellendatenbank nach Art. 12 Abs. 2 NIS2-Richtlinie) für alle importierten Produkte
• Vertragliche Absicherung gegenüber Nicht-EU-Herstellern: Pflicht zur Weitergabe von Sicherheitsinformationen, Patch-Bereitstellung, Kooperation bei Meldepflichten
• Portfolio-Review: Welche importierten Produkte sind CRA-tauglich? Für welche gibt es einen Hersteller, der die Pflichten tatsächlich erfüllen wird?
• Achtung mit Bezug auf Art. 21 CRA: Wer das Produkt unter eigenem Namen vertreibt oder wesentlich verändert, gilt vollständig als Hersteller — mit allen Meldepflichten, ohne Wenn und Aber.

Der Umgang mit den CRA-Meldepflichten, was ist überhaupt Voraussetzung dafür?

Die erwähnten Meldepflichten setzen voraus, dass der Hersteller überhaupt weiß, was in seinem Produkt steckt und welche Schwachstellen existieren. Das klingt trivial, ist es nicht.

Was als Schwachstelle im CRA-Sinne gilt und wie man systematisch danach sucht, ist Gegenstand von zwei weiteren Artikeln dieser Knowledge-Hub-CRA-Artikelserie:

• Artikel 2 adressiert die CRA-konforme Cyber-Risikobewertung
• Artikel 4 thematisiert das Vulnerability Handling und SBOM

Ein kurzer Vorausgriff für technisch versierte Leser: Im CRA-Kontext wird eine Schwachstelle immer entlang der CIA-Trias bewertet — Confidentiality (Vertraulichkeit), Integrity (Integrität), Availability (Verfügbarkeit). Diese drei Dimensionen beschreiben, in welcher Hinsicht ein erfolgreicher Angriff Schaden anrichten kann, und bestimmen so die Kritikalität.

Für die systematische Risikobewertung existieren etablierte Methoden: Die BSI TR-03183 orientiert sich an ISO 31000 und liefert vorgefertigte Asset-Kataloge und Impact-Tabellen; aus dem Automotive- und Fahrzeugentwicklungsbereich ist die TARA-Methodik (Threat Analysis and Risk Assessment nach ISO/SAE 21434) bekannt und konzeptionell übertragbar.

Der CRA schreibt keine spezifische Methode vor, akzeptiert aber jeden strukturierten Ansatz, der Asset-Identifikation, Bedrohungsanalyse und Risikoakzeptanz nachvollziehbar dokumentiert.

Welche Produkteigenschaften verhindern sollen, dass es überhaupt zur Meldung kommt — also welche technischen Anforderungen der CRA an das Produkt selbst stellt — erklärt der folgende Artikel 3 dieser Serie, der die im CRA definierten Essential Cybersecurity Requirements genauer erklärt.

Welche Dokumentation vorgehalten werden muss, um im Ernstfall meldefähig zu sein, und wie der formale Konformitätsnachweis erbracht wird, behandelt Artikel 5 zu Konformitätsbewertung und technischer Dokumentation.