Exportkontrolle für Dual-Use-Verteidigungssoftware: Was Entwickler wissen müssen

Software überschreitet Grenzen unsichtbar. Ein Repository, das an einen Cloud-Anbieter übertragen wird; eine Demo, die per Videokonferenz an einen ausländischen Partner übermittelt wird; ein Auftragnehmer in einem anderen Land, dem Lesezugriff auf ein Build-System gewährt wird – jedes dieser Szenarien stellt nach US-Recht eine potenzielle Exporttransaktion dar. Für Entwickler von Verteidigungssoftware sind die Export Administration Regulations (EAR) und die International Traffic in Arms Regulations (ITAR) die beiden regulatorischen Regime, die diese Transaktionen regeln. Eine fehlerhafte Klassifizierung führt nicht nur zu Papierkram; sie kann strafrechtliche Anklagen, den Entzug von Exportprivilegien und den Ausschluss von künftigen Regierungsaufträgen nach sich ziehen. Dieser Artikel erläutert die wesentlichen Konzepte, die jeder Ingenieur oder Produktverantwortliche bei einem verteidigungsnahen Softwareunternehmen verstehen muss – bevor der erste internationale Geschäftsabschluss erfolgt oder der erste ausländische Staatsangehörige dem Entwicklungsteam beitritt. Verweise auf ITAR-freie Verteidigungssoftwarestrategien finden sich durchgehend, da in der Architekturphase getroffene Klassifizierungsentscheidungen die Compliance-Kosten für die gesamte kommerzielle Lebensdauer des Produkts bestimmen.

Was Software unter Exportvorschriften zum Dual-Use-Gut macht

Der Begriff „Dual-Use" bezeichnet ein Produkt, eine Technologie oder ein Stück Software, das sowohl zivile als auch potenzielle militärische oder nachrichtendienstliche Verwendungsmöglichkeiten besitzt. Nach US-Exportrecht werden Dual-Use-Güter durch die EAR geregelt, die vom Bureau of Industry and Security (BIS) im Handelsministerium verwaltet werden. Die EAR kontrolliert Güter nicht allein auf Basis der Absichten des Entwicklers, sondern auf Basis ihrer technischen Eigenschaften. Eine Geolokalisierungsbibliothek, die Fahrzeuge mit 10-Meter-Genauigkeit verfolgen kann, ist unabhängig davon kontrolliert, ob der Zielmarkt des Entwicklers Logistik oder Gefechtsfeldmanagement ist.

Für Software im Besonderen variieren die auslösenden technischen Parameter je nach Kategorie. In der Kryptografiekategorie (ECCN 5D002) ist der relevante Parameter die Schlüssellänge: Symmetrische Verschlüsselung über 56 Bit und asymmetrische Verschlüsselung über 512 Bit sind kontrolliert – das umfasst nahezu jede heute im Einsatz befindliche Kryptografiebibliothek. In der Navigationskategorie (ECCN 7D004) ist der relevante Parameter, ob die Software Trägheitsmessdaten oder GNSS-Signale in einer Weise verarbeitet, die zivile Genauigkeitsschwellenwerte überschreitet. In der Sensoren- und Laserkategorie (ECCN 6D001, 6D003) ist der Parameter, ob die Software Bild- oder Signalverarbeitung bei Auflösungen oder Bandbreiten ermöglicht, die festgelegte zivile Grenzwerte überschreiten. Die Dual-Use-Klassifizierung ist daher eine technische Bestimmung, keine marketingbezogene.

Software, die unterhalb der Schwellenwerte für jeden kontrollierten ECCN liegt, wird als EAR99 klassifiziert – die Standardklassifizierung für unkontrollierte Handelsgüter. EAR99-Software erfordert grundsätzlich keine Ausfuhrlizenz für die meisten Bestimmungsländer, unterliegt jedoch weiterhin Verboten gegen den Versand in Sanktionsländer und an gesperrte Parteien. Die praktische Herausforderung für Verteidigungssoftwareunternehmen besteht darin, dass ein einzelnes Produkt häufig Module auf verschiedenen ECCN-Ebenen enthält: Die Kernanwendungslogik kann EAR99 sein, der eingebettete TLS-Stack ist 5D002, und ein Signalverarbeitungsmodul kann 7D004 sein. Die Exportklassifizierung des Produkts richtet sich nach der am stärksten kontrollierten Komponente.

EAR vs. ITAR: Welches Regime für Ihr Produkt gilt

Die Grenze zwischen EAR und ITAR wird durch die US Munitions List (USML) definiert, eine Liste von Rüstungsgütern und -dienstleistungen, die unter ITAR in 22 CFR Part 121 veröffentlicht ist. Wurde ein Softwareprodukt speziell für militärische Zwecke entwickelt oder modifiziert und fällt es in eine USML-Kategorie, unterliegt es ITAR – und die Compliance-Anforderungen sind erheblich höher als unter EAR. ITAR erfordert eine Registrierung beim Directorate of Defense Trade Controls (DDTC), eine Genehmigung des Außenministeriums für nahezu jeden Auslandstransfer sowie eine detaillierte Aufzeichnung jeder Offenlegung. Auch die Strafen bei ITAR-Verstößen sind pro Transaktion schwerwiegender als bei EAR-Verstößen.

Relevante USML-Kategorien für Softwareentwickler umfassen Kategorie XI (Militärelektronik, die elektronische Kampfführung, Militärradar und militärische Führungs- und Kontrollsoftware abdeckt), Kategorie XIII (Hilfsmilitärausrüstung, die bestimmte Überwachungs- und Nachrichtengewinnungssoftware einschließt) und Kategorie XV (Raumfahrzeugsysteme und verwandte Güter, die Software für die militärisch genutzte Satellitensteuerung erfasst). Fällt ein Produkt eindeutig in eine dieser Kategorien, ist die ITAR-Registrierung keine Option, sondern eine Voraussetzung für jede ausländische Offenlegung – einschließlich der Vorführung des Produkts vor einem ausländischen Staatsangehörigen in einem US-amerikanischen Büro.

Der praktische Test zur Bestimmung des anwendbaren Regimes ist der Standard „speziell für militärische Zwecke entwickelt oder modifiziert". Ein C2-System, das von Anfang an für militärische Operationen konzipiert und ausschließlich an Verteidigungsbehörden vermarktet wird, unterliegt wahrscheinlich ITAR. Die gleiche zugrunde liegende Kartierungs- und Kommunikationstechnologie, die als kommerzielles Produkt verpackt und an Rettungsdienste, Logistikbetreiber und Militärkunden gleichermaßen verkauft wird, unterliegt eher EAR unter einem Dual-Use-ECCN. Diese Unterscheidung ist nicht rein akademisch: Die strategische Entscheidung zum Aufbau ITAR-freier Verteidigungssoftware erfreut sich zunehmender Beliebtheit unter nicht-US-amerikanischen Entwicklern und Unternehmen, die in alliierte Nationen exportieren möchten, ohne die Hürden der DDTC-Lizenzierung zu bewältigen. Eine gründliche USML-Prüfung durch einen Exportkontroll-Rechtsberater vor dem Produktlaunch ist der einzig verlässliche Weg zur Feststellung, welches Regime gilt.

Exportkontrolle für Verschlüsselung: EAR 740.17 und die 64-Bit-Regel

Exportkontrollen für Verschlüsselung nach EAR gehören zu den am häufigsten anzutreffenden Compliance-Problemen für Verteidigungssoftwareentwickler, da jedes moderne Softwareprodukt Verschlüsselung verwendet. Der relevante ECCN ist 5D002, der Software erfasst, die Verschlüsselungsalgorithmen mit Schlüssellängen über festgelegten Schwellenwerten implementiert oder speziell dafür entwickelt wurde, diese zu unterstützen. AES-128, AES-256, RSA-2048, ECDH mit P-256 oder P-384, TLS 1.2 und TLS 1.3 – all das sind 5D002-kontrollierte Güter. Ein SaaS-Produkt, das ausschließlich über HTTPS bereitgestellt wird, exportiert jedes Mal ein 5D002-Gut, wenn der Browser eines ausländischen Nutzers eine TLS-Sitzung aufbaut.

Die Lizenzausnahme ENC nach EAR 740.17 bietet einen Rahmen für den Export der meisten kommerziellen Verschlüsselung ohne transaktionsbezogene Lizenz. Massenmarkt-Verschlüsselungsprodukte – Software, die über standardmäßige kommerzielle Kanäle für den Einzelhandelsverkauf an die Allgemeinheit verfügbar ist – qualifizieren sich für die freizügigste ENC-Stufe (Abschnitt 740.17(b)(3)) ohne vorherige BIS-Prüfung. Individuelle oder nicht für den Massenmarkt bestimmte Verschlüsselungsprodukte erfordern einen einmaligen Prüfantrag bei BIS und der NSA vor dem Export sowie eine jährliche Verkaufsberichterstattung für bestimmte Bestimmungsländer, darunter Russland und China. Verteidigungssoftwareunternehmen, die individuelle Verschlüsselungsimplementierungen einbetten (anstatt handelsübliche TLS-Bibliotheken zu verwenden), müssen diese Implementierungen separat klassifizieren und können mit strengeren ENC-Zulassungskriterien konfrontiert sein.

Die „64-Bit-Regel" ist ein informeller Verweis auf einen Schwellenwert in EAR Part 742.15, der zwischen öffentlich verfügbarem Verschlüsselungsquellcode (der bei ordnungsgemäßer Veröffentlichung nicht der EAR unterliegt) und kontrollierter Software unterscheidet. Die praktische Konsequenz der Regel lautet: Open-Source-Verschlüsselungsbibliotheken, die ohne Einschränkungen verbreitet werden, unterliegen im Allgemeinen nicht der EAR-Zuständigkeit. Sobald jedoch ein Verteidigungssoftwareunternehmen eine solche Bibliothek forkt und die Verbreitung einschränkt – selbst aus Gründen der Sicherheitshärtung –, kann der eingeschränkte Fork als kontrolliertes 5D002-Gut wieder unter die EAR-Zuständigkeit fallen. Entwicklungsteams, die private Forks von Open-Source-Kryptografiebibliotheken pflegen, sollten sicherstellen, dass diese Forks im Rahmen der Produktklassifizierungsanalyse überprüft werden.

ECCN-Codes in der Verteidigungstechnologiesoftware

Verteidigungstechnologiesoftware konzentriert sich auf eine kleine Anzahl von ECCN-Codes, und das Verständnis des jeweiligen Anwendungsbereichs ermöglicht es Entwicklern, kontrollierte Module frühzeitig im Designprozess zu identifizieren. ECCN 5D002 (Informationssicherheitssoftware) ist bei weitem der häufigste und erfasst Verschlüsselungsimplementierungen jeder Art oberhalb der Mindestschwellenwerte. ECCN 7D004 erfasst Software für Trägheitsnavigationssysteme (INS) und GPS/GNSS-Empfänger, die über die zivilen Genauigkeitsgrenzen hinaus betrieben werden – relevant für jede Navigationssoftware, die in der UAV-Flugsteuerung, der Präzisionszielerfassung oder der autonomen Bodenfahrzeugführung eingesetzt wird. ECCN 4D001 erfasst Software, die speziell für die militärische Nachrichtengewinnung, die Signalauswertung oder elektronische Kampfführungsunterstützungsmaßnahmen entwickelt wurde.

ECCN 0D521 ist eine im Rahmen des EAR-Rahmens für aufkommende Technologien hinzugefügte Kontrolle und erfasst Software, die Überwachung, Standortverfolgung oder die Kommunikationsüberwachung von Einzelpersonen oder Gruppen im großen Maßstab ermöglicht. Dieser ECCN wird zunehmend relevant für Verteidigungssoftware, die RF-Erkennung, SIGINT-nahe Fähigkeiten oder großangelegte Netzwerkdatenanalyse umfasst. ECCN 3D001 erfasst Software für die Herstellung von Halbleitern und elektronischen Komponenten, die selbst kontrolliert sind; er ist relevant für Verteidigungssoftwareunternehmen, die eingebettete Firmware auf der Hardware-Abstraktionsschicht für kontrollierte Signalverarbeitungschips entwickeln. ECCN 2D002 erfasst Software für bestimmte Werkzeugmaschinen-Steuerungssysteme, die in der Waffenherstellung eingesetzt werden – bei reinen Softwareprodukten seltener anzutreffen, aber relevant für Unternehmen, die Software an Hersteller der Verteidigungsindustriebasis verkaufen.

Software mit Modulen aus mehreren ECCN-Kategorien erfordert eine komponentenweise Analyse. Der gesamte Exportlizenzierungsbedarf des Produkts wird durch die am stärksten kontrollierte Komponente bestimmt, doch jede Komponente kann für unterschiedliche Lizenzausnahmen in Frage kommen. Für ein Produkt mit einem 5D002-Verschlüsselungsmodul und einem 7D004-Navigationsmodul kann ENC nicht zur Lizenzierung der 7D004-Komponente verwendet werden – jeder ECCN hat seine eigenen anwendbaren Lizenzausnahmen, die im jeweiligen Commerce Control List-Eintrag aufgeführt sind. Bei Verteidigungssoftware, die in formelle Beschaffungsverfahren eintritt, wird die Vergabebehörde in der Regel eine Kopie der ECCN-Klassifizierung des Produkts und der anwendbaren Lizenzausnahmen als Teil des technischen Dokumentationspakets verlangen.

Deemed-Export-Risiko: Ausländische Staatsangehörige in Entwicklungsteams

Die Deemed-Export-Regel, kodifiziert in 15 CFR 734.13(a)(2), behandelt die Offenlegung von EAR-kontrollierter Technologie oder Quellcode gegenüber einem ausländischen Staatsangehörigen in den Vereinigten Staaten als Export in das Heimatland dieser Person. Die Regel gilt für die Freigabe kontrollierter Güter durch „Sichtinspektion, mündlichen Austausch oder die Anwendung persönlichen Wissens oder technischer Erfahrung, die in den Vereinigten Staaten erworben wurde, auf Situationen im Ausland." In der Praxis bedeutet dies: Einem ausländischen Ingenieur die Architektur eines 5D002-kontrollierten Systems zu zeigen, ihm Lesezugriff auf ein kontrolliertes Repository zu gewähren oder technische Spezifikationen in einem Design-Review zu besprechen, ist ein Exportereignis – eines, das möglicherweise eine BIS-Lizenz erfordert, bevor es rechtmäßig stattfinden kann.

Das Deemed-Export-Risiko ist am größten in Entwicklungsteams, die Staatsangehörige von Ländern mit restriktiven Lizenzanforderungen umfassen: China, Russland und Länder, die umfassenden Sanktionen unterliegen, sind die risikoreichsten Nationalitäten für EAR-kontrollierte Güter. Die Deemed-Export-Regel gilt jedoch bei ITAR-kontrollierten Gütern für Staatsangehörige aller ausländischen Länder – bei Deemed Exports gibt es unter ITAR keine Ausnahme für Verbündete, obwohl für Staatsangehörige bestimmter Bündnispartner Lizenzausnahmen verfügbar sind. Ein Verteidigungssoftwareunternehmen, das einem britischen Ingenieur uneingeschränkten Zugang zu einem ITAR-kontrollierten Quell-Repository gewährt, ohne eine DDTC-Lizenz zu besitzen, hat einen Deemed-Export-Verstoß begangen – ungeachtet des Status des Vereinigten Königreichs als enger US-Verbündeter.

Die Minderung von Deemed-Export-Risiken erfordert einen strukturierten Zugangskontrollrahmen statt informeller Annahmen über den Hintergrund der Teammitglieder. Der Rahmen sollte alle kontrollierten Güter in der Entwicklungsumgebung identifizieren, Teammitglieder nach Staatsangehörigkeit und Aufenthaltsstatus kategorisieren und Zugriffsberechtigungen mit den Lizenzanforderungen für jedes Gut abgleichen. Ausländische Staatsangehörige, die für legitime Entwicklungsarbeiten Zugang zu kontrollierten Gütern benötigen, können durch eine BIS-Deemed-Export-Lizenz (formell eine „EAR-Lizenz zur Freigabe von Technologie an ausländische Staatsangehörige") oder, für EAR-Güter niedrigerer Kontrollebene, durch eine Lizenzausnahme wie Technology and Software Unrestricted (TSU) – sofern anwendbar – autorisiert werden. Das kritische Versagensmuster, das es zu vermeiden gilt, ist eine nachträgliche Entdeckung – das Aufdecken von Deemed-Export-Verstößen im Rahmen einer Behördenprüfung statt des proaktiven Zugriffsmanagements im Vorhinein.

Aufbau eines Exportkontroll-Compliance-Programms für ein kleines Team

Ein Compliance-Programm muss kein großes bürokratisches System sein, um wirksam zu sein. Für ein Softwareunternehmen mit weniger als 50 Ingenieuren besteht die grundlegende Compliance-Infrastruktur aus vier Elementen: einem Produktklassifizierungsprotokoll, einem Screening-Verfahren für gesperrte Parteien, einer Zugangskontrollrichtlinie für kontrollierte Güter und einer jährlichen Schulungspflicht. Jedes dieser Elemente kann von einem einzigen benannten Exportkontrollbeauftragten verwaltet werden – typischerweise einem leitenden Ingenieur oder einem Justiziar mit Exportkontrollausbildung – statt von einer eigenen Compliance-Abteilung.

Das Produktklassifizierungsprotokoll bildet die Grundlage. Es dokumentiert den ECCN für jedes Softwaremodul, die Grundlage der Klassifizierung, anwendbare Lizenzausnahmen und das Datum der letzten Überprüfung. Es sollte aktualisiert werden, wann immer ein neues Modul hinzugefügt oder die technischen Parameter eines bestehenden Moduls geändert werden. Ein Modul, das als EAR99 beginnt, kann zum 5D002-kontrollierten Gut werden, sobald ein Entwickler eine AES-Verschlüsselungsschicht hinzufügt – und das Klassifizierungsprotokoll ist der Mechanismus, der diese Änderung erfasst, bevor ein Vertriebs- oder Partnerschaftsteam das neu kontrollierte Gut unwissentlich ohne Lizenz exportiert. Um als Softwareanbieter NATO-Unterauftragnehmer zu werden, ist in der Regel die Vorlage des Produktklassifizierungsprotokolls beim Hauptauftragnehmer als Teil des Lieferketten-Compliance-Prozesses erforderlich.

Das Screening-Verfahren für gesperrte Parteien sollte automatisch für jeden neuen Kunden, Partner und Vertriebskanal ablaufen. BIS, OFAC und DDTC führen separate Screening-Listen; kommerzielle Screening-Tools aggregieren all diese in einer einzigen API-zugänglichen Datenbank. Das Screening sollte bei der Kontoerstellung für SaaS-Produkte, beim Vertragsabschluss für On-Premise-Implementierungen und zum Zeitpunkt jeder Code- oder technischen Dokumentationsübertragung an Dritte erfolgen. Aufzeichnungen über jedes Screening-Ergebnis sollten fünf Jahre lang aufbewahrt werden. Die Zugangskontrollrichtlinie für kontrollierte Güter in der Entwicklungsumgebung ist das interne Pendant zum Screening gesperrter Parteien – sie ordnet kontrollierte Güter den zu ihrem Zugriff autorisierten Mitarbeitern zu und sollte überprüft werden, wann immer ein neues Teammitglied hinzukommt oder sich der Aufenthaltsstatus eines bestehenden Mitglieds ändert.

Folgen der Nichteinhaltung und Auslöser von Prüfungen

BIS führt Exportkontroll-Prüfungen über sein Office of Export Enforcement (OEE) durch. Prüfungen können durch einen Hinweis eines Mitbewerbers, eine verdächtige Finanztransaktion, die vom Compliance-System einer Bank markiert wurde, eine Zollaufzeichnung, die nicht mit einer Ausfuhrlizenz übereinstimmt, oder eine Überprüfung öffentlicher Aufzeichnungen wie Patentanmeldungen oder Konferenzpräsentationen ausgelöst werden, die enthüllen, dass kontrollierte technische Informationen an ausländische Staatsangehörige weitergegeben wurden. Das OEE führt auch Outreach-Prüfungen durch – freiwillige Compliance-Überprüfungen ohne Feststellung von Fehlverhalten – als Teil seines Bildungsprogramms, und Unternehmen, die proaktiv an Outreach-Prüfungen teilnehmen, werden in nachfolgenden Durchsetzungsmaßnahmen wohlwollender bewertet.

EAR-Zivilstrafen werden pro Verstoß verhängt und wurden nach dem Federal Civil Penalties Inflation Adjustment Act auf über 350.000 US-Dollar pro Transaktion ab 2025 angehoben. Für ein Unternehmen, das zwei Jahre lang wöchentlich Cloud-Deployments eines 5D002-Produkts an ausländische Nutzer ohne ENC-Klassifizierung durchgeführt hat, könnte die auf jedes Deployment angewandte Einzelstrafen eine theoretische Haftung erzeugen, die den Gesamtumsatz des Unternehmens bei weitem übersteigt. In der Praxis verhandelt BIS Vergleiche, die Unternehmensgröße, Compliance-Bemühungen in gutem Glauben und die Kooperation mit der Untersuchung berücksichtigen – doch die theoretische Haftungssumme bestimmt die Vergleichsverhandlungen und kann für ein Start-up existenzbedrohend sein. Strafrechtliche Sanktionen bei vorsätzlichen ITAR- oder EAR-Verstößen erreichen 1 Million US-Dollar pro Verstoß und 20 Jahre Haft und können neben der juristischen Person auch auf einzelne Führungskräfte angewandt werden.

Die freiwillige Selbstanzeige (Voluntary Self-Disclosure, VSD) ist das wirkungsvollste Instrument, das einem Unternehmen zur Verfügung steht, das einen vergangenen Verstoß entdeckt. Die BIS-Durchsetzungsrichtlinien behandeln VSD als einen wesentlichen mildernden Umstand, und gelöste VSDs führen in der Regel zu keiner Strafe oder einer erheblich reduzierten Zivilstrafe im Vergleich zur Strafe für denselben Verstoß, der durch eine Durchsetzungsmaßnahme aufgedeckt wurde. Das VSD-Verfahren erfordert, innerhalb von fünf Tagen nach Entdeckung des potenziellen Verstoßes eine erste Benachrichtigung an das OEE einzureichen, gefolgt von einem vollständigen schriftlichen Bericht innerhalb von 60 Tagen. Verteidigungssoftwareunternehmen, die periodische interne Compliance-Prüfungen durchführen und ein dokumentiertes VSD-Verfahren eingerichtet haben, sind erheblich besser positioniert, um einen entdeckten Verstoß zu überstehen, als Unternehmen ohne Compliance-Infrastruktur und ohne einen Prüfpfad, der belegt, dass der Verstoß selbst identifiziert und nicht von außen entdeckt wurde.