Sicherer Fernzugriff auf SPS und SCADA: Architektur, VPN und NIS2-Konformität

· 16 Minuten Lesezeit
16 min read
Eziwan-Team
IoT-Infrastruktur

Im Jahr 2025 können mehr als 78 % der Störungen an Industrie-SPSen aus der Ferne diagnostiziert und behoben werden – ohne dass ein Techniker vor Ort sein muss. Dennoch schicken die meisten Industrieunternehmen immer noch einen Techniker vor Ort, um Eingriffe von 15 bis 30 Minuten Dauer durchzuführen, die jeweils 800 bis 2.000 € kosten. Das größte Hindernis: die (berechtigte) Angst, das OT-Netzwerk dem Internet auszusetzen.

Dieser Leitfaden beantwortet die Frage, die sich alle Verantwortlichen für Automatisierung und industrielle IT stellen: Wie kann man den Fernzugriff auf seine Steuerungen ermöglichen, ohne eine Sicherheitslücke im OT-Netzwerk zu schaffen? Technische Architektur, VPN-Protokolle, Zugriffskontrolle, Audit-Trail, NIS2-Konformität – alles wird behandelt.

Warum sich der Fernzugriff in der Betriebstechnik vom Fernzugriff in der IT unterscheidet

Die besonderen Anforderungen an OT-Netzwerke

Die Anforderungen an Operational-Technology-Netzwerke (OT) unterscheiden sich grundlegend von denen der klassischen IT-Welt. Wer diese ignoriert, muss entweder auf den Fernzugriff verzichten oder riskiert eine erhebliche Sicherheitslücke.

Ältere Protokolle, die von Grund auf unsicher sind:

  • Modbus TCP/RTU: keine Authentifizierung, keine Verschlüsselung – 1979 für geschlossene Netzwerke entwickelt
  • S7comm (Siemens): proprietäres Protokoll, Port 102, anfällig für Man-in-the-Middle-Angriffe ohne externe Verschlüsselungsebene
  • EtherNet/IP (Rockwell): Port 44818, CIP-Protokoll – keine native Sicherheit bei älteren Versionen
  • PROFINET: Echtzeitprotokoll von Siemens/Ethernet, latenzkritisch, nicht kompatibel mit Standard-Anwendungsproxys

Echtzeitanforderungen und Verfügbarkeit: Eine SPS, die eine Produktionslinie steuert, kann nicht einfach neu gestartet werden, um einen Sicherheitspatch zu installieren. Wartungsfenster werden im Voraus geplant, oft monatlich oder jährlich. Jede ungeplante Unterbrechung – selbst wenn sie nur 30 Sekunden dauert – kann schwerwiegende physische oder finanzielle Folgen haben.

Veraltete Anlagen in der Produktion: In der Produktion sind häufig Siemens S5-, Schneider Premium- oder Allen-Bradley SLC 500-Steuerungen im Einsatz, die bereits 15 bis 25 Jahre alt sind. Keine integrierte Verschlüsselung, keine moderne Authentifizierung – nur RS485 und Modbus.

Ganz andere Folgen eines Einbruchs: Ein Einbruch in das IT-Netzwerk gefährdet Daten. Ein Einbruch in das OT-Netzwerk kann eine Produktionslinie zum Stillstand bringen, einen Sicherheitsfehler auslösen oder im schlimmsten Fall zu einem physischen Zwischenfall führen (wie beim Vorfall im ukrainischen Stromnetz im Jahr 2015 oder beim Triton/TRISIS-Angriff von 2017 auf ein instrumentiertes Sicherheitssystem).

Die gefährlichste Falle: direkte Portweiterleitung

Die Versuchung ist groß: Port 102 (S7) oder Port 80 (Web-HMI) am Router des Standorts zu öffnen und von überall aus auf die SPS zuzugreifen. Schnell, ganz ohne Konfiguration – und katastrophal.

Im Jahr 2024 indexiert die Suchmaschine Shodan kontinuierlich mehr als 45.000 industrielle Steuerungen, die in Frankreich direkt im Internet zugänglich sind. Eine über den S7-Comm-Port zugängliche Siemens-SPS wird von den automatischen Scannern innerhalb von weniger als 48 Stunden erkannt. Zu den dokumentierten Folgen gehören:

  • Manipulation von SPS-Programmen durch böswillige Akteure
  • Absichtliche Produktionsausfälle (OT-Ransomware)
  • Abfluss von Know-how (Programme, Rezepturen, Produktionsparameter)
  • Sabotage von instrumentierten Sicherheitssystemen (SIL)
Ein OT-Port darf niemals direkt mit dem Internet verbunden sein

Keine SPS (Siemens, Schneider, Rockwell, ABB, Omron) darf direkt über das Internet erreichbar sein. Auch nicht, wenn sie durch ein Passwort geschützt ist, und auch nicht über einen nicht standardmäßigen Port. Die einzige sichere Architektur basiert auf einem VPN oder einem System vom Typ „Zero Trust Network Access“.


Die drei Architekturen für sicheren Fernzugriff

Architektur 1: Site-to-Office-VPN – der Industriestandard

Dies ist die am weitesten verbreitete Architektur und für 90 % der industriellen Anwendungsfälle am besten geeignet. Ein industrieller Router vor Ort unterhält ständig einen verschlüsselten ausgehenden VPN-Tunnel zu einem Cloud-Hub oder Ihrem Rechenzentrum. Der Techniker stellt über einen VPN-Client auf seinem Rechner eine Verbindung her.

Wichtigste Merkmale:

  • Keine eingehenden Ports im Standortnetzwerk – die Standort-Firewall blockiert jeglichen eingehenden Datenverkehr
  • Der VPN-Tunnel wird von innen nach außen aufgebaut (ausgehende Verbindung vom Gateway)
  • Alle OT-Protokolle werden über den verschlüsselten Tunnel übertragen: S7comm, Modbus TCP, EtherNet/IP, PROFINET (Layer 2)
  • Der Techniker sieht die SPS so, als befände sie sich lokal im LAN des Standorts
  • TIA Portal, Unity Pro, Studio 5000, FactoryTalk – ohne Anpassungen kompatibel

Einrichtung: 20 Minuten auf der Standortseite (Gateway-Installation), 5 Minuten auf der Technikerseite (OpenVPN- oder WireGuard-Client).

Architektur 2: Jump-Server / OT-Bastion

In Umgebungen mit strengen Sicherheitsrichtlinien (Chemie-, Nuklear- und Wasserwirtschaft) oder mit mehreren beteiligten Teams (Dienstleister, Systemintegratoren, Maschinenbauer) sorgt ein Bastion-Server für eine verstärkte Isolierung.

Die Bastion leitet ausschließlich ausdrücklich genehmigte Verbindungen weiter. Sie protokolliert den gesamten Datenverkehr, lehnt standardmäßig alles ab und gewährt nur den Geräten Zugriff, die in der für jeden Techniker festgelegten Whitelist aufgeführt sind.

Empfohlen für: OIV, EE (NIS2), nach ISO 27001 zertifizierte Standorte, risikobehaftete Branchen (Chemie, Pharmazie, Energie).

Architektur 3: Zero Trust Network Access (ZTNA)

Für große Flotten (50+ Standorte) mit mehreren Teams und externen Partnern (OEM-Maschinenhersteller, Systemintegratoren, Subunternehmer) ist das Zero-Trust-Modell unumgänglich. Das Prinzip lautet: Niemals vertrauen, immer überprüfen.

Jeder Zugriff wird anhand folgender Kriterien bewertet:

  • Identität: Wer meldet sich an? (MFA obligatorisch, LDAP/SSO-kompatibel)
  • Kontext: Von welchem Gerät aus? Seit wann? Von welchem Standort aus?
  • Mindestberechtigung: Zugriff ausschließlich auf die für den Auftrag erforderlichen Ressourcen, nicht mehr
  • Nachvollziehbarkeit: Jeder Befehl, jeder Datenfluss wird protokolliert und kann nachvollzogen werden
KriteriumKlassisches VPNBastionZTNA
Komplexität der BereitstellungGeringMittelHoch
Granularität der ZugriffsrechteNetzwerk/VLANGerätVariabel/Sitzung
Audit und NachverfolgbarkeitVPN-VerbindungenSSH-BefehleAlle Aktionen
Skalierbarkeit (100+ Standorte)MittelGutHervorragend
NIS2-OIV-konformJa (bei korrekter Konfiguration)JaJa (nativ)
InfrastrukturkostenGeringMittelHoch

Praktischer Leitfaden: Fernzugriff auf eine Siemens S7-1200-SPS

Voraussetzungen

  • Eziwan-Gateway im Standortnetzwerk installiert (Subnetz 192.168.1.0/24)
  • S7-1200-Steuerung mit der Adresse 192.168.1.10 (lokal über das TIA-Portal bestätigen)
  • Auf der Eziwan-Plattform erstelltes Technikerkonto
  • TIA-Portal v17 oder höher auf dem PC des Technikers installiert
  • OpenVPN- oder WireGuard-Client installiert

Schritt 1 – Überprüfen der Netzwerktopologie des Standorts

Über das Eziwan-Dashboard → Website → Netzwerkkonfiguration:

# Über die CLI-Schnittstelle des Gateways (lokales SSH oder Konsole)
eziwan route list
# Erwartetes Ergebnis:
# 192.168.1.0/24 via eth0 (LAN) → announced via VPN tunnel
# 0.0.0.0/0 via lte0 (WAN) → default route LTE

eziwan connectivity test 192.168.1.10
# Erwartetes Ergebnis:
# Ping 192.168.1.10 OK (4ms)
# Port 102 (S7) : OPEN

Schritt 2 – Einen Technikerzugang auf der Plattform erstellen

Eziwan-Dashboard → Zugriff → Techniker → Neuer Zugriff:

  1. E-Mail-Adresse des Technikers eingeben (automatische Einladung)
  2. Zugelassene Standorte auswählen: Site-Lyon-Usine-A
  3. Zeitfenster festlegen: Lun-Ven 7h-19h
  4. Zugängliche Geräte auswählen (optional): nur 192.168.1.10
  5. Ablaufdatum des Zugriffs (empfohlen für Dienstleister)
  6. VPN-Profil erstellen – OpenVPN .ovpn oder WireGuard .conf

Der Techniker erhält eine E-Mail mit seiner verschlüsselten Konfigurationsdatei und den Installationsanweisungen.

Schritt 3 – Installation des VPN-Clients (Techniker)

Windows (empfohlen: OpenVPN GUI):

# Installation via winget
winget install OpenVPN.OpenVPN

# Profil importieren (per Drag & Drop in den OpenVPN-Benachrichtigungsbereich ziehen)
# oder über die Befehlszeile:
openvpn --config "C:\eziwan\site-lyon.ovpn" --daemon

Linux:

sudo apt install openvpn network-manager-openvpn-gnome
# Profil über den NetworkManager importieren
sudo nmcli connection import type openvpn file /home/user/site-lyon.ovpn
sudo nmcli connection up site-lyon

macOS (Tunnelblick):

# Installer Tunnelblick (tunnelblick.net)
# Doppelklick auf die .ovpn-Datei → automatischer Import

Schritt 4 – Verbindung zur SPS herstellen

Sobald das VPN aktiv ist, erkennt TIA Portal die Steuerung so, als befände sie sich im lokalen Netzwerk:

TIA Portal → Online → Accessible devices
→ 192.168.1.10 — Siemens S7-1200 CPU 1212C DC/DC/DC
→ Firmware: V4.5
→ S7comm-Verbindung (Port 102) hergestellt
→ Tunnel-Latenz: 18 ms (für TIA Portal akzeptabel)

Was technisch gesehen passiert:

Typische Gesamtlatenz: 15 bis 35 ms bei 4G LTE – mehr als ausreichend für das TIA Portal, das bis zu 100 ms einwandfrei funktioniert.


Kompatibilität mit SPS-Programmiersoftware

SoftwareHerstellerProtokollKompatibel mit Eziwan-VPNAnmerkungen
TIA Portal v17+SiemensS7comm / PROFINET✅ NativLatenz < 50 ms erforderlich
Unity Pro / EcoStruxureSchneiderMODBUS TCP / UNI-TE✅ NativM340, M580, Premium
Studio 5000 / FactoryTalkRockwellEtherNet/IP / CIP✅ NativControlLogix, CompactLogix
Sysmac StudioOmronEtherNet/IP / FINS✅ NativNX-, NJ-Serien
GX WorksMitsubishiMELSEC✅ NativQ-, FX5-Serien
CODESYSHerstellerübergreifendMODBUS TCP / OPC-UA✅ NativCODESYS-Laufzeitumgebung
Step 7 ClassicSiemens (Legacy)S7comm✅ KompatibelS7-300/400, S7-Protokoll v1
TIA Portal und Netzwerklatenz

TIA Portal reagiert empfindlich auf Latenz bei Online-Debugging-Sitzungen. Bei einer Latenz von mehr als 80 ms kann das Verhalten unvorhersehbar werden (Verbindungszeitüberschreitungen, langsame Anzeige der Online-Blöcke). 4G LTE liefert in der Regel 15–35 ms, was ausreichend ist. 3G (sofern noch verfügbar) mit 80–150 ms kann Probleme verursachen.


Fernzugriff auf eine Benutzeroberfläche und ein SCADA-System

Siemens WinCC / KTP-Benutzeroberfläche (über VPN)

Die Benutzeroberfläche befindet sich im lokalen Netzwerk des Standorts (z. B. 192.168.1.20). Bei aktivem VPN:

  • WinCC Runtime: direkt über die lokale IP-Adresse erreichbar
  • Simatic HMI: S7comm-Protokoll, identisches Verhalten wie die SPS
  • KTP-Panel: über das TIA Portal online erreichbar

SCADA Wonderware AVEVA (HTTPS-Reverse-Proxy)

Für SCADA-Systeme mit Webschnittstelle (Wonderware, Ignition, WinCC OA) kann Eziwan einen sicheren Reverse-Proxy konfigurieren, ohne dass auf Benutzerseite ein VPN erforderlich ist:

# Einrichtung eines Reverse-Proxys auf dem Eziwan-Gateway
proxy_rules:
- name: scada-lyon
description: "SCADA Wonderware System Platform — Usine Lyon A"
internal: http://192.168.1.100:80
external: https://scada-lyon.eziwan.com
tls: true # HTTPS mit automatisch erneuerbarem Let's Encrypt-Zertifikat
auth: eziwan_sso # SSO Eziwan mit obligatorischer MFA
allowed_users:
- superviseur@entreprise.fr
- technicien-maintenant@entreprise.fr
session_timeout: 30m # Abmeldung nach Inaktivität
audit_log: true # Alle protokollierten Aktionen

Der Benutzer greift über seinen Browser auf https://scada-lyon.eziwan.com zu, authentifiziert sich über SSO + MFA und gelangt zur SCADA-Oberfläche – ganz ohne VPN-Client und von jedem Gerät aus.

Ignition (Inductive Automation)

Ignition verfügt über ein natives Web-Gateway. Mit Eziwan:

Ignition Gateway (192.168.1.50:8088)
→ Zugriff über den Eziwan-Reverse-Proxy mit HTTPS + MFA
→ Oder direkter Zugriff über VPN (lokaler Port 8088)
→ Oder über Ignition Cloud (sofern eine Ignition Cloud-Lizenz enthalten ist)

Die 7 goldenen Regeln für die Sicherheit beim Fernzugriff auf OT-Systeme

1. Auf der Website sind keine eingehenden Ports offen

Absolute Regel. Das Eziwan-Gateway blockiert standardmäßig alle eingehenden Ports. Die einzige zulässige Verbindung ist eine ausgehende Verbindung (VPN-Tunnel zur Cloud). Selbst der SSH-Port für die Verwaltung des Gateways ist auf der WAN-Seite deaktiviert.

2. Systematische MFA bei allen Zugängen

Ohne Zwei-Faktor-Authentifizierung ist kein Zugriff auf eine VPN-Verbindung, das Eziwan-Portal oder den SCADA-Zugang möglich. Unterstützt werden: TOTP (Google Authenticator, Authy), physischer FIDO2-Schlüssel (YubiKey), SMS (sollte vermieden werden).

3. Befristeter Zugang für Dienstleister

Ein Systemintegrator, der zwei Tage lang an Ihrer Abfüllanlage arbeitet, benötigt keinen dauerhaften Zugriff. Richten Sie einen Zugriff mit Ablaufdatum und Zeitfenster ein. Der Zugriff wird automatisch widerrufen.

4. Ein Zugang pro Person, keine gemeinsamen Zugangsdaten

Ein einziges VPN-Konto, das vom gesamten Team gemeinsam genutzt wird = keine Rückverfolgbarkeit. Jeder Techniker (intern oder extern) muss über ein eigenes, auf seinen Namen lautendes Konto verfügen. Im Falle eines Vorfalls wissen Sie genau, wer wann verbunden war.

5. Vollständige Protokollierung und Aufbewahrung für mindestens 12 Monate

Jede VPN-Verbindung, jede Konfigurationsänderung und jeder Zugriff auf ein Gerät muss mit folgenden Angaben protokolliert werden: Zeitstempel, Identität, Quell-IP-Adresse, Sitzungsdauer. Aufbewahrungsfrist mindestens 12 Monate (NIS2 schreibt für OIV eine Aufbewahrungsfrist von 3 Jahren vor).

6. Strikte Trennung von OT und IT

Die Steuerungen (OT-Netzwerk) dürfen sich nicht im selben VLAN wie die IT-Server befinden. Das Eziwan-Gateway kann mehrere LAN-Schnittstellen mit strengen VLAN-übergreifenden Firewall-Regeln verwalten. Der Zugriff vom IT-Netzwerk auf das OT-Netzwerk erfolgt über eine kontrollierte DMZ.

7. Sofortige Sperrung der Zugangsrechte im Falle eines Ausscheidens

Protokoll zum Ausscheiden: Löschung des Kontos am Tag des Ausscheidens, sofortige Deaktivierung des VPN-Zertifikats, Überprüfung der Sitzungen der letzten 30 Tage. Dies ist in Ihrem HR-Verfahren zu dokumentieren.


Einhaltung der Normen NIS2 und IEC 62443

Was NIS2 für den Fernzugriff vorschreibt

Die NIS2-Richtlinie (die in Frankreich seit Oktober 2024 durch Umsetzung gilt) schreibt für kritische und wichtige Einrichtungen spezifische Maßnahmen im Zusammenhang mit dem Fernzugriff vor:

NIS2-AnforderungArtikelEziwan-Lösung
Starke Authentifizierung (MFA)Art. 21 §2bMFA TOTP/FIDO2 bei allen Zugängen
Verschlüsselung der KommunikationArt. 21 §2hOpenVPN AES-256-GCM oder WireGuard ChaCha20
ZugriffsprotokollierungArt. 21 §2jVollständige, exportierbare Protokolle, konfigurierbare Aufbewahrungsfrist
Verwaltung von DrittzugriffenArt. 21 §2iTemporäre, namentlich zugeordnete, widerrufbare Zugriffe
Meldung von VorfällenArt. 23Automatische Warnmeldungen bei ungewöhnlichen Zugriffen
SchwachstellenmanagementArt. 21 §2eAutomatisch aktualisierte Gateway-Firmware

Zuordnung gemäß IEC 62443

Die Norm IEC 62443 definiert Sicherheitsstufen (Security Levels, SL) für industrielle Steuerungssysteme. Die Eziwan-Architektur umfasst:

SicherheitsstufeVon Eziwan abgedeckte Anforderungen
SL 1 – Schutz vor unbeabsichtigten AngriffenBasisauthentifizierung, Firewall, Protokolle
SL 2 – Schutz vor einfachen gezielten AngriffenMFA, Verschlüsselung, Prüfpfad, Netzwerksegmentierung
SL 3 — Schutz vor ausgeklügelten AngriffenZTNA, erweiterte Netzwerksegregation, Anomalieerkennung
zum Compliance-Export

Die Eziwan-Plattform erstellt einen herunterladbaren NIS2-Compliance-Bericht (PDF), der Folgendes enthält: Zugriffsverzeichnis, Protokolle der letzten 12 Monate, Sicherheitskonfiguration. Der Bericht kann direkt für Ihre ANSSI-Audits oder für Audits durch externe Prüfer verwendet werden.


Fehlerbehebung: Häufige Probleme

TIA Portal erkennt die Steuerung über VPN nicht

Mögliche Ursachen:

  1. Der Pfad zum Subnetz des Standorts wird vom VPN nicht weitergeleitet → Konfiguration der Tunnelschnittstelle überprüfen (eziwan route list am Gateway)
  2. Die Windows-Firewall blockiert S7comm im Netzwerk „Öffentlich“ → Ändern Sie das VPN-Netzwerkprofil auf „Privat“
  3. S7comm-Timeout < Tunnellatenz → Erhöhen Sie im TIA Portal das Verbindungszeitlimit auf 5.000 ms (Einstellungen → PG/PC-Schnittstelle)

Zu hohe Latenz für TIA Portal (> 80 ms)

Prüfungen:

# Ping-Test vom Techniker-PC zur SPS (VPN aktiv)
ping 192.168.1.10 -n 20

# Wenn die Latenz > 80 ms beträgt, überprüfen Sie Folgendes:
# 1. 4G-Signalqualität am Standort (RSRP > -100 dBm empfohlen)
eziwan modem signal

# 2. Standort des VPN-Hubs (wählen Sie „Europa/Frankreich“)
# 3. Netzwerküberlastung auf der Seite des Technikers (von einem anderen Netzwerk aus testen)

VPN-Verbindung hergestellt, aber auf die Steuerung kann nicht zugegriffen werden

# Die Route über das Gateway überprüfen
eziwan route test 192.168.1.10
# Bei Timeout: Das Ethernet-Kabel zwischen Gateway und Switch am Standort überprüfen

# Überprüfen, ob die Steuerung lokal reagiert
eziwan ping 192.168.1.10 --source lan
# Bei Timeout: IP-Konfiguration der SPS und den physikalischen Zustand überprüfen

Häufig gestellte Fragen

Wie viele Techniker können sich gleichzeitig verbinden? Bei den Eziwan-Standardangeboten gibt es keine Begrenzung der Anzahl gleichzeitiger VPN-Verbindungen. An einem Standort können zwei Techniker gleichzeitig an verschiedenen Steuerungen arbeiten. Die 4G-Bandbreite (typischerweise 20–50 Mbit/s) wird auf alle aktiven Verbindungen aufgeteilt.

Ist es möglich, unser bestehendes Unternehmens-VPN anstelle von Eziwan zu nutzen? Ja, sofern Ihr Unternehmens-VPN mit einem Router verbunden werden kann, der einen Standard-IPSec-Tunnel aufbaut. Das Eziwan-Gateway unterstützt IPSec/IKEv2 als alternativen Tunnel. Allerdings ist der Verlust von Audit-Trails, granularer Rechteverwaltung und ZTP bei standortübergreifenden Geräteflotten erheblich.

Können Fernwartungssitzungen (Video) aufgezeichnet werden? Die Aufzeichnung von Sitzungen (Screen Recording) ist im Eziwan Enterprise-Angebot über die Integration mit PAM-Tools (Privileged Access Management) wie CyberArk oder Teleport verfügbar. Diese Funktion ist im Standardangebot nicht nativ enthalten.

Funktioniert der Fernzugriff auch für Steuerungen, die mit Nicht-IP-Protokollen (Profibus, HART) arbeiten? Für Profibus: Es ist ein Profibus-→-Modbus-TCP- oder Profibus-→-Ethernet-Gateway vor Ort erforderlich. Auf ein solches Gateway (z. B. Anybus X-Gateway) kann dann über den VPN-Tunnel zugegriffen werden. Für HART: HART-Messumformer sind in der Regel über ihre lokale Modbus-Schnittstelle oder über einen HART-Multiplexer erreichbar.

Wie geht man mit einem externen Techniker um, der zu einem anderen Unternehmen wechselt? Die Sperrung erfolgt über das Eziwan-Portal mit sofortiger Wirkung: Konto deaktiviert, VPN-Zertifikat gesperrt, Zugriff innerhalb von Sekunden unterbrochen. Der Techniker kann sich nicht mehr einloggen, selbst wenn er seine VPN-Konfigurationsdatei behält (das gesperrte Zertifikat wird vom Konzentrator abgelehnt).

Beeinträchtigt der Fernzugriff den Betrieb der SPS? Nein – das Eziwan-Gateway ist ein passives Netzwerkgerät. Es greift weder in den Feldbus noch in die Kommunikation zwischen SPS und HMI ein. Die SPS „nimmt“ die Fernverbindung nicht wahr: Sie empfängt Modbus- oder S7comm-Anfragen so, als würde sie über das lokale Netzwerk abgefragt werden.


Weiterführende Informationen


Der sichere Fernzugriff auf Ihre Steuerungsgeräte ist im Jahr 2025 kein Luxus mehr – er ist eine betriebliche Notwendigkeit (Senkung der Einsatzkosten) und eine gesetzliche Anforderung (NIS2). Mit der richtigen Architektur senken Sie Ihre Wartungskosten vor Ort um das 3- bis 5-Fache und stärken gleichzeitig die Sicherheit Ihres OT-Netzwerks.

Benötigen Sie eine Überprüfung Ihrer aktuellen Fernzugriffsarchitektur? Vereinbaren Sie eine technische Demo – unser Team führt innerhalb von 45 Minuten eine umfassende Diagnose Ihrer OT-Sicherheit durch.


Weitere Ressourcen