Wer digitale Produkte in Europa verkaufen will, kennt das Spiel mit der CE-Kennzeichnung: technische Unterlagen zusammenstellen, Konformität erklären, Label aufkleben, fertig. Zumindest war es lange so. Mit dem Cyber Resilience Act (CRA) beginnt eine neue Ära. Das CE-Zeichen bleibt, doch sein Inhalt wandelt sich grundlegend. Neben elektrischer Sicherheit, EMV und Produkthaftung rückt nun Cybersicherheit in den Mittelpunkt – nicht als freiwillige Beigabe, sondern als zwingende Marktzutrittsbedingung.
Dieser Text erklärt – ohne Angst, aber ohne Beschönigung – was das praktisch bedeutet. Er richtet sich an Produktmanager, CTOs, Compliance-Verantwortliche, Gründerinnen und Gründer, Einkäufer und Integratoren. Er erzählt, wie man vom ersten Architekturentwurf bis zur letzten Seriennummer CE-fähig bleibt, warum die Dokumentation plötzlich strategisch wird, wieso Vulnerability-Handling und Meldepflichten zu einem neuen „Betriebssystem“ für Hersteller werden – und an welchen Stellen Unternehmen erfahrungsgemäß stolpern. Alles in flüssigem Text, mit punktuellen Einschüben dort, wo es das Verständnis erleichtert.
Was „CE unter dem CRA“ wirklich heißt
Bislang stand das CE-Zeichen sinnbildlich dafür, dass „alles Passt“: elektrische Sicherheit, mechanische Stabilität, elektromagnetische Verträglichkeit, manchmal Ökodesign, bei Funkgeräten Funk-Compliance. Mit dem CRA kommt eine weitere Schiene hinzu: Sicherheitsanforderungen an Produkte mit digitalen Elementen. Das umfasst Software-only-Produkte ebenso wie vernetzte Geräte. Entscheidend ist nicht, ob etwas einen Stecker hat oder ein Gehäuse – entscheidend ist, ob Funktionen digital bereitgestellt werden und Risiken über Software/Netz entstehen können.
Die Folge ist tiefgreifend: Ohne nachweisbar angemessene Cybersecurity gibt es keine CE-Konformität. Und ohne CE kein Inverkehrbringen im Europäischen Wirtschaftsraum. Hersteller, die bislang dachten, „Security machen wir irgendwann nach Release 1.0“, wechseln unfreiwillig die Reihenfolge: Sicherheit wird zur Eintrittskarte.
Wer betroffen ist – und wer glaubt, nicht betroffen zu sein
„Wir bauen nur Software.“ – Betroffen.
„Wir verkaufen ein Gateway, das offline läuft.“ – Betroffen.
„Wir bündeln Open-Source-Pakete und liefern Support.“ – Betroffen (als Hersteller).
„Wir importieren und kleben nur unser Label drauf.“ – Betroffen (als Importeur/Quasi-Hersteller).
„Wir sind Händler, wir packen nur Kartons aus.“ – Betroffen (als Wirtschaftsakteur mit Prüf- und Sorgfaltspflichten).
Nicht betroffen sind lediglich reine Dienstleistungen (klassisches SaaS ohne Produktstatus) sowie Open-Source-Software, sofern sie ohne Gewinnerzielungsabsicht entwickelt und bereitgestellt wird. Wer jedoch OSS kommerzialisierst – also bündelt, vertreibt, integriert, Support verkauft – übernimmt die Herstellerrolle und damit die Pflichten. Für kritische Produktkategorien (z. B. Passwortmanager, Identity-/Access-Management, Firewalls, Router, Betriebssysteme, Hypervisoren, industrielle Steuerungen und weitere Kern-Infrastrukturen) gelten verschärfte Wege der Konformitätsbewertung. Das ändert nichts am Ziel, aber an der Tiefe des Nachweises.
Die Praxisregel ist simpel: Wenn Ihr Produkt Software enthält oder Software ist und Kunden es als Produkt kaufen, planen Sie CRA-Pflichten ein. Punkt.
Von der Idee zur CE-Erklärung: der Weg in verständlicher Sprache
Die juristischen Texte lesen sich abgehoben – der tatsächliche Weg lässt sich nachvollziehbar beschreiben. Denken Sie den Prozess in sechs Erzählkapiteln. Sie bauen dabei nicht nur eine technische Lösung, sondern eine belastbare Geschichte, die Marktaufsicht, Kunden und Auditoren überzeugt.
Kapitel 1: Die Risikogeschichte
Alles beginnt mit einer Risikobetrachtung, nicht mit einer Featureliste. Was kann an meinem Produkt schiefgehen – absichtlich (Angriff) oder unabsichtlich (Fehler, Fehlnutzung)? Welche Werte sind betroffen (Daten, Verfügbarkeit, Integrität, Privatsphäre, Prozesssicherheit)? Welchen Kontext hat das Produkt (privater Haushalt, Industrie, Medizinumfeld, kritische Infrastruktur)? Aus dieser Analyse entstehen Sicherheitsziele und Anforderungen. Sie sind nicht Beiwerk, sondern die erste Seite Ihrer technischen Unterlagen.
Die Kunst ist, weder zu dramatisieren noch zu verharmlosen. Wer Risiken ehrlich beschreibt und priorisiert, baut die Brücke zur angemessenen Lösung – genau das verlangt der CRA.
Kapitel 2: Das Architektur-Versprechen
Auf Risiken folgt Architektur. Sie erklären, welche Sicherheitsprinzipien Sie verankern: Security by Design (Trennung von Zonen, kleinste Rechte, harte Schnittstellen, Schutz vertraulicher Daten), Security by Default (sichere Grundeinstellungen ohne Klick-Hölle), Fail-Safe (wie verhält sich das Gerät im Fehlerfall), Update-Fähigkeit (signierte, überprüfbare Updates, Anti-Rollback), Logging & Monitoring (was wird aufgezeichnet, wie werden Anomalien erkannt).
Diese Architektur ist kein PowerPoint-Wunsch, sondern die Matrix, aus der sich konkrete Kontrollen ableiten lassen. Wer an dieser Stelle nur „TLS überall“ und „wir haben eine Firewall“ schreibt, vergibt sein stärkstes Argument. Wer zeigt, wie Daten im Gerät ruhen (at rest) und reisen (in transit), wie Schlüsselmaterial geschützt ist, wie Boot-Ketten abgesichert sind und wie Nutzerführung Missbrauch verhindert, sammelt Konformitätspunkte für später.
Kapitel 3: Das Entwicklungs-Tagebuch
Hier kommt der Secure Development Lifecycle (SDL) ins Spiel. Der CRA will keine Heldengeschichten, er will Routine. Welche Coding-Standards nutzen Sie? Wie funktionieren Code-Reviews? Welche Automatismen prüfen jede Änderung (statische/dynamische Analysen, Fuzzing, Abhängigkeits-Scans)? Wie halten Sie Drittkomponenten sauber (Stichwort SBOM – dazu gleich mehr)?
Entscheidend ist, dass Sie belegen können, was Sie behaupten. Screenshots von CI-Pipelines mit Security-Gates, Auszüge aus Ergebnisberichten, Ticket-IDs zu Findings – all das gehört zur „Erzählung“. Nicht steril, sondern nachvollziehbar.
Kapitel 4: Die Lieferketten-Landkarte (SBOM als Dreh- und Angelpunkt)
Moderne Produkte sind Lego-Skulpturen: eigene Bausteine, Bibliotheken, Treiber, Firmware-Blobs, Container-Images. Der CRA verlangt, dass Sie wissen, was Sie verbauen. Die Software Bill of Materials (SBOM) ist die Landkarte. Sie nennen Komponenten, Versionen, Quellen, Lizenzen und – wichtig – bekannte Schwachstellen mit Referenzen (CVE).
Eine gute SBOM ist maschinell (CycloneDX, SPDX), aktuell (aus dem Build, nicht aus einer Excel), vollständig (inkl. transitiver Abhängigkeiten) und verknüpft mit Ihrer Flotten-Realität: Welche Kunden haben welche Version? Welche CVE trifft welche Serie? Wer so arbeitet, kann Updates zielgenau planen und kommunizieren – und im Fall der Fälle Meldepflichten verlässlich erfüllen.
Kapitel 5: Das Versprechen nach dem Verkauf (Updates & Support)
Mit dem CRA endet Verantwortung nicht an der Rampe. Sicherheitsupdates müssen über die erwartete Nutzungsdauer bereitstehen; der Weg dorthin muss sicher sein (signierte Pakete, gesicherte Transport- und Verifikationspfade), und die Benachrichtigung der Kunden muss funktionieren. Sie legen offen, welche Versionen unterstützt sind, wie End-of-Support kommuniziert wird und wie Sie Rückruf- oder Korrekturmaßnahmen handhaben, wenn es ernst wird.
Die Praxis zeigt: Wer Updates als Produktfunktion versteht (Staged Roll-out, Rollback, Telemetrie, Erfolgsmessung), spart später Supportkosten und stärkt Vertrauen.
Kapitel 6: Die Reaktionskette (Vulnerability-Handling & Meldungen)
Sicherheitslücken passieren. Der CRA verlangt Organisation statt Überraschung. Ein CVD-Prozess (Coordinated Vulnerability Disclosure) mit klarer Anlaufstelle, reproduzierbaren Abläufen, Priorisierung, definierten SLAs, transparenten Kommunikationsplänen und dokumentiertem Outcome ist Pflicht.
Bei ernsten Vorfällen oder aktiv ausgenutzten Schwachstellen laufen Meldekaskaden: eine Erstmeldung binnen kurzer Frist, technische Details kurz darauf, ein Abschlussbericht nach Behebung. Was wie ein bürokratischer Kraftakt klingt, ist in Wahrheit die Beruhigungspille für Stressmomente: Wer Playbooks, Rollen und Kanäle vorher übt, agiert – statt zu improvisieren.
Wenn Sie diese sechs Kapitel sauber erzählen können, haben Sie die Substanz für die CE-Konformität unter dem CRA. Was dann noch fehlt, ist die Form: die „Konformitätsbewertung“.
Interne Bewertung, Normen, Notified Body: welcher Weg ist Ihrer?
Nicht jedes Produkt muss zur Prüfstelle. Der CRA arbeitet wie viele EU-Regelwerke mit harmonisierten Normen. Wer diese Normen vollumfänglich anwendet, kann oft über die interne Fertigungskontrolle (Selbstbewertung) zur CE-Erklärung gelangen. Für kritische Produktklassen oder abweichende Wege ist eine Drittbewertung durch eine benannte Stelle (Notified Body) vorgesehen.
Es gibt keine Ehre im schwersten Weg. Wer früh erkennt, welche Normen die eigenen Anforderungen exakt treffen (z. B. ETSI EN 303 645 für IoT-Baselines, ISO/IEC 27034 für Application Security, IEC 62443-Teile für Industrienähe, SLSA/SSDF-Leitlinien für Lieferkettensicherheit) und die Architektur passend entwirft, spart sich Jahre. Umgekehrt ist der Gang zur Prüfstelle kein Makel, sondern oft der schnellste und sicherste Weg zur Marktfreigabe – insbesondere bei Produkten, die „zwischen den Stühlen“ sitzen oder deren Risiken hoch sind.
Eine wichtige Konsequenz: Entscheidungen über Normen und Bewertungsweg gehören an den Anfang des Projekts, nicht in die Pre-Launch-Hektik. Sonst muss man später umlackieren, wo man eigentlich schweißen müsste.
Technische Unterlagen: warum die Doku plötzlich strategisch wird
Viele Teams empfinden Dokumentation als lästige Pflicht. Unter dem CRA wird sie zur Währung. Nicht, weil irgendjemand Literatur sammelt, sondern weil Nachweise den Unterschied machen: zwischen einer gut gemeinten Zusicherung und einer belastbaren CE-Erklärung.
Was gehört hinein? Eine klare, für Dritte nachvollziehbare Risikobeurteilung. Architektur- und Datenflussbeschreibungen. Das SDL-Regelwerk samt gelebter Nachweise. Testergebnisse (automatisiert und manuell). Die SBOM in maschinenlesbarer Form. Ihr Update- und Schlüsselmanagement-Konzept. Das CVD-Playbook mitsamt Kontaktwegen. Nutzerinformationen (sichere Defaults, Einrichtungswege, Privacy-Hinweise). Und schließlich die EU-Konformitätserklärung, in der Sie die zutreffenden Rechtsakte und Normen benennen.
Gute Dokumentation ist kuratiert, nicht überladen. Sie zeigt den roten Faden, verweist aber auf Detail-Artefakte, die in Repositories leben. Wer Doku und Entwicklung verzahnt, gewinnt Geschwindigkeit: Jede Änderung am Code hinterlässt automatisch eine Spur im Nachweis-Kosmos.
Post-Market-Surveillance: CE endet nicht an der Ladentür
Der CRA macht Hersteller zu Betreibern ihrer Sicherheitsrealität. Nach dem Markteintritt sind sie verpflichtet, zu beobachten, zu reagieren und zu informieren. Das klingt abstrakt, heißt aber konkret: Sie benötigen Prozesse, um Rückmeldungen aus dem Feld (Support, Telemetrie, CERT-Hinweise) zu sammeln und auszuwerten, Entscheidungen zu dokumentieren, Maßnahmen zu priorisieren und wirksam auszurollen.
Wer hier proaktiv ist, reduziert das Risiko, dass Marktüberwachungsbehörden eingreifen. Diese können nicht konforme Produkte einschränken, verbieten, zurückrufen lassen oder Bußgelder verhängen. Der pragmatische Blick: Post-Market-Surveillance ist keine zusätzliche Abteilung, sondern die logische Verlängerung des SDL in den Betrieb.
Typische Missverständnisse – und wie man sie elegant auflöst
„Unsere Geräte sind offline, uns betrifft das kaum.“
Auch offline existieren Risiken: physische Manipulation, laterale Angriffe über Wartungsports, kompromittierte Update-Medien, bösartige Lieferkettenartefakte. Außerdem: Kunden und Auditoren bewerten nicht nur Zugang, sondern Schadenspotenzial.
„SBOM ist gefährlich, wir verraten doch unsere Innereien.“
Eine SBOM muss nicht das Kronjuwel preisgeben, sie muss Komponenten und Versionen nachvollziehbar machen. Ohne SBOM ist Update-Management in der Fläche Zufall. Mit SBOM gewinnen Sie Handlungsfähigkeit – intern und in Ausschreibungen.
„Open Source hievt uns aus der Pflicht.“
Open Source ist ein Segen, entbindet aber nicht von Verantwortung. Wer OSS als Produkt anbietet, steht in der Pflicht. Die gute Nachricht: Viele OSS-Communities sind in Sachen Security reifer als so manches proprietäre Projekt – nutzen Sie das.
„Drittbewertung ist teuer und langsam.“
Kann sie sein. Teurer ist es, falsch zu planen und Monate vor Launch zu merken, dass die Selbstbewertung nicht trägt. Frühzeitige Pre-Assessments und eine saubere Normenstrategie sparen Zeit und Nerven.
Beispiele aus der Praxis – vom Router bis zur Business-Software
Der Heimrouter eines europäischen OEM
Früher: solide Hardware, funktionale Firmware, sporadische Updates.
Neu: Secure Boot, signierte Updates, Zwangswechsel von Standard-Credentials, sichere Defaults (WPS aus, Remote-Admin aus), telemetriegestützte Roll-outs, öffentliche CVD-Seite. Die SBOM verknüpft Kernel, BusyBox, OpenSSL, Wi-Fi-Stack. Ergebnis: CE-Konformität unter CRA, bessere Bewertungen im Handel, weniger „Notfall-Patches“ am Wochenende.
Ein industrieller Edge-Controller
Früher: „Air-gap“ als Sicherheitsargument, Updates per USB.
Neu: akzeptiertes Risiko-Bild (physischer Zugriff realistisch), Härtung der Wartungsports, Policy für Offline-Updates (signierte Images, verifizierbare Logs), Rollback-Schutz, deklarierter Supportzeitraum. Dazu ein CVD-Programm, das mit Anlagenbauern zusammenspielt. Ergebnis: Aufnahme in Ausschreibungslisten, weil die Sicherheits-Story stimmig ist.
Standalone-Business-Software (On-Premise und als Image)
Früher: Release-Zyklen halbjährlich, Security fixes „bei Gelegenheit“.
Neu: monatliche Security-Zyklen, abhängigkeitsgeführte Patches (SCA), SBOM in CycloneDX, Kundenportal mit Advisories, CVSS-Bewertungen, Fix-Guides. Das Team belegt den SDL mit Pipelines, die Scans automatisiert durchstufen. Ergebnis: Weniger Eskalationen, bessere Vertriebsargumente, saubere CE-Erklärung für die Appliance-Variante.
Verzahnung mit NIS2, AI Act & Co. – warum eine Karte hilft
Der CRA ist kein Solist. Unternehmen sehen sich parallel mit NIS2 (Pflichten für Betreiber wesentlicher/ wichtiger Einrichtungen), mit sektorspezifischen Regeln (z. B. UN ECE R155/R156 im Automotive-Bereich), mit dem AI Act (bei KI-Funktionen), mit der Funkanlagenrichtlinie (bei Funk), mit Ökodesign oder Maschinenverordnung konfrontiert. Die Kunst besteht darin, Bausteine wiederzuverwenden: Eine gute Risikobeurteilung bedient mehrere Rechtsakte, ein sauberer SDL ist universell, SBOM hilft überall, CVD ist branchenübergreifend Gold wert.
Ein Regulatory-Mapping am Anfang des Produktlebens reduziert Doppelarbeit – und verhindert widersprüchliche Versprechen in Handbuch, Marketing und Verträgen.
Organisation & Verträge – die stillen Hebel
Technik ist die eine Hälfte. Die andere Hälfte liegt in Prozessen und Verträgen. Wer Komponenten einkauft, sollte Security-Klauseln standardisieren: Pflicht zur SBOM-Lieferung, Benachrichtigung bei Vulnerabilities, Patch-SLAs, Audits und Rechte zum Sicherheitsnachweis. Wer als Integrator auftritt, braucht klare Zuordnung von Rollen und Pflichten – sonst landet alles beim eigenen Support.
Vertrieb und Legal bekommen neue Werkzeuge: Sie können Supportzeiträume, Update-Versprechen und Informationskanäle sauber beschreiben – und so den Wert eines Produkts fassbar machen. Das wirkt trockener, als es ist: Kunden mögen Transparenz, insbesondere, wenn sie selbst NIS2-Pflichten haben.
„Wann müssen wir fertig sein?“ – Fristen realistisch denken
Der CRA ist in Kraft, die Pflichten greifen gestaffelt. Besonders früh kommen die Anforderungen an Vulnerability-Handling und Meldungen – hier vergehen nur gut zwei Jahre zwischen Inkrafttreten und Wirksamkeit. Die vollumfänglichen CE-Pflichten folgen wenig später. Für Produkte mit Entwicklungs- und Zertifizierungszyklen von 12 bis 24 Monaten heißt das: Jetzt beginnen, nicht „wenn die Normen fertig sind“. Normen helfen, aber sie ersetzen nicht den Aufbau von Kompetenz, Tooling und Routinen.
Ein pragmatischer Blick auf Zeit: Es ist besser, ein Produkt CRA-reif zu machen, daraus eine Blaupause zu bauen und diese dann zu skalieren, als zehn Produkte parallel „ein bisschen“ anzufassen. In die erste Welle gehören typischerweise die Umsatzträger oder die kritischen Komponenten einer Plattform.
Was am häufigsten schiefgeht – und wie man den Bogen kriegt
Am Anfang unterschätzen viele Unternehmen die Querschnittsarbeit. Es reicht nicht, im Engineering „Security“ zu rufen. Einkauf, Legal, Support, Kommunikation, Datenschutz, Produktmanagement – alle müssen an den Tisch. Der zweite Irrtum ist, Doku und Prozesse ex-post schreiben zu wollen. Das wirkt wie eine Theaterkulisse und fällt im Zweifel in sich zusammen. Die Lösung ist banal, aber wirkungsvoll: Automatisieren, was objektivierbar ist (Scans, SBOM, Build-Signierung, Testberichte), und trainieren, was menschlich ist (CVD-Intake, Crisis-Comms, Incident-Playbooks).
Der dritte Klassiker ist die Angst, gegenüber Kunden über Schwachstellen zu sprechen. Paradox, aber wahr: Offene, strukturierte Kommunikation baut Vertrauen auf. Ein Kunde, der weiß, was gerade passiert, bleibt. Ein Kunde, der im Dunkeln tappt, googelt – und geht.
Der wirtschaftliche Blick: Kosten jetzt, Rendite später – aber sicher
Natürlich kostet der Umbau. Wobei „Kosten“ häufig eine Verschiebung sind: Weg von Ad-hoc-Support und nächtlichen Hotfixes, hin zu planbaren Security-Zyklen, besserer Wiederverwendbarkeit und stabileren Releases. Der Return kommt über Ausschreibungen, über Service-Erlöse (z. B. Security-Maintenance), über niedrigere Feldkosten und über die Marke.
Vor allem aber: Der CRA macht sichtbar, was viele ohnehin tun sollten. Er ist kein Innovationskiller, sondern ein Sauberkeitsgebot. Wer das als Chance begreift, hebt sich ab – selbst in Märkten, die heute gnadenlos austauschbar wirken.
Schlussgedanke: CE wird zur Vertrauensmarke – wenn man sie mit Inhalt füllt
Der Cyber Resilience Act verwandelt die CE-Kennzeichnung in eine Sicherheitsaussage. Nicht perfekt, aber ambitioniert. Er zwingt Hersteller, das zu tun, was die besten ohnehin längst machen: Sicherheit von Anfang an denken, Lieferketten im Griff behalten, Updates zuverlässig liefern, Lücken professionell managen und offen kommunizieren.
Wer so arbeitet, hat am Ende mehr als ein Zeichen auf dem Gehäuse. Er hat eine Geschichte, die sich erzählen lässt: Wir verstehen unsere Risiken. Wir haben unsere Architektur im Griff. Wir entwickeln mit System. Wir wissen, woraus unser Produkt besteht. Wir bleiben nach dem Verkauf erreichbar und handlungsfähig. Und wir lassen Sie – unsere Kunden – damit nicht allein.
So wird aus CE tatsächlich das, was es immer sein sollte: ein Versprechen, das hält.