Banner E-Learning IT-Sicherheit
Mit <kes>+ lesen

Integrierte Sicherheitsstrategie : Sicher mit Synergie (2) : Wie EU- und UN-Regulatorik hilfreiche Grundprinzipien einer integrierten Sicherheitsstruktur in der Industrie skizziert

Aktuelle Regulierungen können – richtig verstanden – aufgrund ihres konvergierenden Sicherheitsverständnisses als Katalysator für nachhaltig strukturierte und robuste Sicherheitsarchitekturen dienen, die sowohl ein hohes Schutzniveau als auch eine effiziente Compliance ermöglichen. Unsere Autoren verdeutlichen anhand von UN-Regelwerken aus dem Automotive-Bereich sowie dem Cyber-Resilience-Act (CRA) und der EU-Maschinenverordnung (MVO) sowie branchenübergreifender Fallbeispiele, wie funktionale Sicherheit, Cybersecurity, Software-Update-Management und organisatorische Verantwortung zusammenwirken.

Lesezeit 15 Min.

Vernetzte Produkte verändern die Anforderungen an Produkt- und Systemsicherheit grundlegend. Wo Maschinen, Fahrzeuge und technische Systeme zunehmend softwaregesteuert, updatefähig und in komplexe Wertschöpfungsketten eingebunden sind, reicht eine isolierte Betrachtung einzelner Sicherheitsanforderungen nicht mehr aus. Funktionale Sicherheit, Cybersecurity und organisatorische Produktverantwortung greifen immer enger ineinander und müssen in Entwicklung, Betrieb und Nachweisführung gemeinsam berücksichtigt werden.

Der in der Juni-Ausgabe der erschienene erste Teil dieses Beitrags [1] hat die regulatorischen Grundlagen dieser Entwicklung eingeordnet. Im Fokus standen der Cyber-Resilience-Act (CRA, [2]), die EU-Maschinenverordnung (MVO,[3]) sowie die UNECE-Regelungen R155 [4], R156 [5] und R157 [6], die gemeinsame Grundprinzipien einer integrierten Sicherheitsstruktur skizzieren. Cybersecurity wurde dabei als lebenszyklusübergreifender Bestandteil moderner Produktverantwortung verstanden und nicht als isolierte technische Einzelmaßnahme behandelt.

Der vorliegende zweite Teil knüpft daran an und überführt diese Grundprinzipien in die praktische Anwendung: Anhand branchenübergreifender Fallbeispiele wird gezeigt, wie sich aus regulatorischen Parallelen Synergien und belastbare Umsetzungsstrukturen ableiten lassen. Im Mittelpunkt stehen das Zusammenspiel von CRA und MVO am Beispiel einer vernetzten CNC-Fräse sowie die Anforderungen der UN  R157 an hochautomatisierte Fahrfunktionen. Beide Beispiele verdeutlichen, wie eng Organisation und Technik bei der Umsetzung integrierter Sicherheitsstrukturen ineinandergreifen.

CRA und MVO im Duett

Die MVO und der CRA greifen als zwei zentrale europäische Regulierungsvorhaben unterschiedliche Dimensionen der Produktsicherheit auf und führen mechanische Sicherheit und digitale Resilienz erstmals systematisch zusammen. Die MVO fokussiert auf den Schutz von Menschen und Tieren vor mechanischen, elektrischen und systemischen Gefährdungen, die von Maschinen ausgehen können. Der CRA hingegen adressiert digitale Risiken, wie IT-Schwachstellen, Cyberangriffe, manipulierte Updates oder kompromittierte Lieferketten.

Mit zunehmender Digitalisierung überschneiden sich die Anwendungsbereiche beider Regelwerke immer stärker. Für viele Produkte entsteht dadurch eine Doppelbetroffenheit, die Unternehmen vor Herausforderungen stellt – nicht zuletzt bei der Abgrenzung der Anforderungen und der praktischen Umsetzung integrierter Sicherheitskonzepte. Besonders anspruchsvoll ist die koordinierte Zusammenarbeit zwischen IT-Security, Produktentwicklung und Compliance, um sowohl den CRA-Vorgaben als auch den produktsicherheitsrechtlichen Anforderungen der MVO effizient und widerspruchsfrei gerecht zu werden.

Für Hersteller von Maschinen mit digitalen Elementen resultiert daraus eine regulatorische Doppelverpflichtung: Die parallele Integration von CRA und MVO ist nicht länger optional, sondern ab 2027 notwendig für die Rechtskonformität. Eine fragmentierte Betrachtung von funktionaler Sicherheit und Cybersecurity führt unweigerlich zu Mehraufwand, regulatorischen Risiken und Inkonsistenzen. Beide Regelwerke greifen ineinander wie Schloss und Schlüssel und entfalten nur in Kombination ihre volle Funktionalität – ein Balanceakt, der für moderne cyberphysische Systeme (CPS) unverzichtbar ist.

Typische Anforderungen und Überschneidungen

Die Anforderungen aus CRA und MVO weisen in der Praxis zahlreiche Überschneidungen auf – allem voran dort, wo Produkte sowohl physische als auch digitale Komponenten enthalten: Beide Regelwerke fordern ein systematisches Risikomanagement, die frühzeitige Berücksichtigung sicherheitsrelevanter Aspekte in der Entwicklungsphase (Security/Safety by Design) sowie eine durchgängige Dokumentation und Nachweisführung über den gesamten Produktlebenszyklus.

Während der CRA den Fokus stärker auf digitale Risiken wie Schwachstellenmanagement, Updatefähigkeit und den Schutz vor Cyberangriffen legt, adressiert die MVO primär funktionale Sicherheit und den Schutz vor physischen Gefährdungen. In vernetzten Systemen greifen diese Anforderungen jedoch unweigerlich ineinander. Diese Verzahnung hat eine branchenübergreifende Relevanz, gerade dort, wo IT- und OT-Systeme Grenzflächen bilden. Sicherheitsanforderungen sind daher ganzheitlich und integriert umzusetzen, da sowohl technische Ausfälle als auch Cyberangriffe unmittelbare Auswirkungen auf die Betriebssicherheit haben können.

Für die strukturierte Umsetzung bietet sich der Einsatz von Managementsystemen wie eines Informationssicherheits-Managementsystems (ISMS) an. Ein ISMS schafft Transparenz über regulatorische Anforderungen und ermöglicht, diese systematisch aufzuzeigen – etwa durch Risikoanalysen oder kontinuierliche Updateprozesse. Gleichzeitig wird dadurch auch eine Harmonisierung unterschiedlicher Regelwerke erleichtert: Viele Elemente, beispielsweise Lieferkettenkontrollen oder Incident-Response-Strukturen, finden sich in nahezu allen Cybersecurity-Regulierungen wieder und lassen sich über ein ISMS effizient bündeln.

Praxisbeispiele

Industrie- und Produktionsunternehmen sind von der neuen, zunehmenden regulatorischen Vielfalt und den verknüpften Anforderungen in besonderer Weise betroffen, da ihre Produkte eine wachsende Diversität an komplexen digitalen Komponenten besitzen. Maschinen, Anlagen und Produktionssysteme sind softwaregesteuert, miteinander vernetzt, fernwartbar – etwa über „Over the Air“-Updates (OTA) – und tief in übergeordnete IT- und OT-Strukturen eingebunden. Damit fallen sie simultan in den Anwendungsbereich klassischer Safety-Regulierungen und moderner Cybersecurity-Gesetzgebung. Die praktische Umsetzung der Anforderungen erfordert daher weit mehr als punktuelle technische Maßnahmen und verlangt nach einer strukturellen Anpassung von Entwicklungsprozessen, Architekturen und Betriebsmodellen.

Abbildung 1: CRA- und MVO-Umsetzung am Beispiel einer CNC-Fräse

Use-Case: Umsetzung der Richtlinien an einer CNC-Fräse

Der Umsetzungsprozess für den CRA und die MVO lässt sich am Beispiel einer CNC-Fräse praxisnah in drei Schritte gliedern (vgl. Abb. 1): Zunächst ist zu klären, welche regulatorischen Anforderungen gelten. Bei modernen CNC-Fräsen besteht typischerweise eine doppelte Betroffenheit durch beide Regularien, da sie sowohl als Maschine mit potenziellen Gefährdungen als auch als vernetztes Produkt mit digitalen Elementen einzuordnen sind – durch integrierte Software und mögliche Vernetzung ergeben sich zusätzliche Anforderungen, die über die klassische Produktsicherheit hinausgehen.

Anschließend erfolgt die strukturierte Umsetzung der identifizierten Anforderungen durch technische und organisatorische Maßnahmen (TOMs) im Unternehmen. Der konkrete Umfang hängt dabei maßgeblich vom bestehenden Reifegrad sowie bereits etablierten Prozessen ab, sodass eine systematische Analyse der bestehenden Strukturen eine sinnvolle Grundlage für die Umsetzung bildet.

Abschließend sind die organisatorischen Rahmenbedingungen festzulegen. Dazu zählen allem voran klare Zuständigkeiten, definierte Prozesse sowie ein realistischer Zeitplan, um die Anforderungen nachhaltig in die Organisation zu integrieren.

Das Beispiel verdeutlicht insgesamt, dass in der Praxis häufig mehrere Regelwerke gleichzeitig relevant sind und daher eine ganzheitliche Betrachtung über den gesamten Produktlebenszyklus hinweg erforderlich ist. Die Verantwortlichkeiten liegen typischerweise im Bereich Konstruktion/Entwicklung für die MVO sowie im IT- beziehungsweise OT-Security-Bereich für den CRA. Entsprechend sind klare Zuständigkeiten und geeignete Prozesse festzulegen – etwa für Risikobeurteilungen, Schwachstellenmanagement und Software-Updates. Ergänzend sind Schulungen und Sensibilisierungsmaßnahmen erforderlich, um die Umsetzung im Unternehmen zu unterstützen.

Bei der zeitlichen Planung sind die gestaffelten Anwendungsfristen zu berücksichtigen (siehe [1]), sodass eine frühzeitige Umsetzung sinnvoll ist. Insgesamt sind die Anforderungen nicht als einmaliges Projekt zu verstehen, sondern als dauerhafte Konformitätsstruktur, die langfristig in der Organisation verankert werden muss.

Fallbeispiel Automotive: ALKS und UNECE R157

Die zunehmende Automatisierung im Fahrzeugbereich zeigt exemplarisch, wie technische Innovation und regulatorische Anforderungen zusammenwirken müssen, um sichere und verlässliche Systeme im realen Betrieb zu ermöglichen. Besonders deutlich wird dies am Beispiel von einem „Automated Lane Keeping System“ (ALKS), das der Automatisierungsstufe SAE-Level  3 autonomen Fahrens entspricht und damit den nächsten logischen Entwicklungsschritt in der Fahrzeugautomatisierung markiert.

ALKS übernimmt unter klar definierten Betriebsbedingungen die vollständige Fahraufgabe („Dynamic Driving Task“, DDT), typischerweise auf Autobahnen bei begrenzten Geschwindigkeiten und stabilen Umwelt- sowie Verkehrsbedingungen. Der Fahrer bleibt jedoch als Rückfallebene zentraler Bestandteil des Gesamtsystems und muss jederzeit in der Lage sein, die Fahrzeugführung innerhalb eines vorgegebenen Zeitfensters wieder zu übernehmen.

Abbildung 2 zeigt die Einordnung von ALKS innerhalb der fünf Stufen des autonomen Fahrens. Mit dem Übergang zu Level  3 (hochautomatisiertes Fahren) verschiebt sich die Systemverantwortung erstmals signifikant vom Fahrer auf das Fahrzeug, was unmittelbare Auswirkungen auf das Risikoprofil und die rechtliche Verantwortungszuordnung hat – besonders in Situationen an Systemgrenzen oder bei verzögerter beziehungsweise ausbleibender Übernahme durch den Fahrer.

Abbildung 2: Die fünf Stufen des autonomen Fahrens

UN R157 definiert hierfür einen klar strukturierten Anforderungskatalog, der sich in fünf zentrale funktionale und technische Säulen gliedert, und die Grundlage für die Typgenehmigung für ALKS-Systeme bildet:

  • Systemfunktion und Ausfallsicherheit: Das ALKS muss die gesamte operative Fahraufgabe (DDT) innerhalb seiner „Operational Design Domain“ (ODD) vollständig und sicher übernehmen. Die DDT umfasst die Längs- und Querführung sowie die kontinuierliche Wahrnehmung und Interpretation der Verkehrssituation in Echtzeit. Dies umfasst auch die Fähigkeit, relevante Verkehrssituationen kontinuierlich zu erfassen, zu interpretieren und regelkonform wie ein kompetenter menschlicher Fahrer zu reagieren. Das System muss dabei kontinuierliche Selbstüberwachungsfunktionen implementieren, um die Integrität der Fahrzeugführung sicherzustellen. Bei Erreichen von Systemgrenzen oder im Fall einer nicht rechtzeitig erfolgenden Fahrerübernahme ist das Fahrzeug verpflichtet, ein Minimal-Risk-Manoeuvre (MRM) einzuleiten, um einen sicheren Zustand zu erreichen.
  • Mensch-Maschine-Schnittstelle (HMI) und Fahrerüberwachung: Ein zentrales Element von UN R157 ist die klare Definition der Interaktion zwischen Fahrer und System. Das Fahrzeug muss kontinuierlich feststellen, ob der Fahrer verfügbar und übernahmefähig ist. Hierzu werden geeignete Verfügbarkeitskriterien herangezogen, beispielsweise Blickrichtung, Augenaktivität oder physische Interaktion mit dem Lenksystem. Wird eine mangelnde Verfügbarkeit erkannt, muss das System rechtzeitig eindeutige Warn- und Eskalationssignale ausgeben. Im Fall einer notwendigen Übergabe der Fahrzeugkontrolle ist sicherzustellen, dass der Fahrer die Fahraufgabe innerhalb eines definierten Zeitraums übernehmen kann. Gleichzeitig muss das System in der Lage sein, sich bei Fehlfunktionen oder nicht erfüllten Betriebsbedingungen selbstständig zu deaktivieren.
  • Objekt- und Ereigniserkennung: Das ALKS muss die Verkehrsumgebung im definierten Betriebsbereich vollständig erfassen und interpretieren können. Dies umfasst allem voran die kontinuierliche Überwachung der Fahrspuren vor, neben und – innerhalb definierter Systemgrenzen – auch hinter dem Fahrzeug. Die Anforderungen definieren dabei Mindeststandards für die Erkennung relevanter Objekte und Ereignisse in Abhängigkeit von der maximal zulässigen ALKS-Geschwindigkeit. Ziel ist eine robuste Umfeldwahrnehmung, die eine sichere und regelkonforme Fahrweise unter allen zulässigen Betriebsbedingungen ermöglicht.
  • Fahrmodusspeicher: Jedes Fahrzeug mit ALKS muss mit einem „Data Storage System for Automated Driving“ (DSSAD) ausgestattet sein. Dieses System dient der ereignisbasierten Aufzeichnung relevanter Betriebszustände des automatisierten Fahrmodus. Typischerweise werden dabei Informationen gespeichert, die Rückschlüsse auf Systemaktivierung, Deaktivierung, Fahrerübernahmen sowie sicherheitskritische Ereignisse zulassen. Ziel ist die Sicherstellung von Transparenz, Nachvollziehbarkeit und Unterstützung bei der Unfall- und Ereignisanalyse.
  • Cybersecurity und Softwareaktualisierung: Cybersecurity und Software-Update-Management bilden verbindliche Grundpfeiler der Regelung und sind eng mit den UN-Regelungen R155 (Cyber-Security-Management-System, CSMS) und R156 (Software-Update-Management-System, SUMS) verknüpft. Beide Systeme sind essenziell, um die Integrität und Funktionssicherheit des ALKS dauerhaft zu gewährleisten.

Darüber hinaus verlangt die UN R157 ein umfassendes Validierungs- und Nachweiskonzept. Die funktionale Sicherheit des Systems ist durch eine Kombination aus Simulationen, Teststreckenversuchen und realen Straßentests nachzuweisen. Dieses mehrstufige Testframework stellt sicher, dass das System sowohl unter idealisierten als auch unter realitätsnahen Bedingungen robust funktioniert. Insgesamt schafft UN  R157 damit einen regulatorischen Rahmen, der die sichere Einführung von Level-3-Automatisierung in den öffentlichen Straßenverkehr strukturiert ermöglicht.

CSMS/SUMS-Strukturen

Die UN R157 setzt für die Typgenehmigung eines ALKS die Einhaltung der UN R155 und UN R156 voraus – damit werden CSMS und SUMS als verpflichtende Bausteine des automatisierten Fahrens integriert. So wird gewährleistet, dass jedes ALKS-Fahrzeug nur mit etabliertem Cybersecurity- und Software-Update-Rahmen in den Markt gelangt.

Erwartung über formale Anforderungen hinaus

Regulatorische Anforderungen markieren einen verbindlichen Mindeststandard – die Obergrenze wirksamer Sicherheit wird jedoch nicht festgelegt. Entscheidend ist nicht nur die Existenz von Prozessen, sondern die systematische Identifikation und Priorisierung von Risiken sowie die durchgängige Verantwortung über den gesamten Produktlebenszyklus hinweg.

Während die Regelungen UN  R155 und UN R156 diesen Rahmen über Management- und Prozessanforderungen definieren, konkretisiert die UN R157 diese Logik auf Systemebene im Fahrzeug. Der Fokus liegt dabei auf einem überprüfbaren Fahrverhalten im definierten Einsatzbereich sowie auf technischen Nachweisen durch Tests und Validierungen statt auf einer rein dokumentierten Prozesskonformität.

Die Typgenehmigung nach UN R157 basiert zunächst auf einem umfassenden Dokumentationspaket, das durch den Hersteller eingereicht werden muss. Dieses beschreibt das Systemdesign, die Funktionsweise sowie das zugrunde liegende Sicherheitskonzept und enthält eine strukturierte Analyse, wie das System auf potenzielle Gefährdungen reagiert und die Sicherheit innerhalb des definierten Einsatzbereichs gewährleistet. Dabei müssen allem voran Systeminteraktionen, mögliche Fehlfunktionen, kritische Szenarien innerhalb des Betriebsbereichs, Entscheidungslogiken, vorhersehbarer Fehlgebrauch sowie cybersecurityrelevante Risiken berücksichtigt und nachvollziehbar adressiert werden.

Aufbauend auf dieser Dokumentation erfolgt die technische Verifikation durch die Typgenehmigungsbehörde beziehungsweise eine autorisierte Prüfstelle. Diese umfasst sowohl Tests auf abgesperrten Teststrecken als auch Bewertungen im realen Fahrbetrieb, um das Systemverhalten unter normalen Betriebsbedingungen zu überprüfen.

Die Verifikation umfasst zahlreiche szenariobasierte Tests. Im Folgenden werden ausgewählte Beispiele dargestellt:

  • Spurhaltefähigkeit (Lane-Keeping): Stabilität der Fahrzeugführung innerhalb der Fahrspur über verschiedene Geschwindigkeiten und Fahrbahnkrümmungen hinweg
  • Kollisionsvermeidung bei Hindernissen: Reaktion auf stehende Fahrzeuge, Fußgänger, Zweiräder sowie teilweise oder vollständig blockierte Fahrspuren
  • Folgeverhalten (Car-Following): Einhaltung und Wiederherstellung eines sicheren Abstands zu vorausfahrenden Fahrzeugen einschließlich Bremsmanövern bis zum Stillstand
  • einscherende Fahrzeuge (Cut-in-Szenarien): Fähigkeit zur sicheren Reaktion auf Fahrzeuge, die in die eigene Spur wechseln
  • Umfelderkennung (Field of View): Nachweis der Detektionsfähigkeit nach vorne, seitlich und gegebenenfalls nach hinten innerhalb definierter Erfassungsbereiche
  • Systemgrenzen und Übergaben: Verhalten an den Grenzen des Betriebsbereichs sowie Interaktion mit dem Fahrer bei Übergabe der Fahraufgabe
  • Einzelfehler-Simulation (Systemreaktion auf Komponentenfehler): Überprüfung des Systemverhaltens unter simulierten Fehlern einzelner Komponenten durch gezielte elektrische oder mechanische Signalmanipulation, um interne Einzelfehler nachzustellen

Die Verifizierung stellt somit sicher, dass das reale Systemverhalten mit der dokumentierten Sicherheitsargumentation übereinstimmt und die Anforderungen der Regelung nicht nur formal, sondern auch funktional erfüllt werden.

Cybersecurity als Voraussetzung für funktionale Sicherheit

Cyberangriffe, Manipulationen oder unbeabsichtigte Softwareänderungen können sich direkt auf sicherheitsrelevante Fahrzeugfunktionen auswirken. Wenn Cybersecurity lediglich als formale Compliance-Disziplin verstanden wird, besteht allerdings die Gefahr, dass sicherheitskritische Schwachstellen erst im laufenden Betrieb sichtbar werden – das kann zu potenziell hohen finanziellen und reputativen Schäden führen. Eine proaktive und risikobasierte Integration von Cybersecurity in Entwicklungs- und Änderungsprozesse ist daher die Grundlage für robuste Systemarchitekturen, regulatorische Resilienz sowie Vertrauen in automatisierte und vernetzte Fahrzeuge.

Im Zusammenspiel mit funktionaler Sicherheit und systemischer Absicherung entsteht dabei ein mehrschichtiges Sicherheitsparadigma: ISO  26262 „Road vehicles – Functional safety“ bildet den Rahmen für fehlerbasierte funktionale Sicherheit elektrischer und elektronischer Systeme. ISO 21448 „Road vehicles — Safety of the intended functionality“ (SOTIF) adressiert Risiken aus Leistungsgrenzen ohne zugrundeliegende Systemfehler. Ergänzend ermöglicht ISO 34502 „Road vehicles — Test scenarios for automated driving systems — Scenario based safety evaluation framework“ eine szenariobasierte Validierung automatisierter Fahrfunktionen über definierte Verkehrssituationen hinweg.

Dieses integrierte Sicherheitsframework bildet zusammen mit etablierten Cybersecurity-Standards die Grundlage für die Entwicklung sicherer, robuster und regulatorisch konformer automatisierter und vernetzter Fahrzeugsysteme.

Typische Bruchstellen

In der Praxis zeigen sich typische „Bruchstellen“ entlang historisch gewachsener Organisationsgrenzen. Besonders die Schnittstellen zwischen Entwicklung und Homologation (Zulassung), IT-Security und Fahrzeugentwicklung sowie Original-Equipment-Manufacturer (OEM) und Lieferkette sind anfällig für Fragmentierung. Diese Trennung führt zu Inkonsistenzen zwischen iterativer Produktentwicklung und formalen Nachweislogiken, zu einer verspäteten Integration von Cybersecurity in Architektur und Funktionsdesign sowie zu unklaren Verantwortlichkeiten für Software-Updates und das Verhalten sicherheitskritischer Funktionen über Systemgrenzen hinweg. UN  R157 verdeutlicht, dass solche fragmentierten Strukturen mit den Anforderungen softwaredefinierter, sicherheitskritischer Fahrfunktionen nicht vereinbar sind.

Für Hersteller und Zulieferer ergeben sich klare organisatorische Implikationen: Rollen und Verantwortlichkeiten müssen eindeutig und transparent definiert, abgestimmt und verantwortet werden, um Risiken besser entgegenzusteuern und eine nachhaltige ComplianceKonformität zu erzielen.

Typische „Lessons Learned“

Erfolgreiche Organisationen integrieren Cybersecurity frühzeitig und systematisch in ihre Entwicklungs- und Qualitätsprozesse. Dabei werden Risiken, Sicherheitsanforderungen und Updatekonzepte nicht isoliert betrachtet, sondern eng mit funktionaler Sicherheit, Produktmanagement und Betrieb verzahnt.

Dadurch entstehen neue Schnittstellen zwischen Entwicklung, IT, OT, Qualität, Recht und Management. Cybersecurity wird zu einem verbindenden Element zwischen technischen und organisatorischen Ebenen sowie zu einem zentralen Steuerungsfaktor industrieller Wertschöpfung. In der Praxis zeigen sich gleichzeitig die Vorteile technologieoffener Regelwerke, die bewusst Interpretationsspielräume lassen und somit unterschiedliche Implementierungsansätze ermöglichen.

Was die Industrie vom Automotive lernen kann

Egal ob Industrieanlagen, Konsumgüter oder Medizintechnik: Nahezu alle Sektoren sehen sich mit vergleichbaren Herausforderungen konfrontiert, darunter eine zunehmende Systemautomatisierung sowie eine steigende Software- und Vernetzungsrate in Produkten. Mit steigendem Automatisierungsgrad und verringerter direkter menschlicher Interaktion erhält eine integrierte Informationssicherheit einen besonders hohen Stellenwert, da sich potenzielle Angriffe oder Fehlfunktionen nicht mehr durch manuelle Kontrolle frühzeitig abfangen lassen.

Gleichzeitig zeigt der Automotive-Bereich mit UN R157 exemplarisch, dass regulatorische Rahmenwerke bewusst offen gestaltet werden können, um Innovation zu ermöglichen, statt sie zu begrenzen. Sie definieren Sicherheitsprinzipien und Nachweispflichten, innerhalb derer technologische Weiterentwicklung stattfinden kann.

Fazit

Die dargestellten Fallbeispiele verdeutlichen, dass Cybersecurity, funktionale Sicherheit und Produktsicherheit in modernen vernetzten Systemen nicht getrennt betrachtet werden können. Am Beispiel der vernetzten CNC-Fräse wird sichtbar, wie CRA und MVO funktionale Sicherheit und digitale Resilienz zusammenführen. Für Unternehmen entsteht daraus die Aufgabe, regulatorische Anforderungen nicht isoliert abzuarbeiten, sondern in abgestimmte Prozesse, klare Zuständigkeiten und belastbare Nachweisstrukturen zu überführen.

Organisation und Technik sind als gemeinsame Sicherheitsaufgabe zu verstehen. Sowohl im Industrie- als auch im Automotive-Beispiel zeigt sich, dass technische Maßnahmen allein nicht ausreichen. Risikobeurteilungen, Schwachstellenmanagement, Software-Updates, Validierung und Dokumentation müssen organisatorisch verankert und über den gesamten Produktlebenszyklus hinweg gesteuert werden. Entscheidend ist daher das Zusammenspiel von Entwicklung, IT-Security, Compliance, Homologation und Lieferkette.

Der Automotive-Sektor zeigt anhand von ALKS und UN R157 exemplarisch, wie Cybersecurity, SoftwareUpdate-Management und funktionale Sicherheit praktisch ineinandergreifen. CSMS und SUMS bilden dabei die organisatorische Grundlage, während UN  R157 die Anforderungen an Systemverhalten, Fahrerinteraktion und Validierung hochautomatisierter Fahrfunktionen konkretisiert. Daraus lassen sich auch für andere Industrien hilfreiche Grundprinzipien für vernetzte, softwareintensive und sicherheitskritische Produkte ableiten.

Regulierung als Rahmen für sichere Innovation

Das Beispiel hochautomatisierter Fahrfunktionen zeigt zugleich, wie eng regulatorische Anforderungen und technische Weiterentwicklung miteinander verbunden sind: Technologieoffene Regelwerke schaffen einen Rahmen, in dem neue Funktionen sicher entwickelt, geprüft und in den Markt überführt werden können. Regulierung wird damit nicht nur zur formalen Nachweispflicht, sondern zu einem Strukturgeber für robuste, vertrauenswürdige und marktfähige Sicherheitsarchitekturen.

Patrick Smuda ist Project Manager, Dr.-Ing. Wolfgang K. Walter ist Partner im Bereich Informationssicherheit, IT- und Cybersecurity bei der EFS Unternehmensberatung GmbH.

Literatur

[1] Patrick Smuda, Wolfgang K. Walter, Sicher mit Synergie (1), Wie EU- und UN-Regulatorik hilfreiche Grundprinzipien einer integrierten Sicherheitsstruktur in der Industrie skizziert, 2026# 3, S.  20, www.kes-informationssicherheit.de/print/titelthema-kuenstliche-intelligenz-wettlauf-in-angriff-und-verteidigung/sicher-mit-synergie-1/ (<kes>+)

[2] Europäische Union, Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen … (Cyberresilienz-Verordnung), in: Amtsblatt der Europäischen Union L 20. November 2024, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847

[3] Europäische Union, Verordnung (EU) 2023/1230 des Europäischen Parlaments und des Rates vom 14. Juni 2023 über Maschinen …, in: Amtsblatt der Europäischen Union L 165, S. 1, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32023R1230  

[4] United Nations Economic Commission for Europe (UNECE), Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system, UN Regulation R155, März 2021, https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-andcyber-security

[5] United Nations Economic Commission for Europe (UNECE), Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system, UN Regulation R156, März 2021, https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update    

[6] United Nations Economic Commission for Europe (UNECE), Uniform provisions concerning the approval of vehicles with regard to Automated Lane Keeping Systems, UN Regulations R157, März 2021, https://unece.org/transport/documents/2021/03/standards/unregulation-no-157-automated-lane-keeping-systems-alks

Diesen Beitrag teilen: