Der CRA macht Cybersicherheit zur Pflicht. In diesem Artikel zeigen wir, wie Hersteller mit der EUCC-Zertifizierung und den BSI-Richtlinien (TR-03183) strukturiert und nachvollziehbar die Anforderungen erfüllen – inklusive Vergleichen, Beispielen und praktischer Umsetzungshilfe.
Dieser Artikel wurde erstmals am 04.06.2025 veröffentlicht und am 03.09.2026 auf Basis des zu diesem Zeitpunkt bekannten Rechts- und Informationsstands aktualisiert.
Unsere bisherigen Beiträge zum CRA bieten eine solide Grundlage, um die Anforderungen des CRA zu verstehen und erste Schritte zur Umsetzung zu planen. In diesem Artikel gehen wir einen Schritt weiter: Wir beleuchten zwei zentrale Hilfsmittel zur praktischen Umsetzung der CRA-Anforderungen:
Die EUCC-Zertifizierung als formalisierter technischer Nachweis
Die BSI-Richtlinie TR-03183 als praxisnahe Auslegungshilfe
Refresher: Was fordert der CRA?
Der Cyber Resilience Act (Verordnung 2024/2847) verpflichtet Hersteller, dass ihre Produkte mit digitalen Elementen:
sicher entwickelt
angemessen gegen Cyberangriffe geschützt
über den gesamten Lebenszyklus wart- und patchbar
Hersteller müssen:
eine Cyber-Risikoanalyse vorlegen
konkrete Sicherheitsmaßnahmen technisch umsetzen
technischen Dokumentation nachweisen
Zwei Wege zur Umsetzung: EUCC und TR-03183
Die EUCC (European Union Common Criteria) ist eine offizielle EU-Zertifizierung für Cybersicherheit. Sie basiert auf dem Standard ISO/IEC 15408 und ermöglicht es, technische Sicherheitsfunktionen formell prüfen und zertifizieren zu lassen.
Die BSI TR-03183 ist eine hilfreiche technische Orientierungshilfe des Bundesamts für Sicherheit in der Informationstechnik (BSI).
Sie beinhaltet keinen formalen Zertifizierungsprozess, ist nicht verbindlich und erzeugt keine Konformitätsvermutung.
Ihre aktuellen Teile und Versionen ordnen wir weiter unten ein.
Unterschiede zwischen EUCC und TR-03183
Sowohl EUCC als auch TR-03183 zielen darauf ab, die Anforderungen des CRA umzusetzen, aber sie tun das mit sehr unterschiedlichem Anspruch, Aufwand und Zielsetzung. Hier sind die wichtigsten Unterschiede:
Rechtsstatus und Zielsetzung
Kriterium
EUCC
TR-03183
Rechtsstatus
EU-weites Zertifizierungsschema nach CSA-Verordnung
Nationale Technische Richtlinie des BSI
Ziel
Formale Zertifizierung (z. B. für „wichtige“ Produkte)
Technische Orientierung und Unterstützung zur CRA-Umsetzung
Verbindlichkeit
Kann eingesetzt werden, wenn die Kommission das Schema für den CRA-Nachweis vorgesehen hat und die einschlägigen Anforderungen abgedeckt sind
Nicht verbindlich und keine Konformitätsvermutung
Prüfverfahren und Aufwand
Kriterium
EUCC
TR-03183
Audit erforderlich?
Ja – durch externes, akkreditiertes ITSEF-Prüflabor
Nein – Eigenbewertung durch Hersteller oder Dritte möglich
Aufwand
Hoch (u. a. Security Target, Testreports, Schwachstellenanalyse, Pen-Tests)
Mittel (strukturierte Umsetzung, aber ohne formale Prüfung)
Zertifikat?
Ja – durch benannte Stelle (CAB)
Nein – unterstützt die Dokumentation, ersetzt den Konformitätsnachweis aber nicht
Gültigkeit und Anerkennung
Kriterium
EUCC
TR-03183
Gültigkeit
EU-weit anerkanntes Zertifikat
Nationale Orientierungshilfe, keine internationale Wirkung
Verwendung im CRA
Konformitätsvermutung nach Art. 27 CRA möglich
Nur als Hilfe zur Selbstbewertung, kein Konformitätsnachweis
Technische Tiefe und Formalismus
Kriterium
EUCC
TR-03183
Technischer Detaillierungsgrad
Hoch, modular durch Security Functional & Assurance Requirements
Hoch, in die Teile -1, -2, -3 und -H gegliedert
Formalisierungsgrad
Sehr hoch (Common Criteria-Dokumentation erforderlich)
Mittel (strukturierte Anforderungen mit Prüfmethoden)
Nutzbarkeit für spätere Zertifizierung
Ja – strukturell vorbereitet für EUCC
Ja – als Vorstufe nutzbar
Entscheidungshilfe zur Nutzung
Für Hersteller von Produkten, die gemäß CRA nicht als wichtig oder kritisch eingestuft sind, ist eine Zertifizierung wie EUCC nicht generell verpflichtend. Stattdessen erlaubt der CRA grundsätzlich eine interne Kontrolle auf Basis einer fundierten Risikoanalyse.
Die BSI TR-03183 kann dafür eine detaillierte technische Orientierung bieten. Sie reicht jedoch nicht allein aus, um CRA-Konformität abzuleiten: Hersteller müssen alle anwendbaren CRA-Anforderungen bewerten, den gewählten Konformitätsweg durchführen und die Ergebnisse nachvollziehbar dokumentieren.
EUCC ist dort relevant, wo für den konkreten Produkttyp ein passendes europäisches Zertifizierungsschema genutzt werden kann und ein formaler Zertifizierungsnachweis sinnvoll oder erforderlich ist. Bei Critical Products nach Anhang IV ist nicht pauschal EUCC vorgeschrieben, sondern ein europäisches Cybersicherheitszertifizierungsschema oder ein Drittbewertungsweg gemäß Artikel 32 CRA.
Aktuelle Teile der BSI TR-03183
Die BSI TR-03183 wird fortlaufend weiterentwickelt. Zum Rechts- und Informationsstand 03.09.2026 sind diese Teile aktuell:
Anforderungen für die Konformitätsbewertung mit vollständiger Qualitätssicherung nach Modul H
Für eine belastbare Umsetzung sollten Hersteller die jeweils relevante aktuelle Teilversion, Bezugsquelle, Anwendbarkeit und offene Lücken pro Produkt dokumentieren.
Die Technischen Richtlinien sind eine Vorbereitungshilfe und können durch künftig verfügbare harmonisierte europäische Normen ersetzt werden.
Hersteller, die mit den jeweils einschlägigen aktuellen Teilen der TR-03183 arbeiten, schaffen eine strukturierte Grundlage für ihre technische Dokumentation und Konformitätsbewertung. Die Anwendung ersetzt jedoch weder eine spätere EUCC-Zertifizierung noch eine eigene Konformitätserklärung.
EUCC-Zertifizierung
Wenn eine interne Konformitätsbewertung nicht ausreicht oder ein passendes Zertifizierungsschema für den Produkttyp genutzt werden soll, ist der Schritt zur EUCC-Zertifizierung zu prüfen.
Hersteller: Definiert den Scope (TOE) und liefert Doku.
Prüflabor (ITSEF): Bewertet Design, führt Tests & Pen-Tests durch.
Zertifizierungsstelle (CAB): Validiert alles und vergibt das EUCC-Zertifikat.
Für den CRA lässt sich kein pauschales EUCC-Level festschreiben. Welches Assurance-Level sinnvoll ist, hängt vom Produkttyp, dem anwendbaren Schema und dem angestrebten Nachweis ab.
Das EUCC-Schema orientiert sich an den sogenannten Evaluation Assurance Levels (EALs) aus den Common Criteria. Dabei beschreibt EAL2 ein grundlegendes Niveau an Sicherheitsprüfung – inklusive strukturierter Tests, Überprüfung von Design-Dokumentation und einer systematischen Schwachstellenanalyse. Das Plus-Symbol (EAL2+) steht für zusätzliche, individuell gewählte Prüfkomponenten (z. B. AVA_VAN.3 statt AVA_VAN.2), die über das Minimum hinausgehen, aber noch nicht den vollen Umfang von EAL3 oder höher erreichen.
Laut ENISA – EUCC Scheme ist das Zertifizierungsniveau „substantial“ ein typisches Ziel für viele Produkte unterhalb der Hochsicherheitsklasse. Daraus folgt jedoch nicht automatisch, dass es für jedes CRA-Produkt ausreicht. Ob ein EUCC-Nachweis die Konformitätsvermutung nach Art. 27 CRA unterstützt, hängt davon ab, dass ein einschlägiges europäisches Zertifizierungsschema für den Produkttyp existiert und die relevanten Anforderungen tatsächlich abdeckt.
Fazit: EUCC und TR-03183 als strategische Werkzeuge
Mit der EUCC-Zertifizierung steht ein europaweit anerkanntes Verfahren bereit, das geprüfte Sicherheit dokumentiert. Die BSI TR-03183 liefert dazu eine praxisnahe technische Orientierung für alle, die sich systematisch vorbereiten oder intern evaluieren möchten.
Beide Ansätze ergänzen sich und ermöglichen eine fundierte, effiziente und revisionssichere Umsetzung des CRA. Die EUCC ist dabei kein pauschaler Pflichtweg, sondern ein starkes Instrument dort, wo das Schema zum Produkttyp und zum geforderten Nachweis passt. TR-03183 bildet die pragmatische Brücke dorthin.
Unser CRA-Workshop bietet Ihnen einen kompakten Einstieg und hilft, betroffene Produkte und Pflichten zu identifizieren.
Lars ist Solution Consultant und berät Unternehmen und Entwicklungsteams ganzheitlich bei der Umsetzung ihrer Softwareentwicklungsprojekte, von den Prozessen über die Anforderungen und Architekturen bis hin zu Umsetzung und Betrieb.
Der Cyber Resilience Act schafft erstmals eine eigene Rolle für Open-Source-Verantwortliche. Dieser Artikel erklärt, wer als Open Source Steward gilt, welche Pflichten Art. 24 CRA tatsächlich fordert und was Hersteller beim Einsatz von Open Source beachten müssen.
Der Cyber Resilience Act schreibt je nach Produktkategorie unterschiedliche Konformitätsbewertungsverfahren vor. Dieser Artikel zeigt, welches Verfahren für welches Produkt gilt und wie Hersteller Schritt für Schritt zur CE-Kennzeichnung gelangen.
Unser Artikel in der dotnetpro 3/26 zeigt, warum der Cyber Resilience Act kein reines Compliance-Thema ist, sondern ein ehrlicher Reifegradtest für Softwareentwicklung und Produktverantwortung.
Der Cyber Resilience Act endet nicht an der eigenen Fabrikhalle: Dieser Artikel zeigt, was Hersteller aus Maschinenbau und Industrie von ihren Lieferanten fordern müssen und wie SBOM, Assessments und Vertragsklauseln die Lieferkette absichern.
Der CRA verlangt grundsätzlich ab dem 11. Dezember 2027 eine CVD-Policy und eine Kontaktstelle. Warum Hersteller beides bereits für die Meldepflichten ab September 2026 vorbereiten sollten.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über ENISAs Single Reporting Platform melden. Dieser Beitrag erklärt Meldeweg, Fristen und Umsetzung.
SECURE Call 1 ist geschlossen. Dieser Artikel ordnet SECURE, offene EU-Calls und technische Unterstützungsangebote für die CRA-Umsetzung im September 2026 ein.
Wie Hersteller den Supportzeitraum für Produkte mit digitalen Elementen aus Nutzung, Architektur, Lieferkette und Updatefähigkeit nachvollziehbar ableiten.