Neue Cybersecurity-Vorgaben treffen die Industrie an einer unangenehmen Stelle: Maschinen, Steuerungen und Servicezugänge sollen immer stärker vernetzt werden, gleichzeitig steigen die Anforderungen an Sicherheit, Nachweisbarkeit und Verantwortung. NIS2, der Cyber Resilience Act, die EU-Maschinenverordnung und IEC 62443 wirken dabei nicht wie ein einzelner sauberer Schalter, sondern wie mehrere Ebenen, die zusammen betrachtet werden müssen.
Die wichtigste Entscheidung lautet deshalb nicht: „Wie erfüllen wir jeden Standard maximal?“ Sondern: Welche Maschinen müssen wirklich vernetzt sein, welches Risiko entsteht dadurch und welche Sicherheitsarchitektur ist wirtschaftlich vertretbar? Für manche Anlagen ist starke Netztrennung die beste Antwort. Für andere braucht es Root of Trust, sichere Updates, Zertifikate, kontrollierten Remote Access und Monitoring.
Warum das Thema jetzt in der Industrie ankommt
In vielen Unternehmen wurden Maschinen über Jahre schrittweise vernetzt: für Fernwartung, Produktionsdaten, Auswertungen, Predictive Maintenance oder bequemere Updates. Das bringt echten Nutzen. Es kann aber auch bedeuten, dass Steuerungen, alte Betriebssysteme oder Servicezugänge plötzlich in einem Risikoraum liegen, für den sie nie gebaut wurden.
Genau hier greifen neue Rechtsakte und Normen ineinander. NIS2 richtet sich an die Sicherheit von Netz- und Informationssystemen in wichtigen und wesentlichen Einrichtungen. Der Cyber Resilience Act nimmt Produkte mit digitalen Elementen stärker in die Pflicht. Die EU-Maschinenverordnung bringt Produktsicherheit und digitale Risiken näher zusammen. IEC 62443 liefert den technischen Rahmen für industrielle Automatisierungs- und Steuerungssysteme.
Das ist komplex, aber nicht nur Last. Wer Maschinenflotten, Remote Service und Sicherheitsnachweise sauber aufbaut, reduziert Ausfallrisiken, kann Vorfälle besser nachweisen und schafft Vertrauen bei Kunden, Partnern und Versicherungen.
Die wichtigsten Regelwerke im Überblick
Die folgende Tabelle ist eine Orientierung mit Stand 23. Juni 2026. Sie ersetzt keine Rechtsberatung, zeigt aber, welche Themen Unternehmen in Österreich, Deutschland, der Schweiz und Liechtenstein im Blick behalten sollten.
NIS2
Kernfrage: Betrieb, Risikomanagement, Meldepflichten und Aufsicht. In der EU national umzusetzen; Österreich nennt die EU-Frist 17. Oktober 2024. In der Schweiz gilt NIS2 nicht direkt, dort ist vor allem die eigene Meldepflicht für kritische Infrastrukturen relevant.
IEC 62443
Kernfrage: Technischer Rahmen für OT-Security, Zonen, Komponenten und Security Levels. Keine allgemeine Gesetzesfrist; praktisch wichtig über Kundenanforderungen, Verträge, Ausschreibungen und den Stand der Technik.
Cyber Resilience Act
Kernfrage: Produkte mit digitalen Elementen, Schwachstellen und sichere Produktentwicklung. Die meisten Pflichten gelten in der EU ab 11. Dezember 2027; für Schweizer Hersteller relevant, wenn sie in den EU/EWR-Markt liefern.
EU-Maschinenverordnung
Kernfrage: Maschinensicherheit und digitale Risiken. In der EU im Wesentlichen ab 14. Januar 2027 anwendbar; außerhalb der EU besonders relevant für Maschinen im EU/EWR-Markt oder in EU-Lieferketten.
Quellen
Quellen für diese Einordnung sind unter anderem die österreichische NIS-Anlaufstelle zu NIS2, die EU-Rechtsakte zu NIS2, Cyber Resilience Act und EU-Maschinenverordnung, die IEC-Seiten zu IEC 62443-3-3 und IEC 62443-4-2 sowie die Schweizer Informationen zur Meldepflicht für Cyberangriffe auf kritische Infrastrukturen.
Für die Praxis heißt das: Nicht jedes Unternehmen ist von jedem Regelwerk gleich betroffen. Aber Maschinenbauer, Betreiber kritischer oder wichtiger Dienste, Zulieferer und Anbieter vernetzter Produkte sollten heute prüfen, welche Pflichten direkt gelten und welche Anforderungen über Kunden, Versicherungen, Ausschreibungen oder Lieferketten auf sie zukommen.
Wie weit muss Maschinensicherheit wirklich gehen?
Der teuerste Fehler ist, sofort eine technische Maximalforderung zu planen, ohne den Nutzen der Vernetzung zu prüfen. IEC 62443 Security Level 3 oder 4 kann je nach System und Risiko sehr anspruchsvoll werden. Bei höheren Anforderungen reicht es oft nicht, nur eine Firewall vor die Maschine zu stellen oder ein Passwort zu ändern.
Wenn eine Maschine aus Safety-Gründen, aus Kundenanforderungen oder wegen ihres Einsatzbereichs ein hohes Sicherheitsniveau erreichen muss, kann Hardware-Level Security nötig werden. Dazu gehören beispielsweise ein TPM, sichere Fuses, ein geschützter Bootprozess oder andere Mechanismen, die Manipulationen am Gerät erkennbar machen und Schlüssel besser schützen.
Diese Technik kostet Geld: in Hardware, Entwicklung, Tests, Zertifizierung, Betrieb und Wartung. Deshalb ist die ehrliche Frage wichtig: Braucht die Maschine diese Vernetzung wirklich? Gibt es einen klaren Business Case für Remote Service, Datenanalyse, laufende Updates oder Predictive Maintenance? Oder wurde die Verbindung nur geschaffen, weil sie bequem war?
Wenn Vernetzung keinen Business Case hat: trennen
Wenn eine alte Maschine keinen wirtschaftlich relevanten Grund hat, mit dem Internet oder einem breiten Unternehmensnetz verbunden zu sein, ist Trennung oft die pragmatischste Sicherheitsmaßnahme. Das kann ein echter Air Gap sein, also keine Netzwerkverbindung, oder eine sehr strenge Segmentierung mit klar kontrollierten Übergängen.
Der Preis dafür ist Bequemlichkeit. Techniker müssen Updates unter Umständen physisch vor Ort einspielen. Daten müssen lokal abgeholt oder über streng kontrollierte Wege übertragen werden. Fernwartung wird schwieriger oder langsamer. Am Ende ist es eine Kosten- und Praktikabilitätsfrage.
Trotzdem kann genau das wirtschaftlich sinnvoll sein. Eine alte Steuerung auf ein modernes, dauerhaft vernetztes Security-Niveau zu heben, kann teurer sein als der Nutzen der Vernetzung. In diesem Fall ist „weniger verbunden“ nicht rückständig, sondern eine bewusste Risikoreduktion.
Wenn Vernetzung nötig ist: sauber aufbauen
Manchmal ist Trennung keine echte Option. Maschinen brauchen Daten aus anderen Systemen, Kunden erwarten Remote Service, Produktionsplanung hängt an aktuellen Zuständen oder Predictive Maintenance spart Stillstand. Dann sollte die Sicherheitsarchitektur nicht nachträglich angeklebt werden.
Der erste Schritt ist eine risikobasierte Einordnung: Welche Funktion darf ausfallen? Welche Daten sind kritisch? Welche Kommunikation ist wirklich nötig? Welche Personen, Systeme und Dienstleister dürfen zugreifen? Daraus entstehen Zonen, Übergänge und Anforderungen an Updates, Identitäten, Protokollierung und Monitoring.
IEC 62443 ist hier hilfreich, weil die Norm nicht nur einzelne Schutzmaßnahmen betrachtet, sondern Rollen, Zonen, Leitungen zwischen Zonen, Systemanforderungen und Komponentenanforderungen. Der praktische Nutzen entsteht aber erst, wenn diese Begriffe in eine konkrete Maschinen- und Betriebsarchitektur übersetzt werden.
Warum alles beim Root of Trust beginnt
Ein Root of Trust ist der vertrauenswürdige Ausgangspunkt eines Systems. Vereinfacht gesagt: Irgendwo muss die Maschine anfangen können zu prüfen, ob sie ihrem eigenen Zustand, ihren Schlüsseln und ihrer Software vertrauen darf. Wenn schon dieser Anfang manipulierbar ist, bauen alle höheren Sicherheitsfunktionen auf Sand.
Darum muss dieser Ausgangspunkt letztlich hardwarebasiert sein. Software kann sehr gut schützen, aber wenn ein Angreifer die darunterliegende Softwareumgebung bereits kontrolliert, kann ein rein softwarebasierter Vertrauensanker ebenfalls manipuliert werden. Hardware kann Schlüssel isolieren, Boot-Schritte messen und Zustände nachweisbarer machen.
Ein TPM ist ein typisches Beispiel für einen solchen Baustein. Wichtig ist aber: Ein TPM ist kein allgemeiner Kryptobeschleuniger für jede Aufgabe. Es ist eher ein geschützter Sicherheitsanker, der Schlüssel, Messwerte und Attestierung unterstützt. Für hohe Datenraten oder moderne Algorithmen kann zusätzlich CPU-Leistung oder ein separater Kryptobeschleuniger nötig sein.
Was auf einem Root of Trust aufbaut
Wenn der Root of Trust sauber geplant ist, lassen sich darauf mehrere wichtige Sicherheitsfunktionen aufbauen:
- Sichere Updates: Die Maschine installiert nur Software, die korrekt signiert ist und aus einem vertrauenswürdigen Prozess stammt.
- Sicherer Start: Beim Booten wird geprüft, ob Firmware, Bootloader und wichtige Softwarebestandteile unverändert sind.
- Zertifikate und Identitäten: Maschinen können eindeutige, besser geschützte Identitäten bekommen, statt dass Passwörter oder gemeinsame Schlüssel verteilt werden.
- Kontrollierter Remote Access: Fernzugriffe können über Zertifikate, Rollen, Protokollierung und zeitlich begrenzte Freigaben gesteuert werden.
- Attestierung: Ein System kann nachweisen, in welchem Zustand es gestartet wurde oder ob bestimmte Sicherheitsmessungen plausibel sind.
Wichtig ist dabei die Lebensdauer. Industrielle Anlagen laufen oft viele Jahre. Die Plattform muss deshalb genug Reserven für zukünftige Kryptografie, neue Zertifikatsanforderungen und sichere Updateprozesse haben. Wer heute zu knapp plant, hat später möglicherweise ein Sicherheitsproblem, das sich nur teuer oder gar nicht beheben lässt.
Monitoring macht Sicherheit sichtbar
Viele Unternehmen investieren in Sicherheitsmaßnahmen, sehen danach aber kaum, ob die Flotte tatsächlich sicherer wird. Genau hier ist Security Monitoring wertvoll. Es macht Zustände, Auffälligkeiten, fehlgeschlagene Logins, Updateprobleme oder ungewöhnliche Kommunikation sichtbar.
Für Betreiber hilft Monitoring, unternehmensweite Probleme früh zu erkennen. Für Hersteller kann es ein zusätzlicher Service sein: Kunden erhalten nicht nur eine Maschine, sondern mehr Transparenz über deren Sicherheitszustand. Für Versicherungen, Sachverständige oder rechtliche Auseinandersetzungen können nachvollziehbare Protokolle ebenfalls relevant werden.
Monitoring ersetzt aber keine Maschinensicherheit. Wenn eine Anlage unsichere Updates akzeptiert, ungeschützte Zugänge hat oder ohne klare Identitäten betrieben wird, kann Monitoring nur begrenzt helfen. Es ist ein Verstärker guter Architektur, kein Ersatz dafür.
Was man von der Automobilindustrie lernen kann
Viele Unternehmen schauen auf die Automobilindustrie, weil dort Cybersecurity, sichere Updates, Steuergeräteidentitäten und Security Engineering schon früher stark in den Entwicklungsprozess gedrückt wurden. Das ist als Orientierung sinnvoll: Fahrzeuge zeigen, wie wichtig sichere Lieferketten, Hardwareanker, Updateprozesse und klare Verantwortlichkeiten werden können.
Man sollte diese Erfahrungen aber nicht blind kopieren. Eine Produktionsmaschine, ein Medizingerät, eine Sondermaschine und ein Fahrzeug haben unterschiedliche Risiken, Lebenszyklen und Geschäftsmodelle. Gute Orientierung heißt: Erfahrungswerte übernehmen, aber die eigene Risikobewertung ernst nehmen.
Meine Empfehlung für den Einstieg
Beginnen Sie nicht mit der Frage nach dem teuersten Sicherheitsbaustein. Beginnen Sie mit einer nüchternen Einordnung Ihrer Maschinen und Verbindungen:
- Welche Maschinen sind mit welchen Netzen verbunden?
- Welche Verbindung hat einen echten wirtschaftlichen Nutzen?
- Welche Anlagen können getrennt oder stärker segmentiert werden?
- Wo sind sichere Updates, Remote Access oder Maschinenidentitäten notwendig?
- Welche Nachweise und Monitoringdaten brauchen Kunden, Betreiber oder Versicherungen?
Ich beschäftige mich mit diesem Thema nicht nur theoretisch. Meine Bachelorarbeit behandelte diesen Bereich, und im Masterstudium kamen Hardware Security, TPMs und verwandte Themen dazu. Genau deshalb ist mir wichtig, technische Begriffe nicht größer klingen zu lassen, als sie sind: Am Ende muss die Lösung zum Risiko, zur Maschine, zum Budget und zur geplanten Lebensdauer passen.
Wenn Sie herausfinden möchten, welche Anforderungen auf Ihre Maschinen, Produkte oder Anlagenflotte zukommen, kann Schiemer Software bei der Einordnung und technischen Planung unterstützen. Schreiben Sie an info@schiemer-software.com. Gemeinsam lässt sich klären, ob Netztrennung reicht, ob ein moderner Security-Aufbau nötig ist und welche Schritte wirtschaftlich sinnvoll sind.
Häufige Fragen
Ist IEC 62443 gesetzlich verpflichtend?
Nicht automatisch für jedes Unternehmen. IEC 62443 ist eine Normenreihe, kein einzelnes Gesetz. Sie kann aber praktisch verpflichtend werden, wenn Kunden, Ausschreibungen, Verträge, Konformitätsbewertungen oder der Stand der Technik darauf Bezug nehmen.
Reicht ein Air Gap als Sicherheitsmaßnahme?
Ein echter Air Gap kann sehr wirksam sein, wenn eine Maschine keine Vernetzung braucht. Er bringt aber Betriebsaufwand: Updates, Datenexporte und Wartung müssen physisch oder über streng kontrollierte Prozesse erfolgen. Außerdem muss geprüft werden, ob der Air Gap wirklich besteht und nicht durch Service-Laptops, USB-Sticks oder Schattenverbindungen umgangen wird.
Warum ist ein TPM kein Kryptobeschleuniger?
Ein TPM ist vor allem ein geschützter Vertrauensanker für Schlüssel, Messungen und Attestierung. Es kann kryptografische Funktionen ausführen, ist aber nicht dafür gedacht, große Datenmengen schnell zu verschlüsseln. Für Performance braucht es je nach Plattform CPU-Reserven oder andere Kryptobeschleuniger.
Muss jede Maschine Vertraulichkeit und Verschlüsselung bieten?
Nicht immer im gleichen Ausmaß. In manchen Fällen ist Integrität wichtiger als Vertraulichkeit: Die Maschine muss sicher wissen, dass Software, Konfiguration und Befehle unverändert sind. Wenn keine sensiblen Daten übertragen werden, kann sich der Schwerpunkt verschieben. Das muss aber aus der Risikobewertung kommen, nicht aus Bauchgefühl.
Was ist der erste sinnvolle Schritt?
Eine Bestandsaufnahme: Welche Maschinen sind vernetzt, warum sind sie vernetzt, welche Risiken entstehen dadurch und welche rechtlichen oder kundenseitigen Anforderungen gelten? Erst danach sollte entschieden werden, ob Trennung, Segmentierung, Hardware Security, sichere Updates oder Monitoring Priorität haben.