Wenn Sie beruflich über die Beschaffung oder den Betrieb vernetzter Geräte entscheiden, liegt seit Sommer 2026 ein Satz auf dem Tisch, der genau Ihre Rolle anspricht — im Fuhrpark, in der Klinik-IT, im Werk, in der Kommune oder in einem Betrieb mit Drohnen und Servicerobotern. Er stammt allerdings nicht aus Deutschland. Der schweizerische Nachrichtendienst des Bundes (NDB) schreibt in seinem Lagebericht „Sicherheit Schweiz 2026“ vom 25. Juni 2026:

„Realistisch ist zum Beispiel, dass Daten, die moderne chinesische Fahrzeuge während ihrer Nutzung produzieren, via die Autohersteller an die chinesischen Dienste weitergeleitet werden oder dass die Nachrichtendienste via Schnittstellen Zugriff auf solche Daten haben oder bekommen werden. Diesen Aspekt müssen Personen und Organisationen in der Schweiz bei der Beschaffung chinesischer Fahrzeuge berücksichtigen. Das gilt insbesondere für die Personen und Organisationen, die zu den Hauptaufklärungszielen in der Schweiz zu zählen sind.“

Drei Sätze, drei Einschränkungen: eine Bewertung als realistisch, nicht ein festgestellter Vorgang; ein Beschaffungsauftrag, der für die Schweiz gilt; und ein Adressatenkreis, der ausdrücklich eng gezogen ist.

Für Deutschland gibt es diesen Satz bis heute nicht. Die Bundesregierung antwortet auf die entsprechende parlamentarische Frage, eine nationale Risikoanalyse werde derzeit erarbeitet, und ergänzt: „Konkrete Vorfälle sind der Bundesregierung nicht bekannt.“ Wer hier heute eine Flotte, einen Gerätepark oder eine Klinikausstattung beschafft, entscheidet also ohne behördlichen Anhaltspunkt — weder in die eine noch in die andere Richtung.

Damit dieser Beitrag lesbar bleibt, werden drei Ebenen durchgehend getrennt gehalten: der legitime Herstellerzugriff, der für Softwareupdates technisch nötig ist; die technische Missbrauchsmöglichkeit durch Dritte, die aus derselben Schnittstelle folgt; und der staatliche Zugriff, der bisher eine Risikohypothese bewertender Stellen ist. Zusammen bilden sie das, was hier Risikoschicht heißt: die Ebene aus dauerhafter Verbindung, Sensorik, Fernwartung und Update-Hoheit, die unabhängig von der Gerätegattung besteht. Was auf einer dieser Ebenen belegt ist, ist auf den anderen nicht automatisch belegt — und genau an dieser Stelle geht die öffentliche Debatte regelmäßig verloren.

Was die Bundesregierung prüft — und was in ihrer Antwort nicht steht

Die tragende Fundstelle ist die Antwort der Bundesregierung auf eine Kleine Anfrage, Bundestagsdrucksache 21/6433 vom 10. Juni 2026, dort Seite 11, Antwort zu Frage 28. Diese Antwort enthält eine innere Spannung, die beim Zitieren nicht verschwinden darf. Zuerst heißt es, ein Gesamtüberblick über einige Sicherheitsrisiken vernetzter Fahrzeuge sei „in der europäischen und in der nationalen Risikoanalyse erarbeitet“ worden; zwei Sätze später steht, eine nationale Risikoanalyse werde „derzeit“ erarbeitet.

Danach kommt der Satz, der die Debatte seither trägt: „Konkrete Vorfälle sind der Bundesregierung nicht bekannt.“ Das Wort „konkrete“ gehört dazu, denn ohne dieses Wort wäre die Aussage schärfer, als die Quelle sie macht.

Die Nachfolgedrucksache 21/7220 vom 20. Juli 2026 fügt technisch nichts hinzu; sie verweist für vernetzte Fahrzeuge chinesischer Hersteller auf die Antworten zu den Fragen 27, 28 und 30 der Drucksache 21/6433. Neu ist dort allein eine Einordnung der Lage: Die Bundesregierung geht „derzeit von abstrakten Missbrauchsgefahren bei der Nutzung der anfallenden Daten“ aus. Abstrakt ist ein Fachwort und keine Beschwichtigung — es bezeichnet eine Gefahr, die aus der Konstruktion folgt, nicht aus einem beobachteten Ereignis.

Substanz hat die Antwort dort, wo sie eigene Messungen referiert. Das BSI hat 2025 ein Projekt zur IT-Sicherheit fahrzeuggenerierter Daten durchgeführt. Die Fragesteller beziffern den Untersuchungsumfang unter Verweis auf Bundestagsdrucksache 21/732 auf fünf Fahrzeugmodelle, darunter drei von Nicht-EU-Herstellern; die Antwort selbst nennt keine Zahl. Die Antwort hält fest, die stichprobenartige Prüfung zeige den großen Umfang an Fahrzeugnutzungsdaten, auf den die Fahrzeughersteller Zugriff haben. Für ein einzelnes Fahrzeug nennt sie als Beispiele Geschwindigkeit, Bremsverhalten und Lenkwinkel.

Modelle, Messwerte und Datenziele stehen nicht in der Antwort. Für ein vollständiges Bild zum Datensendeverhalten seien fortlaufende Prüfungen und weitere Ressourcen erforderlich — eine bemerkenswert offene Aussage einer Bundesbehörde über den eigenen Erkenntnisstand.

Wo Sie sich von dieser Antwort die eigentliche Auskunft erhoffen, endet sie.

Zum gemeinsamen Projekt des Bundesamts für Verfassungsschutz und der Zentralen Stelle für Informationstechnik im Sicherheitsbereich (ZITiS), bei dem Fahrzeuge mehrerer chinesischer Hersteller untersucht wurden, verweigert die Bundesregierung die Antwort. Das gilt auch in eingestufter Form und auch gegenüber der Geheimschutzstelle des Bundestages, weil Aufklärungsprofile der Sicherheitsbehörden besonders schutzbedürftig seien. Diese Geheimhaltung beweist weder einen Fund noch eine Entwarnung. Für Ihre Entscheidung bedeutet sie schlicht, dass die eine Quelle, die den Streit beenden könnte, für Sie nicht existiert.

Für Sie heißt das dreierlei, und alle drei Punkte sind zeitpunktbezogen. Ein aggregiertes Lagebild über Nutzung und Präsenz solcher Fahrzeuge in Liegenschaften des Bundes, der Bundeswehr und in unmittelbarer Nähe kritischer Infrastrukturen (KRITIS) liegt nicht vor. In den Fuhrparks der Bundesministerien einschließlich des nachgeordneten Bereichs sowie der Bundeswehr befinden sich zum Antwortzeitpunkt keine Kraftfahrzeuge chinesischer Hersteller im Einsatz. Eine grundsätzliche Regelung der Bundesregierung für ihre eigenen Liegenschaften ist nicht erlassen. Es gibt damit keine Vorlage, an der Sie sich orientieren könnten, und keine Kennzahl, gegen die Sie Ihren eigenen Bestand vergleichen könnten. Länder, Kommunen, Klinikträger und KRITIS-Betreiber sind von der Fuhrpark-Aussage ohnehin nicht erfasst.

Nicht der Antrieb, nicht die Autonomie — die Vernetzung entscheidet

Die Debatte firmiert öffentlich unter „E-Autos“, und das ist der erste Fehler, der Ihnen Geld kosten kann.

Das Risiko folgt der Vernetzung und ist nicht auf Elektrofahrzeuge beschränkt; es betrifft vernetzte Verbrenner und Hybride genauso. Eine Prüfung, die am Antriebsstrang ansetzt, erfasst die falsche Hälfte des Fuhrparks und lässt jeden vernetzten Diesel-Transporter unangetastet. Bei Elektrofahrzeugen kommt die Lade- und Energiedatenschnittstelle als zusätzlicher Risikoraum hinzu, jedoch ist sie nicht die Ursache des allgemeinen Problems, sondern eine weitere Tür an demselben Haus.

Die technische Anlage steht in derselben Regierungsantwort und ist unstrittig. Externe Schnittstellen ermöglichen Fernzugriffe auf Daten und Ressourcen des Fahrzeugs; für die Aktualisierung von Fahrzeugkomponenten und deren Software sind sie erforderlich. Zugriffe auf diese Schnittstellen ermöglichen sich die Hersteller nach der Antwort grundsätzlich selbst, und bei modernen Fahrzeugarchitekturen bleibt teilweise eine Fernkontrolle über bestimmte Kernfunktionen bestehen.

Sensorik in Form von Kameras und Mikrofonen kann nach derselben Antwort zur Ausspähung genutzt werden. Technisch besteht außerdem das Risiko, dass solche Schnittstellen durch Dritte missbraucht werden — was eine Möglichkeit beschreibt und keinen beobachteten Angriff.

Auf europäischer Ebene liegt dazu seit dem 30. Januar 2026 eine koordinierte Risikobewertung zu vernetzten und automatisierten Fahrzeugen vor. Mitgliedstaaten, Kommission und ENISA haben darin 107 Risiken ermittelt und bewertet, von denen 14 als Toprisiken eingestuft sind; die Expertenbewertung dieser Spitzengruppe lautet kritisch in der Auswirkung und mittel in der Wahrscheinlichkeit. Die Bewertung ist rechtlich nicht bindend und akteursneutral angelegt, und der Begriff des Hochrisikoanbieters ist dort ein Arbeitsbegriff, keine veröffentlichte schwarze Liste.

Bemerkenswert für Ihre Beschaffung ist ihre Selbsteinschätzung: Viele der Toprisiken würden durch das geltende EU-Typgenehmigungsrecht adressiert, aber eben nicht alle — Lücken sieht die Bewertung gerade gegenüber organisierten, staatlich unterstützten Bedrohungen.

Von der Autonomie hängt das alles ebenfalls nicht ab. Ob ein Fahrzeug selbst fährt, entscheidet über Zulassung, Haftung und Betriebsbereich; ob es dauerhaft mit einem Backend spricht, entscheidet über die Risikoschicht, um die es hier geht. Die Trennung lohnt sich, weil beide Themen unterschiedliche Nachweise verlangen: Dort geht es um Autonomie und Zulassung, hier um Vernetzung und Betrieb. Welche Nachweise die Typgenehmigung über UN-Regelung Nr. 155 und Nr. 156 sowie über die Updatekette verlangt, steht in unserer Einordnung zu Typgenehmigung, Updatekette und Datenverfügung beim autonomen Fahren. Dieser Beitrag beantwortet die andere Frage, nämlich was ein dauerhaft verbundenes Gerät für Ihren Betrieb bedeutet.

Vier Stufen des Beweises — und wo die gemeldeten Schwachstellen liegen

Damit die Zahlen im weiteren Verlauf nicht falsch gelesen werden, hilft eine einfache Einteilung — sie ist eine redaktionelle Ordnung dieser Redaktion, kein Branchenmodell und keine behördliche Systematik.

Stufe eins ist die Fähigkeit: Ein Gerät besitzt eine Schnittstelle, die etwas ermöglicht. Stufe zwei ist die Schwachstelle: Eine konkrete Lücke ist registriert, mit Kennung, Bewertung und Datum, und hätte etwas erlaubt. Stufe drei ist die Ausnutzung, und die gibt es nur mit Fall, Datum und Registereintrag. Stufe vier ist die Zuordnung zu einem Akteur, und sie existiert ausschließlich als zitierte Bewertung einer benannten Stelle.

Eine belastbare öffentliche Messung dazu stammt vom BSI. Zwischen Februar 2024 und März 2025 hat es 107 Schwachstellen- und Vorfallsmeldungen bearbeitet. Erfasst sind darin Hard- und Software in Straßenfahrzeugen, IT-Dienstleistungen mit direkter Verbindung zu Fahrzeugen sowie Hard- und Software in der Straßeninfrastruktur, Ladeinfrastruktur und Funkstationen für intelligente Verkehrssysteme (C-ITS) eingeschlossen. Diese Zahl hat mit den 107 Risiken der europäischen Risikobewertung nichts zu tun: Dort sind Risiken bewertet worden, hier sind Meldungen gezählt worden. Dass beide Zählungen zufällig dieselbe Zahl tragen, ist die häufigste Verwechslung in diesem Themenfeld.

Interessanter als die Gesamtzahl ist die Verteilung, und dort verlaufen zwei verschiedene Nenner. Nach dem Zugriffsweg klassifiziert die Auswertung 67 Meldungen; in 18 davon geht es um Schwachstellen, die auch über das Internet ausnutzbar waren, während für die Mehrzahl räumliche Nähe oder physischer Zugriff nötig war. Nach dem Status der Schwachstelle klassifiziert die Auswertung 59 Meldungen. Meldungen, bei denen keine Klassifizierung möglich war oder die sich auf einen bereits bekannten Vorgang beziehen, wurden nicht gezählt. Deshalb ergeben 67 und 59 zusammen nicht 107, und deshalb ist jede Prozentangabe ohne Nennerangabe hier falsch.

Von 59 nach Status klassifizierten Meldungen sind 46 belegte Machbarkeitsnachweise, neun rein theoretisch und vier tatsächlich ausgenutzt.

Ein Großteil der Meldungen geht auf Sicherheitsanalysen oder Forschungsarbeiten zurück, und eine Ausnutzung mit kriminellem Hintergrund findet im Fahrzeugkontext nach der öffentlichen Datenlage eher selten statt. Beide Qualifizierungen — „öffentlich“ und „eher“ — stammen aus der Quelle und gehören dazu, sonst wird aus einer Beobachtung über Meldungen eine Aussage über die Wirklichkeit.

Für Ihre Reihenfolge im Betrieb ist die Zugriffswegverteilung die brauchbare Zahl. Wenn die Mehrzahl der gemeldeten Schwachstellen räumliche Nähe oder physischen Zugriff voraussetzt und 18 Meldungen auch über das Internet ausnutzbar sind, dann liegt das vordringliche Prüffeld bei Geräten mit permanenter Mobilfunkanbindung und Fernwartung. Ein Gerät ohne Weitverkehrsanbindung ist deshalb nicht harmlos, denn räumliche Nähe ist auf einem Werksgelände oder in einem Klinikflur schnell hergestellt. Es ist aber nachrangig, weil ein Angriffsweg, der Anwesenheit verlangt, andere Gegenmaßnahmen erlaubt als einer, der aus dem Netz kommt.

Eine Herkunftsangabe zur Beleglage selbst gehört dazu, weil sie erklärt, warum die Belege so aussehen, wie sie aussehen: Die belastbaren Schwachstellendaten stammen weit überwiegend aus US-amerikanischen Registern und Advisories. Eine deutsche Registrierung derselben Sachverhalte ist nicht belegt. Der Schluss, in Deutschland sei weniger passiert, verwechselt Meldewege mit Vorfällen.

Der Fall mit dem größten Umfang offengelegter Daten im BSI-Berichtszeitraum stammt aus Europa

Er hat mit China nichts zu tun, und er ist auch kein Spionagefall.

Verglichen wird dabei der Umfang offengelegter Daten, nicht die Zahl betroffener Fahrzeuge. Nach Zahl der Fahrzeuge liegt ein anderer Fall aus demselben Bericht vorn: ein Angriff auf Infotainment-Systeme in Fahrzeugen eines tschechischen Herstellers, vorgestellt auf der Black Hat Europe 2024. Die Forschenden fanden zwölf Schwachstellen, mit denen sich Schadcode einschleusen ließ; damit wäre es möglich gewesen, die Position des Fahrzeugs in Echtzeit zu verfolgen, Gespräche aufzuzeichnen und Bildschirmfotos anzufertigen. Betroffen waren nach ihrer Schätzung rund 1,4 Millionen Fahrzeuge. Das ist eine Schwachstelle der zweiten Stufe und kein belegter Datenabfluss: Die Forschenden informierten den Hersteller vor der Veröffentlichung, und dieser konnte die Lücken beheben.

Das BSI hält in seinem Branchenlagebild fest, dass der Chaos Computer Club im Dezember 2024 aufgedeckt hat, dass Positionsdaten von Elektrofahrzeugen eines deutschen Herstellers ungeschützt für Dritte über das Internet einsehbar waren. Über einen Konfigurationsfehler in einem verwendeten „Einwicklungsframework“ [sic] konnten Zugangsdaten wie Credentials, Nutzenden-IDs und Authentifizierungstoken zu Cloud-Instanzen des Herstellers erlangt werden. Der Fehler saß damit nicht im Fahrzeug, sondern im Backend — in genau der Schicht, die in Beschaffungsunterlagen selten auftaucht.

Der Umfang ist der Grund, warum dieser Fall am Anfang jeder Betroffenheitsprüfung stehen sollte. Betroffen waren nach Angaben des BSI Daten von ca. 800.000 Fahrzeugen und 600.000 Kundinnen und Kunden, darunter Name, E-Mail-Adresse, teilweise Telefonnummern und Postadressen. Über einen längeren Zeitraum angefahrene Orte waren teilweise zentimetergenau im Cloud-System gespeichert.

Diese Daten hätten, so das BSI wörtlich, „zur Erstellung von Bewegungsprofilen von Privatpersonen und auch von Mitarbeitenden in Sicherheitsbehörden eingesetzt werden können“. Der Konjunktiv steht so in der Quelle und bleibt hier stehen: Belegt ist die Möglichkeit, nicht ihre Verwirklichung.

Ebenso vollständig gehört die Entwarnung dazu, die dieselbe Quelle mitliefert. Der Chaos Computer Club hatte im Vorfeld den Hersteller, die zuständige Datenschutzbehörde und das BSI über den Sachverhalt informiert; der Fehler wurde umgehend behoben; ein tatsächlicher Datenabfluss an Dritte hat nach Angaben des Herstellers nicht stattgefunden. Diese letzte Aussage ist eine Unternehmensangabe und keine behördliche Feststellung, und sie bleibt es auch dann, wenn sie in einem Behördenbericht wiedergegeben wird. Die Zahlen 800.000 und 600.000 stammen umgekehrt allein aus dem BSI-Bericht. Die Veröffentlichung des Clubs vom Dezember 2024 spricht von hunderttausenden Betroffenen und benennt dafür Konzern und Softwaretochter namentlich — als Angabe des Clubs, nicht als Feststellung einer Behörde. Das BSI selbst nennt den Hersteller nicht, und dieser Beitrag folgt darin dem BSI.

Ein zweiter Fall aus demselben Bericht zeigt dieselbe Schicht aus einem anderen Winkel. Im Januar 2025 hat ein Sicherheitsforscher mehrere Schwachstellen in einem Web-Portal eines japanischen Fahrzeugherstellers entdeckt, das als Admin-Portal diente.

Nach der Darstellung des Berichts hätten sich Mitarbeitenden-Passwörter ohne weitere Verifikation neu setzen lassen, sofern eine Mitarbeiter-E-Mail-Adresse bekannt war; die aktivierte Zwei-Faktor-Abfrage hätte sich durch clientseitige Modifikation des Webseiten-Codes umgehen lassen. Mit vollem Portalzugriff waren Positionsdaten von Fahrzeugen in den USA, Kanada und Japan über das zurückliegende Jahr abrufbar — allerdings nur mit Kenntnis der Fahrzeug-Identifikationsnummer oder des Namens und der Postleitzahl. Über das Portal wäre es zudem möglich gewesen, fremde Fahrzeuge zu öffnen oder zu starten. Behoben wurden die Schwachstellen nach Bekanntwerden ebenfalls.

Für Ihre Beschaffung folgt daraus eine unbequeme Einsicht. Kein herkunftsbezogenes Ausschlusskriterium hätte einen dieser beiden Fälle verhindert, denn der eine betrifft einen deutschen, der andere einen japanischen Hersteller.

Was beide Fälle verbindet, ist ein Merkmal, das Sie abfragen können: Wo werden die Daten verarbeitet, wer hat administrativen Zugriff auf das Portal, und wie ist dieser Zugriff abgesichert? Wenn Sie in Ihrer Prüfliste nur ein einziges Feld ergänzen, dann dieses — weil beide hier geschilderten Datenfälle genau dort entstanden sind und nicht am Fahrzeug.

Was über chinesische Hersteller belegt ist — und was Bewertung bleibt

Auf der Stufe der Zuordnung wird die Quellenlage dünn, und sie besteht ausschließlich aus Bewertungen benannter Stellen.

Die Bundesregierung hält staatliche Einflussnahme auf einen Hersteller — über entsprechende rechtliche Vorschriften, aber auch rein politischer Art — mit technischen Mitteln für nicht ausschließbar, und sie begründet das zusätzliche Risiko unter anderem mit chinesischen Kooperations- und Zugriffspflichten. In der Nachfolgedrucksache heißt es dazu, die chinesische Gesetzgebung verpflichte Unternehmen zur Zusammenarbeit mit Regierung und Nachrichtendiensten und könne staatlichen Stellen weitreichende Einsicht in ihre IT-Systeme gewähren; technologische Abhängigkeiten könnten deshalb dazu führen, dass über vernetzte Komponenten generierte Daten entsprechend abfließen. Das ist eine Rechtsbewertung der Bundesregierung über eine fremde Rechtsordnung, keine Feststellung über einen Datenfluss.

Dieselbe Drucksache setzt den Gegenpol selbst — in der Antwort zu Frage 28 und, für die fehlende Ausschlussmöglichkeit, in der Antwort zu Frage 27: Der Betrieb vernetzter Fahrzeuge erzeugt danach, insbesondere bei nicht ordnungsgemäßer Verwendung, grundsätzlich bestimmte IT-Risiken; eine Möglichkeit, diese Risiken gezielt für bestimmte Hersteller auszuschließen, besteht zurzeit nicht; und Typgenehmigung wie Marktüberwachung sind für den deutschen Markt herstellerübergreifend geregelt. Genau darin liegt der Grund, warum die brauchbaren Merkmale weiter unten funktionsbezogen sind.

Auf der Regelseite ist mehr belegt, als meist zitiert wird, allerdings mit einem engen Geltungsbereich. Für wichtige, in China erzeugte Fahrzeugdaten gelten dort Inlandspeicherung und eine Sicherheitsprüfung vor der Übertragung ins Ausland; eine Richtlinie mehrerer Behörden vom 30. Januar 2026 schreibt diesen Stand fort. Dieser Rahmen betrifft die Verarbeitung in China und lässt sich nicht ohne Weiteres auf Exportfahrzeuge übertragen, die in Europa betrieben und aus europäischen Rechenzentren bedient werden. Eine Übertragung geht deshalb an der Sache vorbei — und wer den Rahmen ganz ignoriert, übersieht, dass Datenhoheit dort ausdrücklich als Sicherheitsfrage behandelt wird.

Wie eine funktionsbezogene Antwort aussehen kann, zeigt Polen. Die Antwort des dortigen Verteidigungsministeriums auf eine parlamentarische Interpellation vom 26. März 2026 knüpft die Zugangsregel für militärische Objekte an die Sensor- und Kommunikationsfähigkeit des Fahrzeugs an und nicht ausschließlich an das Produktionsland. Zugang kann danach unter Bedingungen möglich sein, wenn entsprechende Funktionen deaktiviert und Präventionsmaßnahmen angewandt werden; die Regeln sind objektspezifisch und keine allgemeine Ausnahme.

Zurück zur Schweizer Bewertung, mit der dieser Beitrag begonnen hat, weil sie den Rahmen absteckt, in dem eine solche Aussage überhaupt trägt. Der Nachrichtendienst des Bundes bewertet die Weiterleitung von Nutzungsdaten moderner chinesischer Fahrzeuge an chinesische Dienste sowie einen Schnittstellenzugriff dieser Dienste als realistisch; er richtet daraus einen ausdrücklichen Beschaffungsauftrag an Personen und Organisationen in der Schweiz; und er beschränkt diesen Auftrag ausdrücklich auf jene, die zu den Hauptaufklärungszielen in der Schweiz zu zählen sind.

Alle drei Teile gehören zusammen. Ein dokumentierter Einzelfall steht nicht dabei, und ohne die dritte Einschränkung würde aus einer nachrichtendienstlichen Lagebewertung für einen engen Kreis eine allgemeine Warnung, die so nirgends steht.

Für Ihre eigene Prüfung ist an dem polnischen Beispiel die Bauart brauchbar, nicht das Ergebnis: Sensorik, Kommunikationsfähigkeit und Abschaltbarkeit sind Eigenschaften, die Sie an einem Gerät feststellen können, und sie setzen an einer Eigenschaft an statt an einer Adresse. Ob und wie sich daraus eine tragfähige Anforderung formulieren lässt, hängt vom jeweiligen Vergaberegime ab und ist hier nicht geprüft.

Der 5G-Fall — wo der Hebel wirklich saß

Der einzige ausgeschriebene Präzedenzfall für eine europäische Antwort auf ein solches Risiko liegt im Mobilfunk. Er wird gern als Verbot erzählt, und das ist er in Deutschland nicht.

Das Bundesinnenministerium hat am 11. Juli 2024 mitgeteilt, dass es nach individuellen Verhandlungen mit den drei Mobilfunkbetreibern eine Einigung erzielt habe; öffentlich-rechtliche Verträge mit allen drei Betreibern „werden aktuell unterzeichnet“. Diese Formulierung kündigt einen Vollzug an, sie belegt ihn nicht — und sie beschreibt einen Vertrag, keine Untersagung.

Der Inhalt ist enger, als die Schlagzeilen nahelegen. Die Verträge verpflichten die Mobilfunkbetreiber, bis spätestens Ende 2026 keine kritischen Komponenten der Hersteller Huawei und ZTE mehr in ihren 5G-Kernnetzen einzusetzen. In den Zugangs- und Transportnetzen sind bis Ende 2029 die kritischen Funktionen der 5G-Netzwerkmanagementsysteme dieser Hersteller durch technische Lösungen anderer Hersteller zu ersetzen. Zur Funk- und Antennentechnik selbst trifft die Mitteilung keine Aussage; sie benennt allein die zu ersetzenden kritischen Komponenten und kritischen Funktionen. Der Vorspann der Mitteilung lässt das Wort „kritische“ in der Kernnetz-Aussage weg, der Fließtext führt es zweimal; maßgeblich ist der Fließtext. Abgeschlossen wurden damit die Prüfverfahren nach § 9b Abs. 4 BSI-Gesetz in der bis zum 5. Dezember 2025 geltenden Fassung.

Auf europäischer Ebene existiert dazu eine Bewertung, aber kein Rechtsakt. In ihrer Mitteilung vom 15. Juni 2023 hält die Kommission fest, dass Entscheidungen von Mitgliedstaaten zur Beschränkung oder zum Ausschluss von Huawei und ZTE gerechtfertigt und mit dem 5G-Werkzeugkasten vereinbar seien, und sie führt aus, dass beide Anbieter aus ihrer Sicht materiell höhere Risiken darstellten als andere 5G-Zulieferer.

Das ist die Bewertung der Kommission, mit der Kommission als Urheberin — und nicht die Feststellung dieses Beitrags. Eine europaweite Untersagung folgt daraus nicht.

Die Zeile, auf die es ankommt, betrifft aber gar nicht die Netze, sondern die Software. Eine US-amerikanische Ausfuhrbeschränkung aus dem Jahr 2019 wirkte sich mittelbar auf die Lizenzierung eines Betriebssystem-Ökosystems aus; nach übereinstimmenden sekundären Darstellungen betraf der Wegfall der Dienste ausschließlich neue Geräte, während bereits verkaufte Geräte weiterliefen. Eine Primärquelle dafür liegt uns nicht vor, weshalb diese Angabe hier ausdrücklich als sekundär gekennzeichnet ist. Die Zeile zeigt trotzdem, wo der Hebel wirklich saß: nicht an der Hardware und nicht an der Herkunft, sondern an der Software- und Update-Lizenz.

Übersetzt auf Ihre Lage lautet die Frage nicht, ob ein Gerät verboten wird, sondern was passiert, wenn nicht das Gerät, sondern seine Update-Lizenz wegfällt — in Ihrer Flotte, Ihrem Gerätepark, Ihrer Klinik. Die Antwort liegt in derselben Zeile: Betroffen waren neue Geräte, der Bestand lief weiter. Für Sie heißt das, dass das Risiko in der Nachbeschaffung und im Update- und Ersatzteilpfad liegt, nicht im laufenden Betrieb.

Ein Betrieb mit zwanzig gleichen Geräten, der in drei Jahren zehn weitere braucht, hat sein Problem nicht heute, sondern beim einundzwanzigsten. Die politische Vorgeschichte solcher Beschränkungen und ihre Ausdehnung auf andere Gerätegattungen behandeln wir getrennt in der Analyse zu Marktzugangsbeschränkungen bei humanoiden Robotern zwischen China und den USA.

Was Sie heute vom Hersteller verlangen können

Die praktische Frage lautet: Welches Instrument zwingt einen Hersteller, Ihnen Auskunft zu geben, Audits zu ermöglichen oder eine Zusage schriftlich abzugeben? Die ernüchternde Antwort ist, dass das schärfste dieser Instrumente im deutschen Recht seit Dezember 2025 nicht mehr existiert.

Das BSI-Gesetz wurde durch Gesetz vom 2. Dezember 2025 neu gefasst; der hier zitierte Wortlaut ist der konsolidierte Stand nach der Änderung durch Artikel 8 Absatz 1 des Gesetzes vom 23. Juli 2026. Tragende Norm für kritische Komponenten ist jetzt § 41 BSIG.

§ 41 BSIG ist eine Befugnisnorm und kein Beschaffungsraster, und die erste Frage daran lautet, ob er Ihr Haus überhaupt erreicht. Adressat ist nach Absatz 1 der Betreiber kritischer Anlagen. Auch Absatz 5 verlangt Mitwirkung bei der Sachverhaltsermittlung von ihm und nicht vom Hersteller. Für Sie gilt das nur, wenn Ihr Haus unter die kritischen Anlagen fällt; für alle übrigen Betriebe greift § 41 BSIG von vornherein nicht.

Wer dazugehört, bestimmt sich derzeit nach einer Übergangsregelung. § 66 BSIG ordnet an, dass die Begriffsbestimmung der kritischen Anlage in § 2 Nr. 22 erst anzuwenden ist, wenn die Rechtsverordnung nach § 4 Abs. 3 und § 5 Abs. 1 KRITIS-Dachgesetz in Kraft getreten ist. Bis dahin gilt die bis einschließlich 16. März 2026 geltende Fassung weiter.

Was das Instrument selbst erlaubt, steht in den Absätzen 1 bis 4. Nach Absatz 1 kann das Bundesministerium des Innern im Benehmen mit dem für den jeweiligen Sektor genannten Bundesministerium — für Informationstechnik und Telekommunikation ist das das Bundesministerium für Digitales und Staatsmodernisierung — sowie mit dem Auswärtigen Amt gegenüber dem Betreiber kritischer Anlagen den Einsatz kritischer Komponenten eines Herstellers untersagen oder Anordnungen dazu erlassen, wenn der Einsatz die öffentliche Ordnung oder Sicherheit der Bundesrepublik Deutschland voraussichtlich beeinträchtigt. Absatz 2 erlaubt die Erstreckung auf den zukünftigen Einsatz weiterer kritischer Komponenten desselben Herstellers und desselben Komponententyps sowie auf alle Betreiber kritischer Anlagen. Erstreckt das Ministerium die Entscheidung nach Absatz 2 Satz 1 Nummer 2 auf alle Betreiber, ordnet Absatz 3 Satz 1 sie ausdrücklich als Allgemeinverfügung ein. Ob die Untersagung gegenüber einem einzelnen Betreiber dieselbe Form hat, sagt der Wortlaut nicht. Widerspruch und Klage haben nach Absatz 3 Satz 2 in beiden Fällen keine aufschiebende Wirkung. Absatz 4 nennt keine abschließenden Kriterien, sondern Gesichtspunkte, die insbesondere berücksichtigt werden können — darunter die Kontrolle des Herstellers durch einen Drittstaat oder eine Verpflichtung zur Zusammenarbeit mit dessen Stellen.

Der Anwendungsbereich hängt zudem an einer zweiten Definition, die ins Leere greifen kann. Kritische Komponenten bestimmt § 2 Nr. 23 BSIG über eine Rechtsverordnung nach § 56 Abs. 6, die das Innenministerium sektorweise erlassen kann. Eine solche Rechtsverordnung für Informationstechnik und Telekommunikation war zum Stand 30. August 2026 nicht auffindbar; das ist kein Beleg ihrer Nichtexistenz, aber es heißt, dass sich das Instrument für Sie heute nicht als wirksamer Hebel darstellen lässt.

Was mit der Neufassung verschwunden ist, ist redaktionell bemerkenswert. § 41 kennt weder eine vorgelagerte Anzeige des geplanten Einsatzes noch eine Garantieerklärung des Herstellers; andere Melde- und Unterrichtungspflichten enthält das Gesetz an anderer Stelle weiterhin.

Was in einer solchen Garantieerklärung stand, zeigt die Allgemeinverfügung des Bundesinnenministeriums vom 7. Oktober 2021 (BAnz AT 12.11.2021 B1). Sie erging nach § 9b Abs. 3 Satz 4 BSIG in der bis zum 5. Dezember 2025 geltenden Fassung und ausdrücklich „für die Branche Telekommunikation“, mit kritischen Komponenten definiert über § 109 Abs. 6 TKG. Verlangt wurde vom Hersteller die Verpflichtung, für die Dauer des Einsatzes mit dem Betreiber, dem BSI und der Bundesnetzagentur zu kooperieren. Dazu kamen die Pflicht, Auskünfte im Zusammenhang mit Herstellung oder Betrieb zu erteilen, und die Pflicht, dem Betreiber Audits bezüglich des Informationssicherheitsmanagementsystems „zu ermöglichen“. Genau der Hebel, nach dem Sie suchen, hängt also an einem abgeschafften Instrument — und er galt ohnehin nur für einen Sektor.

Auch die Norm, deren Überschrift das Gegenteil verspricht, hilft nicht weiter. § 42 BSIG trägt den Titel „Auskunftsverlangen“ und lautet im Kern, dass Zugang zu den Informationen und Akten in Angelegenheiten nach Teil 2 §§ 4 bis 10 und Teil 3 des Gesetzes nicht gewährt wird; unberührt bleiben nur die Akteneinsichtsrechte von Verfahrensbeteiligten. Das ist eine Zugangsbeschränkung und keine Auskunftspflicht des Herstellers. Bei einer Lektüre, die nur die Überschrift erfasst, entsteht das genaue Gegenteil.

Bleibt der Weg über das Datenrecht, und der ist enger, als sein Ruf vermuten lässt. Der Data Act gilt seit dem 12. September 2025, wobei Artikel 3 Absatz 1 für Produkte gilt, die nach dem 12. September 2026 in Verkehr gebracht werden. Ein Kommissionsleitfaden vom 15. September 2025 ordnet die Fahrzeugdatenkategorien ein, ohne bindend zu sein. Artikel 32 verpflichtet Anbieter von Datenverarbeitungsdiensten zu Schutzmaßnahmen gegen kollidierende Zugriffe von Drittstaatenbehörden auf bestimmte nicht personenbezogene Daten in der Union. Das ist kein allgemeines Verbot staatlicher Zugriffe auf alle Fahrzeugdaten, sondern eine Pflicht eines bestimmten Anbietertyps in einem bestimmten Fall.

Praktisch bedeutet die Gesamtlage für Sie: Nach den für diesen Beitrag geprüften Normen ist der belastbare Hebel derzeit der Vertrag und nicht das Aufsichtsrecht.

Ein Kommissionsvorschlag nennt Fahrzeuge, Drohnen und Medizingeräte in einer Aufzählung

Die Kommission hat am 20. Januar 2026 in Straßburg einen Verordnungsvorschlag vorgelegt: COM(2026) 11 final, Verfahren 2026/0011(COD), eine Verordnung über die ENISA, den europäischen Zertifizierungsrahmen und die Sicherheit der IKT-Lieferketten, die die Verordnung (EU) 2019/881 aufheben soll. Es handelt sich um einen Vorschlag und nicht um geltendes Recht.

Das lässt sich am Text selbst zeigen: Der Aufhebungsartikel 121 Absatz 1 trägt das Platzhalterdatum „TT.MM.JJJJ“, und die Bewertungsfrist in Artikel 120 Absatz 1 steht ebenfalls in eckigen Klammern. Ein Rechtsakt mit Platzhaltern ist nicht in Kraft.

Für die Reichweitenfrage kommt es auf Erwägungsgrund 133 des Entwurfs an, und er ist mit Vorsicht zu lesen. Dort heißt es, Cybersicherheitsrisiken einschließlich Risiken aufgrund der Abhängigkeit von Hochrisikoanbietern ließen sich in mehreren kritischen IKT-Lieferketten in der Union beobachten, „u. a. bei Detektionsgeräten, vernetzten und automatisierten Fahrzeugen, Stromversorgungssystemen, der Stromspeicherung, Wasserversorgungssystemen, Drohnen und Drohnenabwehrsystemen, Cloud-Computing-Diensten, medizinischen Geräten, Überwachungsausrüstung, Weltraumdiensten und Halbleitern“.

Ein Erwägungsgrund regelt nichts; er begründet. Das „u. a.“ macht die Aufzählung ausdrücklich nicht abschließend, und die Zahl der Glieder unterscheidet sich zwischen den Sprachfassungen, weil die englische Fassung Stromversorgung und Stromspeicherung zusammenfasst. Eine Wiedergabe als geschlossener Katalog wäre falsch.

Dennoch ist die Nennung für Sie mehr als eine Fußnote. Drei der genannten Felder — vernetzte und automatisierte Fahrzeuge, Drohnen samt Abwehrsystemen sowie medizinische Geräte — sollen nach dem Entwurf in einer einzigen Aufzählung nebeneinanderstehen, und sie decken den Kernbereich dieses Portals ab. Damit wäre die These, dass es sich um dieselbe Risikoschicht handelt, im Entwurfstext angelegt und nicht mehr nur redaktionell hergeleitet. Eine Herstellerbewertung oder gar ein Verbot folgt daraus nicht.

Der operative Teil des Entwurfs steht in Artikel 103, und auch er wäre eine Befugnisnorm. Er würde die Kommission ermächtigen, per Durchführungsrechtsakt bestimmten in den Anhängen I und II der NIS-2-Richtlinie genannten Einrichtungsarten die Verwendung von Komponenten ermittelter Hochrisikoanbieter in wichtigen IKT-Assets zu untersagen (Absatz 1) oder ihnen Risikominderungsmaßnahmen aufzuerlegen (Absatz 2).

Zu diesen möglichen Maßnahmen zählen nach dem Entwurf Transparenzanforderungen gegenüber der zuständigen Behörde (lit. a), ein Verbot der Übermittlung von Daten an Drittländer und der Datenfernverarbeitung in oder aus einem Drittland (lit. b) sowie von Dritten zu prüfende technische Maßnahmen (lit. c). Unter lit. c nennt der Entwurf geräteinterne Verarbeitung, Segmentierung von Netzsystemen, Sperrung jeglichen Fernzugriffs, Deaktivierung nicht wesentlicher Merkmale, operative Netzüberwachung und die Prüfung von Hard- und Software. Listen von Hochrisikoanbietern sollen erst über Artikel 104 entstehen und wären ebenfalls Durchführungsrechtsakte.

Verwendbar wäre ein Entwurf für Sie nur als Horizont, nicht als Pflicht. Eine Beschaffung mit langer Nutzungsdauer — beispielsweise ein Fahrzeug über acht Jahre, ein Klinikgerät über zwölf, eine Intralogistikflotte über zehn — greift in einen Rahmen hinein, den der Vorschlag adressieren könnte, falls er in dieser Form Gesetz wird. Weder den Ausgang des Verfahrens noch eine Zeitachse behauptet dieser Beitrag: Trilogstand und Anwendungsdatum sind offen und lassen sich aus dem Vorschlagstext nicht ableiten. Wer die Merkmale trotzdem schon jetzt vertraglich abbildet, hat später weniger nachzuverhandeln.

Drohnen — was die Verordnung für die Klassen C1 bis C3 vorschreibt

Für Drohnenbetreiber gilt eine Pflicht, die es für Fahrzeuge in dieser Form nicht gibt, und sie ist ein gutes Anschauungsobjekt für die Reichweite der Risikoschicht. Die delegierte Verordnung (EU) 2019/945 verlangt für bestimmte Klassen unbemannter Luftfahrzeuge eine direkte Fernidentifizierung. Maßgeblich ist dabei nicht die Urfassung vom 11. Juni 2019, sondern der Anhang in der Fassung der delegierten Verordnung (EU) 2020/1058: Deren Artikel 1 Nummer 27 ersetzt den Anhang der Verordnung (EU) 2019/945 vollständig. Wer die Urfassung liest, liest an mehreren Stellen etwas anderes als das, was gilt. Drei weitere Änderungsverordnungen sind ergangen — (EU) 2022/851, (EU) 2024/1108 und (EU) 2025/1130. Sie tragen jeweils den Vermerk, dass sie die deutsche Fassung nicht betreffen; die Fernidentifizierung berühren sie nicht.

Entscheidend sind drei Einschränkungen, die in der öffentlichen Wiedergabe fast immer fehlen. Die Übertragung ist lokal: Artikel 3 Nr. 31 definiert die direkte Fernidentifizierung als System, das die lokale Übertragung von Informationen über ein im Betrieb befindliches Luftfahrzeug gewährleistet. Der Anhang verlangt dazu, dass die Daten „innerhalb des Sendebereichs von vorhandenen Mobilfunkgeräten direkt empfangen werden können“. Es geht also um eine Aussendung in Funkreichweite, nicht um eine Meldung an den Hersteller und nicht um eine Übermittlung an eine Behörde. Die Pflicht ist zweitens klassengebunden — sie steht in Teil 2 des Anhangs unter Nummer 12 für die Klasse C1, in Teil 3 unter Nummer 14 für C2 und in Teil 4 unter Nummer 9 für C3, während C0 und C4 sie nicht kennen. Drittens gilt sie bei C3 nur, sofern das Luftfahrzeug nicht gefesselt ist. Auch das ist eine Stelle, an der die Urfassung in die Irre führt: Dort stand die Gefesselt-Einschränkung noch bei C2 und C3, seit 2020 steht sie nur noch bei C3.

Der Datensatz ist präzise beschrieben. Er ist während der gesamten Flugdauer unter Verwendung eines offenen und dokumentierten Übertragungsprotokolls in Echtzeit direkt und regelmäßig zu übermitteln:

• die UAS-Betreibernummer und der vom Eintragungsmitgliedstaat bereitgestellte Überprüfungscode (i),
• eine eindeutige physische Seriennummer nach ANSI/CTA-2063-2019 (ii),
• der Zeitstempel, die geografische Position des Luftfahrzeugs und seine Höhe über Oberfläche oder Startpunkt (iii),
• der Streckenverlauf gemessen im Uhrzeigersinn vom geografischen Norden sowie die Geschwindigkeit über Grund (iv),
• die geografische Position des Fernpiloten oder, falls nicht verfügbar, des Startpunkts (v),
• ein Hinweis auf den Notstatus des Systems (vi).

Hier liegt die auffälligste Änderung gegenüber der Urfassung, und sie geht in die für Betreiber ungünstige Richtung. 2019 verlangte Buchstabe c, dass der Nutzer die Daten ii bis v nicht verändern kann. Seit 2020 verlangt er nur noch eine Vorkehrung, die eine Manipulation der Funktion des Systems zur direkten Fernidentifizierung erschwert. Aus einer Unveränderbarkeit ist eine Erschwernis geworden. Wer sich auf die ältere Fassung stützt, schreibt dem Gerät eine Eigenschaft zu, die es nicht haben muss.

Für Ihren Betrieb hat das zwei sehr praktische Folgen.

Die Position des Fernpiloten ist in aller Regel ein personenbezogenes Datum, sofern die Person bestimmbar ist, und sie wird bauartbedingt ausgesendet. Wo Beschäftigte fliegen, kann das eine Beteiligung des Betriebsrats auslösen, soweit die Einrichtung dazu bestimmt ist, Verhalten oder Leistung zu überwachen (§ 87 Absatz 1 Nummer 6 BetrVG), und soweit keine gesetzliche oder tarifliche Regelung vorgeht. In die Dokumentation der Verarbeitungstätigkeiten nach Artikel 30 DSGVO gehört die Aussendung ebenfalls; dessen Absatz 5 kennt eine Ausnahme für kleinere Organisationen. Ob und in welchem Umfang eine Mitbestimmung greift, ist im Einzelfall zu klären. Was dabei im Einzelnen zu prüfen ist, behandeln wir gesondert in der Einordnung dazu, was bei Drohnen datenschutzrechtlich abzuarbeiten ist.

Und der Manipulationsschutz wirkt nach zwei Seiten: Gegen Dritte erschwert er die Verfälschung des Datensatzes, gegenüber der betreibenden Organisation erschwert er den Eingriff ebenso, weil auch sie Nutzerin im Sinne der Verordnung ist. Seit der Fassung von 2020 ist das allerdings eine Erschwernis und keine Unveränderbarkeit; wer sich darauf verlässt, der Datensatz sei technisch unveränderlich, stützt sich auf die überholte Urfassung. Weitere Einordnungen zu Betrieb, Klassen und Pflichten finden Sie in unserem Überblick zu Drohnen im gewerblichen Betrieb. Ob und wie der Cyber Resilience Act auf Verbraucherdrohnen durchgreift, ist an dieser Stelle nicht belegt und wird hier deshalb nicht behauptet.

Medizin- und Klinikrobotik — die Lücke, und wie sie sich schließen lässt

In der Klinik ist die Rechtslage auf den ersten Blick besser und auf den zweiten lückenhafter als im Fahrzeug. Die Medizinprodukteverordnung stellt in Anhang I Anforderungen, die genau diese Risikoschicht treffen. Nach Nr. 17.2 ist Software entsprechend dem Stand der Technik zu entwickeln und herzustellen, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit sowie von Verifizierung und Validierung zu berücksichtigen sind. Nr. 17.4 verlangt die Festlegung von Mindestanforderungen an Hardware, an Eigenschaften von IT-Netzen und an IT-Sicherheitsmaßnahmen einschließlich des Schutzes vor unbefugtem Zugriff — und zwar jener, „die für den bestimmungsgemäßen Einsatz der Software erforderlich sind“. Dieser Schlusshalbsatz begrenzt die Pflicht, weshalb er hier mitzitiert wird. Nr. 18.8 verlangt zusätzlich, dass Produkte so weit wie möglich vor unbefugtem Zugriff geschützt sind, der ihr bestimmungsgemäßes Funktionieren behindern könnte.

Die Lücke entsteht dort, wo Sie sie am wenigsten erwarten, nämlich beim Cyber Resilience Act. Dessen Artikel 2 Absatz 2 nimmt Produkte aus, auf die unter anderem die Verordnung (EU) 2017/745 nach Buchstabe a und die Verordnung (EU) 2019/2144 nach Buchstabe c Anwendung finden. Der CRA greift damit nicht, soweit einer dieser Rechtsakte auf das Gerät Anwendung findet. Entschieden wird das am einzelnen Produkt und nicht an der Gerätegattung.

Praktisch bedeutet das: Aus dem CRA folgt für Medizinprodukte keine Pflicht zur Software-Stückliste, der sogenannten SBOM. Das ist keine Aussage darüber, dass Medizinprodukte gar keiner solchen Pflicht unterlägen — die US-amerikanische Zulassungsbehörde verlangt nach der Darstellung des BSI in seiner Technischen Richtlinie TR-03183 Teil 2 seit März 2023 die Vorlage einer Software-Stückliste im Rahmen der Zulassung neuer Medizinprodukte. Für ein Gerät eines US-Herstellers existiert die Stückliste also womöglich längst; sie kommt nur nicht über den europäischen Rechtsakt zu Ihnen.

Die Ausnahme hängt am einzelnen Produkt: Sie greift nur, soweit die Medizinprodukteverordnung auf das Gerät Anwendung findet. Ob ein Gerät Medizinprodukt ist, entscheidet die Zweckbestimmung, die der Hersteller festlegt. Artikel 2 Nummer 1 der Medizinprodukteverordnung stellt dabei auf zwei Merkmale zugleich ab: darauf, was „dem Hersteller zufolge“ für Menschen bestimmt ist, und darauf, dass das Produkt einen der dort aufgezählten medizinischen Zwecke erfüllen soll. Der Einsatzort entscheidet es nicht, und die beobachtete Tätigkeit auch nicht. Ein Transportroboter, der Wäsche und Material über den Flur fährt, wird regelmäßig ohne medizinische Zweckbestimmung in Verkehr gebracht; maßgeblich ist im Einzelfall die Zweckbestimmung in seiner technischen Dokumentation. Für ihn kann der Cyber Resilience Act greifen, sofern er ein Produkt mit digitalen Elementen im Sinne seines Artikels 2 ist. Dessen Pflichten gelten allerdings erst ab dem 11. Dezember 2027; die Meldepflichten der Hersteller nach Artikel 14 greifen ab dem 11. September 2026 und Kapitel IV zu den notifizierten Stellen seit dem 11. Juni 2026. Wo eine medizinische Zweckbestimmung dagegen zweifelsfrei vorliegt, gelten andere Nachweise; den chirurgischen Sonderfall behandeln wir bei OP-Robotern im Klinikbetrieb. Nicht jedes Gerät, das in einer Klinik steht, folgt deshalb demselben Rechtsakt.

Daneben kann Maschinenrecht gelten: bis zum 19. Januar 2027 die Maschinenrichtlinie 2006/42/EG, ab dem 20. Januar 2027 die Maschinenverordnung (EU) 2023/1230. Welcher Rechtsakt im Einzelfall greift, hängt am Produkt und ist hier nicht geprüft.

Wie konkret die Schwachstellenseite in der Klinik aussieht, zeigt ein Advisory der US-amerikanischen Cybersicherheitsbehörde CISA mit der Kennung ICSA-22-102-05, zuletzt überarbeitet am 12. April 2022. Betroffen war der Home Base Server eines Transportroboters für Krankenhäuser in allen Versionen vor Version 24. Für CVE-2022-1070 ist ein CVSS-v3-Wert von 9.8 vergeben; nach dem Wortlaut des Advisories hätte ein unauthentifizierter Angreifer sich mit dem Websocket des Servers verbinden und damit die Steuerung der Roboter übernehmen können. Ebenso gehören die Einordnungen desselben Dokuments dazu. Es hält unter „Mitigations“ fest, dass ein Mitigationsplan umgesetzt, alle Einsatzorte überprüft und auf Version 24 aktualisiert worden seien. Es hält weiter fest, dass keine öffentlich bekannten Exploits gezielt auf diese Schwachstellen abzielen, und CISA kennzeichnet die Seite inzwischen als archivierten Inhalt mit möglicherweise veralteten Angaben. Als Einsatzgebiete nennt das Advisory Ostasien und die Vereinigten Staaten. Ein Zugriff auf Bild- oder Videodaten ist dort nicht beschrieben und wird hier deshalb auch nicht behauptet.

Schließen lässt sich die Lücke auf dem Weg, der ohnehin trägt. Was der CRA für Medizinprodukte nicht vorgibt, können Sie im Wartungs- oder Liefervertrag vereinbaren: die Stückliste in maschinenlesbarem Format, ein datiertes Versorgungsende, eine Zusage zur Bereitstellung von Sicherheitsupdates innerhalb definierter Fristen. Das ersetzt keine Rechtspflicht. Anders als eine fehlende Rechtspflicht lässt sich eine vertragliche Zusage aber überhaupt erst geltend machen; wie weit sie im Einzelfall trägt, entscheidet der jeweilige Vertrag. Wie die CE-Stränge bei Klinikrobotern zusammenlaufen und welcher Rechtsakt an welcher Zweckbestimmung hängt, ordnen wir getrennt bei Krankenhausrobotern zwischen MDR, Maschinenrecht und AI Act ein.

Dieselbe Risikoschicht, andere Geräteklassen

Fahrzeuge, Drohnen und Klinikgeräte standen bisher nebeneinander, jedes mit seiner eigenen Fundstelle. Die Merkmale, die das Risiko erzeugen, hängen jedoch nicht an der Gerätegattung, sondern an der Bauart: dauerhafte Verbindung zu einem Herstellerbackend, Sensorik mit Umgebungserfassung, Fernwartung, Update-Hoheit außerhalb Ihres Hauses. Wo diese vier zusammenkommen, entsteht dieselbe Frage, unabhängig davon, ob das Gerät fährt, fliegt, saugt oder Instrumente führt.

Zwei Einträge brauchen einen Zusatz, weil sie leicht überzogen werden. Die Drohnenzeile beschreibt eine lokale Aussendung in Funkreichweite und keine Meldung an Hersteller oder Behörden; als Ortungspflicht gelesen, wäre sie falsch verstanden. Und die Zeile zur Industrierobotik stützt sich auf einen Entwurfstext, also auf einen Vorschlag, aus dem heute keine Pflicht folgt. Für Fahrzeuge gilt umgekehrt: Ob es dort eine Vorschrift gäbe, die mit der drohnenrechtlichen Aussendepflicht vergleichbar wäre, ist in den für diesen Beitrag geprüften Quellen nicht untersucht worden und bleibt hier deshalb offen.

Für Sie liegt der Nutzen der Tabelle in der Übertragbarkeit. Wenn Sie in Ihrem Haus schon einmal geklärt haben, wo die Kartendaten eines Reinigungsroboters liegen, haben Sie die Frage nach dem Datenziel bereits einmal beantwortet und können dieselbe Frage an den Transportroboter im Klinikflur stellen. Die Fragestellung wandert mit dem Merkmal, nicht mit der Gerätegattung — und genau deshalb ist die verkörperte KI in Gestalt von Physical AI als Sammelbegriff hier brauchbar. Der Begriff beschreibt Geräte, die in derselben Weise sehen, senden und aktualisiert werden.

Sechs Merkmale — und wo Sie die Antwort tatsächlich finden

Aus allem Vorherigen lassen sich sechs Merkmale ableiten, die die Betroffenheit eines konkreten Geräts beschreiben. Sie sind ein redaktionelles Prüfraster dieser Redaktion und keine Rechtspflicht.

Datenziel und Abschaltbarkeit nicht wesentlicher Merkmale finden sich als mögliche Maßnahmen auch im Kommissionsvorschlag. Dort steht außerdem die Prüfung technischer Maßnahmen durch Dritte — das wäre eine Prüfung, die eine Behörde anordnen könnte, und damit etwas anderes als ein vertragliches Auditrecht der Beschafferin. Rein redaktionell und im Vorschlag nicht angelegt sind die Frage nach der Rechtsordnung der signierenden Stelle, die Frage nach der Update-Hoheit, die Frage nach der Einsehbarkeit von Fernzugriffsprotokollen und die Frage nach durchsetzbaren Auditrechten.

Das Herkunftsland des Herstellers ist bewusst kein Merkmal. Es taugt nicht als Prüfgröße, weil die beiden hier geschilderten Datenfälle von einem deutschen und einem japanischen Hersteller stammen und der Infotainment-Fall von einem tschechischen — ein herkunftsbezogenes Kriterium hätte beide durchgelassen. Alle sechs Merkmale sind herkunftsblind und treffen einen deutschen Anbieter mit unkontrolliertem Backend genauso hart wie einen außereuropäischen.

Merkmal 3 und Merkmal 5 sind bewusst unbequem formuliert.

Eine erloschene Kamera-Anzeige ist kein Nachweis dafür, dass die Erfassung endet; sie ist ein Signal der Firmware über sich selbst. Und ein Fernzugriffsprotokoll, das nur der Hersteller vorzeigt, ist kein Protokoll für Sie, weil Sie seine Vollständigkeit nicht feststellen können. Eine ehrliche Nachfragezeile ist an beiden Stellen mehr wert als ein Selbsttest, der nichts prüft.

Diese Spalte ist auch für den Bestand brauchbar, und dort wird sie rückwärts gelesen. Wer ein Gerät bereits im Haus hat, arbeitet dieselben Merkmale ab und stellt fest, was im geschlossenen Vertrag steht — und was nicht.

Wo das Nein feststeht, bleiben zwei Wege: im eigenen Netz kompensieren, etwa durch Trennung, durch Protokollierung am Netzübergang oder durch Beschränkung der Anbindung, oder den Punkt für die nächste Wartungs- oder Vertragsverlängerung vormerken.

Drei Fragen an den Lieferanten

Aus dem Risikobefund dieses Beitrags folgen drei Fragen, die sich schriftlich stellen lassen. Sie sind kein Fragebogen zur Anbieterbewertung. Was hier steht, ist zweierlei: wo eine Antwort auf diese Frage üblicherweise dokumentiert ist, und wann eine Antwort die Frage erkennbar nicht beantwortet hat.

Datenziel und Rechtsraum. Wo die Antwort üblicherweise steht: im Auftragsverarbeitungsvertrag mit der Anlage der Unterauftragnehmer und der Verarbeitungsorte. Nicht beantwortet ist die Frage, wenn mit dem Firmensitz geantwortet wird, denn der Sitz des Anbieters sagt nichts über den Ort der Verarbeitung. Ein europäischer Sitz mit außereuropäischem Unterauftragnehmer ist keine Ausnahme, sondern der Regelfall in Cloud-Architekturen.

Update-Hoheit und ihr Nachweis. Wo die Antwort üblicherweise steht: im Wartungsvertrag und bei der ausstellenden Stelle des Signaturzertifikats. Nicht beantwortet ist die Frage, wenn „nur autorisiertes Personal“ oder „über ein gesichertes Verfahren“ geantwortet wird, weil beides weder eine Rolle noch einen Nachweis benennt. Die Frage zielt darauf, wer ein Update freigeben darf und woran sich das im Nachhinein belegen lässt.

Stückliste und Versorgungsende. Wo die Antwort üblicherweise steht: in einer Software-Stückliste in maschinenlesbarem Format und in einer datierten Supportzusage im Wartungsvertrag. Nicht beantwortet ist die Frage, wenn „regelmäßige Updates“ oder „solange das Produkt im Markt ist“ geantwortet wird — ohne Datum ist das keine Zusage, sondern eine Absichtserklärung. Wo Sensorik militärisch verwendbar ist, kommen weitere Fragen hinzu, die wir unter Dual-Use-Robotik behandeln.

Zwei praktische Hinweise noch, weil sie in der Organisation oft untergehen. Bewertet werden solche Antworten im eigenen Haus üblicherweise von der Datenschutzbeauftragten, der IT-Sicherheit und der Vergabestelle gemeinsam; bei personenbezogenen Aussendungen wie der Fernpilotenposition einer Drohne kommt der Betriebsrat hinzu. Und nicht jede Antwort ist gleich gut nachprüfbar: Die Stückliste können Sie gegen bekannte Komponenten abgleichen, die Signaturkette technisch prüfen.

Den Verarbeitungsort können Sie ohne durchsetzbares Auditrecht nicht nachprüfen — den müssen Sie glauben.

Die Messung an unseren eigenen 220 Beiträgen

Zum Schluss eine Messung in eigener Sache, weil sie erklärt, warum dieser Beitrag überhaupt nötig war. Vor der Recherche haben wir alle 220 Live-Beiträge dieses Portals daraufhin ausgewertet, welche der risikoerzeugenden Merkmale sie überhaupt erwähnen.

Sensorik in Form von Kamera, Mikrofon, LiDAR oder Radar kommt in 119 von 220 Beiträgen vor, also in 54 Prozent. App-Zugriff und Fernsteuerung erreichen 89 Beiträge, Cloud oder Hersteller-Backend 61, Standortdaten 48, Software-Update über Fernaktualisierung (OTA) 32 und die Funkverbindung 30 Beiträge.

Aufschlussreicher als die Einzelwerte ist die Häufung. Nur 32 von 220 Beiträgen tragen vier oder mehr dieser Merkmale gleichzeitig, und 22 davon behandeln Haushaltsroboter. In elf Kategorien liegt der Wert bei null — darunter Medizin- und Klinikrobotik, Exoskelette, Pflege, Industrie, Agrar, Humanoide und Recht.

Ein OP-Roboter hat Kameras, einen Netzanschluss, Herstellerwartung und Updates; unsere Beiträge dazu beschreiben klinische Ergebnisse und erwähnen davon nichts.

Der ehrlichste Teil dieser Messung ist ihr Fehlversuch. Ein erster Durchlauf ergab 100 Prozent bei „Funkverbindung“, weil das Suchmuster das Allerweltswort „vernetzt“ enthielt und damit praktisch jeden Text traf. Erst die geschärfte Messung mit Wortgrenzen liefert die Werte oben, und nur sie sind maßgeblich. Eine Zahl, die das Erwartete bestätigt, ist noch kein Befund — sie ist häufig genug ein Messfehler.

Als Aussage über die Qualität einzelner Beiträge taugt das alles wenig, als Aussage über die öffentliche Aufmerksamkeitsverteilung dagegen sehr gut. Beim Saugroboter im Wohnzimmer fragt jeder nach dem Serverstandort und den App-Rechten; beim Transportroboter im Klinikflur fragt niemand danach, obwohl dort dieselbe Backend-Anbindung sitzt und die betroffenen Daten sensibler sind. Wenn Sie diesen Beitrag mit einer einzigen Handlung verlassen möchten, dann mit dieser: die Frage, die Sie bei einem Reinigungsroboter für die eigene Wohnung selbstverständlich stellen, einmal bei dem Klinik- oder Werksgerät zu stellen, das dieselbe Sensorik und dieselbe Fernwartung trägt.

Häufige Fragen

Dieselbe Konzentration auf wenige Zulieferer betrifft auch Haushaltsrobotik — aufgeschlüsselt unter OEM, ODM und Lieferkette.