IEC 62443 Anforderungen & Security Level

Industrielle Anlagen müssen heute nicht nur zuverlässig und effizient arbeiten. Sie müssen auch gegen Cyber-Security-Risiken geschützt werden, und das über viele Jahre, oft mit Komponenten aus unterschiedlichen Generationen und von verschiedenen Herstellern. Die IEC 62443 bietet dafür einen international etablierten Referenzrahmen. Sie beschreibt, wie Betreiber, Integratoren, Dienstleister und Hersteller ihre jeweiligen Beiträge zur Cyber Security industrieller Automatisierungs- und Steuerungssysteme leisten können.[1][2] Dabei geht es nicht um ein einzelnes Produkt und auch nicht um eine pauschale Checkliste. Die IEC 62443 verbindet Organisation, Prozesse, Risikoanalyse, Systemarchitektur, Produktentwicklung und Betrieb über den gesamten Lebenszyklus eines Industrial Automation and Control System (IACS).

Die etablierte Struktur der IEC-62443-Reihe umfasst vier Teile: allgemeine Grundlagen, Policies und Verfahren, Systeme sowie Komponenten. Ergänzend wurden beziehungsweise werden mit den Teilen 5 und 6 Themen wie Security Profiles und Evaluierungsmethoden weiterentwickelt. [2][3][7]

1. IEC 62443-1 – Allgemeines: Begriffe, Konzepte und Modelle.
2. IEC 62443-2 – Policies und Verfahren: Security-Programme und organisatorische Anforderungen.
3. IEC 62443-3 – Systeme: Risikoanalyse, Systemdesign und technische Systemanforderungen.
4. IEC 62443-4 – Komponenten: sichere Produktentwicklung und technische Anforderungen an Komponenten.
5. IEC 62443-5 – Profile: künftige domänenspezifische Profile für die Anwendung der Normenreihe, etwa für bestimmte Branchen oder Anwendungsfälle. Das Verfahren zu ihrer Erstellung ist in IEC/TS 62443-1-5:2023 beschrieben; veröffentlichte Profile der geplanten Teilreihe IEC 62443-5-x liegen derzeit noch nicht vor. [8]
6. IEC 62443-6 – Evaluierung und Konformität: Methoden zur Bewertung und zum Nachweis definierter Anforderungen. Veröffentlicht sind IEC/TS 62443-6-1:2024 (Bewertung gegen 62443-2-4) und IEC/TS 62443-6-2:2025 (Bewertung gegen 62443-4-2).[9][10]

Für viele praktische Fragestellungen stehen insbesondere die folgenden Normteile im Mittelpunkt:

• IEC 62443-3-2: Risikoanalyse und Systemdesign.
• IEC 62443-3-3: technische Systemanforderungen.
• IEC 62443-4-1: sicherer Produktentwicklungsprozess.
• IEC 62443-4-2: technische Anforderungen an Komponenten.

Ein zentrales Konzept der IEC 62443 sind die Security Levels. Sie differenzieren technische Anforderungen anhand unterschiedlicher Bedrohungssituationen und berücksichtigen dabei Mittel, Ressourcen, Fähigkeiten und Motivation eines potenziellen Angreifers.[2][3] Die normativ definierten Security Levels reichen von SL 1 bis SL 4. Neben den definierten Security Levels SL 1 bis SL 4 kann in einem Security-Level-Vektor für einzelne Foundational Requirements auch ein Wert von SL 0 beziehungsweise „kein zusätzliches Schutzniveau“ auftreten:

• SL 1: Schutz gegen zufälligen oder beiläufigen Verstoß.
• SL 2: Schutz gegen einen absichtlichen Verstoß mit einfachen Mitteln, geringen Ressourcen, allgemeinen Fertigkeiten und geringer Motivation.
• SL 3: Schutz gegen einen absichtlichen Verstoß mit ausgefeilten Mitteln, moderaten Ressourcen, IACS-spezifischem Wissen und moderater Motivation.
• SL 4: Schutz gegen einen absichtlichen Verstoß mit ausgefeilten Mitteln, erweiterten Ressourcen, IACS-spezifischem Wissen und hoher Motivation.[4]

Ein Security Level ist jedoch kein pauschales Etikett für eine gesamte Anlage oder jedes einzelne Produkt. Entscheidend ist immer der Kontext: Welche Zone wird betrachtet? Welcher Conduit verbindet sie mit anderen Bereichen? Welche Risiken bestehen? Welche technischen und organisatorischen Maßnahmen sind bereits vorhanden?

In der Praxis werden insbesondere drei Perspektiven unterschieden:

• SL-T – Target Security Level: das angestrebte Security Level für eine Zone oder einen Conduit. Es wird im Rahmen der Risikoanalyse und des Systemdesigns nach IEC 62443-3-2 zugeordnet.[4]
• SL-C – Capability Security Level: die Security-Fähigkeit, die eine Komponente (nach IEC 62443-4-2) oder ein System (nach IEC 62443-3-3) bei geeigneter Konfiguration und Integration bereitstellen kann. SL-C beschreibt das Potenzial des gelieferten Produkts, nicht das im konkreten Betrieb erreichte Ergebnis.
• SL-A – Achieved Security Level: das Niveau, das in der konkreten, integrierten und betriebenen Lösung tatsächlich erreicht wird.[6]

Im Projekt wird geprüft, ob das erreichte Security Level einer Zone oder eines Conduits die festgelegten SL-Targets erfüllt. Dabei werden die Security Capabilities der eingesetzten Komponenten und Systeme ebenso berücksichtigt wie Architektur, Konfiguration, kompensierende Maßnahmen und Betriebsprozesse. Die Bewertung erfolgt im Kontext der jeweils relevanten Foundational Requirements. Ein Zertifikat oder ein Herstellerclaim beantwortet daher nicht automatisch, welches Security Level eine konkrete Anlage im Betrieb erreicht. Architektur, Konfiguration, Prozesse und Nachweise müssen gemeinsam betrachtet werden. Ein Security Level ist nicht immer als einzelner Gesamtwert zu verstehen. Für Zonen und Conduits kann der erforderliche Schutzbedarf je Foundational Requirement unterschiedlich ausfallen. In diesem Fall wird das Security Level als Vektor betrachtet, der beispielsweise für Authentifizierung, Systemintegrität, Datenfluss oder Verfügbarkeit unterschiedliche Niveaus ausweisen kann.[2]

Security Levels beziehen sich auf technische Schutzwirkung und Anforderungen. In bestimmten Teilen und Bewertungszusammenhängen der IEC-62443-Reihe beschreiben Maturity beziehungsweise Protection Levels die Reife beziehungsweise Vollständigkeit organisatorischer und prozessualer Maßnahmen. Ein ausgereifter Entwicklungsprozess ersetzt keine sichere Systemarchitektur. Umgekehrt belegt eine technische Produktfähigkeit nicht automatisch, dass der Entwicklungs- und Pflegeprozess eines Herstellers angemessen beherrscht wird. Beide Perspektiven müssen getrennt bewertet werden.

Die IEC 62443 verfolgt einen risikobasierten Defense-in-Depth-Ansatz. Schutzmaßnahmen werden nicht auf eine einzelne Barriere konzentriert. Mehrere aufeinander abgestimmte Ebenen sollen verhindern, dass ein einzelner Fehler oder eine einzelne Schwachstelle unmittelbar zum vollständigen Sicherheitsverlust führt.[1]

Das Zonen-Conduit-Modell übersetzt diesen Ansatz in eine nachvollziehbare Systemarchitektur:

• Zone: fasst Assets und Funktionen mit vergleichbaren Sicherheitsanforderungen zusammen.
• Conduit: beschreibt eine kontrollierte Kommunikationsbeziehung zwischen Zonen.
• Betrachtungsebene: für jede Zone und jeden Conduit werden Risiken, Anforderungen und geeignete Schutzmaßnahmen bewertet.

Zonen und Conduits sind dabei nicht einfach Synonyme für VLANs oder vorhandene Netzwerksegmente. Die technische Segmentierung sollte aus dem Schutzbedarf, den Funktionen und den Kommunikationsanforderungen des Systems abgeleitet werden.

IEC 62443-4-1: Wie wird ein Produkt sicher entwickelt?

IEC 62443-4-1 beschreibt Anforderungen an den sicheren Entwicklungs- und Pflegeprozess von Produkten. Dazu gehören unter anderem Sicherheitsanforderungen, Security by Design, sichere Implementierung, Verifikation und Validierung, Schwachstellenmanagement, Security Updates und Sicherheitsdokumentation.

Die zentrale Frage lautet: Wie wird ein Produkt entwickelt und über seinen Lebenszyklus gepflegt?

IEC 62443-4-2: Welche technischen Fähigkeiten besitzt eine Komponente?

IEC 62443-4-2 beschreibt technische Sicherheitsanforderungen an IACS-Komponenten, beispielsweise an Embedded Devices, Hosts, Netzwerkgeräte oder Softwareanwendungen.[2][3] Die zentrale Frage lautet: Welche technischen Sicherheitsfunktionen kann die Komponente bereitstellen? Eine Bewertung nach IEC 62443-4-2 ist immer mit dem konkreten Komponententyp, Geltungsbereich, Produktstand und angewendeten Bewertungsschema zu betrachten.

IEC 62443-3-3: Wie wird das Gesamtsystem geschützt?

IEC 62443-3-3 beschreibt technische Systemanforderungen für das jeweils betrachtete IACS beziehungsweise den definierten Systemumfang. Die Anforderungen orientieren sich an den sieben Foundational Requirements, die grundlegend in IEC/TS 62443-1-1 definiert und auf System- (3-3) und Komponentenebene (4-2) ausgeprägt werden:[2]

1. Identifikation und Authentifizierung (IAC)
2. Nutzungskontrolle (UC)
3. Systemintegrität (SI)
4. Datenvertraulichkeit (DC)
5. eingeschränkter Datenfluss (RDF)
6. zeitnahe Reaktion auf Ereignisse (TRE)
7. Ressourcenverfügbarkeit (RA)

Damit verschiebt sich die Perspektive von der einzelnen Komponente auf das Zusammenspiel der gesamten Lösung. Auch ein zertifiziertes Produkt wirkt nur, wenn es passend integriert, konfiguriert und betrieben wird.

Wo eine Komponente eine Anforderung nicht allein erfüllen kann, sind je nach Kontext zusätzliche Maßnahmen auf Systemebene erforderlich, etwa Architekturmaßnahmen, Segmentierung oder organisatorische Kontrollen. Entscheidend ist, dass die Lösung nachvollziehbar geplant, umgesetzt und nachgewiesen wird.

Diese Verantwortungen lassen sich nicht vollständig durch ein Produkt, einen Dienstleister oder ein Zertifikat ersetzen. Cyber Security entsteht an den Schnittstellen zwischen Anforderungen, Architektur, Lieferkette, Integration und Betrieb.

IEC 62443 ist eine internationale Normenreihe und nicht allein deshalb ein allgemeines Gesetz. Verbindlichkeit kann sich jedoch aus Gesetzen, Verträgen, Kundenanforderungen, Ausschreibungen, Zertifizierungsschemata oder internen Vorgaben ergeben. Auch im Zusammenhang mit NIS2, KRITIS oder dem Cyber Resilience Act ist eine klare Abgrenzung notwendig. Diese Regelwerke sind nicht automatisch gleichbedeutend mit einer IEC-62443-Konformität. Der Cyber Resilience Act ist eine eigenständige EU-Verordnung mit eigenen Anforderungen an Produkte mit digitalen Elementen.[5] Ob und wie NIS2, nationale KRITIS-Regelungen oder der Cyber Resilience Act auf eine Organisation, ein Produkt oder eine Anlage anzuwenden sind, hängt vom jeweiligen Anwendungsbereich und der konkreten rechtlichen Einordnung ab.[11] IEC 62443 kann dabei als Referenzrahmen unterstützen, ersetzt aber keine Rechts- oder Konformitätsprüfung.

Die IEC 62443 bringt Betreiber, Integratoren, Dienstleister und Hersteller in ein gemeinsames Modell. Sie hilft, Cyber-Security-Anforderungen aus Risiken abzuleiten, Verantwortlichkeiten zu klären und technische sowie organisatorische Maßnahmen über den Lebenszyklus zu steuern. Der entscheidende Punkt ist nicht, einer Anlage oder einem Produkt möglichst schnell ein Security Level zuzuweisen. Entscheidend ist, ob Schutzbedarf, Architektur, Komponenten, Prozesse und Betrieb zusammenpassen und ob sich die getroffenen Entscheidungen nachvollziehbar nachweisen lassen.

Sie möchten die Anforderungen der IEC 62443 auf Ihre industrielle Umgebung übertragen? Eine strukturierte Analyse hilft, Schutzbedarf, Zonen und Conduits, Verantwortlichkeiten und offene Nachweise zu bestimmen. Der sinnvolle Ausgangspunkt ist dabei immer das konkrete System, nicht ein pauschales Sicherheitslabel.

• [1] IEC – Understanding IEC 62443
• [2] IEC SyC Smart Energy – IEC 62443 (Foundational Requirements, Rollen)
• [3] ISA – ISA/IEC 62443 Series of Standards
• [4] IEC 62443-3-3 – System security requirements and security levels (Security Levels SL 1–SL 4)
• [5] EU – Cyber Resilience Act, Verordnung (EU) 2024/2847
• [6] ISASecure – Certifications Quick Start Guide
• [7] DKE – IEC 62443: Cybersecurity in der Industrieautomatisierung
• [8] IEC – IEC TS 62443-1-5:2023: Scheme for IEC 62443 security profiles
• [9] IEC – IEC TS 62443-6-1:2024: Security evaluation methodology for IEC 62443-2-4
• [10] IEC – IEC TS 62443-6-2:2025: Security evaluation methodology for IEC 62443-4-2
• [11] EUR-Lex – NIS2 Directive (EU) 2022/2555