CRA und IoT — Sicherheit für vernetzte Geräte
Der CRA macht Cybersecurity für IoT-Geräte zur Pflicht: Hersteller vernetzter Produkte müssen Security by Design, Update-Pflichten und Schwachstellenmanagement implementieren, ergänzend zu NIS2 für Betreiber und dem AI Act für KI-Funktionen. Für KMU mit Smart-Home-Produkten, Industrie-IoT oder vernetzten Medizingeräten ist das keine abstrakte Regulierung mehr, sondern ein konkreter Produkt- und Entwicklungsstandard nach EU-VO 2024/2847.
Für die Einordnung des Gesamtgesetzes lohnt sich zuerst unser Überblick zum Cyber Resilience Act. Wenn Sie die operativen Herstellerpflichten vertiefen wollen, ist danach der Beitrag zu CRA-Anforderungen sinnvoll; für die Kennzeichnungsperspektive ergänzt CRA und CE-Kennzeichnung die Produktseite dieses Artikels.
Warum der CRA für IoT-Hersteller ein Gamechanger ist
Der CRA verändert IoT-Compliance grundlegend, weil vernetzte Geräte erstmals unionsweit einheitlichen, produktspezifischen Cybersecurity-Pflichten unterliegen. Bislang arbeiteten viele Hersteller mit einer Mischung aus Produktsicherheit, Funkanlagenrecht, Vertragsklauseln und internen Secure-Development-Vorgaben. Mit der EU-VO 2024/2847 wird daraus ein verbindlicher Horizontalstandard für Produkte mit digitalen Elementen.
Für IoT-Hersteller ist das ein Gamechanger aus drei Gründen:
- Cybersecurity wird Marktzugangsvoraussetzung. Wer ein vernetztes Produkt nach dem 11. Dezember 2027 neu in der EU in Verkehr bringt, muss die CRA-Anforderungen erfüllen. Das betrifft nicht nur Softwareanbieter, sondern gerade auch Embedded- und Hardware-Hersteller.
- Die Verantwortung endet nicht beim Release. Der CRA koppelt Konformität an den gesamten Produktlebenszyklus. Schwachstellenmanagement, Updates, Meldepflichten und technische Dokumentation laufen nach dem Verkaufsstart weiter.
- KMU sind nicht ausgenommen. Ein Hersteller mit zehn Beschäftigten und einer smarten Sensorbox fällt nicht deshalb aus dem Scope, weil er klein ist. Für deutsche Mittelständler ist genau das die relevante Botschaft.
Zeitlich ist die Verordnung klar gestaffelt. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle greifen ab dem 11. September 2026. Die übrigen Kernpflichten, also Security by Design, Konformitätsbewertung und CE-bezogene CRA-Nachweise, gelten ab dem 11. Dezember 2027. Wer heute noch mit Standardpasswörtern, ungeplanten Firmware-Updates oder unvollständiger technischer Dokumentation arbeitet, baut damit direkt an einem Compliance-Risiko für 2027.
Für Betreiber vernetzter Infrastrukturen überschneidet sich der CRA oft mit NIS2, aber aus anderer Richtung. NIS2 adressiert die organisatorische Resilienz des Betreibers, der CRA die Sicherheit des Produkts selbst. Ein Industrieunternehmen kann deshalb zugleich Betreiberpflichten aufbauen und von Zulieferern CRA-fähige Geräte verlangen. Bei KI-gesteuerten IoT-Produkten kommt zusätzlich der AI Act ins Spiel, sobald etwa ein vernetztes Gerät Entscheidungen mit KI-Komponenten vorbereitet oder automatisiert.
Welche IoT-Geräte fallen unter den CRA?
Unter den CRA fallen grundsätzlich alle IoT-Geräte, die ein digitales Element haben und direkt oder mittelbar mit einem anderen Gerät oder einem Netz verbunden werden können. Maßgeblich ist nicht das Marketing-Etikett „IoT“, sondern die juristische Definition eines Produkts mit digitalen Elementen.
Praktisch erfasst der CRA unter anderem:
- Smart-Home-Produkte wie Kameras, Türschlösser, Alarmanlagen, Heizungssteuerungen und Sprachassistenten
- Industrie-IoT-Komponenten wie Sensor-Gateways, Fernwartungsmodule, Edge-Controller und vernetzte HMI-Einheiten
- Wearables wie Smartwatches oder Fitness-Tracker
- Internetfähige Spielzeuge mit Kamera-, Sprach- oder Tracking-Funktion
- Router, Modems, Switches und andere vernetzte Infrastrukturbausteine
- Vernetzte Komponenten in Maschinen, Gebäudetechnik oder medizinischen Umgebungen
Entscheidend ist die vorhersehbare Verbindung zu anderen Systemen. Ein Sensor, der über Funk, WLAN, Bluetooth, Zigbee, Mobilfunk oder Ethernet kommuniziert, fällt regelmäßig eher in den CRA-Scope als eine vollständig isolierte Komponente ohne digitale Kommunikationsfunktion.
Nicht jedes Produkt unterliegt aber ausschließlich dem CRA. Es gibt Abgrenzungen zu Spezialregimen. Für Medizinprodukte, Fahrzeuge oder Luftfahrt können zusätzliche oder vorrangige sektorspezifische Regeln relevant sein. Das ändert nichts daran, dass Hersteller vernetzter Produkte sehr früh prüfen müssen, welches Regime den Marktzugang dominiert und wie CRA-Pflichten mit anderen EU-Vorgaben zusammenspielen.
Für KMU besonders wichtig ist die Frage nach Bestandsprodukten. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, werden nicht automatisch rückwirkend voll CRA-pflichtig. Wenn ein bestehendes Gerät nach diesem Datum jedoch wesentlich verändert wird oder in einer neuen, geänderten Fassung neu in Verkehr gebracht wird, kann eine neue Konformitätsbewertung erforderlich werden. Die Grenze verläuft also nicht schlicht zwischen „alt“ und „neu“, sondern auch entlang der Frage, ob eine wesentliche Änderung vorliegt.
Wenn Sie branchenspezifisch auf Fertigung und Anlagenbetrieb schauen, finden Sie die Betreiberperspektive ergänzend auf unserer Seite Produktion und Industrie. Für den Begriff der Kennzeichnung selbst hilft außerdem unser Glossarbeitrag zur CE-Kennzeichnung für KI, auch wenn CRA und AI Act unterschiedliche Produktregime betreffen.
Produktkategorien — Standard, Klasse I, Klasse II für IoT
Für IoT-Produkte ist die wichtigste Struktur des CRA dreistufig: Standardprodukte, wichtige Produkte der Klasse I und wichtige Produkte der Klasse II. Die Klassen ergeben sich aus den Anhängen III und IV der Verordnung sowie aus der technischen Konkretisierung durch die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025, die am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt in Kraft getreten ist.
Die kurze Antwort lautet: Die meisten vernetzten Geräte sind zunächst Standardprodukte. Bestimmte IoT-nahe Kategorien steigen aber in Klasse I auf, wenn ihre Kernfunktion sicherheitskritisch für andere Produkte, Netze oder Nutzer ist. Klasse II betrifft noch sensiblere Kategorien mit schärferen Konformitätsanforderungen, ist bei klassischen KMU-IoT-Geräten aber seltener.
| Kategorie | Typische IoT-Beispiele | Regulatorische Folge |
|---|---|---|
| Standardprodukt | vernetzte Sensorbox, smarte Heizungssteuerung, industrielles Gateway ohne Annex-III-Kategorie | Hersteller führt in der Regel interne Konformitätsbewertung anhand der CRA-Anforderungen durch |
| Klasse I | Router, Internet-Modems, Smart-Home-Produkte mit Sicherheitsfunktion, internetfähige Spielzeuge mit Tracking, Wearables mit Health-Monitoring | Strengere Konformitätsbewertung, weil das Produkt ausdrücklich in Annex III bzw. Verordnung 2025/2392 beschrieben ist |
| Klasse II | spezielle Sicherheitsprodukte wie Firewalls, IDS/IPS oder tamper-resistant Mikrocontroller/Mikroprozessoren | Noch höhere regulatorische Dichte; je nach Modul deutlich anspruchsvollere Nachweisführung |
Für typische IoT-Hersteller sind vor allem folgende Klasse-I-Beispiele relevant:
- Router, Modems und Switches mit Internetanbindung
- Smart-Home-Assistenten
- Smart-Home-Produkte mit Sicherheitsfunktionen wie vernetzte Türschlösser, Überwachungskameras, Baby-Monitore und Alarmanlagen
- Internetfähige Spielzeuge mit Sprach-, Kamera- oder Tracking-Funktion
- Wearables mit Gesundheitsmonitoring oder Produkte für Kinder
Das ist für KMU deshalb relevant, weil ein Hersteller nicht nur auf das Gesamtsystem, sondern auf die Kernfunktion seines Produkts schauen muss. Eine simple Smart-Home-App wird nicht allein dadurch zur Klasse-I-Komponente, dass sie einen eingebetteten Browser nutzt. Ein vernetztes Türschloss oder eine Heimkamera mit Sicherheitsfunktion fällt dagegen sehr schnell in die ausdrücklich beschriebene Kategorie.
Klasse II betrifft weniger den klassischen Consumer-IoT-Massenmarkt, sondern eher Komponenten mit besonders zentraler Schutzfunktion, etwa Firewalls oder manipulationsresistente Sicherheitschips. Für Hersteller eingebetteter Hardware kann das trotzdem hochrelevant werden, wenn die eigentliche Produktfunktion in der Absicherung anderer Systeme liegt.
Wichtig ist außerdem: Neben Standard, Klasse I und Klasse II kennt der CRA noch kritische Produkte nach Annex IV. Diese spielen in vielen IoT-KMU-Projekten nicht die Hauptrolle, zeigen aber, dass die CRA-Logik abgestuft ist und nicht jedes vernetzte Gerät gleich behandelt wird.
Cybersecurity-Anforderungen für vernetzte Geräte
Die CRA-Anforderungen für IoT-Geräte lassen sich auf einen Satz verdichten: Hersteller müssen nachweisen, dass ihre Produkte über den gesamten Lebenszyklus hinweg angemessen sicher entwickelt, ausgeliefert, überwacht und aktualisiert werden. Im Zentrum stehen die wesentlichen Cybersecurity-Anforderungen aus Anhang I der EU-VO 2024/2847.
Für vernetzte Geräte bedeutet das praktisch mindestens:
- Risikoanalyse vor dem Inverkehrbringen. Hersteller müssen typische Angriffsvektoren identifizieren, etwa unsichere Schnittstellen, offene Debug-Zugänge, mangelhafte Authentifizierung oder unsichere Cloud-Anbindungen.
- Security by Design und Security by Default. Sicherheit darf nicht nachträglich „dazugebaut“ werden. Relevante Schutzmechanismen müssen schon in Architektur, Firmware, Kommunikationswegen und Voreinstellungen angelegt sein.
- Schutz vor unbefugtem Zugriff. Authentifizierung, Rollenlogik, Zugriffskontrollen und gegebenenfalls sichere Schlüsselverwaltung sind kein optionales Qualitätsmerkmal mehr.
- Vulnerability Handling. Hersteller müssen Schwachstellen beobachten, bewerten, priorisieren und beheben können.
- Technische Dokumentation. Bedrohungsmodell, Testlogik, Updateprozess, Konfigurationen und Konformitätsnachweise müssen belastbar dokumentiert werden.
Bei IoT-Geräten ist die Kombination aus Hardware, Firmware, App und Backend besonders heikel. Ein formal sicheres Gerät kann regulatorisch trotzdem schwach sein, wenn etwa die zugehörige Cloud-API schlecht abgesichert ist oder ein Companion-App-Workflow unsichere Pairing-Prozesse zulässt. Der CRA zwingt Hersteller deshalb zu einer Gesamtbetrachtung des Produkts mit digitalen Elementen, nicht nur zu einer isolierten Sicht auf das Gehäuse oder auf einzelne Softwareteile.
Für viele mittelständische Hersteller heißt das organisatorisch:
- Entwicklungs- und Produktsicherheit enger verzahnen
- Lieferanten und Open-Source-Komponenten sauber erfassen
- SBOM- und Komponentenmanagement aufbauen
- klare Prozesse für Meldung, Triage und Patch-Auslieferung definieren
- technische Dokumentation früher im Entwicklungszyklus beginnen
Wenn Sie die Pflichten strukturiert entlang Entwicklung, Dokumentation und Post-Market-Phase aufarbeiten wollen, lesen Sie ergänzend unseren Beitrag zu CRA-Anforderungen.
Update-Pflicht — Mindestens 5 Jahre Sicherheitsupdates
Für IoT-Hersteller ist die Update-Pflicht eine der wirtschaftlich wichtigsten CRA-Folgen, weil sie direkt auf Produktplanung, Supportkosten und Vertragsmodelle wirkt. Die Verordnung verlangt, dass Schwachstellen durch Sicherheitsupdates adressiert werden können und diese Updates grundsätzlich über den Support-Zeitraum oder für mindestens fünf Jahre nach dem Inverkehrbringen bereitgestellt werden, je nachdem, welcher Zeitraum kürzer ist.
Diese Fünf-Jahres-Logik wird oft verkürzt wiedergegeben. Präziser ist:
- Der Hersteller muss einen Support-Zeitraum festlegen.
- Dieser Zeitraum soll die erwartbare Nutzungsdauer des Produkts widerspiegeln.
- In der Regel darf der Sicherheits-Support nicht einfach nach ein oder zwei Jahren enden, wenn das Gerät typischerweise viel länger im Einsatz bleibt.
- Ist die erwartete Nutzung eines Produkts tatsächlich kürzer als fünf Jahre, darf sich der Support daran orientieren.
Für Smart-Home-Kameras, industrielle Feldgeräte oder vernetzte Zutrittssysteme ist die regulatorische Wirkung erheblich. Solche Produkte werden in der Praxis häufig deutlich länger als zwei Jahre betrieben. Ein Hersteller, der sein Geschäftsmodell auf kurze Hardware-Zyklen stützt, muss deshalb früh entscheiden, wie Updates technisch und wirtschaftlich abgesichert werden.
Der CRA verlangt nicht nur irgendeinen Patch-Prozess, sondern einen funktionsfähigen Lebenszyklusansatz:
- Schwachstellen identifizieren
- bewerten und priorisieren
- Sicherheitsupdates entwickeln
- Updates sicher ausrollen
- Nutzer über relevante Sicherheitsfragen informieren
Für Produkte, bei denen automatische Sicherheitsupdates technisch sinnvoll sind, verlangt der CRA außerdem grundsätzlich eine Standardlogik mit aktivierter Auto-Update-Funktion und einer klaren Opt-out-Möglichkeit. Das ist gerade im IoT-Bereich relevant, weil viele Endnutzer Firmware-Updates sonst gar nicht einspielen würden.
Unternehmerisch heißt das: Wer 2026 oder 2027 noch neue IoT-Produkte plant, sollte den Update-Service nicht als Kundendienst-Thema behandeln, sondern als Teil der Konformitätsarchitektur. Supportlaufzeit, Cloud-Kosten, Schlüsselrotation, Signierung, Release-Management und End-of-Life-Kommunikation gehören damit in das Lastenheft.
Default-Passwörter und Secure Boot — Konkrete Pflichten
Der CRA verbietet nicht mit genau diesen zwei Wörtern „Default-Passwörter“ oder „Secure Boot für jedes Produkt“, aber die praktischen Konsequenzen für IoT-Hersteller laufen genau in diese Richtung. Unsichere Standardkonfigurationen, schwache Zugangsdaten und manipulierbare Boot-Prozesse lassen sich mit den Anforderungen aus Anhang I regelmäßig nicht mehr sauber vereinbaren.
Default-Passwörter
Bei Default-Passwörtern ist die Lage praktisch eindeutig. Wenn ein Gerät mit bekannten Herstellerzugängen, trivialen Standardkennwörtern oder unsicheren universellen Credentials ausgeliefert wird, kollidiert das mit Security-by-Default, Schutz vor unbefugtem Zugriff und der Pflicht, bekannte ausnutzbare Schwachstellen zu vermeiden. Für Hersteller bedeutet das in der Praxis:
- keine global identischen Werkspasswörter für ganze Serien
- keine fest verdrahteten Hintertüren für Support oder Service
- sichere Erstinbetriebnahme mit individuellem Geheimnis oder Zwang zum Credential-Set-up
- nachvollziehbares Credential-Management für Produktion, Service und Reset-Fälle
Gerade bei günstigen IoT-Geräten war es lange üblich, Installation und Support über generische Zugangsdaten zu vereinfachen. Unter dem CRA ist das kein tragfähiges Modell mehr. Wer Produkt, App und Backend nicht so gestaltet, dass individuelle Authentifizierung praxistauglich funktioniert, verlagert sein Komfortproblem in ein Compliance- und Haftungsproblem.
Secure Boot
Bei Secure Boot ist Präzision wichtig. Der CRA schreibt nicht ausdrücklich vor, dass jedes IoT-Gerät zwingend Secure Boot implementieren muss. Der Gesetzestext verlangt aber, dass Produkte gegen Manipulation, unbefugten Zugriff und unsichere Zustände angemessen abgesichert werden. Für viele vernetzte Geräte ist eine abgesicherte Boot-Kette deshalb der naheliegende technische Nachweis, um Firmware-Integrität und Vertrauenskette zu gewährleisten.
Die 2025 veröffentlichte Durchführungsverordnung zu wichtigen und kritischen Produkten verweist zudem bei bestimmten sicherheitsbezogenen Hardware-Funktionen ausdrücklich auf Mechanismen wie secure boot chain, vertrauenswürdige Ausführungsumgebungen oder sichere Kommunikationsschnittstellen. Daraus folgt nicht automatisch eine 1:1-Pflicht für jedes Gerät, wohl aber eine klare regulatorische Erwartung: Hersteller müssen erklären können, wie sie die Integrität der Softwarebasis technisch absichern.
Für KMU ist die richtige Leitfrage deshalb nicht: „Steht Secure Boot wörtlich im Gesetz?“ Sondern: „Wie belegen wir, dass nur autorisierte Firmware startet, Updates signiert sind und manipulierte Images nicht unbemerkt ausgeführt werden?“
CE-Kennzeichnung für IoT-Produkte
Für IoT-Produkte ist die CE-Kennzeichnung unter dem CRA kein Marketing-Siegel, sondern Ausdruck einer abgeschlossenen Konformitätslogik. Hersteller erklären damit, dass das Produkt die anwendbaren Anforderungen erfüllt und die technische Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung vorliegen.
Praktisch läuft der Weg für ein CRA-pflichtiges IoT-Produkt typischerweise so:
- Produkt-Scope bestimmen
- Kategorie prüfen: Standard, Klasse I, Klasse II oder gegebenenfalls kritisch
- Risikoanalyse und technische Dokumentation aufbauen
- Konformitätsbewertungsverfahren durchführen
- EU-Konformitätserklärung erstellen
- CE-Kennzeichnung anbringen
Für viele Hersteller ist wichtig zu verstehen, dass die CE-Kennzeichnung nicht erst am Ende als Etikettstufe beginnt. Sie ist das Ergebnis einer lückenlosen Dokumentations- und Bewertungsstrecke. Fehlen Bedrohungsmodell, Updatekonzept, Testnachweise oder Post-Market-Prozesse, fehlt faktisch auch die Grundlage für eine belastbare Konformitätserklärung.
Gerade bei Klasse-I- oder Klasse-II-Produkten steigen die Anforderungen an das Verfahren. Deshalb ist es sinnvoll, die Kennzeichnung nicht isoliert mit dem Labeling-Team oder der Regulatory-Abteilung zu behandeln, sondern früh mit Entwicklung, Produktsicherheit, Qualitätsmanagement und Einkauf zu verknüpfen.
Die Detailperspektive dazu finden Sie im Beitrag CRA und CE-Kennzeichnung. Für die begriffliche Einordnung hilft außerdem unser Glossar zur CE-Kennzeichnung für KI, auch wenn der CRA nicht mit dem AI-Act-Verfahren verwechselt werden darf.
Praxisbeispiele — Smart Home, Industrie 4.0, Medizintechnik
Der CRA wird für KMU erst verständlich, wenn man ihn an realen Produktbildern durchspielt. Drei typische Kontexte zeigen, wie unterschiedlich dieselbe Verordnung in der Praxis wirkt.
Smart Home
Ein Hersteller vertreibt vernetzte Kameras, Türschlösser und eine mobile App für Endkunden. Genau hier greift der CRA mit voller Härte, weil Smart-Home-Produkte mit Sicherheitsfunktion in der Durchführungsverordnung ausdrücklich als wichtige Produkte der Klasse I beschrieben sind. Für das Unternehmen bedeutet das:
- individuelle Zugangsdaten statt Serienpasswörter
- abgesicherte Pairing- und Onboarding-Prozesse
- verschlüsselte Kommunikation zwischen Gerät, App und Cloud
- Updatefähigkeit über mehrere Jahre
- dokumentierte Schwachstellenannahme und Patch-Steuerung
Ein Hersteller, der bisher vor allem nach Time-to-Market optimiert hat, muss Security-Engineering jetzt als Kernfunktion behandeln. Besonders riskant sind Billigkomponenten, übernommene SDKs und White-Label-Firmware ohne klare Lieferantennachweise.
Industrie 4.0
Ein mittelständischer Maschinenbauer verkauft vernetzte Sensorik, Fernwartungsmodule und Edge-Gateways an Produktionsbetriebe. Der CRA betrifft hier die Produktseite, während NIS2 je nach Betreiber und Sektor die Organisationsseite betrifft. Praktisch relevant sind:
- sichere Remote-Access-Konzepte
- harte Trennung von Servicezugängen und Kundenrollen
- signierte Firmware und kontrollierte Updatepfade
- Dokumentation der eingesetzten Komponenten und Abhängigkeiten
- sauber geregelte End-of-Life- und Supportfristen
Die größte Herausforderung liegt oft nicht im einzelnen Sensor, sondern im Systemverbund. Wenn Gateway, Cloud-Dashboard und Fernwartungsclient zusammen ein Produkt mit digitalen Elementen bilden, muss die Sicherheitslogik über die gesamte Kette tragen.
Medizintechnik
Ein Hersteller entwickelt ein vernetztes Monitoring-Gerät für eine Pflegeumgebung. Hier reicht der Blick auf den CRA allein nicht aus, weil regelmäßig weitere sektorspezifische Anforderungen hinzukommen. Trotzdem bleibt die CRA-Logik für vernetzte Komponenten relevant: Authentifizierung, sichere Updates, Incident-Handling, Nachweisdokumentation und Schutz sensibler Daten sind gerade in medizinischen Umgebungen zentral.
Zusätzlich muss geprüft werden, ob KI-Funktionen eingebettet sind, etwa automatische Erkennungsmuster, Risiko-Scores oder Priorisierung von Alarmen. Dann kommt neben CRA und gegebenenfalls Medizinprodukterecht auch der AI Act in die Bewertung.
Die praktische Konsequenz für KMU lautet deshalb: Nicht mit einzelnen Labels arbeiten, sondern mit einem Regulierungsprofil pro Produktfamilie. Erst dann wird sichtbar, welche Pflichten aus CRA, NIS2, AI Act oder Spezialrecht tatsächlich parallel laufen.
Häufig gestellte Fragen (FAQ)
Fallen alle IoT-Geräte unter den CRA?
Nein, aber sehr viele. Erfasst werden grundsätzlich Produkte mit digitalen Elementen, die direkt oder vorhersehbar mittelbar mit Netzen oder anderen Geräten verbunden werden können. Nicht entscheidend ist die Bezeichnung „IoT“, sondern die tatsächliche digitale Funktion und Konnektivität.
Was gilt für bestehende IoT-Produkte?
Bestehende Produkte werden nicht automatisch rückwirkend voll CRA-pflichtig, nur weil sie am Markt sind. Maßgeblich ist vor allem, wann sie in Verkehr gebracht wurden und ob nach dem 11. Dezember 2027 eine wesentliche Änderung an Design oder Zweck erfolgt. Wartung oder Reparatur ist nicht automatisch eine wesentliche Änderung.
Müssen Default-Passwörter abgeschafft werden?
In der Praxis ja. Der CRA verlangt sichere Standardkonfigurationen und Schutz vor unbefugtem Zugriff. Global identische Standardkennwörter, hartcodierte Service-Zugänge oder triviale Erstzugänge lassen sich damit regelmäßig nicht vereinbaren.
Welche Ausnahmen gibt es?
Ausnahmen gibt es nur begrenzt. Freie und quelloffene Software ohne kommerzielle Tätigkeit kann unter Voraussetzungen ausgenommen sein. Außerdem können sektorspezifische Spezialregime vorrangig sein. Für typische kommerzielle IoT-Produkte deutscher KMU gilt aber: erst Scope prüfen, nicht vorschnell auf eine Ausnahme hoffen.
Sind Industrie-IoT-Geräte anders reguliert als Consumer-IoT?
Die Grundpflichten gelten für beide. Unterschiede entstehen aus dem Produkttyp, der Kategorie, dem Angriffspotenzial und möglichen Spezialgesetzen. Ein Industrie-Gateway ist nicht automatisch strenger reguliert als eine Smart-Home-Kamera, aber die Konformitätsbewertung und das Schadenspotenzial sehen oft anders aus.
CTA: CRA-Pflichten jetzt in ein umsetzbares Schulungsprogramm übersetzen
Wenn Sie CRA-Pflichten für Produkt, Entwicklung, Compliance und Management strukturiert aufarbeiten wollen, ist unsere EU AI Act Schulung zwar nicht der CRA-Nachweis selbst, aber ein sinnvoller Einstieg für Teams, die Regulierungslogik, Rollen und Dokumentationsanforderungen systematisch aufbauen möchten. Gerade bei vernetzten Produkten mit KI-Funktionen hilft ein gemeinsames Verständnis der Schnittstellen zwischen CRA, NIS2 und AI Act, bevor einzelne Abteilungen widersprüchliche Prozesse etablieren.
Wenn Sie zuerst Ihr Produktportfolio sortieren möchten, lesen Sie ergänzend den Überblick zum Cyber Resilience Act, die operative Vertiefung zu CRA-Anforderungen und die Seite CRA und CE-Kennzeichnung.