NIS2 und Cyber Resilience Act: Was sie für Automotive-Cybersecurity bedeuten und was Mobility-Akteure heute wissen müssen

Wer in der Fahrzeugentwicklung bzw. Automobilindustrie für Cybersicherheit verantwortlich ist, dürfte die letzten Jahre damit verbracht haben, ISO/SAE 21434-Prozesse aufzubauen und UN R155-Typgenehmigungsnachweise zu strukturieren. Das stetige Gefühl dabei: Kaum ist ein Regulierungsrahmen einigermaßen stabil, kommt der nächste. (Zuletzt besonders mit Blick auf globale UN R155-Pendants.)

Parallel dazu begleitet die Branche seit deutlich längerer Zeit schon das Thema TISAX – allerdings auf einer anderen Ebene, nämlich der Informationssicherheit auf Unternehmens- und Standortebene und damit stets etwas weniger im Fokus der Fahrzeugentwicklung und Engineering.

Mit der NIS2 und dem Cyber Resilience Act (CRA) folgt in der Wahrnehmung vieler Branchenangehöriger nun eine nächste Welle: weiterer Compliance-Aufwand, der auf dasselbe Team und dasselbe Budget trifft.

Diese Wahrnehmung ist nachvollziehbar. Sie ist aber unpräzise.

Diese Unpräzision hat im Zweifelsfall weitreichende Konsequenzen. Daher ist es in den vielschichtigen Gewerken der Fahrzeugentwicklung und der Security-Verantwortung sinnvoll, einen genauen Überblick darüber zu haben, was NIS2 und der CRA konkret bedeuten, wie sie sich zu den bekannten Automotive-Frameworks verhalten und welche Konsequenzen sich daraus für Automotive-Organisationen ergeben.

Wichtig für Entwicklerinnen und Entwickler: NIS2 und der CRA sind strukturell anders als alles, womit Automotive-Cybersecurity-Teams bislang gearbeitet haben. Sie sind keine Produktentwicklungs- oder Engineering-Standards. Sie sind öffentlich-rechtliche Regelwerke mit staatlichen Behörden, Vorstandshaftung, Bußgeldern und Meldeketten.

Damit verbunden ist ein anderer Abstraktionsgrad: Während die bekannten Automotive-Frameworks vergleichsweise konkret in Requirements-Form vorgeben, was zu tun ist (auch wenn das schon viel Spielraum lässt), bewegen sich NIS2 und CRA auf einem deutlich höheren Level und beschreiben oft nur, mit welchem Thema sich der Hersteller auseinanderzusetzen hat — Stichwort “the manufacturer shall exercise due diligence”. (Ausgenommen die Essential Requirements aus Anhang I CRA.)

Hinzu kommt die Sprache selbst: Im Gegensatz zu ISO-Standards und der UN-Regulierung sind NIS2 und CRA juristisch möglichst unanfechtbar formuliert. Entwickler, die damit arbeiten müssen, treffen damit plötzlich auf einen Sprachstil, mit dem sie bisher kaum zu tun hatten.

Das ändert entsprechend, wer in der eigenen Organisation zuständig ist, welche Dokumentation benötigt wird und welche Konsequenzen bei Verstößen drohen.

Drei Frameworks, drei Ebenen: Was ISO/SAE 21434, UN R155 und TISAX leisten (sollen)

Zum ersten genaueren Verständnis hilft eine kurze Einordnung der bekannten Frameworks, bevor NIS2 und CRA hinzukommen:

• Die ISO/SAE 21434:2021 ist der internationale führende Industriestandard für die Entwicklung von cybersicheren Produkten in der Automobilbranche. Er beschreibt, wie Cybersecurity-Risikomanagement in der Entwicklung von Fahrzeug-E/E-Systemen über den gesamten Lebenszyklus strukturiert wird und wie Cybersecurity in Projekte und Organisationen integriert werden soll. Das Kernwerkzeug ist die Threat Analysis and Risk Assessment-Methodik (TARA). Der Standard richtet sich direkt an Entwicklungsteams bei OEMs und Zulieferern der Fahrzeug- und Automobilindustrie. Meldepflichten oder behördliche Aufsicht gibt es hier nicht. Verbindlichkeit entsteht primär über Kundenanforderungen und gegebenenfalls über Haftungsfragen, wenn nicht nach Stand der Technik gearbeitet wurde.
• Die UN Regulierung UN R155 ist eine typgenehmigungsrelevante Fahrzeugregulierung, die sich ausschließlich an Fahrzeughersteller richtet, nicht an Hersteller von (Teil-)Produkten. Sie verlangt ein nachweislich funktionierendes Cybersecurity Management System (CSMS) und die entsprechende Anwendung für die verschiedenen Fahrzeugtypen als Voraussetzung für die Typgenehmigung. Die Nachweisadressaten sind Genehmigungsbehörden und Technische Dienste.
• TISAX ist der etablierte Branchen-Assessment-Mechanismus für Informationssicherheit auf Unternehmens- und Standortebene. Er basiert auf dem VDA ISA, ist konzeptionell ISO/IEC 27001-nah und erweitert diesen um den Schutz von Prototypen. TISAX erzeugt anerkannte Assessment-Ergebnisse, aber keine öffentlich-rechtlichen Meldepflichten. Für europäische Hersteller ist TISAX heute eine Grundvoraussetzung für Zusammenarbeit.

Keines dieser Frameworks erzeugt für sich genommen die organisationsweiten Meldepflichten und Vorstandshaftungen von NIS2 oder die CE-gestützten Produkt- und Post-Market-Pflichten des CRA.

Wofür NIS2 primär steht: Öffentlich-rechtliche IT-Resilienz auf Unternehmensebene

NIS2 ist zuvorderst ein organisationsbezogenes Regelwerk. Es verpflichtet Einrichtungen in bestimmten Sektoren zu Cybersecurity-Maßnahmen für die Resilienz ihrer Netz- und Informationssysteme. Also IT, OT, Lieferantenbeziehungen, Servicekontinuität.

Für die Automobilindustrie ist der Geltungsbereich relevant: NIS2 erfasst insgesamt 18 Sektoren (11 in Anhang I als “Sektoren von hoher Kritikalität”, 7 in Anhang II als “sonstige kritische Sektoren”). Automotive ist dabei in Anhang II Nummer 5 (“Verarbeitendes Gewerbe”) Buchstabe e adressiert – die Herstellung von Kraftwagen, Anhängern und Sattelanhängern nach NACE Rev. 2 Abt. 29.

Mittlere und große Unternehmen in diesen Sektoren fallen grundsätzlich in den Anwendungsbereich. Da NIS2 eine Richtlinie ist, hängen finale Registrierungsmechanik, zuständige Behörden und länderspezifische Erweiterungen von der nationalen Umsetzung ab. Eine länderübergreifende Rechtsprüfung bleibt erforderlich.

Was NIS2 konkret fordert

NIS2 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen. Art. 21 Abs. 2 der Richtlinie listet zehn Kernelemente: Risikoanalyse und Sicherheitspolitik, Incident Handling, Business Continuity, Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung (einschließlich Management und Offenlegung von Schwachstellen), Wirksamkeitsbewertung, grundlegende Cyber-Hygiene und Schulung, Kryptographie, Personalsicherheit und Zugangskontrolle sowie Multifaktor-Authentifizierung und gesicherte Kommunikation.

Das verschiebt die Compliance-Diskussion von der ECU- und Item-Ebene nach oben — in die Resilienz von IT, OT, Lieferantenbeziehungen und Servicekontinuität der gesamten Organisation.

Vorstandsverantwortung und Sanktionen

Neu für viele Automotive-Organisationen ist die explizite Leitungsverantwortung. NIS2 verlangt, dass Leitungsorgane Cybersecurity-Maßnahmen genehmigen, deren Umsetzung überwachen und an Schulungen teilnehmen. Leitungsorgane können für Verstöße persönlich haftbar gemacht werden. Praktisch bedeutet das: Cybersecurity lässt sich nicht mehr vollständig nach unten delegieren – die Verantwortung bleibt auf Leitungsebene verankert.

Auch wenn dies allzu oft als Compliance-Theorie abgetan wird, sei der Blick auf die Bußgeldobergrenzen empfohlen (zu verstehen als Mindestwerte, Mitgliedstaaten können in ihrer nationalen Umsetzung auch höhere Werte festlegen):

• Wichtige Einrichtungen (important entities): mindestens 7 Mio. EUR oder 1,4 % des weltweiten Jahresumsatzes, je nachdem was höher ist – die für Automotive in der Regel einschlägige Kategorie, da Anhang-II-Einrichtungen nach Art. 3 Abs. 2 NIS2 automatisch als “wichtig” eingestuft werden.
• Wesentliche Einrichtungen (essential entities): mindestens 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes – diese Kategorie greift im Automotive-Kontext nur in Sonderkonstellationen, etwa wenn ein Konzern auch Anhang-I-Einrichtungen betreibt (z.B. eigene Energie-Sparte, qualifizierte Vertrauensdienste, große Cloud-Dienste).

Automobilhersteller und größere Zulieferer in Anhang-II-Sektoren gelten regelmäßig als wichtige Einrichtungen. Dadurch entsteht möglicherweise eine andere Dringlichkeit als durch ein TISAX-Audit-Ergebnis oder einen Typgenehmigungsnachweis. Der entscheidende Unterschied zwischen NIS2 und UN R155 sollte sich klar gemacht werden: Während mit der UN-Regulierung der Marktzugang auf dem Spiel steht, verantworten die handelnden Personen dies nur gegenüber ihrem Arbeitgeber. Unter NIS2 haften sie persönlich.

Die NIS2-Meldekaskade

NIS2 etabliert eine fest definierte Meldekette zu Behörden bei signifikanten Vorfällen:

• innerhalb von 24 Stunden eine Frühwarnung,
• innerhalb von 72 Stunden eine Vorfallsmeldung mit Erstbewertung,
• auf Anforderung ein Zwischenbericht,
• innerhalb eines Monats ein Abschlussbericht.

Die UN R155 kennt zwar eine Reporting-Pflicht an die Approval Authority – mindestens jährlich, “oder häufiger falls relevant”. was bei kritischen Vorfällen in der Praxis als zeitnahe Information ausgelegt wird. Bei kritischen Vorfällen wird das in der Praxis regelmäßig als zeitnahe (oft 24h-)Informationspflicht ausgelegt, schon weil sonst die Wirksamkeit des CSMS und damit die Typgenehmigung in Zweifel stehen.

Der Unterschied liegt in der Verbindlichkeit: NIS2 schreibt die Fristen direkt im Gesetzestext fest, UN R155 überlässt sie der Auslegung zwischen OEM und Behörde.

TISAX und NIS2: näher als gedacht, aber auch nicht dasselbe

Für TISAX-reife Teams ist die relevante Nuance: TISAX deckt wesentliche NIS2-Anforderungen materiell ab und geht in einigen Bereichen darüber hinaus. Das ENX-Gutachten 2025 („Abdeckung NIS2 durch TISAX“) bestätigt das. Aber: Länderspezifische Umsetzungspflichten und nationale Meldepflichten sind nicht abgedeckt und müssen parallel bedient werden. Es gilt also: TISAX ist kein NIS2-Compliance-Zertifikat.

Was der Cyber Resilience Act (CRA) hinzufügt: Produktpflichten mit CE-Kennzeichnung

Der CRA ist fundamental anders strukturiert als NIS2: Er reguliert Produkte, nicht Organisationen. Die Europäische Kommission beschreibt ihn als horizontalen Rahmen für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Erfasst sind u.a. eigenständige Software, separat platzierte Firmware, Hardwarekomponenten wie integrierte Schaltkreise und Sensoren.

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten nach Artikel 14 gelten ab 11. September 2026, auch für Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Die vollständige Anwendung der Hauptpflichten beginnt am 11. Dezember 2027.

Was der CRA konkret verlangt

Vor dem Inverkehrbringen eines erfassten Produkts muss der Hersteller eine Cybersecurity-Risikobewertung durchführen, die Essential Cybersecurity Requirements umsetzen, eine technische Dokumentation erstellen, eine Konformitätsbewertung durchführen, eine EU-Konformitätserklärung ausstellen und die CE-Kennzeichnung anbringen.

Diese Kombination aus Technical File, Erklärung, CE-Kennzeichnung und Marktüberwachung hat in ISO/SAE 21434, TISAX oder NIS2 keine echte Entsprechung.

(Wenngleich hier die Abdeckung der ISO/SAE 21434 hier bereits reinspielt, s. auch der Beitrag zum ersten Blick auf den CRA aus Perspektive der 21434)

Hinzu kommen Post-Market-Pflichten: Hersteller müssen einen Support-Zeitraum festlegen und offenlegen. Mindestens fünf Jahre, es sei denn, die voraussichtliche Nutzungsdauer ist kürzer. Während dieses Zeitraums müssen Schwachstellen behandelt und Sicherheitsupdates bereitgestellt werden. (Kenner erkennen die Parallele zur ordnungsgemäßen TARA-Methodik mit inkludierten Vulnerability-Management-Funktionen entlang des Produktlebenszyklus, Stichwort CYMETRIS)

Der CRA-Meldekanal

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die von ENISA betriebene einheitliche Meldeplattform an das als Koordinator benannte CSIRT ihres Mitgliedstaats melden (ENISA erhält die Meldung parallel): innerhalb von 24 Stunden eine Frühwarnung, innerhalb von 72 Stunden eine vollständigere Meldung; bei aktiv ausgenutzten Schwachstellen folgt der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, bei schwerwiegenden Vorfällen innerhalb eines Monats nach der Vorfallmeldung.

Für einen Automotive-Konzern, der sowohl NIS2- als auch CRA-Pflichten unterliegt, sind die beiden Meldeketten genau auseinanderzuhalten:

• NIS2 zielt auf Vorfälle in den Netz- und Informationssystemen der Einrichtung selbst, also wenn die eigene Diensterbringung signifikant beeinträchtigt wird (Art. 23 NIS2).
• Der CRA zielt auf aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Sicherheit eines vom Hersteller in Verkehr gebrachten Produkts betreffen (Art. 14 CRA).

In der Praxis bedeutet das: Eine Ransomware-Infektion im Werks-IT-Netz löst eine NIS2-Meldung aus, aber keine CRA-Meldung. Eine aktiv ausgenutzte Schwachstelle in einem verkauften Werkstatt-Tool löst eine CRA-Meldung aus, aber nicht zwingend eine NIS2-Meldung. Erst wenn ein Ereignis beide Sphären gleichzeitig trifft – etwa eine Schwachstelle in einem vom OEM betriebenen und verkauften Backend-Dienst – greifen beide Meldeketten parallel.

Was der CRA für typgenehmigte Fahrzeuge bedeutet

Der CRA ist in der Praxis kein zweites UN R155 für typgenehmigte Straßenfahrzeuge. Die CRA-Implementierungs-FAQ der Europäischen Kommission stellt klar: Der CRA gilt nicht für Produkte, auf die die Verordnung (EU) 2019/2144 (Allgemeine Sicherheitsverordnung, GSR) anwendbar ist. Das betrifft Kraftfahrzeuge, Anhänger sowie zugehörige Systeme, Bauteile und selbständige technische Einheiten unter dem EU-Typgenehmigungsrahmen. Zusätzlich schließt die Delegierte Verordnung (EU) 2025/1535 bestimmte L-Klasse-Fahrzeuge explizit vom CRA aus.

Noch konkreter: Fahrzeugentwicklungs- und Automotive-Organisationen, die sich bereits tagein tagaus mit der Anwendung der UN R155 & ISO/SAE 21434 beschäftigen (müssen), sind mit ihren typgenehmigten Fahrzeugprodukten vom CRA ausgenommen. (Nicht aber automatisch mit ihrem übrigen Produktportfolio!)

Dennoch lesen diese Zeilen bis hierhin zahlreiche Angehörige der Automotive- und Vehicle-Wertschöpfung – und zwar zurecht. Die größte Auswirkung des CRA liegt häufig außerhalb des typgenehmigten Fahrzeugumfangs.

Bei eigenständiger Software, separat in Verkehr gebrachten Komponenten, Betriebssystemen, Chips, Mobil-Apps, Werkstattwerkzeugen und anderen nicht ausgeschlossenen digitalen Produkten.

Bei eigenständiger Software, separat in Verkehr gebrachten Komponenten, Betriebssystemen, Chips, Mobil-Apps, Werkstattwerkzeugen und anderen nicht ausgeschlossenen digitalen Produkten. Auch automotive-nahe Produkte außerhalb des (sich stetig weiterentwickelnden!) UN R155-Geltungsbereichs können CRA-pflichtig werden – etwa E-Bikes, Pedelecs, E-Scooter, Quads oder Land- und Forstmaschinen.

Besonders relevant ist das für Zulieferer, die derzeit versuchen, in anderen Branchen Fuß zu fassen und ihre Abhängigkeit von der angeschlagenen Automobilbranche zu verringern. Sobald sie Produkte außerhalb des Typgenehmigungsrahmens platzieren, greift der CRA in voller Schärfe.

Ein Hinweis zur Auslegungslücke: Für Fahrzeugklasse O (Anhänger) besteht derzeit eine bekannte Grauzone. Die UN R155 nennt die Kategorie O im Geltungsbereich (sofern mindestens eine E/E-Komponente), Anhang II der GSR wendet die D4-Cybersecurity-Anforderung jedoch nicht ausdrücklich auf die Kategorie O an. Eine produktbezogene rechtliche Klassifikation sei hier empfohlen.

Kurz erwähnt: Die DIN EN 40000 Normenreihe zur Cybersicherheit von Produkten mit digitalen Elementen

Für die Auslegung der bewusst abstrakt gehaltenen CRA-Anforderungen aus Anhang I entsteht derzeit auf europäischer Ebene die horizontale Normenreihe DIN EN 40000 (mit den vier Modulen: Gemeinsames Vokabular, Prinzipien der Cyberresilienz, Vulnerability Handling, Generic Security Requirements).

Aktuell liegen alle vier Teile als prEN-Entwürfe im Status „Norm-Entwurf“ vor. Die Idee ist, dass die Reihe als praxisnaher Leitfaden zur CRA-Compliance dienen soll, so wie die ISO/SAE 21434 zur UN R155-Compliance.

Drei Ebenen, drei Frameworks: Empfehlungen zur Compliance-Architektur

Die praktische Antwort auf die Frage, wie alle relevanten Frameworks zusammenwirken, ist keine Framework-Verschmelzung.

Eine Compliance-Architektur mit klaren Routing-Regeln je Asset, Produkt, Standort und Service scheint der richtige Weg.

Dabei ließe sich auf drei Ebenen denken.

• Schicht 1: (Produkt-)Entwicklungs-Schicht. ISO/SAE 21434 und UN R155 bleiben die Heimat für Item Definition, TARA, Cybersecurity-Ziele, Lebenszyklus-Arbeitsergebnisse, CSMS-Nachweise und Interaktion mit Genehmigungsbehörden. Hier bleibt das Fahrzeug- und E/E-Engineering verankert.
• Schicht 2: Infrastruktur-Schicht. TISAX als Branchen-Assurance-Baseline für Informationssicherheit, ergänzt durch NIS2 als eigenständige Rechtsschicht für Vorstands-Governance, Registrierungspflichten, Behördeninteraktion und Meldewesen bei signifikanten Vorfällen.
• Schicht 3: Produkt-Markt-Schicht. Ein formales CRA-Screening-Gate im Produktfreigabeprozess. Erste Frage: Greift ein Automotive-Ausschluss unter dem EU-Typgenehmigungsrahmen? Wenn ja, ist der CRA obsolet. Wenn nein, braucht das Produkt ein vollständiges CRA-File inklusive Risikobewertung, CE-Kennzeichnung, Support-Zeitraum, Vulnerability Disclosure Policy und Meldepflichten.

Zwei häufige Fehler, die diese grobe Struktur vermeidet:

1. Alles aus der reinen Perspektive der ISO/SAE 21434 zu denken. Ja, die 21434 bleibt zentral, ist aber nicht die rechtliche Heimat für NIS2-Vorstandshaftung oder CRA-CE-Konformität.
2. NIS2 oder CRA als Ersatz für Automotive-Engineering-Disziplin zu behandeln. Korrekt ist: 21434 und R155 greifen primär ins Fahrzeug-Engineering (und, etwas sehr vereinfacht gesagt, das ‚Drumherum‘), TISAX für den Nachweis zur Absicherung der Infrastruktur, NIS2 für Unternehmensresilienz, CRA für nicht ausgeschlossene Marktprodukte.

Zusammenfassung: Was das für OEMs, Tier-Zulieferer, Mobility-Akteure und weitere Hersteller/Anbieter konkret bedeutet

Die Stifte rausholen, zum Mitschreiben. Aus dem Vorherigen gilt wie folgt:

• OEMs und regulierte Fahrzeughersteller: Das Vehicle-CSMS, TARA und Typgenehmigungsnachweise bleiben in der Engineering-Schicht. NIS2 kommt darüber als Unternehmensschicht für Vorstands-Governance, Entity-Meldepflichten und Resilienz von IT, OT, Werken und Backend. Beim CRA gilt: nicht voreilig alle Fahrzeugkomponenten als CRA-pflichtig einordnen. Die belastbare Frage lautet, ob das konkrete Produkt vom EU-Typgenehmigungsrahmen ausgeschlossen ist oder ob es ein separat in Verkehr gebrachtes Produkt mit digitalen Elementen darstellt.
• Tier-Zulieferer und Komponentenhersteller: Mittlere und große Zulieferer können selbst unter NIS2 als wichtige Einrichtungen fallen. Maßgeblich ist dabei nicht die Größe allein, sondern die Kombination aus Sektoreinstufung (Anhang II NIS2 erfasst u.a. die Herstellung von DV-Geräten, elektrischen Ausrüstungen, Maschinen und Fahrzeugen) und Größenschwelle. Wer Chips, Sensoren oder Steuergeräte produziert, fällt häufig über mehrere Sektorklassen in den Anwendungsbereich – unabhängig davon, ob das Endprodukt typgenehmigt wird. Kleinere Zulieferer spüren NIS2 mittelbar über die Lieferketten-Anforderungen ihrer Kunden. Beim CRA ist die entscheidende Frage, ob der Zulieferer ein erfasstes Produkt unter eigenem Namen in der EU in Verkehr bringt. Chips, Betriebssysteme und separat platzierte Software können als eigenständige Produkte mit digitalen Elementen gelten — mit eigener Risikobewertung, Technical File, Support-Zeitraum und Meldekanal. Ungewohnt für Automotive: Der CRA stellt das In-Verkehr-Bringen unter eigenem Namen dem Herstellen gleich (Art. 21 CRA). Distributoren oder Reseller, die ein Produkt unter eigener Marke vertreiben oder wesentlich modifizieren, werden damit selbst zum CRA-Hersteller – anders als im klassischen Typgenehmigungsgeschäft, wo die Cybersecurity-Verantwortung beim OEM verbleibt.
• Software, Apps, Backend, Tooling &. Co: Eine Mobil-App braucht eine CRA-Klassifikationsentscheidung. Eine Fahrzeugfunktion braucht 21434- und R155-Nachweise. Ein Werk, SOC oder Backend-Betrieb braucht NIS2-Governance und Meldewesen. Eine Pauschal-Etikette „Automotive-Cyber-Compliance“ reicht nicht mehr.

Offene Fragen als Einstieg für den ersten Selbstcheck

Die beschriebenen Regelwerke sind komplex. Nicht alle Auswirkungen lassen sich heute vollständig überblicken, weil nationale NIS2-Umsetzungsgesetze variieren und CRA-Auslegungsfragen in bestimmten Grenzbereichen noch offen sind.

Was sich aber bereits zum gegenwärtigen Zeitpunkt sinnvoll angehen lässt, ist die kritische Selbstüberprüfung:

• Fällt die eigene Organisation unter NIS2 — und wenn ja, als wesentliche oder wichtige Einrichtung? Ist die Registrierung im jeweiligen Mitgliedstaat bereits berücksichtigt?
• Ist die dedizierte Vorstandsverantwortung unter NIS2 in der eigenen Governance-Struktur adressiert? Oder liegt Cybersecurity noch ausschließlich bei Engineering-Teams? (Der Klassiker …)
• Welche Produkte des eigenen Portfolios könnten unter den CRA fallen? Werden sie auch an andere Branchen außerhalb der Automotive-Wertschöpfung verkauft? Gibt es ein formales Screening-Gate, das zwischen typgenehmigten Fahrzeugen und separat in Verkehr gebrachten digitalen Produkten unterscheidet?
• Existiert bereits eine doppelte Meldekette für den Ernstfall? NIS2-Einheitsmeldung und CRA-Produktmeldung — oder ist das noch nicht vorbereitet?
• Ist die eigene Compliance-Architektur so strukturiert, dass Engineering-Schicht, Organisations-Schicht und Produkt-Markt-Schicht klar getrennt sin? Oder wird versucht, alles in einem (anderen) Framework abzubilden? (Und wie gut klappt das?)

In einem Satz: Gute Automotive-Cybersecurity-Engineering-Arbeit bleibt inhaltlich unverändert; was sich mit NIS2 und CRA verschiebt, sind die Verantwortlichkeiten im Unternehmen, die Konsequenzen bei Lücken und der öffentlich-rechtliche Rahmen, in dem Produkte künftig zusätzlich zur Typgenehmigung bestehen müssen.