Der EU Cyber Resilience Act trifft IoT diesen September. Die meisten Produktteams sind nicht bereit.

Am 11. September 2026 zeigt der EU Cyber Resilience Act zum ersten Mal Zähne. Ab diesem Datum muss jeder, der ein Produkt mit digitalen Elementen in der EU verkauft — ein smartes Thermostat, einen Flottentracker, eine vernetzte Kaffeemaschine, die Firmware in jedem davon — aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an die EU-Behörden melden. Nicht 24 Geschäftsstunden. Vierundzwanzig Stunden.

Das ist in drei Monaten. Und es gilt für Produkte, die Sie bereits ausgeliefert haben — nicht nur für die, die nach der Deadline auf den Markt kommen.

Die meiste Berichterstattung zum CRA dreht sich um Dezember 2027, wenn die vollen Secure-by-design-Anforderungen und die CE-Kennzeichnungspflicht kommen. Diese Sichtweise ist bequem — und falsch. Man kann eine Schwachstelle nicht innerhalb von 24 Stunden melden, wenn die Maschinerie fehlt, um sie zu finden, zu triagieren und einzureichen. Und diese Maschinerie baut man nicht in einem Quartal.

Was der CRA abdeckt (vermutlich Ihr Produkt)

Die Verordnung spricht von „Produkten mit digitalen Elementen“, und das ist so breit gemeint, wie es klingt: Hardware mit Software darin, plus eigenständige Software. Consumer-IoT, Industriesensoren, Router, in der EU verkaufte Mobile-Apps, der eingebettete Code in einem Verkaufsautomaten. Wenn es Code ausführt und auf dem EU-Markt ist, sollte die Standardannahme lauten: Es fällt darunter.

Wo Ihr Unternehmen sitzt, spielt keine Rolle. Wie die DSGVO folgt der CRA dem Produkt in den Markt. Ein US- oder UK-Startup, das smarte Geräte an deutsche Kunden verkauft, trägt dieselben Pflichten wie ein Hersteller in München.

Ein paar Kategorien entkommen, weil sie anderswo reguliert sind: Medizinprodukte, Autos, Luftfahrtsysteme, manche Schiffsausrüstung. Open Source bekommt eine Sonderbehandlung — dazu weiter unten. Für alle anderen gilt ein Zeitplan mit zwei Daten, die zählen: 11. September 2026 für die Meldepflichten, 11. Dezember 2027 für den Rest.

Der 11. September ist die eigentliche Deadline

Das erwartet die Verordnung, wenn jemand ein Loch in Ihrem Produkt aktiv ausnutzt: eine Frühwarnung an Ihr nationales CSIRT innerhalb von 24 Stunden nach Kenntnisnahme. Eine ausführlichere Meldung innerhalb von 72 Stunden. Ein Abschlussbericht innerhalb von 14 Tagen, nachdem ein Fix verfügbar ist. Bei schwerwiegenden Vorfällen gilt dasselbe Muster, mit einem Monat für den Abschlussbericht. Alles läuft über eine neue zentrale Meldeplattform, die es gleichzeitig an das CSIRT Ihres Mitgliedstaats und an ENISA, die Cybersicherheitsagentur der EU, weiterleitet.

Lesen Sie das noch einmal mit den Augen eines Produktmanagers, und das Problem liegt auf der Hand. „Innerhalb von 24 Stunden nach Kenntnisnahme“ setzt voraus, dass Sie überhaupt Kenntnis erlangen. Die meisten kleinen und mittleren Gerätehersteller haben keinen strukturierten Weg zu erfahren, dass gerade ein CVE für eine Bibliothek in ihrer Firmware veröffentlicht wurde, kein Postfach, über das ein Security-Researcher einen Menschen erreicht, und keine interne Antwort auf die Frage: „Wer entscheidet, dass das als aktiv ausgenutzt gilt — und wer meldet?“

Deshalb ist die praktische SBOM-Deadline 2026, nicht 2027. Die Software Bill of Materials — ein maschinenlesbares Inventar jeder Komponente in Ihrem Produkt — ist formal eine Anforderung für 2027. Aber man kann keine Abhängigkeiten überwachen, die man nicht aufgelistet hat, und keine 24-Stunden-Frist halten mit einem Triage-Prozess, der mit „Moment, nutzen wir diese Bibliothek überhaupt?“ beginnt. Die Meldepflicht zieht die SBOM-Arbeit klammheimlich ein Jahr nach vorn.

Noch ein unbequemes Detail: Die Meldepflicht erfasst Produkte, die bereits auf dem Markt sind. Das Gerät, das Sie 2022 mit dem vagen Plan „Security klären wir später“ ausgeliefert haben, fällt in den Anwendungsbereich, sobald jemand anfängt, es auszunutzen.

Was Ihr Produkt bis Ende 2027 braucht

Die Welle im Dezember 2027 ist der größere Engineering-Aufwand. Für Produkte, die ab diesem Datum auf den Markt kommen, gehören zu den grundlegenden Anforderungen:

• Auslieferung ohne bekannte ausnutzbare Schwachstellen, mit sicherer Standardkonfiguration — was unter anderem das Ende der Ära des universellen Standardpassworts bedeutet.
• Ein echter Update-Mechanismus: Sicherheitsupdates, wo möglich per OTA ausgeliefert, kryptografisch signiert, auf dem Gerät verifiziert, gegen Rollback auf ältere verwundbare Versionen geschützt und robust genug, um die Flotte nicht mitten im Update zu bricken.
• Eine maschinenlesbare SBOM, in der Praxis SPDX oder CycloneDX, generiert als Teil des Builds statt einmal im Jahr von Hand zusammengetragen.
• Eine Coordinated-Vulnerability-Disclosure-Policy mit einem öffentlichen Weg für Researcher, Probleme zu melden — und jemandem, der die Eingänge tatsächlich liest.
• Kostenlose Sicherheitsupdates über den Support-Zeitraum des Produkts — mindestens fünf Jahre, oder die erwartete Lebensdauer des Produkts, falls kürzer.

Bestätigt wird die Konformität mit der CE-Kennzeichnung — demselben Zeichen, das Sie von Elektronik kennen, jetzt erweitert um Cybersicherheit. Die meisten Produkte können sich selbst bewerten. Die „wichtigen“ Klassen — Router, Firewalls, Passwortmanager, Smart-Home-Hubs mit Sicherheitsfunktionen und dergleichen — brauchen eine benannte Stelle, die die Hausaufgaben prüft. Es lohnt sich, früh herauszufinden, in welchen Topf Ihr Produkt fällt, denn die Kapazität der benannten Stellen wird 2027 ein Engpass.

Die Bußgelder — und das Kleingedruckte

Verstöße gegen die grundlegenden Anforderungen kosten bis zu 15 Mio. € oder 2,5% des gesamten weltweiten Jahresumsatzes — je nachdem, was höher ist. Geringere Verstöße liegen bei 10 Mio. € oder 2%, und wer die Behörden in die Irre führt, zahlt bis zu 5 Mio. € oder 1%. Die Prozentsätze sind der Punkt — das ist Arithmetik im DSGVO-Stil, so gebaut, dass Ignorieren niemals billiger sein kann als Einhalten.

Zwei Ausnahmen werden gern überinterpretiert. Kleinst- und Kleinunternehmen können nicht dafür gebüßt werden, die 24-Stunden- und 72-Stunden-Meldefristen zu verpassen — aber jede andere Pflicht bleibt voll bußgeldbewehrt. Das ist also ein Zugeständnis, keine Freistellung. Und Open-Source-Stewards (Stiftungen und Maintainer, die Software entwickeln, ohne sie zu monetarisieren) sind komplett von Bußgeldern ausgenommen. Sobald dieser Open-Source-Code allerdings in Ihrem kommerziellen Produkt steckt, sind Sie der Hersteller — und seine Schwachstellen sind Ihr Meldeproblem.

Was bis September zu tun ist

Wer ein vernetztes Produkt in der EU verkauft oder verkaufen will, hat eine kurze, konkrete Sommer-Checkliste. Inventarisieren Sie, was tatsächlich in Ihren Produkten steckt — generieren Sie eine SBOM aus dem Build, rekonstruieren Sie keine aus dem Gedächtnis. Richten Sie einen Eingangskanal für Schwachstellen ein: eine security.txt, ein überwachtes Postfach, eine Disclosure-Policy, die ein Researcher findet. Schreiben Sie das Incident-Runbook und spielen Sie die 24-Stunden-Uhr einmal trocken durch, an einem fiktiven CVE — damit der erste Ernstfall nicht zugleich die Generalprobe ist. Und prüfen Sie die Klassifizierung Ihres Produkts, denn sie entscheidet, ob 2027 Selbstbewertung bedeutet oder eine Audit-Warteschlange.

Der härteste Punkt steht nicht auf der Liste, weil er kein September-Problem ist: im Feld aktualisierbare Firmware. Wenn Ihre Geräte heute kein signiertes Update per OTA annehmen können, kostet das Nachrüsten Monate — über Bootloader, Auslieferungsinfrastruktur und Flottenbetrieb hinweg. Teams, die 2027 anfangen, machen das während der Durchsetzungsphase statt davor.

Nichts davon ist exotisches Engineering. Signierte Updates, Dependency-Tracking, ein Weg, auf dem Ihnen jemand sagen kann, dass Ihr Produkt kaputt ist — ein gut geführtes Produktteam will das ohnehin, so wie es Tests und Backups will. Der CRA hat aus „wollen“ nur „müssen“ gemacht und ein Datum drangehängt. Zwei Daten, genau genommen. Das zweite bekommt die ganze Aufmerksamkeit. Das erste ist die Deadline.