Wenn Sie ein vernetztes Gerät herstellen und in der EU verkaufen, gilt der Cyber Resilience Act (CRA) für Sie. Punkt. Es spielt keine Rolle, wo Sie produzieren, wo Ihr Unternehmen registriert ist oder ob Sie ein europäisches Büro haben.
Die Verordnung trat am 10. Dezember 2024 in Kraft. Die meisten Teams haben sich 2027 als Frist angestrichen und sind noch nicht aktiv geworden. Das Problem: 2027 ist der letzte Stichtag für die Durchsetzung, nicht der einzige. Die erste harte Frist ist der 11. September 2026, ab dem die verpflichtende Meldung von Schwachstellen greift. Die Prozesse, die diese Meldung verlangt, lassen sich nicht in einem Sprint aufbauen. Sie müssen Monate vor der Frist laufen, damit Sie den Behörden auf Nachfrage die operativen Nachweise vorlegen können.
Dieser Leitfaden behandelt, was Sie tatsächlich tun müssen, und zwar in der Reihenfolge, in der Sie es tun müssen.
Fällt Ihr Produkt in den Anwendungsbereich?
Der CRA gilt für jede Hard- oder Software, die sich direkt oder indirekt mit einem Gerät oder Netzwerk verbindet und im kommerziellen Kontext auf dem EU-Markt bereitgestellt wird.
Ihr Smart-Sensor, Ihr Industrie-Gateway, Ihr Firmware-Updater und das eingebettete Betriebssystem in Ihrem Thermostat fallen alle darunter. Der Test ist einfach: Wenn es in die EU geliefert wird und sich mit irgendetwas verbindet, fällt es in den Anwendungsbereich.
Was ausgenommen ist:
- Medizinprodukte und Kraftfahrzeuge (durch eigene Branchenvorschriften abgedeckt)
- Nicht kommerzialisierte Open-Source-Software
- Reine SaaS- und PaaS-Angebote, die nicht integraler Bestandteil der Funktion eines erfassten Geräts sind
- Websites, die keine Fernverarbeitung für ein erfasstes Gerät unterstützen
Wenn Sie Importeur oder Händler sind und nicht der ursprüngliche Hersteller, haben Sie dennoch Pflichten. Sie müssen unter Umständen die CE-Kennzeichnung prüfen, Dokumentation aufbewahren und in manchen Fällen die vollen Herstellerpflichten übernehmen, wenn Sie das Produkt vor dem Inverkehrbringen wesentlich verändern.
Noch etwas, das viele Teams übersehen: Die Cybersicherheitsanforderungen der Funkanlagenrichtlinie (RED) gelten bereits seit dem 1. August 2025 für internetfähige Funkgeräte. Wenn Ihr Gerät Wi-Fi oder Bluetooth nutzt und die Frist im August 2025 ohne RED-Bewertung verstrichen ist, kümmern Sie sich zuerst darum. Die RED-Liste ist kürzer als der CRA, aber sie ist bereits überfällig.
Schritt 1: Klassifizieren Sie Ihr Produkt
Der CRA sortiert Produkte in vier Risikokategorien. Ihre Kategorie bestimmt, wie Sie die Konformität nachweisen.
Standard (rund 90 % aller Produkte) Übliche vernetzte Geräte, der Großteil der Consumer-IoT-Produkte, Industriesensoren mit geringerem Risiko. Eine Selbstbewertung ist zulässig. Sie bewerten Ihr eigenes Produkt anhand der wesentlichen Anforderungen und unterzeichnen eine Konformitätserklärung.
Wichtig: Klasse I Produkte mit höherem Risiko, darunter Browser, Passwort-Manager, VPNs und Netzwerkmanagement-Software. Eine Selbstzertifizierung gegen eine harmonisierte Norm ist zulässig, oder Sie ziehen eine benannte Stelle hinzu.
Wichtig: Klasse II Produkte mit erheblichem Sicherheitsrisiko: industrielle Firewalls, Intrusion-Detection-Systeme, Mikroprozessoren, Router, Modems, Smart-Meter-Gateways. In den meisten Fällen ist eine Bewertung durch eine benannte Stelle (Drittpartei) erforderlich.
Kritisch Produkte, von denen kritische Infrastruktur abhängt. Erfordert ein europäisches Cybersicherheits-Zertifizierungsschema. Die im November 2025 verabschiedete Durchführungsverordnung hat geklärt, welche Produkte hier landen.
Die verbindlichen Listen finden Sie in Anhang III und Anhang IV der Verordnung (EU) 2024/2847.
Ein praktisches Problem bei Klasse II und Kritisch: Die Kapazität der benannten Stellen in der EU ist begrenzt. Teams, die erst Ende 2026 oder 2027 starten, werden in Warteschlangen geraten. Das Ziel der Europäischen Kommission ist es, bis zum 11. Dezember 2026 benannte Stellen einzurichten, doch die Verfügbarkeit deckt sich möglicherweise nicht mit der Nachfrage. Fangen Sie früh an.
Schritt 2: Erstellen Sie jetzt Ihre Software Bill of Materials
Die SBOM-Anforderung steht in Anhang I, Teil II des CRA. Hersteller müssen alle Komponenten in ihren Produkten identifizieren und dokumentieren, einschließlich einer Software Bill of Materials in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene abdeckt.
Der Grund, das vor September 2026 zu erledigen, ist operativer, nicht bürokratischer Natur. Wenn eine aktiv ausgenutzte Schwachstelle öffentlich bekannt wird, haben Sie 24 Stunden Zeit, um an die ENISA und Ihr nationales CSIRT zu melden. Um diese Frist einzuhalten, müssen Sie innerhalb von Minuten wissen, ob Ihr Produkt die betroffene Komponente verwendet. Ohne SBOM und automatisiertes Schwachstellen-Tracking verbringen Sie diese 24 Stunden damit, Firmware-Images manuell zu durchforsten.
Was Ihre SBOM abdecken muss:
- Jede Software-Komponente vom Betriebssystem bis zu den Firmware-Modulen
- Sowohl proprietäre als auch Open-Source-Komponenten
- Versionsnummern und Lizenzinformationen
- Bekannte Schwachstellen, jeder Komponente zugeordnet
- Mindestens die Abhängigkeiten der obersten Ebene; wo praktikabel, das vollständige Tracking transitiver Abhängigkeiten
Der CRA schreibt noch kein bestimmtes Format vor, verlangt aber ein “gängiges, maschinenlesbares” Format. Sowohl SPDX als auch CycloneDX erfüllen das. Es wird erwartet, dass die Europäische Kommission die Formate 2026 über Durchführungsrechtsakte festlegt. Wählen Sie jetzt eines aus und bauen Sie es in Ihre CI/CD-Pipeline ein.
Sie müssen Ihre SBOM nicht veröffentlichen. Marktüberwachungsbehörden können sie anfordern, und Sie müssen sie zeitnah bereitstellen können. Bewahren Sie sie in Ihrer technischen Dokumentation auf.
Bei Geräten, die OTA-Updates erhalten, muss der SBOM-Prozess aktuell bleiben. Jede Firmware-Version, die eine Komponente hinzufügt oder aktualisiert, erfordert vor der Auslieferung eine aktualisierte SBOM.
Schritt 3: Bauen Sie Sicherheit von Anfang an ein
Die meisten IoT-Teams haben hier den größten Nachholbedarf. Der CRA verlangt Security by Design, keine Sicherheit, die kurz vor einem CE-Audit nachträglich angeschraubt wird.
Zur Entwurfszeit:
- Keine Standardpasswörter. Geräte müssen entweder so ausgeliefert werden, dass der Nutzer eine eindeutige Zugangsinformation festlegen muss, oder mit hardwareeigenen, pro Gerät erzeugten Zugangsdaten arbeiten.
- Minimieren Sie die Angriffsfläche. Beschränken Sie offengelegte Schnittstellen, Dienste und Ports auf das, was das Produkt zum Funktionieren tatsächlich braucht.
- Threat Modeling vor dem Hardware-Bring-up, nicht danach.
- Secure Boot, um die Firmware-Integrität ab dem Einschalten zu prüfen.
- Verschlüsseln Sie Daten bei der Übertragung und im Ruhezustand, wo das Bedrohungsmodell des Produkts es rechtfertigt.
Während der Entwicklung:
- Ein Secure Software Development Lifecycle (SSDL) mit Sicherheits-Gates bei Code-Review, statischer Analyse und Abhängigkeits-Scanning, integriert in CI/CD.
- Keine bekannten kritischen oder schwerwiegenden Schwachstellen in Komponenten zum Zeitpunkt der Veröffentlichung. Der CRA verlangt, dass Produkte “ohne bekannte ausnutzbare Schwachstellen” auf den Markt gebracht werden.
- Testen Sie gegen Ihr eigenes Bedrohungsmodell, bevor Sie ausliefern.
Nach dem Inverkehrbringen:
- Sicherheitsupdates müssen den Nutzern mindestens 5 Jahre ab dem Inverkehrbringen des Produkts zur Verfügung stehen, oder über die voraussichtliche Nutzungsdauer, falls diese länger ist.
- Ist ein Sicherheitsupdate erst einmal veröffentlicht, muss es mindestens 10 Jahre ab diesem Veröffentlichungsdatum verfügbar bleiben, oder über den verbleibenden Supportzeitraum.
- Automatische Update-Mechanismen oder eine klare Benachrichtigung der Nutzer, wenn Updates verfügbar sind.
- Ein veröffentlichtes End-of-Support-Datum, damit Nutzer wissen, wann Patches eingestellt werden.
Schritt 4: Richten Sie das Schwachstellen-Handling und die Vorfallsmeldung ein
Das ist die Frist im September 2026. Ab dem 11. September 2026 müssen Hersteller innerhalb von 24 Stunden nach Entdeckung einer aktiv ausgenutzten Schwachstelle in einem aktuell auf dem EU-Markt befindlichen Produkt an die ENISA und das zuständige nationale CSIRT melden.
Der Meldungszeitplan:
| Auslöser | Frist | Was einzureichen ist |
|---|---|---|
| Aktiv ausgenutzte Schwachstelle entdeckt | 24 Stunden | Frühwarnung an ENISA und nationales CSIRT |
| Schwerwiegender Cybersicherheitsvorfall mit Auswirkung auf die Produktsicherheit | 24 Stunden | Frühwarnmeldung |
| Nach der Frühwarnung | 72 Stunden | Schwachstellenmeldung mit erster Folgenabschätzung |
| Sobald eine Gegenmaßnahme verfügbar ist | 14 Tage | Vollständiger Bericht: Beschreibung, betroffene Versionen, Gegenmaßnahmen |
Das umfasst auch Altprodukte. Wenn Sie 2019 ein IoT-Gateway ausgeliefert haben und es am 11. September 2026 noch auf dem EU-Markt ist, sind Sie für die Meldung von Schwachstellen darin innerhalb dieser Fristen verantwortlich.
Meldungen gehen an die europäische Schwachstellendatenbank der ENISA und an das nationale CSIRT des Mitgliedstaats oder der Mitgliedstaaten, in denen das Produkt verkauft wird. Sie werden in der Regel an die CSIRTs in jedem Mitgliedstaat weitergeleitet, in dem das Produkt vermarktet wird.
Was vor September 2026 stehen muss:
- Eine koordinierte Richtlinie zur Offenlegung von Schwachstellen (CVD), veröffentlicht und auffindbar
- Ein überwachter Sicherheitskontakt und eine security.txt-Datei
- Interne Triage-Workflows mit klaren Verantwortlichkeiten und Eskalationswegen
- SBOM und Abhängigkeits-Tracking, damit Sie die Frage “Sind wir betroffen?” in Stunden statt Tagen beantworten können
- Eine funktionierende Arbeitsbeziehung zu Ihrem nationalen CSIRT, bevor Sie es anrufen müssen
Schritt 5: Bereiten Sie Ihre technische Dokumentation vor
Jeder Hersteller muss eine technische Dokumentation führen. Marktüberwachungsbehörden können sie jederzeit anfordern. Die Inhaltsanforderungen stehen in Anhang VII des CRA.
Ihre technische Dokumentation muss enthalten:
- Produktbeschreibung: Name, Version, Typ, Seriennummernbereich
- Risikobewertung: Ihr Cybersicherheits-Bedrohungsmodell und wie Ihre Designentscheidungen darauf eingehen
- Sicherheitsarchitektur: wie das Produkt die wesentlichen Anforderungen erfüllt
- SBOM
- Beschreibung des sicheren Entwicklungsprozesses: Coding-Standards, Review-Prozess, Testmethodik
- Verfahren zum Umgang mit Schwachstellen
- Test- und Verifizierungsergebnisse
- Verweis auf die Konformitätserklärung
Bewahren Sie die Dokumentation 10 Jahre nach dem Marktaustritt des Produkts auf. Aktualisieren Sie sie, wenn Sie Sicherheitsupdates herausgeben.
Schritt 6: Bringen Sie die CE-Kennzeichnung richtig an
Die CE-Kennzeichnung nach dem CRA ist nicht dasselbe wie die CE-Kennzeichnung nach älteren Richtlinien. Bei einem Produkt der Klasse II können Sie die Konformität nicht selbst erklären und eine CE-Kennzeichnung anbringen.
Für Produkte der Standardkategorie: Eine Selbstbewertung ist zulässig. Führen Sie die Konformitätsbewertung durch, erstellen Sie eine Konformitätserklärung, bringen Sie die CE-Kennzeichnung an.
Für wichtige Produkte der Klasse I: Selbstzertifizierung gegen eine harmonisierte Norm, oder Hinzuziehung einer benannten Stelle.
Für wichtige Produkte der Klasse II und kritische Produkte: In den meisten Fällen ist eine Bewertung durch eine benannte Stelle erforderlich.
Ihre Konformitätserklärung muss enthalten:
- Produktidentifikation (Name, Typ, Charge, Seriennummer)
- Name und Anschrift des Herstellers
- Konformitätserklärung mit der Verordnung (EU) 2024/2847
- Name und Nummer der benannten Stelle, falls zutreffend
- Angaben zum Zeichnungsbefugten
Die CE-Kennzeichnung muss auf dem Produkt, seiner Verpackung oder den Begleitunterlagen erscheinen, wenn das Produkt zu klein ist, um sie zu tragen.
Woran die meisten Teams scheitern
Es als einmaliges Häkchen behandeln. Der CRA verlangt fortlaufende Prozesse. Schwachstellenüberwachung, SBOM-Aktualisierungen und Vorfallsmeldungen laufen kontinuierlich, solange Ihr Produkt auf dem Markt ist.
Bereits ausgelieferte Produkte ignorieren. Wenn es am 11. September 2026 noch in der EU verkauft wird, fällt es unter die Schwachstellenmeldung. Das schließt Produkte aus dem Jahr 2019 ein.
Den Umfang der SBOM unterschätzen. Ein typisches Firmware-Image enthält Dutzende oder Hunderte von Komponenten. Eine manuelle Inventarisierung skaliert nicht. Automatisieren Sie die SBOM-Erzeugung von Anfang an in Ihrer Build-Pipeline.
Lieferketten-Pflichten übersehen. Komponenten von Drittanbietern bergen ein Risiko, das auf Sie als Hersteller übergeht. Ihre Lieferantenverträge brauchen SBOM-Verpflichtungen und Bedingungen zur Offenlegung von Schwachstellen. Eine Schwachstelle in einer Bibliothek, die Ihr Chip-Lieferant mitliefert, bleibt Ihre Meldepflicht.
Davon ausgehen, dass harmonisierte Normen rechtzeitig kommen. Die CEN/CENELEC-Standardisierung für den CRA läuft noch. Bei Produkten, die eine Drittbewertung erfordern, können Normen noch unvollständig sein, wenn Sie zertifizieren müssen. Binden Sie eine benannte Stelle frühzeitig ein, um zu klären, welche Nachweise sie in der Zwischenzeit akzeptiert.
Eine Anmerkung zu Ihrer IoT-Plattform
Eine Frage kommt häufig auf: Wirkt sich die Cloud-Plattform, mit der Ihr Gerät verbunden ist, auf Ihre CRA-Konformität aus?
Wenn Sie eine universelle IoT-Plattform nutzen, die nicht von Ihnen oder in Ihrem Auftrag entwickelt wurde, fällt sie nicht direkt unter den CRA. Reine SaaS- und PaaS-Angebote sind von der Verordnung ausgenommen. Für Ihre technische CRA-Dokumentation zählt, dass Sie die Plattform als Teil Ihrer Lieferkette dokumentieren, die von ihr angewendeten Sicherheitskontrollen verstehen und Nachweise haben, die Sie den Marktüberwachungsbehörden vorlegen können.
Achten Sie bei der Bewertung von Plattformen auf dokumentierte Verschlüsselung im Ruhezustand und bei der Übertragung, auf Zugriffskontrollen, Audit-Logging, veröffentlichte Prozesse zur Offenlegung von Schwachstellen und unabhängige Sicherheitsvalidierung. Eine ISO/IEC-27001-Zertifizierung, unabhängige Sicherheitsbewertungen und ein veröffentlichtes Sicherheitsportal mit verfügbarer Dokumentation sind die Dinge, nach denen Sie fragen sollten. Plattformen, die diese Nachweise nicht zügig liefern können, bremsen Ihren CRA-Dokumentationsprozess aus.
TagoIO verfügt über eine ISO/IEC-27001-Zertifizierung, GDPR-Konformität und ein öffentliches Security Portal unter security.tago.io mit Audit-Berichten, Sicherheits-Selbstbewertungen und vollständiger Dokumentation auf Anfrage. Wenn Sie TagoIO als Teil der Datenpipeline Ihres Geräts nutzen, finden Sie dort die Sicherheitsdokumentation, die Sie für Ihre Lieferkettenbewertung brauchen.
Zeitplan
| Datum | Meilenstein |
|---|---|
| 10. Dezember 2024 | CRA in Kraft getreten |
| 1. August 2025 | RED-Cybersicherheitsanforderungen gelten für internetfähige Funkgeräte |
| 11. Juni 2026 | Benennungen der Konformitätsbewertungsstellen müssen stehen |
| 11. September 2026 | Melde- und Berichtspflichten für Schwachstellen und Vorfälle beginnen |
| 11. Dezember 2027 | Alle CRA-Anforderungen vollständig durchsetzbar |
Quellen
- Verordnung (EU) 2024/2847: der CRA-Text. Beginnen Sie mit Anhang I (Sicherheitsanforderungen), Anhang III/IV (Produktkategorien), Anhang VII (technische Dokumentation).
- ENISA-Leitfaden zum CRA: enisa.europa.eu
- IoT Security Foundation: Compliance-Ressourcen und Zuordnung zu ENISA-Normen unter iotsecurityfoundation.org
- ETSI EN 303 645: die bestehende Norm für Consumer-IoT-Sicherheit, stark an die Anforderungen aus Anhang I des CRA angelehnt
- CRA-Leitfaden der Europäischen Kommission: im März 2026 zur Stellungnahme veröffentlicht, behandelt die Auslegung des Anwendungsbereichs und die Unterstützung von KMU
Dieser Artikel gibt den Stand des CRA im April 2026 wieder. Durchführungsrechtsakte und harmonisierte Normen werden noch finalisiert. Prüfen Sie die Seiten zur digitalen Strategie der Europäischen Kommission auf Aktualisierungen. Die Verordnung (EU) 2024/2847 ist die maßgebliche Quelle.
