CRA-Konformitäts-Glossar

Wesentliche Terminologie zum Verständnis der EU Cyberresilienz-Verordnung, der Sicherheitsstandards für Software-Lieferketten und der Compliance-Anforderungen.

A

Anhang VII

CRA-Anhang VII legt den Mindestinhalt der EU-Konformitätserklärung fest, die Hersteller für Produkte mit digitalen Elementen ausstellen müssen. Enthält Produktidentifikation, Herstellerangaben, angewendete Normen und die Unterschrift eines bevollmächtigten Vertreters.

CRA-Anhang

Artikel 13 - Pflichten der Hersteller

CRA Artikel 13 legt die grundlegenden Herstellerpflichten fest: Security by Design, SBOM-Pflege, Schwachstellenbehandlung, Bereitstellung von Sicherheitsupdates über den gesamten Produktlebenszyklus und Aufbewahrung der technischen Dokumentation für mindestens 10 Jahre.

CRA-Artikel

Artikel 14 - Meldepflichten

CRA Artikel 14 verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden (Frühwarnung), 72 Stunden (Detailbericht) und 14 Tagen (Abschlussbericht) an ENISA zu melden. Schwerwiegende Vorfälle folgen demselben Schema, jedoch mit einer 30-Tage-Frist für den Abschlussbericht.

CRA-Artikel

B

Benannte Stelle

Unabhängige Konformitätsbewertungsstelle, die von einem EU-Mitgliedstaat benannt wurde, um zu beurteilen, ob Produkte regulatorische Anforderungen erfüllen. Erforderlich für die Drittpartei-Konformitätsbewertung von Wichtiges Produkt (Klasse I), Wichtiges Produkt (Klasse II) und Kritische Produkte gemäß CRA-Anhang III und IV.

CRA-Anforderung

Bevollmächtigter Vertreter - Artikel 18

Nach Artikel 18 Absatz 1 der Verordnung (EU) 2024/2847 (der Cyberresilienz-Verordnung) kann ein Hersteller schriftlich eine in der Union ansässige natürliche oder juristische Person als Bevollmächtigten benennen. Die Benennung ist nach dem CRA freiwillig, anders als nach Artikel 11 MDR oder Artikel 5 RED, die einen Bevollmächtigten für Hersteller außerhalb der EU vorschreiben. Nach Artikel 18 Absatz 3 hält der Bevollmächtigte die EU-Konformitätserklärung und die technische Dokumentation für die Marktüberwachungsbehörden mindestens zehn Jahre lang bereit (oder für den Unterstützungszeitraum, je nachdem, welcher Zeitraum länger ist), übermittelt auf begründetes Verlangen Informationen und arbeitet bei Maßnahmen zur Abwendung von Risiken zusammen. Artikel 18 Absatz 2 nimmt die materiellen Cybersicherheitspflichten aus Artikel 13 vom Auftrag aus. Abzugrenzen vom Einführer nach Artikel 19. Mehr im Erklärartikel zu Artikel 18 unter /de/bevollmaechtigter-cra.

CRA-Rolle

C

CE-Kennzeichnung

Europäisches Konformitätszeichen, das die Einhaltung der EU-Gesetzgebung anzeigt. Unter CRA müssen Produkte mit digitalen Elementen die CE-Kennzeichnung tragen, um legal im EU-Markt verkauft zu werden. Erfordert die Durchführung der Konformitätsbewertung und EU-Konformitätserklärung.

CRA-Anforderung

CRA - Cyberresilienz-Verordnung

EU-Verordnung 2024/2847 zur Festlegung verbindlicher Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (PDEs), die in der Europäischen Union verkauft werden. In Kraft getreten am 10. Dezember 2024. Hauptpflichten gelten ab 11. Dezember 2027. Umfasst Hardware- und Softwareprodukte mit Netzwerkkonnektivität.

EU-Verordnung

CSAF - Gemeinsames Rahmenwerk für Sicherheitshinweise

OASIS-Standard für maschinenlesbare Sicherheitshinweise. Ermöglicht die automatisierte Verarbeitung von Schwachstellenmeldungen. Wird für koordinierte Schwachstellenoffenlegung (CVD) und ENISA-Berichterstattung unter CRA-Anforderungen verwendet.

OASIS-Standard

CSIRT - Computer Security Incident Response Teams

Benannte Cybersicherheitsstellen, denen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Artikel 14 des CRA melden müssen und die sich mit der ENISA bei der Schwachstellenreaktion auf EU-Ebene abstimmen.

CRA-Anforderung

CVD - Koordinierte Offenlegung von Schwachstellen

Prozess zur verantwortungsvollen Offenlegung von Sicherheitslücken gegenüber Anbietern vor der öffentlichen Bekanntgabe. CRA Artikel 13(8) verlangt von Herstellern, CVD-Richtlinien einzuführen und zu veröffentlichen, einschließlich Sicherheitskontaktinformationen.

CRA-Anforderung

CVE - Häufige Schwachstellen und Gefährdungen

Standardisierter Identifikator für öffentlich bekannte Cybersicherheitslücken (z. B. CVE-2024-12345). Verwaltet von MITRE Corporation. Weltweit verwendet für Schwachstellenverfolgung, Offenlegung und Behebungskoordination.

Industriestandard

CVSS - Gemeinsames Bewertungssystem für Schwachstellen

Industriestandard zur Bewertung der Schwachstellenschwere auf einer Skala von 0-10. CVSS 4.0 ist die neueste Version. Bietet Basis-, zeitliche und Umgebungsmetriken. Kritisch (9.0-10.0), Hoch (7.0-8.9), Mittel (4.0-6.9), Niedrig (0.1-3.9).

FIRST.org-Standard

CycloneDX

OWASP-Standard zur Erstellung von Software-Stücklisten (SBOMs) und verwandten Artefakten. Unterstützt SBOM, VEX, HBOM, SaaSBOM und mehr. Version 1.5+ empfohlen. Von BSI TR-03183 als bevorzugtes Format für CRA-Compliance referenziert.

OWASP-Standard

E

ENISA - Agentur der Europäischen Union für Cybersicherheit

EU-Agentur für Cybersicherheitspolitik und Vorfallkoordination. Nach Artikel 14 des CRA melden Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über eine einheitliche Meldeplattform an die ENISA und das koordinierende CSIRT, mit einer Frühwarnung innerhalb von 24 Stunden und einer Folgemeldung innerhalb von 72 Stunden. Die Meldepflicht beginnt am 11. September 2026.

EU-Agentur

EPSS - System zur Vorhersage von Exploit-Wahrscheinlichkeit

FIRST.org-Modell zur Schätzung der Wahrscheinlichkeit (0-100%), dass eine Schwachstelle in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird. Wird für risikobasierte Schwachstellenpriorisierung zusammen mit CVSS verwendet. Höherer EPSS = höhere Priorität für Behebung.

FIRST.org-Standard

EU-Konformitätserklärung

Formelles Dokument, das erklärt, dass ein Produkt die anwendbare EU-Gesetzgebung einschließlich CRA einhält. Muss vom Hersteller oder bevollmächtigten Vertreter unterzeichnet werden. Erforderlich für CE-Kennzeichnung. Muss auf anwendbare harmonisierte Normen verweisen.

CRA-Anforderung

EU-Maschinenverordnung - Verordnung (EU) 2023/1230

EU-Verordnung, die die Maschinenrichtlinie 2006/42/EG ersetzt und ab dem 20. Januar 2027 gilt. Für Maschinen mit digitalen Elementen sind Cybersicherheitsnachweise in der technischen Dokumentation erforderlich (Anhang III §1.1.9 — Schutz vor Korrumpierung). Produkte mit digitalen Elementen müssen gleichzeitig dieser Verordnung und dem CRA entsprechen.

EU-Verordnung

H

Harmonisierte Normen

Europäische Normen, die von anerkannten Normungsorganisationen (CEN, CENELEC, ETSI) verabschiedet und im EU-Amtsblatt referenziert werden. Produkte, die harmonisierten Normen entsprechen, profitieren von einer Konformitätsvermutung mit den entsprechenden wesentlichen CRA-Anforderungen, was die Konformitätsbewertung vereinfacht.

CRA-Konzept

HBOM - Hardware-Stückliste

Maschinenlesbares Inventar von Hardware-Komponenten in einem Produkt, einschließlich Prozessoren, Speicher, integrierte Schaltkreise und Firmware. Ergänzt SBOM für vollständige Produkttransparenz. CycloneDX unterstützt das HBOM-Format.

CycloneDX-Format

Hersteller

Die Einrichtung, die ein Produkt mit digitalen Elementen entwickelt oder herstellt und unter eigenem Namen oder eigener Marke auf dem EU-Markt in Verkehr bringt. Hersteller tragen die Hauptpflichten des CRA: Risikobeurteilungen durchführen, SBOMs pflegen, Schwachstellen behandeln, Sicherheitsupdates für mindestens fünf Jahre bereitstellen und ausgenutzte Schwachstellen an die ENISA melden.

CRA-Rolle

I

Importeur

Eine in der EU ansässige Einrichtung, die ein Produkt mit digitalen Elementen eines Herstellers außerhalb der EU auf dem europäischen Markt in Verkehr bringt. Importeure müssen überprüfen, ob der Hersteller die Konformitätsbewertung durchgeführt hat, die CE-Kennzeichnung angebracht ist und die technische Dokumentation verfügbar ist. Sie haften gemeinsam für nicht konforme Produkte.

CRA-Rolle

K

KEV - Bekannte ausgenutzte Schwachstellen

CISAs maßgeblicher Katalog von Schwachstellen, die aktiv in freier Wildbahn ausgenutzt werden. Höchste Priorität für die Behebung, da sie bestätigte reale Bedrohungen darstellen. Bundesbehörden müssen KEV-Schwachstellen innerhalb festgelegter Fristen beheben.

CISA-Katalog

Konformitätsbewertung

Verfahren, das überprüft, ob ein Produkt die wesentlichen Cybersicherheitsanforderungen des CRA erfüllt. Standardprodukte führen eine Selbstbewertung durch (Modul A). Wichtige Produkte der Klasse I können sich ebenfalls selbst bewerten, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein Cybersicherheitszertifizierungsschema vollständig angewendet werden; andernfalls ist eine Bewertung durch Dritte erforderlich. Produkte der Klasse II und kritische Produkte erfordern eine Bewertung durch Dritte (Modul B+C oder Modul H) oder ein europäisches Cybersicherheitszertifizierungsschema.

CRA-Anforderung

Kritisches Produkt (Anhang IV) - CRA Anhang IV

Produkte mit digitalen Elementen, die wesentliche Cybersicherheitsfunktionen für andere Produkte, Netzwerke oder Dienste erfüllen. In CRA Anhang IV aufgeführt, umfassen diese Hardware-Sicherheitsmodule (HSMs), Smartcard-Leser, sichere Elemente und Hardwaregeräte mit Sicherheitsboxen. Kritische Produkte erfordern eine europäische Cybersicherheitszertifizierung gemäß einem anwendbaren Schema oder — falls kein Schema existiert — eine Konformitätsbewertung durch Dritte bei einer benannten Stelle.

Klassifizierung übernehmen

N

NVD - Nationale Schwachstellendatenbank

US-Regierungs-Repository für Schwachstellendaten, gepflegt von NIST. Aufgebaut auf CVE-Identifikatoren. Bietet CVSS-Scores, CPE-Informationen (betroffenes Produkt), CWE-Klassifizierungen und Behebungshinweise.

NIST-Datenbank

O

OSV.dev - Open-Source-Schwachstellendatenbank

Open Source Vulnerability database maintained by Google. Aggregates security advisories from GitHub (GHSA), Go, Rust, PyPI, and 15+ ecosystems into a single queryable API. CRA Evidence uses OSV.dev as one of its vulnerability sources to catch advisories that ecosystem-specific databases track before they receive CVE IDs.

Vulnerability Database

P

PDE - Produkt mit digitalen Elementen

Ein Produkt mit digitalen Elementen ist Hard- oder Software, die auf dem EU-Markt bereitgestellt wird und deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem anderen Gerät oder Netz umfasst. Die rechtliche Definition findet sich in Artikel 3 Nummer 1 des CRA. Der CRA unterscheidet vier Formen: Softwareprodukte (Artikel 3 Nummer 4), Hardwareprodukte (Artikel 3 Nummer 5), separat in Verkehr gebrachte Komponenten (Artikel 3 Nummer 6, einschließlich Firmware und SDKs) und vom Hersteller bereitgestellte Datenfernverarbeitungslösungen (Artikel 3 Nummer 2, Cloud- oder Ferndienste, die für die Funktion des Produkts erforderlich sind). Ein reines Cloud-SaaS ohne installierbaren Client fällt in der Regel nicht unter den CRA; ein hybrides Produkt, bei dem der Cloud-Dienst des Herstellers für die Funktion des Produkts erforderlich ist, fällt über Artikel 3 Nummer 2 in den Anwendungsbereich. Der entscheidende Test ist die Datenverbindung, und Artikel 3 Nummer 8, 9 und 10 unterscheidet logische, physische und indirekte Verbindungen.

CRA-Definition

prEN 50742

Europäischer Normentwurf für die Sicherheit von Maschinen zum Schutz vor Korrumpierung. Enthält technische Spezifikationen zur Umsetzung von §1.1.9 der Maschinenverordnung (EU) 2023/1230. Definiert zwei Konformitätspfade: eigenständiger Ansatz und Integration mit IEC 62443 für Hersteller, die bereits in diesem industriellen Cybersicherheitsrahmen arbeiten. Nach der Veröffentlichung als harmonisierte Norm schafft die Konformität eine Konformitätsvermutung hinsichtlich der Cybersicherheitsanforderungen der Maschinenverordnung. Veröffentlichung für Ende 2026 erwartet.

Normentwurf

PURL - Paket-URL

Standardisiertes Format zur Identifizierung von Softwarepaketen über Ökosysteme hinweg (z. B. pkg:npm/lodash@4.17.21). Wird in SBOMs zur eindeutigen Identifizierung von Komponenten verwendet. Ermöglicht automatisiertes Schwachstellenmatching und Lizenzcompliance.

Industriestandard

R

RDPS - Fernverarbeitungslösungen für Daten

Cloud- oder SaaS-Funktionalität, die als Teil eines Produkts mit digitalen Elementen Daten aus der Ferne verarbeitet. Sie fällt in den Anwendungsbereich der CRA-Konformitätsbewertung des Produkts, wenn sie einen dreiteiligen Test erfüllt: Die Daten werden 'aus der Ferne' verarbeitet, das Produkt würde ohne sie eine Kernfunktion verlieren, und sie wird vom Hersteller oder unter seiner Verantwortung konzipiert. SaaS von Dritten, das diesen Test nicht besteht, muss dennoch im Rahmen der Sorgfaltspflicht nach Artikel 13 Absatz 5 als Komponente behandelt werden.

CRA-Anforderung

Risikobewertung

Systematischer Prozess zur Identifizierung, Analyse und Bewertung von Cybersicherheitsrisiken im Zusammenhang mit einem Produkt mit digitalen Elementen. Vorgeschrieben durch CRA Artikel 13(2) und muss in der technischen Dokumentation dokumentiert werden. Umfasst Bedrohungen, Schwachstellen, potenzielle Auswirkungen und Risikominderungsmaßnahmen über den gesamten Produktlebenszyklus.

CRA-Anforderung

S

SBOM - Software-Stückliste

Formales, maschinenlesbares Inventar von Softwarekomponenten und Abhängigkeiten, einschließlich Versionen, Lizenzen und Beziehungen. Erforderlich durch CRA Artikel 13(4) für Schwachstellenmanagement und Lieferkettentransparenz. Kann im CycloneDX- oder SPDX-Format sein.

CRA-Anforderung TR-03183

SCA - Software Composition Analysis

Software Composition Analysis (SCA) identifiziert Open-Source- und Drittanbieterkomponenten, Versionen, Lizenzen und bekannte Schwachstellen in einem Softwareprodukt. Sie wird häufig genutzt, um SBOMs zu erzeugen, über Releases hinweg aktuell zu halten und die Schwachstellenüberwachung nach CRA Artikel 13 zu speisen.

Industriestandard

SPDX - Software-Paketdatenaustausch

ISO/IEC 5962:2021 Standard zur Kommunikation von Software-Stücklisteninformationen. Entwickelt von der Linux Foundation. Weit verbreitet für Lizenzcompliance und Schwachstellenverfolgung. Version 2.2.1+ empfohlen für CRA-Compliance.

ISO-Standard

Standardprodukt

Produkte mit digitalen Elementen, die nicht unter die in den CRA-Anhängen III und IV definierten Kategorien „Wichtig“ oder „Kritisch“ fallen. Standardprodukte können die Konformitätsbewertung durch interne Kontrolle (Selbstbewertung) des Herstellers gemäß CRA Anhang VIII ohne Beteiligung Dritter durchlaufen. Dies umfasst die überwiegende Mehrheit kommerzieller Software und Hardware.

Klassifizierung übernehmen

T

Technische Dokumentation

Vollständiges Dokumentationspaket zum Nachweis der CRA-Konformität. Umfasst Risikobewertung, SBOM, Sicherheitsdesign-Dokumentation, Schwachstellenbehandlungsverfahren, Testergebnisse und EU-Konformitätserklärung. Muss 10 Jahre oder die Produktlebensdauer aufbewahrt werden (je nachdem, was länger ist).

CRA-Anforderung

TR-03183

Technische Richtlinie des deutschen BSI (Bundesamt für Sicherheit in der Informationstechnik) mit detaillierten Anforderungen für die SBOM-Erstellung und -Verwaltung. Weithin als Best Practice für die Einhaltung von CRA Artikel 13 referenziert. Spezifiziert minimale SBOM-Felder, Formate und Aktualisierungsanforderungen.

BSI-Richtlinie

V

Vertriebspartner

Jede Einrichtung in der Lieferkette, die nicht Hersteller oder Importeur ist und ein Produkt mit digitalen Elementen auf dem EU-Markt bereitstellt. Händler müssen vor der Bereitstellung prüfen, ob das Produkt die CE-Kennzeichnung trägt und die EU-Konformitätserklärung beigefügt ist. Wenn ein Händler das Produkt verändert, wird er nach dem CRA zum Hersteller.

CRA-Rolle

VEX - Austausch zur Ausnutzbarkeit von Schwachstellen

Dokument, das den Ausnutzbarkeitsstatus von Schwachstellen in einem bestimmten Produkt kommuniziert. Gibt an, ob ein CVE Ihr Produkt betrifft (betroffen, nicht betroffen, behoben, in Untersuchung). Hilft nachgelagerten Benutzern, Alert-Fatigue durch Fehlalarme zu reduzieren.

CycloneDX/CSAF-Format

VKB - Schwachstellen-Wissensdatenbank

A continuously updated vulnerability database that aggregates advisories from multiple sources, such as the CVE List (cvelistV5), OSV.dev, CISA KEV, EPSS, and ENISA EUVD, into a single queryable knowledge base. Instead of scanning dependencies on demand against a single source, a VKB maintains a local mirror of all known vulnerabilities and matches them against software components as new CVEs are published. This reduces detection latency from hours or days to minutes, and cross-referencing multiple sources lowers the risk of missed advisories.

Schwachstellenmanagement

W

Wichtiges Produkt (Klasse I) - CRA Anhang III, Teil I

Produkte mit digitalen Elementen, die eine cybersicherheitsrelevante Funktion erfüllen oder ein erhöhtes Risiko bergen. Klasse I umfasst Identitätsmanagementsysteme, VPNs, Netzwerkmanagement-Tools, SIEM-Systeme, Boot-Manager und andere in CRA Anhang III Teil I aufgeführte Kategorien. Hersteller müssen entweder harmonisierte Normen anwenden, die alle wesentlichen Anforderungen abdecken (was eine Selbstbewertung ermöglicht), oder eine Konformitätsbewertung durch Dritte bei einer benannten Stelle durchlaufen.

Klassifizierung übernehmen

Wichtiges Produkt (Klasse II) - CRA Anhang III, Teil II

Produkte mit digitalen Elementen, die kritische Cybersicherheitsfunktionen erfüllen und ein erhebliches Risiko bergen. Klasse II umfasst Betriebssysteme, Hypervisoren, Firewalls, Intrusion-Detection-Systeme, Mikrocontroller, industrielle Automatisierungssysteme und andere in CRA Anhang III Teil II aufgeführte Kategorien. Diese Produkte erfordern stets eine Konformitätsbewertung durch Dritte bei einer benannten Stelle, unabhängig davon, ob harmonisierte Normen existieren.

Klassifizierung übernehmen

Bereit für die CRA-Compliance?

CRA Evidence hilft Ihnen bei der Verwaltung von SBOMs, der Nachverfolgung von Schwachstellen und der Erstellung prüfungsfertiger Dokumentation.