EU-Verordnung 2024/2847

CRA-Glossar

100 Fachbegriffe des EU Cyber Resilience Act — erklärt, mit Quellenangaben und Links zu vertiefenden Artikeln.

A

  • Anhang I

    Enthält die grundlegenden Cybersicherheitsanforderungen nach Art. 13 CRA, aufgeteilt in zwei Teile: Teil I (13 technische Sicherheitsanforderungen) und Teil II (6 Anforderungen zum Schwachstellenmanagement). Gilt verpflichtend für alle Produkte mit digitalen Elementen, unabhängig von der Risikoklasse.

    Anhang I, Art. 13 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • Anhang III

    Enthält die abschließende Liste der "Important Products" (Klasse I und Klasse II) nach Art. 7 CRA. Produkte auf dieser Liste unterliegen strengeren Konformitätsbewertungsverfahren als die Default-Klasse. Klasse I umfasst z. B. VPN-Software und Smart-Home-Hubs, Klasse II Firewalls und Hypervisoren.

    Anhang III, Art. 7 CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • Anhang IV

    Enthält die Liste der "Critical Products" nach Art. 8 CRA — die höchste Risikoklasse. Dazu zählen Hardware-Sicherheitsmodule (HSMs), Smart-Meter-Gateways und Chipkarten-Betriebssysteme. Für Critical Products ist eine EU-Cybersecurity-Zertifizierung (z. B. EUCC) erforderlich.

    Anhang IV, Art. 8 CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • Anhang VII

    Definiert den Mindestinhalt der technischen Dokumentation nach Art. 31 CRA. Sie muss u. a. Produktbeschreibung, Risikoanalyse, SBOM, Konformitätsnachweise und Testergebnisse enthalten. Aufbewahrungspflicht: 10 Jahre nach Inverkehrbringen.

    Anhang VII, Art. 31 CRA (EU-Verordnung 2024/2847) Technische Dokumentation nach CRA

  • Angriffsoberfläche

    Die Summe aller potenziellen Angriffspunkte (Attack Surface) eines Produkts — offene Netzwerkports, APIs, Protokoll-Schnittstellen, Debug-Ports und Nutzerinterfaces. Im CRA-Kontext: Hersteller müssen die Angriffsoberfläche in der Risikoanalyse erfassen und durch Minimalitätsprinzip (nur notwendige Funktionen aktivieren) reduzieren.

    Anhang I Teil I Nr. 2, Art. 13 Abs. 2 CRA (EU-Verordnung 2024/2847) Risikoanalyse nach CRA

  • Authentifizierung

    Technischer Prozess zur Verifikation der Identität eines Nutzers, Geräts oder Systems. Anhang I Teil I Nr. 1 CRA verlangt, dass Produkte mit digitalen Elementen Authentifizierungsmechanismen implementieren. Für sicherheitskritische Funktionen muss starke Authentifizierung (Multi-Faktor, kryptographische Tokens) eingesetzt werden.

    Anhang I Teil I Nr. 1 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • API-Sicherheit

    Schutz von Anwendungsschnittstellen (APIs) vor Missbrauch, unbefugtem Zugriff und Datenlecks. Im CRA-Kontext müssen alle externen APIs eines Produkts in der Risikoanalyse bewertet werden: Authentifizierung, Rate Limiting, Input Validation und Zugriffsrechte. Unsichere APIs sind einer der häufigsten Angriffspfade bei vernetzten Produkten.

    Anhang I Teil I CRA (EU-Verordnung 2024/2847); OWASP API Security Top 10 Risikoanalyse nach CRA

B

  • Bevollmächtigter

    Ein in der EU ansässiger Vertreter eines nicht-EU-Herstellers, der schriftlich bevollmächtigt wurde, die Herstellerpflichten nach dem CRA in der EU wahrzunehmen. Die Bestellung eines Bevollmächtigten ist für nicht-EU-Hersteller verpflichtend, die keine Niederlassung in der EU haben.

    Art. 3 Nr. 18, Art. 20 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • BSI

    Bundesamt für Sicherheit in der Informationstechnik — die zentrale Behörde für Cybersicherheit in Deutschland. Das BSI ist im CRA-Kontext als nationale Marktaufsichtsbehörde für den deutschen Markt vorgesehen. Das BSI veröffentlicht auch CRA-Leitfäden, Technische Richtlinien und begleitet Unternehmen bei der Umsetzung.

    BSI-Gesetz (BSIG), § 1 ff.; CRA Art. 54; BSI: bsi.bund.de/cra BSI als CRA-Marktaufsichtsbehörde

  • Bedrohungsmodellierung

    Systematischer Prozess zur Identifikation und Bewertung von Cyberangriff-Szenarien für ein Produkt. Typische Methoden: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), PASTA oder TARA. Ergebnis ist eine strukturierte Liste von Bedrohungen, die in die Risikoanalyse einfließen.

    Anhang I Teil I CRA (EU-Verordnung 2024/2847); ENISA Threat Modeling Guide Risikoanalyse nach CRA

  • Bußgelder (CRA)

    Bei Verstößen gegen den CRA drohen empfindliche Bußgelder: Bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes (je nachdem was höher ist) für Verstöße gegen wesentliche Anforderungen. Geringere Bußgelder (7,5 Mio. € / 1 % Umsatz) für Meldepflichtverstöße. Marktaufsichtsbehörden können auch Produktrücknahmen anordnen.

    Art. 64 CRA (EU-Verordnung 2024/2847) CRA Bußgelder und Sanktionen

C

  • CE-Kennzeichnung

    Das CE-Zeichen bestätigt die Konformität eines Produkts mit den EU-Anforderungen. Ab Dezember 2027 darf kein CRA-pflichtiges Produkt ohne gültige CE-Kennzeichnung in der EU in Verkehr gebracht werden. Die Kennzeichnung erfolgt nach erfolgter Konformitätsbewertung und Ausstellung der EU-Konformitätserklärung.

    Art. 28, Art. 29 CRA (EU-Verordnung 2024/2847) Konformitätserklärung und CE-Kennzeichnung

  • Common Criteria (CC)

    Internationaler Standard ISO/IEC 15408 für die Bewertung der IT-Sicherheit von Produkten. Für CRA-Critical-Produkte kann die EUCC-Zertifizierung (European Union Cybersecurity Certification Scheme based on Common Criteria) als Konformitätsnachweis verlangt werden.

    ISO/IEC 15408; Art. 8, Anhang IV CRA (EU-Verordnung 2024/2847) CRA Konformitätsbewertung und Self-Assessment

  • CVE

    Common Vulnerabilities and Exposures — ein standardisiertes Bezeichnungssystem für bekannte Sicherheitslücken in Software und Hardware (z. B. CVE-2024-1234). CVEs werden von MITRE gepflegt und in der NVD (National Vulnerability Database) veröffentlicht. Hersteller müssen CVEs in ihren Produkten aktiv überwachen.

    Anhang I Teil II, Art. 14 CRA (EU-Verordnung 2024/2847); MITRE CVE-Programm Schwachstellen-Meldepflicht nach CRA

  • CVD

    Coordinated Vulnerability Disclosure (koordinierte Schwachstellenoffenlegung) — ein Prozess, bei dem Sicherheitsforscher entdeckte Schwachstellen zunächst vertraulich an den Hersteller melden, bevor sie öffentlich bekannt gemacht werden. Der CRA verpflichtet Hersteller, einen CVD-Prozess zu ermöglichen.

    Art. 14 Abs. 1, Anhang I Teil II Nr. 5 CRA (EU-Verordnung 2024/2847) Vulnerability Disclosure Policy erstellen

  • CVSS

    Common Vulnerability Scoring System — ein standardisiertes Bewertungssystem für den Schweregrad von Sicherheitslücken auf einer Skala von 0,0 (kein Risiko) bis 10,0 (kritisch). CVSS ≥ 9,0 gilt als "kritisch", ≥ 7,0 als "hoch". Im CRA-Kontext relevant für die Priorisierung von Schwachstellenbehebungen.

    FIRST CVSS-Standard (v3.1/v4.0); Anhang I Teil II CRA (EU-Verordnung 2024/2847) Schwachstellen-Meldepflicht nach CRA

  • CycloneDX

    Ein offenes SBOM-Standard-Format, ursprünglich von OWASP entwickelt. CycloneDX unterstützt neben Software-Komponenten auch Hardware, Services und Vulnerability-Daten (SBOM + VEX in einem Dokument). Neben SPDX das am häufigsten empfohlene Format für CRA-konforme SBOMs. Wird von zahlreichen Build-Tools nativ unterstützt.

    OWASP CycloneDX Spezifikation; ENISA SBOM Empfehlungen; Anhang I Teil II Nr. 1 CRA SBOM erstellen: Anforderungen nach CRA

  • Cloud-Backend

    Server-seitige Infrastruktur eines vernetzten Produkts (z. B. Device-Management-Server, OTA-Update-Dienst, Telemetrie-Backend). Wenn ein Cloud-Backend direkt mit dem CRA-pflichtigen Gerät kommuniziert, fällt es als "Datenfernverarbeitungslösung" in den CRA-Geltungsbereich. Hersteller sind für Sicherheit des gesamten Systems verantwortlich.

    Art. 3 Nr. 1, Art. 2 CRA (EU-Verordnung 2024/2847) CRA für Cloud-Dienste

D

  • Default-Klasse

    Die Grundklasse des CRA — gilt für alle Produkte mit digitalen Elementen, die nicht in Anhang III (Important) oder Anhang IV (Critical) aufgeführt sind. Für die Default-Klasse ist eine Selbstbewertung (Konformitätsbewertungsmodul A) ausreichend; kein Notified Body erforderlich. Trotzdem gelten alle inhaltlichen Anforderungen aus Anhang I vollständig.

    Art. 6, Art. 32 Abs. 1 CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • DSGVO und CRA

    Der EU Cyber Resilience Act und die DSGVO (Datenschutz-Grundverordnung) ergänzen sich: Die DSGVO schützt personenbezogene Daten, der CRA die Cybersicherheit von Produkten. Beide Verordnungen verlangen Risikoanalysen und Schutzmaßnahmen — aber mit unterschiedlichem Fokus. Produkte die personenbezogene Daten verarbeiten, unterliegen beiden Rechtsrahmen gleichzeitig.

    EU-Verordnung 2024/2847 (CRA); EU-Verordnung 2016/679 (DSGVO) CRA Pflichten für Hersteller

  • Digitale Elemente

    Im CRA-Kontext: alle Software- und Hardware-Bestandteile eines Produkts, die eine direkte oder indirekte Netzwerkverbindung ermöglichen oder darüber kommunizieren. Dazu zählen Firmware, Betriebssysteme, Kommunikationsmodule, eingebettete Software und die zugehörigen Datenfernverarbeitungslösungen (z. B. Cloud-Backend).

    Art. 3 Nr. 1, Art. 2 CRA (EU-Verordnung 2024/2847) Bin ich vom CRA betroffen?

  • Datenintegrität

    Sicherstellung, dass Daten nicht unbemerkt verändert, gelöscht oder verfälscht werden. Im CRA-Anforderungskatalog (Anhang I Teil I) eine der grundlegenden Sicherheitseigenschaften: Produkte müssen die Integrität gespeicherter und übertragener Daten schützen — durch Prüfsummen, kryptographische Signaturen oder sichere Kommunikationsprotokolle.

    Anhang I Teil I Nr. 1 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

E

  • ENISA

    Europäische Agentur für Netz- und Informationssicherheit (European Union Agency for Cybersecurity) — EU-Behörde mit Sitz in Heraklion/Athen. Im CRA-Kontext ist ENISA primärer Empfänger für Meldungen über aktiv ausgenutzte Schwachstellen nach Art. 14 CRA. ENISA betreibt dafür eine spezialisierte Meldeinfrastruktur.

    Art. 14 Abs. 1, Art. 14 Abs. 7 CRA (EU-Verordnung 2024/2847) Schwachstellen-Meldepflicht nach CRA

  • EU Cyber Resilience Act (CRA)

    EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Tritt schrittweise in Kraft: Meldepflichten ab 11. September 2026, volle Geltung ab 11. Dezember 2027.

    EU-Verordnung 2024/2847 (Cyber Resilience Act), veröffentlicht im Amtsblatt der EU am 20. November 2024 Was ist der EU Cyber Resilience Act?

  • EUCC

    European Union Cybersecurity Certification Scheme based on Common Criteria — ein EU-weites Zertifizierungsschema für IT-Sicherheitsprodukte, das auf dem Common Criteria Standard (ISO/IEC 15408) basiert. Für CRA-Critical-Produkte kann eine EUCC-Zertifizierung als Konformitätsnachweis verlangt werden.

    Art. 8 Abs. 2 CRA; EU-Verordnung 2024/482 (EUCC-Verordnung) CRA Risikoklassen erklärt

  • EN 18031

    Europäische Norm EN 18031, entwickelt von ETSI für den Cyber Resilience Act (auch bekannt als ETSI EN 303 645 in der überarbeiteten Form). Umfasst Cybersicherheitsanforderungen für vernetzte Produkte und soll als harmonisierte Norm unter dem CRA anerkannt werden. Anwendung begründet Konformitätsvermutung für abgedeckte Anforderungen.

    ETSI EN 18031; CRA Art. 27 (Harmonisierte Normen) Harmonisierte Normen im CRA

  • EUVDB

    European Union Vulnerability Database — die von ENISA betriebene Datenbank für Schwachstellenmeldungen nach dem CRA. Ab 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen über die EUVDB-Plattform melden. Die EUVDB ergänzt die US-amerikanische NVD als EU-spezifische Infrastruktur.

    Art. 14 Abs. 1 CRA (EU-Verordnung 2024/2847); ENISA EUVDB Schwachstellen-Meldepflicht nach CRA

  • End-of-Life (EoL)

    Der Zeitpunkt, ab dem ein Hersteller keine Sicherheitsupdates mehr für ein Produkt bereitstellt. Im CRA-Kontext: Ein Produkt darf nicht vor Ablauf des Update-Zeitraums (mindestens 5 Jahre) auf EoL gesetzt werden. Wenn ein Produkt EoL geht, muss dies den Nutzern klar kommuniziert werden, damit sie Ersatz beschaffen können.

    Anhang I Teil I Nr. 10, Art. 13 Abs. 8 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

F

  • Firmware

    Fest in ein Gerät eingebettete Software, die grundlegende Hardware-Steuerung und Kommunikation übernimmt (z. B. BIOS, Router-Firmware, SPS-Betriebssystem). Firmware gilt nach CRA als "Produkt mit digitalen Elementen" und unterliegt allen Anforderungen — SBOM, Updates, Risikoanalyse — wenn sie eine Netzwerkschnittstelle hat.

    Art. 3 Nr. 1 CRA (EU-Verordnung 2024/2847) CRA für Embedded-Hersteller

  • FOSS (Open-Source-Software)

    Free and Open-Source Software. Im CRA ist Open-Source-Software grundsätzlich vom Geltungsbereich ausgenommen, wenn sie nicht kommerziell vermarktet wird. Sobald ein Unternehmen Open-Source-Software kommerziell einsetzt, verändert oder unter eigenem Namen vertreibt, entsteht eine CRA-Pflicht. Die Grenze "kommerziell vs. nicht kommerziell" ist in Einzelfällen noch nicht abschließend durch Leitlinien geklärt.

    Art. 2 Abs. 4, Erwägungsgrund 18–19 CRA (EU-Verordnung 2024/2847) CRA und Open Source

G

  • IT-Grundschutz (BSI)

    Das BSI IT-Grundschutz-Kompendium ist ein deutscher Standard für Informationssicherheit, der systematische Sicherheitsmaßnahmen definiert. Unternehmen, die bereits nach IT-Grundschutz arbeiten, haben eine solide Basis für die CRA-Risikoanalyse. IT-Grundschutz ist kein harmonisierter Standard nach CRA, aber inhaltlich weitgehend kompatibel.

    BSI IT-Grundschutz-Kompendium (BSI-Standard 200-1 ff.); CRA Art. 27 ISO 27001 und CRA

  • Geschäftsführer-Haftung

    CRA-Verstöße können neben Unternehmensgeldbußen auch persönliche Haftung für Geschäftsführer und Vorstände begründen — je nach nationalem Recht des Mitgliedstaats. In Deutschland kommen HGB-Sorgfaltspflichten und GmbHG/AktG-Haftungsregeln in Betracht. Compliance-Verantwortung für CRA liegt beim Management.

    Art. 64 CRA (EU-Verordnung 2024/2847); § 43 GmbHG, § 93 AktG CRA: Haftung für Geschäftsführer

H

  • Harmonisierte Norm

    Ein technischer Standard der von der EU-Kommission unter einer EU-Verordnung in Auftrag gegeben und im Amtsblatt der EU veröffentlicht wurde. Wer eine harmonisierte Norm vollständig anwendet, profitiert von der "Konformitätsvermutung" — es wird angenommen, dass die relevanten gesetzlichen Anforderungen erfüllt sind. Für den CRA arbeiten CEN/CENELEC an harmonisierten Normen (z. B. EN 18031).

    Art. 27 CRA (EU-Verordnung 2024/2847); Verordnung (EU) Nr. 1025/2012 (Normungsverordnung) Harmonisierte Normen im CRA

  • Hersteller

    Natürliche oder juristische Person, die ein Produkt mit digitalen Elementen entwickelt oder herstellen lässt und es unter ihrem eigenen Namen oder ihrer eigenen Marke in Verkehr bringt oder in Betrieb nimmt. Hersteller tragen die primäre Verantwortung für CRA-Konformität.

    Art. 3 Nr. 13 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • Händler

    Eine natürliche oder juristische Person in der Lieferkette, die ein Produkt auf dem Markt bereitstellt — ohne es zu verändern. Händler haben im CRA eingeschränktere Pflichten als Hersteller oder Importeure: Sie müssen sicherstellen, dass CE-Kennzeichnung und Dokumentation vorhanden sind, und bei Zweifeln nicht konformer Produkte die Behörden informieren.

    Art. 3 Nr. 21, Art. 22 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • HSM (Hardware Security Module)

    Hardware Security Module — ein spezialisierter Sicherheitsprozessor für kryptographische Operationen und Schlüsselverwaltung. HSMs fallen als "Critical Product" unter Anhang IV CRA und benötigen eine Zertifizierung durch eine notifizierte Stelle sowie ggf. ein europäisches Cybersicherheits-Zertifikat (EUCC).

    Anhang IV CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

I

  • Important Class I

    Mittlere CRA-Risikoklasse (Anhang III, Teil I). Umfasst Produkte mit erhöhtem Sicherheitsrisiko wie VPN-Software, Passwort-Manager, Smart-Home-Hubs, Router, Browser und Betriebssysteme für allgemeine Nutzung. Konformitätsbewertung: Selbstbewertung möglich wenn harmonisierte Normen angewendet werden; sonst Notified Body erforderlich.

    Art. 7, Anhang III Teil I CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • Important Class II

    Hohe CRA-Risikoklasse (Anhang III, Teil II). Umfasst Produkte mit besonders kritischer Sicherheitsfunktion: Hypervisoren, Firewalls, Intrusion-Detection-Systeme, PKI-Produkte, Mikrocontroller mit Sicherheitsfunktion. Notified Body ist immer Pflicht — unabhängig von harmonisierten Normen.

    Art. 7 Abs. 2, Anhang III Teil II CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • Importeur

    Eine in der EU ansässige natürliche oder juristische Person, die ein Produkt aus einem Drittland in der EU in Verkehr bringt. Wenn kein Bevollmächtigter des Herstellers existiert, übernimmt der Importeur wesentliche Herstellerpflichten nach dem CRA — darunter die Prüfung der Konformitätsdokumentation.

    Art. 3 Nr. 20, Art. 21 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • In Verkehr bringen

    Die erstmalige Bereitstellung eines Produkts mit digitalen Elementen auf dem EU-Markt. Dieser Zeitpunkt löst die CRA-Pflichten aus: Ab Dezember 2027 dürfen nur noch CRA-konforme Produkte erstmalig auf dem EU-Markt bereitgestellt werden.

    Art. 3 Nr. 22 CRA (EU-Verordnung 2024/2847) Bin ich vom CRA betroffen?

  • Incident Response

    Strukturierter Prozess zur Reaktion auf Sicherheitsvorfälle: Erkennung, Eindämmung, Behebung, Wiederherstellung und Analyse. Anhang I Teil II CRA fordert, dass Hersteller Prozesse für Sicherheitsvorfälle vorhalten. Incident Response ist eng verknüpft mit der Meldepflicht nach Art. 14 CRA.

    Anhang I Teil II, Art. 14 CRA (EU-Verordnung 2024/2847) Schwachstellen-Meldepflicht nach CRA

  • Integrität

    Sicherheitsziel, das sicherstellt, dass Daten und Code nicht unbemerkt verändert werden (Schutzziel der Informationssicherheit neben Vertraulichkeit und Verfügbarkeit). CRA Anhang I Teil I fordert Integritätsschutz für gespeicherte und übertragene Daten sowie für Firmware- und Software-Updates (z. B. durch kryptographische Signaturen).

    Anhang I Teil I Nr. 1 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • IEC 62443

    Internationale Normenserie für Industrial Automation and Control Systems Security (IACS). IEC 62443 deckt Cybersicherheitsanforderungen für industrielle Netzwerke, Steuerungssysteme und Komponenten ab. Für CRA-pflichtige Industrieprodukte kann IEC 62443 als harmonisierter Standard angewendet werden — ggf. begründet das Konformitätsvermutung.

    IEC 62443-Normenserie; CRA Art. 27 (Harmonisierte Normen) Harmonisierte Normen im CRA

  • ISO 27001

    Internationaler Standard für Informationssicherheits-Managementsysteme (ISMS). Eine ISO-27001-Zertifizierung ist kein direkter Konformitätsnachweis für den CRA, stärkt aber die Risikoanalyse und das Schwachstellenmanagement. Unternehmen mit ISO 27001 ISMS haben eine gute Ausgangslage für die CRA-Konformität.

    ISO/IEC 27001:2022; CRA Anhang I (ergänzend) ISO 27001 und CRA

K

  • Konformitätsbewertung

    Der Prozess, durch den nachgewiesen wird, dass ein Produkt die wesentlichen Anforderungen des CRA erfüllt. Je nach Risikoklasse gibt es verschiedene Bewertungsmodule: Modul A (Selbstbewertung, Default-Klasse), Modul B+C oder EU-Typprüfung (Important/Critical). Die gewählte Methode muss dokumentiert werden.

    Art. 32, 33, 34 CRA (EU-Verordnung 2024/2847) CRA Self-Assessment und Konformitätsbewertung

  • Konformitätserklärung (EU-DoC)

    Das formale Dokument, mit dem der Hersteller erklärt, dass sein Produkt alle relevanten CRA-Anforderungen erfüllt. Die EU-Konformitätserklärung (EU Declaration of Conformity) ist Voraussetzung für die CE-Kennzeichnung und muss 10 Jahre aufbewahrt werden.

    Art. 28 CRA (EU-Verordnung 2024/2847) Konformitätserklärung und CE-Kennzeichnung

  • Konformitätsvermutung

    Rechtliche Vermutung, dass ein Produkt die wesentlichen Anforderungen einer EU-Verordnung erfüllt, wenn es eine harmonisierte europäische Norm vollständig anwendet. Im CRA-Kontext: Wer die harmonisierten Normen (z. B. EN 18031) vollständig anwendet, muss nicht separat beweisen, dass er die entsprechenden CRA-Anforderungen erfüllt.

    Art. 27 CRA (EU-Verordnung 2024/2847); Art. 2 Nr. 5 Verordnung 1025/2012 Harmonisierte Normen im CRA

  • Kryptographie

    Mathematisch-technische Verfahren zur Absicherung von Daten (Verschlüsselung, Signaturen, Schlüsselaustausch). Anhang I Teil I Nr. 1 CRA verlangt den Einsatz von Kryptographie nach Stand der Technik zum Schutz gespeicherter, verarbeiteter und übertragener Daten. Veraltete Algorithmen (MD5, SHA-1, DES) gelten nicht mehr als Stand der Technik.

    Anhang I Teil I Nr. 1 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • Kritische Produkte

    Produkte der höchsten CRA-Risikoklasse nach Anhang IV: Hardware Security Devices mit Sicherheitsfunktion, Smart-Meter-Gateways und Chipkarten-ICs. Für kritische Produkte ist eine notifizierte Stelle Pflicht und zusätzlich ggf. ein europäisches Cybersicherheits-Zertifikat (EUCC) erforderlich. Nur wenige Produkte fallen in diese Klasse.

    Art. 8, Anhang IV CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

L

  • Lebenszyklus-Unterstützung

    Die Pflicht von Herstellern, Sicherheitsupdates über die gesamte "erwartete Nutzungsdauer" des Produkts bereitzustellen — mindestens jedoch 5 Jahre nach Inverkehrbringen. Anhang I Teil I Nr. 10 CRA. Für Produkte die länger als 5 Jahre vermarktet werden, verlängert sich die Updatepflicht entsprechend.

    Anhang I Teil I Nr. 10 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

  • Lieferkette

    Alle Zulieferer von Software- und Hardware-Komponenten die in ein Produkt mit digitalen Elementen eingehen. Hersteller sind verantwortlich für die CRA-Konformität der gesamten Lieferkette. Dies umfasst Open-Source-Komponenten, zugekaufte Bibliotheken und Hardware-Module.

    Art. 13 Abs. 5 CRA (EU-Verordnung 2024/2847) CRA und Lieferkette

  • Least Privilege (Prinzip der minimalen Rechte)

    Sicherheitsprinzip: Jede Komponente, jeder Nutzer und jeder Prozess erhält nur die minimal nötigen Rechte für seine Funktion. Im CRA verlangt Anhang I Teil I, dass Produkte nach dem Minimalprinzip konfiguriert werden — unnötige Dienste, Schnittstellen und Berechtigungen müssen deaktiviert oder entfernt werden.

    Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

M

  • Marktaufsicht

    Die behördliche Überwachung der CRA-Konformität. In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) als nationale Marktaufsichtsbehörde für den CRA vorgesehen. Marktaufsichtsbehörden können Produkte prüfen, Herstellerpflichten durchsetzen und Marktrücknahmen anordnen.

    Art. 54 ff. CRA (EU-Verordnung 2024/2847); BSI-Gesetz (BSIG) BSI als CRA-Marktaufsichtsbehörde

  • Meldepflicht

    Ab 11. September 2026 (nicht erst Dezember 2027!) müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten innerhalb von 24 Stunden an ENISA melden. Innerhalb von 72 Stunden folgt eine detailliertere Meldung. Schwerwiegende Vorfälle mit Sicherheitsauswirkungen sind ebenfalls meldepflichtig.

    Art. 14 CRA (EU-Verordnung 2024/2847); gilt ab 11. September 2026 Schwachstellen-Meldepflicht nach CRA

  • Maschinenverordnung

    EU-Verordnung 2023/1230 über Maschinen und zur Aufhebung der Maschinenrichtlinie 2006/42/EG. Regelt die funktionale Sicherheit von Maschinen (Schutz vor mechanischen Gefährdungen). Gilt parallel zum CRA für vernetzte Maschinen: Die Maschinenverordnung deckt Sicherheitsfunktionen, der CRA Cybersicherheit. CE-Erklärungen für beide können kombiniert werden.

    EU-Verordnung 2023/1230 (Maschinenverordnung); CRA Art. 3 Abs. 2 CRA für Maschinenbauer

  • Minimalprinzip

    Beim CRA: die Anforderung, dass Produkte mit der minimal notwendigen Funktionalität und den minimal notwendigen offenen Schnittstellen ausgeliefert werden. Unnötige Features, Ports, Dienste und Nutzerkonten müssen deaktiviert oder entfernt sein. Kombiniert Secure by Default und Least Privilege zu einer übergreifenden Sicherheitsstrategie.

    Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • Marktrücknahme

    Maßnahme zur Entfernung eines nicht-konformen oder gefährlichen Produkts aus der Lieferkette, bevor es den Endnutzer erreicht. Zu unterscheiden von einem Rückruf (bereits beim Endnutzer). Marktaufsichtsbehörden können Marktrücknahmen anordnen, wenn ein Produkt ernsthaftes Cybersicherheitsrisiko darstellt.

    Art. 3 Nr. 27, Art. 64 ff. CRA (EU-Verordnung 2024/2847) Marktrücknahme und Rückruf nach CRA

  • Modul A (Konformitätsbewertung)

    Interne Fertigungskontrolle — das einfachste Konformitätsbewertungsverfahren nach CRA. Der Hersteller bewertet selbst, ob sein Produkt die CRA-Anforderungen erfüllt, erstellt die technische Dokumentation und stellt die EU-Konformitätserklärung aus. Kein Notified Body erforderlich. Zulässig für die Default-Klasse und Important Class I (mit harmonisierten Normen).

    Art. 32 Abs. 1, Anhang VIII Modul A CRA (EU-Verordnung 2024/2847) Konformitätsbewertungsmodule erklärt

  • Modul H (Konformitätsbewertung)

    Vollständige Qualitätssicherung — das umfangreichste CRA-Konformitätsbewertungsverfahren. Ein Notified Body prüft das vollständige Qualitätssicherungssystem des Herstellers. Zulässig für Important Class II und Critical Products. Vorteil gegenüber Modul B+C: Deckt alle Produktvarianten ab, ohne Einzelprüfungen.

    Art. 32 Abs. 2, Anhang VIII Modul H CRA (EU-Verordnung 2024/2847) Konformitätsbewertungsmodule erklärt

N

  • Notified Body

    Eine von EU-Mitgliedstaaten notifizierte (benannte) unabhängige Prüfstelle, die Konformitätsbewertungen für regulierte Produkte durchführt. Im CRA-Kontext ist ein Notified Body für Important Class II verpflichtend und für Important Class I erforderlich, wenn keine harmonisierten Normen vollständig angewendet werden.

    Art. 35 ff. CRA (EU-Verordnung 2024/2847) Notified Body: Auswahl und Vorbereitung

  • Netzwerksegmentierung

    Aufteilung eines Netzwerks in isolierte Bereiche um die Ausbreitung von Angriffen zu begrenzen. Im CRA-Kontext besonders relevant für Industrieprodukte und SCADA-Systeme: OT- und IT-Netzwerke müssen segmentiert werden. Teil der Risikoanalyse und Schutzmaßnahmen nach Anhang I Teil I.

    Anhang I Teil I CRA; IEC 62443-3-3 CRA für SPS und Industriesteuerungen

  • NANDO-Datenbank

    New Approach Notified and Designated Organisations — die offizielle EU-Datenbank aller notifizierten Stellen für EU-Produktkonformität. Ab dem 11. Juni 2026 sind CRA-Notified Bodies in der NANDO-Datenbank sichtbar. Hersteller, die eine notifizierte Stelle benötigen (Important Class II, Critical), suchen dort nach zugelassenen Prüfstellen.

    CRA Art. 71 Abs. 2; NANDO: https://ec.europa.eu/growth/tools-databases/nando/ Notified Body: Auswahl und Vorbereitung

  • NIS2-Richtlinie

    EU-Richtlinie über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau (Richtlinie 2022/2555). NIS2 gilt für Betreiber kritischer Infrastruktur und wichtiger Dienste — nicht für Produkthersteller wie der CRA. Überschneidungen gibt es, wenn ein Unternehmen sowohl Hersteller (CRA) als auch Betreiber kritischer Infrastruktur (NIS2) ist.

    EU-Richtlinie 2022/2555 (NIS2); Vergleich: /wissen/cra-vs-nis2 CRA vs. NIS2: Was gilt für wen?

  • NVD

    National Vulnerability Database — die umfassendste Schwachstellendatenbank, betrieben vom US-amerikanischen NIST. Enthält Details zu CVEs inkl. CVSS-Scores, betroffene Produktversionen und Patch-Status. Im CRA-Kontext nutzen Hersteller die NVD für CVE-Monitoring und als Quelle für die SBOM-basierte Schwachstellenüberwachung.

    NIST NVD: https://nvd.nist.gov; CRA Art. 14 (Schwachstellenmanagement) Schwachstellen-Meldepflicht nach CRA

O

  • OTA-Update

    Over-the-Air — die drahtlose Übertragung von Software-Updates auf vernetzte Geräte. Für CRA-pflichtige vernetzte Produkte ist OTA-Fähigkeit de facto Pflicht: Anhang I Teil I Nr. 2 fordert, dass Schwachstellen durch Updates behoben werden können. Updates müssen kryptographisch signiert und rollback-fähig sein.

    Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

  • Open-Source-Ausnahme

    Rein Open-Source-Software, die ohne kommerzielle Tätigkeit bereitgestellt wird, ist vom CRA-Geltungsbereich ausgenommen. Sobald eine natürliche oder juristische Person ein Entgelt verlangt, Open-Source-Software in ein kommerzielles Produkt einbettet oder vertreibt, gilt die Ausnahme nicht mehr. Gemeinnützige Organisationen und Stiftungen können ebenfalls unter den CRA fallen.

    Art. 2 Abs. 4, Erwägungsgrund 18 CRA (EU-Verordnung 2024/2847) CRA und Open Source

P

  • Produkt mit digitalen Elementen

    Der zentrale CRA-Begriff für alle Hardware- und Softwareprodukte mit einer digitalen Komponente, die eine direkte oder indirekte Netzwerkverbindung haben können. Art. 3 Nr. 1 CRA. Betroffen ist praktisch jedes vernetzte Gerät, jede App und jede eingebettete Software die in der EU in Verkehr gebracht wird.

    Art. 3 Nr. 1, Art. 2 CRA (EU-Verordnung 2024/2847) Bin ich vom CRA betroffen?

  • Patch-Management

    Systematischer Prozess zur Identifikation, Bereitstellung und Installation von Sicherheits-Patches und Updates. Anhang I Teil II CRA verpflichtet Hersteller, erkannte Schwachstellen zeitnah zu beheben und Patches bereitzustellen. Im CRA-Kontext Teil des Schwachstellenmanagements — enge Verbindung zu SBOM und CVE-Monitoring.

    Anhang I Teil II Nr. 6, Art. 13 Abs. 8 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

  • Penetrationstest

    Autorisierter Angriff auf ein System um Sicherheitslücken zu finden, bevor echte Angreifer dies tun (Pentest). Der CRA fordert keine Pentests explizit, aber für die Risikoanalyse und Konformitätsnachweise werden Pentests de facto erwartet — insbesondere für Important Class II und Critical Products. Für die Selbstbewertung (Modul A) empfiehlt das BSI Penetrationstests.

    Anhang I Teil I, Art. 32 CRA (EU-Verordnung 2024/2847); BSI IT-Grundschutz Risikoanalyse nach CRA

  • Produktlebenszyklus

    Im CRA-Kontext: der Zeitraum von der Entwicklung über das Inverkehrbringen bis zur Außerbetriebnahme eines Produkts. CRA-Anforderungen beziehen sich explizit auf den gesamten Lebenszyklus: Risikoanalyse, Schwachstellenmanagement und Updates müssen bis mindestens 5 Jahre nach letztem Verkauf aufrechterhalten werden.

    Art. 13, Anhang I CRA (EU-Verordnung 2024/2847) CRA Pflichten für Hersteller

  • Produktrückruf

    Maßnahme zur Rücknahme eines bereits beim Endnutzer befindlichen Produkts, wenn es ein ernsthaftes Cybersicherheitsrisiko darstellt. Zu unterscheiden von der Marktrücknahme (noch in der Lieferkette). CRA-Marktaufsichtsbehörden können Rückrufe anordnen. Hersteller müssen Rückrufverfahren in ihrer Schwachstellenreaktion planen.

    Art. 3 Nr. 28, Art. 64 ff. CRA (EU-Verordnung 2024/2847) Marktrücknahme und Rückruf nach CRA

R

  • Risikoanalyse

    Systematische Bewertung der Cybersicherheitsrisiken eines Produkts über seinen gesamten Lebenszyklus. Pflicht nach Anhang I Teil I CRA für alle Hersteller. Die Risikoanalyse muss dokumentiert und in die technische Dokumentation aufgenommen werden.

    Anhang I Teil I, Art. 13 Abs. 2 CRA (EU-Verordnung 2024/2847) Risikoanalyse nach CRA

  • Risikoklasse

    Der CRA unterteilt Produkte in vier Risikoklassen: Default (ca. 80–90 % aller Produkte), Important Class I, Important Class II und Critical. Die Klasse bestimmt, welches Konformitätsbewertungsverfahren notwendig ist und ob ein Notified Body einbezogen werden muss.

    Art. 6–8, Anhang III, Anhang IV CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

S

  • SBOM

    Software Bill of Materials — eine vollständige, maschinenlesbare Liste aller Software-Komponenten eines Produkts inkl. Versions- und Lizenzangaben. Pflicht nach Anhang I Teil II Nr. 1 CRA für alle Hersteller. Standardformate: CycloneDX und SPDX. Grundlage für CVE-Monitoring und Schwachstellenmanagement.

    Anhang I Teil II Nr. 1 CRA (EU-Verordnung 2024/2847) SBOM erstellen: Anforderungen nach CRA

  • Schwachstelle

    Eine Sicherheitslücke oder ein Fehler in einem Produkt, der von Angreifern ausgenutzt werden kann. Hersteller müssen Schwachstellen aktiv überwachen, beheben und — wenn aktiv ausgenutzt — innerhalb von 24 Stunden an ENISA melden. Sicherheitsupdates für kritische Schwachstellen müssen umgehend bereitgestellt werden.

    Art. 3 Nr. 14, Art. 14, Anhang I Teil II CRA (EU-Verordnung 2024/2847) Schwachstellen-Meldepflicht nach CRA

  • Secure by Default

    Sicherheitsprinzip des CRA: Produkte müssen standardmäßig in der sichersten praktikablen Konfiguration ausgeliefert werden. Konkret: Keine Standard-Passwörter, alle unnötigen Dienste deaktiviert, sichere Protokolle aktiviert. Anhang I Teil I Nr. 2 CRA. Eine unsichere Werkseinstellung ist kein legitimer Auslieferungszustand.

    Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • Sicherheits-Token

    Hardware-Gerät zur Speicherung kryptographischer Schlüssel und zur Durchführung sicherer Authentifizierungsoperationen (z. B. FIDO2-Stick, PIV-Smartcard). Sicherheits-Token fallen als "Important Class I" unter Anhang III CRA. Konformitätsbewertung durch Selbstbewertung möglich, wenn harmonisierte Normen angewendet werden.

    Anhang III Teil I CRA (EU-Verordnung 2024/2847) CRA Risikoklassen erklärt

  • Software-Update-Mechanismus

    Technischer Mechanismus für die sichere Bereitstellung und Installation von Software-Updates. Anhang I Teil I Nr. 2 CRA verlangt, dass Hersteller einen sicheren Update-Mechanismus implementieren: Updates müssen kryptographisch signiert, authentifiziert und vor Manipulation geschützt sein. Rollback-Fähigkeit ist Best Practice.

    Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

  • Secure by Design

    Designprinzip, bei dem Cybersicherheit von Beginn der Produktentwicklung an eingebaut wird — nicht nachträglich ergänzt. Der CRA verankert Secure by Design als grundlegendes Anforderungsprinzip (Art. 13, Anhang I). Produkte müssen so entwickelt werden, dass Sicherheitslücken durch die Architektur minimiert werden.

    Art. 13 Abs. 1, Anhang I Teil I Nr. 2 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • security.txt

    Eine Textdatei unter der standardisierten URL /.well-known/security.txt, die Sicherheitsforschern Kontaktinformationen für Schwachstellenmeldungen bietet (RFC 9116). Im CRA-Kontext: security.txt ist die technisch einfachste Umsetzung der VDP-Pflicht nach Art. 13 Abs. 6 CRA. Die Datei muss mindestens Kontakt-E-Mail und/oder URL enthalten.

    RFC 9116; Art. 13 Abs. 6 CRA (EU-Verordnung 2024/2847) Vulnerability Disclosure Policy erstellen

  • Sicherheitsarchitektur

    Die strukturierte Beschreibung aller Sicherheitsmaßnahmen eines Produkts: Authentifizierungskonzept, Kryptographie-Einsatz, Netzwerksegmentierung, Update-Mechanismus, Zugriffsrechte. Teil der technischen Dokumentation nach Anhang VII CRA. Eine dokumentierte Sicherheitsarchitektur ist Grundlage für Konformitätsbewertung und Marktaufsichtskontrollen.

    Anhang VII CRA (EU-Verordnung 2024/2847) Technische Dokumentation nach CRA

  • Smart-Meter-Gateway

    Kommunikationseinheit für intelligente Messsysteme (iMSys), die Energieverbrauchsdaten sicher übertragen. Smart-Meter-Gateways sind im CRA explizit als "Critical Product" in Anhang IV gelistet. Sie benötigen eine Zertifizierung durch eine notifizierte Stelle und ggf. EUCC-Zertifizierung.

    Anhang IV CRA (EU-Verordnung 2024/2847); Messstellenbetriebsgesetz (MsbG) CRA Risikoklassen erklärt

  • Software-Lieferkette

    Die Kette aller Software-Komponenten, Bibliotheken, Tools und Prozesse, die in die Entwicklung und Bereitstellung eines Produkts einfließen. Supply-Chain-Angriffe (z. B. Log4Shell, SolarWinds) zeigen die Risiken. Im CRA verlangt Art. 13 Abs. 5, dass Hersteller die Sicherheit ihrer gesamten Software-Lieferkette gewährleisten.

    Art. 13 Abs. 5 CRA (EU-Verordnung 2024/2847) CRA und Lieferkette

  • SPDX

    Software Package Data Exchange — ein ISO-Standard (ISO/IEC 5962:2021) für SBOM-Daten. SPDX ist neben CycloneDX das zweite empfohlene Format für CRA-konforme SBOMs. Es hat besondere Stärken bei der Lizenz-Compliance-Verwaltung und ist in der Linux-Welt weit verbreitet (z. B. Yocto-Projekte).

    ISO/IEC 5962:2021 (SPDX); Anhang I Teil II Nr. 1 CRA SBOM erstellen: Anforderungen nach CRA

  • STRIDE

    Threat-Modeling-Methodik von Microsoft, die sechs Bedrohungskategorien unterscheidet: Spoofing (Identitätsvortäuschung), Tampering (Manipulation), Repudiation (Abstreitbarkeit), Information Disclosure (Datenleck), Denial of Service (Verfügbarkeitsangriff), Elevation of Privilege (Rechteeskalation). Häufig verwendete Methodik für die CRA-Risikoanalyse.

    Microsoft Threat Modeling Tool; Anhang I Teil I CRA (EU-Verordnung 2024/2847) Risikoanalyse nach CRA

T

  • Technische Dokumentation

    Vollständige Dokumentation des Produkts gemäß Anhang VII CRA. Inhalt: Produktbeschreibung, Konformitätsbewertungsunterlagen, Risikoanalyse, SBOM, Testberichte und mehr. Aufbewahrungspflicht: 10 Jahre nach dem letzten Inverkehrbringen. Grundlage für Marktaufsichtskontrollen.

    Art. 31, Anhang VII CRA (EU-Verordnung 2024/2847) Technische Dokumentation nach CRA

  • Transparenzpflichten

    Hersteller müssen Nutzern wesentliche Sicherheitsinformationen über ihr Produkt bereitstellen: Unterstützungszeitraum, bekannte Schwachstellen, Kontaktdaten für Sicherheitsmeldungen, SBOM (auf Anfrage). Diese Transparenzpflichten sollen Nutzern helfen, informierte Kaufentscheidungen zu treffen und Risiken zu bewerten.

    Art. 13 Abs. 7, Art. 13 Abs. 9 CRA (EU-Verordnung 2024/2847) CRA Pflichten für Hersteller

  • TARA

    Threat Analysis and Risk Assessment — eine Bedrohungsanalyse- und Risikobewertungsmethodik, die in der Automobilindustrie aus ISO 21434 (und UNECE WP.29 / UN-R 155) bekannt ist. Im CRA-Kontext kann TARA als strukturierte Methodik für die Risikoanalyse nach Anhang I Teil I dienen.

    ISO/SAE 21434; Anhang I Teil I CRA (EU-Verordnung 2024/2847) Risikoanalyse nach CRA

  • Technische Kompetenz

    Im CRA-Kontext: die Anforderung, dass Notified Bodies und Hersteller nachweislich über technisches Know-how für die Bewertung ihrer Produktkategorie verfügen. Für Notified Bodies ist Kompetenznachweis Voraussetzung für Notifizierung. Für Hersteller ist internes oder externes Cybersicherheits-Know-how notwendig für glaubwürdige Selbstbewertungen.

    Art. 36, 37 CRA (EU-Verordnung 2024/2847) Notified Body: Auswahl und Vorbereitung

U

  • Update-Zeitraum

    Der Zeitraum, über den ein Hersteller Sicherheitsupdates bereitstellen muss. Mindestanforderung nach CRA: 5 Jahre oder die "erwartete Nutzungsdauer", je nachdem welcher Zeitraum länger ist. Der Update-Zeitraum muss in der EU-Konformitätserklärung und in der Produktdokumentation angegeben werden.

    Anhang I Teil I Nr. 10, Art. 13 Abs. 8 CRA (EU-Verordnung 2024/2847) Sicherheitsupdates nach CRA

V

  • VDP

    Vulnerability Disclosure Policy — eine öffentlich zugängliche Richtlinie, die beschreibt wie Sicherheitsforscher und Dritte Schwachstellen im Produkt melden können. Art. 13 Abs. 6 CRA verpflichtet alle Hersteller zur Veröffentlichung einer VDP. Sie muss Kontaktinformationen und den erwarteten Meldeprozess enthalten.

    Art. 13 Abs. 6, Anhang I Teil II Nr. 5 CRA (EU-Verordnung 2024/2847) Vulnerability Disclosure Policy erstellen

  • Versionsmanagement

    Systematische Verwaltung von Software-Versionen inklusive Changelog, Abhängigkeiten und Sicherheits-Patches. Im CRA-Kontext: Jede veröffentlichte Version muss einer SBOM zugeordnet werden können. Das Versionsmanagement ist Grundlage für CVE-Tracking ("Welche Version ist von CVE-XYZ betroffen?") und für die Patch-Kommunikation an Kunden.

    Anhang I Teil II Nr. 1 CRA (EU-Verordnung 2024/2847) SBOM erstellen: Anforderungen nach CRA

  • VEX

    Vulnerability Exploitability eXchange — ein Datenformat, das Hersteller verwenden, um den Ausnutzbarkeitsstatus bekannter CVEs in ihren Produkten zu kommunizieren. VEX-Dokumente werden oft zusammen mit SBOMs veröffentlicht und informieren Nutzer darüber, ob ein CVE in der spezifischen Produktkonfiguration tatsächlich ausnutzbar ist.

    CISA VEX-Dokument; OWASP CycloneDX VEX-Profil; Anhang I Teil II CRA SBOM erstellen: Anforderungen nach CRA

  • Vulnerability Management

    Kontinuierlicher Prozess zur Identifikation, Bewertung, Behebung und Dokumentation von Schwachstellen in einem Produkt. Anhang I Teil II CRA verpflichtet Hersteller zu einem systematischen Vulnerability-Management-Programm — von der CVE-Überwachung über koordinierte Offenlegung bis zur Patch-Bereitstellung.

    Anhang I Teil II CRA (EU-Verordnung 2024/2847) Schwachstellen-Meldepflicht nach CRA

W

  • Wirtschaftsakteur

    Oberbegriff im CRA für alle am Inverkehrbringen und Bereitstellen von Produkten beteiligten Parteien: Hersteller, Bevollmächtigte, Importeure und Händler. Jede Kategorie hat unterschiedliche, abgestufte Pflichten. Hersteller tragen die umfassendsten Verantwortlichkeiten.

    Art. 3 CRA; Art. 13–26 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • White-Label

    Ein Produkt, das von einem OEM hergestellt, aber unter der Marke eines anderen Unternehmens vertrieben wird (OEM-Rebranding). Im CRA gilt: Wer ein White-Label-Produkt unter eigenem Namen in der EU in Verkehr bringt, wird dadurch zum Hersteller — mit allen CRA-Pflichten. Der OEM bleibt daneben eigener Hersteller. Beide können CRA-pflichtig sein.

    Art. 3 Nr. 13 CRA (EU-Verordnung 2024/2847) Wirtschaftsakteure nach CRA

  • Wesentliche Produktänderung

    Eine Änderung an einem bereits auf dem Markt befindlichen Produkt, die als neues Inverkehrbringen gilt und damit neue CRA-Pflichten auslöst. Wesentliche Änderungen können sein: neue Netzwerkschnittstellen, neue Funktionen oder tiefgreifende Software-Änderungen. Bei nur unwesentlichen Updates (Bugfixes) gilt das Produkt als nicht neu in Verkehr gebracht.

    Art. 3 Nr. 22, Art. 13 CRA (EU-Verordnung 2024/2847) Produktänderungen und CRA

Z

  • Zugangskontrolle

    Mechanismen, die den Zugriff auf Systemressourcen auf autorisierte Nutzer und Prozesse beschränken. Anhang I Teil I Nr. 1 CRA fordert Zugangskontrolle als grundlegende Sicherheitsanforderung. Dazu zählen Authentifizierung, Autorisierung, rollenbasierte Zugriffskontrolle (RBAC) und physische Zugangssicherung.

    Anhang I Teil I Nr. 1 CRA (EU-Verordnung 2024/2847) CRA Anhang I im Detail

  • Zulieferer

    Unternehmen, das Software-Komponenten, Hardware-Module oder Firmware an einen Produkthersteller liefert, ohne das Endprodukt selbst in Verkehr zu bringen. Der Hersteller ist für die CRA-Konformität der Zulieferer-Komponenten in seinem Produkt verantwortlich. Best Practice: SBOMs und Sicherheitsdokumentation vom Zulieferer einfordern.

    Art. 13 Abs. 5 CRA (EU-Verordnung 2024/2847) CRA und Lieferkette

  • Zertifizierung (Cybersicherheit)

    Formale Bestätigung durch eine akkreditierte Stelle, dass ein Produkt bestimmte Sicherheitsanforderungen erfüllt. Im CRA-Kontext: Für Critical Products kann eine Zertifizierung nach dem EUCC-Schema (Common Criteria) verlangt werden. Für Important Class II ist ein Notified Body erforderlich, aber noch kein volles Zertifizierungsschema.

    Art. 8 Abs. 2 CRA; EU-Verordnung 2024/482 (EUCC); ENISA EUCS CRA Self-Assessment und Konformitätsbewertung

Begriff verstanden — jetzt Ihr Produkt prüfen

Kostenloser CRA-Check: Indikative Klassifizierung in 5 Minuten.

CRA-Prüfung starten Zur Wissensdatenbank
Hinweis: Diese Information ist eine indikative Einschätzung auf Basis der EU-Verordnung 2024/2847 und ersetzt keine Rechtsberatung. Bei rechtlichen Fragen wenden Sie sich bitte an einen spezialisierten Anwalt.