Häufig gestellte Fragen

Die Klassifizierung richtet sich nach der Kernfunktion des Produkts, nicht nach jeder einzelnen Funktion, die es enthält. Entspricht die Kernfunktion einer in Anhang III genannten Kategorie, ist das Produkt „wichtig“ (Klasse I oder II); entspricht sie Anhang IV, ist es „kritisch“; andernfalls ist es ein „Standardprodukt“. Eine Funktion wie Identitätsmanagement oder ein VPN, die nur als Merkmal enthalten ist, macht das Produkt nicht „wichtig“, sofern dies nicht sein eigentlicher Zweck ist. Treffen mehrere Kategorien zu, gilt die strengere Klasse. Art. 7

Nicht kommerzielle Open-Source-Software, die außerhalb einer Geschäftstätigkeit entwickelt wird, fällt weitgehend nicht in den Anwendungsbereich. Verwalter von Open-Source-Software unterliegen einem leichteren, maßgeschneiderten Pflichtenkatalog. Open-Source-Komponenten, die im Rahmen einer Geschäftstätigkeit bereitgestellt werden, können in den Anwendungsbereich fallen.

Eigenständige Dienste liegen in der Regel außerhalb des CRA. Lösungen zur Datenverarbeitung auf Distanz, die für ein Produkt zur Erfüllung seiner Funktionen erforderlich sind, gelten jedoch als Teil dieses Produkts und fallen in den Anwendungsbereich. Außerhalb des CRA zu stehen bedeutet nicht, unreguliert zu sein: Web- und Cloud-Dienste können unter andere EU-Vorschriften fallen, insbesondere NIS2 (Directive (EU) 2022/2555) für mittlere und große Einrichtungen in erfassten Sektoren sowie die GDPR für personenbezogene Daten. Art. 3(2)

Ja. Die CRA gilt für Produkte, die auf dem EU-Markt in Verkehr gebracht werden, unabhängig davon, wo der Hersteller niedergelassen ist. Hersteller außerhalb der EU müssen sicherstellen, dass ein in der Union niedergelassener Wirtschaftsakteur für die einschlägigen Verpflichtungen verantwortlich ist.

Sie gliedern sich in zwei Teile von Anhang I: Sicherheitseigenschaften, die das Produkt aufweisen muss (sicher in der Standardkonfiguration, Vertraulichkeit, Integrität, Verfügbarkeit, minimierte Angriffsfläche, Sicherheitsupdates), und Prozesse zur Schwachstellenbehandlung, die der Hersteller betreiben muss (SBOM, Behebung, koordinierte Offenlegung). Anhang I

Ja. Hersteller müssen die im Produkt enthaltenen Komponenten ermitteln und dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format. Anhang I · II(1)

Der Unterstützungszeitraum ist die Zeitspanne, in der ein Hersteller Sicherheitsupdates bereitstellen muss. Er muss den Zeitraum widerspiegeln, in dem die Verwendung des Produkts nach vernünftigem Ermessen zu erwarten ist: fünf Jahre als Standard, kürzer, wenn die erwartete Nutzungsdauer kürzer ist, und länger, wenn sie länger ist. Art. 13(8)

Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Sicherheit des Produkts beeinträchtigen, müssen der ENISA und dem zuständigen CSIRT gemeldet werden. Eine Frühwarnung ist innerhalb von 24 Stunden nach Kenntnisnahme fällig, gefolgt von einer ausführlicheren Meldung und einem Abschlussbericht. Art. 14

Die Verordnung ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab September 2026 (21 Monate später) und der Großteil der Pflichten gilt ab Dezember 2027 (36 Monate später). Art. 71

Verstöße gegen die grundlegenden Anforderungen oder die Herstellerpflichten können Geldbußen von bis zu €15 Millionen oder 2,5 % des gesamten weltweiten Jahresumsatzes nach sich ziehen, je nachdem, welcher Betrag höher ist. Für andere Verstöße und für die Übermittlung falscher Angaben gelten niedrigere Obergrenzen.

Ja, seit dem 11. September 2026, dem Tag, an dem die Pflicht nach Art. 14 selbst begann. Die Plattform ist unter portal.cra-srp.enisa.europa.eu in Betrieb; Sie wählen die Rolle „Assigned Representative“ und melden sich mit einem EU-Login-Konto an, für das die Multi-Faktor-Authentifizierung aktiviert ist. Die ENISA hat die Adresse am 10. September 2026 in ihren SRP-FAQ veröffentlicht, zusammen mit einem AR-Benutzerhandbuch und den Nutzungsbedingungen der Plattform. Vier Dinge waren zu diesem Zeitpunkt noch nicht verfügbar: die freiwillige Meldung nach Art. 15, eine Meldeschnittstelle (API), ein Feld für die Kenntnisnahme bei aktiv ausgenutzten Schwachstellen und ein 72-Stunden-Zähler, der ab der Kenntnisnahme und nicht ab der Übermittlung Ihrer Frühwarnung misst, sodass die Uhr auf dem Bildschirm eine Meldung als überfällig anzeigen kann, bevor die gesetzliche Frist abgelaufen ist. Die Plattform läuft derzeit nur auf Englisch. Siehe die Meldeleitfaden. Art. 14 · 16

Der Normungsauftrag M/606 der Kommission wurde 2025 von CEN, CENELEC und ETSI angenommen und umfasst rund 41 Normen (horizontale und produktspezifische). Nach dem Entwurf einer Änderung der Kommission von M/606 vom Juli 2026, der die Fristen für 2026 um zwei Monate verschoben hat, werden die beiden zentralen horizontalen Normen (sichere Entwicklung und Schwachstellenbehandlung) nun bis zum 31. Oktober 2026 erwartet, die vertikalen Produktnormen bis zum 31. Dezember 2026 und die übrigen horizontalen Normen bis zum 30. Oktober 2027, vor der vollständigen Anwendung im Dezember 2027. Die Befolgung einer zitierten harmonisierten Norm begründet eine Konformitätsvermutung. Anhang I

Durchlaufen Sie den für Ihre Produktklasse geltenden Weg der Konformitätsbewertung, stellen Sie die technische Dokumentation zusammen, erstellen und unterzeichnen Sie die EU-Konformitätserklärung und bringen Sie anschließend die CE-Kennzeichnung an. Standardprodukte dürfen eine interne Kontrolle vornehmen; wichtige und kritische Produkte erfordern strengere Verfahren. Art. 28 · 32

Beginnen Sie mit dem CRA Fast Check, um Anwendungsbereich und Klasse zu bestätigen, folgen Sie dem für Ihre Rolle verfassten Leitfaden und nutzen Sie die Konformitätsmatrix, um die grundlegenden Anforderungen bis zur Erledigung nachzuverfolgen.

Die Meldepflichten gemäß Art. 14 werden durchsetzbar. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die einheitliche Meldeplattform an ENISA und das zuständige CSIRT melden. Dies ist die erste der wesentlichen Pflichten des CRA, die in Kraft tritt, weit vor der vollständigen Anwendung am 11. Dezember 2027. Siehe den Meldeleitfaden. Art. 14 · 71

Nein. Nur aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle die die Sicherheit Ihres Produkts beeinträchtigen, sind gemäß Art. 14 meldepflichtig. Schwachstellen, die Sie vor ihrer Ausnutzung finden und beheben, werden über Ihren gewöhnlichen Schwachstellenmanagementprozess abgewickelt, nicht über den Meldekanal. Der Meldeleitfaden legt den Test und die Fristen fest. Art. 14

Über die einheitliche Meldeplattform der ENISA, die seit dem 11. September 2026 unter portal.cra-srp.enisa.europa.eu in Betrieb ist und Ihre Meldung an die ENISA und das zuständige nationale CSIRT weiterleitet. Sie übermitteln innerhalb von 24 Stunden nach Kenntnisnahme eine Frühwarnung, innerhalb von 72 Stunden eine ausführlichere Meldung und einen Abschlussbericht innerhalb von 14 Tagen, nachdem eine Abhilfemaßnahme für eine Schwachstelle verfügbar ist, bzw. innerhalb eines Monats nach der 72-Stunden-Meldung bei einem schwerwiegenden Vorfall. Die Anmeldung erfolgt über EU Login mit Multi-Faktor-Authentifizierung. Siehe die schrittweise Meldeleitfaden. Art. 14 · 16

In der Regel nicht allein dadurch. Der Leitfaden der Kommission stellt klar, dass Software, die auf dem Gerät des Nutzers ausgeführt wird (eine heruntergeladene App, eine Browser-Erweiterung, ein lokal installierter Client), ein Produkt mit digitalen Elementen ist, während eine Webanwendung, die ausschließlich über einen Browser genutzt wird, oder eine Website, die lediglich Informationen darstellt, dies nicht ist. Ein Remote-Dienst ist nur dann erfasst, wenn es sich um eine Datenverarbeitung auf Distanz handelt, die für ein Produkt zur Erfüllung seiner Funktionen erforderlich ist. Außerhalb des CRA zu stehen bedeutet nicht, unreguliert zu sein: Ein reiner Webdienst kann weiterhin unter NIS2 (für mittlere und große Anbieter) und die GDPR fallen. Art. 3 Siehe die Überblick über den Leitfaden der Kommission.

Es kann die Antwort ändern, denn der CRA regelt Produkte, nicht Dienste. Derselbe Code, als installierbare App verpackt (einschließlich eines Builds mit Capacitor, Electron oder Ähnlichem), wird auf dem Gerät des Nutzers ausgeführt und ist ein Produkt mit digitalen Elementen, sodass der CRA gilt. Wird er ausschließlich als Progressive Web App im Browser bereitgestellt, handelt es sich um einen Webdienst, der als Produkt in der Regel nicht unter den CRA fällt; das Backend, mit dem er kommuniziert, ist nur dann erfasst, wenn es sich um eine Datenverarbeitung auf Distanz handelt, die ein Produkt zur Erfüllung seiner Funktionen benötigt. Zwei Vorbehalte: Ein reiner Webdienst ist nicht unreguliert (NIS2 kann für mittlere und große Anbieter gelten, die GDPR für personenbezogene Daten), und die Grenze zwischen Produkt und Dienst kann verschwimmen, weshalb „eine PWA ausliefern“ als Architekturentscheidung und nicht als garantierte Ausnahme zu betrachten ist. Art. 3 Siehe die Überblick über den Leitfaden der Kommission.

Nur wenn das Update eine wesentliche Änderung: eine Änderung, die das Cybersicherheitsrisiko des Produkts in einer Weise verändert, die Ihre Risikobewertung noch nicht abgedeckt hat. Gewöhnliche Sicherheitsupdates sind in der Regel keine wesentlichen Änderungen. Ist ein Update wesentlich, gilt das geänderte Produkt als neu in Verkehr gebracht, und für die betroffenen Teile ist eine neue Konformitätsbewertung erforderlich. Art. 3(30) Der Leitfaden der Kommission legt den Test fest.