5/5 Vernetzte Verantwortung: Konsequenzen ziehen – jetzt

1 – 2 – 3 – 4 – 5

Nach der Analyse von regulatorischen Rahmenbedingungen, Sicherheitsanforderungen, technischen Prozessen und organisatorischen Herausforderungen ist eines klar: Firmware ist keine statische Produktkomponente – sie ist ein lebendiger Angriffsvektor mit systemischer Wirkung.

Ihre Verwundbarkeit endet nicht mit der Entwicklung – im Gegenteil: Sie beginnt dort erst richtig. In vernetzten Embedded-Systemen wird die Firmware zur dauerhaften Schnittstelle zwischen physischer Funktionalität und digitaler Bedrohungslage. Sicherheitsprobleme betreffen nicht mehr nur Technik, sondern tangieren Haftung, Zulassung, Marktzugang und letztlich auch das Vertrauen der Nutzer.

Daraus ergibt sich ein klarer Handlungsauftrag für Hersteller, Zulieferer und Systemintegratoren:

1. Technisch: Systeme so gestalten, dass sie auch bei langfristiger Nutzung sicher aktualisierbar und kontrollierbar bleiben – unter Beachtung regulatorischer Anforderungen, kryptografischer Standards und organisatorischer Realität.
2. Organisatorisch: Sicherheitsprozesse etablieren, die über das Projektende hinaus greifen – inkl. Supportstrukturen, Monitoring-Routinen, rechtlicher Absicherung und dokumentierter Verantwortlichkeiten. Dafür ist entsprechendes Budget^* vorzuhalten!
3. Strategisch: Entscheidungen über Funktionalität, Vernetzung und Abhängigkeiten nicht nur unter Innovationsdruck treffen – sondern mit einem Bewusstsein für mögliche Langzeitfolgen, regulatorische Veränderungen und technologische Brüche.
4. Systemisch: Die gesamte Liefer- und Servicekette als sicherheitskritisch begreifen. Wer auf externe Komponenten, Bibliotheken oder Cloud-Dienste setzt, muss auch deren Sicherheitsfolgen aktiv managen.

Die Verantwortung beginnt nicht bei der ersten Codezeile – sie beginnt bei der Systemidee. Wer heute Produkte entwickelt, deren Relevanz über Jahre bestehen bleibt, muss auch über Jahre sicherheitsfähig bleiben – technisch, organisatorisch, rechtlich und kulturell.

Digitale Verantwortung endet nicht mit dem Produktverkauf – sie beginnt dort.

Sicheren Updateprozess gestalten

Ein absicherbarer, dokumentierter und rechtlich zulässiger Updateprozess ist essenziell – nicht nur für akute Reaktionsfähigkeit, sondern auch für die langfristige Zulassungsfähigkeit vernetzter Systeme. Er steht im Zentrum regulatorischer Anforderungen wie UNECE R156 (Software Update and Software Update Management System) und ist Voraussetzung für jedes nachhaltige Vulnerability Management.

Dabei geht es nicht nur um die technische Möglichkeit zum Patchen, sondern um ein ganzheitliches Konzept, das folgende Anforderungen erfüllt:

• Kryptografisch abgesichert: Die Authentizität und Integrität jeder Updatekomponente muss durch digitale Signaturen gewährleistet sein. Nur signierte, verifizierbare Pakete dürfen in produktive Systeme eingespielt werden. Auch Metadaten wie Versionierung und Hashwerte müssen manipulationssicher sein.
• Differenzierbar nach Komponenten und Regionen: Systeme bestehen häufig aus mehreren Subkomponenten (z. B. Steuergerät, Gateway, App, Cloudservice), die separat verwaltet und aktualisiert werden müssen. Auch regionale Varianten (z. B. gesetzlich vorgeschriebene Funktionen in bestimmten Ländern) erfordern ein flexibles Rollout-Management.
• Rückverfolgbar dokumentiert: Jeder Updatevorgang – von der Paketgenerierung bis zur erfolgreichen Installation – muss vollständig dokumentiert und im Bedarfsfall auditierbar sein. Dies betrifft nicht nur die Technik, sondern auch Entscheidungsprozesse, Freigaben und Freigabekriterien.
• In bestehende Supply-Chain-Strukturen integrierbar: Viele Updates entstehen nicht beim OEM selbst, sondern bei Tier-1- oder Tier-2-Zulieferern. Der gesamte Updatepfad muss deshalb rollenbasiert steuerbar, sicher übertragbar und in bestehende Logistik- und Qualitätssicherungssysteme eingebunden sein.

Darüber hinaus müssen Unternehmen folgende strategische Fragen beantworten:

• Wie lange garantieren wir Sicherheitsupdates und unter welchen Voraussetzungen?
• Wie gehen wir mit Systemen um, die nicht (mehr) updatefähig sind – z. B. aufgrund fehlender Konnektivität oder veralteter Plattformen?
• Welche Infrastruktur benötigen wir intern (CI/CD, Signing Server, Compliance-Monitoring), um die Sicherheit der Updates langfristig zu gewährleisten?

Ein sicherer Updateprozess ist kein reines Technologiethema. Er erfordert rechtliche Absicherung, organisatorische Reife und eine klare strategische Verantwortung – vom Entwicklungsstart bis zum End-of-Support. Wer hier lückenhaft agiert, gefährdet nicht nur seine Systeme – sondern auch die eigene Zulassung, Produkthaftung und Marktakzeptanz.

Ressourcenplanung über das Produktleben hinaus

Embedded-Systeme bleiben oft über Jahre – manchmal Jahrzehnte – im Feld. Gerade in sicherheitskritischen oder infrastrukturell eingebetteten Anwendungen ist eine Lebensdauer von 10 bis 20 Jahren keine Ausnahme. Daraus ergibt sich die Pflicht, Sicherheitsbetreuung über das Ende der Produktion (EoP) hinaus zu planen – auch wenn Produktentwicklung, Serienfertigung und Markteinführung längst abgeschlossen sind.

• Wartungskapazitäten: Viele Sicherheitsprobleme treten erst lange nach Serienstart auf – etwa durch neu entdeckte CVEs oder veränderte Bedrohungsszenarien. Unternehmen müssen dafür Ressourcen vorhalten: Know-how-Träger, Incident Response Teams, juristische Begleitung und technische Servicekapazitäten. Diese Ressourcen lassen sich nicht kurzfristig aktivieren – sie müssen strategisch vorgesehen und strukturell gesichert sein.
• Infrastruktur für Build- und Signierungsprozesse: Sicherheitspatches setzen voraus, dass sich Firmwarepakete auch Jahre nach Freigabe reproduzierbar bauen, testen und signieren lassen. Dafür müssen Toolchains, Quellcodes, Abhängigkeiten und Zertifikate langfristig archiviert und wartbar bleiben. „Buildability over Lifecycle“ ist eine oft unterschätzte Anforderung.
• Vertragliche Regelungen mit Dienstleistern: Viele Komponenten stammen von externen Entwicklungspartnern oder Plattformanbietern. Um auch in späteren Produktphasen sicherheitsrelevante Änderungen umsetzen zu können, müssen Wartungsrechte, Updatepflichten, Supportfristen und Haftungsfragen frühzeitig geklärt und dokumentiert sein. Andernfalls droht ein technischer Lock-in ohne Sicherheitsgarantie.

Hinzu kommt die Frage: Wie lange gilt ein Produkt eigentlich als betreuungspflichtig? Gesetzliche Regelungen (z. B. in der Maschinenverordnung oder über Produkthaftungsrecht) definieren teils Mindestfristen. Doch oft geht es auch um Markenverantwortung und Markterwartung: Ein Produkt, das sich selbst überlässt, wird zum Reputationsrisiko – und langfristig zum regulatorischen Problem.

Auch interne Faktoren müssen berücksichtigt werden:

• Wie stellen wir Know-how-Sicherung sicher – trotz Personalfluktuation?
• Welche Rolle spielt automatisierte Dokumentation im Buildprozess?
• Gibt es Pläne für Obsoleszenzmanagement bei Toolchains, Betriebssystemen und Schlüsselmaterial?

Langfristiger Produktsupport ist keine Kür, sondern Voraussetzung für digitale Nachhaltigkeit – technisch, wirtschaftlich und ethisch. Wer Embedded-Systeme auf den Markt bringt, übernimmt Verantwortung über deren gesamten Lebenszyklus hinweg – unabhängig vom EoP.

Entwicklungspartner als Schwachstelle mitdenken

Die Lieferkette ist nur so sicher wie ihr schwächstes Glied. Entwicklungspartner, IT-Dienstleister, Backend-Betreiber, App-Agenturen und Hostingprovider – sie alle tragen dazu bei, dass digitale Produkte entstehen, betrieben und aktualisiert werden können. Doch sie sind auch potenzielle Eintrittstore für Angreifer – technisch, organisatorisch und juristisch.

Die Realität zeigt: Zahlreiche Sicherheitsvorfälle der letzten Jahre (z. B. Log4Shell, SolarWinds, MOVEit) wurzeln nicht im eigenen Code, sondern in Drittabhängigkeiten. Daraus ergibt sich eine klare Pflicht: Cybersecurity muss über die Unternehmensgrenzen hinaus gedacht und vertraglich geregelt werden.

• Vertraglich geregelte Sicherheitsanforderungen: Bereits in der Beauftragung müssen Anforderungen an sichere Entwicklung, Buildprozesse, Zugriffskontrollen, Schwachstellenkommunikation und Patchzyklen definiert werden – idealerweise in Form von SLAs (Service Level Agreements) oder SBoSCs (Security Bill of Software Contracts).
• Kontrollmechanismen und Auditierungsrechte: Auftraggeber sollten sich das Recht einräumen lassen, sicherheitsrelevante Prozesse beim Partner zu prüfen – sei es durch Audits, durch gemeinsame Penetrationstests oder durch Offenlegung von SBOMs. Transparenz ist die Voraussetzung für Vertrauen.
• Definierte Eskalationsprozesse bei Vorfällen: Wer meldet wann an wen? Welche Pflichten bestehen zur Offenlegung von Sicherheitsereignissen? Wie erfolgt die Abstimmung bei CVE-Veröffentlichungen oder regulatorischen Berichtsfristen? Diese Fragen müssen im Vorfeld geklärt sein – nicht erst im Krisenmodus.

Besonders kritisch sind Konstellationen mit mehreren Subdienstleistern, Offshore-Entwicklung oder komplexen Toolchain-Abhängigkeiten. Hier droht ein Verlust der Kontrolle über Codequalität, Deploymentpfade und Sicherheitsmaßnahmen. Lieferkettensicherheit (Supply Chain Security) wird deshalb zunehmend auch regulatorisch adressiert – etwa durch die NIS2-Richtlinie in der EU oder die Executive Order 14028 in den USA.

Ein modernes Sicherheitskonzept muss deshalb mehr leisten als nur „Security-by-Design“ im eigenen Entwicklungsteam. Es muss:

• Lieferkettenrisiken systematisch analysieren (Third Party Risk Assessment),
• Sicherheitsverantwortung explizit vertraglich verankern,
• und die Fähigkeit zur schnellen Reaktion auf externe Sicherheitsvorfälle etablieren.

Fazit: In einer vernetzten Produktwelt ist Sicherheit immer auch eine Frage des Ökosystems. Wer Partner integriert, muss auch deren Sicherheitsfolgen mitverantworten – strukturell, juristisch und technisch.

Item Definition: Was muss wirklich vernetzt sein?

Die Definition der bereitgestellten Funktionalität ist ein zentraler Sicherheitshebel – nicht nur aus Sicht der funktionalen Sicherheit, sondern auch im Hinblick auf Cyberresilienz und regulatorische Zulassungsfähigkeit. Die ISO 26262 fordert mit dem Konzept der Item Definition eine präzise Beschreibung dessen, was ein System leisten soll – und unter welchen Bedingungen. Dabei geht es nicht nur um Funktionen, sondern auch um Betriebsmodi, Abhängigkeiten, Schnittstellen und Systemgrenzen.

In Kombination mit einem systematischen Funktionsbewertungsansatz ergibt sich ein klarer Bewertungsmaßstab:

• Ist die Onlinefunktionalität wirklich notwendig oder nur komfortgetrieben?
  Viele Funktionen sind „by default“ vernetzt, ohne dass ein konkreter Mehrwert entsteht. OTA-Updates, App-Anbindungen oder Cloud-Dienste dienen oft primär der Marktpositionierung. Doch jede zusätzliche Vernetzung ist ein potenzielles Risiko. Die Frage muss daher lauten: Wie hoch ist der funktionale Nutzen – und wie groß ist der Angriffsraum?
• Ist die Verfügbarkeit der Funktion kritisch auch bei Marktversagen, Insolvenz oder Rückzug des Herstellers?
  Funktionen, die z. B. auf Backend-Dienste, Plattform-APIs oder Lizenzserver angewiesen sind, müssen auch unter realistischen Ausfallszenarien bewertet werden. Ein System, das ohne Onlineverbindung unbrauchbar wird, verliert seine Betriebssicherheit. Die Verfügbarkeit muss daher entkoppelt von Marktdynamiken mitgedacht werden.
• Können Sicherheitsfunktionen offline redundant erhalten bleiben?
  Kritische Funktionen – z. B. Fahrassistenz, Notbremsung, Zutrittssysteme – sollten auch bei unterbrochener Verbindung, Cyberangriffen oder Infrastrukturproblemen verfügbar sein. Redundanz bedeutet nicht nur doppelte Hardware, sondern auch alternative Betriebsmodi ohne Onlineabhängigkeit.

Die Frage „Was muss wirklich vernetzt sein?“ ist kein rein technisches Designkriterium. Sie ist Ausdruck von Verantwortungsbewusstsein in einer zunehmend digitalisierten Welt. Wer Funktionen bereitstellt, die nur durch ständige Onlineverbindung steuerbar oder sicher betreibbar sind, schafft nicht nur Komfort – sondern auch neue Verwundbarkeiten.

Funktionale Reduktion ist kein Rückschritt, sondern Teil verantwortungsbewusster Digitalisierung. Es geht nicht um Verzicht, sondern um Verhältnismäßigkeit: Die Vernetzungslogik eines Produktes muss begründet, dokumentiert und im Zweifel auch zurücknehmbar sein.

Gerade im Kontext regulatorischer Anforderungen (z. B. ISO 26262, UNECE R155, Maschinenverordnung) wird diese Fragestellung künftig an Bedeutung gewinnen: Systeme mit kritischer Safety-Funktion müssen auch dann noch sicher funktionieren, wenn externe Dienste nicht verfügbar sind – oder kompromittiert wurden.

Wer das System versteht, kann es sicher machen. Wer die Funktionen reduziert, macht es robuster.

Aufruf: Vernetzung ist Verantwortung – und das langfristig

Vernetzte Systeme verändern sich nicht nur technologisch – sie verändern auch ihre Bedrohungsoberfläche. Jede neue Abhängigkeit, jede neu eingeführte Onlinefunktion, jede Erweiterung per Update bedeutet auch: neue Angriffsflächen, neue Interaktionen, neue Unsicherheiten. In diesem Spannungsfeld gilt: Sicherheit ist kein Projektabschluss – sie ist ein Prozess, der nie endet.

Der Charakter vernetzter Produkte ist langfristig. Doch viele Unternehmen planen Sicherheit kurzfristig: begrenzt auf Entwicklungsbudgets, befristete Serviceverträge oder vermeintlich kalkulierbare Supportzeiträume. Diese Haltung ist nicht zukunftsfähig.

• Technisch muss Sicherheit über die Lebensdauer hinaus gedacht werden – inklusive Updatefähigkeit, Schlüsselmanagement, Dokumentation und Nachvollziehbarkeit.
• Organisatorisch braucht es langlebige Strukturen: Sicherheitsverantwortung darf nicht an Projektgrenzen oder Rollenwechsel scheitern.
• Juristisch entstehen neue Anforderungen: Cybersecurity wird regulatorisch eingefordert (z. B. durch den Cyber Resilience Act, NIS2, R155) – auch Jahre nach dem Serienstart.
• Kulturell bedeutet Verantwortung: Wer digital vernetzt, schafft Abhängigkeiten – und muss bereit sein, deren Risiken auch langfristig zu tragen.

Es reicht nicht, „updatefähig“ zu sein – man muss auch wirklich updaten wollen, können und dürfen. Die Vorstellung, vernetzte Produkte nach Markteintritt sich selbst zu überlassen, ist nicht nur sicherheitstechnisch naiv, sondern zunehmend haftungsrelevant.

Daher braucht es ein Umdenken – weg von punktueller Absicherung hin zu einer langfristigen Sicherheitsstrategie, die folgende Fragen adressiert:

• Wie stellen wir sicher, dass wir unsere Systeme auch in 5, 10 oder 15 Jahren noch verstehen und warten können?
• Welche Betriebsmodelle ermöglichen Sicherheit über regulatorische, organisatorische und technologische Veränderungen hinweg?
• Wie sichern wir unsere Nutzer ab – selbst dann, wenn unsere Firma, Plattform oder Dienstleistung nicht mehr existiert?

Wer heute Produkte vernetzt, vernetzt auch Risiken, Menschen und Märkte. Diese Verantwortung endet nicht mit dem Produktverkauf – sie beginnt dort.

Vernetzung ist Verantwortung – und das langfristig.