Es gibt einen Satz, den ich in den letzten Monaten regelmäßig gehört habe – in Gesprächen mit israelischen Gründern, in Briefings mit Vertriebsleitern, in Präsentationen vor potentiellen europäischen Partnern. Als Executive Security Architect begleite ich israelische Technologieunternehmen beim Markteintritt in Deutschland und Europa – genau dort, wo Produktarchitektur auf Haftungsrealität trifft. Dieser Satz kommt meistens dann, wenn das Thema Cyber Resilience Act auftaucht. Er lautet, sinngemäß: „Wir haben bis 2027.“
Der Satz ist nicht falsch. Er ist gefährlich.
Denn wer glaubt, dass „bis 2027″ bedeutet, man habe noch Zeit, versteht weder den Regulierungsmechanismus noch die operative Realität, die dieser Mechanismus erzeugt. Die vollständige Anwendung des CRA gilt ab dem 11. Dezember 2027 – ab diesem Datum dürfen nur noch Produkte in Verkehr gebracht werden, die sämtliche Anforderungen der Verordnung vollständig erfüllen. Das ist korrekt. Aber dieser Satz verschweigt, was vorher passiert. Und was vorher passiert, ist das eigentliche Problem.
Der CRA ist kein Softwareproblem. Er ist ein Produktarchitekturproblem.
Wenn europäische Unternehmen über den Cyber Resilience Act reden, denken sie meistens an Software. An Patches, an Updates, an Schwachstellen-Disclosure. Das ist verständlich – der CRA hat eine starke Sichtbarkeit im Bereich Connected Devices und IoT. Aber für israelische Hersteller von RF-Technologie, Drohnenabwehrsystemen, Embedded Hardware und taktischen Kommunikationsgeräten ist der CRA etwas anderes: Er ist eine fundamentale Anforderung an die Art, wie ein Produkt gedacht, gebaut und über seinen gesamten Lebenszyklus verantwortet wird.
Der CRA betrifft alle Unternehmen, die Produkte mit digitalen Elementen entwickeln, herstellen, importieren oder in den Verkehr bringen. Die entscheidende Formulierung ist „digitale Elemente“. Ein RF-Jamming-System, das über ein Softwareinterface konfiguriert wird, ist ein Produkt mit digitalen Elementen. Eine Drohnenabwehrplattform mit eingebetteter Erkennungssoftware ist ein Produkt mit digitalen Elementen. Ein taktisches Kommunikationsmodul mit verschlüsselter Firmware ist ein Produkt mit digitalen Elementen.
Der CRA gilt für alle Hersteller, die Produkte mit digitalen Elementen auf dem EU-Markt in Verkehr bringen – unabhängig davon, ob sie ihren Geschäftssitz innerhalb oder außerhalb der EU haben. Das bedeutet: Wer in Israel Hardware baut und diese Hardware nach Deutschland, Frankreich, Polen oder irgendeinen anderen EU-Mitgliedsstaat verkauft, ist vollumfänglich betroffen. Es gibt keine geographische Ausnahme. Es gibt keine Ausnahme für Dual-Use-Produkte im klassischen Sinne. Die Verordnung ist direkt anwendbar – anders als die NIS-2-Richtlinie braucht sie keine nationale Umsetzung in den Mitgliedsstaaten.
Was September 2026 bedeutet – und warum das jetzt relevant ist
Die meisten Hersteller, mit denen ich spreche, haben Dezember 2027 im Kalender. Was sie nicht haben: den 11. September 2026.
Ab diesem Datum unterliegen Hersteller von vernetzten Produkten der Meldepflicht für Schwachstellen und Vorfälle. Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen mit Auswirkung auf die Sicherheit von Produkten mit digitalen Elementen muss innerhalb von 24 Stunden eine initiale Meldung erfolgen. In Deutschland wird diese Meldung voraussichtlich an das BSI zu richten sein, das als nationale Marktüberwachungsbehörde für den CRA vorgesehen ist. Innerhalb von 72 Stunden sind weitere Informationen zu ergänzen. Ein Abschlussbericht ist spätestens 14 Tage nach einem Sicherheitsupdate oder einem Workaround zu erstellen.
24 Stunden. Das ist keine bürokratische Frist, die man mit einer E-Mail erfüllt. Das ist eine operative Anforderung, die eine funktionierende interne Meldestruktur voraussetzt – Monitoring, Eskalationswege, definierte Verantwortlichkeiten, eine technische Dokumentation, die aktuell genug ist, um einen konkreten Vorfall innerhalb eines Tages qualifiziert beschreiben zu können.
Für ein israelisches Unternehmen, das bislang keine regulatorische Infrastruktur für den europäischen Markt aufgebaut hat, ist das kein kleiner Schritt. Das ist eine organisatorische Transformation. Und diese Transformation braucht Zeit – nicht Wochen, sondern Quartale.
Am 3. März 2026 veröffentlichte die Europäische Kommission den lang erwarteten Entwurf für die Umsetzungsleitlinien zum Cyber Resilience Act. Die Konsultation lief bis Ende März 2026. Das ist kein Signal, dass die Umsetzung sich verzögert. Es ist das Signal, dass die operative Phase begonnen hat. Branchenbeobachter sehen darin das Ende der Planungs- und den Start der Umsetzungsphase.
Die Klassifizierungsfalle
Der CRA unterscheidet zwischen Standardprodukten und wichtigen bzw. kritischen Produkten mit digitalen Elementen. Diese Unterscheidung ist für israelische Hersteller von besonderer Relevanz – und besonders häufig missverstanden.
Produkte der Klasse I unterliegen verschärften Anforderungen und benötigen in der Regel eine Drittpartei-Konformitätsbewertung durch eine akkreditierte Stelle. Produkte der Klasse II – also solche, die als kritisch für Sicherheit oder Infrastruktur eingestuft werden – stehen noch strengeren Anforderungen gegenüber. Viele Produkte, die israelische Unternehmen in den deutschen und europäischen Markt bringen wollen, können je nach konkreter Funktion und Anhang-III-Einordnung in diese Kategorien fallen: taktische Hardware, Kommunikationssysteme mit Verschlüsselung, Netzwerkinfrastrukturkomponenten, Geräte mit Remote-Management-Funktionalität.
Der erste große Meilenstein kommt bereits am 11. Juni 2026: Dann wird der Rechtsrahmen für die Benachrichtigung von Konformitätsbewertungsstellen wirksam. Dieser Schritt ist nötig, um genügend akkreditierte Testlabore für die Produktzertifizierung bereitzustellen und Marktengpässe zu vermeiden.
„Marktengpässe zu vermeiden“ ist eine diplomatische Formulierung. Übersetzt bedeutet sie: Es gibt zu wenige akkreditierte Stellen für die Menge der Produkte, die bis Dezember 2027 bewertet werden müssen. Wer mit der Einleitung des Konformitätsbewertungsverfahrens wartet, riskiert, keinen Platz mehr zu bekommen – nicht weil die Anforderungen nicht erfüllbar wären, sondern weil die Kapazität der bewertenden Stellen begrenzt ist.
Das ist keine Spekulation. Das ist die regulatorische Erfahrung aus der NIS-2-Umsetzung, aus der DSGVO, aus der CE-Kennzeichnungspraxis. Regulatorische Fristen erzeugen Ansturm kurz vor Ablauf. Wer diesen Ansturm kennt, positioniert sich davor. Wer ihn nicht kennt, steht im Stau.
Was der CRA tatsächlich fordert – operativ
Jenseits der Fristen ist es wichtig zu verstehen, was der CRA inhaltlich verlangt. Es sind keine abstrakten Anforderungen. Es sind konkrete Pflichten, die tief in Produktentwicklung und Betrieb eingreifen.
Security by Design und Security by Default. Sicherheitsanforderungen müssen in der Architektur des Produkts verankert sein – nicht als nachträgliche Schicht, sondern als inhärentes Designprinzip. Schwache Standardpasswörter, unverschlüsselte Kommunikation, fehlende Angriffsflächen-Minimierung: alles Nicht-Konformitätsgründe.
Software Bill of Materials. Hersteller sind verpflichtet, ein systematisches Schwachstellenmanagement einzuführen. Dazu gehört die Erstellung einer sogenannten Software Bill of Materials – ein detailliertes Verzeichnis aller im Produkt verwendeten Softwarekomponenten. Für Hersteller, die auf Open-Source-Komponenten, Drittanbieter-Bibliotheken oder zugekaufte Embedded-Systeme setzen, ist das keine Selbstverständlichkeit. Es erfordert Transparenz über die eigene Lieferkette auf einer Ebene, die viele bislang nicht hatten.
Schwachstellenmanagement über den Produktlebenszyklus. Die Pflicht, Schwachstellenmanagement über die gesamte erwartete Nutzungsdauer aufrechtzuerhalten – bei sicherheitsrelevanter Hardware typischerweise fünf Jahre oder mehr – erfordert kontinuierliche Investitionen. Unternehmen müssen ihre installierte Basis in Echtzeit überwachen können, um schnell korrigierende Maßnahmen umzusetzen. Das bedeutet: Wer ein Produkt heute auf den Markt bringt, ist in fünf Jahren noch für dessen Sicherheitsstatus verantwortlich – und muss das nachweisen können.
Für einen israelischen Hersteller, der an Behörden, kritische Infrastrukturbetreiber oder Sicherheitsbehörden in Deutschland liefert, ist dieser Punkt besonders relevant. Öffentliche Auftraggeber in Deutschland werden zunehmend CRA-Konformität als Zugangsvoraussetzung in Ausschreibungen verankern – noch bevor die Verordnung vollständig gilt. Das ist nicht spekulativ. Das ist die logische Konsequenz aus dem Beschaffungsrecht in Verbindung mit KRITIS-Regulierung.
Das Lieferkettenproblem
Ein Aspekt, der in der CRA-Diskussion noch zu wenig Aufmerksamkeit bekommt, ist die Lieferkettenwirkung. Der CRA erkennt an, dass Hersteller entlang der gesamten Lieferkette für die Sicherheitsergebnisse verantwortlich sind.
Das bedeutet praktisch: Wenn ein israelisches Unternehmen Komponenten bezieht – Chips, Module, Softwarebibliotheken, Kommunikationsprotokolle – muss es sicherstellen, dass diese Komponenten ebenfalls den CRA-Anforderungen genügen. Oder es muss in der Lage sein, fehlende Konformität der Zulieferer durch eigene Maßnahmen zu kompensieren und zu dokumentieren.
Für Unternehmen, die in der israelischen Rüstungs- und Sicherheitstechnologiebranche verwurzelt sind und auf ein Netzwerk aus israelischen Sublieferanten zurückgreifen, ist das ein strukturelles Problem. Diese Sublieferanten sind nicht zwingend CRA-konform – weil sie es bislang nicht sein mussten. Die Anforderung wird durch die Lieferkette nach unten durchgereicht, und der Hersteller am Ende trägt die Verantwortung.
Counter-Drone-Technologie: Die regulatorische Doppelbelastung
Für israelische Hersteller von Counter-UAS-Systemen – Jamming-Technologie, RF-basierter Drohnenerkennung, elektronischer Drohnenabwehr – ist der CRA kein abstraktes Compliance-Thema. Er ist eine akute Geschäftsrealität, die durch ein Dokument konkrete politische Gestalt angenommen hat, das in der deutschen Verteidigungstechnikdiskussion noch kaum angekommen ist.
Am 11. Februar 2026 veröffentlichte die Europäische Kommission ihren Action Plan on Drone and Counter-Drone Security. Der Aktionsplan ist darauf ausgelegt, die EU-Mitgliedstaaten durch koordinierte Maßnahmen zu unterstützen, mit Schwerpunkten auf verbesserter Vorbereitung, gesteigerter Erkennungskapazität, koordinierter Reaktion und gestärkter Verteidigungsbereitschaft. Was viele in der israelischen Defense-Tech-Szene noch nicht registriert haben: Dieser Plan verknüpft Counter-Drone-Systeme explizit mit dem CRA.
Eine wichtige Einschränkung vorab: Der CRA sieht eine Ausnahme für Produkte vor, die ausschließlich für militärische Zwecke oder für die Verteidigung im engeren Sinne bestimmt sind. Für rein militärische Beschaffungsprozesse kann diese Ausnahme greifen. Sie greift nicht für denselben Systemtyp, sobald er zum Schutz ziviler Infrastruktur eingesetzt wird – an Flughäfen, Häfen, Energieanlagen oder Regierungsgebäuden. Genau das ist aber der Kernmarkt, den israelische Counter-Drone-Anbieter in Deutschland adressieren. Wer dort verkaufen will, bewegt sich im zivilen KRITIS-Umfeld – und damit vollständig im Geltungsbereich des CRA.
Mit der vollständigen Anwendung des Cyber Resilience Act im Dezember 2027 wird die große Mehrheit der auf dem EU-Markt platzierten Drohnen verbindlichen Cybersicherheitsanforderungen unterliegen, womit Security-by-Design gefördert wird. Das klingt zunächst wie eine Anforderung an Drohnenhersteller. Es ist aber auch eine Anforderung an alle Systeme, die mit Drohnen interagieren – also an die Counter-Drone-Infrastruktur selbst.
Ein RF-Jamming-System, das Drohnensignale erkennt, klassifiziert und unterbricht, ist ein vernetztes System mit digitalen Elementen. Es verarbeitet Signaldaten in Echtzeit, kommuniziert mit übergeordneten Leit- und Kommandosystemen, wird per Software konfiguriert und aktualisiert. Es fällt unter den CRA. Und es fällt in eine Produktkategorie, die im Kontext des Aktionsplans besondere regulatorische Aufmerksamkeit bekommt.
Die Kommission will eine koordinierte unionsweite Sicherheitsrisikobewertung von Drohnen und Counter-Drone-Kapazitäten durchführen, die auch Risiken in der IKT-Lieferkette bewertet. Darauf soll ein Drone and Counter-Drone Security Toolbox folgen, der verhältnismäßige Sicherheitsminderungsmaßnahmen vorschlägt – insbesondere für den Einsatz von Counter-Drone-Systemen rund um kritische Infrastrukturen.
Bis Q3 2026 wird die EU-Kommission Sicherheitskriterien definieren, die maßgeblich bestimmen werden, welche Counter-Drone-Systeme rund um kritische Infrastrukturen zum Einsatz kommen können. Ein israelischer Anbieter, der in diesem Zeitraum keine CRA-konforme Dokumentation vorlegen kann, wird in diesem Prozess nicht positiv auftauchen. Und wer dort nicht positiv auftaucht, wird es deutlich schwerer haben, Zugang zu genau den Beschaffungsprozessen zu erhalten, für die er gebaut ist: Flughäfen, Energieversorger, Häfen, Regierungsgebäude. Die Frist bis dahin ist nicht Dezember 2027. Sie ist wenige Monate entfernt.
Die Konformitätsfalle für Dual-Use-Technologie
Counter-Drone-Systeme unterliegen in Deutschland zusätzlich dem Außenwirtschaftsgesetz, BAFA-Exportkontrolle und im Einzelfall Dual-Use-Vorschriften. Das ist bekannt. Was weniger bekannt ist: Der CRA tritt zu diesen Anforderungen nicht alternativ hinzu, sondern kumulativ.
Ein israelisches Unternehmen, das eine Jamming-Lösung nach Deutschland liefert, muss alle drei Ebenen parallel erfüllen: die außenwirtschaftsrechtliche Genehmigung, die CRA-Konformität des Produkts als digitales Element und – bei Einsatz rund um KRITIS-Objekte – die Anforderungen des KRITIS-Dachgesetzes an die Betreiber, die das System einsetzen. Diese drei Regulierungsebenen sprechen nicht miteinander. Sie haben unterschiedliche Behörden, unterschiedliche Fristen, unterschiedliche Nachweislogiken.
Wer glaubt, eine BAFA-Exportgenehmigung stelle sicher, dass das Produkt im deutschen Markt einsetzbar ist, unterschätzt die Tiefe des deutschen Regulierungsraums. Die Exportgenehmigung regelt, ob das Produkt ausgeführt werden darf. Der CRA regelt, ob es in Verkehr gebracht werden darf. Das KRITIS-Dachgesetz regelt, ob der Betreiber, der es einsetzt, damit seinen Resilienzpflichten nachkommt. Drei verschiedene Fragen. Drei verschiedene Antworten, die alle „Ja“ lauten müssen.
Was das für die Produktarchitektur bedeutet
Die praktische Konsequenz für Counter-Drone-Hardware ist konkret: Jedes System, das in den europäischen Markt gebracht werden soll, braucht eine dokumentierte Risikoanalyse, eine SBOM aller softwareseitigen Komponenten, einen definierten Supportzeitraum mit Patch-Verpflichtung und einen internen Meldeprozess für Schwachstellen – mit den oben genannten 24-Stunden-Fristen.
Für RF-Jamming-Systeme bedeutet das zusätzlich: Die Firmware, die Frequenzsteuerung, die Signalklassifikations-Algorithmen – all das sind dokumentationspflichtige digitale Elemente. Wenn ein Sublieferant die Erkennungssoftware beisteuert, muss auch dieser Sublieferant die Anforderungen erfüllen, oder der Haupthersteller muss die Lücke durch eigene Nachweise schließen.
Israelische Unternehmen in diesem Segment sind typischerweise stark in der Hardware-Exzellenz und im operativen Know-how. Die Fähigkeit, eine lückenlose regulatorische Dokumentation im europäischen Format vorzulegen, ist eine andere Kompetenz – und eine, die man aufbauen muss, bevor der erste Auftrag kommt. Denn im deutschen Beschaffungsprozess wird diese Dokumentation vor Vertragsabschluss angefordert, nicht danach.
Was das für den deutschen Markt bedeutet
Deutschland ist für israelische Sicherheitstechnologieunternehmen ein strategischer Zielpunkt – aus politischen, industriellen und wirtschaftlichen Gründen. Die deutsch-israelische Sicherheitskooperation hat in den letzten Jahren an Tiefe gewonnen. Family Offices und institutionelle Investoren haben Appetit auf israelische Defense-Tech entwickelt. Behörden und Betreiber kritischer Infrastruktur suchen nach Lösungen jenseits der etablierten großen Anbieter.
Aber Deutschland ist auch der Markt, in dem regulatorische Nichtkonformität am schnellsten zur Marktzugangssperre wird. Nicht durch hohe Bußgelder – obwohl auch die existieren: Der CRA sieht Sanktionen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist – sondern durch das Ausschreibungs- und Beschaffungsrecht, durch Vergabeprozesse, durch die informelle Wirkung des BSI-Urteils über ein Produkt.
Der CRA fügt dieser Realität eine neue Dimension hinzu: Wer ein zertifiziertes ISMS bereits umgesetzt hat, hat die Konformitätsvermutung schon einmal für sich. Umgekehrt gilt: Wer keine dokumentierte Sicherheitsarchitektur, kein Schwachstellenmanagement und keine Meldeprozesse vorweisen kann, hat in einem deutschen Beschaffungsverfahren für sicherheitskritische Technologie ein ernsthaftes Problem – und das nicht erst ab 2027.
In der Praxis entsteht damit eine neue Form der Marktzugangsschwelle. Nicht durch Zölle oder politische Entscheidungen, sondern durch regulatorische Nachweisfähigkeit. Hersteller, die ihre Sicherheitsarchitektur, ihr Schwachstellenmanagement und ihre Lieferketten transparent dokumentieren können, werden im europäischen Beschaffungsumfeld zunehmend bevorzugt – oft lange bevor formale Fristen wie der Dezember 2027 erreicht sind.
Das Zeitfenster, das sich schließt
Ich sage israelischen Herstellern, mit denen ich arbeite, Folgendes: Der CRA-Zeitplan ist keine Frist. Er ist ein Trichter. Und dieser Trichter wird enger.
Jetzt ist die Umsetzungsleitlinie der EU-Kommission in der Finalisierung. Das bedeutet: Wer jetzt anfängt, hat noch die Möglichkeit, die Leitlinie in seiner Compliance-Planung zu berücksichtigen. Wer jetzt anfängt, hat noch Zeit, einen Konformitätsbewertungspartner zu finden, bevor die Kapazitäten unter dem Ansturm der Nachrücker ausgeschöpft sind. Wer jetzt anfängt, kann dem September 2026 – mit seinen 24-Stunden-Meldepflichten beim BSI und dem beginnenden EU-Drohnen-Sicherheitsprozess – mit funktionierenden internen Prozessen begegnen.
Konkret bedeutet das: Jetzt die Klassifizierung der eigenen Produkte nach Anhang III klären. Jetzt prüfen, ob und wo eine Drittpartei-Konformitätsbewertung erforderlich ist. Jetzt eine SBOM aufbauen. Jetzt interne Meldeprozesse definieren. Jetzt die Lieferkette analysieren. Und – für Counter-Drone-Anbieter – jetzt sicherstellen, dass man im Q3-2026-Kriterienprozess der EU-Kommission mit einer dokumentierten Sicherheitsarchitektur vertreten ist, nicht mit einem Produktdatenblatt.
Nicht 2027.
Eine letzte Anmerkung
Der Cyber Resilience Act ist kein Angriff auf Hersteller außerhalb der EU. Er ist der Versuch, einen Markt zu schaffen, in dem Käufer wissen können, was sie kaufen. In dem Sicherheitsversprechen verifizierbar sind. In dem Hersteller für die Sicherheit ihrer Produkte über die Zeit verantwortlich bleiben.
Das ist für israelische Unternehmen, deren Stärke in operativer Exzellenz und technischer Tiefe liegt, eigentlich eine Chance. CRA-Konformität wird zum Marktzugangsfaktor – nicht zum optionalen Differenzierungsmerkmal, sondern zur Voraussetzung für jeden ernsthaften Auftrag in Deutschland und Europa. Gerade im Counter-Drone-Segment, wo europäische Beschaffer zunehmend unter politischem Druck stehen, Lieferketten zu prüfen und Systemsicherheit zu dokumentieren, ist zertifizierte Konformität kein bürokratisches Hindernis – sie ist der Eintritt.
Aber diese Chance erfordert, dass man die Anforderung ernst nimmt. Und rechtzeitig.
„Wir haben bis 2027″ ist kein Plan. Es ist eine Illusion, die teuer werden kann. Wer jetzt anfängt, hat noch Optionen. Wer wartet, hat 2027 weniger davon. Sprechen Sie mich an.
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar