Im bisherigen Verlauf dieser Serie haben wir zwei Grundlagen geklärt.
Erstens: Der Cyber Resilience Act schafft verbindliche Sicherheitsanforderungen.
Zweitens: Die IEC 62443 liefert den technischen Rahmen für Architektur und Umsetzung.
Nun folgt die entscheidende Frage:. Wann wird eine industrielle Anlage regulatorisch zu einem Produkt im Sinne des Cyber Resilience Act und welche konkreten Pflichten entstehen daraus für Betreiber? Diese Frage ist komplexer, als viele annehmen.
1 Der regulatorische Perspektivwechsel
Der Cyber Resilience Act betrachtet nicht nur klassische Softwareprodukte. Er erfasst Produkte mit digitalen Elementen. Das umfasst auch industrielle Steuerungssysteme, sofern sie digitale Komponenten enthalten, mit Netzwerken verbunden sind, Updates erhalten können oder sicherheitsrelevante Funktionen ausführen. Damit wird eine Anlage nicht nur als technische Infrastruktur betrachtet, sondern als reguliertes Produkt. Das bedeutet konkret:
Sicherheitsanforderungen gelten systematisch
Dokumentationspflichten entstehen
Haftungsfragen verschieben sich
Updatefähigkeit wird zur Pflicht
Eine Anlage ist damit nicht mehr nur ein Projekt, sondern ein digitales Produkt mit Lebenszyklusverantwortung.
2 Die Verbindung zur CE Kennzeichnung
Viele industrielle Anlagen unterliegen bereits europäischen Produktvorschriften und tragen eine CE Kennzeichnung. Mit dem Cyber Resilience Act wird Cybersicherheit faktisch Bestandteil der Konformitätsbewertung. Das bedeutet:
Sicherheitsfunktionen müssen dokumentiert werden
Risikobewertungen müssen Cyberaspekte enthalten
Technische Dokumentation muss Sicherheitsarchitektur beschreiben
Update und Schwachstellenprozesse müssen nachvollziehbar sein
Cybersicherheit wird damit Teil der Produktkonformität und nicht mehr nur eine betriebliche Zusatzmaßnahme.
3 Die Rolle der technischen Dokumentation
Ein zentrales Element des regulatorischen Rahmens ist die technische Dokumentation. Sie muss mindestens enthalten:
Architekturübersicht
Zonenkonzept
Sicherheitsanforderungen
Verschlüsselungsstrategie
Remote Access Konzept
Updateverfahren
Vulnerability Management Prozess
Incident Meldeprozess
Fehlt diese Dokumentation, entsteht ein regulatorisches Risiko unabhängig von der tatsächlichen technischen Qualität des Systems. Sicherheit ohne Dokumentation ist rechtlich nicht existent.
4 SBOM und Abhängigkeitstransparenz
Ein weiterer zentraler Punkt ist die Transparenz über eingesetzte Softwarebestandteile. Software Bill of Materials, kurz SBOM, wird zunehmend zur Erwartungshaltung im Markt. Für industrielle Systeme bedeutet das:
Verwendete Bibliotheken müssen bekannt sein
Firmware Komponenten müssen nachvollziehbar sein
Drittanbieter Software muss identifiziert sein
Versionsstände müssen dokumentiert sein
Ohne Abhängigkeitsübersicht ist kein strukturiertes Vulnerability Management möglich.
5 Haftung und Betreiberverantwortung
Ein häufiger Irrtum ist die Annahme, regulatorische Pflichten betreffen ausschließlich Hersteller. In der Praxis tragen Betreiber Mitverantwortung. Sie müssen sicherstellen:
Dass nur konforme Systeme eingesetzt werden
Dass Updates strukturiert bewertet werden
Dass Sicherheitsmechanismen nicht eigenständig außer Kraft gesetzt werden
Dass Remote Zugänge kontrolliert sind
Ein Betreiber, der eine unsichere Konfiguration akzeptiert oder Sicherheitsmechanismen deaktiviert, bewegt sich in einer haftungsrelevanten Zone.
6 Wann wird es kritisch
Eine industrielle Anlage wird regulatorisch besonders relevant, wenn Remote Access implementiert ist, Cloud Anbindungen bestehen, WLAN eingesetzt wird, externe Dienstleister Zugriff erhalten oder Software regelmäßig aktualisiert wird. In diesen Fällen entsteht eine klare digitale Angriffsfläche. Das bedeutet:
Architektur und Betriebsprozesse müssen belastbar sein
Sicherheitslevel müssen definiert sein
Monitoring muss vorhanden sein
Incident Prozesse müssen vorbereitet sein
7 Konkrete Handlungsfelder für Betreiber
Betreiber sollten prüfen:
Ist die Anlage als Produkt im regulatorischen Sinn einzuordnen
Existiert eine vollständige technische Dokumentation
Ist die Updatefähigkeit über den geplanten Lebenszyklus sichergestellt
Sind Softwareabhängigkeiten bekannt
Ist die Sicherheitsarchitektur nachvollziehbar dokumentiert
Sind Verantwortlichkeiten klar geregelt
Ohne diese Grundlagen entsteht regulatorische Unsicherheit.
8 Strategische Konsequenz
Der Cyber Resilience Act verschiebt die Verantwortung von reaktiver Sicherheit hin zu strukturierter Sicherheitsarchitektur und Lebenszyklusverantwortung. Eine industrielle Anlage ist nicht mehr nur eine technische Installation. Sie ist ein digitales Produkt mit Betriebspflichten.
Im nächsten Artikel gehen wir tiefer in die technische Umsetzung und zeigen, wie eine Risikoanalyse nach IEC 62443 praktisch durchgeführt wird und wie daraus konkrete Architekturentscheidungen entstehen.
Weitere Artikel
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 2 – IEC 62443 richtig verstanden und wie 3-3, 4-1, und 4-2 zusammen eine belastbare Sicherheitsarchitektur bilden
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 1 – Cyber Resilience Act und was industrielle Betreiber jetzt konkret umsetzen müssen
Artikelserie – Digitale ID – Artikel 17 – Geld als Machtarchitektur
Artikelserie Digitale ID – Artikel 5 – Der verlorene Schatten