RED, EN 18031 und CRA Readiness Guide: Praktische Antworten aus dem QIMA Webinar

Der nützlichste Teil des Webinars von QIMA, durch die EU zu navigieren Cybersicherheits-Compliance für Connected Productswar die Q&A.

Hersteller fragten nach Standards, scoping, Produktvarianten, CRA Reporting, Supportzeiten und Dokumentation. Dies sind die Fragen, die auftauchen, wenn RED cyber und CRA beginnen, echte Produkte, das Starten von Timelines und technische Dateien zu beeinflussen.

Dieser Artikel macht diese Fragen in praktische Anleitung für Produkt-, Engineering-, Compliance-, Qualitäts- und Zertifizierungs-Teams.

QIMA hat Cyberexpert für die in diesem Artikel beschriebene Bereitschaftsarbeit gebaut: Skizierung, Anforderungskartierung, Beweisvorbereitung, E. nfo-Support und Expertenüberprüfung, bevor ein Produkt eine formale Bewertung erhält.

Es handelt sich hier um einen Bildungsrückgewinn, nicht um eine Rechtsberatung. Hersteller sollten produktspezifische Verpflichtungen gegenüber dem amtlichen Rechtstext, harmonisierten Normen und ihrem gewählten Konformitätsbewertungsweg überprüfen.

Die wichtigste Lektion: Beginnen Sie nicht mit dem Standard

Ein gängiger Fehler ist, zuerst zu fragen: Welchen Standard sollten wir verwenden?

Das ist in der Logik zu spät.

Die beste erste Frage ist: Was muss dieses Produkt beweisen?

Die Antwort hängt von der Produktgrenze ab, die beabsichtigte Verwendung, Konnektivität, Datenverarbeitung, Assets, Schnittstellen, Kernfunktionalität und ob RED, CRA oder beide angewendet werden.

RED-Cyber-Anforderungen stammen von den Funkgeräterichtlinie und den Cybersicherheitsrelevanten wesentlichen Anforderungen gemäß Artikel 3 Absatz 3 Buchstabe d), (e) und (f), deckt Netzwerkschutzab, Persönliche Daten und Datenschutzund Betrugsschutz. Delegierte Verordnung (EU) 2022/30 aktiviert diese Anforderungen für bestimmte Funkgeräteklassen und Implementing Decision (EU) 2025/138 betrifft harmonisierte Standards zur Unterstützung dieser Anforderungen im Bereich der Netzsicherheit.

CRA ist breiter. Es gilt für Produkte mit digitalen Elementen, die auf den EU-Markt gebracht werden, wenn ihr beabsichtigter Zweck oder vernünftigerweise vorhersehbarer Gebrauch eine direkte oder indirekte logische oder physikalische Datenverbindung zu einem Gerät oder Netzwerk enthält. Darüber hinaus werden Herstellerverpflichtungen von über Entwurf, Entwicklung, Produktion, Wartung, technische Dokumentation, Konformitätsbewertung, Support-Zeiten und Verwundbarkeitsbehandlung hinweg erstellt.

Das bedeutet, dass die erste Lieferung eine produktspezifische Compliance-Karte sein sollte.

Wird die EN 18031 durch EN 40000 ersetzt?

Frage vom Webinar: Wird EN 18031 durch EN 40000 ersetzt werden?

Kurze Antwort: Nicht nötig.

Gergely Bakos erklärte in der Frage&A, dass EN 18031 und die EN 40000 Serie unterschiedliche Tragweite und Reichweite hätten. EN 18031 is central for RED cybersecurity compliance.

Die Hersteller sollten also nicht davon ausgehen, dass die eine Norm die andere einfach ersetzt.

Für ein Radioprodukt im RED Cyber-Bereich kann die EN 18031 nach wie vor der zentrale Weg für RED sein. Aber CRA-Verpflichtungen können zusätzliche Arbeit erfordern, insbesondere im Bereich der Handhabung von Schwachstellen, Reporting, Sicherheitsaktualisierungen und Unterstützungszeitplanung.

Praktischer Einstieg: Standardauswahl sollte der Produktanalyse folgen.

Ein Hersteller sollte in der Lage sein zu erklären:

• warum EN 18031 gilt, oder nicht angewendet wird

• ob EN 40000 Anleitung für zusätzliche CRA-Arbeit benötigt wird

• wo Verwundbarkeitsbehandlung abgedeckt ist

• wo Benachrichtigte Körperbeteiligung benötigt werden kann

• welche Beweise jede Entscheidung unterstützen

Wenn die Antwort nur „EN 18031“ lautet, ist die Standardauswahl nicht ausreichend dokumentiert.

2. RED scoping ist der Ort, wo Hersteller frühzeitig verspätet werden können

Ce<unk> dric Le<unk> vy-Bencheton war einer der praktischsten Bestandteile des Webinars. Sein Punkt war klar:<strong> RED Cyber-Anwendungsbereich ist nicht immer offensichtlich. </strong>

Ein Produkt kann RED-Cyber-Fragen aufwerfen, wenn es über eine drahtlose Schnittstelle und Internetverbindung verfügt auch wenn die Internetverbindung nicht drahtlos ist.

Beispiel 1:

Ein Gerät hat Bluetooth für die Einrichtung und Ethernet für die Netzwerkkommunikation. Das Bluetooth mag lokal sein, aber die Ethernet-Verbindung kann immer noch für RED Cyber-scoping wichtig sein.

Beispiel 2:

Ein Produkt verwendet Zigbee und verbindet sich über ein Gateway oder eine mobile App. „Lokales Radio“ zu nennen, reicht nicht aus. Wenn die App oder das Gateway das Produkt fernsteuern kann, muss die indirekte Konnektivität überprüft werden.

Nützliche Vorbehalte: Die Verarbeitung personenbezogener Daten bedeutet nicht automatisch, dass es in jedem Fall einen Datenschutzeffekt gibt. Ein drahtloses Mikrofon oder Verstärker kann Audio verarbeiten, aber es nicht speichern. Die Datenschutzanalyse hängt immer noch von ab, was das Produkt mit den Daten macht.

Praxis-Spekulationstest

Vor der Entscheidung über den Geltungsbereich sollten die Hersteller vier Fragen beantworten:

1. Hat das Produkt eine Funkschnittstelle?

2. Verfügt das Produkt über direkte oder indirekte Internetverbindungen?

3. Kann ein anderes System, ein app, ein Gateway oder ein Cloud-Service das Produkt steuern?

4. Wird der Produktprozess, die Speicherung oder Weitergabe von Daten, die für den Netzschutz, die Privatsphäre oder den Schutz von Betrug relevant sind, zur Kenntnis genommen?

Eine nützliche Scope Datei sollte ein einfaches Konnektivitätsdiagramm enthalten. Es sollte drahtlose Schnittstellen, kabelgebundene Schnittstellen, mobile Apps, Gateways, Cloud-oder Remote-Verarbeitung, Update-Kanäle und Service-oder Debug-Schnittstellen anzeigen.

Das muss nicht kompliziert sein, sondern muss präzise sein.

3. RED-Risikobewertung und Cybersicherheits-Risikobewertung sind unterschiedliche Dokumente

Frage vom Webinar: EN 18031 bietet keine Risikobewertungsmethodik. Füllt EN 40000 diese Lücke?

Kurze Antwort: teilweise, aber nicht vollständig.

Ce<unk> dric erklärte , dass EN 18031 Entscheidungsbäume und Erwähnungen <strong>STRIDE</strong>enthalten, aber es bietet den Herstellern keine vollständige Methode zur Gefahrenmodellierung oder zur Risikobewertung im Cybersicherheitsbereich. EN 40000-1-2 wurde als Leitfaden für Risikomanagementschritte diskutiert, aber nicht als fertige Methode, die in jede Produktdatei kopiert werden kann.

Die Unterscheidung ist wichtig.

Eine RED-Cyber-Risikobewertung hilft zu ermitteln, welche RED-rechtlichen Anforderungen gelten.

Eine Cybersicherheitsrisikobewertung untersucht das aktuelle Produktrisiko: Benutzer, Daten, Schnittstellen, Belichtungskontext, Einsatzkontext, Angriffsszenarien, Auswirkungen, Kontrollen und Restrisiken.

Das Beispiel von Ce<unk> dric macht das einfach: Die gleiche Kamera kann unterschiedliche Risiken in einem Schlafzimmer, einem Garten oder einem Parkplatz mit sich bringen. Die Hardware könnte ähnlich sein. Der Kontext ist nicht.

Ein schwacher Risikoeintrag sagt:

<unk> Risiko ist gering.

Ein nützlicher Risikoeintrag sagt:

✓ Die Ethernet-Service-Schnittstelle wird nur während der Installation und Wartung in einer kontrollierten physikalischen Umgebung verwendet. Es wird während der normalen Benutzeroperation nicht belichtet. Diese Annahme wird durch die Service-Prozedur, die Schnittstellenkonfiguration und die Installationsdokumentation unterstützt. Basierend auf diesem Nutzungskontext wird die Zugriffskontrolle als nicht anwendbar für dieses Asset und diese Schnittstelle behandelt.

Diese Art des Einstiegs trägt dazu bei, die Entscheidung zu erfassen, einzuhalten und zu beurteilen.

4. EN 18031 ist schwierig, weil sie auf Vermögenswerten basiert

EN 18031 ist keine flache Checkliste. Es fordert die Hersteller auf, in Bezug auf Vermögenswerte, Schnittstellen, Entitäten, Sicherheitsmechanismen, Implementierungskategorien und Entscheidungsbäume zu denken.

Assets können vertrauliche Parameter, sensible Parameter, Funktionen, Datenparameter, Sicherheitsparameter, Netzwerkwerte, Privatsphäre-Assets und finanzielle Vermögenswerte umfassen.

Dies wird schnell produktspezifisch.

Eine sichere Update-Funktion zum Beispiel kann das Abrufen des Updates, das Überprüfen, Installieren, Zurückfahren nach einem Fehler und das Loggen des Ergebnisses umfassen. Ein Hersteller kann entscheiden, diese als eine sichere Updatefunktion zu gruppieren. Das kann vernünftig sein, aber die Gruppierung darf keine Details verbergen, die zur Bewertung wichtig sind.

Ein praktisches Asset Register sollte nur die wichtigen Felder erfassen:

Ist das Asset Register schwach, sind E.Info, E.Just, und die Antworten auf den Entscheidungsbaum ebenfalls schwach.

5. Entscheidungsbäume brauchen Beweise und keine Vermutungen

Für die EN 18031 sind die Entscheidungsbäume von zentraler Bedeutung für die EN 18031. Assessors verwenden sie, um festzustellen, ob das Ergebnis PASSist, FAILoder NICHT ANWENDUNG.

Das bedeutet, dass ein Entscheidungsbaumpfad als Entscheidungsprotokoll dokumentiert werden muss.

Ein Entscheidungsprotokoll sollte antworten:

• welche Anforderung geprüft wurde

• welches Asset und Interface beteiligt waren

• welcher Pfad gefolgt wurde

• warum das Ergebnis PASS, FEHLER oder NICHT ANWENDUNG ist

• welche Beweise das Ergebnis unterstützen

• ob sich diese Entscheidung auf andere Anforderungen auswirkt

Beispiel: Ethernet und sichere Kommunikation

Ce<unk> dric erklärte , dass Ethernet schwierig sein könne, da es in der Regel unverschlüsselt ist und keine eigene Zugriffskontrolle habe. Wenn die Zugriffskontrolle auf diese Ethernet-Schnittstelle zutrifft, können sichere Kommunikationsanforderungen folgen.

Eine schwache Rechtfertigung würde sagen:

<unk> Ethernet wird nur von Technikern verwendet.

Eine stärkere Rechtfertigung würde sagen:

✓ Die Ethernet-Schnittstelle ist nur während der Installation und Wartung in einer kontrollierten physischen Umgebung zugänglich. Sie ist während des normalen Betriebs Endnutzern nicht ausgesetzt. Zugriffsbedingungen sind in der Benutzer- und Servicedokumentation beschrieben. Die Schnittstelle ist deaktiviert oder eingeschränkt außerhalb der Servicebedingungen. Basierend auf diesem Nutzungskontext führt der Entscheidungsbaum des Zugriffskontrollsystems zu KEINEM APPLICABLE für dieses Asset und diese Schnittstelle. Unterstützende Belege werden in den Serviceverfahren, der Schnittstellenkonfiguration und der Dokumentation zur Produktarchitektur zur Verfügung gestellt.

Das ist der Unterschied zwischen einer Annahme und einem bewertungsfähigen Beweis.

6. E.Info und E.Just sollten das Produkt klar erklären

Die EN 18031 Dokumentation ist nicht nur ein Verzeichnis von Produktdokumenten.

Sie muss erklären, was umgesetzt wird, warum es relevant ist, welche Vermögenswerte es schützt. welcher Entscheidungsweg verfolgt wurde und wo die Beweise überprüft werden können.

Ce<unk> dric hob hervor, dass E.Info und E.Just bei der Bewertung verwendet werden, daher benötigen sie Anregungen von Stakeholdern aus den Bereichen Engineering, Entwicklung, Firmware, Produkt und Compliance.

Schwäche Antwort:

<unk> Das Produkt verwendet Verschlüsselung.

Stärkere Antwort:

✓ Das Produkt verwendet TLS 1.3 zur Kommunikation zwischen dem Gerät und dem Cloud-Dienst. Dies schützt übertragene Konfigurationsdaten und Gerätestatusinformationen vor unbefugter Offenlegung und Modifikation. Die Implementierung wird in der Kommunikationsarchitektur beschrieben und im Sicherheitsbericht überprüft. Die Behandlung der Zertifikate wird im Bereich Schlüsselmanagement beschrieben. Referenzen: Architekturdiagramm A-03, Testbericht T-12, Firmware-Konfigurationsextrakt F-07.

Die stärkere Antwort ist besser, weil sie dem Bewerter sagt, was geschützt ist, wie sie geschützt ist, warum sie wichtig ist und wo sie zu überprüfen ist.

7. Produktvarianten können die Arbeit wiederverwenden, aber nur mit einer Begründung

Frage vom Webinar: Wenn Geräte die gleiche Funktionalität aber unterschiedliche Formfaktoren haben, benötigen sie separate Compliance-Prüfungen?

Kurze Antwort: Sie müssen vielleicht nicht bei Null anfangen, aber Sie müssen die Unterschiede beurteilen.

Hersteller sollten mit der Kernfunktionalität des Produkts beginnen. Wenn Varianten die gleiche Kernfunktion haben, können einige Arbeiten wiederverwendet werden. Aber Formfaktorunterschiede können noch immer Auswirkungen auf Cybersicherheitsanforderungen oder CRA-Konformität haben.

Zum Beispiel können eine Karte und ein Ring Firmware und Kernfunktionalität teilen. Aber sie können sich in Bezug auf physische Belichtung, Antennenverhalten, Batteriebeschränkungen, Update-Prozess, Wahrscheinlichkeit von Verlust, Benutzerinteraktion oder Datenschutz unterscheiden.

Eine kurze Wiederverwendungstabelle reicht aus:

Ziel ist es, wiederholte Arbeit zu vermeiden, ohne Nachweise zu kopieren, die nicht dem Produkt passen.

8. CRA-Reporting beginnt vor der vollständigen CRA-Anwendung

Frage vom Webinar: Was ist der praktische Unterschied zwischen September 2026 und Dezember 2027 im Rahmen der CRA?

Kurze Antwort: September 2026 dreht sich um Berichterstattung. Dezember 2027 dreht sich um die vollständige Bewerbung.

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Zwischenfälle melden, die die Sicherheit von Produkten mit digitalen Elementen beeinträchtigen. Die Europäische Kommission erklärt, dass die Berichterstattung innerhalb von 24 Stunden eine Frühwarnung enthält. eine vollständige Mitteilung innerhalb von 72 Stunden und Abschlussberichte innerhalb der jeweils gültigen 14-Tage- oder einmonatigen Frist. Berichte werden einmal über die CRA Single Reporting Platform erstellt, die ENISA mit der Erstellung beauftragt wird.

Die wichtigsten Bestimmungen der RAA gelten ab dem 11. Dezember 2027, die Meldepflichten gelten ab dem 11. September 2026. Die Zusammenfassung der Kommission besagt außerdem, dass Meldepflichten für alle Produkte gelten, die digitale Elemente enthalten, die auf dem EU-Markt verfügbar sind. einschließlich Produkte, die bereits vor dem 11. Dezember 2027 auf den Markt gebracht wurden.

Miha<unk> ly Pajerichs praktischer Punkt war, dass die Berichterstattung nicht ohne die Behandlung von Verwundbarkeiten funktionieren kann. Ein Hersteller kann nicht berichten, was er nicht entdeckt, erhält, bewertet, klassifiziert und eskaliert.

Minimaler Prozess vor September 2026

Bevor die Meldepflicht beginnt, sollten die Hersteller Folgendes haben:

1. Eine öffentliche Schwachstelle, die Kontakt oder Web-Formular meldet.

2. Ein interner Besitzer für Routing-Berichte.

3. Eine Möglichkeit, die betroffenen Produkte, Versionen und Komponenten zu identifizieren.

4. Ein Prozess der Schwere und Ausnutzung.

5. Ein Entscheidungsweg für die Berichterstattung.

6. Ein Prozess für die Benutzerkommunikation.

7. Eine Ticket Datensatzvorlage.

Das ist ein praktisches Minimum, das nicht perfekt sein muss, aber es muss brauchbar sein.

9. Mehrere Fabriken benötigen eine Berichtsentscheidungh

Frage vom Webinar: Wer meldet Vorfälle, wenn ein Unternehmen mehrere Fabriken unter dem gleichen Board hat?

Nicht jede Fabrik sollte separat melden. Fabriken oder Standorte sollten interne Berichtswege haben. Eine zentrale Herstellerfunktion sollte beurteilen, ob der Fall über die einheitliche Berichtsplattform gemeldet werden muss. Wenn sich der Hersteller außerhalb der EU befindet, kann der autorisierte Vertreter, Importeur oder Distributor je nach Fall beteiligt sein.

Ein nützlicher Test ist eine Tabellenübung.

Szenario:

Ein Anbieter meldet eine Schwachstelle in einem Kommunikationsmodul, das in drei Produkten verwendet wird. Einer ist in der Produktion. Einer befindet sich noch in der Entwicklung. Aktive Ausbeutung ist unklar. Ein Patch existiert bereits, aber er wurde nicht auf jedem Produkt getestet.

Der Hersteller sollte innerhalb des Berichtszeitraums antworten können:

• welche Produkte und Versionen betroffen sind

• ob die Verwundbarkeit aktiv ausgenutzt wird

• ob Benutzer eine Leitlinie für die Abschwächung benötigen

• ob eine Berichterstattung erforderlich ist

• wer den Bericht billigt

• wo die Beweise gespeichert sind

Wenn dies in einem Test nicht möglich ist, ist der Prozess nicht bereit.

10. Unterstützungszeiträume betreffen die Technik, nicht nur die Einhaltung

Frage vom Webinar: Wie sollen Hersteller die richtige Sicherheitsunterstützungszeit entscheiden?

Gergely erklärte , dass fünf Jahre der Standard-Ausgangspunktsei, aber die vorgesehene Lebensdauer des Produkts zähle. Langlebige Industrie- oder OT-Produkte benötigen möglicherweise eine längere Planung.

Der CRA-Gesetzestext verlangt von den Herstellern die Festlegung eines Supportzeitraums, der die voraussichtliche Nutzungsdauer des Produkts widerspiegelt. Ferner wird festgestellt, dass die Förderfrist mindestens fünf Jahre betragen soll es sei denn, das Produkt wird für weniger als fünf Jahre voraussichtlich verwendet. Der offizielle EUR-Lex-Text bezieht sich auch auf die Bedingung, dass Sicherheitsaktualisierungen für mindestens 10 Jahre oder für den Rest der Unterstützungszeit verfügbar bleiben.

Dies wirkt sich auf die Produktplanung aus.

Vor dem Start sollten die Hersteller wissen:

• wie Updates geliefert werden

• wer Sicherheits-Patches pflegt

• welche Lieferantenverpflichtungen benötigt werden

• wie Verwundbarkeiten von Drittanbietern überwacht werden

• wie das Ende der Unterstützung kommuniziert wird

• wie lange ausgestellte Sicherheitsaktualisierungen verfügbar bleiben

Für langlebige Produkte sollte diese Entscheidung Produkt-, Ingenieur-, Support-, Rechts- und gewerbliche Eigentümer umfassen.

Wo Cyberexpert passt

Der schwierige Teil ist nicht die Lektüre der Verordnung, sondern das Sammeln von Produktinformationen, die Mapping-Anforderungen, das Schreiben brauchbarer E. nfo und E.Just, die Verbindung von Beweismitteln zu Behauptungen und das Wissen, wann eine Überprüfung durch Experten erforderlich ist.

Das ist die Bereitschaft, die Cyberexperten zu unterstützen.

Cyberexpert hilft Herstellern, Produktinformationen zu strukturieren, anwendbare Anforderungen zu identifizieren, E.Info-Erwartungen zu kartieren, Beweise vorzubereiten, Lieferanten einzubeziehen und Selbstbewertung, Expertenbewertung oder Laborbewertung vorzubereiten.

Wenn du dich jetzt auf RED cyber vorbereitest, oder CRA als nächstes meldest, Cyberexpert verwenden, um zu überprüfen, was für Ihr Produkt gilt Identifizieren Sie Lücken in der Dokumentation und erstellen Sie Ihre Belege vor einer formellen Bewertung.

Ein 30-tägiger Plan

Woche 1: Produkt suchen

Erstellen Sie eine Produktgrenze, eine Konnektivitätskarte, eine Datenkarte, eine Schnittstellenliste, eine Gebrauchszusammenfassung, eine RED Scope Note und eine CRA Scope Note.

Output: Das Team weiß, welches Produkt bewertet wird und warum es im Geltungsbereich sein kann.

Woche 2: Baue die EN 18031 Basis

Erstellen Sie das Asset-Register, die Entitätsliste, die Schnittstellenkarte, die erste Sicherheitsmechanik-Zuordnung und die Annahmen des Entscheidungsbaums, die Beweise benötigen.

Output: Das Team kann sehen, wo die EN 18031 arbeitet und wo Produktinformationen fehlen.

Woche 3: Prüfe Beweislücken

Überprüfen Sie E.Info, E.Just, SBOM, HBOM, Benutzerhandbuch, Konfigurationsdokumentation, exponierte Dienste, Update-Prozess, Protokollierung, Testbeweise und Architekturdiagramme.

Output: Das Team weiß, was es gibt und was noch Arbeit braucht.

Woche 4: Bereite CRA-Verwundbarkeit vor

Stellen Sie den Schwachstellen-Report-Kontakt, CVD-Richtlinien-Entwurf, Ansaugprozess, Bestandsbestandsmerkmale, Erntebewertungsmethode, Berichtswesen, Benutzerbenachrichtigungsprozess und Vorlagen für Vorfälle ein.

Ausgabe: Der Hersteller hat vor Beginn der CRA-Meldepflicht einen Basisprozess.

Was ist wichtig zu merken

Die Webinar-Fragen deuten auf eine praktische Schlussfolgerung hin:

Hersteller müssen die Cybersicherheits-Compliance früher in die Produktentwicklung verschieben.

RED cyber kann den Marktzugang jetzt beeinflussen. CRA-Bericht beginnt vor der vollständigen CRA-Anwendung. EN 18031 erfordert produktspezifische Beweise, nicht generische Ansprüche. EN 40000 kann bei zusätzlichen Bereichen helfen, aber es ist nicht überflüssig, das Produkt zuerst zu verstehen.

Vor dem nächsten RED- oder CRA-Planungstreffen sollten die Hersteller in der Lage sein zu antworten:

• Ist das Produkt im RED Cyber-Geltungsbereich?

• Ist das Produkt im CRA-Bereich?

• Was ist die Produktgrenze?

• Was ist die Kernfunktionalität des Produkts?

• Welche Schnittstellen und Verbindungswege gibt es?

• Welche Vermögenswerte müssen geschützt werden?

• Welche EN 18031 Entscheidungsbaumpfade wurden befolgt?

• Können PASS, FEHLERN und NICHT ANWENDBAREN Ergebnisse gerechtfertigt sein?

• Werden E.Info und E.Just von der Ingenieurskunst validiert?

• Gibt es ein SBOM oder ein Bestandsbestand?

• Gibt es eine öffentliche Verwundbarkeit, die Kontakt meldet?

• Wer besitzt interne CRA-Berichte?

• Wie sieht die Förderperiode aus?

• Welche Belege können bei Produktvarianten wiederverwendet werden?

• Ist das Produkt zur Selbstbewertung, Bewertung durch Experten oder zur Laborbewertung bereit?

Wenn mehrere Antworten unklar sind, befindet sich das Produkt noch in der Vorbereitungsphase.

Dies ist der richtige Zeitpunkt, um die Lücken zu beseitigen, bevor sie sich auf Bewertung, Zertifizierung oder Marktzugang auswirken.

Um diese Schritte in die Praxis umzusetzen, laden Sie sich die folgende praktische Checkliste herunter und überprüfen Sie Ihre RED-Cyber- und CRA-Bereitschaft.