BSI-Empfehlungen zur IoT-Sicherheit helfen dabei, vernetzte Geräte, industrielle Steuerungen und ihre Betriebsumgebung zusammen abzusichern. Entscheidend sind nachvollziehbare Zuständigkeiten, kontrollierte Kommunikationswege und ein beherrschbarer Lebenszyklus. Eine Maschine wird nicht allein durch ein Sicherheitszertifikat oder eine vorgeschaltete Firewall sicher. Ebenso wenig begründet jeder IoT-Einsatz automatisch dieselben gesetzlichen Pflichten.
Für die rechtliche Einordnung sind drei Ebenen zu trennen: Anforderungen an das Produkt und seinen Hersteller, Sicherheitsanforderungen an die betreibende Einrichtung und der Schutz personenbezogener Daten. Seit dem 11. September 2026 gelten bereits die Hersteller-Meldepflichten des Cyber Resilience Act. Seine wesentlichen übrigen Produktpflichten werden grundsätzlich am 11. Dezember 2027 anwendbar. Für die Planung einer industriellen Anlage ist deshalb sowohl der heutige Betrieb als auch die künftige Beschaffung relevant.
Welche BSI-Unterlagen passen zu industriellen IoT-Geräten?
Im IT-Grundschutz-Kompendium, Edition 2023 behandelt IND.1 die Prozessleit- und Automatisierungstechnik. IND.2.1 betrifft allgemeine ICS-Komponenten, also Komponenten industrieller Steuerungssysteme. Ergänzend existieren spezifische Bausteine etwa für speicherprogrammierbare Steuerungen, Sensoren und Aktoren sowie Maschinen. IND.3.2 behandelt Fernwartung im industriellen Umfeld. Eine pauschale Bezeichnung „IND.x“ bezeichnet dagegen keinen einzelnen verbindlichen IoT-Standard.
Die Auswahl richtet sich nach dem tatsächlichen System. Ein vernetzter Temperatursensor, sein Gateway, eine Engineering-Station und die Cloud-Auswertung haben unterschiedliche Funktionen und Angriffsflächen. Für eine vollständige Modellierung kommen neben industriellen Bausteinen beispielsweise Anforderungen an Netze, Identitäten, Outsourcing und Protokollierung hinzu. Die Grundschutz-Methodik erklärt, wie diese Zielobjekte und ihre Abhängigkeiten zusammengeführt werden.
Die Wörter MUSS und SOLLTE kennzeichnen Anforderungen innerhalb des jeweiligen BSI-Bausteins. Daraus folgt nicht, dass jede dort beschriebene Maßnahme für jedes deutsche Unternehmen unmittelbar gesetzlich vorgeschrieben ist. Verbindlichkeit kann sich etwa aus einer einschlägigen Rechtsnorm, einer vertraglichen Vorgabe oder dem gewählten Nachweisverfahren ergeben. Unabhängig davon liefern die Bausteine einen fachlichen Maßstab, dessen Anwendbarkeit und Umsetzung im konkreten Sicherheitskonzept begründet werden sollten.
Auch die technische Richtlinie TR-03183 ist sauber einzuordnen. Teil 1 in Version 1.0.0 erläutert ausdrücklich, dass er Herstellern bei der CRA-Vorbereitung hilft, selbst keine Herstellerpflichten begründet und keine Konformitätsvermutung erzeugt. Die Anwendung dieser BSI-Hilfe ist daher kein pauschaler Nachweis vollständiger CRA-Konformität. Wer eine Konformitätsaussage bewertet, muss das Produkt, die geprüfte Version, den Prüfgegenstand und das tatsächlich vorgesehene Verfahren betrachten.
Herstellerrolle, Betreiberpflichten und Datenschutz bestimmen
Der Cyber Resilience Act, Verordnung (EU) 2024/2847, erfasst grundsätzlich auf dem Markt bereitgestellte Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung einschließt. Dazu können Hardware, Software und zugehörige erforderliche Fernverarbeitungslösungen gehören. Der konkrete Anwendungsbereich enthält Ausnahmen und Abgrenzungen zu anderen Produktregelungen. Die Bezeichnung IoT allein entscheidet deshalb noch nicht über die Einordnung.
Ein Unternehmen, das ein Gerät lediglich für seine Produktion einkauft, ist dadurch nicht automatisch dessen Hersteller. Eigene Entwicklung, Vermarktung unter eigenem Namen oder relevante Veränderungen können die Rollenprüfung dagegen erforderlich machen. Dokumentieren Sie, welches Unternehmen das Produkt in Verkehr bringt, wer Komponenten integriert und wer den späteren Betrieb verantwortet. Auch bei einer schlüsselfertig gelieferten Anlage verbleiben Aufgaben beim Betreiber, etwa Zugangsverwaltung und sichere Einbindung ins Werksnetz.
Für besonders wichtige und wichtige Einrichtungen enthält § 30 BSIG Anforderungen an geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen. Ob eine Einrichtung erfasst wird, hängt unter anderem von Einrichtungsart, Größe, Sondertatbeständen und gesetzlichen Ausnahmen ab. Nicht jede vernetzte Maschine macht ihren Eigentümer zur regulierten Einrichtung. Die gesonderte Prüfung erläutert der Beitrag zur NIS2-Umsetzung in Deutschland.
Bei regulierten Betrieben gehört die OT in die Betrachtung, soweit ihre Systeme, Komponenten und Prozesse für die Dienste relevant sind. Für Betreiber kritischer Anlagen können zusätzliche Anforderungen gelten. Die praktische Verbindung zwischen Unternehmenspflichten und Anlagenbetrieb behandelt der Leitfaden zu NIS2 für industrielle Anlagen und OT. Produktkonformität und ein betreiberbezogenes Sicherheitskonzept beantworten dabei verschiedene Fragen; eines ersetzt das andere nicht.
Ein Inventar muss Entscheidungen ermöglichen
Erfassen Sie nicht nur Gerätenamen und IP-Adressen. Für eine belastbare Betriebsentscheidung sind Funktion, Standort, verantwortliche Person, Firmwarestand, Kommunikationspartner, Fernzugänge und Supportende hilfreich. Dokumentieren Sie außerdem, welche Anlage bei Ausfall betroffen ist und welche technischen oder vertraglichen Einschränkungen Änderungen erschweren. Ein Inventar ohne zuständige Person hilft wenig, wenn eine kritische Herstellermeldung eingeht.
Berücksichtigen Sie versteckte Abhängigkeiten: Zeitserver, zentrale Identitätsdienste, Lizenzprüfung, DNS, externe Analyseplattformen und Wartungsgateways können den Betrieb beeinflussen. Eine lokal arbeitende Steuerung kann von einem entfernten Dienst abhängig sein, obwohl dieser im ursprünglichen Netzplan fehlt. Stellen Sie deshalb gemeinsam mit Instandhaltung und Lieferanten fest, welche Verbindung für welchen Vorgang benötigt wird und was bei deren Ausfall geschieht.
Für die Erhebung ist das Produktionsrisiko maßgeblich. Ein unvorbereiteter aktiver Scan kann empfindliche ältere Komponenten stören. Prüfen Sie zunächst vorhandene Konfigurationen, Lieferunterlagen und geeignete passive Beobachtungsmöglichkeiten. Gezielte technische Prüfungen lassen sich anschließend mit Anlagenverantwortlichen und Herstellern abstimmen. Das ist eine praktische Vorgehensweise zur Risikobegrenzung, keine gesetzlich vorgeschriebene Reihenfolge für jede Anlage.
Die Risikoanalyse nach BSI-Standard 200-3 hilft, Schutzbedarf und konkrete Gefährdungen zusammenzubringen. Eine manipulierte Temperaturanzeige kann bei einer Komfortanwendung vor allem Unannehmlichkeiten verursachen, bei einer Prozesssteuerung aber eine gefährliche Fehlentscheidung auslösen. Bewerten Sie Vertraulichkeit, Integrität und Verfügbarkeit deshalb anhand des physischen Prozesses und nicht nur anhand des Gerätepreises.
Kommunikationswege begrenzen und Abhängigkeiten erhalten
Der Baustein IND.2.1 Allgemeine ICS-Komponente verlangt innerhalb seines Anwendungsrahmens die Trennung der ICS-Komponenten von der Office-IT. IND.1 ergänzt die Betrachtung durch ein geeignetes Zonenkonzept. Praktisch werden Systeme mit vergleichbarem Schutzbedarf und passenden Betriebsabhängigkeiten zusammengefasst; Übergänge werden ausdrücklich freigegeben und kontrolliert.
Beginnen Sie mit den benötigten Datenflüssen. Welche Steuerung sendet an welches Leitsystem, welcher Dienst darf konfigurieren und welche Informationen müssen ins Unternehmensnetz? Eine Firewallregel sollte diesen Zweck erkennen lassen. Eine breite Freigabe für ein ganzes Produktionsnetz erleichtert zwar zunächst die Inbetriebnahme, erschwert aber später die Begrenzung eines kompromittierten Rechners.
Segmentierung muss zugleich den sicheren Prozess erhalten. Ein ungeplanter Verbindungsabbruch kann die Produktion beeinträchtigen oder Warninformationen unterbrechen. Prüfen Sie deshalb Abhängigkeiten, Ausfallverhalten und Wiederanlauf vor einer Änderung. Ein gesondertes Wartungsfenster, ein Rückfallplan und die Anwesenheit verantwortlicher Fachleute können erforderlich sein. Eine Datendiode oder vollständige physische Trennung ist eine mögliche Speziallösung, aber kein allgemeines Gütesiegel für jede OT-Architektur.
Für administrative Verbindungen und schützenswerte Datenübertragung sind geeignete kryptographische Verfahren ein wichtiger Baustein. Die BSI-Empfehlungen zur Kryptographie unterstützen die Auswahl. Berücksichtigen Sie zusätzlich Zertifikatslaufzeiten, Schlüsselverwaltung und die Folgen einer gescheiterten Erneuerung. Ein verschlüsselter Kanal verhindert weder den Missbrauch eines unberechtigt vergebenen Administratorkontos noch Angriffe über eine bereits kompromittierte Gegenstelle.
Fernwartung unter Kontrolle des Betreibers organisieren
Ein dauerhaft erreichbarer Lieferantenzugang kann die Schutzwirkung der übrigen Architektur unterlaufen. Erfassen Sie daher auch Wartungsverbindungen, die in einer Maschine vorkonfiguriert sind, über Mobilfunk laufen oder aktuell deaktiviert erscheinen. Legen Sie fest, welcher Dienstleister welche Tätigkeiten an welchen Systemen ausführen darf und wer eine Sitzung intern freigibt. Die verantwortliche Stelle muss den Zugang bei Bedarf auch beenden können.
Der BSI-Baustein IND.3.2 Fernwartung im industriellen Umfeld unterscheidet unter anderem verbindliche Regeln für Dritte, kontrollierte Zugänge und technische Entkopplung. Er ist keine vollständige Freigabe für fernbedientes Anlaufen oder Stoppen einer Anlage; solche steuernden Zugriffe auf Prozessebene liegen außerhalb seines beschriebenen Umfangs und erfordern eine gesonderte Sicherheitsbetrachtung.
Für eine übliche Wartungssituation kann ein kontrollierter Zugang über einen Sprungserver sinnvoll sein. Individuelle Konten, passende zusätzliche Authentisierung und zeitlich begrenzte Freigaben ermöglichen eine bessere Zuordnung als ein gemeinsam genutztes Lieferantenpasswort. Überprüfen Sie auch die Wartungsgeräte und den Dateiaustausch. Eine sichere Sitzung hilft wenig, wenn anschließend ungeprüfte Dateien über einen anderen Kanal auf die Steuerung gelangen.
Vereinbaren Sie, wie Änderungen freigegeben, beobachtet und dokumentiert werden. Wo Tätigkeiten Menschen oder Anlagen gefährden können, reicht eine nachträgliche Protokollauswertung nicht aus. Das Personal vor Ort muss den Zustand kennen und nötigenfalls eingreifen können. Regeln für Notzugänge sollten denselben Verantwortungsrahmen erhalten; ein dauerhaft offener Ersatzkanal darf nicht unbemerkt zur bequemeren Standardlösung werden.
Updates, Ausnahmen und Wiederherstellung planen
Sicherheitsupdates sollten nach Risiko priorisiert werden. Eine universelle gesetzliche Frist von sieben oder dreißig Tagen für sämtliche IoT-Patches existiert nicht. Ausschlaggebend sind unter anderem aktive Ausnutzung, Erreichbarkeit, Schadenspotenzial und verfügbare Gegenmaßnahmen. IND.2.1 verbindet Wartung mit freigegebenen Updates oder geeigneter Erprobung und sieht für kritische Sicherheitsupdates eine kurzfristige Wartung vor. Das verlangt eine begründete Entscheidung statt bloßes Warten auf den nächsten Jahresstillstand.
Vor einem Eingriff sollten passende Sicherungen, ein Rückfallweg und klare Freigabekriterien bereitstehen. Bei einer Steuerung kann die Wiederherstellung mehr als eine Firmwaredatei benötigen: Programme, Parameter, Zertifikate, Lizenzen und kompatible Ersatzhardware können ebenfalls entscheidend sein. Prüfen Sie anhand eines abgestimmten Szenarios, ob diese Bestandteile zusammen einen sicheren Wiederanlauf ermöglichen. Eine vorhandene Sicherungsdatei beweist das noch nicht.
Kann ein Update zunächst nicht eingespielt werden, dokumentieren Sie den Grund, die befristeten Ersatzmaßnahmen und den nächsten Entscheidungstermin. Beispielsweise können zusätzliche Zugriffsbeschränkungen oder die vorübergehende Abschaltung eines nicht benötigten Dienstes das Risiko reduzieren. Eine Ausnahme muss jedoch erneut bewertet werden, wenn sich die Ausnutzungslage ändert. Fehlender Herstellersupport kann mittelfristig einen Austausch erforderlich machen.
Verbinden Sie diese Entscheidungen mit der Notfall- und Wiederanlaufplanung. Bestimmen Sie, wer eine Anlage sicher isolieren darf, welche Abläufe manuell fortgeführt werden können und wann die Wiederinbetriebnahme fachlich freigegeben wird. IT-Betrieb, Instandhaltung und Prozessverantwortliche benötigen dafür gemeinsame Annahmen. Technische Wiederherstellung und sichere Produktionsaufnahme sind nicht notwendigerweise derselbe Zeitpunkt.
Beschaffung und Support über den Lebenszyklus
Fragen Sie vor der Bestellung nach dem zugesagten Supportzeitraum, sicheren Updatewegen und dem Verfahren für Schwachstellenmeldungen. Klären Sie außerdem, was bei einem Lieferantenwechsel oder der Einstellung eines Cloud-Dienstes geschieht. Eine Anlage mit langer geplanter Nutzung braucht eine nachvollziehbare Perspektive für Sicherheitsaktualisierungen und Ersatzteile. Der günstige Anschaffungspreis bildet diese Betriebsanforderungen nicht vollständig ab.
Für die grundsätzlich ab Dezember 2027 geltenden CRA-Herstelleranforderungen richtet sich der Supportzeitraum nach der erwarteten Nutzungsdauer und den gesetzlichen Kriterien. Er beträgt grundsätzlich mindestens fünf Jahre; wird eine kürzere Nutzung erwartet, entspricht er dieser erwarteten Nutzungsdauer. Bei langlebigen Industrieprodukten kann ein längerer Zeitraum erforderlich sein. Fünf Jahre sind daher weder eine universelle Höchstgrenze noch ein pauschales Versprechen für sämtliche heute vorhandenen Geräte.
Eine Software Bill of Materials unterstützt die Zuordnung eingebauter Komponenten. Der CRA verlangt im einschlägigen Herstellerrahmen eine maschinenlesbare Stückliste, die mindestens die obersten Abhängigkeiten erfasst. Die BSI TR-03183-2, Version 2.1.0, erläutert technische Anforderungen an solche Stücklisten. Eine SBOM sagt allerdings allein nicht aus, ob eine enthaltene Schwachstelle im konkreten Produkt tatsächlich ausnutzbar ist. Dazu müssen Komponentenverwendung, Konfiguration und Herstellerinformationen bewertet werden.
Prüfen Sie Sicherheitszusagen auch bei der Abnahme. Lassen sich voreingestellte Zugänge ändern, unnötige Dienste abschalten und Konfigurationen nachvollziehbar sichern? Ist die zugesagte Wartung mit dem betrieblichen Freigabeprozess vereinbar? Halten Sie offene Punkte mit verantwortlicher Stelle und Entscheidungstermin fest. Eine vorübergehende Inbetriebnahme mit dokumentierten Ersatzmaßnahmen kann eine andere Entscheidung erfordern als die endgültige Abnahme. Vereinbaren Sie diese Unterschiede vorab, damit Zeitdruck am Produktionsstart nicht stillschweigend zu einer dauerhaften Risikoübernahme führt.
Legen Sie außerdem die Aussonderung fest. Entfernen Sie Zugangsdaten, Zertifikate und schützenswerte Konfigurationen, soweit sie nicht für einen gesondert berechtigten Zweck benötigt werden. Entziehen Sie Verbindungen in zentralen Systemen und berücksichtigen Sie mögliche Cloud-Kopien. Der Ausbau eines Sensors beendet nicht automatisch dessen registrierten Zugang oder die Speicherung seiner bisherigen Daten bei einem Dienstleister.
CRA-Meldungen bereits seit September 2026
Artikel 14 CRA betrifft Hersteller, die von einer aktiv ausgenutzten Schwachstelle ihres Produkts oder einem schwerwiegenden Sicherheitsvorfall mit Auswirkungen auf die Produktsicherheit Kenntnis erlangen. Die Meldung erfolgt über die gemeinsame Meldeplattform an den zuständigen koordinierenden CSIRT und ENISA. Eine gewöhnliche, bislang nicht aktiv ausgenutzte Schwachstelle ist nicht allein deshalb eine Pflichtmeldung nach dieser ersten Fallgruppe; der zweite Vorfalltatbestand ist gesondert zu prüfen.
Für beide Fallgruppen ist ohne unangemessene Verzögerung eine frühe Warnung spätestens innerhalb von 24 Stunden nach Kenntniserlangung vorgesehen. Die weitergehende Meldung erfolgt ohne unangemessene Verzögerung spätestens innerhalb von 72 Stunden nach Kenntniserlangung, soweit die erforderlichen Angaben nicht bereits übermittelt wurden. Die Abschlussfristen unterscheiden sich: Bei aktiv ausgenutzten Schwachstellen sind grundsätzlich spätestens 14 Tage nach Verfügbarkeit einer Abhilfe oder Minderung die Abschlussangaben fällig. Bei schwerwiegenden Vorfällen ist grundsätzlich ein Monat nach der weitergehenden Vorfallmeldung maßgeblich.
Daneben verlangt Artikel 14 die Information betroffener Nutzer über die bekannt gewordene aktive Ausnutzung oder den schwerwiegenden Vorfall und erforderlichenfalls über mögliche Schutzmaßnahmen. Planen Sie deshalb einen erreichbaren Produktkontakt und die Zuordnung betroffener Gerätestände. Eine Behördenmeldung allein sorgt noch nicht dafür, dass eine Instandhaltungsabteilung die verfügbare Abhilfe kennt und kontrolliert einspielen kann.
Die Kommission bestätigt die gestaffelten Anwendungstermine. Artikel 69 Absatz 3 erstreckt die Artikel-14-Pflichten auch auf erfasste Produkte, die vor Dezember 2027 in Verkehr gebracht wurden. Hersteller dürfen deshalb ältere Produktreihen nicht allein wegen dieses Datums aus ihrem Meldeprozess entfernen. Betreiber sollten ihren Lieferanten betroffene Versionen, beobachtete Auswirkungen und technische Anhaltspunkte zeitnah mitteilen können.
Personenbezogene Daten im IoT-Betrieb
Gerätekennungen, Standortdaten, Kamerabilder oder Bedienprotokolle können personenbezogen sein, wenn sie Personen zugeordnet werden können. Bestimmen Sie Zweck und Rechtsgrundlage, begrenzen Sie Zugriffe und legen Sie angemessene Löschfristen fest. Ein Sicherheitszweck erlaubt keine unbegrenzte Leistungsüberwachung von Beschäftigten. Der risikobezogene Schutz nach Artikel 32 DSGVO betrifft dabei auch Verfügbarkeit und Wiederherstellbarkeit.
Bei einer Verletzung personenbezogener Daten ist die Meldung an die Datenschutzaufsicht getrennt zu beurteilen: unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, sofern ein Risiko nicht unwahrscheinlich ist; eine spätere Meldung ist zu begründen. Alle Verletzungen des Schutzes personenbezogener Daten müssen dokumentiert werden, auch diejenigen ohne Behördenmeldung. Ein wahrscheinlich hohes Risiko verlangt grundsätzlich zusätzlich die unverzügliche Information Betroffener, vorbehaltlich der Ausnahmen des Artikels 34. Eine CRA-Meldung ersetzt diese Prüfung nicht.
Ein belastbarer IoT-Betrieb verbindet damit Produktinformationen und betriebliche Entscheidungen. Für jede relevante Komponente sollte erkennbar sein, wer Änderungen verantwortet, wie Zugriffe begrenzt werden, welche Risiken noch bestehen und wie ein sicherer Wiederanlauf gelingt. Diese Nachvollziehbarkeit ist im Alltag nützlicher als ein pauschales Versprechen, eine einzelne technische Maßnahme mache die gesamte Anlage rechtskonform.