CRA-Konformitat: Lektionen aus ENISAs EUDI-Wallet-Schema [2026]

Am 3. April 2026 veroffentlichte ENISA den Entwurf v0.4.614 des Zertifizierungsschemas fur die europaische digitale Identitats-Wallet: 110 Seiten, eine offentliche Konsultation mit Frist 30. April und ein Webinar am 8. April. Dies ist das erste Cybersicherheitszertifizierungsschema fur IKT-Dienste, das je im Rahmen des EU Cybersecurity Act ausgearbeitet wurde. Das EUCC erfasst bereits IKT-Produkte; dieses Schema betritt Neuland, indem es denselben Rahmen auf Dienste anwendet. Es richtet sich an digitale Identitats-Wallets, nicht an Produkte im Allgemeinen. Die darin festgelegten Anforderungen an Nachweise, Lieferkettenpflichten und Konformitatsinfrastruktur werden jedoch pragen, wie die gesamte EU-Cybersicherheitszertifizierung funktioniert, einschliesslich der Schemata, die kunftig CRA-Produkte erfassen werden. Hier erfahren Sie, was das Schema vorschreibt, wo der CRA ausdrucklich zitiert wird und was Produkthersteller im Blick behalten sollten.

Warum ein Wallet-Schema fur Produkthersteller relevant ist

Das EUDIW-Schema und der CRA betreffen unterschiedliche Rechtsobjekte. Der CRA regelt Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Das Wallet-Schema regelt einen bestimmten Dienstleistungstyp: die EUDI-Wallet-Losung. Es handelt sich nicht um dieselbe Verordnung.

Aber sie teilen dieselbe rechtliche Grundstruktur.

Artikel 24 und Artikel 27 des CRA verweisen beide auf EU-Cybersicherheitszertifizierungsschemata im Rahmen des Cybersecurity Act als alternativen Konformitatsweg. Ein Produkt, das von einem anwendbaren CSA-Schema erfasst wird, kann die Zertifizierung nach diesem Schema nutzen, um die Konformitat mit den entsprechenden wesentlichen CRA-Anforderungen nachzuweisen. Ein solches Schema fur CRA-Produkte existiert noch nicht. Das EUDIW-Wallet-Schema ist das erste ausgearbeitete, und die Entscheidungen, die ENISA hier trifft, zu Nachweisformaten, Lieferkettenanforderungen und Bewertungsmethodik, werden ubertragen werden.

Das Schema zieht auf Seite 9 eine klare Zustandigkeitsgrenze. Der Text ist direkt: Der CRA "gilt nicht unmittelbar fur EUDI-Wallets, da sie im Rahmen des vorliegenden Schemas zertifiziert werden, da sie als IKT-Dienste und nicht als IKT-Produkte zertifiziert werden." Fur die meisten EUDIW-Teilnehmer ist der CRA keine parallele Verpflichtung. Das Schema hat sich selektiv an der CRA-Methodik orientiert, aber diese Anleihe weitet den Geltungsbereich der Verordnung nicht aus.

Die Ausnahme betrifft mobile Anwendungen. Wenn die Wallet-Instanz eine mobile Anwendung ist, die von einer kommerziellen Einheit auf dem Markt bereitgestellt wird, gilt der CRA fur diese Anwendung als Produkt mit digitalen Elementen. Fur Unternehmen, die eine mobile Wallet-App kommerziell vertreiben, sind gleichzeitig zwei Regime anwendbar. Der CRA regelt die Vormarktkonformitat und die nachmarktlichen Pflichten zum Schwachstellenmanagement fur das Produkt. Das Wallet-Schema regelt die kontinuierliche Dienstzertifizierung. Sie stapeln sich, aber nur in diesem konkreten Szenario. Eine Organisation, die eine Wallet-Losung rein als IKT-Dienst anbietet, hat durch dieses Schema keine CRA-Verpflichtung.

Der gemeinsame Rahmen umfasst den CSA und das europaische Common-Criteria-basierte Evaluierungsrahmenwerk (ECCF), CEN TS 18072 fur Wallet-Dienstleistungsanforderungen sowie das EUCC (EU Common Criteria-basiertes Cybersicherheitszertifizierungsschema) als kompositionelle Basis fur Hardware- und Plattformkomponenten. Diese Infrastruktur wurde nicht allein fur Wallets gebaut. Sie ist das Skelett, das kunftige CRA-nahe Schemata verwenden werden.

Eine weitere Abgrenzung: Das Schema stellt fest, dass EUDIW-Zertifikate "nicht fur die Konformitatsvermutung" nach dem CRA geeignet sein werden (S.9). Selbst fur mobile Wallet-Apps, auf die der CRA anwendbar ist, erfullt das EUDIW-Zertifikat nicht die CRA-Konformitat. Die beiden Compliance-Spuren sind getrennt und mussen jeweils unabhangig voneinander abgeschlossen werden.

Mobile Wallet-Vertreiber: zwei unabhangige Compliance-Spuren. Wenn Sie als kommerzielle Einheit eine mobile Wallet-App auf dem EU-Markt bereitstellen, gilt der CRA fur diese App als Produkt mit digitalen Elementen. Sie benotigen eine CRA-Konformitatsbewertung fur das Produkt und eine EUDIW-Zertifizierung fur den Wallet-Dienst. Keine erfullt die andere. Beide mussen unabhangig voneinander abgeschlossen und unter getrennten Uberwachungszyklen aufrechterhalten werden. Wenn Sie die Wallet rein als IKT-Dienst ohne eine separat vertriebene mobile App anbieten, gilt der CRA fur Sie durch dieses Schema nicht.

Wenn Ihre Produkte kunftig einem CSA-Zertifizierungsschema nach Artikel 27 des CRA unterliegen werden, ist das Wallet-Schema Ihre deutlichste Vorschau auf diese Bewertung. Die hier validierten Methoden sind die Methoden, denen Sie begegnen werden.

Den aktuellen CRA-Moduloptionen, solange CSA-Schemata noch ausstehen, widmet sich der Leitfaden zur Konformitatsbewertung.

Die heutige Zertifizierungsinfrastruktur

Die CRA-Konformitatslandschaft hat derzeit vier Ebenen. Standardprodukte (die Mehrheit) konnen Modul A zur Selbstbewertung nutzen. Wichtige Produkte der Klasse I konnen Modul A verwenden, wenn sie harmonisierte Normen anwenden, oder zu einer Notifizierten Stelle gehen. Wichtige Produkte der Klasse II und kritische Produkte erfordern eine Drittparteienbewertung, wobei kritische Produkte auch ein anwendbares CSA-Schema benotigen, sofern eines existiert.

Die Lucke: Kein CSA-Schema deckt derzeit die wesentlichen CRA-Anforderungen ab. Das bedeutet, der Artikel-27-Weg, bei dem eine CSA-Zertifizierung die Konformitatsvermutung nach CRA auslost, ist fur kein Produkt derzeit begehbar. Er existiert in der Verordnung, aber nicht in der Praxis.

Das EUDIW-Wallet-Schema schließt diese Lucke nicht. Aber es etabliert das Modell.

Das Schema schreibt ausschliesslich den Assurance-Level "hoch" vor, ohne dass niedrigere Stufen erlaubt sind. Die Begrundung im Dokument ist direkt: "Alle Funktionen der EUDI-Wallets sind Sicherheitsfunktionen, einige davon von kritischer Sensibilitat" (S.17). Das Schema urteilt, dass keine Wallet-Funktion risikoarm genug ist, um Selbstbewertung zu erlauben.

Selbstbewertung ist nicht nur nicht empfohlen. Sie ist gesperrt: "Eine Konformitatsselbstbewertung... ist nicht zulassig" (S.18).

Diese Logik entspricht dem CRA-Ansatz fur wichtige und kritische Produkte. Hohere Einsatze rechtfertigen strengere Konformitaatswege. Die genaue Schwelle unterscheidet sich zwischen den Regimen, aber das Prinzip ist identisch. Wenn ENISA kunftige CSA-Schemata fur CRA-Produktkategorien ausarbeitet, ist dieselbe Argumentation fur Anhang-III- und Anhang-IV-Produkte zu erwarten.

Die aktuellen Produktklassifizierungsregeln nach CRA erlautert der Produktklassifizierungsleitfaden.

Was das Schema von privaten Unternehmen verlangt

Das Schema definiert einen vierstufigen Lebenszyklus fur Antragsteller.

Die Vorbereitung umfasst die Zusammenstellung von Dokumentation, Risikoabschatzung und die Erhebung von Assurance-Nachweisen fur Komponenten. Hier wird Ihr Lieferkettennachweis zur blockierenden Abhangigkeit, nicht zu einer optionalen Erganzung.

Die erste Bewertung beinhaltet Designprufung und Abhangigkeitsanalyse. Eine IT-Sicherheitsevaluierungsstelle (ITSEF) pruft Ihre Architektur, Ihr Vertrauensmodell und den Konformitatsstatus jeder Komponente, von der Ihre Wallet abhangt.

Die zweite Bewertung umfasst Funktionstests, Penetrationstests und Schwachstellenbewertung gegenuber den behaupteten Sicherheitsfunktionen der Wallet. Dies ist keine Dokumentenprufung. Tester tasten das System aktiv ab.

Die Wartung setzt sich nach der Zertifikatsausstellung fort. Eine jahliche Uberwachung ist erforderlich, einschliesslich Penetrationstests zum jeweiligen Jahrestag. Dies ist kein Ankreuzfeld. Es sind wiederkehrende Bewertungskosten, die im Zertifikatslebenszyklus eingebaut sind.

Das Zertifikat ist 5 Jahre gultig. Die Obergrenze ist hart. Das Schema stellt fest, dass keine Ausnahme moglich ist (S.26). Wenn das Zertifikat erlischt, muss die Wallet deaktiviert werden. Es gibt keine verhandelbare Nachfrist.

Die Pflicht zur Informationsintegritat ist strenger als in den meisten Compliance-Rahmenwerken. Das Bereitstellen unrichtiger oder unvollstandiger Informationen gegenuber der Zertifizierungsstelle wird als Nichteinhaltung eingestuft, nicht als Nichtkonformitat (S.23-24). Der Unterschied ist wesentlich: Nichtkonformitat lost einen Behebungsprozess aus. Nichteinhaltung kann unter anderen Voraussetzungen zur Aussetzung oder zum Entzug fuhren.

Nach Benachrichtigung uber eine Nichtkonformitat haben Sie 30 Tage Zeit, um zu beurteilen, ob der Befund wesentlich ist (S.38). Diese Frist beginnt nicht, wenn Sie das Problem entdecken. Sie beginnt, wenn die Zertifizierungsstelle Sie benachrichtigt. Organisationen ohne Einnahmeprozesse fur Konformitatsbenachrichtigungen werden dieses Zeitfenster verbrauchen, bevor jemand die E-Mail gelesen hat.

Eine Aussetzung ist offentlich. Das Schema schreibt eine verpflichtende Offenlegung vor, wenn ein Zertifikat ausgesetzt wird (S.40). Die maximale Aussetzungsdauer betragt 42 Tage, kann aber von der nationalen Cybersicherheitszertifizierungsbehorde (NCCA) auf bis zu 1 Jahr verlangert werden. Dies ist keine interne Angelegenheit. Ihre Kunden und vertrauenden Parteien werden es sehen.

Die Aufbewahrung von Dokumenten erstreckt sich uber 5 Jahre nach Ablauf des Zertifikats, einschliesslich physischer Produktexemplare, soweit zutreffend (S.49). Bei Softwareprodukten mit einem 5-jahrigen Zertifikat ergibt sich eine Mindestnachweiskette von 10 Jahren.

Das CRA-Modell verlangt eine Konformitaatsbewertung vor der Marktbereitstellung und ein Schwachstellenmanagement nach der Marktbereitstellung. Das Wallet-Schema verlangt kontinuierliche Konformitat mit jahlichen Penetrationstests und Uberwachung wahrend des gesamten Zertifikatslebenszyklus. Fur Unternehmen, die beiden Regimen unterliegen, sind die Nachzertifizierungspflichten des Wallet-Schemas in Umfang und Haufigkeit anspruchsvoller als die des CRA.

Ihre Lieferkette ist jetzt Teil der Zertifizierungskette

Das Wallet-Schema verwendet ein kompositionelles Bewertungsmodell mit drei unterschiedlichen Ebenen.

Die Wallet Secure Cryptographic Application (WSCA) und ihre zugrunde liegende Hardwareplattform werden nach EUCC, dem EU-Common-Criteria-Schema, bewertet. Dies umfasst die Hardware-Sicherheitsmodule, Secure-Elemente und Trusted Execution Environments, von denen die Wallet abhangt.

Die Wallet-Instanz (die auf dem Gerat des Nutzers laufende Software) wird nach FiTCEM bewertet, der Functional IT Common Evaluation Method, die Software-Evaluierungen handhabt, bei denen eine Hardware-Trennung nicht praktikabel ist.

Wallet-Dienste (serverseitige Komponenten, Identitatsausstellung, Schnittstellen zu vertrauenden Parteien) werden nach CEN TS 18072-Anforderungen bewertet.

Jede Ebene hat ihren eigenen Bewertungsweg. Ihr Zertifikat hangt von den darunter liegenden Zertifikaten ab.

Das Schema ist ausdrucklich uber die Pflichten, die dies fur Antragsteller bedeutet: Sie mussen "die Assurance-Dokumentation fur seine Komponenten zusammenstellen, was bedeuten kann, dass einige von ihnen zertifiziert werden mussen" (S.14). "Kann bedeuten" untertreibt es. Fehlt einem Bauteil die erforderliche Assurance-Dokumentation, kann Ihre Bewertung nicht abgeschlossen werden.

Die Offenlegung von Unterauftragnehmern ist erschopfend. Jeder Unterauftragnehmer muss aufgefuhrt werden, zusammen mit dem Umfang der auf seinen Beitrag angewendeten Konformitatsbewertung (S.78). Es gibt keine generische Kategorie "wir nutzen renommierte Anbieter". Jeder Dritte hat entweder dokumentierte Konformitatsnachweise oder nicht, und diese Lucke ist Ihr Problem bei der Bewertung.

Meldungen uber vorgelagerte Schwachstellen sind in beiden Richtungen verpflichtend. Wenn eine Schwachstelle ein IKT-Produkt betrifft, das einem zusammengesetzten IKT-Dienst zugrunde liegt, muss der EUCC-Zertifikatsinhaber abhangige EUDIW-Zertifikatsinhaber informieren (S.43). Dies ist eine spezifische Pflicht, die an Schwachstellenmeldungen geknupft ist, keine allgemeine Benachrichtigungspflicht bei jeder Zertifikatsanderung. Wenn Ihr Komponentenlieferant eine Schwachstelle identifiziert und Sie nicht informiert, verletzt er seine Pflichten. Wenn er Sie informiert, haben Sie ein 30-tagiges Fenster zur Wesentlichkeitsbeurteilung.

Die kontinuierliche Uberwachung hort nicht an Ihrer Organisationsgrenze auf. Wenn ein Basiszertifikat aktualisiert oder ersetzt wird, muss die CAB eine differenzielle Abhangigkeitsanalyse der Anderungen durchfuhren (S.84). Eine wesentliche Aktualisierung einer Abhangigkeit lost eine formale CAB-Bewertung aus, ob Ihr Zertifizierungsumfang betroffen ist.

Cloud-Anbieter sind nicht ausgenommen. Das Schema klassifiziert "vom Anbieter bereitgestellte" Infrastruktur (S.61) als eine Komponente im Anwendungsbereich der Lieferkettenbewertung. Wenn Ihr Wallet-Dienst auf einer Cloud-Plattform lauft, ist der Konformitatsstatus dieser Plattform Teil Ihres Nachweispakets.

Die Weitergaberegel ist bedeutsam: Ist in einem Zertifizierungsbericht einer Basiskomponente eine Behebung einer Nichtkonformitat ausstehend, muss die CAB deren Auswirkung auf den zusammengesetzten IKT-Dienst bewerten (S.84). Ist diese Auswirkung wesentlich, kann die zusammengesetzte Bewertung erst abgeschlossen werden, wenn die Nichtkonformitat behoben ist. Dies ist nicht automatisch, sondern hangt davon ab, ob die Nichtkonformitat als wesentlich fur Ihren Dienst eingestuft wird. Eine schwerwiegende offene Nichtkonformitat im Zertifizierungsbericht Ihres WSCA-Lieferanten kann jedoch den Abschluss Ihrer Bewertung verhindern.

Dies ist kein hypothetisches Zukunftsmodell fur den CRA. Die SBOM-Pflicht des CRA (Anhang I Teil II) und die Anforderungen an das Schwachstellenmonitoring (Artikel 13 und 14) funktionieren nach demselben Prinzip. Das Wallet-Schema zeigt, wie diese Pflichten in der Praxis innerhalb eines formalen Zertifizierungsrahmens wirken: dokumentiert, bilateral und blockierend.

Wie die Lieferkettenpflichten des CRA mit kunftigen CSA-Zertifizierungsschemata zusammenwirken werden, erlautert Cybersecurity Act 2. Die praktische Mechanik der SBOM-Erstellung und -Pflege behandelt der SBOM-Erstellungsleitfaden.

Was Ihre bestehenden Zertifizierungen tatsachlich wert sind

Die meisten Hersteller gehen davon aus, dass ihre bestehenden Zertifizierungen in neuen Schemata Gewicht haben. Bei EUDIW hangt die Antwort vollstandig davon ab, welche Zertifizierung Sie halten und wie prazise Ihr Auditor deren Umfang den Schemakriterien zugeordnet hat.

Das Schema befasst sich damit direkt in Abschnitt 5.3. Es erlaubt Konformitatsbewertungsstellen (CABs), sich auf fruhere Arbeit zu stutzen, aber die Bedingungen sind streng. Ein Bruckenbrief ist erforderlich, wenn zwischen dem Berichtszeitraum des fruheren Audits und der aktuellen Bewertung eine Lucke besteht (S.85). Partielle Anerkennung ist gangig; vollstandige Anerkennung ist selten.

Der ISO-27001-Befund verdient besondere Aufmerksamkeit. Das Schema stellt klar: "es bietet fur sich allein keine ausreichende Sicherheit, dass die im Anwendungsbereichsdokument ausgewahlten Einzelkontrollen auf dem von diesem Schema geforderten Strenge-Niveau konzipiert sind und funktionieren" (S.88).

Diese Logik geht uber EUDIW hinaus. Eine ISMS-Zertifizierung bestatigt die Prozessreife und das Vorhandensein eines Managementsystems. Sie bestatigt nicht, dass einzelne Kontrollen auf dem Assurance-Niveau funktionieren, das ein bestimmtes Schema verlangt. Dieselbe Argumentation wird bei CRA Anwendung finden, wenn harmonisierte Normen finalisiert werden.

Wenn Ihr SOC-2-Typ-II-Audit ohne EU-Cybersicherheitskriterien im Blick durchgefuhrt wurde, qualifiziert es sich nicht fur eine bedingte Anerkennung. Sie wurden eine verifizierte Zuordnung von Ihrem Auditor benotigen. Planen Sie dieses Gesprach jetzt, bevor Sie in einem Zertifizierungszeitplan stecken.

Einen tieferen Vergleich dessen, was ISO 27001 tatsachlich abdeckt, gegenuber CRA-Anforderungen liefert unser ISO-27001-Vergleichsleitfaden.

Schwachstellenmanagement geht uber den CRA hinaus

Die Anforderungen des EUDIW-Schemas an das Schwachstellenmanagement stutzen sich ausdrucklich auf den CRA. Das Schema stellt fest: "Dieser Abschnitt... schopft hauptsachlich aus anderen Vorschriften, wie Artikel 55 des CSA... und auch aus dem CRA" (S.43). Diese Herkunft ist bedeutsam, weil die Anforderungen dieselbe Struktur teilen, sich aber in der Mechanik unterscheiden.

Zum SBOM: Das Schema verlangt ein maschinenlesbares Format (S.43), im Einklang mit CRA-Anhang I Teil II. Dies ist kein neues Konzept, wenn Sie CRA-Pflichten bereits verfolgen, aber es bestatigt, dass SBOMs als technisches Artefakt zu einer Basiserwartung in EU-Schemata werden, nicht nur CRA-spezifisch.

Sicherheitsupdates mussen getrennt von Funktionsupdates bereitgestellt werden (S.43). Dies ist operativ bedeutsam. Ein kombiniertes Release, das Schwachstellen behebt und neue Funktionen hinzufugt, schafft Unklarheit daruber, was Nutzer akzeptieren. Das Schema behandelt sie als getrennte Pflichten.

Ihre CVD-Richtlinie muss offentlich und auf EN ISO/IEC 29147 ausgerichtet sein (S.47). Dies ist kein Richtliniendokument, das in einem Compliance-Ordner vergraben ist. Es muss auffindbar, aktuell und nach dem Standard strukturiert sein.

Zur Wirkungsanalyse: CVSS-Werte allein genugen nicht. Das Schema verlangt eine kontextspezifische Analyse (S.44). Ein CVSS-Wert von 9,8 in einem Einsatzkontext kann in Ihrem Kontext einem CVSS-Wert von 4,0 entsprechen, aber Sie mussen diese Begrundung dokumentieren, nicht nur behaupten.

Die operativ bedeutsamste Anforderung: Eine wesentliche Schwachstelle ohne Behebungspfad lost den Zertifikatsentzug aus (S.45). Das schafft eine direkte Verbindung zwischen Ihrer Patch-Kadenz und Ihrem Zertifizierungsstatus. Die Uhr stoppt nicht bei der Bewertung.

Der CRA-Vergleich ist hier relevant. Der CRA verlangt eine ENISA-Meldung innerhalb von 24 Stunden nach Entdeckung einer aktiv ausgenutzten Schwachstelle. EUDIW verwendet "ohne ungebhrliche Verzogerung" uber die CAB-Kette. Andere Uhr, andere Weiterleitung, ahnliche Absicht. Wenn Sie Prozesse fur das eine aufbauen, legen Sie diese so an, dass sie auch das andere erfullen.

Eine Aufschlusselung der 24-Stunden-Meldepflicht im Einzelnen liefert unser Beitrag zum ENISA-Schwachstellenmeldesystem. Einen Ausgangspunkt fur Ihre CVD-Richtlinie bietet die CVD-Richtlinienvorlage.

Was bestatigt ist und was unsere Analyse ist

Funf Punkte, die es zu verfolgen gilt

Das Schema ist nicht endgultig. Die Konsultationsfrist am 30. April bedeutet, dass noch Anderungen moglich sind. Dies sind die Bereiche, in denen das Ergebnis Ihre Planung wesentlich beeinflusst.

1. Anforderungen an das Nachweisformat: Das Schema verweist auf maschinenlesbare SBOMs und Struktur der technischen Unterlage, standardisiert aber nicht vollstandig, wie "ausreichend" in der Praxis aussieht. CABs werden dies interpretieren. Bis dahin bauen Sie auf das strukturierteste Format, das Sie verteidigen konnen.

2. CAB-Kapazitat: Die Zulassung erfordert sowohl Akkreditierung als auch NCCA-Genehmigung sowie den Abschluss einer Pilotbewertung (S.30). Das Hochfahrproblem ist real. Wenn qualifizierte CABs rar sind, wenn das Schema in Kraft tritt, verschieben sich Zeitplane unabhangig davon, wie gut Sie vorbereitet sind. Das liegt nicht in Ihrer Kontrolle, beeinflusst aber Ihre Planungsannahmen.

3. Gegenseitige Anerkennung: Das Schema ubernimmt die EUCC-Bestimmungen zur gegenseitigen Anerkennung mit Drittlandsschemata nicht (S.52). Die gegenseitige Anerkennung mit Drittlandern wird ausdrucklich fur eine spatere Phase offen gelassen: "diese Bedingungen konnen in einer spateren Phase hinzugefugt werden." Dies ist eine offene Frage, keine abschliessende Entscheidung. Planen Sie nicht damit, dass Ihre US-Zertifizierungen ubertragen werden, aber dies ist eine aktiv offene Frage und keine dauerhafte Ablehnung.

4. Nationaler Schema-Sonnenuntergang: Bestehende nationale Schemata haben nach Inkrafttreten ein 12-monatiges Fenster, um gultig zu bleiben (S.56). Wenn Ihre aktuelle Zertifizierung nach einem nationalen Schema ausgestellt wurde, verstehen Sie, wann dieses Fenster schliesst.

5. Offene Fragen: Eigentumerschaft von Penetrationstests, Schwellenwerte fur das Angriffspotenzial und Tiefenqualifikatoren fur die Schwachstellenanalyse sind im aktuellen Text noch nicht gelost (S.97-98). Dies sind keine redaktionellen Lucken. Sie beeinflussen, wie Sie Bewertungen planen und budgetieren.

Was wir mit Sicherheit wissen

• Der CRA wird ausdrucklich als Quelle fur die Anforderungen des Schemas zitiert.
• SBOM in maschinenlesbarem Format ist verpflichtend.
• ISO 27001 allein genugt nicht, um organisatorische Kontrollanforderungen zu erfullen.
• Selbstbewertung ist auf keinem Assurance-Level fur EUDIW-Komponenten zulassig.
• Die Zertifikatsgultigkeit ist auf 5 Jahre begrenzt.

Unsere Analyse (nicht bestatigt)

• CRA-Konformitatsbewertungsschemata werden wahrscheinlich ahnlichen Mustern bei SBOM-Anforderungen, CVD-Richtlinie und der Unzulanglichkeit von ISO 27001 allein folgen. Das EUDIW-Schema gibt einen Vorgeschmack darauf, wie ENISA diese Pflichten bewertet.
• Der Druck in der Lieferkettenzertifizierung wird zunehmen. Die komponentenbezogenen Anforderungen von EUDIW deuten darauf hin, dass nachgelagerte Hersteller beginnen werden, von vorgelagerten Lieferanten unabhangige Zertifizierungen zu verlangen, nicht nur Selbsterklarungen.
• SOC-2-Zuordnung ist eine echte Chance. Wenn Sie jetzt mit Ihrem Auditor zusammenarbeiten, um eine Kriterienzuordnung zu EU-Cybersicherheitsanforderungen zu strukturieren, konnen Sie Ihr nachstes SOC-2-Typ-II fur eine bedingte Anerkennung positionieren, anstatt bei null anzufangen.

Was noch niemand weiss

• Wann ein CRA-spezifisches Zertifizierungsschema veroffentlicht wird und wie der Konsultationszeitplan aussieht.
• Welche harmonisierten Normen unter dem CRA benannt werden und welche Assurance-Schwellen sie setzen werden.
• Wie sich die nationale CAB-Kapazitat im Verhaltnis zur Nachfrage entwickeln wird, wenn mehrere Schemata gleichzeitig aktiv sind.

Was Hersteller jetzt tun sollten

Das Konsultationsfenster und die endgultige Schema-Veroffentlichung geben Ihnen ein definiertes Zeitfenster zur Vorbereitung. Dies sind konkrete Schritte, keine allgemeinen Ratschlage.

• Verstehen Sie Ihren Konformitaatsbewertungsweg. Die Assurance-Level des Schemas korrespondieren mit unterschiedlichen Produktkategorien. Was fur Sie gilt, ist nicht immer offensichtlich. Nutzen Sie einen strukturierten Entscheidungsprozess, bevor Sie annehmen, Ihren Weg zu kennen. Beginnen Sie mit dem Leitfaden zur Konformitatsbewertung.

• Bauen Sie Nachweise jetzt auf. SBOMs, Risikoabschatzungen, Schwachstellenoffenlegungsrichtlinien und technische Unterlagen brauchen Zeit, um korrekt erstellt zu werden. Beginnen Sie wahrend der Konsultationsphase, konnen Sie iterieren, bevor eine CAB sie anfordert.

• Gehen Sie nicht davon aus, dass ISO 27001 Sie abdeckt. Das Schema ist eindeutig. Wenn Ihre Compliance-Haltung auf ISO 27001 als Proxy fur Cybersicherheitsgewahrleistung aufgebaut ist, haben Sie eine Lucke. Identifizieren Sie, welche Kontrollen einer unabhangigen Verifizierung bedurfen.

• Strukturieren Sie Ihr nachstes SOC-2-Audit mit EU-Kriterienzuordnung. Wenn eine SOC-2-Erneuerung ansteht, sprechen Sie mit Ihrem Auditor, bevor der Scope festgelegt wird. Eine dokumentierte Kriterienzuordnung zu EUDIW- (und kunftig CRA-) Anforderungen ist es, was einen Typ II von partieller zu bedingter Anerkennung verwandelt.

• Verfolgen Sie den Konsultationsprozess. Das Webinar am 8. April und die Schriftfrist am 30. April sind die letzten formalen Eingabepunkte, bevor das Schema in Richtung Finalisierung geht. Wenn das Schema Ihre Produkte betrifft, reichen Sie Kommentare ein oder beobachten Sie zumindest, was sich andert.

• Kartieren Sie Ihre Lieferkette. Identifizieren Sie, welche vorgelagerten Komponenten vom Anwendungsbereich des Schemas erfasst werden. Wenn ein Lieferant keine Zertifizierung fur eine von Ihnen integrierte Komponente nachweisen kann, wird diese Lucke bei der Bewertung zu Ihrem Problem.

Wie CRA Evidence hilft

CRA Evidence unterstutzt die Dokumentations- und Prozessinfrastruktur, die EUDIW- und CRA-Bewertungen erfordern:

• SBOM-Management: Erstellen, speichern und exportieren Sie SBOMs in maschinenlesbaren Formaten, die mit den Anforderungen aus CRA-Anhang I Teil II ubereinstimmen.
• VDP mit CVD-Workflow: Veroffentlichen und verwalten Sie Ihre Schwachstellenoffenlegungsrichtlinie mit einem strukturierten Aufnahme- und Reaktions-Workflow, ausgerichtet auf EN ISO/IEC 29147.
• ENISA-Meldeverfolgung: Verfolgen Sie die 24-Stunden-, 72-Stunden- und 14-Tage-Meldefenster mit prufsicheren Aufzeichnungen fur jede Meldung.
• Lieferantenportal: Verwalten Sie vor- und nachgelagerte Meldungen innerhalb Ihrer Lieferkette, mit dokumentierten Kommunikationsnachweisen fur technische Unterlagen.

Erfahren Sie, was CRA Evidence abdeckt, auf craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Fur spezifische Compliance-Beratung wenden Sie sich an qualifizierten Rechtsrat.