CRA-Konformität: Lektionen aus ENISAs EUDI-Wallet-Schema [2026]

Am 3. April 2026 veröffentlichte ENISA den Entwurf v0.4.614 des Zertifizierungsschemas für die europäische digitale Identitäts-Wallet: 110 Seiten, eine öffentliche Konsultation mit Frist 30. April und ein Webinar am 8. April. Dies ist das erste Cybersicherheitszertifizierungsschema für 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 Identitäts-Wallets, nicht an Produkte im Allgemeinen. Die darin festgelegten Anforderungen an Nachweise, Lieferkettenpflichten und Konformitätsinfrastruktur werden jedoch prägen, wie die gesamte EU-Cybersicherheitszertifizierung funktioniert, einschließlich der Schemata, die künftig CRA-Produkte erfassen werden. Hier erfahren Sie, was das Schema vorschreibt, wo der CRA ausdrücklich zitiert wird und was Produkthersteller im Blick behalten sollten.

Warum ein Wallet-Schema für 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-Lösung. Es handelt sich nicht um dieselbe Verordnung.

Aber sie teilen dieselbe rechtliche Grundstruktur.

Artikel 27 des CRA verweist auf EU-Cybersicherheitszertifizierungsschemata im Rahmen des Cybersecurity Act als alternativen Konformitätsweg. Ein Produkt, das von einem anwendbaren CSA-Schema erfasst wird, kann die Zertifizierung nach diesem Schema nutzen, um die Konformität mit den entsprechenden wesentlichen CRA-Anforderungen nachzuweisen. Ein solches Schema für 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 übertragen werden.

Das Schema zieht auf Seite 9 eine klare Zuständigkeitsgrenze. Der Text ist direkt: Der CRA „gilt nicht unmittelbar für EUDI-Wallets, da sie im Rahmen des vorliegenden Schemas zertifiziert werden, da sie als IKT-Dienste und nicht als IKT-Produkte zertifiziert werden." Für 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 für diese Anwendung als Produkt mit digitalen Elementen. Für Unternehmen, die eine mobile Wallet-App kommerziell vertreiben, sind gleichzeitig zwei Regime anwendbar. Der CRA regelt die Vormarktkonformität und die nachmarktlichen Pflichten zum Schwachstellenmanagement für das Produkt. Das Wallet-Schema regelt die kontinuierliche Dienstzertifizierung. Sie stapeln sich, aber nur in diesem konkreten Szenario. Eine Organisation, die eine Wallet-Lösung rein als IKT-Dienst anbietet, hat durch dieses Schema keine CRA-Verpflichtung.

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

Eine weitere Abgrenzung: Das Schema stellt fest, dass EUDIW-Zertifikate „nicht für die Konformitätsvermutung" nach dem CRA geeignet sein werden (S.9). Selbst für mobile Wallet-Apps, auf die der CRA anwendbar ist, erfüllt das EUDIW-Zertifikat nicht die CRA-Konformität. Die beiden Compliance-Spuren sind getrennt und müssen jeweils unabhängig voneinander abgeschlossen werden.

Mobile Wallet-Vertreiber: zwei unabhängige Compliance-Spuren. Wenn Sie als kommerzielle Einheit eine mobile Wallet-App auf dem EU-Markt bereitstellen, gilt der CRA für diese App als Produkt mit digitalen Elementen. Sie benötigen eine CRA-Konformitätsbewertung für das Produkt und eine EUDIW-Zertifizierung für den Wallet-Dienst. Keine erfüllt die andere. Beide müssen unabhängig voneinander abgeschlossen und unter getrennten Überwachungszyklen aufrechterhalten werden. Wenn Sie die Wallet rein als IKT-Dienst ohne eine separat vertriebene mobile App anbieten, gilt der CRA für Sie durch dieses Schema nicht.

Wenn Ihre Produkte künftig 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 Konformitätsbewertung.

Die heutige Zertifizierungsinfrastruktur

Die CRA-Konformitätslandschaft hat derzeit vier Ebenen. Standardprodukte (die Mehrheit) können Modul A zur Selbstbewertung nutzen. Wichtige Produkte der Klasse I können 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 benötigen, sofern eines existiert.

Die Lücke: Kein CSA-Schema deckt derzeit die wesentlichen CRA-Anforderungen ab. Das bedeutet, der Artikel-27-Weg, bei dem eine CSA-Zertifizierung die Konformitätsvermutung nach CRA auslöst, ist für kein Produkt derzeit begehbar. Er existiert in der Verordnung, aber nicht in der Praxis.

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

Das Schema schreibt ausschließlich den Assurance-Level „hoch" vor, ohne dass niedrigere Stufen erlaubt sind. Die Begründung im Dokument ist direkt: „Alle Funktionen der EUDI-Wallets sind Sicherheitsfunktionen, einige davon von kritischer Sensibilität" (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 Konformitätsselbstbewertung... ist nicht zulässig" (S.18).

Diese Logik entspricht dem CRA-Ansatz für wichtige und kritische Produkte. Höhere Einsätze rechtfertigen strengere Konformitätswege. Die genaue Schwelle unterscheidet sich zwischen den Regimen, aber das Prinzip ist identisch. Wenn ENISA künftige CSA-Schemata für CRA-Produktkategorien ausarbeitet, ist dieselbe Argumentation für Anhang-III- und Anhang-IV-Produkte zu erwarten.

Die aktuellen Produktklassifizierungsregeln nach CRA erläutert der Produktklassifizierungsleitfaden.

Was das Schema von privaten Unternehmen verlangt

Das Schema definiert einen vierstufigen Lebenszyklus für Antragsteller.

Die Vorbereitung umfasst die Zusammenstellung von Dokumentation, Risikoabschätzung und die Erhebung von Assurance-Nachweisen für Komponenten. Hier wird Ihr Lieferkettennachweis zur blockierenden Abhängigkeit, nicht zu einer optionalen Ergänzung.

Die erste Bewertung beinhaltet Designprüfung und Abhängigkeitsanalyse. Eine IT-Sicherheitsevaluierungsstelle (ITSEF) prüft Ihre Architektur, Ihr Vertrauensmodell und den Konformitätsstatus jeder Komponente, von der Ihre Wallet abhängt.

Die zweite Bewertung umfasst Funktionstests, Penetrationstests und Schwachstellenbewertung gegenüber den behaupteten Sicherheitsfunktionen der Wallet. Dies ist keine Dokumentenprüfung. Tester tasten das System aktiv ab.

Die Wartung setzt sich nach der Zertifikatsausstellung fort. Eine jährliche Überwachung ist erforderlich, einschließlich Penetrationstests zum jeweiligen Jahrestag. Dies ist kein Ankreuzfeld. Es sind wiederkehrende Bewertungskosten, die im Zertifikatslebenszyklus eingebaut sind.

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

Die Pflicht zur Informationsintegrität ist strenger als in den meisten Compliance-Rahmenwerken. Das Bereitstellen unrichtiger oder unvollständiger Informationen gegenüber der Zertifizierungsstelle wird als Nichteinhaltung eingestuft, nicht als Nichtkonformität (S.23-24). Der Unterschied ist wesentlich: Nichtkonformität löst einen Behebungsprozess aus. Nichteinhaltung kann unter anderen Voraussetzungen zur Aussetzung oder zum Entzug führen.

Nach Benachrichtigung über eine Nichtkonformität 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 für Konformitätsbenachrichtigungen werden dieses Zeitfenster verbrauchen, bevor jemand die E-Mail gelesen hat.

Eine Aussetzung ist öffentlich. Das Schema schreibt eine verpflichtende Offenlegung vor, wenn ein Zertifikat ausgesetzt wird (S.40). Die maximale Aussetzungsdauer beträgt 42 Tage, kann aber von der nationalen Cybersicherheitszertifizierungsbehörde (NCCA) auf bis zu 1 Jahr verlängert werden. Dies ist keine interne Angelegenheit. Ihre Kunden und vertrauenden Parteien werden es sehen.

Die Aufbewahrung von Dokumenten erstreckt sich über 5 Jahre nach Ablauf des Zertifikats, einschließlich physischer Produktexemplare, soweit zutreffend (S.49). Bei Softwareprodukten mit einem 5-jährigen Zertifikat ergibt sich eine Mindestnachweiskette von 10 Jahren.

Das CRA-Modell verlangt eine Konformitätsbewertung vor der Marktbereitstellung und ein Schwachstellenmanagement nach der Marktbereitstellung. Das Wallet-Schema verlangt kontinuierliche Konformität mit jährlichen Penetrationstests und Überwachung während des gesamten Zertifikatslebenszyklus. Für Unternehmen, die beiden Regimen unterliegen, sind die Nachzertifizierungspflichten des Wallet-Schemas in Umfang und Häufigkeit 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 abhängt.

Die Wallet-Instanz (die auf dem Gerät 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, Identitätsausstellung, Schnittstellen zu vertrauenden Parteien) werden nach CEN TS 18072-Anforderungen bewertet.

Jede Ebene hat ihren eigenen Bewertungsweg. Ihr Zertifikat hängt von den darunter liegenden Zertifikaten ab.

Das Schema ist ausdrücklich über die Pflichten, die dies für Antragsteller bedeutet: Sie müssen „die Assurance-Dokumentation für seine Komponenten zusammenstellen, was bedeuten kann, dass einige von ihnen zertifiziert werden müssen" (S.14). „Kann bedeuten" untertreibt es. Fehlt einem Bauteil die erforderliche Assurance-Dokumentation, kann Ihre Bewertung nicht abgeschlossen werden.

Die Offenlegung von Unterauftragnehmern ist erschöpfend. Jeder Unterauftragnehmer muss aufgeführt werden, zusammen mit dem Umfang der auf seinen Beitrag angewendeten Konformitätsbewertung (S.78). Es gibt keine generische Kategorie „wir nutzen renommierte Anbieter". Jeder Dritte hat entweder dokumentierte Konformitätsnachweise oder nicht, und diese Lücke ist Ihr Problem bei der Bewertung.

Meldungen über 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 abhängige EUDIW-Zertifikatsinhaber informieren (S.43). Dies ist eine spezifische Pflicht, die an Schwachstellenmeldungen geknüpft ist, keine allgemeine Benachrichtigungspflicht bei jeder Zertifikatsänderung. Wenn Ihr Komponentenlieferant eine Schwachstelle identifiziert und Sie nicht informiert, verletzt er seine Pflichten. Wenn er Sie informiert, haben Sie ein 30-tägiges Fenster zur Wesentlichkeitsbeurteilung.

Die kontinuierliche Überwachung hört nicht an Ihrer Organisationsgrenze auf. Wenn ein Basiszertifikat aktualisiert oder ersetzt wird, muss die CAB eine differenzielle Abhängigkeitsanalyse der Änderungen durchführen (S.84). Eine wesentliche Aktualisierung einer Abhängigkeit löst 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 läuft, ist der Konformitätsstatus dieser Plattform Teil Ihres Nachweispakets.

Die Weitergaberegel ist bedeutsam: Ist in einem Zertifizierungsbericht einer Basiskomponente eine Behebung einer Nichtkonformität 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 Nichtkonformität behoben ist. Dies ist nicht automatisch, sondern hängt davon ab, ob die Nichtkonformität als wesentlich für Ihren Dienst eingestuft wird. Eine schwerwiegende offene Nichtkonformität im Zertifizierungsbericht Ihres WSCA-Lieferanten kann jedoch den Abschluss Ihrer Bewertung verhindern.

Dies ist kein hypothetisches Zukunftsmodell für 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 künftigen CSA-Zertifizierungsschemata zusammenwirken werden, erläutert Cybersecurity Act 2. Die praktische Mechanik der SBOM-Erstellung und -Pflege behandelt der SBOM-Erstellungsleitfaden.

Was Ihre bestehenden Zertifizierungen tatsächlich wert sind

Die meisten Hersteller gehen davon aus, dass ihre bestehenden Zertifizierungen in neuen Schemata Gewicht haben. Bei EUDIW hängt die Antwort vollständig davon ab, welche Zertifizierung Sie halten und wie präzise Ihr Auditor deren Umfang den Schemakriterien zugeordnet hat.

Das Schema befasst sich damit direkt in Abschnitt 5.3. Es erlaubt Konformitätsbewertungsstellen (CABs), sich auf frühere Arbeit zu stützen, aber die Bedingungen sind streng. Ein Brückenbrief ist erforderlich, wenn zwischen dem Berichtszeitraum des früheren Audits und der aktuellen Bewertung eine Lücke besteht (S.85). Partielle Anerkennung ist gängig; vollständige Anerkennung ist selten.

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

Diese Logik geht über EUDIW hinaus. Eine ISMS-Zertifizierung bestätigt die Prozessreife und das Vorhandensein eines Managementsystems. Sie bestätigt 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 durchgeführt wurde, qualifiziert es sich nicht für eine bedingte Anerkennung. Sie würden eine verifizierte Zuordnung von Ihrem Auditor benötigen. Planen Sie dieses Gespräch jetzt, bevor Sie in einem Zertifizierungszeitplan stecken.

Einen tieferen Vergleich dessen, was ISO 27001 tatsächlich abdeckt, gegenüber CRA-Anforderungen liefert unser ISO-27001-Vergleichsleitfaden.

Schwachstellenmanagement geht über den CRA hinaus

Die Anforderungen des EUDIW-Schemas an das Schwachstellenmanagement stützen sich ausdrücklich auf den CRA. Das Schema stellt fest: „Dieser Abschnitt... schöpft hauptsächlich 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 bestätigt, dass SBOMs als technisches Artefakt zu einer Basiserwartung in EU-Schemata werden, nicht nur CRA-spezifisch.

Sicherheitsupdates müssen getrennt von Funktionsupdates bereitgestellt werden (S.43). Dies ist operativ bedeutsam. Ein kombiniertes Release, das Schwachstellen behebt und neue Funktionen hinzufügt, schafft Unklarheit darüber, was Nutzer akzeptieren. Das Schema behandelt sie als getrennte Pflichten.

Ihre CVD-Richtlinie muss öffentlich 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 genügen 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 müssen diese Begründung dokumentieren, nicht nur behaupten.

Die operativ bedeutsamste Anforderung: Eine wesentliche Schwachstelle ohne Behebungspfad löst 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 ungebührliche Verzögerung" über die CAB-Kette. Andere Uhr, andere Weiterleitung, ähnliche Absicht. Wenn Sie Prozesse für das eine aufbauen, legen Sie diese so an, dass sie auch das andere erfüllen.

Eine Aufschlüsselung der 24-Stunden-Meldepflicht im Einzelnen liefert unser Beitrag zum ENISA-Schwachstellenmeldesystem. Einen Ausgangspunkt für Ihre CVD-Richtlinie bietet die CVD-Richtlinienvorlage.

Was bestätigt ist und was unsere Analyse ist

Fünf Punkte, die es zu verfolgen gilt

Das Schema ist nicht endgültig. Die Konsultationsfrist am 30. April bedeutet, dass noch Änderungen möglich 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 vollständig, wie „ausreichend" in der Praxis aussieht. CABs werden dies interpretieren. Bis dahin bauen Sie auf das strukturierteste Format, das Sie verteidigen können.

2. CAB-Kapazität: 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 Zeitpläne unabhängig davon, wie gut Sie vorbereitet sind. Das liegt nicht in Ihrer Kontrolle, beeinflusst aber Ihre Planungsannahmen.

3. Gegenseitige Anerkennung: Das Schema übernimmt die EUCC-Bestimmungen zur gegenseitigen Anerkennung mit Drittlandsschemata nicht (S.52). Die gegenseitige Anerkennung mit Drittländern wird ausdrücklich für eine spätere Phase offen gelassen: „diese Bedingungen können in einer späteren Phase hinzugefügt werden." Dies ist eine offene Frage, keine abschließende Entscheidung. Planen Sie nicht damit, dass Ihre US-Zertifizierungen übertragen 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 gültig zu bleiben (S.56). Wenn Ihre aktuelle Zertifizierung nach einem nationalen Schema ausgestellt wurde, verstehen Sie, wann dieses Fenster schließt.

5. Offene Fragen: Eigentümerschaft von Penetrationstests, Schwellenwerte für das Angriffspotenzial und Tiefenqualifikatoren für die Schwachstellenanalyse sind im aktuellen Text noch nicht gelöst (S.97-98). Dies sind keine redaktionellen Lücken. Sie beeinflussen, wie Sie Bewertungen planen und budgetieren.

Was wir mit Sicherheit wissen

• Der CRA wird ausdrücklich als Quelle für die Anforderungen des Schemas zitiert.
• SBOM in maschinenlesbarem Format ist verpflichtend.
• ISO 27001 allein genügt nicht, um organisatorische Kontrollanforderungen zu erfüllen.
• Selbstbewertung ist auf keinem Assurance-Level für EUDIW-Komponenten zulässig.
• Die Zertifikatsgültigkeit ist auf 5 Jahre begrenzt.

Unsere Analyse (nicht bestätigt)

• CRA-Konformitätsbewertungsschemata werden wahrscheinlich ähnlichen Mustern bei SBOM-Anforderungen, CVD-Richtlinie und der Unzulänglichkeit 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 unabhängige Zertifizierungen zu verlangen, nicht nur Selbsterklärungen.
• SOC-2-Zuordnung ist eine echte Chance. Wenn Sie jetzt mit Ihrem Auditor zusammenarbeiten, um eine Kriterienzuordnung zu EU-Cybersicherheitsanforderungen zu strukturieren, können Sie Ihr nächstes SOC-2-Typ-II für eine bedingte Anerkennung positionieren, anstatt bei null anzufangen.

Was noch niemand weiß

• Wann ein CRA-spezifisches Zertifizierungsschema veröffentlicht 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-Kapazität im Verhältnis zur Nachfrage entwickeln wird, wenn mehrere Schemata gleichzeitig aktiv sind.

Was Hersteller jetzt tun sollten

Das Konsultationsfenster und die endgültige Schema-Veröffentlichung geben Ihnen ein definiertes Zeitfenster zur Vorbereitung. Dies sind konkrete Schritte, keine allgemeinen Ratschläge.

• Verstehen Sie Ihren Konformitätsbewertungsweg. Die Assurance-Level des Schemas korrespondieren mit unterschiedlichen Produktkategorien. Was für Sie gilt, ist nicht immer offensichtlich. Nutzen Sie einen strukturierten Entscheidungsprozess, bevor Sie annehmen, Ihren Weg zu kennen. Beginnen Sie mit dem Leitfaden zur Konformitätsbewertung.

• Bauen Sie Nachweise jetzt auf. SBOMs, Risikoabschätzungen, Schwachstellenoffenlegungsrichtlinien und technische Unterlagen brauchen Zeit, um korrekt erstellt zu werden. Beginnen Sie während der Konsultationsphase, können 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 für Cybersicherheitsgewährleistung aufgebaut ist, haben Sie eine Lücke. Identifizieren Sie, welche Kontrollen einer unabhängigen Verifizierung bedürfen.

• Strukturieren Sie Ihr nächstes 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 künftig 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 ändert.

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

Wie CRA Evidence hilft

CRA Evidence unterstützt 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 übereinstimmen.
• VDP mit CVD-Workflow: Veröffentlichen 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 prüfsicheren Aufzeichnungen für jede Meldung.
• Lieferantenportal: Verwalten Sie vor- und nachgelagerte Meldungen innerhalb Ihrer Lieferkette, mit dokumentierten Kommunikationsnachweisen für technische Unterlagen.

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

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