Kurzfassung.

Die BIS-Connected-Vehicle-Regelung ist seit 17. März 2025 in Kraft. Die Attestierungsfristen für Hardware-Herkunft und Software-Herkunft sind MY2027 bzw. MY2030. Die Lieferketten-Governance ist das Betriebsmodell, das die Regelung überlebbar macht.

Warum diese Regelung anders ist als eine Verbraucher-Tech-Beschränkung

Die endgültige Regelung des U.S. Department of Commerce (Bureau of Industry and Security, BIS) zur Sicherung der Lieferkette für Informations- und Kommunikationstechnologie bei vernetzten Fahrzeugen trat am 17. März 2025 in Kraft. Sie verbietet, dass bestimmte vernetzte Fahrzeugtechnologien mit Verbindungen zur Volksrepublik China oder zu Russland in den US-Markt eingeführt werden. Die Software-Verbote gelten ab Modelljahr 2027, die Hardware-Verbote ab Modelljahr 2030 (oder ab 1. Januar 2029 für Komponenten ohne Modelljahr).

Was die Regelung von typischen Importbeschränkungen unterscheidet, ist nicht eine einzelne Komponentenliste, sondern die Anforderung an Hersteller (Fahrzeug-OEMs und bestimmte Hardware-Importeure), nachzuweisen, dass die in der Lieferkette enthaltene Software und Hardware nicht aus den genannten Ländern stammen oder von ihnen beeinflusst werden. Das ist eine Behauptung über Architektur, Komponentenherkunft und Software-Inhaltskette, nicht über das fertige Produkt allein.

Für Lieferanten und Zulieferer bedeutet dies, dass sie nicht nur eine Komponente liefern, sondern auch die Beweismittel mitliefern müssen, die zeigen, woraus die Komponente besteht und wer an ihrer Erstellung beteiligt war. Für OEMs bedeutet dies, dass sie Lieferantenbeweise konsumieren und in eine einzige, prüfbare Erklärung pro Fahrzeugmodell und Modelljahr verdichten müssen.

Was die Regelung tatsächlich abdeckt

Die Regelung gilt für "Connected Vehicle Systems" (VCS) und "Automated Driving Systems" (ADS). VCS umfasst die Telematik-Kontrolleinheit (TCU), die Steuergeräte, die Funkkommunikation aktivieren, die Mobilfunk- und Satellitenfunkmodule, Wi-Fi- und Bluetooth-Module sowie das fahrzeuginterne Betriebssystem, das diese Schnittstellen verwaltet. ADS umfasst die Hardware und Software, die für SAE-Level-3- bis Level-5-Autonomie verwendet werden.

Beide Bereiche stehen unter besonderer Aufsicht, weil sie die kritische Verbindung zwischen Fahrzeug und Außenwelt darstellen oder weil sie die Kontrolle über fahrzeugkritische Funktionen ohne menschliche Aufsicht haben. Die Regelung erkennt, dass diese Subsysteme die wahrscheinlichsten Angriffspfade für ausländische Bedrohungsakteure sind und dass die Vertrauensgrundlage durch die Software- und Hardwareherkunft entlang der gesamten Wertschöpfungskette bestimmt wird.

Der Zeitplan für die Umsetzung

Die wichtigsten Daten:

  • 17. März 2025: Die Regelung tritt in Kraft. Die Pflicht zur Konformitätserklärung gilt für Importeure von VCS-Komponenten ab diesem Datum, obwohl die ersten Erklärungen erst für spätere Modelljahre fällig werden.
  • Modelljahr 2027: Verbote für Software gelten. Fahrzeuge des Modelljahres 2027 oder später dürfen keine VCS-Software enthalten, die einer Person mit Sitz in den genannten Ländern unterliegt oder die in diesen Ländern entwickelt oder geliefert wurde.
  • Modelljahr 2030: Verbote für Hardware gelten. Die Hardware-Beschränkung ist um drei Jahre versetzt, um den Lieferanten Zeit zu geben, die physische Lieferkette anzupassen.
  • 1. Januar 2029: Für VCS-Hardware-Einheiten ohne Modelljahr-Zuordnung (z. B. Aftermarket-Komponenten) gilt eine kalendarische Frist statt einer modelljahrbasierten.

OEMs, die für die Modelljahre 2027 oder 2028 in den US-Markt liefern wollen, müssen heute Architekturentscheidungen treffen. Designentscheidungen für ein Fahrzeug, das in zwei Jahren auf den Markt kommt, werden gerade jetzt eingefroren, einschließlich der Auswahl der Telematik-, Konnektivitäts- und Software-Stack-Lieferanten. Die Lieferantenverhandlungen und die Bewertungen der Herkunft müssen weit vor der ersten Produktion stattfinden.

Warum normale Stücklisten nicht ausreichen

Die meisten Fahrzeug-Stücklisten verfolgen Komponenten und Lieferanten der Stufe 1. Die Regelung erfordert jedoch Nachweise weit über das hinaus, was eine herkömmliche Stückliste enthält. Sie müssen wissen, woher die Software stammt — nicht nur, welcher Tier-1-Lieferant sie liefert, sondern auch, welche Tier-2- oder Tier-3-Unternehmen sie entwickelt haben und ob diese Unternehmen Verbindungen zu den genannten Ländern haben.

Bei eingebetteter Software bedeutet dies, eine Software-Stückliste (SBOM) auf Komponentenebene zu pflegen, die jede Bibliothek, jedes Modul und jede Toolchain einschließt, die in den Build-Prozess eingeflossen sind. Bei Hardware bedeutet dies, die Herkunft der Halbleiter, der eingebetteten Firmware in Subkomponenten und der Fertigungsbetriebe nachzuverfolgen. Beide Spuren müssen für die Konformitätserklärung zusammengeführt werden.

Mit der Klassifizierung von Produkten und Transaktionen beginnen

Bevor Sie Lieferanten kontaktieren, müssen Sie wissen, was in den Anwendungsbereich der Regelung fällt. Eine grobe Klassifizierungs-Übung sollte folgendes leisten:

  • Identifizieren Sie alle Komponenten, die VCS oder ADS gemäß der Regelungsdefinition sind. Dies sind nicht nur die offensichtlichen Telematik-Module — es schließt jedes Steuergerät ein, das mit der Außenwelt kommuniziert oder das Telematik-Daten verarbeitet.
  • Klassifizieren Sie für jede Komponente, ob sie Hardware, Software oder beides ist. Eine TCU ist ein Hardware-Produkt, aber sie führt Software aus, die separat klassifiziert werden muss.
  • Identifizieren Sie, welche Modelljahre den Verboten unterliegen. Ein Fahrzeug, das im Jahr 2026 als Modelljahr 2027 in Produktion geht, unterliegt den Software-Verboten ab dem ersten Produktionsfahrzeug.
  • Klassifizieren Sie Komponenten als "betroffen" oder "nicht betroffen". Eine Komponente, die nur in nicht-US-Märkten verkauft wird, ist nicht betroffen, muss aber dennoch identifiziert werden, falls sich die Marktstrategie ändert.

Diese Übung mag trivial erscheinen, aber bei einem Programm mit Hunderten von Steuergeräten ist es leicht, Komponenten zu übersehen, die in den Geltungsbereich fallen. Eine sorgfältige Klassifizierung schafft die Grundlage für alles, was folgt.

Ein Inventar abgedeckter Technologien aufbauen

Sobald die Klassifizierung abgeschlossen ist, müssen Sie für jede betroffene Komponente ein vollständiges Herkunfts-Profil erstellen. Dies umfasst:

  • Hardware-Herstellungsstandort und -besitz: Wo wird die Komponente gefertigt? Wer besitzt die Fertigungsstätte und die Designrechte?
  • Software-Lieferkette: Wer hat die Software geschrieben? Welche Open-Source-Komponenten sind enthalten? Welche Toolchain wurde verwendet?
  • Subkomponenten-Inventar: Welche Halbleiter, Module und Bibliotheken sind in der Komponente enthalten? Wer hat sie hergestellt oder geschrieben?
  • Beschäftigte und Unterauftragnehmer: Welche Firmen und Personen waren an Design, Entwicklung oder Wartung beteiligt? Haben sie Verbindungen zu den genannten Ländern?
  • Updates und Wartung: Wer kann die Komponente nach der Produktion ändern? Wie werden Updates ausgeliefert?

Dieses Inventar muss dynamisch sein. Lieferantenwechsel, Komponenten-Substitutionen und Software-Updates ändern alle das Herkunfts-Profil. Eine Momentaufnahme zum Zeitpunkt der Konformitätserklärung reicht nicht aus — das Inventar muss während der gesamten Lebensdauer des Modells aktuell gehalten werden.

Lieferanten-Due-Diligence, die über einen Fragebogen hinausgeht

Ein Cybersecurity-Fragebogen reicht für die Regelung nicht aus. Sie müssen tiefer gehen: Sie müssen die Eigentümerstruktur der Lieferanten verifizieren, ihre Software-Lieferkette validieren und ihre Fähigkeit prüfen, die geforderten Bescheinigungen für eine zukünftige Lieferung über mehrere Modelljahre hinweg zu liefern.

Eine wirksame Due-Diligence umfasst:

  • Eigentumsverifikation: Wer kontrolliert das Unternehmen? Welche Investoren und Vorstandsmitglieder gibt es? Welche Verbindungen zu Personen oder Firmen mit Sitz in den genannten Ländern bestehen?
  • Standortverifikation: Wo sind die Forschungs- und Entwicklungszentren? Wo befindet sich die Fertigung? Wo werden die Daten gehostet?
  • Software-Lieferkette des Lieferanten: Welche Open-Source-Komponenten verwendet der Lieferant? Wie verwaltet er Schwachstellen-Updates? Wer hat Zugriff auf den Quellcode?
  • Operative Sicherheit: Welche Zugangskontrollen, Hintergrundprüfungen und Aufsichten gelten für die Entwicklungs-Teams?
  • Vertragsbedingungen: Welche Vertragsklauseln verpflichten den Lieferanten zur Offenlegung von Eigentumsänderungen, Subunternehmern oder Software-Lieferkettenänderungen?

Software- und Hardware-Klassifizierung: zwei verschiedene Probleme

Die Regelung behandelt Software und Hardware unterschiedlich, und die Compliance-Prozesse müssen das widerspiegeln. Software ist beweglicher: Sie kann mit jedem Update ihren Charakter ändern, eine neue Bibliothek aus einer anderen Quelle einbeziehen oder von einer anderen Person geändert werden. Hardware ist physischer: Sie ändert sich nur, wenn sie ausgetauscht wird.

Für Software brauchen Sie eine SBOM auf Build-Ebene, die für jedes ausgelieferte Update aktualisiert wird. Für Hardware brauchen Sie eine Komponentenliste mit Herkunfts-Nachweisen, die sich nur bei Änderungen der physischen Lieferkette aktualisiert.

Beide müssen mit der Bauteilnummer und dem Modelljahr verknüpft werden, damit Sie eine spezifische Konformitätserklärung pro Modelljahr und Variante generieren können.

Die Compliance-Erklärung als operative Datenkette

Die Konformitätserklärung ist nicht ein einmaliges Dokument. Sie ist eine fortlaufende Datenkette, die zeigt, dass Ihre Lieferkette über die gesamte Modelljahr-Laufzeit konform bleibt. Wenn sich ein Lieferant ändert, wenn eine Komponente substituiert wird oder wenn ein Software-Update ausgeliefert wird, muss die Erklärung aktualisiert werden — und die Aktualisierung muss durch das Beweismittel-System gestützt werden, das die Klassifizierung, Herkunft und Verifikation der neuen Komponente zeigt.

Praktisch bedeutet dies, dass Ihre Compliance-Erklärung mit Ihren Engineering-, Beschaffungs- und Software-Update-Workflows verbunden sein muss. Eine isolierte Compliance-Datenbank, die manuell aus Quellsystemen aktualisiert wird, wird die Realität nicht überleben.

Software-Updates und die Compliance-Frage

Software-Updates sind die schwierigste laufende Compliance-Anforderung. Jedes Update muss bewerten, ob neue Komponenten von Personen oder Firmen aus den genannten Ländern stammen. Wenn eine neue Open-Source-Bibliothek hinzugefügt wird, muss diese Bibliothek überprüft werden. Wenn ein neuer Tier-2-Lieferant beauftragt wird, muss er einer Due-Diligence unterzogen werden.

Praktisch erfordert dies einen Compliance-Schritt im OTA-Update-Pipeline, der vor dem Auslieferungs-Freigabe-Schritt liegt. Wenn die Compliance nicht gewährleistet ist, kann das Update nicht ausgeliefert werden, oder es muss eine Lieferkette- oder Komponentenänderung initiiert werden, bevor das Update freigegeben wird.

Aftermarket-Komponenten und der Aftersales-Markt

Die Regelung erstreckt sich auf den Aftermarket. Wenn ein OEM oder ein Drittanbieter eine Ersatz-Telematik-Einheit für ein bestehendes Fahrzeug verkauft, muss diese Einheit den gleichen Verboten unterliegen, wenn das ursprüngliche Fahrzeug ein Modelljahr 2027+ ist. Aftermarket-Hardware ohne Modelljahr-Zuordnung muss die Frist vom 1. Januar 2029 einhalten.

Dies erfordert eine Aftersales-Komponentenstrategie. OEMs müssen entscheiden, ob sie ihre eigene Aftermarket-Versorgung aufrechterhalten oder ob sie sich auf Dritthersteller verlassen, die die gleichen Lieferkettenbeschränkungen einhalten. Die Aftersales-Kette muss in die Compliance-Strategie integriert werden, nicht erst nachträglich.

Die Konformitäts-Audit-Erfahrung

Wenn BIS Sie auditiert, müssen Sie nicht nur eine Erklärung vorlegen, sondern auch die Beweismittel zur Untermauerung. Dies umfasst:

  • Eine vollständige SBOM auf Komponentenebene für die zertifizierten Modelle und Modelljahre.
  • Lieferantenbescheinigungen für jeden Tier-1, Tier-2 und Tier-3, der in den Geltungsbereich fällt.
  • Eigentümer- und Standortverifikations-Berichte für betroffene Lieferanten.
  • Die Audit-Trail der Compliance-Erklärung, die zeigt, wer was wann genehmigt hat.
  • Aufzeichnungen über alle Komponentenänderungen, Software-Updates und Lieferanten-Substitutionen, die seit der ersten Erklärung erfolgt sind.

Die Vorbereitung dieser Beweismittel ist die Hauptherausforderung. Wenn die Beweismittel in einem Knowledge-Graph mit dem Konformitätserklärungs-System verbunden sind, kann jedes Audit-Element direkt aus der Quellsystem heruntergezogen werden. Andernfalls ist es ein manueller Sucheinsatz pro Audit, was unter Zeitdruck riskant ist.

Ein Implementierungs-Plan für den nächsten Quartal

Wochen 1-4: Klassifizierung und Inventar

Klassifizieren Sie alle Komponenten Ihrer in Frage kommenden Modelljahre. Erstellen Sie das Inventar der betroffenen Komponenten und die Verbindungen zu Tier-1-Lieferanten.

Wochen 5-8: Tier-2- und Tier-3-Kartierung

Erweitern Sie das Inventar auf Tier-2- und Tier-3-Lieferanten. Identifizieren Sie, welche Subkomponenten und Software-Komponenten aus den genannten Ländern stammen oder Verbindungen zu ihnen haben.

Wochen 9-12: Lieferanten-Verhandlungen

Verhandeln Sie Vertragsbedingungen mit allen Tier-1-, Tier-2- und Tier-3-Lieferanten in Bezug auf Bescheinigung, Offenlegung und Compliance-Verpflichtung. Bestätigen Sie, welche Komponenten ersetzt werden müssen.

Wochen 13-16: Pilot-Konformitätserklärung

Erstellen Sie eine Pilot-Konformitätserklärung für ein in-Scope-Fahrzeugmodell. Identifizieren Sie Lücken, fehlende Beweismittel und schlecht dokumentierte Komponenten. Verfeinern Sie den Prozess.

Wochen 17-24: Operativer Roll-out

Rollen Sie das Compliance-Programm auf alle in-Scope-Modelle aus. Integrieren Sie die Compliance-Schritte in OTA-Update-Pipelines, Beschaffungs-Workflows und Engineering-Change-Management.

Wie eine vernetzte Beweismittel-Plattform hilft

Eine Konformitätserklärung ist nur so vertrauenswürdig wie die Beweismittel, die sie stützen. Wenn Sie versuchen, die Erklärung aus isolierten Tabellen, Lieferantenfragebögen und Engineering-Datenbanken zusammenzuführen, ist das Risiko von Lücken und Widersprüchen hoch. Eine vernetzte Plattform, die Komponenten, Lieferanten, SBOMs, Bescheinigungen und Genehmigungs-Workflows in einem Knowledge-Graph verbindet, ermöglicht es, dass jede Erklärung aus den aktuellen Engineering-Datensätzen abgeleitet wird, anstatt dass sie separat zusammengestellt werden muss.

Mit ThreatZ können OEMs und Tier-1-Lieferanten die Lieferketten-Beweismittel mit ihrer bestehenden TARA, SBOM und Compliance-Infrastruktur verbinden. Die Konformitätserklärung wird zu einer Sichtweise auf die bestehenden Engineering-Datensätze, nicht zu einer parallelen Compliance-Übung.

Häufig gestellte Fragen

Gilt die Regelung für Fahrzeuge, die außerhalb der USA verkauft werden?

Nein. Die Regelung betrifft nur Fahrzeuge, die für den US-Markt bestimmt sind. Wenn Ihr OEM jedoch globale Plattformen mit US-Marktversorgung produziert, ist die Lieferkette des US-Markt-Versions-Fahrzeugs der Regelung unterworfen, auch wenn die Plattform global ist.

Was passiert, wenn ein Tier-3-Lieferant ohne mein Wissen einen unter-Verbot stehenden Komponentenbeitrag macht?

Die Regelung verlangt eine Sorgfaltspflicht, nicht Perfektion. Wenn Sie nachweisen können, dass Sie eine systematische, dokumentierte Due-Diligence durchgeführt haben und dass die fehlerhafte Lieferung im guten Glauben übersehen wurde, ist Ihre Verteidigung stärker. Aber die Sorgfaltspflicht muss real sein — nicht ein Checklisten-Eintrag — und die Beweismittel müssen verfügbar sein.

Sind reine Hardware-Komponenten ohne Software vom Geltungsbereich ausgeschlossen?

Nicht unbedingt. Wenn die Hardware ein VCS-Element ist (z. B. ein Mobilfunkmodul), unterliegt sie dem Hardware-Verbot ab MY2030, auch wenn die Software in einer separaten Komponente läuft. Die Klassifizierung als VCS hängt von der Funktion ab, nicht von der Hardware-Software-Kombination.

Wie verhält sich diese Regelung zu UNECE R155?

Die beiden Regelungen sind getrennt. R155 ist eine Cybersicherheits-Management-Regelung, die für Typgenehmigungen weltweit gilt. Die BIS-Regelung ist eine Lieferketten-Herkunfts-Regelung, die nur für den US-Markt gilt. Sie können nicht die R155-Konformität als Ersatz für die BIS-Konformität verwenden. Beide haben unterschiedliche Beweismittel-Anforderungen.

Was ist die größte Herausforderung in der Praxis?

Die Tier-2- und Tier-3-Sichtbarkeit. Die meisten OEMs haben gute Sichtbarkeit auf Tier-1-Lieferanten, aber Tier-2 und tiefer wird oft nur über Vertragsklauseln statt über tatsächliche Daten verwaltet. Die Regelung erfordert Daten, nicht Klauseln, und das Aufbauen dieser Sichtbarkeit ist die größte operative Herausforderung.

Weiterführende Beiträge auf VxLabs

Maßgebliche Quellen

  • BIS Final Rule on Connected Vehicles — Federal Register, 16. Januar 2025
  • U.S. Department of Commerce, Bureau of Industry and Security, Office of Information and Communications Technology and Services