OPC UA scheitert selten an seiner Kryptographie. Es scheitert daran, dass Trust-Lists offen gelassen wurden, die anonyme Anmeldung „nur für die Inbetriebnahme“ aktiv blieb oder ein Server mit einer ungepatchten Bibliothek ausgeliefert wurde. Wenn Sie nach praxistauglichen Best Practices für die OPC UA-Sicherheit in realen Produktionsanlagen suchen, setzen Sie genau hier an: Das Protokoll ist robust, die Schwachstelle liegt in der Implementierung. 

Das ist nicht nur unsere Einschätzung. Das deutsche BSI hat die Spezifikation 2016 sowie erneut 2022 (die Aktualisierung umfasste Version 1.04 und die open62541-Implementierung) evaluiert und keine systematischen Designfehler festgestellt. Dennoch zählte das TRACE-Team von Bitsight in den zwölf Monaten bis Juni 2025 insgesamt 14.220 über das Internet erreichbare OPC UA-Server – 51,74 % davon akzeptierten anonyme Verbindungen. Von den Geräten, die ihren Sicherheitsmodus übermittelten, boten rund 80 % weiterhin den unverschlüsselten Modus „None“ an. Dasselbe Protokoll, grundlegend unterschiedliche Sicherheitsniveaus. 

Dieser Beitrag richtet sich an CISOs, OT-Sicherheitsverantwortliche und Anlagenarchitekten, die mit den Grundlagen von OPC UA bereits vertraut sind. Er beleuchtet die Funktionsweise von Zertifikaten und Trust-Lists in der Praxis, zeigt auf, welche Security Policies aktiviert und welche ausgemustert werden sollten, beschreibt die häufigsten Fehlkonfigurationen und geht auf die 2026 veröffentlichten Security Advisories ein, die für Ihre Prüfungen in diesem Quartal maßgeblich sind. 

Kernpunkte 

• Betrachten Sie die Anwendungsauthentifizierung (Zertifikate und Trust-Lists) als die entscheidende Sicherheitsmaßnahme. Anonyme Benutzer sind dahinter vertretbar, ohne sie jedoch ein erhebliches Risiko. 

• Deaktivieren Sie die Security Policy „None“ sowie die veralteten Richtlinien Basic128Rsa15 und Basic256, sofern der Betrieb nicht durch dokumentierte Legacy-Systeme zwingend erforderlich ist. 

• Erzwingen Sie SignAndEncrypt an jedem Endpunkt und stellen Sie sicher, dass Benutzer-Tokens (Username-Tokens) ebenfalls über eine moderne Richtlinie verschlüsselt werden. 

• Erfassen Sie alle OPC UA-Bibliotheken in Ihren Systemen. Das Eclipse-Milo-Advisory vom Oktober verdeutlicht, dass die Version des Protokoll-Stacks ebenso kritisch ist wie die Serverkonfiguration. 

• Exponieren Sie OPC UA-Endpunkte unter keinen Umständen direkt ins Internet und auditieren Sie die Kommunikationsbeziehungen innerhalb der OT-Netzwerke. 

OPC UA-Sicherheit im Jahr 2026: Relevante Änderungen und deren Bedeutung 

Seit dem Sommer häufen sich die Security Advisories zu OPC UA. Sie verdeutlichen: Die Schwachstellen liegen primär in Protokoll-Stacks, Vertrauensankern (Trust Anchors) und veralteter Kryptographie, nicht im Protokoll selbst. Nachfolgend die Chronologie (neueste zuerst). Keiner der genannten Fälle stellt einen bestätigten Sicherheitsvorfall dar; die Advisories beschreiben potenzielle Risiken, und Hersteller melden für die meisten Schwachstellen bisher keine aktive Ausnutzung. 

Drei strukturelle Muster, die Aufmerksamkeit erfordern 

1. Autorisierungslogik versagt trotz korrekter Konfiguration. Mehrere Milo-Schwachstellen betreffen die Zugriffskontrolle und nicht die Kryptographie. Eine CVE betrifft das Duplizieren von Serverkonfigurationen, bei dem das konfigurierte Rollen-Mapping fehlschlägt. Dadurch können rollengeschützte Methoden und Knoten ungeschützt bleiben – insbesondere, wenn der Server anonyme Sitzungen gestattet. Eine weitere Schwachstelle ermöglicht es, den Aufruf einer geschützten Methode innerhalb eines Batches mit einer autorisierten Anfrage mitzuschicken. Eine dritte führt dazu, dass Diagnoseknoten ohne Autorisierung lesbar sind, wodurch Details zur Sitzungssicherheit, verwendete Policies und öffentliche Client-Zertifikate offengelegt werden. Selbst bei fehlerfreier Konfiguration bleibt ein Restrisiko, weshalb das Management von Bibliotheken fester Bestandteil Ihres OPC UA-Sicherheitskonzepts sein muss. 

2. Veraltete Kryptographie birgt akute Risiken. Die kritischste Schwachstelle in Milo, CVE-2026-60007 (CVSS v4.0 9.1), ist ein Padding-Oracle-Angriff bei der Verarbeitung von Username-Tokens. Ein On-Path-Angreifer, der ein mit Basic128Rsa15 verschlüsseltes Username-Token abfängt, kann durch wiederholte, unauthentifizierte ActivateSession-Anfragen das Passwort rekonstruieren. Sitzungen ohne diese Richtlinie sind gegen diese Technik immun. Die Deaktivierung veralteter Policies ist daher eine zwingende Schutzmaßnahme und keine bloße Systembereinigung. Beachten Sie abweichende Einstufungen: Das Advisory selbst nennt CVSS v3 8.2 insgesamt, während einzelne CVEs über CVSS v4.0-Vektoren bewertet sind. 

3. Vertrauensanker und Clients als unterschätzte Angriffsfläche. Das Prosys-Advisory und der Client-Bug in open62541 betreffen unterschiedliche Komponenten, verdeutlichen aber denselben Grundsatz: Welche Zertifikate Ihr OPC UA-Client oder Ihre Broker-Verbindung als vertrauenswürdig einstuft, ist ebenso sicherheitsrelevant wie die Konfiguration des Servers. Prosys bestätigt, dass OPC UA-Client- und -Server-Verbindungen unbeeinträchtigt blieben, da sie den Zertifikatsspeicher der Anwendung statt des Java-Trust-Stores nutzen. Hier greift das PKI-Modell von OPC UA wirksam; das Risiko bestand bei den peripheren MQTT-, HTTPS- und LDAP-Verbindungen. 

Aktualisierungen von Spezifikation und Protokoll-Stacks 

Normativ brachte Version 1.05.07 der OPC UA-Spezifikation wesentliche Neuerungen bei ECC-Sicherheitsrichtlinien mit sich. Das Maintenance-Release 1.5.5 von open62541 setzte diese um, einschließlich ECC-basierter Sitzungsauthentifizierung. Der Server verweigert nun ECC-Policies zur Authentifizierung über ungesicherte (None) Kanäle. Ein Issue der OPC Foundation zu Version 1.05.07 migriert zudem die ECC-Richtlinie nistP256 von AES-128-CBC zu AES-128-GCM. Die Auswirkungen auf Ihre Richtlinienauswahl erläutern wir im Folgenden. 

Das Schichtenmodell der OPC UA-Sicherheit (und typische Schwachstellen) 

Die Sicherheitsarchitektur von OPC UA basiert auf drei Kontrollmechanismen, die in der Praxis oft fälschlicherweise gleichgesetzt werden. Die Leitlinien der OPC Foundation unterteilen diese in Benutzer-, Anwendungs- und Transportsicherheit. Jede Schicht kann separat konfiguriert werden – und weist eigene Fehlerquellen auf. 

Daraus folgt: Ein Server kann zwar eine „zertifikatbasierte Sicherheit“ ausweisen, operativ aber dennoch ungeschützt sein. Die Anwendungsauthentifizierung wird von Angreifern zuerst sondiert. Ist sie nicht durchgesetzt, kann ein nicht autorisierter Client einen sicheren Kanal öffnen, die Endpunktliste abfragen und die schwächste angebotene Option wählen. Der Client wählt den Endpunkt, der Server autorisiert ihn. Steht in der Konfiguration neben einer sicheren Option ein Endpunkt mit „None“, wählt ein Angreifer diesen ungeschützten Pfad. 

Wichtig für das Gesamtkonzept: Die OPC Foundation stellt klar, dass OPC UA kein Informationssicherheits-Managementsystem (ISMS) nach ISO 27001 ersetzt. Das Protokoll liefert technische Mechanismen. Richtlinienkompetenz, Mitarbeitersensibilisierung, physische Sicherheit und die Zonierung des Netzwerks verbleiben in der Verantwortung des Betreibers. 

OPC UA-Zertifikate: Trust-Lists, GDS und Lifecycle-Management 

Das Zertifikatsmanagement ist der Bereich, an dem viele Initiativen zur OPC UA-Sicherheit im Betriebsalltag scheitern. Die kryptographischen Verfahren sind erprobt; der operative Aufwand für die Verteilung, Freigabe und Erneuerung von Zertifikaten über Hunderte von Geräten verleitet Betriebsteams jedoch häufig dazu, Sicherheitsprüfungen zu deaktivieren. 

Funktionsweise des Vertrauensmodells 

Jede OPC UA-Anwendung besitzt ein Instanzzertifikat. Server und Clients verwalten jeweils eine Trust-List (Vertrauensliste) mit den Zertifikaten (selbstsigniert oder CA-ausgestellt), mit denen eine Kommunikation zulässig ist. Nicht gelistete Zertifikate müssen in einem Rejected-Store abgelegt werden, bis ein Administrator sie manuell freigibt. Diese explizite Freigabe ist der eigentliche Kontrollmechanismus – und zugleich der Grund, warum er im Betriebsalltag oft umgangen wird. 

Eine wissenschaftliche Untersuchung von 48 industriellen Produkten mit ausgewiesenem OPC UA-Support unterteilte Zertifikatsprobleme in drei Hauptkategorien: fehlende Unterstützung von Trust-Lists (11 Produkte bzw. 22,9 %), standardmäßig deaktivierte Trust-Lists sowie unsichere Konfigurationen derselben. Der Analyse zufolge bewarben 14,6 % der Produkte ein sicheres Design, validierten das Zertifikatsvertrauen in der Praxis jedoch unzureichend. Die Funktionen existieren; Werkseinstellungen und Dokumentationen verleiten Anwender jedoch zu oft dazu, sie zu umgehen. 

Anhand von drei Kontrollfragen können Sie das Risikopotenzial in Ihrer eigenen Umgebung verifizieren: 

1. Weist jeder Server unbekannte Client-Zertifikate standardmäßig ab oder werden sie automatisch akzeptiert? 

2. Welche Personen oder Rollen sind autorisiert, Zertifikate in den Trusted-Store zu verschieben, und wird dies revisionssicher protokolliert? 

3. Welcher Prozess stellt sicher, dass abgelaufene Zertifikate oder außer Betrieb genommene Geräte aus ausnahmslos allen referenzierenden Trust-Lists entfernt werden? 

Einsatz von GDS oder OT-spezifischen Zertifizierungsstellen im Produktivbetrieb 

Eine manuelle Zertifikatsverwaltung auf Geräteebene ist bei zehn Servern machbar. Bei tausend Geräten skaliert sie nicht mehr. Das Modell des Global Discovery Servers (GDS) von OPC UA ermöglicht es einer zentralen Instanz, Anwendungszertifikate zu signieren und Trust-Lists auf die Server zu verteilen. Ein Server muss dadurch lediglich dem GDS vertrauen und nicht jedem einzelnen Kommunikationspartner. Wird ein neues CA-Zertifikat im GDS hinterlegt, wird das Update automatisch an alle verwalteten Server ausgerollt. 

Wesentliche betriebliche Aspekte aus Herstellervorgaben und Praxiserfahrungen: 

• Der Server muss dem GDS-Agenten vorab vertrauen. Schlägt ein Push-Vorgang fehl, liegt dies meist an fehlendem Vertrauen in den GDS. Die Behebung erfolgt herstellerspezifisch über Provisioning oder das manuelle Verschieben des GDS-Zertifikats in den Trusted-Store. 

• Das für den Push genutzte Dienstkonto benötigt Zertifikats-Administrationsrechte auf dem Server (beispielsweise die Rolle „SecurityAdmin“). Dieses Konto ist mit denselben Sicherheitsstandards wie ein Domänen-Administrator zu behandeln. 

• Einige Server führen nach einem Zertifikats-Push einen Neustart durch. Planen Sie Zertifikatsrotationen daher grundsätzlich in definierten Wartungsfenstern und überwachen Sie die Reinitialisierung der Clients. 

• Betreiben Sie diese CA zwingend als private CA. Das erwähnte Prosys-Advisory illustriert die Risiken, wenn ein TLS-Client unbemerkt öffentlichen Root-CAs vertraut. Eine dedizierte OT-CA oder eine streng reglementierte Sub-CA stellt sicher, dass Anwendungsidentitäten ausschließlich intern legitimiert werden können. 

Checkliste für das Zertifikatsmanagement 

Ein weiteres Risiko betrifft die Implementierung: Team82 von Claroty wies nach, dass einige Server mit proprietärer Zertifikatskettenprüfung nicht gegen zirkuläre Zertifikatsketten abgesichert waren (Zertifikat A signiert durch B, Zertifikat B signiert durch A), was zu einem Denial of Service führte. Wenn Sie eigene OPC UA-Komponenten entwickeln oder integrieren, prüfen Sie die Validierung der Zertifikatskette mit derselben Sorgfalt wie die Verschlüsselung. 

OPC UA Security Policies und Modi: Empfehlungen zur Konfiguration 

Eine Security Policy definiert eine normierte Kombination kryptographischer Algorithmen (Signierung, asymmetrische und symmetrische Verschlüsselung, Schlüsselableitung) gemäß Teil 7 des Standards. Der Sicherheitsmodus (None, Sign oder SignAndEncrypt) legt fest, ob diese Algorithmen angewendet werden. Beide Parameter müssen korrekt gewählt werden. Eine starke Richtlinie auf einem Endpunkt mit dem Modus „None“ bietet keinerlei Schutzwirkung. 

Hinweis zu ECC: Elliptic-Curve-Richtlinien bieten ein vergleichbares oder höheres Sicherheitsniveau bei kürzeren Schlüssellängen, was für ressourcenbeschränkte Embedded-Geräte optimal ist. open62541 unterstützt bereits sechs Kurven. Die Standardisierung befindet sich jedoch in der Konsolidierung. Mit Version 1.05.07 wurden ECC-Kanäle und Sitzungsauthentifizierungen angepasst, nistP256 wechselt von AES-CBC auf AES-GCM, und führende .NET-SDKs markieren ursprüngliche URIs für Curve25519 und Curve448 zugunsten von ChaCha20-Poly1305 bereits als veraltet. Jede ECC-Kurve erfordert zudem ein eigenes Schlüsselpaar, wenngleich RSA und ECC parallel auf einem Server betrieben werden können. Unsere Empfehlung: Pilotieren Sie ECC in homogenen Teilsystemen, verzichten Sie jedoch vorerst auf eine verbindliche Vorgabe in heterogenen Multi-Vendor-Anlagen. 

Modi und Benutzer-Tokens 

• SignAndEncrypt als Standard etablieren. Die OPC Foundation gestattet den Modus „Sign“ bei kritischen Performance-Einschränkungen. Für Steuerungsdaten und authentifizierungsrelevante Kommunikation gibt es jedoch im Regelfall keine Rechtfertigung für den Verzicht auf Verschlüsselung. 

• Mindestsicherheitsrichtlinie konfigurieren. Einige Produkte ermöglichen die Festlegung einer Untergrenze (Minimum Security Policy), sodass der Server schwächere Policies kategorisch abweist (z. B. Rockwell FactoryTalk Optix). Nutzen Sie diesen Parameter, um Richtlinien verbindlich durchzusetzen. 

• Benutzer-Tokens isoliert absichern. Benutzername und Passwort werden während der Sitzungsaktivierung übertragen und gemäß der Richtlinie des Benutzer-Tokens verschlüsselt. Ist dieses Token mit Basic128Rsa15 oder ähnlich schwachen Verfahren geschützt, bietet auch ein starker Transportkanal keinen hinreichenden Schutz. Setzen Sie bei Machine-to-Machine-Kommunikation vorzugsweise auf X.509-Benutzer-Tokens und reservieren Sie Passwörter für Personen, abgesichert durch MFA auf der Zugriffsebene. 

• PubSub-Absicherung berücksichtigen. OPC UA PubSub über MQTT oder UDP nutzt eigene Sicherheitsrichtlinien (AES-CTR-basiert) sowie TLS zum Broker bei MQTT. Wenden Sie die Grundsätze für private CAs auch hier konsequent an. 

Zehn häufige OPC UA-Fehlkonfigurationen und Gegenmaßnahmen 

Die Mehrheit der Sicherheitsbefunde bei OPC UA lässt sich auf wiederkehrende Standardfehler zurückführen. Nutzen Sie diese Übersicht für interne Audits. Die ersten vier Punkte decken das größte praktische Risikopotenzial ab. 

Audit-Check: Überprüfung in 15 Minuten 

Verbinden Sie einen OPC UA-Client (z. B. UaExpert) mit einem Server pro Standort und fragen Sie die Endpunktliste ab. Jeder Endpunkt sollte mindestens SignAndEncrypt mit Basic256Sha256 oder höher anzeigen. Initiieren Sie anschließend einen Verbindungsaufbau mit einem neu generierten Zertifikat, das nicht in der Trust-List enthalten ist. Der Server muss die Verbindung zwingend verweigern. Schlägt einer dieser Tests fehl, weisen die Systeme die Schwachstellen 1 bis 4 auf. 

Dies deckt sich mit den Analysen von Trout Software: Die Mehrzahl der OT-Sicherheitslücken resultiert aus Konfigurationsdefiziten statt aus Designfehlern des Protokolls. Das bedeutet auch: Diese Risiken lassen sich herstellerunabhängig und ohne Wartezeit auf Patches beheben. 

Supply-Chain- und clientseitige Risiken bei OPC UA 

Ihr Sicherheitsniveau wird maßgeblich durch Drittanbieter-Code bestimmt. Team82 von Claroty identifizierte rund 50 Schwachstellen in etwa 15 OPC UA-Protokoll-Stacks, die Hunderte von Endprodukten betrafen. Die Stacks bilden ein kritisches Glied in der OT-Lieferkette, da Hersteller sie oft ohne tiefgreifende Modifikationen integrieren. Ein Fehler in einer Basiskomponente schlägt somit simultan auf PLCs, Gateways und Historians durch. 

Zwei Maßnahmen zur Risikominimierung: 

Transparenz über eingesetzte Komponenten (SBOM). Wie die Viakoo-Analyse zu Milo darlegt, kann die Bibliothek tief in Servern integriert sein – die Versionsnummer des Endgeräts lässt somit keinen direkten Rückschluss auf die Anfälligkeit zu. Fordern Sie von Ihren Lieferanten genaue Angaben zum integrierten OPC UA-Stack inklusive Versionsstand und erfassen Sie diese Daten im Asset-Management. Bei Veröffentlichung eines Advisories muss die Betroffenheit innerhalb weniger Stunden feststehen. 

Misstrauen gegenüber Servern aus Client-Perspektive (Zero Trust). Sicherheitskonzepte fokussieren sich oft auf den Serverschutz; Clients sind jedoch gleichermaßen exponiert. Team82 demonstrierte dies anhand der Verkettung von Schwachstellen in Ignition (Inductive Automation) und edgeAggregator (Softing): Durch das Senden manipulierter Daten von einem OPC UA-Server an den Client wurde Remote Code Execution erreicht. Dasselbe Prinzip lag der open62541-Schwachstelle von 2026 zugrunde. Kann ein Angreifer einen bösartigen Server im Netzwerk platzieren und einen legitimen Client zur Verbindung bewegen, verschafft er sich Zugriff auf das System. 

Konkrete Schutzmaßnahmen: 

• Konfigurieren Sie auf Clients verbindliche Allow-Lists für Serververbindungen über verifizierte Trust-Lists statt automatischer Akzeptanz. 

• Segmentieren Sie Datenaggregatoren, Gateways und Integrationsserver separat. Als Brücken zwischen Systemen stellen sie bevorzugte Ziele für laterale Bewegungen dar. 

• Behandeln Sie Textfelder, Knotennamen und Strukturen, die von einem Server übermittelt werden, in eigenen Anwendungen und Dashboards grundsätzlich als nicht vertrauenswürdige Eingaben. 

• Integrieren Sie folgende Kernfragen in Sicherheitsfragebögen für Lieferanten: 

1. Welcher OPC UA-Stack und welche Version sind im Produkt implementiert? 

2. Stellen Sie eine SBOM bereit, und innerhalb welcher Fristen werden Patches für Stack-Schwachstellen (CVEs) bereitgestellt? 

3. Weist der Server unbekannte Client-Zertifikate standardmäßig ab? 

4. Lässt sich eine verbindliche Mindestsicherheitsrichtlinie konfigurieren und der Modus „None“ vollständig deaktivieren? 

5. Welche rollenbasierte Zugriffskontrolle (RBAC) wird vom OPC UA-Server unterstützt, und wie wird deren Wirksamkeit verifiziert? 

Hardening-Checkliste für OPC UA in industriellen Netzwerken 

Zertifikate und Richtlinien sind die Grundvoraussetzung, reichen alleine jedoch nicht aus. Ein belastbares industrielles Sicherheitskonzept für OPC UA erfordert flankierende Kontrollen auf mehreren Ebenen. 

Netzwerk und Systemarchitektur 

• Segmentieren Sie OPC UA-Server in Zonen und definieren Sie Conduits gemäß IEC 62443. Zonenübergreifende OPC UA-Kommunikation muss kontrollierte Übergabepunkte passieren und darf nicht unsegmentiert geroutet werden. 

• Implementieren Sie Allowlisting für autorisierte Client-IP-Adressen auf der Firewall. Der Standardport 4840 ist hinlänglich bekannt (96,81 % der von Bitsight identifizierten exponierten Server nutzten ihn). Verlassen Sie sich nicht auf Security through Obscurity. 

• Nutzen Sie „Reverse Connect“, sofern dies von den Produkten unterstützt wird. Hierbei initiiert der Server in der Steuerungszone die Verbindung zum Client in der übergeordneten Zone, wodurch eingehende Firewall-Freigaben in sensible Bereiche vermieden werden. 

• Realisieren Sie Fernzugriffe ausschließlich über VPN-Verbindungen oder gehärtete Remote-Access-Gateways mit MFA. Veröffentlichen Sie niemals OPC UA-Endpunkte direkt im Internet. 

Identitäts- und Rechtemanagement 

• Weisen Sie Benutzern und Diensten individuelle Accounts zu. Geteilte Standardkonten verhindern eine revisionssichere Nachvollziehbarkeit im Audit-Fall. 

• Verwenden Sie X.509-Benutzer-Tokens für die M2M-Kommunikation und beschränken Sie kennwortbasierte Logins auf administrative Zugriffe von Personen. 

• Vergeben Sie Lesezugriffe restriktiv und Schreib- sowie Methodenrechte nach dem Minimalprinzip (Least Privilege). Validieren Sie die Rollenbeschränkungen nach jedem Update oder Konfigurationsabgleich. Fehler wie der Milo-Rollenzuweisungs-Bug verdeutlichen, wie wichtig Verifikationstests nach Systemänderungen sind. 

Monitoring und Angriffserkennung 

• Aktivieren Sie das Server-Auditing und binden Sie die Protokolldaten in Ihr industrielles SIEM oder OT-Monitoring ein. 

• Generieren Sie Alarme bei Sitzungsaufbauten über den Modus „None“, neuen Zertifikaten im Rejected- oder Trusted-Store, Auffälligkeiten bei fehlgeschlagenen ActivateSession-Aufrufen (Indikator für Oracle-Angriffe) sowie Schreib- oder Methodenaufrufen von bisher unbekannten IP-Adressen. 

• Überwachen Sie Discovery-Anfragen von nicht autorisierten Endpunkten. Aufklärungsmuster von Angreifern beginnen in der Regel mit dem Scannen von Endpunkten. 

Patch-Management und Ausfallsicherheit 

• Halten Sie das Inventar der OPC UA-Komponenten auf aktuellem Stand und patchen Sie über offizielle Hersteller-Releases. Führen Sie keinen eigenmächtigen Komponentenaustausch auf industriellen Appliances durch. 

• Sofern Patches noch nicht verfügbar sind, beschränken Sie den Netzzugriff über Firewalls streng auf verifizierte Kommunikationspartner. Dies deckt sich mit den empfohlenen Übergangsmaßnahmen zu den Milo-Sicherheitsmeldungen. 

• Konfigurieren Sie Limits für Verbindungen, Sitzungsanzahlen und Nachrichtengrößen, falls herstellerseitig unterstützt. Diverse bekannte Schwachstellen (wie beim B&R PPT30) basieren auf unauthentifizierter Ressourcenerschöpfung. 

• Führen Sie vor der Inbetriebnahme sowie nach signifikanten Updates Belastungstests und Protokoll-Fuzzing in einer repräsentativen Laborumgebung durch. 

90-Tage-Aktionsplan für CISOs zur OPC UA-Härtung 

Für Sicherheitsverantwortliche, die das Gesamtrisiko steuern, aber nicht operativ für die Anlagenführung zuständig sind, bietet dieser Ablaufplan einen strukturierten Pfad zur belastbaren Risikominimierung innerhalb eines Quartals. 

Zwei Praxishinweise: Rechnen Sie mit Legacy-Systemen, die aktuelle Standards technisch nicht erfüllen. Dokumentieren Sie jede Ausnahme strukturiert mit Verantwortlichkeit, kompensierenden Maßnahmen (Netztrennung, Allowlisting, IDS-Überwachung) und Prüffristen. Stimmen Sie zudem sämtliche Eingriffe eng mit der operativen Betriebsleitung (OT) ab: Ein unangekündigtes Schärfen von Trust-Lists an laufenden Produktionslinien gefährdet die Anlagenverfügbarkeit und schwächt die Akzeptanz von Sicherheitsmaßnahmen nachhaltig. 

Shieldworkz: Sichere OPC UA-Implementierung in kritischen Infrastrukturen 

Shieldworkz ist auf ganzheitliche industrielle OT-Cybersecurity spezialisiert. Wir schützen SCADA-, OT- und IoT-Umgebungen in KRITIS-Sektoren. Durch die Integration von Produkten, Sicherheitsdienstleistungen und praxiserprobten Architekturen überführen wir Prüfungsergebnisse nahtlos in wirksame Schutzmaßnahmen – ohne Reibungsverluste zwischen verschiedenen Dienstleistern. 

Unser Leistungsspektrum im Bereich OPC UA umfasst: 

• Sichtbarkeit (Asset Visibility): Automatisierte Identifikation von OPC UA-Servern, Clients und Gateways in allen Liegenschaften sowie Analyse der Kommunikationsbeziehungen. 

• Sicherheitsbewertung (Assessment): Detailliertes Audit von Endpunkten, Richtlinien, Zertifikatsstrukturen, Benutzer-Tokens und Trust-List-Konfigurationen anhand anerkannter Standards mit priorisierten Handlungsempfehlungen. 

• Härtung & Remediation: Konzeption und Implementierung von Zertifikats- und GDS-Prozessen, Netzwerkzonierung nach IEC 62443 und Ausarbeitung kompensierender Kontrollen für Legacy-Komponenten. 

• Patch- & Schwachstellenmanagement: Fortlaufender Abgleich herstellerspezifischer Security Advisories (z. B. Eclipse Milo, open62541) mit Ihrer spezifischen Anlagenkonfiguration und Planung von Maßnahmen im Einklang mit betrieblichen Wartungsfenstern. 

Für eine fundierte Evaluierung Ihrer OPC UA-Architektur steht Ihnen das Expertenteam von Shieldworkz für ein technisches Sicherheitsreview gerne zur Verfügung. 

OPC UA Security: Häufig gestellte Fragen (FAQ) 

Welche Best Practices sind für die OPC UA-Sicherheit prioritär? 

Die Durchsetzung valider Trust-Lists, die Nutzung des Modus SignAndEncrypt mit Basic256Sha256 oder höher, das Deaktivieren von „None“ und veralteten Policies, die Abschaltung anonymer Zugriffe, die Isolation vor dem öffentlichen Internet, die Aktivierung des Auditings sowie die kontinuierliche Aktualisierung der eingesetzten Protokoll-Stacks in allen Komponenten. 

Ist OPC UA standardmäßig sicher („Secure by Default“)? 

Das Protokoll selbst ist es gemäß den Analysen des BSI. Viele Endprodukte sind es ab Werk jedoch nicht, da Parameter für Trust-Lists, anonyme Zugänge und Legacy-Policies vom Anwender definiert werden und Produkte teils in permissiven Standardeinstellungen ausgeliefert werden. Eine Einzelfallprüfung der Geräte ist zwingend erforderlich. 

Welche OPC UA Security Policy wird aktuell empfohlen? 

Vorzugsweise Aes256_Sha256_RsaPss oder Aes128_Sha256_RsaOaep, sofern von allen Endpunkten unterstützt, mit Basic256Sha256 als absolutem Mindeststandard. Basic128Rsa15 und Basic256 sind vollständig zu deaktivieren. ECC-Richtlinien sollten vorerst in definierten Pilotumgebungen erprobt werden, bis herstellerseitig eine breite Interoperabilität gemäß Spezifikation 1.05.07 gegeben ist. 

Ist ein anonymer Zugriff technisch vertretbar? 

Ausschließlich dann, wenn die Anwendungsauthentifizierung über Zertifikate strikt erzwungen wird, der Zugriff auf unkritische Nur-Lese-Knoten limitiert ist und die Protokollierung aktiv läuft. Ein anonymer Zugang auf netzwerkseitig exponierten Servern ohne Zertifikatsprüfung stellt ein gravierendes Sicherheitsrisiko dar. 

Wann ist der Einsatz eines Global Discovery Servers (GDS) erforderlich? 

Sobald mehr als eine geringe Anzahl an OPC UA-Applikationen betrieben wird, ist ein GDS oder ein vergleichbares automatisiertes Zertifikatsmanagementsystem erforderlich. Dadurch vertrauen Endgeräte einer zentralen CA anstatt jedem Kommunikationspartner individuell, was kontrollierte Zertifikatswechsel im laufenden Betrieb erst ermöglicht. 

Erfordern die Schwachstellen in Eclipse Milo vom Oktober 2026 eine Abkehr von OPC UA? 

Nein. Erforderlich ist die Identifikation betroffener Produkte mit Milo-Stack, das Anfordern von Hersteller-Updates, die temporäre netzwerkseitige Beschränkung des Zugriffs sowie die zwingende Deaktivierung von Basic128Rsa15, um den primären Angriffsvektor zu eliminieren. 

Können OPC UA-Server sicher im Internet bereitgestellt werden? 

Eine direkte Bereitstellung im Internet wird von den führenden Industrieherstellern strikt abgelehnt. Sofern Fernzugriffe unumgänglich sind, müssen diese stets über VPN-Infrastrukturen oder dedizierte Remote-Access-Systeme mit MFA geführt werden. Der OPC UA-Endpunkt selbst muss innerhalb eines segmentierten Zonenkonzepts geschützt bleiben.