Produkte müssen bereits in der Entwicklungsphase so gestaltet werden, dass grundlegende Sicherheitsanforderungen erfüllt sind, bekannte Schwachstellen vermieden werden und der Einsatz veralteter oder unsicherer Komponenten ausgeschlossen ist. Dazu gehören Prinzipien wie „Security by Design“ und „Security by Default“. Hierbei muss bei der Integration von Drittanbieter-Komponenten eine ausführliche Due-Diligence-Prüfung erfolgen.

Die Erkennung, Bewertung und Beseitigung von Schwachstellen muss systematisch in interne Prozesse integriert und durch eine verpflichtende Dokumentation nachvollziehbar sichergestellt werden. Das Schwachstellenmanagement muss über den gesamten Supportzeitraum des Produktes betrieben werden.

Hersteller sind verpflichtet für ihre Produkte eine Software-Stückliste (SBOM) zu erstellen. Diese dient als detaillierte Inventarliste der eingesetzten Komponenten und ist ein wesentliches Werkzeug zur Unterstützung des Schwachstellenmanagements.

Bevor ein Produkt auf den Markt gebracht wird, müssen Hersteller Konformitätsbewertungsverfahren durchführen, um bei erfolgreichem Abschluss die EU-Konformitätserklärung ausstellen sowie die CE-Kennzeichnung an dem Produkt anbringen zu können.

Erfasste Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen über eine zentrale Meldeplattform an das nationale Computer Security Incident Response Team (CSIRT) sowie der European Union Agency for Cybersecurity (ENISA) gemeldet werden. Wie die Meldewege konkret ausgestaltet sind, wird im weiteren Verlauf dieses Whitepapers beleuchtet.

Hersteller sind verpflichtet, während des Supportzeitraums ihrer Produkte regelmäßig Sicherheitsupdates bereitzustellen und eine leicht zugängliche oder automatisierte Installation zu ermöglichen. Der Supportzeitraum muss klar kommuniziert werden und spiegelt die Dauer der voraussichtlichen Nutzung des Produkts wider - mindestens jedoch fünf Jahre. Wird davon ausgegangen, dass die Nutzungsdauer des Produktes weniger als fünf Jahre beträgt, muss der Supportzeitraum der voraussichtlichen Nutzungsdauer entsprechen.

Verbraucher sind umfassend über die Cybersicher-heitsfunktionen zu informieren. Das beinhaltet die Bereitstellung klarer Hinweise zu bestehenden Risiken und erforderlichen Updates, sowie entsprechende Sicherheitsinformationen in Nutzerhand-büchern zugänglich zu machen.

Die oben genannten Anforderungen sind risikobasiert und abhängig von der Produktkategorie. Je höher das Risiko in der Produktkategorie, desto strenger sind die Anforderungen und desto formaler ist die Konformitätsbewertung. Der CRA unterscheidet dabei drei Produktkategorien ^[4]:

• Standardprodukte umfassen alle Hardware- und Softwareprodukte, die digitale Funktionen enthalten (z. B. Smarte Produkte, Bildverarbeitung, Videospiele etc.). An diese Produkte werden grundlegende Sicherheitsanforderungen gestellt, die durch harmonisierte Normen vorgegeben werden. Die Konformitätsbewertung erfolgt intern durch den Herstellenden.
• Wichtige Produkte werden in Klasse I (Passwortmanager, Betriebssysteme etc.) und Klasse II (Firewalls, Mikroprozessoren etc.) unterteilt und erfüllen entweder zentrale Funktionen für die Cybersicherheit anderer Produkte, Netze oder Dienste oder bergen aufgrund ihrer Funktion ein erhebliches Risiko systematischer, sicherheitssicherheitsoder nutzerbezogener Schäden bei Manipulation oder Missbrauch. Bei wichtigen Produkten ergeben sich zusätzliche Anforderungen an die Dokumentation, Nachweisführung und Schwachstellenbehandlung. Die Konformitätsbewertung muss teilweise extern in Form einer EU-Baumusterprüfung erfolgen.
• Kritische Produkte sind Produkte (z. B. Chipkarten, Smart-Meter-Gateways etc.), deren Sicherheitsmängel zu schwerwiegenden Störungen von kritischen Lieferketten im Binnenmarkt führen können oder eine kritische Abhängigkeit wesentlicher Einrichtungen von der Produktkategorie besteht. Kritische Produkte unterliegen den höchsten Cybersicherheitsanforderungen. Harmonisierte Normen sind anzuwenden und es ist entweder ein Cybersicherheitszertifikat oder eine EU-Baumusterprüfung für die Konformitätserklärung und CE-Kennzeichnung notwendig.

Image

Die folgende Abbildung zeigt eine vereinfachte und praxisorientierte Darstellung des Konformitätsbewertungsverfahrens gemäß CRA auf.

In der Praxis zeigt sich, dass der Großteil der eben dargestellten Anforderungen auf den Herstellern lastet. Hier gilt zu beachten, dass die Definition von Hersteller weit gefasst ist und nicht nur Unternehmen, die Produkte mit digitalen Elementen selbst entwickeln oder herstellen, sondern auch solche, die diese konzipieren, entwickeln oder herstellen lassen und unter eigenem Namen oder eigener Marke vermarkten als Hersteller gelten. Für die übrigen Akteure besteht die Hauptaufgabe in der sorgfältigen Due-Diligence-Prüfung entlang der Lieferkette. Importeure müssen gewährleisten, dass die Hersteller die produktbezogenen Sicherheitsanforderungen sicherstellen und das Produkt die CE-Kennzeichnung trägt. Bei Händlern umfasst die Prüfung der Anforderungserfüllung sowohl Hersteller als auch Importeure. Neben der Prüfung der CE-Kennzeichnung zählen hierzu insbesondere die Angabe der Kontaktdaten auf dem Produkt, die Angabe des Supportzeitraums sowie die Bereitstellung von Sicherheitsinformationen für Verbraucher. Kommen die Akteure ihren Pflichten nicht nach, werden Verstöße gegen den CRA mit Geldbußen von bis zu:

• 5 Millionen Euro oder
• 2,5 % des weltweiten Jahresumsatzes

geahndet. Außerdem müssen die jeweiligen Produkte vom Markt genommen werden [3, 4].

Sobald ein Unternehmen von einer kritischen oder aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erfährt, ist eine erste Information darüber zeitnah über die SRP zu übermitteln. Dieser frühe Schritt dient weniger der Detailanalyse als vielmehr der Frühwarnung. Es soll ein Signal sein, das Behörden und andere potenziell Betroffene dieser Schwachstelle schnell auf potenzielle Risiken aufmerksam macht. Somit können bei Bedarf länderübergreifend andere Akteure informiert werden.

Im Anschluss muss eine detaillierte Bewertung, einschließlich der Meldung, erfolgen, die den Kontext, erste Einschätzungen zur Wirkung und die Einordnung in Produktgruppen beschreibt. Diese Phase spiegelt wider, dass Sicherheit nicht allein ein technisches Ereignis, sondern ein vernetzter Sachverhalt ist, der Entwicklung, Betrieb und Nutzen für alle Beteiligten umfasst.

Sobald sich die Lage geklärt hat und erste Maßnahmen ergriffen wurden, dient ein abschließender Bericht dazu, die Beobachtungen zu konsolidieren und Lehren für künftige Bedrohungen und Risiken zu ziehen. Damit bietet der Meldeweg auch eine lehrende Komponente – er ist weniger ein administrativer Endpunkt als ein Bestandteil eines kontinuierlichen Sicherheitsprozesses.

Image

Diese Stufen zeigen, dass der CRA Meldepflichten nicht als bürokratische Pflicht vorsieht, sondern als moderiertes Informations- und Steuerungsinstrument [4, 7]. Davon profitieren nicht nur die direkt Beteiligten, sondern auch andere Hersteller und Nutzer ähnlicher Produkte. Diese werden auf die Schwachstellen hingewiesen und können rechtzeitig Updates zur Verfügung stellen bzw. gestellt bekommen.

Der eigentliche Mehrwert liegt weniger im Einhalten von Fristen als in der Etablierung eines gemeinsamen Verständnisses von Risiko und Reaktion.

Die Entscheidung Meldungen über eine zentrale EU-Plattform zu kanalisieren, ist kein technokratischer Detailpunkt, sondern Ausdruck eines Paradigmenwechsels. Statt in jedem Mitgliedstaat einzeln zu melden, nutzen Hersteller eine gemeinsame Meldeinstanz, die übergreifend koordiniert:

• Hersteller reichen einen Bericht über die SRP ein
• Nationale CSIRTs werden informiert und können länderübergreifend reagieren
• ENISA aggregiert, analysiert und erleichtert Informationsaustausch

Für KMU bedeutet dies: Sie müssen sich nicht auf unterschiedliche Meldewege in verschiedenen Ländern einstellen, sondern auf einen einheitlichen, gemeinsamen Informationsraum.

Wesentlich für das Verständnis des Meldewegs im CRA ist der Blick auf die Regulatorik-Landschaft insgesamt: Meldepflichten existieren nicht isoliert. Bereits heute sehen andere Regelwerke Meldeprozesse vor, die sich inhaltlich und zeitlich mit den Anforderungen des CRA überlappen oder ergänzen, wobei die folgenden Beispiele nur Auszüge darstellen und keinen vollständigen Überblick über die entsprechenden Meldewege geben.

Die DSGVO fordert die Meldung von Datenschutzverletzungen, wenn ein Risiko für betroffene Personen vorliegt. Im Finanzbereich verlangt DORA die Meldung von ICT-Incidents, die für kritische und wichtige Dienste relevant sind. Die NIS-2-Richtlinie erweitert die Anforderungen an das Incident Reporting für eine Vielzahl von Einrichtungen erheblich und verschärft Fristen sowie Governance-Vorgaben. Auch der EU AI Act wird Meldepflichten für schwerwiegende KI-bezogene Vorfälle vorsehen. Das Ergebnis ist eine kumulierende Erwartung an Unternehmen, mehrere Meldewege gleichzeitig zu verstehen und zu bedienen.

Für viele KMU führt dies zu Unklarheiten darüber, welches Ereignis nach welcher Regulatorik gemeldet werden muss. Hier liegt ein zentraler praktischer wie strategischer Schmerzpunkt: Wenn Meldepflichten getrennt von den zugrunde liegenden Prozessen betrachtet werden, entstehen Silos, Doppelmeldungen und Reaktionsverzögerungen.

Für KMU ist nicht allein das Einhalten einzelner Fristen entscheidend, sondern die Prozessverankerung von Meldungs- und Reaktionslogiken im Unternehmen. Es benötigt einen internen IncidentManagementprozess, welcher Verantwortlichkeiten festlegt, Ereignisse früh erkennt, bewertet und strukturiert aufzubereiten weiß. Ein solcher Ansatz entlastet zugleich im Kontext anderer Regulatorien und macht Meldepflichten zu einem integralen Teil der Sicherheits- und Risikosteuerung. Wer regulatorische Anforderungen übergreifend denkt, reduziert Komplexität und stärkt zugleich seine organisatorische Reife.

Unterstützung bei dem beschriebenen Meldeweg liefern der CRA selbst sowie die Technische Richtlinie (TR)-03183 des BSI [8, 9]. Insbesondere in der Technischen Richtlinie kann nachgelesen werden, wie Hersteller ihrer Pflicht nachgehen können ihre Kunden zu informieren.

• Haben Sie vollständig identifiziert, welche Ihrer Produkte unter den CRA fallen?
• Ist Ihnen bekannt, welche Software- und Hardware-Komponenten (inkl. Open Source) in diesen Produkten enthalten sind?
• Wissen Sie, welche Pflichten sich aus Ihrer Betroffenheit konkret für Ihr Unternehmen ergeben?

Reflexion: Unklare Betroffenheit führt in der Praxis häufig dazu, dass notwendige Maßnahmen zu spät oder unvollständig umgesetzt werden.

• Sind Sicherheitsanforderungen verbindlicher Bestandteil Ihres Entwicklungsprozesses?
• Wird Security bereits in der Design-Phase berücksichtigt?
• Gibt es klare Kriterien, wann ein Produkt als „sicher genug“ gilt?
• Werden sicherheitsrelevante Entscheidungen nachvollziehbar dokumentiert?

Reflexion: Der CRA verschiebt den Fokus von reaktiver Absicherung hin zu „Security by Design“ und „Security by Default“. Unternehmen ohne strukturierte Entwicklungsprozesse stehen hier oft vor grundlegenden Anpassungen.

• Existiert ein definierter Prozess für den Umgang mit Schwachstellen über den gesamten Produktlebenszyklus?
• Werden Sicherheitsupdates zeitnah und zuverlässig bereitgestellt?
• Ist klar geregelt, wer Schwachstellen bewertet, priorisiert und allgemein verantwortet?
• Wissen Sie, wie Sie im Falle einer aktiv ausgenutzten Schwachstelle reagieren müssen?

Reflexion: Viele Organisationen haben technische Lösungen – aber keine klaren Verantwortlichkeiten. Genau hier entstehen im Ernstfall erhebliche Risiken.

• Sind Verantwortlichkeiten für CRA-relevante Themen eindeutig definiert?
• Arbeiten Produktmanagement, Entwicklung, Security und Legal strukturiert zusammen?
• Ist das Thema CRA auf Management-Ebene verankert?

Reflexion: Der CRA ist kein reines IT-Thema. Ohne übergreifende Governance-Struktur lassen sich die Anforderungen kaum nachhaltig erfüllen.

• Können Sie Ihre Sicherheitsmaßnahmen gegenüber Behörden und Kunden nachvollziehbar darlegen?
• Existiert bereits technische Dokumentation, die die CRA-Anforderungen angemessen berücksichtigt?
• Sind Sie vorbereitet auf Rückfragen von Marktaufsichtsbehörden?
• Wissen Sie, welche Nachweise Sie im Zweifel vorlegen müssen?

Reflexion: Nicht die fehlende Sicherheit, sondern die fehlende Nachweisfähigkeit wird häufig zur Herausforderung.

Einordnung der eigenen Situation Wenn Sie mehrere Fragen:

• Mit „Nein“ beantwortet haben - akuter Handlungsbedarf
• Mit „Teilweise“ beantwortet haben - strukturelle Lücken
• Mit „Ja“ beantwortet haben - gute Ausgangsbasis, aber mutmaßlich Detailarbeit notwendig

Der CRA verlangt keine Perfektion, aber nachvollziehbare, belastbare Strukturen.

In der praktischen Umsetzung sehen wir, dass Unternehmen selten an einzelnen technischen Maßnahmen scheitern, sondern an fehlender Transparenz, unklaren Verantwortlichkeiten und fehlender Gesamtarchitektur. Zudem beobachten wir, dass die größte Herausforderung bei der CRAUmsetzung in der nachhaltigen organisatorischen Verankerung liegt. Viele Unternehmen müssen zunächst ein geeignetes Managementsystem etablieren, das klare Verantwortlichkeiten, Entscheidungswege und Kontrollmechanismen schafft. Ohne diese Grundlage bleibt Cybersecurity häufig ein Querschnittsthema, das zwischen Entwicklung, Produktmanagement und Compliance verteilt ist, mit dem Risiko, dass Maßnahmen punktuell umgesetzt werden, jedoch keine konsistente Gesamtsteuerung entsteht.

Zudem sehen wir, dass die Interpretation der CRA-Vorgaben in vielen KMU Unsicherheit auslöst. Anforderungen wie Security-by-Design oder die Verpflichtungen rund um das Schwachstellenmanagement lassen Spielräume offen, die stark vom Produktportfolio und dem jeweiligen Risikoprofil abhängen. Gleichzeitig ist es für KMU schwierig, den tatsächlichen regulatorischen Druck realistisch einzuschätzen, auch weil in vielen Fällen noch Unklarheit darüber besteht, welche Stellen künftig als notifizierende Entitäten auftreten und wie konkret die Konformitätsbewertung in der Praxis ausgestaltet sein wird. Diese Unsicherheit kann dazu führen, dass Umsetzungsinitiativen verzögert werden.

Ein weiterer kritischer Punkt ist die Entwicklung, Anpassung und Dokumentation relevanter Prozesse. Der CRA verlangt nicht nur technische Sicherheits-maßnahmen, sondern vor allem nachvollziehbare Nachweise über den gesamten Produktlebenszyklus hinweg. Viele Unternehmen unterschätzen dabei den Aufwand, Entwicklungs-, Change- und Incident- Managementprozesse so weiterzuentwickeln, dass sie operativ effizient und wirksam durchgeführt werden können.

Des Weiteren fordert der CRA in vielen Organisationen eine kulturelle Entwicklung. Häufig ist noch nicht ausreichend Awareness vorhanden, um Cybersecurity als festen Bestandteil von Produktqualität und Unternehmensverantwortung zu verankern. Erfolgreiche Umsetzung bedeutet daher auch, interne Akzeptanz zu schaffen und Sicherheit als kontinuierlichen Prozess zu etablieren.

Es zeigt sich, dass Unternehmen, die mit der Umsetzung der Anforderungen des CRA pragmatisch starten und die Prozesse iterativ weiterentwickeln, meist schneller messbare Fortschritte erzielen als solche, die aufgrund der Komplexität zunächst in Analysephasen verharren. Eine strukturierte CRAReifegrad- Analyse hilft dabei, Risiken frühzeitig zu erkennen, Maßnahmen zu priorisieren und den CRA pragmatisch umzusetzen. Entscheidend ist, frühzeitig Klarheit zu schaffen, bevor regulatorischer Druck oder Sicherheitsvorfälle zum Treiber werden.

Produkte müssen bereits in der Entwicklungsphase so gestaltet werden, dass grundlegende Sicherheitsanforderungen erfüllt sind, bekannte Schwachstellen vermieden werden und der Einsatz veralteter oder unsicherer Komponenten ausgeschlossen ist. Dazu gehören Prinzipien wie „Security by Design“ und „Security by Default“. Hierbei muss bei der Integration von Drittanbieter-Komponenten eine ausführliche Due-Diligence-Prüfung erfolgen.

Die Erkennung, Bewertung und Beseitigung von Schwachstellen muss systematisch in interne Prozesse integriert und durch eine verpflichtende Dokumentation nachvollziehbar sichergestellt werden. Das Schwachstellenmanagement muss über den gesamten Supportzeitraum des Produktes betrieben werden.

Hersteller sind verpflichtet für ihre Produkte eine Software-Stückliste (SBOM) zu erstellen. Diese dient als detaillierte Inventarliste der eingesetzten Komponenten und ist ein wesentliches Werkzeug zur Unterstützung des Schwachstellenmanagements.

Bevor ein Produkt auf den Markt gebracht wird, müssen Hersteller Konformitätsbewertungsverfahren durchführen, um bei erfolgreichem Abschluss die EU-Konformitätserklärung ausstellen sowie die CE-Kennzeichnung an dem Produkt anbringen zu können.

Erfasste Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen über eine zentrale Meldeplattform an das nationale Computer Security Incident Response Team (CSIRT) sowie der European Union Agency for Cybersecurity (ENISA) gemeldet werden. Wie die Meldewege konkret ausgestaltet sind, wird im weiteren Verlauf dieses Whitepapers beleuchtet.

Hersteller sind verpflichtet, während des Supportzeitraums ihrer Produkte regelmäßig Sicherheitsupdates bereitzustellen und eine leicht zugängliche oder automatisierte Installation zu ermöglichen. Der Supportzeitraum muss klar kommuniziert werden und spiegelt die Dauer der voraussichtlichen Nutzung des Produkts wider - mindestens jedoch fünf Jahre. Wird davon ausgegangen, dass die Nutzungsdauer des Produktes weniger als fünf Jahre beträgt, muss der Supportzeitraum der voraussichtlichen Nutzungsdauer entsprechen.

Sobald ein Unternehmen von einer kritischen oder aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erfährt, ist eine erste Information darüber zeitnah über die SRP zu übermitteln. Dieser frühe Schritt dient weniger der Detailanalyse als vielmehr der Frühwarnung. Es soll ein Signal sein, das Behörden und andere potenziell Betroffene dieser Schwachstelle schnell auf potenzielle Risiken aufmerksam macht. Somit können bei Bedarf länderübergreifend andere Akteure informiert werden.

Im Anschluss muss eine detaillierte Bewertung, einschließlich der Meldung, erfolgen, die den Kontext, erste Einschätzungen zur Wirkung und die Einordnung in Produktgruppen beschreibt. Diese Phase spiegelt wider, dass Sicherheit nicht allein ein technisches Ereignis, sondern ein vernetzter Sachverhalt ist, der Entwicklung, Betrieb und Nutzen für alle Beteiligten umfasst.

Sobald sich die Lage geklärt hat und erste Maßnahmen ergriffen wurden, dient ein abschließender Bericht dazu, die Beobachtungen zu konsolidieren und Lehren für künftige Bedrohungen und Risiken zu ziehen. Damit bietet der Meldeweg auch eine lehrende Komponente – er ist weniger ein administrativer Endpunkt als ein Bestandteil eines kontinuierlichen Sicherheitsprozesses.

Image

Diese Stufen zeigen, dass der CRA Meldepflichten nicht als bürokratische Pflicht vorsieht, sondern als moderiertes Informations- und Steuerungsinstrument [4, 7]. Davon profitieren nicht nur die direkt Beteiligten, sondern auch andere Hersteller und Nutzer ähnlicher Produkte. Diese werden auf die Schwachstellen hingewiesen und können rechtzeitig Updates zur Verfügung stellen bzw. gestellt bekommen.

Der eigentliche Mehrwert liegt weniger im Einhalten von Fristen als in der Etablierung eines gemeinsamen Verständnisses von Risiko und Reaktion.

Die Entscheidung Meldungen über eine zentrale EU-Plattform zu kanalisieren, ist kein technokratischer Detailpunkt, sondern Ausdruck eines Paradigmenwechsels. Statt in jedem Mitgliedstaat einzeln zu melden, nutzen Hersteller eine gemeinsame Meldeinstanz, die übergreifend koordiniert:

• Hersteller reichen einen Bericht über die SRP ein
• Nationale CSIRTs werden informiert und können länderübergreifend reagieren
• ENISA aggregiert, analysiert und erleichtert Informationsaustausch

Für KMU bedeutet dies: Sie müssen sich nicht auf unterschiedliche Meldewege in verschiedenen Ländern einstellen, sondern auf einen einheitlichen, gemeinsamen Informationsraum.

Wesentlich für das Verständnis des Meldewegs im CRA ist der Blick auf die Regulatorik-Landschaft insgesamt: Meldepflichten existieren nicht isoliert. Bereits heute sehen andere Regelwerke Meldeprozesse vor, die sich inhaltlich und zeitlich mit den Anforderungen des CRA überlappen oder ergänzen, wobei die folgenden Beispiele nur Auszüge darstellen und keinen vollständigen Überblick über die entsprechenden Meldewege geben.

Die DSGVO fordert die Meldung von Datenschutzverletzungen, wenn ein Risiko für betroffene Personen vorliegt. Im Finanzbereich verlangt DORA die Meldung von ICT-Incidents, die für kritische und wichtige Dienste relevant sind. Die NIS-2-Richtlinie erweitert die Anforderungen an das Incident Reporting für eine Vielzahl von Einrichtungen erheblich und verschärft Fristen sowie Governance-Vorgaben. Auch der EU AI Act wird Meldepflichten für schwerwiegende KI-bezogene Vorfälle vorsehen. Das Ergebnis ist eine kumulierende Erwartung an Unternehmen, mehrere Meldewege gleichzeitig zu verstehen und zu bedienen.

Für viele KMU führt dies zu Unklarheiten darüber, welches Ereignis nach welcher Regulatorik gemeldet werden muss. Hier liegt ein zentraler praktischer wie strategischer Schmerzpunkt: Wenn Meldepflichten getrennt von den zugrunde liegenden Prozessen betrachtet werden, entstehen Silos, Doppelmeldungen und Reaktionsverzögerungen.

Für KMU ist nicht allein das Einhalten einzelner Fristen entscheidend, sondern die Prozessverankerung von Meldungs- und Reaktionslogiken im Unternehmen. Es benötigt einen internen IncidentManagementprozess, welcher Verantwortlichkeiten festlegt, Ereignisse früh erkennt, bewertet und strukturiert aufzubereiten weiß. Ein solcher Ansatz entlastet zugleich im Kontext anderer Regulatorien und macht Meldepflichten zu einem integralen Teil der Sicherheits- und Risikosteuerung. Wer regulatorische Anforderungen übergreifend denkt, reduziert Komplexität und stärkt zugleich seine organisatorische Reife.

Unterstützung bei dem beschriebenen Meldeweg liefern der CRA selbst sowie die Technische Richtlinie (TR)-03183 des BSI [8, 9]. Insbesondere in der Technischen Richtlinie kann nachgelesen werden, wie Hersteller ihrer Pflicht nachgehen können ihre Kunden zu informieren.