Das Grundproblem
Im ersten Beitrag dieser Reihe haben wir gezeigt, dass die Bereichsausnahmen für den Verteidigungssektor in CRA, KI-VO und NIS2 die meisten Defence-Unternehmen mit Dual-Use-IT-Produkten nicht schützen. Wer Produkte sowohl zivil als auch militärisch anbietet, muss die zivile Regulierung grundsätzlich vollständig einhalten.
Doch diese Regulierung wurde für den zivilen Kontext entworfen. Ihre Leitprinzipien – Transparenz, Offenlegung, schnelle Reaktion, behördliche Aufsicht – stehen in einem strukturellen Spannungsverhältnis zu den Anforderungen der militärischen Nutzung: Geheimhaltung, Need-to-Know, Akkreditierungszyklen, operative Autonomie. Für Dual-Use-Unternehmen, die beide Welten bedienen, entstehen daraus konkrete Konflikte, für die es bisher keinen koordinierten Auflösungsmechanismus gibt.
Im Folgenden stellen wir vier Spannungsfelder dar, die in der Praxis besonders relevant werden.
1. Meldepflichten vs. operative Geheimhaltung
Gleich vier Rechtsakte können bei einem einzigen Sicherheitsvorfall parallele Meldepflichten auslösen: Der CRA (Art. 14: 24 Stunden an CSIRT/ENISA bei aktiv ausgenutzter Schwachstelle), die KI-VO (Art. 73: 2–15 Tage an die Marktüberwachungsbehörde bei schwerwiegendem KI-Vorfall), die NIS2 (Art. 23: 24 Stunden an das BSI bei erheblichem Sicherheitsvorfall) und die DSGVO (Art. 33: 72 Stunden an die Datenschutzaufsicht bei Verletzung personenbezogener Daten).
Jede dieser Meldungen geht an andere Behörden, mit unterschiedlichen Fristen und Formaten. Das ist schon für rein zivile Unternehmen komplex. Für Dual-Use-Unternehmen kommt ein zusätzliches Problem hinzu: Die Meldung kann militärisch relevante Informationen offenlegen.
Ein Beispiel: Die CRA-Schwachstellenmeldung wird über die ENISA-Plattform EU-weit an alle betroffenen Computer Security Incident Response Teams (CSIRT) verteilt. Wenn dasselbe Produkt auf einem Bundeswehr-Netzwerk läuft, offenbart die Meldung potenziell, welche IT-Systeme die Bundeswehr nutzt und wo deren Schwachstellen liegen. Im SolarWinds-Fall (2020) wurden 560 Instanzen des kompromittierten Softwaretools „Orion“ auf Netzwerken des US-Verteidigungsministeriums identifiziert – genau die Art von Information, die ein Gegner für seine Angriffsplanung braucht.
Ähnlich problematisch: Die KI-VO-Vorfallsmeldung geht an die Marktüberwachungsbehörde (Entwurf BReg vom 11. März 2026: Bundesnetzagentur) – eine zivile Behörde, die typischerweise nicht mit Verschlusssachen und Geheimhaltungsstufen zu tun hat. Bei einem KI-System, das auch militärisch genutzt wird, kann der Abschlussbericht (mit Risikobewertung und Beschreibung der Leistungsgrenzen) hochsensible Informationen über militärische Fähigkeiten preisgeben. Und die DSGVO-Meldung bei einer Datenpanne kann Informationen über militärisches Personal oder operative Kontexte preisgeben, bevor der MAD oder das Zentrum für Cybersicherheit der Bundeswehr den Angriffsvektor analysieren konnten.
Die Rechtsakte enthalten zwar einzelne „Notbremsen“ zum Schutz von militärisch sensiblen Informationen:
Art. 2 Abs. 8 CRA und Art. 2 Abs. 11 NIS 2: Keine Bereitstellung von Informationen, die wesentliche nationale Sicherheitsinteressen gefährden,
Art. 16 Abs. 2 CRA: Verzögerung der Weiterverbreitung durch das CSIRT an die ENISA,
Art. 23 DSGVO und § 29 BDSG: Begrenzte Einschränkung zur Wahrung der nationalen Sicherheit.
Aber: All diese Regelungen liefern keine verlässliche, abgestimmte und praktikable Lösung des Zielkonflikts. Zum einen handelt es sich stets um Einzelfallabwägungen und keine allgemeinen Ausnahmeregelungen. Zum anderen stellen sich bei ihrer Anwendung viele bislang ungeklärte Fragen: Wie ist es zum Beispiel, wenn sich die Meldung eines Vorfalls auf der zivilen Nutzungsseite nur mittelbar auf die militärische Seite auswirkt? Und was ist, wenn das Produkt größtenteils zivil und nur zu einem ganz kleinen Teil militärisch genutzt wird? Kann sich das Unternehmen dann aus allen zivilen Meldepflichten zurückziehen, mit der Begründung, die Meldung wäre für die Verteidigungsinteressen eines Mitgliedsstaats gefährlich? Diese Rechtsfragen im Spannungsfeld von Dual Use sind bislang nicht geklärt.
2. SBOM-Transparenz vs. VS-Einstufung
Der CRA verlangt eine maschinenlesbare Software Bill of Materials (SBOM) in der technischen Dokumentation. Das Ziel – Transparenz über Software-Lieferketten – ist nachvollziehbar.
Für Dual-Use-Produkte wird es zum Problem: Wenn der Code der zivilen und der militärischen Variante identisch ist, ist auch die SBOM identisch. Sie legt offen, welche Open-Source-Bibliotheken (und deren bekannte Schwachstellen), welche Verschlüsselungsbibliotheken und welche Systemkomponenten die Bundeswehr einsetzt. Im Grunde ist die SBOM eine technische Blaupause der IT-Architektur – für den zivilen Markt ein Qualitätsmerkmal, für den militärischen Einsatz ein potenzielles Sicherheitsrisiko.
Ob eine SBOM für ein Dual-Use-Produkt, das auch militärisch eingesetzt wird, als Verschlusssache einzustufen ist oder als Dokumentation für Behörden zugänglich sein muss, ist nach aktuellem Stand ungeklärt.
3. Update-Pflicht vs. militärische Akkreditierung
Der CRA verpflichtet Hersteller, Sicherheitsupdates während des gesamten Unterstützungszeitraums zeitnah und kostenlos bereitzustellen. Die Logik ist: schnell patchen, Risiko minimieren.
Die militärische Realität funktioniert anders. Jede Softwareänderung auf einem VS-IT-System der Bundeswehr muss durch die Deutsche militärische Security Accreditation Authority im Zentrum für Cyber-Sicherheit der Bundeswehr akkreditiert werden. Dieser Prozess dauert Wochen bis Monate. Ein „sofortiges“ Patch-Deployment, wie der CRA es verlangt, ist auf einem akkreditierten System nicht möglich.
Für Dual-Use-KMU bedeutet das im Ergebnis: Sie müssen möglicherweise zwei getrennte Release-Zyklen fahren – einen für den zivilen Markt (CRA-konform, schnell) und einen für die Bundeswehr (akkreditierungskonform, langsam). Das bindet Ressourcen und erfordert eine klare Prozessarchitektur, die viele Unternehmen heute noch nicht haben.
4. KI-Änderungssperre und Marktüberwachung vs. Schutz militärischer Fähigkeiten
Besonders problematisch ist auch die Änderungssperre im Zusammenhang mit der Meldepflicht nach Art. 73 KI-VO: Anbieter von Hochrisiko-KI-Systemen müssen schwerwiegende Vorfälle innerhalb von 2 bis 15 Tagen an die Marktüberwachungsbehörde melden. Das eigentliche Problem liegt aber weniger in der Meldung selbst als in dem, was Art. 73 Abs. 6 KI-VO danach verlangt: Der Anbieter muss unverzüglich Untersuchungen durchführen und dabei mit den zuständigen Behörden zusammenarbeiten. Vor allem aber darf er keine Änderungen am betroffenen KI-System vornehmen, die eine spätere Analyse des Vorfalls beeinträchtigen könnten – es sei denn, er informiert die Behörde vorab. Im zivilen Kontext ist das eine sinnvolle Beweissicherungsregel.
Im militärischen Dual-Use-Kontext wird daraus ein operatives Dilemma: Wenn dasselbe KI-System auch von der Bundeswehr genutzt wird und dort eine sicherheitskritische Fehlfunktion zeigt – etwa eine Fehlidentifikation in der Zielaufklärung –, kann die Bundeswehr aus Gründen der Einsatzsicherheit (OPSEC) gezwungen sein, das System sofort zu patchen, abzuschalten oder durch eine Rückfallebene zu ersetzen. Die Änderungssperre steht dem diametral entgegen: Sie verlangt, den fehlerhaften Zustand für die behördliche Untersuchung zu konservieren. Der Anbieter steht zwischen einer gesetzlichen Pflicht, das System unangetastet zu lassen, und der operativen Notwendigkeit seines militärischen Kunden, genau das Gegenteil zu tun. Eine Auflösung dieses Konflikts sieht die KI-VO nicht vor.
Wie können Dual-Use-KMU mit diesen Spannungsfeldern umgehen?
Keines dieser Spannungsfelder ist heute abschließend gelöst. Die bestehenden Regelungen in den einzelnen Rechtsakten sind auf staatliche Akteure zugeschnitten, nicht auf private Unternehmen, die beide Märkte bedienen. Umso wichtiger ist eine proaktive Vorbereitung:
Meldeprozesse intern definieren – vor dem Ernstfall: Wer bei einem Sicherheitsvorfall an wen in welcher Reihenfolge meldet, muss vorab geklärt sein. Die Abstimmung mit dem militärischen Auftraggeber darüber, wie Meldepflichten und Geheimhaltungsinteressen im konkreten Vertragsverhältnis gelöst werden, sollte Teil der Vertragsverhandlung sein – nicht des Incident Response.
Getrennte Release-Zyklen einplanen: Wer Dual-Use-Produkte liefert, braucht eine Prozessarchitektur, die CRA-konforme Updates für zivile Kunden und akkreditierungskonforme Updates für die Bundeswehr parallel ermöglicht.
SBOM-Strategie für den Dual-Use-Fall entwickeln. Frühzeitig klären, ob und wie die SBOM eines Dual-Use-Produkts erstellt und geteilt werden kann.
—
Dies ist der zweite Beitrag unserer dreiteiligen Reihe zum Thema „Cyber Defence & Tech Law für Defence Unternehmen“. Der dritte Beitrag befasst sich damit, wie sich mit den Auswirkungen von gesetzlichen wie vertraglichen Cybersicherheits-Pflichten auf Verträge in der militärischen Lieferkette.
Dr. André Schmidt ist Rechtsanwalt und Partner, Fachanwalt für IT-Recht und leitet die Praxisgruppe Tech Law. Niklas Vogt ist Rechtsanwalt und Senior Associate, Fachanwalt für IT-Recht.
