Die CE-Kennzeichnung wird durch den CRA um Cybersecurity erweitert: Ab dem 11. Dezember 2027 dürfen digitale Produkte nur mit nachgewiesener Cybersecurity-Konformität auf den EU-Markt, analog zur CE-Kennzeichnung für KI bei Hochrisiko-Systemen nach der EU-VO 2024/1689. Für Hersteller bedeutet das: Ohne belastbare Konformitätsbewertung, technische Dokumentation und EU-Konformitätserklärung gibt es keine saubere Marktbereitstellung mehr.
Rechtlich ist der Rahmen klar. Die Verordnung (EU) 2024/2847, der Cyber Resilience Act, gilt seit dem 10. Dezember 2024 und wird nach Art. 71 ab dem 11. Dezember 2027 vollständig anwendbar; die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle starten bereits am 11. September 2026. Für Geschäftsführung, Produktverantwortliche, Compliance, Security und Entwicklung ist die entscheidende Frage deshalb nicht, ob Cybersecurity Teil der CE-Kennzeichnung wird, sondern welches Verfahren für das eigene Produkt gilt und welche Unterlagen bis zur Markteinführung vorliegen müssen. Für die begriffliche Einordnung helfen daneben die Glossar-Einträge zu Konformitätsbewertung, Konformitätserklärung und technischer Dokumentation.
Was die CE-Kennzeichnung künftig auch für Cybersecurity bedeutet
Die CE-Kennzeichnung steht unter dem CRA nicht mehr nur für klassische Produktsicherheit, sondern auch für nachgewiesene Cybersecurity über den gesamten Produktlebenszyklus. Art. 3 Nr. 31 der EU-VO 2024/2847 definiert die CE-Kennzeichnung im CRA ausdrücklich als Zeichen dafür, dass Produkt und Herstellerprozesse den wesentlichen Cybersecurity-Anforderungen aus Anhang I entsprechen. Wer den Gesamtzusammenhang vertiefen möchte, sollte die Nachweiskette aus Konformitätsbewertung, EU-Konformitätserklärung und technischer Dokumentation als zusammenhängendes System verstehen.
Praktisch heißt das: Hersteller erklären nicht nur, dass ein Gerät elektrisch sicher ist oder andere sektorspezifische Regeln erfüllt werden. Sie erklären zusätzlich, dass Sicherheitsanforderungen wie Secure-by-Design, angemessene Voreinstellungen, Schwachstellenmanagement, Sicherheitsupdates und der Umgang mit bekannten Komponenten umgesetzt wurden. Die CE-Kennzeichnung wird damit faktisch zum sichtbaren Cybersecurity-Nachweis für Produkte mit digitalen Elementen.
Wichtig ist die Abgrenzung zum Marketing. Die CRA-CE-Kennzeichnung ist kein freiwilliges Gütesiegel und kein allgemeines „Cybersecurity-Siegel“, das sich Unternehmen selbst verleihen können. Sie ist ein gesetzlich gebundener Marktzugangsnachweis. Wer das Zeichen anbringt, ohne die Anforderungen zu erfüllen, setzt sich Marktaufsicht, Vertriebsstopps und Bußgeldern aus.
Ebenso wichtig ist die Abgrenzung zum AI Act. Beim CRA geht es um die Cybersecurity von Produkten mit digitalen Elementen, also etwa Software, vernetzte Geräte und erforderliche Remote-Processing-Lösungen. Beim AI Act geht es um KI-spezifische Pflichten für Hochrisiko-KI. Die Logiken sind verwandt, aber nicht identisch; parallel wirken in vielen Lieferketten außerdem NIS2-Vorgaben zur organisatorischen Cybersicherheit und ISO 42001 als Managementsystemstandard für KI-Governance. Wenn Sie die Systematik des CRA zuerst im Überblick einordnen wollen, helfen die Begriffe Konformitätsbewertung und Konformitätserklärung als Grundlage für beide Regime.
Konformitätsbewertung nach dem CRA — 3 Verfahren
Der CRA kennt für Produkte mit digitalen Elementen drei praktische Konformitätsbewertungsverfahren nach Art. 32 und Anhang VIII. Diese drei Wege entscheiden darüber, ob der Hersteller selbst bewertet oder ob eine notifizierte Stelle eingebunden werden muss.
1. Interne Kontrolle nach Modul A
Die interne Kontrolle nach Modul A ist das Standardverfahren für normale Produkte mit digitalen Elementen. Der Hersteller erstellt die technische Dokumentation, prüft die Einhaltung der wesentlichen Anforderungen aus Anhang I selbst und erklärt in eigener Verantwortung die Konformität. Dieses Verfahren ist besonders relevant für Standardsoftware, vernetzte Consumer-Produkte und sonstige Produkte, die nicht in den besonderen Klassen des Anhangs III oder IV landen.
2. EU-Baumusterprüfung plus interne Fertigungskontrolle nach Modul B + C
Das Verfahren Modul B plus C kombiniert eine externe Prüfung des technischen Entwurfs mit einer anschließenden internen Produktionskontrolle. Zuerst prüft eine notifizierte Stelle die technische Auslegung, die Risikobewertung und die Vulnerability-Handling-Prozesse. Danach stellt der Hersteller intern sicher, dass die tatsächlichen Produkte dem geprüften Typ entsprechen. Dieses Verfahren ist typisch für wichtige Produkte mit digitalen Elementen, wenn eine reine Selbstbewertung nicht ausreicht.
3. Vollständige Qualitätssicherung nach Modul H
Modul H ist das umfassendste Verfahren. Hier bewertet eine notifizierte Stelle nicht nur ein Einzelprodukt, sondern das gesamte Qualitäts- und Konformitätssystem des Herstellers. Das ist vor allem für Hersteller mit reifen Security- und Qualitätsprozessen attraktiv, die viele Produkte oder Produktfamilien strukturiert absichern wollen. Für komplexere Herstellerorganisationen kann Modul H effizienter sein als eine Vielzahl einzelner Prüfungen.
Die Logik des CRA lässt sich so verdichten:
| Produktkategorie | Typischer Weg | Drittprüfung nötig? | Praktische Folge |
|---|---|---|---|
| Standardprodukt | Modul A | Nein | Hersteller bewertet selbst und dokumentiert vollständig |
| Wichtiges Produkt Klasse I | Modul A nur bei vollständiger Anwendung einschlägiger Standards oder Spezifikationen, sonst Modul B + C oder H | Oft ja | Standards werden zum Hebel für Selbstbewertung |
| Wichtiges Produkt Klasse II | Modul B + C oder H, alternativ geeignetes Zertifizierungsschema | Ja, grundsätzlich | Drittprüfung ist der Regelfall |
Diese Dreiteilung ist für die Umsetzungsplanung zentral. Viele Teams sprechen pauschal von „dem CRA-Audit“. Tatsächlich verlangt die Verordnung aber zunächst eine saubere Klassifizierung des Produkts und erst danach die Wahl des passenden Verfahrens.
Selbstbewertung vs. Drittprüfung — Wann welches Verfahren?
Die wichtigste Antwort zuerst: Selbstbewertung bleibt unter dem CRA möglich, aber nicht grenzenlos. Art. 32 Abs. 1 erlaubt für Produkte mit digitalen Elementen grundsätzlich die interne Kontrolle nach Modul A. Für wichtige Produkte nach Anhang III zieht der CRA die Schwelle jedoch deutlich an.
Für Standardprodukte außerhalb der Klassen I und II ist Selbstbewertung der normale Weg. Der Hersteller muss dann trotzdem dieselbe Sorgfalt anwenden wie bei extern geprüften Produkten: Risikoanalyse, sichere Entwicklung, Dokumentation, Support-Zeitraum, Update-Mechanismen und Schwachstellenmanagement müssen nachweisbar sein. „Selbstbewertung“ bedeutet also nicht „geringerer Standard“, sondern nur „ohne externe Prüfstelle“. Genau diese Verwechslung ist in der Praxis häufig, wenn Teams den CRA nur aus einer Vertriebs- oder Label-Perspektive betrachten und die eigentliche Nachweisarbeit unterschätzen.
Für wichtige Produkte der Klasse I ist die Lage differenzierter. Selbstbewertung funktioniert nur dann belastbar, wenn harmonisierte Normen, gemeinsame Spezifikationen oder geeignete europäische Cybersicherheitszertifizierungsschemata vollständig angewandt werden. Fehlen diese Grundlagen, werden sie nur teilweise angewandt oder existieren sie noch nicht, verlangt Art. 32 Abs. 2 den Wechsel zu Modul B plus C oder zu Modul H. Genau hier liegt für viele Hersteller das eigentliche Compliance-Risiko: Nicht die Produktidee ist problematisch, sondern die falsche Annahme, man könne ohne belastbare Normenbasis intern freizeichnen.
Für wichtige Produkte der Klasse II ist die Schwelle nochmals höher. Art. 32 Abs. 3 sieht hier grundsätzlich Drittprüfung vor, entweder über Modul B plus C, Modul H oder ein geeignetes europäisches Cybersicherheitszertifizierungsschema auf mindestens „substantial“-Niveau. Typische Klasse-II-Beispiele aus Anhang III sind Firewalls, Intrusion-Detection- und Prevention-Systeme oder bestimmte manipulationsresistente Mikrocontroller.
Für Softwarehersteller ist das besonders relevant, weil Anhang III auch reine Softwarekategorien nennt. Dazu gehören etwa Betriebssysteme, Passwortmanager, Browser, VPN-Produkte, SIEM-Systeme oder Identitäts- und Zugriffsmanagementlösungen. Wer solche Software unter eigener Marke auf den EU-Markt bringt, sollte früh prüfen, ob die eigene Produktkategorie in Klasse I oder II fällt. Die CE-Frage ist dann keine Vertriebsfrage mehr, sondern eine Architektur- und Release-Management-Frage. Parallel kann NIS2 dort relevant werden, wo dieselben Hersteller selbst regulierte Einrichtungen betreiben oder an kritische Sektoren liefern; organisatorische Resilienz ersetzt die produktbezogene CRA-Konformität aber nicht.
EU-Konformitätserklärung — Was rein muss
Die EU-Konformitätserklärung ist der formale Rechtsakt, mit dem der Hersteller die Verantwortung übernimmt. Nach Art. 28 und Anhang V der EU-VO 2024/2847 gehört sie zwingend zur CE-Kennzeichnung dazu. Ohne Erklärung keine rechtssichere Anbringung des CE-Zeichens.
Inhaltlich muss die Erklärung mindestens folgende Punkte abdecken:
- eindeutige Identifikation des Produkts
- Name und Anschrift des Herstellers oder Bevollmächtigten
- Erklärung, dass die Konformität in alleiniger Verantwortung des Herstellers erfolgt
- Beschreibung des Produkts mit Rückverfolgbarkeit
- Aussage, dass das Produkt die einschlägige Harmonisierungsrechtsvorschrift erfüllt
- Verweise auf verwendete harmonisierte Normen, gemeinsame Spezifikationen oder Cybersicherheitszertifizierungsschemata
- falls relevant: Name und Kennnummer der notifizierten Stelle, beschriebenes Verfahren und Zertifikat
- Ort, Datum, Name, Funktion und Unterschrift
Die Erklärung ist damit kein kurzes Marketingblatt, sondern die komprimierte juristische Zusammenfassung der gesamten Konformitätsarbeit. Sie muss zur technischen Dokumentation passen, dieselbe Produktversion abdecken und bei Änderungen aktualisiert werden. Importeur, Distributor und Marktaufsicht verlassen sich darauf, dass die Erklärung die tatsächliche Compliance-Lage zutreffend abbildet.
Der CRA erlaubt außerdem eine vereinfachte EU-Konformitätserklärung, wenn die vollständige Fassung über eine angegebene Internetadresse abrufbar ist. Das entlastet vor allem Hersteller digitaler Produkte. Entlastung heißt aber nicht Beliebigkeit: Die vollständige Erklärung muss existieren, aktuell sein und auf Anfrage vorgelegt werden können.
Technische Dokumentation als Grundlage der CE-Kennzeichnung
Die technische Dokumentation ist das Rückgrat der CRA-CE-Kennzeichnung. Art. 31 verlangt, dass sie vor dem Inverkehrbringen erstellt und während des Support-Zeitraums laufend aktualisiert wird. Anhang VII konkretisiert, was mindestens hineinmuss.
Zum Mindestinhalt gehören insbesondere:
- allgemeine Produktbeschreibung und Zweckbestimmung
- Versionsstände der Software, soweit sie die Compliance beeinflussen
- Benutzerinformationen und Anleitungen
- Beschreibung von Design, Entwicklung und Produktion
- Beschreibung der Vulnerability-Handling-Prozesse
- gegebenenfalls die Software Bill of Materials
- Risikoanalyse und Risikobewertung
- Nachweise zu angewandten Normen oder alternativen Lösungen
- Testberichte zur Verifikation der Anforderungen
- Kopie der EU-Konformitätserklärung
In der Praxis scheitern Projekte selten an der Idee der Dokumentation, sondern an ihrer Fragmentierung. Security hält Testberichte vor, Entwicklung kennt die Abhängigkeiten, Product besitzt die Release-Historie, Legal entwirft die Erklärung und niemand führt alles in einer prüffähigen Akte zusammen. Unter dem CRA reicht das nicht. Die Dokumentation muss so strukturiert sein, dass eine Behörde nachvollziehen kann, wie Anforderungen aus Anhang I erfüllt wurden.
Für Hersteller von Standardsoftware ist das oft Neuland, weil sie bisher eher nach Release Notes, Tickets und Security Advisories gearbeitet haben. Diese Unterlagen bleiben nützlich, ersetzen aber kein CRA-Dossier. Ein belastbares Dokumentationssystem sollte deshalb technische Architektur, Bedrohungsmodell, verwendete Komponenten, Update-Prozess, Support-Ende und Testnachweise in einer konsistenten Akte verbinden.
CE-Kennzeichnung für Software — Neuland für viele Hersteller
Ja, Software kann unter dem CRA CE-pflichtig sein. Art. 3 Nr. 1 definiert ein Produkt mit digitalen Elementen ausdrücklich als Software- oder Hardwareprodukt einschließlich zugehöriger Remote-Data-Processing-Lösungen. Art. 2 erfasst zudem Produkte, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu Gerät oder Netzwerk einschließt.
Für viele Hersteller ist das deshalb ein Paradigmenwechsel. Bisher wurde CE vor allem mit physischen Geräten verbunden. Der CRA zieht nun ausdrücklich auch Standalone-Software und notwendige Remote-Processing-Funktionen in die Logik ein. Art. 30 regelt sogar gesondert, wie die CE-Kennzeichnung bei Software angebracht wird: entweder in der EU-Konformitätserklärung oder auf der Website, die das Softwareprodukt begleitet.
Wichtig ist aber die Präzision: Nicht jede denkbare Cloud- oder SaaS-Leistung fällt automatisch unter den CRA. Remote-Datenverarbeitung ist nur dann erfasst, wenn sie vom Hersteller für das Produkt entworfen oder verantwortet wird und ihr Fehlen eine Produktfunktion verhindern würde. Reine Unternehmens-IT-Sicherheit oder das gesamte Netz des Herstellers werden dadurch nicht pauschal reguliert. Diese Differenz ist für Softwareunternehmen zentral.
Ebenso wichtig ist die Open-Source-Frage. Reine freie Open-Source-Software ohne kommerzielle Marktbereitstellung ist nicht automatisch CRA-pflichtig. Beiträge zum Quellcode außerhalb eigener Verantwortung lösen die Herstellerpflichten nicht aus. Sobald Open-Source-Komponenten aber in ein kommerziell bereitgestelltes Produkt integriert oder unter eigener Marke angeboten werden, bleibt die Herstellerverantwortung bestehen. Open Source ist also kein Freibrief gegen CE-Pflichten.
Marktüberwachung und Sanktionen bei falscher CE-Kennzeichnung
Die CRA-CE-Kennzeichnung ist nur so belastbar wie die Marktüberwachung dahinter. Der CRA verknüpft die Herstellerpflichten deshalb mit Korrekturmaßnahmen, Informationspflichten und Bußgeldrahmen. Wer ein nicht konformes Produkt mit CE-Zeichen in Verkehr bringt, riskiert nicht nur juristische Sanktionen, sondern auch Rückrufe, Vertriebsstopps und operative Folgekosten.
Art. 64 unterscheidet dabei zwischen verschiedenen Sanktionsstufen. Verstöße gegen die wesentlichen Cybersecurity-Anforderungen und gegen zentrale Herstellerpflichten können mit bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden. Verstöße gegen Pflichten zur Konformitätserklärung, CE-Anbringung, technischen Dokumentation oder zu den Konformitätsbewertungsverfahren können mit bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes sanktioniert werden.
Für Hersteller ist die operative Konsequenz klar: Falsche CE-Kennzeichnung ist kein reines Formalproblem. Wenn die Konformitätsbewertung falsch gewählt wurde, die Dokumentation lückenhaft ist oder die Erklärung nicht zur ausgelieferten Version passt, steht nicht nur ein Papierfehler im Raum. Dann fehlt der rechtliche Nachweis für die Marktbereitstellung selbst. Die Marktüberwachung prüft damit nicht nur, ob ein Logo korrekt angebracht wurde, sondern ob der gesamte Compliance-Prozess von Design über Tests bis zum Schwachstellenmanagement tatsächlich funktioniert.
Besonders sensibel wird das in Lieferketten. Importeure und Distributoren müssen prüfen, ob CE-Zeichen, Unterlagen und Herstellerangaben vorliegen. Wer als Hersteller hier unsauber arbeitet, verursacht also nicht nur ein internes Problem, sondern blockiert Beschaffung, Vertrieb und Partnervertrauen. Genau deshalb sollten CRA-Anforderungen früh mit Produktmanagement, Security, Legal und Release-Prozess verzahnt werden.
Häufig gestellte Fragen (FAQ)
Braucht Software jetzt eine CE-Kennzeichnung?
Software braucht nicht pauschal „jetzt“ eine neue CE-Kennzeichnung. CE-relevant wird Software unter dem CRA dann, wenn sie als Produkt mit digitalen Elementen in den Anwendungsbereich der Verordnung fällt und ab dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wird. Das betrifft ausdrücklich auch Standalone-Software und bestimmte notwendige Remote-Processing-Lösungen.
Wer darf die Konformitätsbewertung durchführen?
Die Konformitätsbewertung startet immer beim Hersteller. Je nach Produktkategorie darf er sie intern nach Modul A durchführen oder muss eine notifizierte Stelle für Modul B plus C oder Modul H einbinden. Für wichtige Produkte der Klasse II ist Drittprüfung grundsätzlich vorgesehen; für Klasse I hängt sie stark von der Nutzung einschlägiger Standards oder Spezifikationen ab.
Was passiert bei falscher CE-Kennzeichnung?
Bei falscher CE-Kennzeichnung drohen Korrekturmaßnahmen durch die Marktüberwachung, bis hin zu Rücknahme oder Rückruf. Zusätzlich greifen Bußgeldrahmen nach Art. 64 der EU-VO 2024/2847. Für Hersteller ist das Risiko deshalb nicht nur behördlich, sondern auch geschäftlich relevant.
Gilt die CE-Pflicht auch für Open-Source-Software?
Nicht in jedem Fall. Frei geteilte Open-Source-Software ohne kommerzielle Marktbereitstellung ist anders zu behandeln als kommerziell bereitgestellte Produkte. Sobald ein Hersteller Open-Source-Bestandteile in ein eigenes vermarktetes Produkt integriert oder das Gesamtprodukt unter eigener Marke anbietet, trägt er aber die CRA-Verantwortung für das Produkt insgesamt.
Was ist der Unterschied zwischen CRA- und AI-Act-CE-Kennzeichnung?
Die CRA-CE-Kennzeichnung bezieht sich auf Cybersecurity von Produkten mit digitalen Elementen nach der EU-VO 2024/2847. Die CE-Kennzeichnung nach dem AI Act bezieht sich auf Hochrisiko-KI nach der EU-VO 2024/1689. Beide Regime können sich in intelligenten, vernetzten Produkten überschneiden, prüfen aber unterschiedliche Anforderungen und Nachweise.
Nächster Schritt für Hersteller
Der pragmatische nächste Schritt ist eine frühe CRA-Gap-Analyse pro Produktlinie: Produktklasse bestimmen, passendes Konformitätsverfahren festlegen, technische Dokumentation strukturieren und die EU-Konformitätserklärung nicht erst kurz vor Go-live entwerfen. Wenn Sie dafür im Unternehmen ein gemeinsames Grundverständnis zu regulatorischen Pflichten aufbauen wollen, nutzen Sie unseren EU AI Act Kurs als strukturierten Einstieg in Governance, Nachweislogik und regulatorische Rollen im Produktumfeld.
Wenn Sie CRA, AI Act, NIS2 und ISO-42001-Bezüge nicht isoliert behandeln wollen, ist ein gemeinsames Begriffsverständnis der schnellste Startpunkt. Der Kurs hilft Fachbereichen, Compliance und Führung dabei, Rollen, Nachweise und regulatorische Schnittstellen einheitlich zu verstehen, bevor produktbezogene CRA-Projekte in die Tiefe gehen.