Irgendwann in der zweiten Hälfte 2027 wird ein Händler auf AliExpress oder Amazon ein Smart-Home-Gerät anbieten, das kein CE-Zeichen nach dem Cyber Resilience Act trägt. Der deutsche Zoll wird es stoppen. Der Importeur — falls es einen gibt — wird haften. Und der chinesische Hersteller, der sein Produkt seit Jahren mit Standardpasswort "admin" ausliefert und seit drei Firmware-Versionen keine Sicherheitslücken gepatcht hat, wird für den EU-Markt schlicht nicht mehr existieren.
Das ist nicht Spekulation. Das ist Verordnung (EU) 2024/2847. Verabschiedet am 23. Oktober 2024, in Kraft getreten am 10. Dezember 2024, erste operative Deadline am 11. September 2026, volle Wirksamkeit ab 11. Dezember 2027.
Der Cyber Resilience Act — kurz CRA — ist das erste Mal, dass die EU IoT-Sicherheit nicht als Empfehlung formuliert, sondern als Marktvoraussetzung. Wer nicht compliant ist, darf nicht verkaufen. Punkt.
Was der CRA tatsächlich regelt — und was nicht
Der CRA gilt für "Produkte mit digitalen Elementen" (Products with Digital Elements, PDEs). Das klingt abstrakt, umfasst aber praktisch alles: eine smarte Glühbirne, einen Zigbee-Stick, einen Heimrouter, ein NAS, eine IP-Kamera, einen Smart Lock, den Shelly-Dimmer an deiner Wohnzimmerwand.
Die Verordnung unterscheidet drei Risikokategorien (Annex III und IV):
Standard (Default) ist die große Mehrheit der Consumer-IoT-Geräte: smarte Steckdosen, Lampen, Temperatursensoren, einfache Aktoren. Hersteller können per Selbstbewertung (Module A, "Internal Control") die Konformität erklären. Kein externer Auditor nötig — aber technische Dokumentation, SBOM und Schwachstellenmanagement müssen trotzdem existieren. Wichtig Klasse I sind Geräte mit sicherheitsrelevanten Funktionen. Laut Zephyr-Projektdokumentation, die sich direkt auf Annex III stützt: Smart Door Locks, Smart Home Hubs, Router, vernetzte Alarmanlagen, Babymonitore. Selbstbewertung ist hier nur erlaubt, wenn harmonisierte Normen vollständig angewendet werden — sonst muss eine Notified Body ran (Module B+C oder H). Wichtig Klasse II und Kritisch sind industrielle PLCs, Hardware-Security-Module, Smart-Meter-Gateways mit Remote-Abschaltfunktion. Für den normalen Smart-Home-Kontext vorerst nicht relevant — außer du baust gerade einen Energie-Gateway in deinen Neubau ein.Die Klassifizierung entscheidet die Kernfunktion des Geräts, nicht seine Komponenten. Ein Kaffeevollautomat mit WLAN-Chip ist "Default", auch wenn er den gleichen ESP32 enthält wie ein Sicherheits-Gateway. Espressifs eigener Developer Blog (veröffentlicht 16. März 2026) bestätigt das: "Most ESP32-based IoT products are expected to fall under the Default or Important Class I category, depending on functionality and risk profile."
Die drei Deadlines — und warum September 2026 der kritische Punkt ist
Die meisten Artikel zum CRA nennen 2027 als das magische Jahr. Das stimmt für die volle Compliance — aber die erste echte operative Pflicht greift schon am 11. September 2026.
Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten an ENISA (European Union Agency for Cybersecurity) melden. Die Meldepflicht läuft gestaffelt: innerhalb von 24 Stunden eine Early Warning, innerhalb von 72 Stunden eine detaillierte Meldung mit Produktinfo und Art des Exploits, innerhalb von 14 Tagen ein Abschlussbericht mit vollständiger Schwachstellenbeschreibung und bereitgestelltem Patch.
Wer das nicht erfüllt, riskiert Bußgelder bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes — je nachdem, was höher ist. Artikel 13 und 14 der Verordnung sind da eindeutig.
Die zweite Deadline: Juni 2026 — Conformity Assessment Bodies (die Notified Bodies) müssen bis dahin operational sein. Wer für sein Klasse-I-Gerät externe Zertifizierung braucht, muss also vor diesem Datum anfangen, Kapazitäten zu buchen.
Die dritte: 11. Dezember 2027 — Ab hier darf kein non-compliant Produkt mehr auf den EU-Markt. CE-Zeichen nur noch mit CRA-Compliance. Und CE ist Voraussetzung für die Einfuhr.
Was Hersteller konkret liefern müssen
Die technischen Anforderungen stehen in Annex I der Verordnung. Für Smart-Home-Hersteller bedeutet das in der Praxis:
Keine Default-Passwörter mehr. Jedes Gerät kommt entweder mit einzigartigem Passwort ab Werk oder zwingt den Nutzer beim ersten Start zur Passwortvergabe. "admin/admin" ist nicht mehr zulässig. Das klingt banal, war aber bei erschreckend vielen Billiggeräten noch 2024 gelebter Standard.
Sicherheitsupdates für mindestens fünf Jahre. Artikel 13(8) der Verordnung: Hersteller müssen einen Support-Zeitraum definieren und kommunizieren. Espressifs FAQ vom März 2026: "This period should be at least 5 years from when the product is placed on the market, unless a shorter period is justified." Wer weiß, dass Verbraucher ihren Shelly gerne acht bis zwölf Jahre betreiben, ahnt, was das bedeutet.
Ein SBOM in maschinenlesbarem Format. CycloneDX oder SPDX, automatisiert aus dem Build-System generiert — nicht per Hand. Syft, Trivy oder CycloneDX-CLI erledigen das für Firmware-Projekte. Der Punkt: Wenn ein CVE für eine bekannte Bibliothek veröffentlicht wird, muss der Hersteller in Minuten wissen, welche Produkte betroffen sind und welche Firmware-Version.
Schwachstellenmonitoring über den gesamten Lebenszyklus. Relevante Feeds: NVD, OSV.dev, CISA KEV. Der KEV ist der kritischste: Taucht dort eine Komponente aus dem eigenen Produkt auf, läuft sofort die 24-Stunden-Uhr für ENISA.
Technische Dokumentation nach Annex VII und VIII: Risikoabschätzung, Sicherheitsarchitektur, EU Declaration of Conformity. Default-Produkte: Selbstbewertung. Klasse-I-Geräte ohne vollständig angewendete harmonisierte Normen: externe Prüfstelle.
Wo Home Assistant und Open Source stehen
Als der CRA-Entwurf bekannt wurde, ging die Frage sofort durch die Community: Trifft das Home Assistant? Trifft es Zigbee2MQTT-Maintainer?
Die Antwort steht in Recital 18 der Verordnung: Einzelne Entwickler und Contributor werden explizit ausgenommen. Der CRA greift nur, wer ein Produkt "mit kommerzieller Absicht" auf den Markt bringt.
Home Assistant als Open-Source-Software, die Nabu Casa als Stiftung verwaltet, agiert als "Open-Source-Steward" nach Artikel 3(14) — eine Rolle mit reduzierten Pflichten: Cybersecurity-Policy dokumentieren, aktiv ausgenutzte Schwachstellen melden, mit Behörden kooperieren. Kein CE-Zeichen, keine Conformity Assessment, keine SBOM-Pflicht nach CRA.
Der Haken liegt woanders: Wer Home Assistant kommerziallerweise in ein Produkt verpackt und verkauft — ein fertiges HA-System-Kit, ein vorkonfiguriertes NAS mit HA-Image — der ist "Hersteller" im Sinne des CRA und trägt die volle Pflichtenlast. Das schreibt das Element-Blog (12. März 2026) treffend: "If a third party forks a project and commercialises it, responsibility for CRA compliance rests with that party — not with the original developer or maintainer."
Für den normalen Home-Assistant-Nutzer, der sein eigenes System betreibt: keine direkte CRA-Pflicht. Für den Hersteller des Zigbee-Sticks, den er dabei einsetzt: volle Pflicht.
Was das für Shelly, Sonoff und ESP32-basierte Geräte bedeutet
Shelly und Sonoff sind in der DACH-Community beliebt — erschwinglich, flashbar mit Tasmota oder ESPHome, und von Haus aus schon auf einem besseren Sicherheitsniveau als viele Billigkonkurrenten. Trotzdem müssen auch die nachziehen.
Shelly — Allterco Robotics, Bulgarien, also EU-Hersteller — hat hier einen strukturellen Vorteil: als EU-Unternehmen direkt im Regulierungsrahmen, keine Importeur-Extraschicht. Die Gen2/Gen3-Geräte laufen auf ESP32, Espressif arbeitet aktiv an CRA-Compliance-Unterstützung (SBOM-Tooling über west spdx und das ESP-IDF Security Dashboard auf espressif.github.io). Der Espressif-Blogpost vom März 2026 zeigt: Die Platform-Seite ist vorbereitet. Die OEM-Pflicht liegt beim Gerätehersteller.
Sonoff (ITEAD, China) ist als Nicht-EU-Hersteller auf Importeure angewiesen. Das CRA-Regime macht den EU-Importeur zum de-facto-Mitverantwortlichen: Er muss prüfen, dass der Hersteller seine Pflichten erfüllt hat, bevor er das Produkt in den EU-Markt einführt. Für ITEAD bedeutet das: SBOM, Vulnerability Disclosure Policy, 5-Jahre-Support-Erklärung, dokumentiertes Update-System — oder kein EU-Regalplatz mehr.
Für die Community, die Geräte selbst flasht: Ein Gerät, das mit Custom-Firmware (Tasmota, ESPHome) betrieben wird, läuft außerhalb des Compliance-Rahmens des ursprünglichen Herstellers. Die CRA-Pflicht des Herstellers bezieht sich auf seine Firmware. Wer seinen Shelly auf ESPHome umrüstet, übernimmt faktisch die Verantwortung für sein eigenes System — was bei Home-Assistant-Nutzern niemanden überraschen dürfte.
Der eigentliche Effekt: Marktbereinigung
Die Verordnung ist nicht dafür gebaut, Enthusiasten das Leben schwer zu machen. Sie ist dafür gebaut, den Markt zu bereinigen.
Die reale Situation: Auf Amazon und AliExpress gibt es heute Tausende Smart-Home-Geräte chinesischer Kleinhersteller, die seit Jahren keine Firmware-Updates bekommen, default credentials ausliefern und ihre Cloud-Infrastruktur irgendwann einstellen. Genau diese Geräte — Vstarcam-Kameras mit Backdoor (Artikel 043 hat das dokumentiert), NoName-Thermostate mit hartkodierten Passwörtern, Billig-Hubs die seit 2020 kein Update bekommen haben — treffen die neuen Anforderungen massiv.
Was verschwindet: Hersteller ohne Vulnerability Disclosure Policy. Geräte ohne funktionierende OTA-Update-Mechanismen. Produkte, deren Cloud eingestellt wird, ohne dass der Käufer das vorher weiß. Günstige Kameras, die ihren Datenstrom unverschlüsselt durchs Netz schicken.
Was bleibt: Hersteller, die schon länger in Security-by-Design investiert haben. Offene Ökosysteme mit Community-Vulnerability-Reporting. Matter-zertifizierte Geräte, die ohnehin schon engere Sicherheitsanforderungen als der Marktdurchschnitt erfüllen.
Was der CRA für Käufer bedeutet — heute
Wer heute ein Smart-Home-Gerät kauft, das nach dem 11. Dezember 2027 noch supported sein soll, hat drei sinnvolle Fragen:
Wie lang ist der dokumentierte Support-Zeitraum? Ab 2027 muss der Hersteller das auf Verpackung oder im Onlineshop angeben. Bis dahin: selbst nachschauen, ob es überhaupt eine Antwort gibt.
Hat der Hersteller ein öffentliches Vulnerability-Disclosure-Programm? Eine SECURITY.md im GitHub-Repository und eine erreichbare security@-Adresse sind Mindeststandard. Fehlt beides, fehlt die grundlegende Bereitschaft.
Läuft das Gerät lokal ohne Cloud? Das ist nicht nur Datenschutz — wenn die Cloud eingestellt wird, muss der Hersteller das nach CRA kommunizieren. Shelly mit lokalem API, Home Assistant mit Matter over Thread: beides funktioniert auch ohne Server in Shenzhen.
Ob der Hersteller aus der EU kommt oder wenigstens ein identifizierbarer EU-Importeur dahintersteht, ist die vierte Frage. Der Importeur haftet mit. Das ist ein natürliches Filter, das funktioniert.
Harmonisierte Normen: noch nicht fertig
Ein Detail, das für Hersteller relevant ist: Die harmonisierten Normen, auf die der CRA verweist, sind größtenteils noch nicht fertig. ETSI EN 303 645 (Cyber Security for Consumer IoT) existiert — aber die produktspezifischen CRA-harmonisierten Standards (prEN 304 626 für Betriebssysteme, prEN 304 636 für Firewalls etc.) sind Draft. Espressifs FAQ: "Most harmonized standards expected to start publishing by end of the year 2026."
Das hat eine praktische Konsequenz: Wer heute für Klasse-I-Geräte auf harmonisierte Normen bauen will, um die Selbstbewertung zu nutzen (Module A), hat möglicherweise nicht alle relevanten Normen zur Verfügung — und muss damit entweder einen Notified Body einschalten oder bis 2026 warten. Die Conformity Assessment Bodies sind laut Verordnung erst ab 11. Juni 2026 operational.
Ein Stichtag, der zählt
Der CRA kommt nicht mit einer Übergangsphase, die man aussitzen kann. Er kommt mit Bußgeldern, CE-Pflicht und Marktzugangssperren — und sein erster echter Test ist nicht 2027, sondern September 2026.
Ob die Marktüberwachung das dann auch konsequent exekutiert, ist eine andere Frage. Die EU hat mit Regulierung nicht selten Gesetze geschrieben, die auf dem Papier scharf waren und in der Praxis zahnlos blieben. Beim CRA gibt es zumindest einen Hebel, den es vorher nicht gab: das CE-Zeichen als Marktzugangsvoraussetzung. Wer kein CE hat, kommt nicht rein — und Importeure, die das ignorieren, haften persönlich.
Für die Home-Assistant-Community: Die Verordnung trifft uns als Nutzer kaum direkt. Aber sie trifft jeden Hersteller, dessen Zigbee-Aktor, Kamera oder Hub wir ins Netz hängen. Wenn das dazu führt, dass mehr Hersteller einen Vulnerability-Disclosure-Kanal einrichten und Firmware länger pflegen — dann hat das regulatorische Papiertiger tatsächlich Biss bekommen.
Quellen:
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Amtsblatt der Europäischen Union, 20. November 2024 — eur-lex.europa.eu
- Zephyr Project Documentation: EU Cyber Resilience Act, 19. April 2026 — docs.zephyrproject.org
- Espressif Developer Portal: Understanding the EU Cyber Resilience Act (CRA), 16. März 2026 — developer.espressif.com
- Complaro: CRA Compliance Checklist: What You Need Before September 2026, 31. März 2026 — complaro.com
- Element.io: The Cyber Resilience Act: Implications for open source and digital products, 12. März 2026 — element.io
- Kunnus / Think Ahead Technologies GmbH: Smart Home und CRA: Was Hersteller von Consumer Electronics jetzt beachten müssen, 18. Dezember 2025 — kunnus.tech
- European Commission: Cyber Resilience Act — Frequently Asked Questions — digital-strategy.ec.europa.eu
- Industrial Cyber: European Commission opens consultation on draft guidance to help manufacturers comply with CRA, 9. März 2026 — industrialcyber.co
