Die Herstellung eines IoT-Geräts wird traditionell als Hardwareprojekt betrachtet: Elektronik, Gehäuse, Stromversorgung, EMV, Firmware, Fertigungsprüfung, Dokumentation und anschließend der Vertrieb.

Ein vernetztes Produkt bleibt nach der Auslieferung jedoch nicht unverändert. Neue Schwachstellen tauchen im eigenen Code, in verwendeten Bibliotheken, im Betriebssystem oder in den Kommunikationskomponenten auf. Die Bedrohungslage kann sich ändern, während das Produkt jahrelang am selben Standort in Betrieb ist.

Der Cyber Resilience Act (CRA) der Europäischen Union macht dieses Lebenszyklusrisiko zur Pflicht des Herstellers.

Wo stehen wir im September 2026?

Der CRA, also die Verordnung (EU) 2024/2847, ist am 10. Dezember 2024 in Kraft getreten.

Die wesentlichen Produktanforderungen gelten ab dem 11. Dezember 2027. Die Meldepflichten gelten jedoch bereits seit dem 11. September 2026. Die Vorbereitung ist also kein fernes Projekt, das erst Ende 2027 beginnt.

Die Verordnung erfasst Hardware- und Softwareprodukte mit digitalen Elementen. Den genauen Anwendungsbereich, die Produktkategorie und das Konformitätsbewertungsverfahren muss jeder Hersteller für sein eigenes Produkt bestimmen.

Ein industrielles IoT-Gateway, ein netzwerkfähiger Zähler, eine intelligente Steuerung oder zugehörige Software gehört mit hoher Wahrscheinlichkeit zu einer Produktwelt, die wegen des CRA bewusst überprüft werden muss.

Security by Design ist ab jetzt kein Schlagwort mehr

Die Verordnung schreibt verbindliche Cybersicherheitsanforderungen für Konzeption, Entwicklung, Herstellung und Wartung vor. Sicherheit lässt sich deshalb nicht am Projektende mit einem Penetrationstest auf das fertige Produkt „aufsetzen“.

Bereits bei der Architektur muss unter anderem entschieden werden:

  • welche Dienste standardmäßig erreichbar sind;
  • wie das Gerät eindeutig identifiziert wird;
  • ob es werkseitige, gemeinsam genutzte oder leicht zu erratende Zugangsdaten gibt;
  • wie Daten bei der Übertragung und bei der Speicherung geschützt sind;
  • wie der Zugriff eingeschränkt werden kann;
  • wie Sicherheitsereignisse protokolliert werden können;
  • was bei fehlerhaften oder manipulierten Eingaben geschieht;
  • wie ein sicherer Zustand wiederhergestellt werden kann.

Das Prinzip der minimalen Angriffsfläche bedeutet: Was für die Funktion des Produkts nicht erforderlich ist, sollte standardmäßig nicht verfügbar sein.

Aktualisierbarkeit ist eine Produktfunktion

Es genügt nicht, ein vernetztes Gerät so zu konzipieren, dass es am Verkaufstag sicher erscheint. Es muss auch sicher aktualisierbar sein.

Dafür kann Folgendes erforderlich sein:

  • digital signierte, auf Integrität geprüfte Firmware;
  • ein sicherer Aktualisierungskanal;
  • Versions- und Kompatibilitätsverwaltung;
  • Wiederherstellung nach einem fehlgeschlagenen Update;
  • ein umfangreiches, aber kontrolliertes Gerätemanagement;
  • Update-Protokoll und Installationsstatus;
  • eine eindeutige Kommunikation des Supportzeitraums.

OTA-Updates allein bedeuten noch keine Sicherheit. Fehlen Signaturprüfung, Berechtigungsverwaltung, Rollback oder ein Installationsnachweis, kann der Aktualisierungsmechanismus selbst zur Angriffsfläche werden.

Schwachstellenmanagement über den gesamten Supportzeitraum

Eine wesentliche Neuerung des CRA besteht darin, dass er Produktsicherheit als Prozess behandelt. Der Hersteller muss Schwachstellen entgegennehmen, bewerten, beheben und kommunizieren können.

Dafür braucht es auch intern eine funktionierende Ordnung:

  • wer Sicherheitsmeldungen entgegennimmt;
  • wie Schweregrad und Betroffenheit bewertet werden;
  • welche Produktversionen betroffen sind;
  • welche Komponente das Problem verursacht;
  • wie die Korrektur erstellt und getestet wird;
  • wie sie zu den Kunden gelangt;
  • wie der Abschluss dokumentiert werden kann.

Eine E-Mail-Adresse allein ist noch kein Prozess für das Schwachstellenmanagement.

Man muss wissen, was in der Firmware steckt

Moderne Firmware und Software bestehen selten vollständig aus eigenem Code. Open-Source-Bibliotheken, Betriebssystemkomponenten, Netzwerk-Stacks und SDKs von Zulieferern bauen aufeinander auf.

Wird eine dieser Komponenten verwundbar, muss der Hersteller wissen, welche Produkte und Versionen betroffen sind. Dafür ist ein geordnetes Verzeichnis der Abhängigkeiten und Komponenten nötig. Eine Software-Stückliste (SBOM) kann dabei ein wichtiges Werkzeug sein.

Eine SBOM ist allerdings nur eine Bestandsliste. Einen Mehrwert bietet sie erst, wenn sie mit der Versionsverwaltung, den Schwachstelleninformationen, dem betroffenen Gerätebestand und dem Aktualisierungsprozess verknüpft ist.

Die Meldepflicht setzt Erkennungsfähigkeit voraus

Seit dem 11. September 2026 unterliegen Hersteller bei bestimmten aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen einer Meldepflicht. Das genaue Verfahren und die aktuellen behördlichen Leitlinien muss der Hersteller entsprechend seiner Rolle und seinem Produkt befolgen.

Aus praktischer Sicht steht jedoch eines fest: Was eine Organisation nicht erkennen, intern eskalieren und den Produktversionen zuordnen kann, kann sie auch nicht fristgerecht melden.

Voraussetzungen für den Meldeprozess sind daher:

  • ein Produkt- und Versionsverzeichnis;
  • ein Ansprechpartner für Sicherheit;
  • eine Klassifizierung von Vorfällen;
  • klare Entscheidungs- und Freigaberegeln;
  • Kundenkommunikation;
  • ein nachweisbares Ereignisprotokoll.

Hinter der CE-Kennzeichnung stehen künftig Entwicklungsnachweise

Nach dem CRA wird die CE-Kennzeichnung konformer Produkte auch anzeigen, dass sie die Cybersicherheitsanforderungen erfüllen. Je nach Risikoeinstufung des Produkts kann ein unterschiedliches Konformitätsbewertungsverfahren erforderlich sein, bei bestimmten Kategorien unter Einbeziehung einer benannten Stelle (Notified Body).

Das erfordert einen dokumentierten Entwicklungsprozess. Risikobewertung, Architekturentscheidungen, Testergebnisse, Komponenteninformationen, Schwachstellenmanagement und Freigabenachweise müssen aufbewahrt werden.

Im Nachhinein lässt sich kaum glaubwürdig rekonstruieren, warum eine Sicherheitsentscheidung Jahre zuvor getroffen wurde. Die Dokumentation muss deshalb parallel zur Entwicklung entstehen.

Was bedeutet das für eine Entwicklung nach Art von OrigSmart?

Aufgrund der Hardware-, Gateway- und Plattformkompetenzen von OrigSmart darf die Sicherheit nicht am Gerätegehäuse enden. Der gesamte Lebenszyklus des Systems muss gemeinsam betrachtet werden:

  • kundenspezifische Hardware und Firmware;
  • Feldkommunikation;
  • Geräteidentität und Konfiguration;
  • sichere Aktualisierung;
  • Berechtigungen auf Plattformseite;
  • Ereignisprotokoll und Monitoring;
  • Vorfall- und Schwachstellenmanagement;
  • Betriebsprozesse auf Kundenseite.

Diese vollständige Wertschöpfungskette bedeutet zugleich Verantwortung und Wettbewerbsvorteil. Ein Hersteller und Integrator, der Hardware, Software, Betrieb und nachweisbare Sicherheitsprozesse bereits beim Produktdesign miteinander verbindet, wird Ende 2027 keine Konformitätsdokumente unter Zeitdruck erstellen müssen.

Beim CRA geht es nicht darum, dem IoT-Gerät mehr Papier beizulegen. Es geht darum, dass das digitale Produkt während seines gesamten unterstützten Lebenszyklus ein beherrschbares Cybersicherheitsrisiko bleibt.

Lassen Sie uns Ihr Projekt besprechen

Quellen

Hinweis: Dieser Artikel dient der allgemeinen fachlichen Information und stellt keine Rechts- oder Konformitätsberatung dar.