IEC 62443 verstehen: Der Standard für industrielle Cybersicherheit

Vorsicht: Die Normenreihe IEC 62443 ist kein Papiertiger, den man einmal kauft, ins Regal stellt und abhakt. Wer glaubt, mit der Zertifizierung sei man „fertig", hat das Konzept nicht verstanden.

Ich hatte vor ein paar Jahren einen Termin bei einem Mittelständler im Maschinenbau. Der Geschäftsführer zeigte mir stolz das Zertifikat an der Wand – TÜV-geprüft, alles schick. Vier Wochen später hat ein Dienstleister, der per Fernwartung auf die Steuerung zugreifen durfte, eine Ransomware eingeschleppt. Die Produktion stand zwei Wochen. Der Geschäftsführer hat mich danach gefragt, warum die Zertifizierung das nicht verhindert hat. Die Antwort war unangenehm: Weil er nur ein Stück Papier gekauft hat, aber keinen Prozess.

Kurz gesagt: Die IEC 62443 ist die international anerkannte Normenreihe für die IT-Sicherheit industrieller Automatisierungssysteme (IACS). Sie beschreibt nicht nur technische Anforderungen, sondern ein komplettes Lifecycle-Modell – von der ersten Risikoanalyse bis zum sicheren Betrieb im laufenden Werk. Das Gute: Sie funktioniert. Das Schlechte: Sie verlangt mehr Disziplin, als die meisten Unternehmen aufbringen wollen.

IEC 62443: Mehr als nur eine weitere Norm im Regal

Ich habe in den letzten Jahren ein Dutzend Unternehmen bei der Umsetzung begleitet – vom Chemiepark mit 5.000 Messstellen bis zum kleinen Automatisierer mit drei Leuten im Schaltschrank. Und ich habe einen Fehler immer wieder gesehen: Die Verantwortlichen behandeln die 62443 wie eine ISO 9001. Man kauft das Dokument, schreibt ein Handbuch, lässt sich auditieren – fertig.

Falsch. Die Normenreihe lebt von der Unterscheidung der Rollen. Es ist ein himmelweiter Unterschied, ob Sie ein Hersteller von Steuerungen sind, ein Integrator, der Anlagen zusammenbaut, oder ein Betreiber, der die Anlage später fahren muss. Die Teilstandards sind genau darauf zugeschnitten.

Und dann ist da noch der zeitliche Aspekt. Die Normenreihe existiert seit 2009 in Teilen, aber sie ist nie „fertig". Manche Teile sind noch in Arbeit, andere wurden überarbeitet – der Teil 2-1 zum Beispiel wurde 2024 in einer neuen Version veröffentlicht. Wer sich da nicht auf dem Laufenden hält, arbeitet mit einem veralteten Stand und glaubt trotzdem, compliant zu sein. Das ist gefährlicher als keine Norm.

Die Basis: Was ist ein IACS überhaupt?

Die Norm definiert als Zielobjekt die Industrial Automation and Control Systems (IACS). Nicht nur die SPS in der Steuerungsebene, sondern das gesamte Netzwerk aus Sensoren, Aktoren, Leitsystemen und den Verbindungen zur IT-Ebene. Was viele überrascht: Auch die Zones and Conduits gehören dazu – also die Segmentierung des Netzes in Sicherheitszonen mit definierten Übergängen. Der Grundgedanke ist simpel: Nicht alles muss gleich gut geschützt sein, aber jedes System braucht einen definierten Schutzbedarf.

Die Struktur der Normenreihe: Wer macht was?

Hier ein Überblick, den ich mir am Anfang selbst so gewünscht hätte – aufgeteilt in die vier Teile, die für die Praxis wirklich relevant sind. Die Norm kennt vier Hauptgruppen, und es ist entscheidend zu verstehen, dass sich die Anforderungen an Sie als Leser richten:

Teil	Zielgruppe	Kernaussage
62443-1-x (Grundlagen)	Alle Beteiligten	Begriffe, Konzepte, Modelle – das Fundament jeder weiteren Arbeit.
62443-2-x (Prozesse)	Betreiber von Anlagen	Security-Management-Systeme, Richtlinien, Schulungen – der organisatorische Rahmen.
62443-3-x (Technik)	Betreiber & Integratoren	Risikobeurteilung, Systemanforderungen, Security Level – die technische Umsetzung im Werk.
62443-4-x (Produkte)	Hersteller von Komponenten	Anforderungen an die sichere Produktentwicklung und die Eigenschaften der Komponenten selbst.

Warum die Trennung so wichtig ist

Der größte Fehler, den ich in Beratungsprojekten sehe, ist ein falsches Verständnis der eigenen Rolle. Ein SPS-Hersteller, der die Anforderungen aus Teil 2 (Betreiberprozesse) zu erfüllen versucht, scheitert zwangsläufig – und umgekehrt. Der Maschinenbauer, der Teile 3 und 4 anwendet, übersieht die organisatorische Verantwortung seiner eigenen IT-Abteilung.

Ehrlich gesagt: Die Rollendefinition ist der Punkt, an dem viele Projekte kippen. In einem Projekt haben wir drei Monate gebraucht, weil wir uns nicht einigen konnten, wer für die sichere Fernwartung verantwortlich ist – der Hersteller der Maschine, der Integrator der Anlage oder der Betreiber. Die Norm gibt darauf eine klare Antwort: Der Betreiber trägt die Verantwortung für die Security der Anlage, muss aber die Anforderungen an die Zulieferer herantragen.

Security Levels: Die Sprache der Norm lernen

Das Herzstück der technischen Teile sind die Security Levels (SL 1 bis SL 4). Sie beschreiben, wie gut ein System gegen Angriffe geschützt sein muss – von SL 1 (Schutz gegen zufällige oder unbeabsichtigte Verstöße) bis SL 4 (Schutz gegen gezielte, hochprofessionelle Angriffe mit großen Ressourcen).

Ein Beispiel aus meiner Erfahrung: Ein Kraftwerksbetreiber hat für das Leitsystem SL 3 gefordert, weil die Anlage kritisch ist. Aber die Komponenten im Feld, die einfachen Durchflussmesser und Temperatursensoren, wurden mit SL 1 spezifiziert. Das Problem? Diese Sensoren sind über Feldbusse mit dem Leitsystem verbunden. Ein Angreifer, der einen Sensor kompromittiert, hat einen Fuß in der Tür zum Leitsystem. Die Zonierung hat diese Verbindung nicht berücksichtigt.

Die Norm verlangt hier eine detaillierte Risikobeurteilung – nicht irgendeine, sondern eine, die die tatsächlichen Bedrohungen gegen die tatsächlichen Schwachstellen abwägt. Der Target Security Level (SL-T) wird aus der Risikoanalyse abgeleitet, und die erreichten Levels (SL-A) müssen dagegen geprüft werden.

Wie wählt man den richtigen Security Level?

Meine Faustregel nach Jahren der Beratung:

• SL 1: Nicht-kritische Anlagen, die in sich geschlossen sind. Minimaler Aufwand, meistens Standardhärtung.
• SL 2: Anlagen mit Fernwartungszugang, die nicht direkt mit dem Internet verbunden sind. Erhöhte Anforderungen an Zugriffskontrolle und Monitoring.
• SL 3: Kritische Infrastrukturen oder Anlagen mit hohem Schadenspotenzial. Segmentierung, Zonenbildung, durchgängiges Monitoring – hier wird es teuer.
• SL 4: Nur in Ausnahmefällen sinnvoll, weil die Kosten exponentiell steigen und die Verfügbarkeit leidet. Für 95% der Unternehmen ist SL 3 das realistische Maximum.

Ein Fehler, den ich gemacht habe: In einem Projekt für einen Chemiepark habe ich SL 3 als Ziel definiert, ohne die Kosten für die Nachrüstung der Bestandsanlagen zu prüfen. Das Ergebnis war ein sechsstelliger Investitionsplan für eine Anlage, die in fünf Jahren ohnehin ersetzt wird. Der Kunde hat mich zu Recht gefragt, ob das Verhältnis aus Aufwand und Nutzen stimmt. Die Antwort der Norm: Nein, der Security Level muss risikobasiert gewählt werden – und Risiko heißt immer auch: Eintrittswahrscheinlichkeit mal Schadenshöhe. Eine Anlage, die nur noch fünf Jahre läuft, hat ein anderes Risikoprofil als eine Neuinvestition mit 20 Jahren Laufzeit.

Ist die IEC 62443 verpflichtend?

Die kurze Antwort: Es kommt darauf an, in welcher Branche Sie tätig sind. In einigen Bereichen ist die Norm regulatorisch vorgeschrieben – insbesondere für Betreiber von Kritischen Infrastrukturen (KRITIS) wird sie als anerkannter Standard herangezogen. Aber es gibt eine wichtige Einschränkung, die viele überrascht: Es gibt (noch) keine direkte Anwendung von IEC 62443 für KRITIS-Nachweise und -Maßnahmen. Das heißt: Die Norm wird genutzt, um die IT-Sicherheit von Industrieanlagen zu bewerten, aber ein Zertifikat nach IEC 62443 ist nicht automatisch der Nachweis, den die Aufsichtsbehörden verlangen. Diese Nachweise laufen weiterhin über die BSI-Kataloge, ISO 27001 oder branchenspezifische Sicherheitsstandards (B3S).

Was heißt das für Sie? Wenn Sie nicht gerade in einer KRITIS-Branche arbeiten, sind Sie rechtlich nicht verpflichtet, die Norm anzuwenden. Aber die Vertragspraxis holt Sie ein. Ich sehe zunehmend Ausschreibungen, in denen die IEC 62443 als Anforderung genannt wird – nicht als Gesetz, sondern als Nachweis der Lieferfähigkeit. Wer das Zertifikat hat, ist im Vorteil. Wer es nicht hat, muss mit Zusatzfragen rechnen.

Der Blick nach Brüssel

Und dann ist da noch die regulatorische Entwicklung in der EU. Die NIS-2-Richtlinie wird den Druck auf Industrieunternehmen erhöhen – auch wenn sie die IEC 62443 nicht namentlich erwähnt, wird der Nachweis „Stand der Technik" in der Umsetzung oft über die Norm geführt. Der Cyber Resilience Act wird zusätzlich die Anforderungen an Produkthersteller verschärfen. In meiner Einschätzung wird die IEC 62443 in den nächsten Jahren de facto zur Pflicht – nicht wegen eines Paragraphen, sondern weil der Markt es so will.

Welche Cybersecurity-Zertifizierung ist die beste?

Diese Frage bekomme ich ständig – von Geschäftsführern, die einen Haken hinter das Thema machen wollen. Und ich kann sie nicht pauschal beantworten. Die beste Zertifizierung ist die, die zu Ihrem Risikoprofil und zu Ihren Kundenanforderungen passt. Wer ausschließlich IT-Systeme betreibt, ist mit ISO 27001 besser beraten. Wer Produktionsanlagen betreibt oder herstellt, kommt an IEC 62443 nicht vorbei.

Der Unterschied ist fundamental: Die ISO 27001 ist ein Managementsystem-Standard – sie beschreibt Prozesse, aber nicht, wie eine SPS konkret gehärtet werden muss. Die IEC 62443 ist technisch deutlich konkreter. Sie fordert, dass die Sicherheitsfunktionen von Komponenten messbar sind, dass die Netzwerksegmentierung dokumentiert ist und dass die Entwicklungsprozesse des Herstellers einer Prüfung standhalten.

Mein konkreter Vorschlag für die Praxis

Was ich in Projekten als sinnvollen Weg sehe:

• Für den IT-Bereich: ISO 27001 als Basis, weil sie das Management-System etabliert und die Organisation in die Pflicht nimmt.
• Für den Produktionsbereich: IEC 62443-3-2 für die Risikobeurteilung und IEC 62443-3-3 für die technischen Systemanforderungen.
• Für den Einkauf: IEC 62443-4-1 und -4-2 als Anforderung an die Zulieferer. Damit sorgen Sie dafür, dass die Komponenten, die Sie einkaufen, den gleichen Sicherheitsanforderungen genügen wie Ihre eigene Organisation.

Wenn Sie beides kombinieren, sind Sie auf der sicheren Seite. Die Normen widersprechen sich nicht – im Gegenteil, eine saubere ISO 27001-Zertifizierung erleichtert die IEC 62443-Umsetzung, weil viele Prozesse (Asset-Management, Schulungen, Incident Response) identisch sind.

Der Weg zur Zertifizierung: Ein praktischer Leitfaden

Ich will Ihnen hier keinen Projektplan mit 27 Phasen vorsetzen. Stattdessen die vier Stufen, die ich in jedem erfolgreichen Projekt gesehen habe – und die Fehler, die dabei passieren.

Die 4 Stufen zur ersten Zertifizierung

Stufe 1: Das Security Level Assessment. Bevor Sie irgendein Zertifikat anstreben, müssen Sie wissen, welcher Schutzbedarf überhaupt besteht. Eine Risikoanalyse nach Teil 3-2 liefert die Basis. In einem Projekt für einen Lebensmittelhersteller haben wir dabei festgestellt, dass der Schutzbedarf deutlich niedriger war als vermutet – die Anlage war vollständig von der IT entkoppelt, der Schaden bei einem Ausfall begrenzt. Das hat dem Kunden eine sechsstellige Investition erspart. Stufe 2: Die Lückenanalyse. Sie prüfen den Ist-Zustand gegen die Anforderungen des Ziel-Security-Levels. In der Praxis heißt das: Netzwerk- und Systemdokumentation sichten, Zugriffskonzepte prüfen, Patch-Management bewerten. Der Aufwand ist nicht zu unterschätzen – in einem Projekt mit 12 Standorten haben wir allein dafür vier Monate gebraucht, weil die Dokumentation in den Werken unterschiedlich war. Stufe 3: Die Umsetzungsprojekte. Jetzt wird investiert: Segmentierung, Zonenbildung, Härtung der Systeme, Einführung eines Security-Monitorings. Hier scheitern die meisten Projekte, weil der operative Betrieb keine Stillstandszeiten für Sicherheitsmaßnahmen erlaubt. Der Trick: Die Maßnahmen in geplante Wartungsfenster legen und die kritischen Punkte priorisieren. Stufe 4: Das Audit. Die eigentliche Zertifizierung durch eine akkreditierte Stelle. Und genau hier beginnt der Prozess von vorne – die Norm verlangt, dass der Prozess kontinuierlich aufrechterhalten wird. Das Zertifikat hat eine begrenzte Gültigkeit, und Überwachungsaudits sind die Regel. Wer glaubt, mit dem Audit sei die Arbeit getan, wird spätestens beim zweiten Überwachungsaudit unsanft geweckt.

Die häufigsten Fehler bei der Umsetzung

Ich habe genug Fehler selbst gemacht und bei anderen gesehen. Die drei größten Fallstricke sind:

Fehler Nr. 1: Die Norm als reines Dokumentenprojekt behandeln. Ein ehemaliger Kollege hat das komplette Sicherheitskonzept als 200-seitiges Word-Dokument verfasst – das niemand gelesen hat, weil es keine operative Relevanz hatte. Die Norm verlangt gelebte Prozesse, keine Ghostwriter-Arbeit. Fehler Nr. 2: Die Bestandsanlagen ignorieren. Neubauten sind einfach: Die Anforderungen werden in der Ausschreibung festgelegt, der Hersteller liefert. Bestandsanlagen sind der eigentliche Knackpunkt. In einem Chemiepark hatten wir eine Anlage aus den 90er Jahren, bei der die Steuerung nicht einmal über ein modernes Patch-Verfahren verfügte. Die Lösung war nicht die Nachrüstung, sondern eine zusätzliche Segmentierung und ein strikteres Zugriffsregime. Fehler Nr. 3: Die Lieferkette vergessen. Ein Integrator hat mir einmal erklärt, er würde die Norm erfüllen, weil die Steuerungen, die er verbaut, ein 62443-Zertifikat haben. Die Frage, ob seine eigene Engineering-Abteilung die Anforderungen an die Integratoren erfüllt, hat er mit einem Achselzucken beantwortet. Genau das ist die Lücke, die Angreifer nutzen. Die Norm kennt die Rolle des Integrators explizit – und stellt Anforderungen an dessen Prozesse, nicht nur an die Komponenten.

Ein Vergleich: IEC 62443 vs. ISO 27001 in der Praxis

Die beiden Normen werden oft gegeneinander ausgespielt, dabei ergänzen sie sich. Der Unterschied ist nicht Qualität, sondern Anwendungskontext.

Die ISO 27001 ist der Generalist – sie passt für jedes Unternehmen, unabhängig von der Branche. Sie betrachtet die Organisation als Ganzes: Prozesse, Menschen, Technik. Die IEC 62443 ist der Spezialist für die Produktion – sie kennt die Besonderheiten von Steuerungssystemen: hohe Verfügbarkeitsanforderungen, lange Lebenszyklen, Echtzeit-Kommunikation. Genau hier liegt der Mehrwert.

Ich habe einen Betreiber eines Logistikzentrums beraten, der eine ISO-27001-Zertifizierung hatte und glaubte, damit sei die Produktion abgedeckt. Erst als sich ein Angreifer über eine ungesicherte Fernwartungsschnittstelle eines automatisierten Förderbandes Zugang verschafft hat, hat er verstanden: Das ISMS deckt die IT ab, aber nicht die besonderen Anforderungen der Steuerungsebene. Nach dem Vorfall haben wir ein separates Projekt zur Umsetzung der IEC 62443 gestartet – mit dem Ergebnis, dass die Produktionsnetzwerke heute sauber segmentiert sind und die Fernwartung über einen zentralen, überwachten Gateway läuft.

Die Zukunft: Was kommt nach der Norm?

Ich bin kein Prophet, aber ich sehe drei Entwicklungen, die die Bedeutung der IEC 62443 weiter steigern werden. Erstens: Der Cyber Resilience Act wird die Anforderungen an Produkthersteller verschärfen – die 62443-4-x wird dabei zum Maßstab. Zweitens: Die NIS-2-Richtlinie wird den Kreis der betroffenen Unternehmen massiv erweitern – auch Unternehmen, die heute nicht unter KRITIS fallen, werden ihre Lieferketten und Produktionsumgebungen nachweisen müssen. Drittens: Die zunehmende Vernetzung von Produktion und IT – Stichwort Industrie 4.0 – wird die Grenzen zwischen den Sicherheitsdomänen verschwimmen lassen. Wer heute die Grundlagen schafft, kann morgen reagieren.

Die Norm ist nicht perfekt. Sie ist komplex, die Teilstandards sind teilweise noch in Arbeit, und die Umsetzung ist teuer. Aber sie ist der einzige international anerkannte Standard, der die Besonderheiten der industriellen Automatisierung wirklich ernst nimmt. Und das ist mehr, als die meisten anderen Standards von sich behaupten können.

Ich bin gespannt, wie sich die Norm in den nächsten Jahren entwickelt – und ob die Zertifizierung irgendwann zur echten Pflicht wird. Bis dahin gilt: Wer jetzt einsteigt, hat einen Vorsprung. Und der ist mehr wert als jedes Zertifikat an der Wand.