CRA Leitfaden: den EU Cyber Resilience Act in 10 Schritten umsetzen

Bevor Sie ein einzelnes Produkt durch den CRA führen, brauchen Sie den Überblick über Ihr gesamtes Portfolio. Dieser CRA Leitfaden beginnt deshalb mit einer Bestandsaufnahme. Listen Sie zuerst alle Produkte auf, die Sie in der EU verkaufen oder anbieten: Hardware, Firmware, Standardsoftware, Apps und Begleit-Apps sowie die zugehörige Remote-Datenverarbeitung. Erfassen Sie außerdem Varianten und Versionen, denn jede neue Produktversion muss die Anforderungen erfüllen.

CRA Leitfaden: Welche Produkte sind im Scope?

Für jedes Produkt prüfen Sie anschließend, ob der CRA gilt. Er erfasst „Produkte mit digitalen Elementen“, die in der EU auf dem Markt bereitgestellt werden und deren Zweckbestimmung oder vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz umfasst (Art. 2). Für diese erste Einordnung genügt die heutige Produktbeschreibung; Schritt 1 schärft die Zweckbestimmung danach je Produkt. Beantworten Sie deshalb vier Fragen:

• Handelt es sich um ein Produkt mit digitalen Elementen, also um Hardware oder Software?
• Umfasst die Zweckbestimmung oder die vorhersehbare Verwendung eine Datenverbindung?
• Stellen Sie das Produkt in der EU auf dem Markt bereit?
• Greift eine Ausnahme?

Ausgenommen sind beispielsweise Bereiche mit eigener Regulierung wie Medizinprodukte, Kraftfahrzeuge und die zivile Luftfahrt. Ebenfalls ausgenommen sind Ersatzteile, die baugleiche Komponenten ersetzen und nach denselben Spezifikationen hergestellt werden (Art. 2 Abs. 6). Reine SaaS-Angebote fallen nicht unter den CRA (gegebenenfalls aber unter NIS2). Eine Remote-Datenverarbeitung, die der Hersteller entwickelt hat und ohne die das Produkt eine Funktion nicht erfüllen kann, gehört dagegen zum Produkt.

Teilen Sie die betroffenen Produkte danach in zwei Gruppen. Produkte, die bereits auf dem Markt sind, unterliegen schon heute den Meldepflichten (Schritt 7). Für Produkte, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, gelten hingegen alle Anforderungen. Maßgeblich ist dabei das einzelne Exemplar: Verkaufen Sie ein bestehendes Produkt nach diesem Stichtag weiter, muss folglich jedes neu in Verkehr gebrachte Stück den CRA erfüllen.

Gap-Analyse: Wo stehen Sie heute?

Für die Produkte im Scope folgt die Gap-Analyse. Sie vergleichen dabei Ihren Ist-Stand mit den Anforderungen des CRA: Sicherheitseigenschaften nach Anhang I Teil I, Schwachstellenmanagement nach Anhang I Teil II, Meldeprozess, Dokumentation und Unterstützungszeitraum. Das Ergebnis ist eine priorisierte Liste offener Punkte. Beginnen Sie am besten mit den Produkten, die schon am Markt sind, denn für sie gelten die Meldepflichten bereits. Darüber hinaus lohnt ein früher Blick auf wichtige und kritische Produkte, weil dort oft eine notifizierte Stelle nötig ist und die Vorlaufzeit entsprechend länger wird.

Halten Sie das Ergebnis schließlich als Roadmap fest: je Produkt die offenen Anforderungen, die Verantwortlichen und einen Zieltermin. Beteiligen Sie dabei von Anfang an Produktmanagement, Entwicklung, Qualitätsmanagement, Vertrieb und Rechtsabteilung, denn der CRA betrifft Prozesse über den gesamten Produktlebenszyklus. Die Roadmap ist folglich die Grundlage für alle weiteren Schritte dieses Leitfadens, die Sie danach Produkt für Produkt durchlaufen.

Für Produkte, die schon auf dem Markt sind, beschreibt der Beitrag CRA für Bestandsprodukte: vier Wege die möglichen Strategien. Eine erste Selbsteinschätzung liefert außerdem der CRA Readiness Check.

Bevor es um Normen, Dokumente oder Meldungen geht, muss zunächst eine Frage sauber beantwortet sein: Wofür ist Ihr Produkt bestimmt? Der CRA nennt das die Zweckbestimmung (engl. intended purpose): die Verwendung, für die ein Produkt laut Hersteller bestimmt ist, einschließlich der besonderen Nutzungsumstände und -bedingungen, so wie er sie in Gebrauchsanleitung, Werbe- oder Verkaufsmaterial, Erklärungen und technischer Dokumentation angibt (Art. 3 Nr. 23). Zusätzlich zählen die vernünftigerweise vorhersehbare Verwendung (Nr. 24) und die vernünftigerweise vorhersehbare Fehlanwendung (Nr. 25).

Warum die Zweckbestimmung so viel entscheidet

Deshalb hat kaum eine Angabe im CRA so viele Folgen:

• Anwendungsbereich: Ob der CRA überhaupt gilt, hängt davon ab, ob die Zweckbestimmung oder die vorhersehbare Verwendung eine Datenverbindung zu einem Gerät oder Netz umfasst (Art. 2).
• Risikobewertung: Sie analysiert die Risiken vor allem auf Grundlage der Zweckbestimmung und der vorhersehbaren Verwendung, etwa der Betriebsumgebung und der zu schützenden Werte (Art. 13 Abs. 3). Ein Sensor im Wohnzimmer hat deshalb ein anderes Risikoprofil als derselbe Sensor in einer Industrieanlage.
• Unterstützungszeitraum: Er spiegelt die voraussichtliche Nutzungsdauer wider; dabei zählen ebenfalls ausdrücklich die Art des Produkts und seine Zweckbestimmung (Art. 13 Abs. 8).
• Datenminimierung: Das Produkt darf zudem nur die Daten verarbeiten, die für seine Zweckbestimmung erforderlich sind (Anhang I Teil I).
• Dokumentation und Nutzerinformation: Die Zweckbestimmung gehört in die technische Dokumentation (Anhang VII) und in die Informationen für Nutzer (Anhang II). Dort müssen Sie zudem auf bekannte oder vorhersehbare Umstände hinweisen, die mit der Zweckbestimmung oder einer vorhersehbaren Fehlanwendung zusammenhängen und zu erheblichen Cybersicherheitsrisiken führen können.
• Wesentliche Änderung: Ändert sich der bestimmungsgemäße Zweck, für den das Produkt geprüft wurde, liegt eine wesentliche Änderung vor, und die Konformität muss neu bewertet werden (Art. 3 Nr. 30). Sicherheitsupdates, die die Zweckbestimmung nicht verändern, gelten dagegen nicht als wesentliche Änderung.

Praxis-Tipp aus dem CRA Leitfaden: Marketing zählt mit

Werbe- und Verkaufsaussagen zählen übrigens mit. Wer ein Consumer-Gerät auf der Website „auch für den industriellen Einsatz“ bewirbt, erweitert damit die Zweckbestimmung und muss die Risikobewertung folglich entsprechend auslegen. Umgekehrt ist die Zweckbestimmung jedoch auch ein Gestaltungshebel: Lässt sich eine Anforderung nicht vollständig erfüllen, kann der Hersteller den Einsatz etwa auf vertrauenswürdige Umgebungen beschränken, wie es die Erwägungsgründe des CRA ausdrücklich nennen. Eine zu weit gefasste Zweckbestimmung macht die Umsetzung teuer, eine zu enge lässt hingegen Risiken außen vor. Legen Sie sie deshalb bewusst und konkret fest und stimmen Sie sie zwischen Produktmanagement, Entwicklung und Marketing ab. Aus diesem Grund steht sie in diesem CRA Leitfaden gleich nach der Bestandsaufnahme.

Schritt 0 hat gezeigt, welche Produkte unter den CRA fallen. Je Produkt folgen nun zwei Fragen: Welche Rolle haben Sie, und wie weisen Sie die Einordnung nach? Der CRA unterscheidet Hersteller (Art. 13), Importeur (Art. 19) und Händler (Art. 20). Hersteller außerhalb der EU können zudem einen EU-Bevollmächtigten benennen (Art. 18). Wer ein Produkt unter eigenem Namen vertreibt oder wesentlich verändert, übernimmt die Herstellerpflichten (Art. 21 und 22). Für Open-Source-Software gibt es darüber hinaus die eigene Rolle des „Open-Source-Software-Stewards“ (Art. 24).

Halten Sie außerdem je Produkt schriftlich fest, warum es unter den CRA fällt oder nicht, und begründen Sie das mit der Zweckbestimmung aus Schritt 1. Aus der Triage in Schritt 0 wird so ein belastbarer Nachweis gegenüber Marktüberwachung und Kunden. Für diesen CRA Leitfaden gehen wir im Folgenden von der Herstellerrolle aus.

Die Produktklasse entscheidet schließlich über den Konformitätsweg. Der CRA unterscheidet:

• Standardprodukte (die große Mehrheit): Selbstbewertung durch den Hersteller möglich.
• Wichtige Produkte der Klasse I (Anhang III), beispielsweise Passwort-Manager, Router, Betriebssysteme, Smart-Home-Produkte mit Sicherheitsfunktion.
• Wichtige Produkte der Klasse II (Anhang III), beispielsweise Hypervisoren, Firewalls, Intrusion-Detection-Systeme, manipulationssichere Mikroprozessoren.
• Kritische Produkte (Anhang IV), beispielsweise Hardware-Geräte mit Sicherheitsboxen, Smart-Meter-Gateways und Smartcards.

Was genau unter die Kategorien fällt, beschreibt im Detail die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 mit technischen Beschreibungen zu Anhang III und IV (Art. 7 und 8).

Welche Produkte in welche Kategorie fallen, zeigt der CRA Online-Check anhand konkreter Beispiele.

Das Herzstück des CRA ist die Risikobewertung nach Art. 13 Abs. 2 und 3. Der Hersteller bewertet die Cybersicherheitsrisiken seines Produkts und berücksichtigt das Ergebnis in Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung. Ziel ist es, Risiken zu minimieren, Sicherheitsvorfälle zu verhindern und deren Auswirkungen so gering wie möglich zu halten, auch für Gesundheit und Sicherheit der Nutzer. Deshalb gilt: Wenn Sie aus diesem CRA Leitfaden nur einen Schritt sehr gründlich umsetzen, dann diesen.

Was die Risikobewertung enthalten muss

Art. 13 Abs. 3 und 4 legen den Mindestinhalt fest:

• Risikoanalyse: auf Grundlage der Zweckbestimmung und der vorhersehbaren Verwendung, etwa der Betriebsumgebung und der zu schützenden Werte, unter Berücksichtigung der voraussichtlichen Nutzungsdauer.
• Anwendbarkeit der Anforderungen: für jede Sicherheitsanforderung aus Anhang I Teil I Nummer 2 die Angabe, ob sie anwendbar ist und wie Sie sie umsetzen.
• Angemessenes Schutzniveau: wie Sie Anhang I Teil I Nummer 1 anwenden, also ein den Risiken angemessenes Cybersicherheitsniveau sicherstellen.
• Schwachstellenbehandlung: wie Sie die Anforderungen aus Anhang I Teil II umsetzen.
• Begründung: Ist eine grundlegende Anforderung nicht anwendbar, gehört eine klare Begründung in die technische Dokumentation.

Die Bewertung ist außerdem Teil der technischen Dokumentation (Art. 31, Anhang VII). Bei Hochrisiko-KI-Systemen, die zusätzlich unter den AI Act fallen, kann sie zudem Teil der dort geforderten Risikobewertung sein (Art. 13 Abs. 4).

CRA Leitfaden: Risikobewertung mit Threat Modeling

Der CRA schreibt keine bestimmte Methode vor. In der Praxis hat sich jedoch Threat Modeling bewährt, denn es übersetzt die Vorgaben aus Art. 13 und Anhang I in einen wiederholbaren Prozess. Dabei beantworten Sie vier Leitfragen:

• Woran arbeiten wir?
• Was kann schiefgehen?
• Was tun wir dagegen?
• Haben wir gründlich genug gearbeitet?

Methoden wie STRIDE, LINDDUN (Datenschutz) oder PASTA beleuchten dabei unterschiedliche Blickwinkel. Welche Sie wählen, ist zweitrangig. Entscheidend ist, dass Sie das gesamte System betrachten und keinen kritischen Bereich übersehen. So gehen Sie konkret vor:

1. System modellieren: Erstellen Sie ein Datenflussdiagramm mit externen Akteuren, Prozessen, Datenspeichern, Datenflüssen und Vertrauensgrenzen. Dazu gehören auch Begleit-Apps und die Datenverarbeitung aus der Ferne.
2. Schützenswerte Werte bestimmen: etwa personenbezogene Daten, Zugangsdaten, Firmware und sicherheitsrelevante Funktionen.
3. Bedrohungen ermitteln: Prüfen Sie jedes Element systematisch. Besonders ergiebig sind Stellen, an denen Identitäten entstehen, sensible Daten liegen oder das Vertrauensniveau wechselt.
4. Risiken einstufen: Bewerten Sie Auswirkung und Eintrittswahrscheinlichkeit. Berücksichtigen Sie dabei bereits umgesetzte Maßnahmen.
5. Maßnahmen ableiten: Mindern Sie jedes Risiko, bis das Restrisiko angemessen ist, und begründen Sie diese Entscheidung.
6. Anhang I zuordnen: Halten Sie für jede Anforderung fest, ob sie anwendbar ist und wie Sie sie umsetzen.

Beispiel: von der Bedrohung zur Anforderung aus Anhang I

Nehmen wir ein vernetztes Gerät mit Anmeldedienst. Nutzer melden sich über HTTPS an, und die Zugangsdaten liegen in einer Datenbank. Das Modell zeigt drei Elemente: den Nutzer als externen Akteur, den Anmeldedienst als Prozess und die Datenbank als Datenspeicher. Verbunden sind sie über den Datenfluss der Anmeldung. Daraus ergeben sich drei typische Bedrohungen:

Genau diese Kette aus Bedrohung, Maßnahme, Anforderung und technischer Dokumentation prüfen Konformitätsbewertungsstellen und Marktüberwachungsbehörden später. Umgekehrt gilt ebenso: Besteht ein Risiko aufgrund von Architektur, Zweckbestimmung oder Einsatzumgebung nicht, ist die zugehörige Maßnahme nicht erforderlich. Dann dokumentieren Sie nachvollziehbar, warum die Anforderung nicht anwendbar ist. So vermeiden Sie unnötige Komplexität und bleiben trotzdem konform.

Threat Modeling im Entwicklungsprozess verankern

Threat Modeling ist keine einmalige Übung, sondern Teil Ihres sicheren Entwicklungsprozesses (Secure SDLC). Erstellen Sie das Modell beim Architekturentwurf. Aktualisieren Sie es danach bei größeren Features und vor jedem Release. Neue Schnittstellen, ein anderes Hosting oder geänderte Komponenten von Dritten sind ebenfalls ein Anlass für ein Update. Bewerten Sie in diesen Fällen die Risiken neu und prüfen Sie, ob die Maßnahmen noch ausreichen. Wiederverwendbare Vorlagen und ein gemeinsames Vokabular im Team helfen dabei spürbar.

Komponenten von Dritten und laufende Aktualisierung

Beziehen Sie außerdem Komponenten von Dritten ein, einschließlich Open-Source-Software. Hersteller müssen bei der Integration die gebotene Sorgfalt walten lassen, damit solche Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen (Art. 13 Abs. 5). Entdecken Sie eine Schwachstelle in einer Komponente, melden Sie sie zudem dem Hersteller oder Maintainer dieser Komponente (Art. 13 Abs. 6). Die Risikobewertung ist schließlich kein einmaliges Dokument. Sie wird während des Unterstützungszeitraums dokumentiert und bei Bedarf aktualisiert, etwa nach neuen Schwachstellen, Hinweisen Dritter oder Produktänderungen (Art. 13 Abs. 3 und 7).

Eine ausführliche Anleitung zur Methode finden Sie im CRA Threat Modeling Leitfaden.

Anhang I Teil I listet die Sicherheitsanforderungen an das Produkt selbst. Dieser CRA Leitfaden nennt die wichtigsten:

• Auslieferung ohne bekannte ausnutzbare Schwachstellen und mit sicherer Standardkonfiguration
• Sicherheitsupdates, wo sinnvoll automatisch als Standardeinstellung mit einfacher Abschaltmöglichkeit
• Schutz vor unbefugtem Zugriff durch Authentifizierung und Zugriffskontrolle
• Vertraulichkeit und Integrität von Daten, Datenminimierung
• minimierte Angriffsfläche und Protokollierung sicherheitsrelevanter Ereignisse
• sichere Löschung von Daten und Einstellungen durch den Nutzer

Harmonisierte Normen, die eine Konformitätsvermutung auslösen, erarbeiten CEN, CENELEC und ETSI derzeit; im Amtsblatt ist allerdings noch keine veröffentlicht (Stand September 2026). Bis dahin hilft deshalb das CRA Requirements Standards Mapping von ENISA und JRC, das jede Anforderung bestehenden Normen, etwa der Reihe IEC 62443, gegenüberstellt.

Wie die offiziellen Auslegungshilfen der Kommission die Anforderungen konkretisieren, ordnet der Beitrag CRA Leitlinien erklärt ein.

CRA Leitfaden: Informationen und Anleitungen für Nutzer (Anhang II)

Neben den technischen Anforderungen verlangt der CRA außerdem Informationen und Anleitungen für Nutzer. Sie liegen dem Produkt in Papierform oder elektronisch bei (Art. 13 Abs. 18). Anhang II legt dafür den Mindestinhalt fest:

• Name, Postanschrift, E-Mail-Adresse und gegebenenfalls Website des Herstellers
• die zentrale Kontaktstelle für Schwachstellenmeldungen und das Konzept zur koordinierten Offenlegung von Schwachstellen
• Name, Typ und weitere Angaben zur eindeutigen Identifizierung des Produkts
• Zweckbestimmung, Sicherheitsumfeld, Hauptfunktionen und Sicherheitseigenschaften
• bekannte oder vorhersehbare Umstände, die zu erheblichen Cybersicherheitsrisiken führen können, auch bei vorhersehbarer Fehlanwendung
• gegebenenfalls die Internetadresse der EU-Konformitätserklärung
• Art der technischen Sicherheitsunterstützung und Enddatum des Unterstützungszeitraums
• Anleitungen zur sicheren Inbetriebnahme und Nutzung, zur Installation von Sicherheitsupdates, zum Abschalten automatischer Updates und zur sicheren Außerbetriebnahme mit Löschung der Nutzerdaten
• Hinweise, wie sich Änderungen am Produkt auf die Datensicherheit auswirken können
• bei Produkten zur Integration: Informationen, mit denen der Integrator Anhang I und Anhang VII erfüllen kann
• falls Sie die SBOM für Nutzer bereitstellen: wo sie abrufbar ist

Die Angaben müssen klar, verständlich und in einer Sprache verfasst sein, die Nutzer und Marktüberwachungsbehörden leicht verstehen. Außerdem stellen Sie sie mindestens zehn Jahre oder für die Dauer des Unterstützungszeitraums bereit, je nachdem, was länger ist. Dieser CRA Leitfaden empfiehlt deshalb, die Nutzerinformation von Anfang an einzuplanen. Viele Inhalte ergeben sich direkt aus Zweckbestimmung, Risikobewertung und Schwachstellenprozess.

Anhang I Teil II verlangt einen dauerhaften Prozess für Schwachstellen. Dazu gehört eine Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten erfasst. Außerdem verlangt der CRA zeitnahe Behebung durch Sicherheitsupdates, regelmäßige Tests, eine Richtlinie zur koordinierten Offenlegung (CVD) und eine Kontaktadresse für Schwachstellenmeldungen. Behobene Schwachstellen sind außerdem öffentlich zu dokumentieren.

Hersteller müssen darüber hinaus einen Unterstützungszeitraum festlegen, in dem sie Schwachstellen behandeln und Sicherheitsupdates liefern (Art. 13 Abs. 8). Er muss der erwarteten Nutzungsdauer entsprechen, die sich aus der Zweckbestimmung ergibt, und beträgt mindestens fünf Jahre, es sei denn, das Produkt wird kürzer genutzt. Das Enddatum (mindestens Monat und Jahr) muss zudem beim Kauf klar angegeben sein. Jedes Sicherheitsupdate muss nach seiner Veröffentlichung mindestens zehn Jahre oder für den Rest des Unterstützungszeitraums verfügbar bleiben, je nachdem, was länger ist.

Welche Pflichten bei einer gemeldeten Schwachstelle im Detail gelten, beschreibt der Beitrag CRA Schwachstellenmeldung.

Seit dem 11. September 2026 gilt Art. 14, und zwar für alle Produkte im Anwendungsbereich, auch für solche, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Folglich ist es der einzige Schritt dieses CRA Leitfadens, der schon heute verbindlich gilt. Konkret gibt es zwei getrennte Meldewege über die Single Reporting Platform (SRP) von ENISA; jede Meldung geht dadurch gleichzeitig an das koordinierende CSIRT Ihres Mitgliedstaats und an ENISA.

Wichtig ist außerdem: Die Fristen laufen ab dem Zeitpunkt, an dem der Hersteller Kenntnis erlangt. Darüber hinaus müssen Sie betroffene Nutzer über die Schwachstelle oder den Vorfall und mögliche Abhilfemaßnahmen informieren (Art. 14 Abs. 8). Unter welchen Bedingungen die Weitergabe einer Meldung an andere CSIRTs aus Cybersicherheitsgründen aufgeschoben werden kann, regelt die Delegierte Verordnung (EU) 2026/881. Antworten auf Detailfragen gibt schließlich die SRP-FAQ von ENISA.

Wann die Uhr zu laufen beginnt, klärt der Beitrag CRA-Meldefristen und Kenntnisnahme.

Alle bisherigen Schritte dieses CRA Leitfadens münden schließlich in die technische Dokumentation. Sie muss vor dem Inverkehrbringen vorliegen (Art. 31, Anhang VII). Sie umfasst Produktbeschreibung, Entwurf und Architektur, Risikobewertung, angewandte Normen, Schwachstellenprozess, Testberichte und Konformitätserklärung. Dazu gehört zudem die SBOM, die Sie der Marktüberwachung auf Verlangen vorlegen. Dazu kommen die Informationen und Anleitungen für Nutzer nach Anhang II aus Schritt 5. Alle Unterlagen sind zehn Jahre oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, was länger ist (Art. 13 Abs. 13).

Wie das in der Praxis aussieht, zeigt das durchgerechnete Beispiel CRA Compliance in der Praxis.

Welches Verfahren gilt, hängt von der Produktklasse ab (Art. 32, Anhang VIII). Hier zahlt sich folglich die Klassifizierung aus Schritt 3 dieses CRA Leitfadens aus:

• Standardprodukte: interne Kontrolle durch den Hersteller (Modul A); die strengeren Verfahren stehen ebenfalls offen.
• Wichtige Produkte Klasse I: Modul A nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder einer europäischen Cybersicherheitszertifizierung (mindestens Stufe „substanziell“); sonst EU-Baumusterprüfung (Modul B + C) oder umfassende Qualitätssicherung (Modul H).
• Wichtige Produkte Klasse II: Modul B + C oder Modul H mit einer notifizierten Stelle, oder eine europäische Cybersicherheitszertifizierung (mindestens Stufe „substanziell“).
• Kritische Produkte: europäische Cybersicherheitszertifizierung, sofern vorgeschrieben, sonst wie Klasse II.

Die Wege im Detail vergleicht der Beitrag CRA Konformitätsbewertung. Welche Rolle notifizierte Stellen und das BSI dabei spielen, lesen Sie unter CRA notifizierte Stelle und BSI.

Die Regeln zu notifizierten Stellen (Kapitel IV) gelten übrigens bereits seit dem 11. Juni 2026. Wie sich das EU-Zertifizierungsschema EUCC einfügt, erläutert ENISA in CRA implementation via EUCC.

Nach erfolgreicher Bewertung stellt der Hersteller schließlich die EU-Konformitätserklärung aus (Art. 28, Anhang V) und bringt die CE-Kennzeichnung an (Art. 30). Damit ist die Arbeit jedoch nicht beendet: Jede wesentliche Änderung, etwa eine neue Funktion, die das Risikoprofil verändert, oder eine geänderte Zweckbestimmung, kann eine neue Konformitätsbewertung auslösen. Sicherheitsupdates, die die Zweckbestimmung nicht verändern, gelten hingegen nicht als wesentliche Änderung. Am Ende des CRA Leitfadens steht deshalb ein dauerhafter Prozess, kein einmaliges Projekt.

Wann genau eine wesentliche Veränderung vorliegt und wie der Unterstützungszeitraum damit zusammenhängt, vertieft der Beitrag Wesentliche Veränderung und Unterstützungszeitraum.