4/5 Regularien im Griff: Wenn Vorschrift Verantwortung fordert

1 – 2 – 3 – 4 – 5

Vielleicht erscheint es im ersten Moment abwegig, sich im Umfeld der Embedded Systeme und deren Firmware mit Regularien zu beschäftigen – früher oder später stellen sie aber relevante Aspekte dar. Nicht nur steigt die Anzahl an Normen und Vorschriften, auch die Einhaltung wird immer schärfer eingefordert und überwacht.

Regulatorische Landschaft: Safety, Security und Maschinenverordnung

Embedded-Systeme bewegen sich in einem Spannungsfeld technischer Anforderungen und gesetzlicher Auflagen. Dabei wirken unterschiedliche Regulierungsstränge zusammen – mit jeweils eigenem Fokus, rechtlicher Bindung und branchenspezifischer Reichweite. Die große Herausforderung besteht darin, diese Normen nicht isoliert, sondern im Zusammenspiel zu verstehen.

• Funktionale Sicherheit (FuSa, ISO 26262¹): Diese Norm wurde für die Automobilindustrie entwickelt und adressiert das Risiko zufälliger Fehlfunktionen in sicherheitskritischen Systemen. Sie definiert ein mehrstufiges Safety-Lifecycle-Modell, von der Konzeptphase bis zur Decommissioning-Strategie. Das Ziel ist es, die Integrität von Sicherheitsfunktionen unter normalen wie fehlerhaften Bedingungen zu gewährleisten.
• SOTIF (ISO 21448): Die Norm „Safety of the Intended Functionality“² ergänzt ISO 26262 und behandelt Risiken, die nicht aus Fehlern, sondern aus unzureichender Leistung³ resultieren – etwa bei unvollständiger Objekterkennung in automatisierten Fahrsystemen. Sie adressiert auch Unsicherheiten in Umgebungswahrnehmung und Machine-Learning-Modellen. SOTIF ist damit besonders relevant für moderne Fahrerassistenzsysteme und autonome Funktionen. Weiterhin adressiert SOTIF Sicherheitsrisiken, die sich aus unvorhergesehenem Gebrauch bis hin zu Missbrauch durch den Nutzer ergeben.
• Cybersecurity (ISO/SAE 21434, UNECE R155): Diese Regelwerke definieren Anforderungen an das Management von Cyberrisiken über den gesamten Fahrzeuglebenszyklus hinweg – von der Bedrohungsanalyse über die Absicherung technischer Schnittstellen bis hin zu Update-Prozessen und Vorfallmanagement. Die Cybersecurity behandelt somit einen unberechtigten Eingriff in das System durch Dritte. Während ISO/SAE 21434 als technische Norm strukturiert ist, verlangt UNECE R155 regulatorisch ein Cybersecurity Management System (CSMS) als Voraussetzung für Typzulassungen in der EU.
• Maschinenverordnung (EU 2023/1230): Diese neue Verordnung der Europäischen Union ersetzt die bisherige Maschinenrichtlinie und hebt die Rolle von Software und Cybersecurity explizit hervor. Hersteller müssen Risiken, die aus digitalen Komponenten und unsicheren Softwarekonfigurationen entstehen, systematisch bewerten und dokumentieren. Die Verordnung gilt ab 2027 verpflichtend für alle Hersteller, Importeure und Betreiber innerhalb der EU.

Die Komplexität entsteht nicht nur durch die Anzahl der Normen, sondern durch ihre teilweise überlappenden Zuständigkeitsbereiche.

Während ISO 26262 auf zufällige E/E-Fehler⁴ fokussiert, adressiert ISO/SAE 21434 gezielte Angriffe. Beide können sich jedoch auf dieselbe Steuerungseinheit beziehen – und müssen daher im Engineeringprozess abgestimmt werden.

Hinzu kommt: Die Normen entfalten ihre Wirkung international unterschiedlich stark.

In Europa sind viele Anforderungen regulatorisch bindend⁵, werden sie in anderen Regionen primär durch Produkthaftung, Marktanforderungen oder freiwillige Selbstverpflichtung getrieben.

Für global agierende Unternehmen entsteht daraus ein anspruchsvolles Compliance-Szenario, das ein tiefes Verständnis der jeweils relevanten Normenlandschaft erfordert.

Schnittmengen und Priorisierung: Wenn Safety auf Security trifft

Safety und Security beeinflussen sich gegenseitig: Eine manipulierte Software kann sicherheitskritische Funktionen aushebeln, ein sicher ausgelegtes System kann durch fehlende Security unbrauchbar werden. In der Praxis gilt: „Security first“ bei sicherheitsrelevanter Steuerung – denn ein angegriffenes System kann keine Safety garantieren.

Das Prinzip „Ober schlägt Unter“ bedeutet konkret: Cybersecurity kann Sicherheitsfunktionen overrulen – und muss deshalb auch regulatorisch priorisiert werden. Sicherheitsfunktionen verlieren ihren Wert, wenn ihre Steuerpfade kompromittiert wurden.

• Safety schützt vor ungewolltem Verhalten – Security vor gewolltem Missbrauch: Funktionale Sicherheit (z.B. nach ISO 26262) adressiert zufällige Fehlerzustände. Security (z.B. ISO/SAE 21434) schützt vor absichtlicher Manipulation. Beide Domains verfolgen dasselbe Ziel – Systemintegrität –, aber aus unterschiedlichen Perspektiven.
• Ein kompromittiertes System kann keine Safety garantieren: Wenn ein Angreifer Zugriff auf die Kommunikationspfade, Speicherbereiche oder Steuerungslogik eines Systems erhält, sind selbst redundant ausgelegte Sicherheitsfunktionen nicht mehr verlässlich. Die Safety-Absicherung verliert ihre Aussagekraft, wenn die darunterliegende Schicht (Security) nicht intakt ist.
• Das ISO/SAE 21434-Framework erkennt diese Hierarchie explizit an: In der Cybersicherheitsnorm für Kraftfahrzeuge wird die Notwendigkeit betont, Cybersecurity-Managementprozesse nicht nur parallel, sondern integriert mit Safety-Aktivitäten umzusetzen. Eine Sicherheitsanalyse ohne Berücksichtigung potenzieller Angriffe bleibt unvollständig.
• Das Prinzip der kontrollierten Kaskade: Sicherheitskonzepte müssen schichtweise wirken – vergleichbar mit einem Sicherheitszwiebelmodell. Die äußeren Schichten (z.B. Perimeterschutz, Authentifizierung, Verschlüsselung) verhindern, dass Bedrohungen überhaupt zu den inneren, Safety-relevanten Funktionen durchdringen können. Sind diese äußeren Schichten durchlässig, nützt selbst die robusteste Safety-Architektur im Inneren nichts.

In regulatorischer Hinsicht ergibt sich daraus eine klare Konsequenz: Cybersecurity muss nicht nur ein begleitender Aspekt, sondern eine verbindliche Voraussetzung für Safety-Zulassungen sein. Prüfprozesse und Zertifizierungen, die Safety unabhängig von der Systemhärtung bewerten, greifen zu kurz – insbesondere in hochvernetzten Systemen.

Auch in der Praxis stellt sich zunehmend die Frage: Welche Sicherheitsfunktionen sind im Ernstfall noch vertrauenswürdig – und welche wurden möglicherweise bereits kompromittiert?

Die Reaktionsstrategien auf Systemfehler müssen deshalb Security-Verdachtsfälle mitdenken. „Safe State“ bedeutet nicht nur funktional sicher – sondern auch: frei von Manipulation.

Die Normenlandschaft beginnt, diese Sichtweise zu reflektieren – doch in der Umsetzung bleibt sie oft fragmentiert. Das Prinzip „Ober schlägt Unter“ muss künftig stärker operationalisiert werden: in Form von integrierten Analysemodellen, abgestimmten Auditverfahren und expliziten Wechselbeziehungen in der Dokumentation sicherheitsrelevanter Funktionen.

Kurzum: Wer Safety garantieren will, muss Security kontrollieren.

Regelwerke, Branchen, Regionen

Die Anwendung regulatorischer Vorgaben variiert erheblich in Abhängigkeit von Branche, Produktkategorie und regionalem Rechtsrahmen. Dabei ist nicht nur der inhaltliche Fokus unterschiedlich, sondern auch das Maß an Verbindlichkeit, Prüfungsintensität und Durchsetzungskraft.

• Medizintechnik: Hier gelten die Vorgaben der IEC 62304 für den Lebenszyklus von Medizinsoftware. Ergänzt wird dies durch regulatorische Leitlinien wie die FDA Guidance on SBOMs, die seit März 2023 verbindlich eine Software Bill of Materials für Zulassungen medizinischer Geräte in den USA verlangt. Ziel ist die transparente Nachverfolgbarkeit aller eingesetzten Softwarekomponenten und damit ein proaktiver Umgang mit Sicherheitslücken.
• Automotive: In der Automobilbranche gelten besonders strikte Sicherheitsanforderungen. Die funktionale Sicherheit wird durch ISO 26262 geregelt. Ergänzt wird sie durch ISO/SAE 21434, die als spezifische Cybersecurity-Norm sicherstellt, dass Bedrohungen systematisch analysiert und adressiert werden. Die UNECE R155 wiederum verpflichtet OEMs zu einem dokumentierten Cybersecurity Management System als Voraussetzung für die Typzulassung von Fahrzeugen in Europa.
• Industrielle Anlagen: Die funktionale Sicherheit wird durch IEC 61508 geregelt – eine sektorübergreifende Basissicherheitsnorm für elektrische/elektronische Systeme. Zusätzlich gelten branchenspezifische Ergänzungen (z.B. IEC 62061 für Maschinen oder IEC 61511 für Prozessleittechnik). Im EU-Raum ist zudem die neue Maschinenverordnung EU 2023/1230 zu beachten, die Anforderungen an Software und Cybersecurity erstmals explizit formuliert.
• Kritische Infrastrukturen: In der EU wird die Cybersicherheit durch die NIS2-Richtlinie geregelt, die ab 2024 weitreichende Pflichten für Betreiber kritischer Dienste etabliert – u.a. zur Risikoanalyse, zu Vorfallmeldungen und zur Kontrolle der Lieferkette. Ergänzt wird dies durch den geplanten Cyber Resilience Act, der verpflichtende SBOMs, Sicherheitsupdates und Schwachstellenmanagement auch für Hersteller digitaler Produkte fordert.

Diese Vielfalt bringt Herausforderungen mit sich: Während einige Normen branchenspezifisch und hochdetailliert sind (z.B. ISO 26262 im Automotive-Bereich), bleiben andere absichtlich technologieneutral (z.B. NIS2), um eine breitere Anwendbarkeit zu gewährleisten. Zudem unterscheiden sich Regionen in der Umsetzung deutlich: Während die EU auf gesetzlich bindende Verordnungen mit Kontrollinstanzen setzt, dominieren in den USA regulatorische Guidance-Dokumente und Haftungsanreize.

Für international tätige Hersteller bedeutet dies: Compliance ist nicht universell – sie muss kontextsensitiv, produktbezogen und regionsspezifisch organisiert werden. Nur so lassen sich Haftungsrisiken, Zulassungshürden und Reputationsverluste systematisch vermeiden.

Tagging von CVEs: Normbezug für die Praxis

Ein praktikabler Ansatz zur Orientierung im Schwachstellenmanagement wäre die Erweiterung von CVE-Einträgen um normative Referenzen – also das Tagging nach potenziell betroffenen Regelwerken. Derzeit listen CVEs (Common Vulnerabilities and Exposures) Schwachstellen auf Ebene von Softwarekomponenten, Bibliotheken oder Protokollen. Doch sie sagen nichts darüber aus, in welchem regulatorischen Kontext eine Schwachstelle relevant ist.

Ein Beispiel: Eine CVE in einer vernetzten Kommunikationsbibliothek, die in der Steuerung eines Fahrzeugs zum Einsatz kommt, könnte Auswirkungen auf:

• die funktionale Sicherheit nach ISO 26262,
• die Cybersecurity-Anforderungen nach ISO/SAE 21434,
• sowie die regulatorische Zulassung gemäß UNECE R155

haben – je nach Integrationstiefe und Systemkontext.

Derzeit ist diese Einordnung manuell und interpretationsbedürftig. Hersteller und Zulieferer müssen sich mühsam durch CVE-Beschreibungen, CVSS-Scores und Patchhinweise arbeiten, um mögliche Relevanzen für Sicherheitsanforderungen zu erkennen. Dabei wäre ein strukturiertes „CVE-to-Norm-Mapping“ ein effektiver Hebel für:

• kontextsensitive Priorisierung: Schwachstellen, die Safety- oder Zulassungsnormen tangieren, müssen sofort bewertet und behandelt werden – auch wenn ihr technischer CVSS-Score moderat ist.
• Zulassungs- und Auditfähigkeit: Bei Homologationsprozessen nach UNECE R155 oder im FDA-Zulassungsverfahren für Medizingeräte können gezielt relevante CVEs dokumentiert werden – mit Bezug zur jeweiligen Norm.
• Erleichterung für Entwickler und Security-Officers: Der Rückschluss von einer technischen Schwachstelle auf die betroffenen Normen beschleunigt Entscheidungsprozesse und verbessert die Compliance.

Ansätze wie das VEX-Format (Vulnerability Exploitability eXchange) gehen bereits in diese Richtung. Sie ergänzen CVEs um Kontextinformationen zur tatsächlichen Ausnutzbarkeit im konkreten System. Ein zusätzlicher Layer könnte normrelevante Risiken kennzeichnen – etwa durch ein Schema wie:

CVE-2023-XYZ | Norm-Tag: ISO26262, R155, FDA-SBOM

Langfristig könnten solche Erweiterungen in öffentliche Schwachstellendatenbanken wie die NVD (National Vulnerability Database) oder die EUVD (European Union Vulnerability Database) integriert werden. Auch für branchenspezifische Plattformen – z.B. CERTs, OEM-Portale oder Herstelleradvisories – wäre eine Normverknüpfung ein erheblicher Mehrwert.

Fazit: CVEs beschreiben Symptome – doch das regulatorische Risiko ergibt sich erst durch Kontext. Norm-Tags könnten diesen Zusammenhang systematisieren – und Sicherheitsverantwortung von der Interpretation zur strukturierten Bewertung weiterentwickeln.

Homologation: Wenn Prozesse von Unbekanntem überholt werden

Zulassungsprozesse – etwa die Typgenehmigung nach UNECE R155 oder branchenspezifische Normprüfungen wie ISO/SAE 21434 oder IEC 61508 – verlangen umfangreiche Dokumentation, Prüfberichte und Sicherheitsnachweise. Hersteller müssen nachweisen, dass ihr Produkt unter Berücksichtigung aller bekannten Bedrohungen entwickelt, abgesichert und validiert wurde. Auch der „Control of Residual Risk“ – also der Umgang mit bekannten, aber nicht eliminierten Risiken – muss klar belegt sein.

In der Theorie entsteht so ein nachvollziehbarer Sicherheitsnachweis, der Behörden, Kunden und Prüforganisationen Vertrauen vermitteln soll. In der Praxis aber wird dieses System zunehmend durch eine dynamische Realität überfordert:

• Neue Schwachstellen entstehen laufend – auch nach Zertifizierung: Angriffsvektoren, Exploits und Schwachstellen entstehen in hoher Frequenz. Ein Produkt, das heute als „sicher“ gilt, kann morgen bereits verwundbar sein – selbst ohne jede Änderung am Code. Besonders in global vernetzten Embedded-Umgebungen genügt eine neu entdeckte Schwachstelle in einer Drittbibliothek, um ein gesamtes System rückwirkend angreifbar zu machen.
• Zulassungsprozesse sind statisch – Bedrohungen dynamisch: Die heute üblichen Zertifizierungen sind Momentaufnahmen. Sie dokumentieren einen definierten Entwicklungsstand – aber keine nachhaltige Überwachung. Es fehlt an Mechanismen zur Post-Zertifizierungs-Überprüfung, obwohl neue CVEs, technologische Veränderungen oder Verschärfungen von Regulierungen täglich auftreten.
• Hoher Dokumentationsdruck kollidiert mit agilen Entwicklungspraktiken: Homologation erfordert formale Nachweise, strukturierte Risikoanalysen und nachvollziehbare Sicherheitsprozesse – meist in Form von Prüfberichten, Testdokumentationen, SBOMs oder Sicherheitskonzepten. Doch moderne Firmwareentwicklung ist oft inkrementell, verteilt und auf kurze Zyklen ausgelegt. Die Dokumentation hinkt nicht selten dem Stand der Software hinterher.
• Patch-Management steht im regulatorischen Niemandsland: Wird nach der Zulassung eine Schwachstelle entdeckt, stellt sich die Frage: Darf gepatcht werden – oder beginnt der Zulassungsprozess von vorn? Klare Leitlinien fehlen oft, insbesondere wenn sich Patches auf sicherheitskritische Funktionen auswirken. Hersteller befinden sich dann im Dilemma zwischen Reaktionsschnelligkeit und regulatorischer Konformität.
• Komplexität der Lieferkette erschwert Nachvollziehbarkeit: Viele Embedded-Produkte sind das Resultat arbeitsteiliger Entwicklung – mit Komponenten aus verschiedenen Ländern, Zulieferstufen und Softwarequellen. Homologationsdokumente können häufig nur das erfassen, was bekannt oder kontrollierbar ist. Doch was ist mit modifizierten Open-Source-Komponenten, proprietären Blobs oder Bibliotheken ohne SBOM?

In dieser Gemengelage entsteht ein strukturelles Spannungsfeld:

Der regulatorische Anspruch auf Nachvollziehbarkeit kollidiert mit der technischen Realität permanenter Veränderung.

Eine zukunftsorientierte Homologationsstrategie muss daher über das klassische Dokumentationsmodell hinausgehen. Sie braucht:

• kontinuierlich gepflegte SBOMs als Referenzbasis,
• integrierte Monitoringprozesse für neu auftretende CVEs,
• Update- und Patchprozesse mit rechtlich abgesichertem Handlungsspielraum,
• eine kulturübergreifende Sicherheitsverantwortung über die gesamte Lieferkette hinweg.

Andernfalls droht ein regulatorisches Paradoxon: Systeme gelten auf dem Papier als sicher – während sie im Feld längst verwundbar sind. Wer die Compliance zum Ziel erhebt, muss lernen, mit Unsicherheit zu leben – und angemessen darauf zu reagieren.

Feedbackkultur: Wenn das Feld spricht

Auch scheinbar unwichtige Geräte – etwa smarte Haushaltshelfer, IoT-Spielzeug oder vernetzte Sensorik – können sicherheitsrelevant sein. Ihre Vernetzungsfähigkeit macht sie zu potenziellen Einfallstoren in größere Systeme, auch wenn ihr Funktionsumfang oder ihr Marktpreis dies zunächst nicht vermuten lassen. Sicherheitslücken in einem smarten Babyphone oder einer günstigen WLAN-Steckdose können lateral in Unternehmensnetzwerke oder kritische Infrastrukturen übergreifen.

Das technische Risiko wird dabei durch organisatorische Blindstellen verstärkt: Viele Hersteller verzichten auf strukturierte Rückmeldeprozesse aus dem Feld. Nutzer haben keine klaren Kanäle, um verdächtiges Verhalten oder Sicherheitsprobleme zu melden. Supportsysteme sind auf Funktionalitäts- statt Sicherheitsanfragen ausgelegt. Und interne Prozesse zur Eskalation technischer Hinweise fehlen oder sind intransparent.

Eine resiliente Sicherheitsstrategie braucht daher eine Feedbackkultur, die über die Entwicklungsphase hinausreicht:

• Verpflichtende Rückmeldekanäle: Geräte sollten über definierte Kommunikationswege verfügen, über die Sicherheitsvorfälle oder Verdachtsmomente gemeldet werden können – digital, dokumentiert und nachvollziehbar. Ein QR-Code auf der Verpackung mit Verweis auf ein strukturiertes Meldeformular ist ein möglicher Einstieg.
• Niedrigschwellige Meldemöglichkeiten: Nicht nur Expertinnen und Experten, sondern auch Endnutzer müssen in der Lage sein, ungewöhnliches Verhalten zu melden. Meldungen sollten auch ohne tiefes technisches Verständnis akzeptiert werden – etwa über einfache Kategorien wie unerwartetes Verhalten, Verbindungsprobleme oder Fehlermeldung auf App.
• Prozesse zur internen Reaktion: Eingehende Meldungen müssen nicht nur gesammelt, sondern auch analysiert und bewertet werden. Ein interdisziplinäres Security Response Team kann dabei helfen, zwischen Bedienfehler, technischer Störung und Sicherheitsvorfall zu unterscheiden – und angemessen zu reagieren.
• Pflicht zur Weiterleitung an OEM oder Zulieferer: Wird ein sicherheitsrelevanter Fehler entdeckt, der aus einer zugekauften Komponente stammt, muss dieser fundiert und formell an den Verantwortlichen übermittelt werden. Hier beginnt Sicherheitsverantwortung entlang der Lieferkette.
• Kategorisierung und Bewertung von Felddaten: Regelmäßige Auswertung von Vorfällen kann Muster sichtbar machen – etwa bei bestimmten Firmwareständen, Hardwarevarianten oder regionalen Nutzungsszenarien. Diese Erkenntnisse sollten direkt in Updateentscheidungen und Design-Reviews einfließen.
• Transparente Kommunikation: Sicherheitskommunikation darf nicht an der Unternehmensgrenze enden. Betroffene Nutzer und Systeme müssen informiert, Updates bereitgestellt und ggf. Rückrufaktionen eingeleitet werden. Vertrauen entsteht nicht durch Perfektion, sondern durch Reaktionsfähigkeit.

Der Aufbau einer professionellen Feedbackkultur ist keine Kür, sondern Teil eines integralen Sicherheitsmanagements – insbesondere im Embedded-Bereich, wo Standardisierung und Transparenz vielfach fehlen. Es gilt:

Was das Feld meldet, muss in der Organisation ankommen – strukturiert, bewertet und bearbeitet.