Was ist IEC 62443? Zonen, Security Level und was NIS2 verlangt

Die Reihe ist nach Rollen gegliedert: Betreiber, Integrator und Hersteller haben jeweils eigene Anforderungen.

Sicherheit ergibt sich hier aus einer Arbeitsteilung und ist keine Eigenschaft eines einzelnen Produkts.

Entsprechend ist auch die Normenreihe geteilt. Die allgemeinen Teile 1-x beschreiben Begriffe und Konzepte. Die Teile 2-x richten sich an Betreiber (etwa 2-1) und an Dienstleister wie Integratoren (etwa 2-4), die Teile 3-x an das System (3-2 Risikobewertung und Zonenschnitt, 3-3 Systemanforderungen und Security Level) und die Teile 4-x an die Komponenten und ihre Hersteller (4-1 sicherer Entwicklungsprozess, 4-2 technische Anforderungen an Komponenten). Bei einer Anforderung aus einer Ausschreibung ist deshalb zuerst zu prüfen, an welche Rolle sie überhaupt gerichtet ist. Ein Betreiber kann vom Lieferanten keine Betreiberpflichten verlangen.

Die neueren Teile der Reihe tragen den Titel Security for industrial automation and control systems; abgekürzt heißt dieser Gegenstand in der Reihe IACS, ausgeschrieben in den deutschen Normfassungen „industrielle Automatisierungssysteme“. Die Abkürzung steht auch in den Teiletiteln: 2-1 nennt die IACS asset owners, 2-4 die IACS service providers, 4-2 die IACS components.

Das ist das praktische Herzstück der Norm.

Eine Zone ist eine Gruppe von Geräten und Systemen mit gleichem Schutzbedarf. Alle Steuerungen einer Fertigungslinie können eine Zone sein. Die Büro-IT ist eine andere. Ein Fernwartungszugang eine dritte.

Ein Conduit ist die kontrollierte Verbindung zwischen zwei Zonen: die bewusst eingerichtete, mit definierten Protokollen, definierten Richtungen und einer Stelle, an der man mitliest. Eine beliebige Leitung zwischen zwei Netzen ist noch kein Conduit.

Der Nutzen liegt im Schnitt. Beim Zerlegen einer Anlage in Zonen muss jede Verbindung gefunden und benannt werden, auch die, die in keiner Dokumentation mehr stehen: das Notebook eines Maschinenherstellers, eine Fernwartung, die sechs Jahre zuvor eingerichtet wurde, ein Datenexport über einen Netzwerkordner, den einmal jemand für eine Auswertung angelegt hat. Diese Funde sind der Ertrag der Übung, und ihretwegen lohnt sich der Zonenschnitt auch ohne angestrebtes Zertifikat. Am Ende steht eine Liste dessen, was mit der Anlage spricht, und sie ist so vollständig, wie die Suche gründlich war.

Die Norm stuft den Schutzbedarf nach der Art des Angreifers, gegen den geschützt werden soll. Gefragt wird also, gegen wen eine Anlage geschützt sein muss, und nicht allgemein, wie sicher sie ist.

Genau genommen ist ein Security Level ein Vektor über sieben Anforderungsgruppen, die Foundational Requirements; „SL 3“ ist die Kurzform.

Das angestrebte (SL-T) und das erreichte Security Level (SL-A) gelten für eine Zone oder einen Conduit, nicht für ein einzelnes Gerät. Für Systeme und Komponenten beschreibt die Norm das mögliche Level (SL-C): die Stufe, die sie richtig eingebunden und konfiguriert erreichen können, gemessen an den Anforderungen, die die Norm für Systeme und für Komponenten festlegt. Die Frage „Welches SL hat Ihr Produkt?“ zielt deshalb nur auf das mögliche Level. Festzulegen ist, welches SL die Zone oder der Conduit braucht, und zu prüfen, was eine Komponente dazu beiträgt.

Diese Dreiteilung wirkt bürokratisch, hat aber einen praktischen Nutzen: Ein Zwischenstand lässt sich dokumentieren, statt dass ein Projekt zwei Jahre lang „noch nicht sicher“ heißt.

NIS2 ist eine EU-Richtlinie, IEC 62443 eine Norm. Die Richtlinie verlangt, dass bestimmte Betreiber Risikomanagement betreiben und Vorfälle melden. Wie das geschieht, legt sie nicht fest, und die Norm ist eine der Antworten darauf. In Deutschland ist die Richtlinie mit dem NIS-2-Umsetzungsgesetz seit dem 6. Dezember 2025 geltendes Recht; die Pflichten stehen im BSI-Gesetz.

Zu diesen Pflichten gehört für besonders wichtige und wichtige Einrichtungen, sich beim BSI zu registrieren, spätestens drei Monate, nachdem sie erstmals oder erneut als solche Einrichtung gelten (§ 33 BSIG). Einen erheblichen Sicherheitsvorfall melden sie in drei Stufen: eine frühe Erstmeldung spätestens 24 Stunden, nachdem sie davon erfahren haben, eine Meldung spätestens nach 72 Stunden und eine Abschlussmeldung spätestens einen Monat nach dieser Meldung; dauert der Vorfall dann noch an, zunächst eine Fortschrittsmeldung (§ 32 BSIG). Die Geschäftsleitung ist verpflichtet, die Maßnahmen zum Risikomanagement umzusetzen und ihre Umsetzung zu überwachen (§ 38 BSIG).

Die praktische Verbindung: Für die Mindestanforderungen aus der NIS2-Umsetzung bietet IEC 62443 einen Rahmen, mit dem sie sich für eine Automatisierungsanlage beschreiben lassen. Umgekehrt macht ein Zertifikat allein niemanden NIS2-konform, weil das Gesetz auch Organisation und Meldewege verlangt.

Wie sich die Mindestanforderungen konkret auf eine Konnektivitätskomponente abbilden lassen, beschreibt ausführlich NIS-2-Anforderungen erfüllen mit dem Kepware OPC UA Server.

Und der Cyber Resilience Act?

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) richtet sich vor allem an Hersteller, nicht an Betreiber. Er verlangt, dass Produkte mit digitalen Elementen sicher entwickelt und dokumentiert werden und dass der Hersteller Schwachstellen während eines festgelegten Unterstützungszeitraums behebt, grundsätzlich mindestens fünf Jahre lang. Diese Pflichten gelten ab dem 11. Dezember 2027.

Früher greift die Meldepflicht: Seit dem 11. September 2026 muss ein Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an seinem Produkt melden, mit einer Frühwarnung binnen 24 Stunden, einer Meldung binnen 72 Stunden und einem Abschlussbericht. Die Meldungen gehen an das zuständige CSIRT und an die ENISA, und die betroffenen Nutzer muss er informieren. Das gilt auch für Produkte, die schon vor diesem Tag in Verkehr gebracht wurden.

Für Betreiber bedeutet das: Ab dem 11. Dezember 2027 muss einiges, was bis dahin nur zugesagt wird, jedem Produkt beiliegen, etwa die Kontaktstelle für Schwachstellen und das Enddatum des Unterstützungszeitraums. Die technische Dokumentation selbst ist für die Marktüberwachungsbehörden bestimmt.

In der Automatisierungspyramide ist Sicherheit keine eigene Ebene. Sie entscheidet sich an den Übergängen: Wo Daten eine Schicht verlassen, liegen die Conduits. Eine Steuerung steht in ihrer Zone. Eine Anbindung zwischen OT und IT verbindet Zonen, und zwar dauerhaft. Sicherheitlich verdient sie deshalb mehr Aufmerksamkeit als die einzelne Steuerung.

Eine Middleware zwischen OT und IT sitzt auf einem solchen Conduit. An ihr wird festgelegt, welche Daten in welche Richtung fließen und welche nicht. Gegenüber vielen direkten Verbindungen gibt es damit eine Stelle zu prüfen statt zwanzig, und diese Stelle kann protokollieren, was sie durchlässt. Zwanzig Einzelverbindungen sind auch dann schwer zu kontrollieren, wenn jede für sich verschlüsselt ist. Erst ein gebündelter Übergang lässt sich vollständig beschreiben.

Eine solche Bündelung beschreibt ein veröffentlichter Anwenderbericht, erschienen im April 2019 im Maschinenmarkt und auf opc-router.de nachzulesen. Bei STIHL kommunizierte damals jede Montagelinie über einen OPC Router mit einem eigenen lokalen SQL-Server; darüber lagen zentrale Datenbanken, die die Linien zusammenfassten. „Diese Architektur erhöht die Sicherheit und beschleunigt die Kommunikation“, sagte Dominik Feil, damals seitens der IT für die Produktion zuständig. „Deshalb haben wir sie vor einigen Jahren zum Standard gemacht.“ Der Stand der Angaben gehört dazu: 16 Installationen in Deutschland, dazu Werke in den USA und China, beides zum Zeitpunkt des Berichts. Beschrieben ist damit eine Schichtung, die aus Betriebsgründen entstanden ist, kein Zonenschnitt nach der Norm. Sie beantwortet aber dieselbe Frage: welche Systeme miteinander sprechen und über welche Stelle.

Mehr zum Plug-in, um dessen Sicherheitseinstellungen es weiter unten geht: OPC-UA-Client-Plug-in. Wie ISA-95 und die Automatisierungspyramide die Ebenen ordnen: Was ist ISA-95? · Was ist IT/OT-Integration?

Eine Anlage kann ein Audit bestehen und trotzdem nicht so geschützt sein, wie die Unterlagen sagen. Mehrere Ursachen liegen in der Bauweise der Systeme selbst: darin, wann Identität geprüft wird, wo eine Verschlüsselung endet und wie eine Projektierung transportiert wird.

Die rechte Spalte der Tabelle und die Absätze zum OPC Router darunter nennen Fähigkeiten und Einstellorte aus dem Handbuch des OPC Router zum Stand dieses Artikels und sind keine Konformitätsaussage. Ob eine Zone oder ein Conduit das angestrebte Security Level erreicht, hängt an allen Maßnahmen darin, nicht an einer einzelnen Komponente.

Ein Widerruf erreicht die laufende Verbindung nicht

Ein Zertifikat wird zentral zurückgezogen oder einem Benutzer eine Rolle entzogen. Die Sperre ist gesetzt, im Verwaltungswerkzeug sieht alles richtig aus, und die bestehende Verbindung arbeitet weiter wie zuvor. Bei einer Maschinenanbindung kann das bis zum nächsten Neustart so bleiben.

Die Ursache liegt in der Auslegung: Identität wird beim Sitzungsaufbau geprüft, nicht bei jeder Nachricht. Eine Prüfung je Telegramm wäre für eine Anbindung, die im Sekundentakt Werte trägt, nicht tragbar, und eine Sperrlistenabfrage bei jedem Wert würde die Zelle vom Netzwerk abhängig machen. Eine Sperrliste wirkt deshalb erst beim nächsten Handshake, und den löst bei einer stabilen Verbindung unter Umständen erst ein Neustart aus. Der Test dafür ist einfach: ein Recht entziehen, ohne den Dienst neu zu starten, und danach prüfen, ob die Verbindung noch Daten liefert. Das Ergebnis ist die tatsächliche Wirkungsfrist.

Die Frist lässt sich verkürzen und beziffern, aber nicht abschaffen. Beim Betreiber liegt, sie festzulegen, statt sie offenzulassen. Ein zyklischer Abgleich mit einer zentralen Zertifikatsverwaltung hat ein Intervall, und dieses Intervall sagt, wie lange ein Widerruf braucht, bis er im System ankommt. Beendet der Abgleich die laufende Verbindung nicht, macht ihn für sie erst ein Neustart wirksam; ohne Neustart bleibt die Frist offen. Auf der Bedienseite gehören die Sitzungszeiten gesetzt, wo es sie gibt; sind sie ab Werk abgeschaltet, gelten sie erst, wenn jemand sie setzt. Bei Anmeldung über eine Windows-Gruppe wird das Recht dort entzogen, wo es herkommt. Den Test aus dem vorigen Absatz führt der Betreiber selbst durch.

Der OPC Router kann Zertifikate, Vertrauenslisten und Sperrlisten zyklisch von einem Global Discovery Server beziehen und im laufenden Betrieb abgleichen. Ab Werk passt sich das Abrufintervall dem GDS an: Es beginnt bei 5 Minuten und folgt dann dem Aktualisierungsintervall, das der GDS für seine Vertrauenslisten meldet; meldet er keines, bleibt es bei 5 Minuten. Ist die automatische Anpassung ausgeschaltet, gilt ein festes Intervall zwischen 1 Minute und 24 Stunden. Eingestellt wird das unter Zertifikate > Zertifikate über OPC UA GDS im Bereich „Automatischer Abruf“. Die Funktion setzt eine Enterprise-Lizenz je Installation sowie einen solchen Server im Unternehmen voraus. Damit wird die Frist, bis der neue Stand im OPC Router vorliegt, bezifferbar. Die Grenze nennt das Handbuch im selben Zusammenhang: Der Abgleich wirkt nicht auf bereits laufende Plug-ins. Bestehende Verbindungen arbeiten mit dem alten Stand weiter, bis das Plug-in das nächste Mal startet, und wann das geschieht, hängt am Betrieb des Plug-ins.

Auch auf der Bedienseite nennt das Handbuch eine Frist. Eine Rollenänderung greift erst, wenn das gespeicherte Login-Token erneuert wird, und nach dem Löschen eines Nutzers kann es bis zu 30 Minuten dauern, bis er auf allen Geräten abgemeldet ist. Für eine kürzere Frist gibt es ein Inaktivitäts-Timeout und eine maximale Sitzungsdauer; beide sind ab Werk abgeschaltet und werden global über Umgebungsvariablen gesetzt, je Benutzer feinjustierbar. Das Recht, überhaupt etwas zu entziehen, regelt eine Rechtematrix mit drei Rollen und 22 Berechtigungen, in der das Verwalten von Zertifikaten, Benutzern und Lizenz ausschließlich der Admin-Rolle vorbehalten ist. Vergeben werden die Rollen vom Betreiber, und bei einer Migration aus einer älteren Version erhalten vorhandene Nutzer zunächst die Rolle Admin.

Der Zonenübergang kann eine Prüfung aushebeln, die der Aufbau herstellen sollte

Ein Übergang kann über einen Reverse Proxy in einer entmilitarisierten Zone gebaut werden, statt die Verbindung direkt durch die Zonengrenze zu führen. Je nach Protokoll und Proxy kommt die Verbindung danach nur zustande, wenn eine Prüfung ausbleibt, die gerade die Identität der Gegenstelle sichern sollte.

Ein Reverse Proxy, der die Transportverschlüsselung beendet, beendet damit auch die Transportidentität des Clients. Der Server dahinter sieht entweder das Zertifikat des Proxys oder gar keines. Eine Prüfung, die Transportzertifikat und Anwendungszertifikat gegeneinander abgleicht, kann die beiden dann nicht mehr sicher zuordnen. Für den OPC-UA-Server des OPC Router ist das dokumentiert: Ist er über HTTPS hinter einem Reverse Proxy erreichbar, muss die Option „Mutual TLS aktivieren“ aus sein, weil die Zuordnung dort „nicht immer eindeutig“ ist; die Verbindung kann sonst trotz korrekter Konfiguration fehlschlagen. Im Audit steht dann eine Prüfung, die hinter dem Proxy nicht aktiv sein darf und deshalb begründet werden muss. Die Anmeldung mit Benutzername und Passwort bleibt dabei Pflicht, anonyme Verbindungen sind über HTTPS nicht zulässig.

Zonenschnitt, Lage des Conduits und Einstufung des Segments hinter dem Proxy bleiben Betreiberentscheidungen. Auch die Firewall-Regeln legt der Betreiber an; das Windows-Setup richtet keine Ausnahmen ein und weist während der Installation nur darauf hin. Die verbreitete Empfehlung, die Transportverschlüsselung im Reverse Proxy zu beenden statt in der Anwendung, gibt auch das Handbuch, aus Gründen der Netzwerkleistung und „insbesondere dann, wenn der Netzwerkverkehr zwischen dem Reverse-Proxy und dem OPC Router als sicher angesehen werden kann“. Ob das Segment dahinter so gelten kann, prüft der Betreiber. Lässt sich das nicht prüfen, ist zu entscheiden, ob die Transportverschlüsselung vor dem OPC Router enden darf.

Für den Datenweg zur Anlage braucht der Übergang keinen Proxy, solange der OPC Router die Verbindung als Client selbst aufbaut, ausgehend auf den Port des Zielsystems. Ein Reverse Proxy kommt im Datenpfad erst dort in Betracht, wo ein externer Client den OPC Router selbst erreichen soll, etwa beim REST-Server, beim integrierten OPC-UA-Server, beim IDoc-Trigger für SAP und beim Web Management. Welche Ports eingehend freizugeben sind, hängt deshalb an den projektierten Plug-ins. Die vollständige Liste steht in einem dokumentierten Portkatalog mit Standardwert, Zweck und Kontext, dazu eine Liste der festen ausgehenden Internet-Ziele, die unverändert an die Netzwerkabteilung gehen kann, und eine Liste der Ports, die der OPC Router nicht verwendet. Für die HTTPS-Ziele darunter, etwa Lizenzierung, pronubes und Solution Gallery, kann der OPC Router einen ausgehenden Proxy verwenden, der je Dienst über HTTPS_PROXY gesetzt wird. Die Grenzen nennt das Handbuch im selben Abschnitt. Ein Proxy mit Anmeldung wird nicht unterstützt. Unter Windows deckt HTTPS_PROXY die Sperrlisten-Abfragen auf Port 80 nicht ab, die Windows selbst über die systemweite WinHTTP-Einstellung stellt. Und HTTPS_PROXY wirkt prozessweit: Interne Ziele wie der Redundanzpartner oder die Gegenstellen der HTTP- und REST-Plug-ins müssen in NO_PROXY stehen, sonst laufen auch diese Verbindungen über den Proxy. Bei TLS-Inspection nennt das Handbuch zwei Wege, und keiner davon schaltet die Zertifikatsprüfung im OPC Router ab: entweder eine Ausnahme von der Inspection für die Internet-Ziele, oder das Zertifikat der Inspection-Zertifizierungsstelle im Zertifikatsspeicher des lokalen Computers, „nicht nur in dem des angemeldeten Benutzers“. Zur TLS-Inspection im Datenpfad selbst sagt das Handbuch nichts.

Das Zertifikat lautet auf einen Namen, die Anlage spricht IP

Eine verschlüsselte Verbindung wird eingerichtet und abgelehnt, weil im Zertifikat nur der Rechnername steht, der Server aber über seine IP-Adresse angesprochen wird.

Ein Zertifikat gilt nur für die Namen und Adressen, die darin eingetragen sind. Eine feste IP-Adresse kann darin stehen, und OPC UA sieht das für Server ausdrücklich vor. Steht im Zertifikat aber nur der Rechnername, passt es nicht mehr, sobald der Server über seine IP-Adresse angesprochen wird. Die Automatisierung adressiert aus guten Gründen über feste IP-Adressen: Ein Zellennetz hat nicht unbedingt eine Namensauflösung, die Adresse steht im Schaltplan, und eine Anlage soll nicht von einem Dienst abhängen, den die IT betreibt. Beide Praktiken sind für sich richtig. Sie passen nur zusammen, wenn das Zertifikat die Adresse trägt, unter der der Server angesprochen wird.

Wird die Prüfung ganz abgeschaltet, läuft die Anlage danach in einem Zustand, in dem auch ein abgelaufenes oder ausgetauschtes Zertifikat nicht mehr auffällt, bis jemand den Schalter zurücksetzt, denn es gibt keine Meldung mehr. Sichtbar wird das in der Konfiguration, an Verbindungen, die einmal eingerichtet und nie wieder angefasst wurden.

Die Ursache liegt im Zertifikat, und das stellt keine Middleware aus. Es gibt drei Wege, und alle drei gehören dem Betreiber: ein Zertifikat beschaffen, das genau die Identität trägt, unter der tatsächlich adressiert wird, also den Rechnernamen oder die feste IP-Adresse, eingetragen als Subject Alternative Name; eine Namensauflösung im Zellennetz bereitstellen; oder bewusst und dokumentiert entscheiden, welche Prüfung gelockert wird. Der dritte Weg ist vertretbar, solange er dokumentiert ist. Dazu gehört die Nebenwirkung, die das Handbuch ausdrücklich nennt: Bei abgeschalteter Zertifikatsvalidierung werden „auch falsche Servernamen oder abgelaufene Zertifikate“ akzeptiert.

Der OPC-UA-Client des OPC Router trennt die Prüfung in mehrere Schalter. Dokumentiert sind eine Zertifikatsvalidierung, die die Gültigkeit des Serverzertifikats prüft (Voreinstellung ein), eine Prüfung der Application URI des Servers gegen die konfigurierte (Voreinstellung ein), und die Wahl des Vertrauensspeichers. Die Einstellung „Alle (unsicher)“ weitet den Vertrauenskreis und lässt die Gültigkeitsprüfung stehen; im Handbuch heißt es: „Das Server-Zertifikat muss dennoch gültig sein.“ Für die Adresse gilt laut Handbuch: Der Endpunkt muss so angesprochen werden, wie er im Zertifikat hinterlegt ist. Einzurichten ist deshalb ein Serverzertifikat, das auf den Namen oder die feste IP-Adresse ausgestellt ist, über die der OPC Router verbindet, und im Plug-in genau dieser Endpunkt. Die Schalter stehen im OPC-UA-Client-Plug-in im Reiter „Sicherheit“, der Endpunkt im Reiter „Verbindung“.

Der Zustand ist außerdem nachlesbar. Die Zertifikatsverwaltung zeigt je Zertifikat Antragsteller, DNS-Namen, Ausstellungs- und Ablaufdatum, Seriennummer, Fingerprint und Quelle. Weil die Projektierung als YAML in einem intern geführten Git liegt, das festhält, wer wann was geändert hat, ist ein abgeschalteter Haken beim Vergleich zweier Stände sichtbar. Für ein Audit ist damit neben dem Zustand auch der Zeitpunkt der Änderung belegbar.

Die höchste Sicherheitsstufe ist die höchste, die die Gegenstelle anbietet

Im Projekt wird die Einstellung gesetzt, die die stärkste verfügbare Sicherheit verlangt. Die Verbindung kommt zustande, in der Unterlage steht „verschlüsselt“, die Sache gilt als erledigt. Was tatsächlich ausgehandelt wurde, steht damit nirgends.

Ein Client kann nur auswählen, was der Server anbietet. Bietet eine ältere Steuerung nur einen ungesicherten Endpunkt an, ist das Beste vom Angebotenen eben dieser. Derselbe Gedanke steht hinter dem Security Level einer Zone: Das Niveau entsteht am schwächeren Ende. Ablesen lässt sich das Ergebnis deshalb nur am ausgehandelten Endpunkt; die Konfiguration des Clients zeigt die Absicht.

Beim Betreiber liegt, nachzusehen, welche Endpunkte die Gegenstelle überhaupt anbietet, bevor die Einstellung als Nachweis in eine Unterlage wandert. Dazu gehört die dokumentierte Bedingung für den Verbindungstest: Er gelingt nur, wenn auf beiden Seiten die gleiche Sicherheitsstufe eingestellt ist und die auszutauschenden Client- und Serverzertifikate gegenseitig als vertrauenswürdig eingestuft sind. Das Einstufen auf der Serverseite kann keine Middleware übernehmen.

Der OPC-UA-Client des OPC Router hat den Schalter „Höchste Sicherheitsstufe verwenden“. Laut Handbuch erzwingt er beim Verbindungsaufbau die sicherste vom Server angebotene Sicherheitskonfiguration und lehnt schwächere Endpunkte ab, sofern eine sicherere Alternative verfügbar ist. Solange er aktiv ist, ist das Feld für den Sicherheitsmodus gesperrt. Was dabei herauskommt, hängt weiterhin an der Gegenstelle. Welche Voreinstellung dieser Schalter hat, steht im Handbuch nicht: Bei der Zertifikatsvalidierung und bei der Prüfung der Application URI ist sie ausdrücklich vermerkt, bei diesem Schalter nicht. Welche Einstellung gilt, zeigt deshalb nur die eigene Installation.

Die Anlage ist sauber, die Exportdatei nicht

Die Zugangsdaten sind ordentlich abgelegt, die Zonen sind geschnitten, der Übergang ist beschrieben. Dann wird die Projektierung exportiert: für eine Sicherung, für den Support, für eine zweite Anlage. Die Datei, die dabei entsteht, kommt in keinem Netzplan und in keiner Zonenbetrachtung vor.

Eine Projektierung muss transportierbar sein, sonst lässt sie sich weder sichern noch duplizieren. Transportierbar heißt, dass alles Nötige in einer Datei steckt. Ein Geheimnis, das mitmuss, verlässt damit den Schutz, den die Installation ihm gegeben hat. Das ist die Kehrseite der Übertragbarkeit, und sie gilt für jedes System, dessen Export Geheimnisse mitnimmt. Bemerkbar wird das erst, wenn etwas passiert: Der Fund kommt später, aus einer Dateiablage oder einem Ticketanhang.

Beim Betreiber liegt, beim Export eine Passphrase zu vergeben, sobald die Datei den Rechner verlässt, weitergegeben oder abgelegt wird. Projekte exportieren darf laut Rechtematrix auch die Rolle Editor, und die Passphrase vergibt, wer gerade exportiert. Danach ist nachzusehen, wo die Exporte der letzten Jahre liegen. Beim Aufräumen ist Vorsicht nötig: Der OPC Router prüft nicht, ob ein Secret noch verwendet wird, und ein gelöschtes, aber noch referenziertes Secret führt zu Laufzeitfehlern.

Im OPC Router nehmen die Passwortfelder der Konfigurationsdialoge keinen Klartext entgegen, sondern verweisen auf ein Secret; in der Konfiguration steht nur der Schlüssel, nicht der Wert. Es gibt zwei Speicher. Der eine legt die Werte verschlüsselt und getrennt von der übrigen Projektierung ab, der andere liest sie aus den Umgebungsvariablen des Systems oder Containers und ist immer schreibgeschützt, sodass der Wert gar nicht erst in die Projektierung gerät. Zwei Nebenwirkungen zählen sicherheitlich: Secret-Werte sind nie Teil eines Projekt-Versionsstands, versioniert wird nur der Schlüssel, ein Rollback ändert also kein Passwort. Und aus dem Diagnosepaket für eine Supportanfrage wird die Datei mit den internen Secrets entfernt. Die Ausnahme nennt das Handbuch selbst: Ohne Passphrase stehen die Werte in der Exportdatei im Klartext. Verwaltet wird all das unter Menü > Secrets.

Diese Fragen lassen sich in jeder Ausschreibung stellen und kosten nur die Zeit, sie zu stellen:

1. Wie werden Zugangsdaten abgelegt? Liegen Passwörter im Klartext in einer Konfigurationsdatei, oder verweist die Konfiguration auf einen geschützten Speicher?
2. Welche Rollen gibt es, und was dürfen sie? Eine Software mit genau einem Administrator-Konto ist in einer Zone mit Schutzbedarf schwer zu rechtfertigen.
3. Welche Ports werden geöffnet, wozu, und lassen sie sich einschränken? Eine vollständige Portliste sollte der Hersteller liefern können, ohne nachzusehen.
4. Wie werden Zertifikate ausgerollt und erneuert? Manuell auf jeder Maschine oder zentral verwaltet. Bei vielen Anlagen entscheidet das darüber, ob Verschlüsselung im Betrieb durchgehalten wird.
5. Wie schnell wirkt ein Entzug von Rechten? Sofort oder erst nach Ablauf einer Sitzung. Beides ist vertretbar, aber es muss bekannt sein.
6. Wie werden Schwachstellen gemeldet, und in welcher Frist? Seit dem 11. September 2026 ist das keine Kulanzfrage mehr: Der Cyber Resilience Act schreibt Herstellern Meldefristen gegenüber den Behörden vor und verpflichtet sie, betroffene Nutzer zu informieren.

Aufschlussreich ist neben dem Inhalt, ob der Hersteller die Antworten vorliegen hat. Die Fragen taugen deshalb schon als Vorauswahl, bevor eine Anlage ausgeschrieben wird.

Für den OPC Router stehen die Antworten auf die Fragen 1 bis 5 weiter oben, bei den Problemen: Zugangsdaten und Export, Rollen und Rechtematrix, der Portkatalog, die Zertifikate über einen Global Discovery Server, die Wirkungsfrist eines Rechteentzugs. Jede steht dort mit ihrer Grenze und bezieht sich auf das Handbuch zum Stand dieses Artikels, nicht auf frühere Versionen des OPC Router. Die sechste, die Meldefrist für Schwachstellen, ist keine Produkteigenschaft. Für aktiv ausgenutzte Schwachstellen setzt der Cyber Resilience Act seit dem 11. September 2026 die Fristen gegenüber den Behörden. Was ein Hersteller darüber hinaus zusagt, gehört in seine Antwort auf die Frage und nicht in einen Grundlagenartikel.

Stand: 22. September 2026. Aussagen zum OPC Router beziehen sich auf seine Dokumentation zu diesem Stand.