OT Security
Industrial Security: Unternehmen starten CRA- und NIS2-Readiness-Projekte
Kernaussagen
- Industrieunternehmen verbinden CRA-Produktpflichten und NIS2-Organisationspflichten zunehmend in gemeinsamen Readiness-Programmen — getrennte Excel-Listen scheitern an Lieferketten und OT-Realität.
- Ein belastbares Gap Assessment priorisiert Produkte mit digitalen Elementen, kritische OT-Assets und Melde- sowie Konformitätslücken entlang der Wertschöpfung.
- SBOM, Secure-by-Design und IEC 62443 liefern unterschiedliche, aber komplementäre Struktur — nicht austauschbar, aber in einem Architekturboard verzahnbar.
- Hersteller und Integratoren sollten Benannte Stellen und September-2026-Meldepflichten früh einplanen; reine Betreiber fokussieren NIS2-Register und Lieferantensteuerung.
- Readiness ist kein Compliance-Theater: ohne delivery-ready Rollen bleiben Programme auf Folien stehen.
Industrial Security steht 2026 vor einer Doppelbelastung: Der Cyber Resilience Act verschiebt Produkt- und Lieferantenverantwortung, NIS2 verlangt organisationale Resilienz und Meldewesen. Industrieunternehmen — von Maschinenbau über Energie bis zu kritischen Zulieferern — starten deshalb zunehmend CRA- und NIS2-Readiness-Projekte, die beide Welten in einem Steuerungsmodell zusammenführen.
Dieser Artikel beschreibt, wie ein belastbares Readiness-Programm aufgebaut wird: Gap Assessment, SBOM, Secure-by-Design, IEC 62443, OT Security und konkrete Vorbereitung auf die nächsten CRA-Meilensteine. Keine Rechtsberatung.
Warum Industrie anders priorisiert
In OT-Umgebungen kollidieren Verfügbarkeit, funktionale Sicherheit und Cybersecurity. Patches brauchen Wartungsfenster, Altanlagen laufen Jahrzehnte, Fernwartung ist wirtschaftlich unverzichtbar — und zugleich Angriffsvektor. Wer CRA nur als „IT-Thema“ behandelt, übersieht, dass Steuerungen, Gateways und Engineering-Workstations Produkte mit digitalen Elementen sind oder solche enthalten.
Gleichzeitig trifft NIS2 viele Betreiber in Energie, Transport, Fertigung und digitaler Infrastruktur. Die Schnittstelle ist offensichtlich: Ein kompromittiertes Update-Modul ist CRA-Produktproblem und NIS2-Vorfall. Unser OT-Security-Lagebild zeigt, warum delivery-ready Teams hier entscheidend sind.
Readiness-Programm: Struktur in vier Phasen
Phase 1 — Scope und Betroffenheit
Zuerst klären: Hersteller, Importeur, Betreiber oder Kombination? CRA-Pflichten hängen von der Rolle in der Wertschöpfunke ab; NIS2 von Sektor und Größe — siehe NIS2-Umsetzung.
Parallel: Portfolio aller Produkte mit digitalen Elementen — Hardware, eingebettete Software, Fernwartungsportale, Edge-Gateways. OT-Assets nach Kritikalität und Konnektivität klassifizieren.
Phase 2 — Gap Assessment
Ein wirksames Gap Assessment vergleicht Ist-Zustand mit CRA-Anhang-I-Anforderungen, geplanten harmonisierten Normen, IEC-62443-Zielzonen und NIS2-Maßnahmenkatalog. Typische Lücken:
- fehlende SBOM-Pflege in der Entwicklung,
- unscharfe Support-Enddaten für Feldgeräte,
- getrennte Incident-Prozesse für IT, OT und Produktsecurity,
- Verträge ohne Update- und Schwachstellenklauseln bei OEMs.
Gap Assessment — Prioritätsmatrix
- Hoch / kurzfristig: Meldepflichten ab September 2026, kritische Produktklassen, internetexponierte OT.
- Hoch / mittelfristig: Konformitätsmodule für wichtige Produkte, Benannte Stellen.
- Mittel: IEC-62443-Zonen-Nachschärfung, Lieferantenregister.
- Strukturell: gemeinsame Governance-Boards für CRA, NIS2 und Safety.
Phase 3 — Umsetzungspakete
Readiness-Projekte sollten in Pakete schneiden, die Engineering liefern kann:
- Secure-by-Design / Secure-by-Default in Produktlinien und Retrofit-Richtlinien,
- SBOM-Toolchain in CI/CD und Zulieferer-Onboarding,
- Schwachstellen-Inbox mit 24h/72h-Eskalation Richtung ENISA-Plattform,
- OT-Segmentierung und Wartungszugänge nach IEC-62443-Logik — vertieft in IEC 62443 und Recruiting.
Phase 4 — Evidenz und Auditfähigkeit
Technische Dokumentation, Konformitätserklärungen, Risikoregister und Protokolle sicherheitsrelevanter Änderungen müssen versioniert vorliegen — nicht erst vor Kundenaudits zusammensuchen. Für CRA-Kontext lohnt der Abgleich mit den Leitlinien zur CRA-Umsetzung.
SBOM in der industriellen Lieferkette
Das BSI beschreibt die Software Bill of Materials als Zutatenliste der Software — maschinenlesbar, für Schwachstellenhandling genutzt, ohne Veröffentlichungspflicht. In Industrieprojekten ist die SBOM oft der erste harte Test der Lieferkette:
- Bekommen Sie SBOMs von OEM-Komponenten vertraglich?
- Fließen Firmware-Stacks aus Drittländern in Ihre Produkt-SBOM?
- Wer pflegt Updates, wenn der Komponentenhersteller den Support beendet?
Ohne SBOM-Disziplin wird CRA-Meldepflicht zum Blindflug.
IEC 62443 und CRA: komplementär, nicht doppelt
IEC 62443 strukturiert Rollen, Zonen und Conduit-Modelle in industriellen Automatisierungssystemen. Der CRA definiert Marktzugangspflichten für Produkte mit digitalen Elementen. Ein sinnvolles Readiness-Modell mappt Anforderungen:
| Thema | IEC 62443 | CRA |
|---|---|---|
| Architektur | Zonen / Conduits | Secure by Design |
| Komponenten | SL-Ziele | SBOM, Konformität |
| Betrieb | Patch under change control | Support, Updates |
| Vorfälle | Prozessintegration | Meldeplattform ENISA |
Konflikte entstehen, wenn Safety-Freigaben und Security-Patches unkoordiniert bleiben — ein Governance-Thema für Vorstand und Werkleitung, siehe Cybersecurity Governance 2026.
OT Security: operative Baustellen
Typische OT-Baustellen in Readiness-Projekten:
- Asset-Transparenz: unvollständige Inventare von SPS, HMI, Gateways,
- Fernwartung: Ad-hoc-VPNs statt kontrollierter Jump-Server,
- Identitäten: geteilte Engineering-Accounts,
- Monitoring: IT-SOC ohne OT-Protokollverständnis.
Priorisieren Sie Maßnahmen mit direkter Betriebswirkung — nicht nur Compliance-Dokumente.
Mini-Checkliste: CRA-Vorbereitung für Industrie
Produkt-RACI je Vertriebskanal (Hersteller/Importeur/Händler) dokumentieren.
Melde-Playbook mit ENISA-Plattform-Schnittstelle bis Q3 2026 testen.
Top-10-OEM-Verträge auf Update-, SBOM- und Incident-Klauseln prüfen.
Benannte Stelle identifizieren, falls wichtige/kritische Produktklassen betroffen — Thema ab Juni 2026.
NIS2-Vorbereitung parallel
Readiness ohne NIS2 ist halb. Für betroffene Betreiber:
- BSI-Registrierung und Risikomanagement — Registrierungsfrist,
- einheitliche Incident-Faktenbasis für SOC, OT und Produktsecurity,
- Geschäftsleitungs-Schulung und Nachweislogik.
CRA-Meldungen und NIS2-Meldungen können sich überschneiden — ein Ticketmodell spart Zeit und Haftungsrisiko.
Personal und Programme
Readiness-Projekte scheitern selten an fehlenden Slides, sondern an fehlenden Hybridprofilen: OT-Security, Product Security, Compliance Engineering. Der Fachkräftemarkt ist angespannt — siehe IT-Fachkräftemarkt KRITIS. Frühe Bindung schlägt Rettungs-Headhunting vor Zertifizierungsfenstern.
Fazit
CRA- und NIS2-Readiness-Projekte in der Industrie brauchen ein gemeinsames Steuerungsmodell: Gap Assessment über Produkt und OT, SBOM und Secure-by-Design in der Entwicklung, IEC 62443 in der Betriebsarchitektur, Melde- und Konformitätspfad ab 2026. Wer beide Regime getrennt plant, zahlt doppelt — wer sie verzahnt, gewinnt operative Resilienz und auditfähige Lieferketten.
Weiterführend: EU CRA für Unternehmen, Cyber-Resilienz-Grundlagen. Besetzung: Cybersecurity Recruiting.
Quelle
Bundesamt für Sicherheit in der Informationstechnik — Cyber Resilience Act
Häufige Fragen
- Zwei Workstreams an der Schnittstelle Produkt vs. Organisation — aber eine gemeinsame Datenbasis für Lieferanten, Schwachstellen und Incidents. Sonst entstehen widersprüchliche Prioritäten zwischen Werk und Konzern-IT.
- IEC 62443 strukturiert industrielle Cybersecurity hervorragend, ersetzt aber nicht CRA-Konformität oder NIS2-Meldelogik. Synergien gibt es bei Rollen, Segmentierung und Lieferantenanforderungen — formale Mapping-Tabelle ist Pflicht.
- OT-Security-Architektinnen, Product Security mit Firmware-Verständnis und Regulatory Engineers, die CRA-Module und IEC-Zonen verbinden. Genau hier unterstützt Perfomynd mit outcome-basierten Suchprofilen.