Ein Release steht kurz vor der Freigabe. Die automatisierten Tests sind grün, die bekannten Schwachstellen bewertet, die Dokumentation ist fast fertig. Dann erscheint ein Bericht über KI-Agenten, die Angriffe schneller und mit weniger menschlichen Eingriffen ausführen können. Muss die Risikobewertung jetzt neu geschrieben werden? Braucht das Produkt eine eigene KI-Abwehr? Und reicht ein herkömmlicher Penetrationstest überhaupt noch? Die kurze Antwort lautet: Die Bedrohung verändert sich, die rechtliche Methode bleibt. Der Cyber Resilience Act schreibt keine KI-Verteidigung vor. Er verlangt jedoch, dass Hersteller die tatsächliche Risikolage ihres Produkts ernst nehmen — bei der Entwicklung, vor dem Release und während des gesamten Unterstützungszeitraums.

Der Anlass: eine zugespitzte These mit einem richtigen Kern

Die NZZ hat Ende August 2026 in einem Kommentar beschrieben, wie künstliche Intelligenz die Cybersicherheit verändert[1]. Im Mittelpunkt stehen drei Eigenschaften: Geschwindigkeit, Masse und technische Komplexität. KI-gestützte Systeme können Ziele automatisiert analysieren, mehrere Vorgehensweisen parallel verfolgen und Teile einer Angriffskette schneller bearbeiten, als es ein einzelner Mensch könnte. Die Schlussfolgerung des Kommentars ist optimistisch, aber dringlich: Cyberabwehr sei möglich, müsse jedoch stärker automatisiert werden; KI könne dabei selbst ein wichtiges Werkzeug sein.

Als Schlagzeile funktioniert „KI gegen KI“. Als Sicherheitskonzept ist uns die Formel zu einfach.

Ein gut abgesichertes Produkt braucht nicht zwingend ein lernendes Modell, das jeden Angriff in Echtzeit erkennt. Oft leisten sorgfältig gesetzte Zugriffsrechte, eine kleine Angriffsfläche, sichere Standardkonfigurationen, signierte Updates, belastbare Protokollierung und ein geübter Schwachstellenprozess mehr. Umgekehrt wird ein unsicheres Produkt nicht dadurch sicher, dass vor seine Schwachstellen ein KI-System geschaltet wird. Wer die Grundlagen auslässt, automatisiert im schlechtesten Fall nur die Illusion von Kontrolle.

Der NZZ-Kommentar trifft dennoch einen wichtigen Punkt: Die Wirtschaftlichkeit von Angriffen verschiebt sich. Wenn sich Recherche, Schwachstellensuche, Codeerstellung oder die Koordination einzelner Angriffsschritte automatisieren lassen, kann ein Angreifer mehr Ziele mit weniger Zeitaufwand prüfen. Schwachstellen, die gestern wegen des manuellen Aufwands kaum attraktiv waren, können morgen in grösserem Massstab ausgenutzt werden. Für Hersteller folgt daraus nicht automatisch eine neue einzelne Schutzmassnahme. Es folgt die Pflicht, die Annahmen hinter der bisherigen Risikobewertung zu überprüfen.

Genau an dieser Stelle trifft die aktuelle Debatte auf den Cyber Resilience Act.

Was die bekannt gewordenen Unternehmensberichte tatsächlich belegen

Die öffentliche Diskussion stützt sich derzeit stark auf Berichte der Unternehmen, die Modelle entwickeln oder evaluieren. Diese Veröffentlichungen sind wertvoll, aber sie sind keine unabhängigen Untersuchungsberichte. Ihre Aussagen sollten deshalb weder ignoriert noch ungeprüft als gesicherter Gesamtbefund übernommen werden.

Anthropic berichtete im November 2025 über eine nach eigener Einschätzung chinesische, staatlich unterstützte Spionagekampagne. Nach Darstellung des Unternehmens wurde Claude Code gegen rund dreissig Ziele eingesetzt; in einer kleinen Zahl von Fällen sei der Zugriff gelungen. Menschen hätten Ziele ausgewählt und die Angriffsinfrastruktur eingerichtet, während zahlreiche operative Schritte weitgehend automatisiert worden seien. Anthropic bezeichnete dies als ersten dokumentierten gross angelegten Cyberangriff ohne substanzielle menschliche Mitwirkung[6]. Das ist die Einschätzung des betroffenen Modellanbieters, nicht das Ergebnis einer behördlichen oder gerichtlich überprüften Aufarbeitung.

OpenAI veröffentlichte im August 2026 zwei eigene Mitteilungen. Die erste betrifft Cybersecurity-Evaluationen durch externe Partner, bei denen die Modellaktivität nach Darstellung des Unternehmens über den vorgesehenen Testrahmen hinausging[7]. Die zweite betrifft einen Sicherheitsvorfall im Zusammenhang mit Hugging Face, bei dem eigene Modelle in einer Evaluationsumgebung Sicherheitskontrollen umgangen und Drittsysteme erreicht haben sollen[8]. Der zweite Fall ist damit weniger ein externer Cyberangriff als ein Kontrollverlust über ein eingesetztes KI-System — ein Szenario, auf das wir bei den Leitplanken für KI-Werkzeuge zurückkommen. Das Unternehmen spricht in beiden Veröffentlichungen von fortgeschrittenen Cyberfähigkeiten sowie von Massnahmen zur Stärkung der Modellsicherheit, der Überwachung und der Ausrichtung von Modellen[7][8]. Auch hier gilt: Die Berichte stammen von einem beteiligten Unternehmen. Sie zeigen reale Fragestellungen bei Evaluation, Zugriffskontrolle und Überwachung; sie erlauben aber keine pauschale Aussage, wonach KI-Agenten nun jedes beliebige IT-System autonom kompromittieren könnten.

Die EU-Kommission wählte in ihrer Mitteilung zur finalen CRA-Leitlinie eine bemerkenswert klare Formulierung. Neuere Entwicklungen bei Frontier-KI-Modellen mit Cyberfähigkeiten machten eine schnelle und korrekte Umsetzung des CRA noch dringlicher[4]. Diese Aussage ist politisch und praktisch bedeutsam. Rechtlich ändert sie den Verordnungstext nicht. Weder die Kommissionsmitteilung noch die Leitlinie C(2026) 5252 führen eine allgemeine Pflicht ein, zur Abwehr künstliche Intelligenz einzusetzen.

Wir lesen die derzeitige Quellenlage daher so: Es gibt genügend Hinweise, um KI-gestützte Angriffsmöglichkeiten in einer zeitgemässen Bedrohungsanalyse zu berücksichtigen. Es gibt keinen Grund, daraus eine allumfassende technische Überlegenheit der Angreifer abzuleiten. Und es wäre falsch, einzelne Unternehmensberichte in eine neue, vom CRA angeblich vorgeschriebene Produktfunktion umzudeuten.

Der CRA reguliert Produktsicherheit — nicht jede Unternehmens-IT

Bevor ein Hersteller neue Kontrollen plant, muss er sauber bestimmen, wofür er sie plant. Der CRA ist eine Produktverordnung. Er legt horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem Unionsmarkt bereitgestellt werden. Er ist kein allgemeines Gesetz zur Absicherung sämtlicher interner IT-Systeme eines Unternehmens.

Diese Abgrenzung ist bei KI-Cyberangriffen besonders wichtig. Ein Angriff auf das E-Mail-System, das interne Identitätsmanagement oder die Entwicklungsumgebung eines Herstellers kann für das Unternehmen schwerwiegend sein. Daraus folgt aber nicht ohne Weiteres, dass jede Massnahme zum Schutz dieser Systeme eine grundlegende Produktanforderung des CRA ist. Der CRA wird produktbezogen, wenn zum Beispiel

  • die Entwicklungs- oder Lieferkette die Integrität des ausgelieferten Produkts gefährdet,
  • Zugangsdaten oder Signierschlüssel für Produktupdates betroffen sind,
  • eine Schwachstelle im Produkt oder in einer integrierten Komponente ausgenutzt wird,
  • das Produkt selbst sicherheitsrelevante Ereignisse nicht angemessen erfassen oder melden kann,
  • ein Vorfall die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigt oder
  • die internen Prozesse des Herstellers eine wirksame Behandlung von Produktschwachstellen nicht mehr gewährleisten.

Für die allgemeine Unternehmens- und Netzwerksicherheit können daneben insbesondere die NIS-2-Richtlinie und ihre nationale Umsetzung, sektorspezifische Vorgaben, Datenschutzrecht oder vertragliche Pflichten relevant sein. Die Regime überschneiden sich in der Praxis, ihre Adressaten und Rechtsfolgen sind jedoch nicht identisch. Ein CRA-Projektdossier sollte diese Ebenen nicht vermischen.

Für Schweizer Hersteller ist der Marktbezug entscheidend. Wer ein erfasstes Produkt auf dem EU-Markt bereitstellt, kann den CRA erfüllen müssen, auch wenn Entwicklung und Unternehmenssitz in der Schweiz liegen. Die Frage lautet nicht, wo der Code geschrieben wurde, sondern ob das Produkt in den sachlichen und räumlichen Anwendungsbereich der Verordnung fällt. Den allgemeinen Anwendungsbereich und die Abgrenzung zu reinem SaaS haben wir in den früheren Beiträgen dieser Serie erläutert.

Keine KI-Pflicht, aber ein verbindlicher Sicherheitsrahmen

Art. 13 Abs. 1 CRA verpflichtet Hersteller, Produkte mit digitalen Elementen so zu konzipieren, zu entwickeln und herzustellen, dass sie die grundlegenden Cybersicherheitsanforderungen aus Anhang I Teil I erfüllen[2]. Art. 13 Abs. 2 verlangt eine Bewertung der Cybersicherheitsrisiken. Deren Ergebnis muss in Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung berücksichtigt werden. Ziel ist, Risiken zu minimieren, Sicherheitsvorfälle zu verhindern und ihre Auswirkungen möglichst gering zu halten.

Der Verordnungstext nennt dafür kein bestimmtes Produkt und keinen bestimmten Anbieter. Er verlangt weder ein Large Language Model noch einen KI-Agenten, weder ein bestimmtes Scanwerkzeug noch ein Security Operations Center in einer festgelegten Grösse. Das ist kein Mangel, sondern Ausdruck der technologieneutralen und risikobasierten Konstruktion.

Die Pflicht ist dennoch konkret. Anhang I verlangt zunächst ein angesichts der Risiken angemessenes Cybersicherheitsniveau. Abhängig von der Risikobewertung kommen unter anderem folgende Produkteigenschaften hinzu:

  • Bereitstellung ohne bekannte ausnutzbare Schwachstellen, soweit dies für das Produkt zutrifft;
  • sichere Standardkonfiguration;
  • Behebbarkeit von Schwachstellen durch Sicherheitsaktualisierungen, gegebenenfalls mit automatischer Installation und benutzerfreundlicher Opt-out-Möglichkeit;
  • Schutz vor unbefugtem Zugriff, einschliesslich geeigneter Authentifizierungs-, Identitäts- oder Zugriffsmechanismen;
  • Schutz der Vertraulichkeit und Integrität von Daten, Befehlen, Programmen und Konfigurationen;
  • Begrenzung der Angriffsfläche;
  • Minderung der Auswirkungen eines Sicherheitsvorfalls;
  • Aufzeichnung oder Überwachung sicherheitsbezogener interner Vorgänge, verbunden mit der im CRA vorgesehenen Opt-out-Möglichkeit für Nutzer;
  • Schutz der Verfügbarkeit wesentlicher Funktionen, auch durch Abwehr- und Eindämmungsmassnahmen gegen Überlastungsangriffe.

Anhang I Teil II ergänzt die Anforderungen an den Umgang mit Schwachstellen. Hersteller müssen Schwachstellen und Komponenten ermitteln und dokumentieren, unter anderem mithilfe einer Software-Stückliste. Sie müssen Schwachstellen im Hinblick auf das Produktrisiko unverzüglich behandeln, das Produkt regelmässig und wirksam testen, eine Strategie für die koordinierte Offenlegung von Schwachstellen einrichten und Mechanismen für die sichere Verbreitung von Updates bereitstellen[2].

Keine dieser Anforderungen lautet „Setzen Sie KI ein“. Fast jede kann aber durch geeignete Automatisierung unterstützt werden. Diese Unterscheidung sollte in Lastenheften, Verträgen und technischen Dokumentationen sichtbar bleiben: Die gesetzliche Pflicht betrifft das Schutzziel und den Prozess. Das eingesetzte Werkzeug ist eine Umsetzungsentscheidung des Herstellers.

Wie KI die Risikobewertung verändert

Die Risikobewertung nach Art. 13 CRA ist keine einmalige Liste bekannter CVEs. Sie muss mindestens die Zweckbestimmung, die vernünftigerweise vorhersehbare Verwendung, die Betriebsumgebung und die zu schützenden Güter berücksichtigen. Während des Unterstützungszeitraums wird sie dokumentiert und gegebenenfalls aktualisiert. Art. 13 Abs. 7 verlangt darüber hinaus, relevante Cybersicherheitsaspekte und bekannt gewordene Schwachstellen systematisch und der Art des Risikos angemessen zu dokumentieren[2].

Ein Hersteller muss also nicht abstrakt die Frage beantworten, ob „KI gefährlich“ ist. Er muss konkreter werden:

Welche Angriffsschritte könnten bei unserem Produkt leichter skalieren? Ein öffentlich erreichbares Administrationsinterface, ein verbreitetes Standardpasswort oder eine ungeprüfte Eingabe kann für automatisierte Angriffe attraktiver sein als eine stark begrenzte, nur lokal erreichbare Schnittstelle.

Welche Annahmen zur Reaktionszeit sind noch tragfähig? Wenn Scans, Variantenbildung oder die Ausnutzung einer veröffentlichten Schwachstelle schneller erfolgen können, darf ein Prozess nicht darauf bauen, dass zwischen Bekanntwerden und Missbrauch regelmässig mehrere Wochen liegen.

Welche Teile der Lieferkette sind besonders exponiert? Automatisierte Schwachstellensuche betrifft nicht nur den eigenen Code. Abhängigkeiten, Build-Prozesse, Paketquellen, Signierschlüssel und Update-Infrastruktur können ebenso relevant sein.

Was könnte ein Angreifer mit dem Produkt bewirken? Bei einer lokalen Desktop-Anwendung sind andere Auswirkungen zu erwarten als bei einem fernadministrierbaren Industrieprodukt, einem Identitätsdienst oder einer Komponente, die in zahlreiche weitere Produkte eingebaut wird.

Kann das Produkt einen Angriff begrenzen? Eine kompromittierte Funktion sollte nicht automatisch Zugriff auf sämtliche Daten, Mandanten oder angeschlossenen Systeme eröffnen. Segmentierung, Rechtebegrenzung und sichere Wiederherstellung bleiben wichtig, unabhängig davon, ob der erste Zugriff durch einen Menschen, ein Skript oder ein agentisches System erfolgte.

Die Kommissionsleitlinie C(2026) 5252 bestätigt diesen risikobasierten Ansatz. Sie stellt klar, dass die Anwendbarkeit und Umsetzung einzelner Anforderungen anhand der Risikobewertung zu bestimmen sind. Bestehende Sicherheitsmassnahmen können genügen, wenn der Hersteller ihre Angemessenheit nachweist. Der CRA verlangt nicht allein deshalb ein Redesign oder neue Funktionen, weil eine andere technische Lösung denkbar wäre[3].

Für KI-Risiken gilt dasselbe: Eine aktualisierte Bedrohungsannahme kann zu neuen oder strengeren Kontrollen führen. Sie kann aber auch zum dokumentierten Ergebnis führen, dass vorhandene Kontrollen das zusätzliche Risiko bereits angemessen abdecken. Entscheidend ist, dass diese Schlussfolgerung aus dem Produkt, seiner Verwendung und nachvollziehbaren Nachweisen hergeleitet wird.

Regelmässig testen heisst nicht: jeden Freitag denselben Scanner starten

Die vielleicht direkteste Verbindung zwischen der aktuellen Angriffsentwicklung und dem CRA liegt in Anhang I Teil II Nr. 3. Danach müssen Hersteller die Sicherheit ihres Produkts während des Unterstützungszeitraums regelmässig und wirksam testen und überprüfen[2].

Die finale Kommissionsleitlinie präzisiert den Begriff. Regelmässige Tests bedeuten nicht, in starren Abständen mechanisch eine unveränderte Testkampagne zu wiederholen. Hersteller sollen vielmehr fortlaufend prüfen, ob neue Erkenntnisse — etwa neue Bedrohungen oder neu entdeckte Schwachstellen — eine Anpassung der bestehenden Tests verlangen. Häufigkeit, Tiefe und Inhalt sollen zum Risikoprofil des Produkts, seiner Entwicklung und zur Bedrohungslage passen. Wenn sich relevante neue Erkenntnisse ergeben, sind neue oder geänderte Tests zu entwerfen und auszuführen; bei Produktänderungen können auch Regressionstests angezeigt sein. Gibt es keine relevanten neuen Erkenntnisse, verlangt die Leitlinie nicht, künstlich zusätzliche Tests zu erfinden[3].

Das ist für die KI-Debatte hilfreicher als eine pauschale Forderung nach „mehr Penetrationstests“. Hersteller sollten ihren Testbestand gegen veränderte Angriffswege prüfen. Je nach Produkt können dazugehören:

  • statische Codeanalyse und Prüfung von Abhängigkeiten in der CI/CD-Pipeline;
  • dynamische Tests exponierter Schnittstellen;
  • negative Tests, die ausdrücklich prüfen, was ein Nutzer oder Prozess nicht tun können darf;
  • Fuzzing von Parsern, Protokollen und Dateiformaten;
  • Tests von Authentifizierung, Autorisierung und Mandantentrennung;
  • Missbrauchsfälle für Rate Limits, Ressourcenverbrauch und automatisierte Anfragen;
  • Prüfung der Updatekette, einschliesslich Signaturvalidierung, Rollback-Schutz und Fehlerverhalten;
  • gezielte Penetrationstests bei hohem Risiko oder sicherheitsrelevanten Änderungen;
  • erneute Tests nach Architekturänderungen, neuen Abhängigkeiten oder veränderter Betriebsumgebung.

KI kann dabei Testfälle vorschlagen, Codepfade priorisieren, Varianten generieren oder grosse Mengen von Ergebnissen vorsortieren. Sie kann den Testprozess beschleunigen. Der Hersteller bleibt dafür verantwortlich, dass die Tests zum Produkt passen, die Ergebnisse richtig bewertet werden und relevante Lücken nicht wegen eines falschen Sicherheitsgefühls unbeachtet bleiben.

Ein KI-generierter Test ohne nachvollziehbare Zielsetzung ist kein guter Nachweis. Für die technische Dokumentation braucht es zumindest die Verbindung zwischen Risiko, Anforderung, Testmethode, Ergebnis, Abweichung und Freigabeentscheidung. Das gilt genauso für herkömmliche Werkzeuge. Neu ist nur, dass bei agentischen Systemen zusätzlich geklärt werden sollte, welche Werkzeuge und Daten sie verwenden durften und ob ihre Aktionen begrenzt und protokolliert waren.

Monitoring: Ein CRA-Begriff mit klaren Grenzen

Die NZZ hebt die Möglichkeit hervor, mithilfe von KI auffälliges Verhalten schnell zu erkennen und Zugänge automatisch zu sperren[1]. Für Betreiber grosser IT-Umgebungen kann das eine sinnvolle Verteidigungsstrategie sein. Der CRA stellt jedoch eine andere und enger auf das Produkt bezogene Frage.

Anhang I Teil I Nr. 2 lit. l verlangt — soweit nach der Risikobewertung einschlägig —, dass das Produkt sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung relevanter interner Vorgänge bereitstellt. Als Beispiele nennt die Verordnung den Zugriff auf Daten, Dienste oder Funktionen sowie Änderungen daran. Nutzern muss ein Opt-out-Mechanismus zur Verfügung stehen[2].

Daraus folgt nicht, dass jedes Produkt sämtliche Nutzerdaten zentral an den Hersteller übertragen oder eine KI-basierte Verhaltensanalyse durchführen muss. Eine solche Auslegung würde Fragen des Datenschutzes, der Vertraulichkeit, der Zweckbindung und der Datenminimierung aufwerfen. Der CRA selbst verlangt in Anhang I zugleich, die Verarbeitung personenbezogener und sonstiger Daten auf das für die Zweckbestimmung angemessene und erforderliche Mass zu begrenzen.

Ein plausibles Monitoring-Konzept beginnt daher mit vier Entscheidungen:

  1. Welche Ereignisse sind für die Sicherheit dieses Produkts tatsächlich relevant?
  2. Wo werden sie erfasst und wie lange werden sie benötigt?
  3. Wer darf sie sehen, und wie werden Integrität und Vertraulichkeit der Protokolle geschützt?
  4. Welche Reaktion ist bei einem Signal erlaubt — Hinweis, zusätzliche Prüfung, temporäre Begrenzung oder automatische Sperre?

Automatische Reaktionen können die Zeit bis zur Eindämmung verkürzen. Sie können aber auch legitime Nutzer aussperren oder kritische Funktionen unterbrechen. Bei einem Produkt, dessen Verfügbarkeit sicherheitsrelevant ist, muss der Hersteller die Auswirkungen eines Fehlalarms genauso betrachten wie die Folgen eines übersehenen Angriffs. Vollautomatisierung ist keine Vermutung zugunsten der Sicherheit. Sie ist eine Designentscheidung, die selbst in die Risikobewertung gehört.

Schwachstellenmanagement wird zum laufenden Kernprozess

KI-gestützte Schwachstellensuche kann die Zahl potenzieller Funde erhöhen. Damit wächst nicht nur die Chance, Fehler früher zu entdecken. Es wächst auch die Gefahr, dass Teams in ungeprüften Meldungen, Duplikaten und theoretischen Ergebnissen versinken.

Die Kommissionsleitlinie liefert dafür eine nützliche Einordnung. Eine Schwachstelle kann dem Hersteller nicht nur durch öffentliche Datenbanken oder eine koordinierte Meldung bekannt werden, sondern auch durch eigene interne Tests und Analysen; als Beispiel nennt die Leitlinie ausdrücklich KI-gestützte Dienste. Ein Fund allein bedeutet jedoch noch nicht, dass die Schwachstelle unter praktischen Betriebsbedingungen ausnutzbar ist oder das konkrete Produkt betrifft. Der Hersteller muss die Information untersuchen, verifizieren und auf die eigene Produktkonfiguration beziehen[3].

Damit entsteht ein Arbeitsprozess, der nicht bei der Erkennung endet:

  • Fund aufnehmen und Herkunft festhalten;
  • betroffene Versionen und Komponenten bestimmen;
  • technische Richtigkeit und praktische Ausnutzbarkeit prüfen;
  • Schwere, Exposition und mögliche Auswirkungen bewerten;
  • erforderliche Eindämmung oder Behebung bestimmen;
  • Sicherheitsupdate entwickeln und testen;
  • Veröffentlichung und Nutzerinformation planen;
  • Risikobewertung, SBOM und technische Dokumentation aktualisieren;
  • bei aktiver Ausnutzung die Meldepflichten nach Art. 14 CRA prüfen.

Für integrierte Komponenten enthält Art. 13 Abs. 6 zusätzliche Vorgaben. Stellt der Hersteller dort eine Schwachstelle fest, muss er sie der herstellenden oder wartenden Person beziehungsweise Einrichtung melden und selbst behandeln. Entwickelt er einen Fix für die Komponente, ist dieser unter den gesetzlichen Voraussetzungen weiterzugeben[2]. Gerade bei automatisierter Analyse von Open-Source-Abhängigkeiten ist deshalb ein sauberer Upstream-Prozess nötig. Ein Ticket in der eigenen Entwicklung löst die Lieferkettenpflicht nicht vollständig.

Eine SBOM hilft, Funde einem Produkt zuzuordnen. Sie beantwortet aber nicht von selbst, ob eine Komponente im konkreten Build vorhanden, der fehlerhafte Code erreichbar oder eine Schwachstelle praktisch ausnutzbar ist. KI kann bei der Korrelation unterstützen; die produktbezogene Entscheidung und ihre Dokumentation bleiben beim Hersteller.

Sicherheitsupdates müssen schneller werden, aber nicht unkontrollierter

Wer mit schnelleren Angriffen rechnet, denkt rasch an schnellere Patches. Das ist richtig, solange Geschwindigkeit nicht gegen Integrität ausgespielt wird.

Anhang I Teil II verlangt, Schwachstellen im Verhältnis zum Risiko unverzüglich zu behandeln und zu beheben. Sicherheitsupdates müssen sicher verbreitet werden; verfügbare Sicherheitsaktualisierungen sind unverzüglich und grundsätzlich kostenlos bereitzustellen. Soweit technisch machbar, sollen Sicherheitsupdates getrennt von Funktionsupdates angeboten werden[2]. Art. 13 Abs. 9 regelt zusätzlich, wie lange bereitgestellte Sicherheitsaktualisierungen verfügbar bleiben müssen.

Ein belastbarer Updateprozess braucht daher mehr als eine kurze Entwicklungszeit. Er umfasst typischerweise:

  • eindeutige Zuordnung des Updates zu Produkt und Version;
  • Schutz des Build- und Signierprozesses;
  • Prüfung der Authentizität und Integrität beim Empfang;
  • sichere Fehlerbehandlung bei unterbrochener Installation;
  • Regressionstests für sicherheitsrelevante Funktionen;
  • verständliche Hinweise für Nutzer;
  • dokumentierte Entscheidung über automatische Installation, Aufschub und Opt-out;
  • einen Plan für Rücknahme oder Wiederherstellung, falls das Update selbst Fehler verursacht.

KI kann die Analyse eines Fehlers oder die Erstellung eines Patch-Entwurfs beschleunigen. Einen ungeprüften, von einem Modell vorgeschlagenen Code direkt in eine signierte Sicherheitsaktualisierung zu übernehmen, wäre dagegen schwer mit einem kontrollierten Entwicklungs- und Freigabeprozess vereinbar. Je kürzer die Reaktionszeit, desto besser müssen Verantwortlichkeiten, Tests und technische Freigabeschranken vorbereitet sein.

Die Risikobewertung endet nicht mit der CE-Kennzeichnung

Ein häufiger Denkfehler lautet: Vor dem Inverkehrbringen wird geprüft, danach wird nur noch gepatcht. Art. 13 zeichnet ein anderes Bild. Die Risikobewertung ist während des Unterstützungszeitraums zu dokumentieren und gegebenenfalls zu aktualisieren. Der Hersteller muss relevante Cybersicherheitsaspekte systematisch festhalten. Schwachstellen müssen über die erwartete Produktlebensdauer und den Unterstützungszeitraum wirksam behandelt werden[2].

Eine veränderte KI-Bedrohungslage ist daher kein Anlass für hektische Produktpolitik, wohl aber ein möglicher Aktualisierungsauslöser. Praktisch sollte der Hersteller festlegen, welche Ereignisse eine Überprüfung anstossen. Dazu können gehören:

  • neue Angriffsverfahren, die das Produkt oder seine Technologieklasse betreffen;
  • belastbare Hinweise auf schnellere oder breiter skalierbare Ausnutzung;
  • neu bekannt gewordene Schwachstellen im eigenen Produkt oder in Abhängigkeiten;
  • Sicherheitsvorfälle bei vergleichbaren Produkten;
  • Änderungen an Architektur, Schnittstellen oder Betriebsumgebung;
  • neue sicherheitsrelevante Produktfunktionen;
  • Erkenntnisse aus Support, Monitoring, Tests oder externen Meldungen.

Nicht jedes Ereignis verlangt eine neue Fassung des gesamten Dossiers. Es sollte aber erkennbar sein, dass der Hersteller den Hinweis bewertet hat: betroffen oder nicht betroffen, vorhandene Kontrolle ausreichend oder nicht ausreichend, weitere Prüfung erforderlich oder abgeschlossen. Diese kurzen, nachvollziehbaren Entscheidungen sind im Ernstfall wertvoller als ein umfangreiches Dokument, das seit dem ersten Release nicht mehr geöffnet wurde.

Ab 11. September 2026 gelten die CRA-Meldepflichten

Die Meldepflichten nach Art. 14 CRA gelten ab dem 11. September 2026. Die übrigen Hauptpflichten des CRA gelten grundsätzlich ab dem 11. Dezember 2027[2]. Diese unterschiedlichen Stichtage dürfen nicht verwechselt werden. Hinzu kommt eine Besonderheit, die oft übersehen wird: Nach Art. 69 Abs. 3 CRA gelten die Meldepflichten ab dem 11. September 2026 für alle erfassten Produkte mit digitalen Elementen — auch für solche, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden und von den übrigen Anforderungen der Verordnung deshalb noch nicht erfasst sind[2]. Wer bereits ein erfasstes Produkt auf dem EU-Markt hat, braucht den Meldeprozess daher nicht erst mit dem nächsten Release.

Art. 14 betrifft insbesondere aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen haben. Die Meldung erfolgt gestuft über die dafür vorgesehene einheitliche Meldeplattform: Eine Frühwarnung ist grundsätzlich unverzüglich, spätestens binnen 24 Stunden nach Kenntniserlangung abzugeben; weitere Angaben folgen grundsätzlich binnen 72 Stunden. Die Fristen und Inhalte unterscheiden sich im Detail zwischen aktiv ausgenutzter Schwachstelle und schwerwiegendem Sicherheitsvorfall. Den vollständigen Ablauf haben wir im Beitrag zu den CRA-Meldepflichten dargestellt.

KI kann die Triage beschleunigen, aber die rechtliche Einordnung nicht stillschweigend übernehmen. „Schwachstelle entdeckt“, „Schwachstelle praktisch ausnutzbar“, „aktiv ausgenutzt“ und „schwerwiegender Sicherheitsvorfall“ sind verschiedene Feststellungen. Für die Frist ist zudem die Kenntniserlangung des Herstellers entscheidend. Wer automatisierte Systeme einsetzt, sollte deshalb vorab klären, wann ein technisches Signal als ungeprüfter Hinweis gilt, wann ein Mensch oder ein definierter Prozess die Relevanz bestätigt und wie diese Zeitpunkte dokumentiert werden.

Der gefährlichste Moment ist nicht der, in dem ein Modell zu viele Warnungen erzeugt. Es ist der, in dem niemand weiss, wer eine Warnung übernehmen, bewerten und nötigenfalls melden muss.

Wo KI in der Verteidigung sinnvoll eingesetzt werden kann

Hersteller müssen künstliche Intelligenz nicht einsetzen. Sie dürfen sie als Werkzeug nutzen, wenn der Einsatz zum Produkt, zu den Daten und zum Risiko passt. Besonders naheliegend sind fünf Einsatzfelder.

Analyse von Code und Abhängigkeiten. Modelle können Hinweise aus statischer Analyse zusammenfassen, verdächtige Muster priorisieren oder bei der Zuordnung von Schwachstellen zu Codepfaden helfen. Ergebnisse sollten reproduzierbar geprüft werden; Quellcode und vertrauliche Informationen dürfen nicht unkontrolliert an externe Dienste gelangen.

Testvorbereitung. Aus Anforderungen, Schnittstellenbeschreibungen und früheren Fehlern lassen sich zusätzliche Testideen oder Missbrauchsfälle ableiten. Das Modell erweitert den Denkraum, ersetzt aber weder ein fachliches Testziel noch die Verifikation des Ergebnisses.

Triage eingehender Meldungen. KI kann Duplikate erkennen, unstrukturierte Meldungen ordnen oder betroffene Komponenten vorschlagen. Die Einstufung von Ausnutzbarkeit, Schwere und Meldepflicht braucht überprüfbare Kriterien und eine verantwortliche Person.

Auswertung von Produkttelemetrie und Protokollen. Bei geeigneten Produkten kann Mustererkennung helfen, ungewöhnliches Verhalten schneller zu erkennen. Datenminimierung, Zugriffsschutz, Aufbewahrung und Fehlalarmfolgen müssen von Anfang an mitgeplant werden.

Unterstützung bei der Dokumentation. Informationen aus Tickets, Tests und Release-Unterlagen können zu einem Entwurf für das Risikodossier zusammengeführt werden. Das ist nützlich, solange Quellen, Versionen und Freigaben erhalten bleiben und keine nicht belegten Aussagen in die technische Dokumentation gelangen.

Das ENISA „Secure by Design and Default Playbook“ bietet dafür einen guten, bewusst technologieoffenen Rahmen[5]. Es beschreibt 22 Prinzipien, gegliedert in architektonische Grundlagen, operative Integrität, sichere Standardeinstellungen und geführten Schutz. Für jedes Prinzip nennt ENISA praktische Schritte, mögliche Nachweise und Kriterien für eine Release-Prüfung. Besonders hilfreich für KMU ist der Rat, kleine wiederverwendbare Artefakte zu pflegen, automatisierte Kontrollen in CI/CD zu bevorzugen und vertiefte manuelle Prüfungen dort einzusetzen, wo das Risiko sie rechtfertigt.

Das Playbook ist keine Rechtsnorm und kein vollständiges Compliance-Handbuch. ENISA bezeichnet die Zuordnung seiner Prinzipien zu Anhang I CRA ausdrücklich als indikativ. Wer die Checklisten übernimmt, erhält also noch keine automatische Konformitätsvermutung. Er gewinnt aber eine brauchbare technische Struktur für Kontrollen, die sich dokumentieren und in bestehende Entwicklungsabläufe einbauen lassen.

KI-Werkzeuge brauchen ihre eigenen Leitplanken

Sobald ein KI-System mehr darf als Text vorschlagen, wird seine Einbindung selbst sicherheitsrelevant. Ein Agent, der Repositories durchsuchen, Scanner starten, Tickets ändern oder Testsysteme ansprechen kann, hat reale Berechtigungen. Diese Berechtigungen sollten nicht weiter reichen als für die jeweilige Aufgabe nötig.

Wir würden für einen solchen Einsatz mindestens folgende Punkte dokumentieren:

  • klarer Zweck und zulässiger Arbeitsbereich des Systems;
  • erlaubte Datenquellen, Werkzeuge und Zielumgebungen;
  • technische Begrenzung von Netzwerkzugriffen und Berechtigungen;
  • Trennung von Entwicklungs-, Test- und Produktionsumgebung;
  • Freigabeschritt vor Änderungen an Code, Konfiguration oder produktiven Systemen;
  • nachvollziehbare Protokollierung der Aktionen und verwendeten Versionen;
  • Umgang mit vertraulichem Quellcode, personenbezogenen Daten und Geheimnissen;
  • Abbruchmöglichkeit und sichere Rückkehr in einen bekannten Zustand;
  • Prüfung von Fehlalarmen, übersehenen Befunden und nicht reproduzierbaren Ergebnissen;
  • Verantwortlichkeit einer natürlichen Person für die abschliessende Entscheidung.

Diese Punkte sind keine wörtliche „KI-Checkliste“ des CRA. Sie sind eine praktische Konsequenz aus allgemeinen Prinzipien wie Rechtebegrenzung, Angriffsflächenminimierung, Integrität, Überwachung und kontrollierter Änderung. Welche Massnahmen erforderlich sind, hängt davon ab, ob das KI-Werkzeug bloss einen Bericht entwirft oder selbst in einer Testumgebung handelt.

Dass diese Frage nicht theoretisch ist, zeigen die Anbieterberichte selbst: Der von OpenAI beschriebene Hugging-Face-Vorfall betraf nach Darstellung des Unternehmens ein KI-System, das in einer Evaluationsumgebung mehr Zugriff erlangte als vorgesehen[8]. Auch die Berichte zu missbräuchlicher Modellnutzung unterstreichen, dass Schutzmechanismen, Überwachung und Missbrauchserkennung weiterentwickelt werden müssen[6][7]. Für einen Produkthersteller genügt es allerdings nicht, sich auf die Sicherheitsversprechen des Modellanbieters zu verlassen. Er muss seine eigene Integration, seine Berechtigungen und die Auswirkungen eines Fehlverhaltens bewerten.

Ein Beispiel: Das Update-Gateway eines mittelständischen Herstellers

Nehmen wir einen fiktiven Hersteller, der ein Gateway für die Fernwartung kleiner Industrieanlagen vertreibt. Das Gerät besitzt eine Weboberfläche, nimmt signierte Updates entgegen und kommuniziert mit einem zentralen Wartungsdienst. Der Hersteller hat bereits Zugriffskontrollen, eine SBOM, Schwachstellenscans und einen jährlichen Penetrationstest eingerichtet.

Nun zeigen neue Berichte, dass agentische Systeme Aufklärung, Variantenbildung und die Verkettung mehrerer Angriffsschritte beschleunigen können. Daraus folgt noch nicht, dass das Gateway ein eigenes KI-Modell benötigt. Der Hersteller überprüft stattdessen die Annahmen seines Risikodossiers.

Er stellt fest, dass die Weboberfläche bei Fehlversuchen zwar protokolliert, aber nicht ausreichend begrenzt. Die Schnittstelle ist öffentlich erreichbar, weil einzelne Kunden keine VPN-Infrastruktur betreiben. Ein Angreifer könnte Zugangsdaten automatisiert testen und danach bekannte Schwächen in einer älteren Webkomponente prüfen. Die Komponente ist in der SBOM erfasst; der bisherige Prozess bewertet neue Hinweise jedoch nur einmal pro Woche.

Die angemessene Reaktion könnte aus mehreren Schritten bestehen: stärkere Authentifizierung, Rate Limits, bessere Mandantentrennung, eine enger begrenzte Administrationsschnittstelle, tägliche statt wöchentliche Prüfung relevanter Schwachstellenquellen, zusätzliche negative Tests und ein aktualisierter Incident- und Meldeprozess. Für besonders auffällige Muster könnte der Hersteller später eine lernende Erkennung erproben. Die ersten wirksamen Massnahmen sind jedoch klassische Sicherheitskontrollen.

In der technischen Dokumentation hält er fest, welcher neue Hinweis die Überprüfung ausgelöst hat, welche Angriffsszenarien betroffen sind, welche bestehenden Kontrollen genügen und wo zusätzliche Massnahmen beschlossen wurden. Anschliessend werden Tests und Freigabekriterien angepasst. Genau darin zeigt sich der risikobasierte CRA-Ansatz: keine reflexhafte Technologiebeschaffung, sondern eine begründete Verbindung zwischen Bedrohung, Produkt, Kontrolle und Nachweis.

Ein Arbeitsplan für die nächste Release-Runde

Hersteller müssen wegen der aktuellen Berichte nicht ihre gesamte Architektur in einer Woche umbauen. Sie sollten aber die nächste Release- oder Risiko-Runde nutzen, um zehn Fragen verbindlich zu beantworten:

  1. Geltungsbereich: Welches Produkt und welche Version betrachten wir, und fällt das Produkt voraussichtlich unter den CRA?
  2. Exposition: Welche Schnittstellen, Konten und Funktionen sind aus externen oder weniger vertrauenswürdigen Netzen erreichbar?
  3. Schutzgüter: Welche Daten, Funktionen und verbundenen Systeme könnten bei einem erfolgreichen Angriff beeinträchtigt werden?
  4. Skalierung: Welche bisherigen Angriffsannahmen verändern sich, wenn Aufklärung und Versuche schneller oder parallel erfolgen?
  5. Grundkontrollen: Sind sichere Standardkonfiguration, Rechtebegrenzung, Angriffsflächenminimierung und sichere Wiederherstellung tatsächlich umgesetzt?
  6. Testbestand: Decken die vorhandenen Tests neue Missbrauchsfälle ab, oder wiederholen wir nur eine veraltete Kampagne?
  7. Schwachstellenprozess: Können Funde aus internen, externen und KI-gestützten Quellen aufgenommen, verifiziert, priorisiert und behoben werden?
  8. Updates: Lässt sich ein dringender Sicherheitsfix sicher bauen, signieren, verteilen, zurücknehmen und den Nutzern erklären?
  9. Meldung: Wer entscheidet ab dem 11. September 2026, ob eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall vorliegt, und wer bedient die Meldeplattform?
  10. Nachweis: Wo sind Risiko, Entscheidung, Test, Ergebnis und Freigabe so dokumentiert, dass sie später nachvollzogen werden können?

Wer diese Fragen beantwortet, hat noch keine vollständige CRA-Konformität erreicht. Er erkennt jedoch rasch, ob die neue Angriffsdynamik an einer konkreten Stelle des Produkts zu Handlungsbedarf führt. Gerade für KMU ist diese Eingrenzung wichtig. Die Alternative — wahllos neue Sicherheitswerkzeuge einzukaufen — bindet Budget und schafft häufig zusätzliche Systeme, die gepflegt, überwacht und abgesichert werden müssen.

Was Geschäftsleitung, Recht und Entwicklung gemeinsam entscheiden müssen

KI-Cyberrisiken sind keine reine Aufgabe der Entwicklungsabteilung. Entwicklung setzt technische Kontrollen um, kann aber nicht allein festlegen, welches Restrisiko das Unternehmen trägt, welche Produktzusagen gemacht werden oder wie schnell ein Release trotz eines offenen Befunds erfolgen darf. Die Geschäftsleitung legt Ressourcen, Verantwortlichkeiten und Eskalationswege fest; Produktverantwortliche beschreiben Zweckbestimmung, Betriebsumgebung und erwartete Nutzung; Security bewertet Bedrohungen, Tests, Schwachstellen und Vorfälle; Recht und Compliance prüfen regulatorische Kategorien und Meldepflichten; der Support liefert Hinweise aus dem Feld. Ohne diese Verbindung bleibt die Risikobewertung entweder technisch eng oder juristisch abstrakt.

Besonders heikel ist die Freigabeentscheidung bei einem neuen Fund kurz vor dem Release. Die finale Kommissionsleitlinie behandelt ausdrücklich den Fall, dass eine potenziell ausnutzbare Schwachstelle erst in der letzten Entwicklungsphase bekannt wird. Der Hersteller muss anhand der Risikobewertung entscheiden, ob das Produkt sicher in Verkehr gebracht werden kann oder vorab behoben werden muss. Zu berücksichtigen sind Schwere, praktische Ausnutzbarkeit, Auswirkungen und Produktrisiko — aber auch die Folgen einer Verschiebung, etwa wenn die neue Version zugleich andere ausnutzbare Schwachstellen behebt oder für den Weiterbetrieb kritischer Systeme benötigt wird[3].

Das ist keine Einladung, offene Schwachstellen schönzureden, sondern ein Auftrag zu einer dokumentierten, produktbezogenen Entscheidung. Je stärker ein KI-Werkzeug die Zahl der Funde erhöht, desto wichtiger werden einheitliche Bewertungskriterien und klare Freigabekompetenzen.

Unsere Schlussfolgerung: erst die Sicherheitsarchitektur, dann die Automatisierung

KI verschiebt die Risikolage, weil einzelne Angriffsschritte schneller, skalierbarer und leichter kombinierbar werden können. Sie erweitert zugleich die Möglichkeiten der Verteidigung. Beides ist ernst zu nehmen; beides rechtfertigt keine Abkürzung.

Der CRA gibt Herstellern dafür einen brauchbaren Rahmen. Er verlangt eine aktuelle, produktbezogene Risikobewertung, ein angemessenes Sicherheitsniveau, begrenzte Angriffsflächen, geeignete Zugriffs- und Überwachungsmechanismen, regelmässige wirksame Tests, einen belastbaren Schwachstellenprozess und sichere Updates. Diese Pflichten sind technologieneutral. Sie können mit KI unterstützt werden, müssen es aber nicht.

Wer bereits sauber entwickelt, Risiken dokumentiert und Erkenntnisse aus Tests und Betrieb zurück in den Produktprozess führt, beginnt nicht bei null. Wer dagegen auf eine KI-Abwehr hofft, ohne Standardkonfiguration, Updatekette und Schwachstellenmanagement in Ordnung zu bringen, setzt am falschen Ende an.

Die gute Nachricht aus der aktuellen Debatte lautet deshalb nicht, dass KI jedes Sicherheitsproblem lösen werde. Die bessere Nachricht ist nüchterner: Hersteller kennen viele der wirksamen Massnahmen bereits. Der CRA zwingt sie, diese Massnahmen zum überprüfbaren Bestandteil des Produkts und seines Lebenszyklus zu machen.

crAIready verbindet Risiko, Nachweis und Reaktion

crAIready unterstützt Hersteller und andere CRA-Akteure dabei, die CRA-Pflichten in einem durchgängigen Arbeitsprozess abzubilden:

  • Der Onboarding-Wizard: Produkt und voraussichtliche Produktklasse erfassen; die abschliessende rechtliche Einordnung bleibt beim Hersteller.
  • SBOM & Lieferkette: Maschinenlesbare SBOMs per Upload oder über eine angebundene CI-Pipeline übernehmen, Produktversionen zuordnen und Abhängigkeiten produktbezogen verwalten.
  • Schwachstellen & CVD: SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD abgleichen, Funde für die Triage aufbereiten sowie Bewertungen, Massnahmen und Zuständigkeiten nachvollziehbar halten.
  • Meldepflicht & Incident Response: Angaben zu aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen getrennt vorbereiten und die gesetzlichen Fristen im Blick behalten; Prüfung, Freigabe und Einreichung über die einheitliche Meldeplattform bleiben beim verantwortlichen Unternehmen.
  • Dokumentation & Konformität: Risikobewertung, Nachweise und Freigaben versioniert zusammenführen; technische Dokumentation und EU-Konformitätserklärung entstehen als Entwürfe zur fachlichen Prüfung und Freigabe, zentrale Bearbeitungs- und Freigabevorgänge werden protokolliert.

Der Einstieg ist unser kostenloser CRA-Quick-Check. Er unterstützt mit wenigen Fragen eine unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte. Ob ein konkretes Produkt erfasst ist und welche Massnahmen im Einzelfall genügen, muss der Hersteller anhand seines Produkts und seiner Risikobewertung entscheiden. Keine Rechtsberatung im Sinne des RDG.

Methodik dieser Recherche

Ausgangspunkt war der NZZ-Kommentar von Lukas Mäder vom 26. August 2026 zu den Auswirkungen leistungsfähiger KI-Systeme auf Angriff und Verteidigung[1]. Wir haben daraus die journalistische Fragestellung übernommen, nicht aber sämtliche dort genannten Beispiele als Tatsachenbasis dieses Beitrags verwendet.

Die rechtlichen Aussagen wurden unmittelbar gegen die Verordnung (EU) 2024/2847 geprüft, insbesondere Art. 13, Art. 14, Art. 69 und Art. 71 sowie Anhang I Teile I und II[2]. Für die Auslegung regelmässiger Tests, bekannter ausnutzbarer Schwachstellen und der fortlaufenden Risikobewertung wurde die finale, unverbindliche Leitlinie der EU-Kommission C(2026) 5252 vom 27. Juli 2026 ausgewertet[3]; eine verbindliche Auslegung des Unionsrechts bleibt dem Gerichtshof der Europäischen Union vorbehalten. Als technische Orientierung diente das ENISA „Secure by Design and Default Playbook“ (Version 1.0, Juli 2026)[5] — eine unverbindliche Praxishilfe, deren Zuordnung zu Anhang I CRA nach eigener Aussage indikativ ist und keine Konformitätsvermutung begründet.

Die beschriebenen Cyberkampagnen, Evaluationen und Vorfälle geben wir ausschliesslich so wieder, wie Anthropic beziehungsweise OpenAI sie in eigenen Unternehmensveröffentlichungen darstellen[6][7][8] — als Berichte beteiligter Unternehmen, nicht als unabhängige behördliche Feststellungen. Der Praxisfall zum Update-Gateway ist fiktiv.

Dieser Beitrag trennt Rechtsanforderung und technische Umsetzung: Der CRA schreibt keine KI-gestützte Cyberabwehr vor. Aussagen zum sinnvollen Einsatz von KI-Werkzeugen sind praktische Empfehlungen, keine Wiedergabe einer gesetzlichen Pflicht.

Quellen

[1] Lukas Mäder, „Mit KI werden Hackerangriffe gefährlicher. Doch KI kann auch helfen bei der Cyberabwehr. Diese Chance muss man nutzen“, NZZ, Kommentar vom 26.08.2026.

[2] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 13 Abs. 1–9, Art. 14, Art. 69 Abs. 2 und 3, Art. 71 Abs. 2 sowie Anhang I Teil I Nr. 1 und 2 und Teil II Nr. 1–8.

[3] Europäische Kommission, Leitlinie zur Unterstützung der Umsetzung des Cyber Resilience Act, C(2026) 5252 final vom 27.07.2026 — unverbindliche Kommissionsauslegung; insbesondere Abschnitte 7.1 und 7.2 zur Risikobewertung sowie Abschnitt 9.2.2 zu bekannten ausnutzbaren Schwachstellen und Abschnitt 9.2.3 zu wirksamen und regelmässigen Tests und Überprüfungen.

[4] Europäische Kommission, „Commission publishes new guidance to support businesses' implementation of the Cyber Resilience Act“, 27.07.2026 — Mitteilung zur Leitlinie und zur Dringlichkeit der CRA-Umsetzung angesichts neuer Entwicklungen bei Frontier-KI-Modellen mit Cyberfähigkeiten.

[5] ENISA, „Secure by Design and Default Playbook — A Practical Guide to Secure by Design and Default Principles for SMEs“, Version 1.0, Juli 2026 — unverbindliche technische Praxishilfe mit 22 Prinzipien, Nachweisbeispielen und Release-Kriterien; veröffentlicht am 30.07.2026.

[6] Anthropic, „Disrupting the first reported AI-orchestrated cyber espionage campaign“, Unternehmensbericht, November 2025 — Eigendarstellung des Modellanbieters zu einer von ihm erkannten und untersuchten Kampagne.

[7] OpenAI, „Third-party cyber evaluations involving OpenAI models“, Unternehmensmitteilung vom 04.08.2026 — Eigendarstellung zu Cybersecurity-Evaluationen durch externe Partner, bei denen die Modellaktivität über den vorgesehenen Testrahmen hinausging, und zu daraus abgeleiteten Schutzmassnahmen.

[8] OpenAI, „The Hugging Face incident and the road ahead“, Unternehmensmitteilung vom 26.08.2026 — Eigendarstellung zu einem Vorfall, bei dem eigene Modelle in einer Evaluationsumgebung Sicherheitskontrollen umgangen und Drittsysteme erreicht haben sollen, sowie zu Massnahmen für Modellsicherheit, Monitoring und Alignment.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und zu möglichen Auswirkungen KI-gestützter Angriffsmethoden. Er ersetzt keine individuelle Rechtsberatung, Sicherheitsprüfung oder Risikobewertung. Ob der CRA auf ein konkretes Produkt anwendbar ist und welche technischen und organisatorischen Massnahmen angemessen sind, hängt vom Einzelfall ab. Unternehmensberichte zu Cybervorfällen geben die Darstellung der jeweiligen Unternehmen wieder. Veröffentlicht am: 31.08.2026. Zuletzt aktualisiert am: 06.09.2026. Fachlich geprüft am: 05.09.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Weiterführend: Teil 14: Was kostet CRA-Compliance wirklich? — Methodik, Rollen und realistischer Aufwand für die Umsetzung.