Cyber Resilience Act (CRA): Was Industriegüter künftig leisten müssen

Der Cyber Resilience Act (CRA) verschiebt Cybersicherheit von einer Best Practice zu einer verbindlichen Produkteigenschaft, die dokumentierbar und auditierbar ist. Für Hersteller bedeutet das: Security wird Teil von Entwicklung, Release, Support und Kommunikation. Betreiber hingegen erhalten mehr Transparenz und Planbarkeit. Wie sich Mitsubishi Electric und weitere Hersteller mit der Thematik auseinandersetzen, erfahren Sie in diesem Beitrag.

Cyber Resilience Act 2026 – Das Wichtigste in Kürze

Der Cyber Resilience Act – Theorie und Praxis

Der Cyber Resilience Act bezieht sich ausdrücklich auf den Lebenszyklus. Damit reicht es nicht, ein Produkt einmal sicher zu entwickeln. Entscheidend sind wiederholbare Prozesse, mit denen Schwachstellen erkannt, bewertet, behoben und kommuniziert werden – und zwar so, dass Betreiber diese Informationen in ihre Anlagen- und Patchplanung übersetzen können.

Während Hersteller die Security in ihren Produkten ausbauen müssen, ergibt sich für Betreiber die Pflicht, Update- und Risikoprozesse im Betrieb so aufzustellen, dass die gelieferten Security-Fähigkeiten tatsächlich wirksam werden.

Was der CRA im Kern fordert – praxisnah übersetzt

Secure by Design heißt in der Automatisierung: Sicherheitsaspekte müssen in Architektur und Entwicklungsprozess hinein – inklusive Threat Modeling, abgesicherter Updatepfade, sauberer Trust-Zonen und konsequenter Minimierung der Angriffsfläche. Viele OT-Systeme laufen jahrelang. Architektur-Entscheidungen (z. B. Update-Integrität oder Rechtekonzept) sind deshalb oft wichtiger als einzelne Security-Features.

Secure by Default bedeutet: Auslieferungszustand und Standard-Konfigurationen dürfen keine unnötigen Risiken erzeugen. Typisch sind restriktive Defaults, minimale aktivierte Dienste, klare Benutzer-/Rollenmodelle und das Vermeiden unsicherer Werkspasswörter. Gerade in heterogenen Anlagen, in denen nicht jede Komponente sofort hart konfiguriert wird, ist der Default-Zustand oft der reale Sicherheitszustand.

Vulnerability Management wird vom Einzelfall zur Pflichtdisziplin: Schwachstellen müssen strukturiert angenommen (z. B. über Disclosure-Kanäle), bewertet (Schweregrad, Exploitability, betroffene Versionen), priorisiert, behoben und in geeigneter Form kommuniziert werden. Betreiber brauchen dabei nicht nur die Info „es gibt ein Update“, sondern eine handlungsfähige Darstellung: Was ist betroffen? Wie kritisch ist es? Gibt es Workarounds? Welche Version fixt? Bis wann wird supportet?

Updates über den Lebenszyklus betreffen die reale Betriebsfähigkeit: Security-Updates müssen verfügbar sein und in der Praxis einspielbar bleiben. Das hängt u. a. von Update-Mechanismen, Dokumentation, Rollback-Sicherheit und klaren Supportzeiträumen ab. Für Betreiber wird damit das Patchen weniger zufällige, sondern planbare Instandhaltung.

Welche Nachweise in der Lieferkette und in Audits wirklich zählen

Der Cyber Resilience Act ist nachweisorientiert. In der Industrie sind besonders diese Artefakte relevant:

• SBOM (Software Bill of Materials): Grundlage, um Abhängigkeiten und betroffene Komponenten bei neuen CVEs schnell zu identifizieren.
• Patch- und Supportprozesse: Dokumentierte Patchpolitik, definierte Supportzeiten, nachvollziehbare Freigaben.
• CVE-/Advisory-Kommunikation: Eindeutige Schwachstellen-Referenzen, Status, Workarounds, Fix-Versionen.
• Update-Integrität: Signaturprüfung und gesicherter Updatepfad – praktisch der Schutz gegen manipulierte Firmware und Software.
• Betriebsdiagnostik: Logging und Exportfähigkeit und nachvollziehbare Ereignisketten für Incident Response.

Diese Nachweise sind für Betreiber nicht nur Compliance, sondern auch operative Hilfe: Sie verkürzen die Zeit von der Meldung bis zur Maßnahme und reduzieren Unsicherheiten in der Lieferkette.

Drei Hersteller-Perspektiven

Rund 29 000 Unternehmen fallen seit Ende 2025 unter erweiterte Sicherheits- und Meldepflichten. Cybersecurity wird laut Mitsubishi Electric ausdrücklich zur Leitungsaufgabe. Damit steigt der Compliance-Druck entlang der industriellen Lieferkette erheblich und ergänzt die Vorgaben des CRA.

Nach Angaben des Branchenverbandes Bitkom zeigen aktuelle Zahlen, wie dringlich die Cybersicherheit ist: Im Jahr 2024 verursachten Cyberangriffe auf industrielle Systeme weltweit Schäden von mehr als 178 Milliarden Euro, das sind 30 Milliarden Euro mehr als in 2023.

Auf den Fachpressetagen 2026, veranstaltet durch RBS Stutensee, war zu spüren, wie sehr die Thematik die Hersteller aktuell beschäftigt. Drei von ihnen stellen wir stellvertretend vor:

Mitsubishi Electric: CRA als auditierbare Resilienz

Mitsubishi Electric beschreibt den Cyber Resilience Act als Rahmen, der Cybersicherheit in Entwicklung, Betrieb und Support zwingend verankert. Auffällig ist der Fokus auf Transparenz und Nachvollziehbarkeit – also genau das, was Betreiber für Auditfähigkeit und Risikoentscheidungen benötigen.

Ein zentrales Element ist ein Product Security Incident Response Team. Kurz PSIRT koordiniert das Schwachstellenmanagement von der Annahme externer Meldungen bis zur Veröffentlichung von Gegenmaßnahmen. Die Rolle als CVE Numbering Authority (CNA) unterstreicht die Absicht, Schwachstellen eindeutig zu kennzeichnen und konsistent zu kommunizieren. Für Betreiber ist das praktisch relevant: CVE-basierte Kommunikation lässt sich in Asset- und Vulnerability-Management-Systemen eindeutig nachverfolgen. „Betroffen/nicht betroffen“ wird prüfbar.

Besonders wirksame CRA Maßnahmen

Technisch betont Mitsubishi Electric Maßnahmen, die in OT-Umgebungen besonders wirksam sind: signierte Firmware-Updates für Integrität, rollenbasierte Zugriffskontrollen als Least Privilege und Monitoring-Konzepte für die Betriebsfähigkeit. Alle Maßnahmen orientieren sich an internationalen Standards wie IEC 62443-4-2 und schaffen eine belastbare Grundlage für Audit und Nachweisführung.

An Produktbeispielen wird diese Logik konkret: Für die neue HMI-Serie GOT3000 zum Beispiel nennt Mitsubishi signierte Updates, restriktive Standard-Konfigurationen und eine rollenbasierte Benutzerverwaltung. Das sind typische Hebel, weil HMIs häufig Schnittstellen nach außen bieten (Web, Remote, USB) und im Betrieb viele Nutzerrollen existieren. Bei SPS-Plattformen wie der Melsec MX-F werden getrennte Engineering- und Betriebsnetze, verschlüsselte Fernzugriffe und definierte Updateprozesse hervorgehoben. Das adressiert den besonders kritischen Angriffsweg über das Engineering.

Für die CRA-Nachweisführung nennt Mitsubishi Electric explizit typische Belege: SBOM, dokumentierte Patchprozesse, Log-Export und die Kommunikation des Supportzeitraums sowie die Offenlegung bekannter CVEs. Das ist keine Nebenbemerkung, sondern Kern der CRA-Mechanik: Security wird über Artefakte und Prozesse belastbar.

Omron: CRA im Zusammenspiel mit der Maschinenverordnung

Omron stellt die CRA-Anforderungen in den breiteren Kontext der europäischen Regulierung: Ab 20. Januar 2027 gilt die EU-Maschinenverordnung 2023/1230. Darin werden digitale Risiken stärker als Bestandteil der Maschinensicherheit verankert. In dieser Sichtweise ergänzt der Cyber Resilience Act die Maschinenverordnung produktseitig. Beide zusammen treiben die Integration von Safety und Security in Richtung systemische Verantwortung.

Als strategisches Grundkonzept betont Omron Defense-in-Depth, also mehrere Schutzschichten, die sich gegenseitig absichern. Für reale Industrieumgebungen ist das oft die pragmatischste Antwort, weil Anlagen heterogen sind im Sinne von Alt- und Neusystemen, mehreren Herstellern, unterschiedlichen Protokollen oder Wartungszugängen. Statt auf eine perfekte Einzelmaßnahme zu setzen, wird das Risiko über Schichten reduziert.

Netzwerksegmentierung und Firewall-Management

Die konkret genannten Bausteine sind genau die üblichen Stellhebel in Automatisierungs-Architekturen:

• Netzwerksegmentierung und Firewall-Management zur Begrenzung von Zugriffsrechten und lateraler Bewegung
• Verschlüsselte Kommunikation via TLS und Zertifikate (z. B. für OPC UA-Serverfunktionen), um Abhören / Manipulation zu erschweren
• Benutzer- und Rollenmanagement, um Konfiguration und Betrieb sauber zu trennen
• Integritätsprüfungen über Hashcodes und Schreibschutzfunktionen gegen unbemerkte Manipulation
• Kontinuierliches Schwachstellen-Management mit transparentem Patchprozess.

Für Betreiber ergibt sich daraus ein sehr praktischer CRA-Readiness-Kern: Wer CRA-konform beschaffen und betreiben will, braucht eine Anlagenarchitektur, in der Segmentierung, Identitäten, Kryptografie und Patchprozesse nicht optional sind, sondern als Normalzustand funktionieren.

Wireless Logic mdex: KI skaliert Social Engineering

Wireless Logic mdex beschreibt weniger die Produkt-Compliance, sondern den Angriffsdruck, der den Cyber Resilience Act in der Praxis zwingend macht, besonders durch KI-gestütztes Social Engineering. Die Kernaussage: Phishing ist nicht mehr plump, sondern wird über KI sprachlich, kontextuell und organisatorisch glaubwürdig. KI imitiert Tonalität, Stil und Kommunikationsmuster, variiert Inhalte automatisch („mass personalized phishing“) und nutzt Anlässe wie Messen oder regulatorische Deadlines als Aufhänger.

Dazu kommen Lernmechanismen wie A/B-Testing für bessere Reaktionsraten und Omnichannel-Kampagnen in Form von E-Mail, SMS, Voice, Social. Diese erhöhen den Druck und sollen Kontrollmechanismen umgehen. Für gezielte Angriffe wird zudem auf Voice-Cloning / Deepfake-Potenziale verwiesen.

Warum das für CRA relevant ist

Warum ist das für den Cyber Resilience Act relevant? Weil viele erfolgreiche Vorfälle nicht mit einer hochkomplexen Schwachstelle starten, sondern mit kompromittierten Identitäten, missbrauchter Fernwartung oder manipulativen Change-Anfragen. CRA-konforme Prozesse wie Patch, Incident, Disclosure funktionieren nur, wenn Organisationen gleichzeitig die menschliche Angriffsfläche adressieren: Wer darf Updates freigeben? Wie werden Identitäten verifiziert? Wie werden Changes dokumentiert und rückgängig gemacht?

Als Gegenstrategie beschreibt Wireless Logic mdex ein Modell aus Abwehren, Erkennen, Reagieren, ergänzt durch regelmäßige Awareness-Schulungen. Technisch liegt der Fokus auf IoT-Umgebungen: IoT-Geräte sind häufig außerhalb klassischer Perimeter, teils unbeaufsichtigt und damit als Einstiegspunkte attraktiv.

In diesem Umfeld wird KI-gestützte Anomalie-Erkennung als Kern genannt: Abweichungen vom Normalprofil wie Datenfrequenz, Datenvolumen, Kommunikation aus anderen Ländern werden erkannt und klassifiziert (z. B. DDoS, MiTM, Device Takeover). Gegenmaßnahmen wie Drosselung oder Isolation können ausgelöst werden.

Ergänzend werden Absicherungsmechanismen im Connectivity-Layer genannt wie z. B. VPN-Schicht, privater APN, dedizierte eUICC-SIMs, um Kommunikationspfade zu härten.

Häufige Fragen