Was der Cyber Resilience Act für autonome KI-Agenten bedeutet

← Zurück zum Blog

Der CRA — mehr als ein weiteres EU-Gesetz

Der Cyber Resilience Act (CRA) ist kein gewöhnliches Regulierungspaket aus Brüssel. Es ist die umfassendste Cybersicherheitsverordnung, die die EU je für vernetzte Produkte erlassen hat — und sie trifft den Kern dessen, was wir bei nAIce jeden Tag bauen: Produkte mit digitalen Elementen („Products with Digital Elements“, kurz PDEs).

Der CRA verpflichtet Hersteller, Software und hardwarenahe Produkte über ihren gesamten Lebenszyklus hinweg sicher zu entwickeln, zu betreiben und zu warten. Dazu gehören verpflichtende Schwachstellenmeldungen, Sicherheitsupdates für mindestens fünf Jahre und eine durchgängige Dokumentationspflicht. Wer sich nicht daran hält, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes — je nachdem, was höher ist.

Und ja: Autonome KI-Agenten fallen eindeutig unter den PDE-Begriff. Denn sie sind Software, die selbstständig Entscheidungen trifft, auf externe Systeme zugreift und potenziell sicherheitsrelevanten Code ausführt. Der CRA betrachtet sie nicht als Sonderfall — sondern als reguläres Produkt mit digitalen Elementen, das sämtliche Anforderungen erfüllen muss.

Warum KI-Agenten besonders betroffen sind

Auf den ersten Blick könnte man meinen, der CRA sei ein Gesetz für IoT-Geräte und Netzwerk-Hardware. Doch autonome KI-Agenten wie nAIce sind in mehrfacher Hinsicht stärker betroffen als die meisten anderen PDEs:

SBOM-Pflicht: Jeder KI-Agent muss eine lückenlose Software Bill of Materials (SBOM) vorweisen können — eine maschinenlesbare Liste sämtlicher Abhängigkeiten, Bibliotheken und Komponenten. Bei einem KI-Agenten, der LLM-APIs, Vektor-Datenbanken, Sandbox-Runtimes und dutzende Open-Source-Pakete nutzt, ist das keine triviale Anforderung.

24-Stunden-Meldepflicht: Wird eine aktiv ausgenutzte Schwachstelle entdeckt, muss sie innerhalb von 24 Stunden an die zuständige Behörde (in Deutschland das BSI) gemeldet werden. Für Betreiber autonomer Agenten bedeutet das: Sie brauchen ein rund um die Uhr besetztes Security-Operations-Team — oder einen Anbieter, der das übernimmt.

Support-Verpflichtung über die Lebensdauer: Der CRA schreibt vor, dass sicherheitsrelevante Updates für die gesamte erwartete Nutzungsdauer bereitgestellt werden müssen, mindestens jedoch fünf Jahre. Wer heute einen KI-Agenten in Produktion nimmt, muss sicherstellen, dass er auch 2031 noch gepatcht wird. Ohne einen professionellen Wartungsvertrag ist das für die meisten Unternehmen nicht darstellbar.

Prompt Injection: Der blinde Fleck des CRA

So weitreichend der CRA auch ist: Er wurde geschrieben, bevor Large Language Models und KI-Agenten den Massenmarkt erreichten. Sein Sicherheitsmodell basiert auf klassischer IT-Security — Buffer Overflows, Injection-Schwachstellen in Web-Anwendungen, unsichere Protokolle. Was der CRA nicht adressiert, sind LLM-spezifische Angriffsvektoren wie Prompt Injection.

Prompt Injection ist eine völlig neue Klasse von Sicherheitslücken: Ein Angreifer bettet versteckte Instruktionen in Texte ein, die ein KI-Agent verarbeitet — sei es in einer E-Mail, einer Webseite oder einem PDF. Der Agent interpretiert diese Instruktionen als legitime Befehle und führt sie aus, ohne dass klassische Security-Tools dies erkennen würden.

Der CRA verlangt „angemessene Cybersicherheit“ — aber was bei KI-Agenten „angemessen“ ist, wird sich erst durch die Praxis und erste Gerichtsurteile klären.

Genau hier setzt nAIce an: Unsere Sandbox-Architektur isoliert jede Agenten-Ausführung in einer eigenen, abgeschotteten Umgebung. Selbst wenn ein Prompt-Injection-Angriff erfolgreich wäre, hat der Angreifer keinen Zugriff auf das Host-System, das Netzwerk oder andere Agenten. Wir gehen damit über die CRA-Mindestanforderungen hinaus — weil wir wissen, dass klassische IT-Security bei LLM-basierten Systemen nicht ausreicht.

CRA-Timeline: Was bis wann zu tun ist

Der Cyber Resilience Act wird nicht über Nacht wirksam. Die EU hat eine gestaffelte Übergangsfrist vorgesehen, die Unternehmen Zeit für die Umsetzung gibt. Trotzdem sollten Betreiber von KI-Agenten jetzt handeln — denn die ersten Fristen sind bereits verstrichen:

10. Dezember 2024: Der CRA tritt offiziell in Kraft. Ab diesem Datum beginnt die Übergangsfrist von 36 Monaten für die meisten Verpflichtungen.

11. Dezember 2025: Die EU-Mitgliedstaaten müssen ihre Benannten Stellen (Notified Bodies) eingerichtet haben — die Prüforganisationen, die für die Konformitätsbewertung kritischer Produkte zuständig sind.

11. Juni 2026: Die Notifizierungspflicht für aktiv ausgenutzte Schwachstellen tritt in Kraft. Ab diesem Datum müssen Hersteller Sicherheitslücken innerhalb von 24 Stunden melden. Diese Frist ist jetzt.

11. Dezember 2027: Der CRA wird vollständig durchgesetzt. Ab diesem Datum müssen alle PDEs auf dem EU-Markt sämtliche Anforderungen erfüllen — inklusive SBOM, CE-Kennzeichnung, Konformitätserklärung und dokumentierten Sicherheitsprozessen. Wer bis dahin nicht CRA-ready ist, darf in der EU nicht mehr verkaufen.

So ist nAIce aufgestellt

Wir haben nAIce von der ersten Codezeile an für den CRA konzipiert. Nicht als nachträgliches Compliance-Projekt, sondern als Architekturentscheidung. Denn wir sind überzeugt: Sicherheit, die erst am Ende dazugebaut wird, ist keine Sicherheit.

CRA-ready seit Tag 1: Unsere Entwicklungsprozesse sind auf die Anforderungen des CRA ausgerichtet — von der Bedrohungsmodellierung über die sichere Softwareentwicklung bis zur dokumentierten Schwachstellenbehandlung.

SBOM mit jedem Release: Jede neue Version von nAIce wird mit einer maschinenlesbaren SBOM im standardisierten SPDX-Format ausgeliefert. Kunden können jederzeit nachvollziehen, welche Abhängigkeiten in ihrer Instanz laufen — ein Knopfdruck genügt.

Sandbox-Isolation: Unsere Container-basierte Ausführungsumgebung stellt sicher, dass jeder KI-Agent in einer eigenen, gehärteten Sandbox läuft. Kein direkter Netzwerkzugriff ohne explizite Freigabe, keine persistenten Dateisystem-Zugriffe ohne Audit-Log.

Security-Gates in CI/CD: Jeder Commit durchläuft automatisierte Security-Scans — SAST, Dependency-Checks, Container-Image-Scans — bevor er in Produktion gehen kann. Das ist keine optionale Stufe, sondern ein harter Gate-Mechanismus: Fällt ein Scan durch, stoppt die Pipeline.

Jetzt CRA-ready mit nAIce starten →