blog-thumbnail-ki compliance.png

KI Compliance & Souveränität: 4 Optionen für Unternehmen

blog-detail-page

KI-Tools rechtskonform einsetzen: AVV, Anonymisierung, Self-Hosting und lokale KI. Datenschutz und Souveränität für Unternehmen. Jetzt informieren!

KI-Tools DSGVO-konform nutzen: AVV, Anonymisierung, Self-Hosting und lokale KI. Maximale Datensicherheit und Unabhängigkeit für Unternehmen.

KI-Assistenten wie Claude, ChatGPT oder Gemini sind in vielen Unternehmen längst Alltag. Sie fassen Dokumente zusammen, beantworten Kundenanfragen und schreiben Code. Was dabei oft übersehen wird: Mit jedem Prompt verlassen potenziell sensible oder personenbezogene Daten das Unternehmen. Wer das ohne vertragliche und technische Absicherung tut, verstößt in der Regel gegen die DSGVO oder gibt schützenswerte Firmendaten an Dritte weiter. Gleichzeitig hat der Juni 2026 gezeigt, dass Compliance nur die halbe Frage ist. Die andere Hälfte heißt Souveränität. Wie abhängig darf ein Unternehmen von einem einzelnen Anbieter sein, auf dessen Verfügbarkeit es keinen Einfluss hat? Dieser Artikel zeigt vier Wege, KI-Tools rechtskonform einzusetzen, und ordnet ein, wie viel Unabhängigkeit jeder Weg tatsächlich bringt.

Der Juni 2026 als Weckruf

Am 12. Juni 2026 wies das US-Handelsministerium Anthropic per Exportkontroll-Direktive an, den Zugang zu seinen leistungsfähigsten Modellen Claude Fable 5 und Mythos 5 für alle Nicht-US-Bürger zu sperren. Weil Anthropic die Staatsangehörigkeit seiner Nutzer technisch nicht prüfen konnte, schaltete das Unternehmen beide Modelle kurzerhand weltweit ab. Auch für US-Kunden. 19 Tage später wurde die Anordnung aufgehoben, seit 1. Juli ist Fable 5 wieder global verfügbar. Der Vorfall ist überstanden, aber die Lektion bleibt. Eine einzelne Direktive einer ausländischen Regierung kann ein Werkzeug, das tief in Geschäftsprozessen steckt, über Nacht abschalten. Die EU-Kommission nahm den Fall zum Anlass, ihre wenige Tage zuvor vorgestellten Pläne zur technologischen Souveränität zu bekräftigen. Wer heute eine KI-Strategie plant, sollte beide Dimensionen mitdenken: Datenschutz und Verfügbarkeit.

Das Problem beginnt beim Consumer-Account

Der häufigste Compliance-Verstoß in der Praxis ist unspektakulär. Mitarbeitende nutzen private oder Pro-Accounts von ChatGPT oder Claude für Firmendaten. Consumer-Pläne sind dafür nicht gemacht. Es gibt keinen Auftragsverarbeitungsvertrag, und die Anbieter nutzen Eingaben standardmäßig für das Training ihrer Modelle. Anthropic hat im August 2025 genau diesen Schritt vollzogen: Chats von Free-, Pro- und Max-Nutzern fließen seither ins Training ein, sofern nicht aktiv widersprochen wird. Bei Zustimmung mit einer Aufbewahrungsfrist von fünf Jahren. OpenAI handhabt es bei Free und Plus ähnlich. Seit Juli 2026 kommt ein weiterer Punkt dazu. Anthropic hat seine Consumer-Datenschutzrichtlinie um die Kategorie „Verification Data" erweitert, das heißt, das Unternehmen kann anlassbezogen eine Alters- oder Identitätsprüfung verlangen, inklusive Ausweisfoto und Gesichtsaufnahme. Eine gesetzliche Pflicht zur Gesichtserkennung existiert nicht, und Business-, Enterprise- und API-Kunden sind ausgenommen. Die Richtung ist trotzdem bemerkenswert, denn der Zugang zu Consumer-KI wird zunehmend an Identität geknüpft. Biometrische Daten sind nach Art. 9 DSGVO eine besondere Kategorie und die Verarbeitung dieser Daten für die geplante Identitätsprüfung läuft über US-Dienstleister. Für Unternehmen heißt das: Die private Nutzung von KI-Accounts mit Firmendaten gehört per interner Richtlinie unterbunden. Alles Weitere ist eine Frage des richtigen Setups.

Der rechtliche Rahmen: DSGVO und AI Act

Zwei Regelwerke greifen parallel. Die DSGVO gilt für jede Verarbeitung personenbezogener Daten, unabhängig davon, ob eine KI beteiligt ist. Die österreichische Datenschutzbehörde stellt in ihren FAQ klar, dass wer ein fremdes KI-System einsetzt, selbst Verantwortlicher ist und muss prüfen, ob Daten an den Hersteller abfließen. Der AI Act ergänzt das um KI-spezifische Pflichten. Für Unternehmen, die KI-Tools lediglich nutzen, sind vor allem zwei Punkte relevant. Seit Februar 2025 gilt die KI-Kompetenzpflicht und Mitarbeitende, die mit KI arbeiten, müssen ausreichend geschult sein. Ab 2. August 2026 greifen die Transparenzpflichten des Art. 50. Ab dann müssen KI-generierte Inhalte wie Deepfakes und öffentliche Texte gekennzeichnet werden. Die strengen Hochrisiko-Pflichten wurden mit dem Ende Juni 2026 beschlossenen Digital Omnibus auf Ende 2027 bzw. 2028 verschoben. Dass die Behörden das Thema ernst nehmen, zeigen die laufenden Verfahren. Die italienische Datenschutzbehörde verhängte gegen OpenAI 15 Millionen Euro Bußgeld, wobei das Urteil im März 2026 zwar aus Zuständigkeitsgründen aufgehoben wurde. Das Verfahren liegt nun bei der irischen Behörde. Der Chatbot-Anbieter hinter Replika zahlte 5 Millionen Euro, gegen X/Grok laufen gleich zwei Untersuchungen. Die Stoßrichtung ist klar: Rechtsgrundlagen, Transparenz und Trainingsdaten stehen im Fokus. In Österreich informiert die KI-Servicestelle der RTR, die WKO stellt KMU-Guidelines samt Mustern für interne KI-Richtlinien bereit. Eine eigene Marktüberwachungsbehörde für den AI-Act hat Österreich übrigens noch nicht benannt, die Frist dafür ist seit August 2025 verstrichen.

Vier Optionen zu datenschutzkonformer und souveräner künstlicher Intelligenz

fact_check_FILL0_wght400_GRAD200_opsz48.svg

person_search_FILL0_wght400_GRAD200_opsz48.svg

home_FILL0_wght400_GRAD200_opsz48.svg

desktop_mac_FILL0_wght400_GRAD200_opsz48.svg

Für den datenschutzkonformen Einsatz von KI gibt es nicht den einen richtigen Weg, sondern vier – von der vertraglichen Absicherung beim Anbieter über Anonymisierung und selbst betriebene Modelle bis zur vollständig lokalen Verarbeitung, jeweils mit steigendem Aufwand und steigender Souveränität.

Option 1: Auftragsverarbeitung mit dem KI-Anbieter

Der direkteste Weg zur DSGVO-Konformität führt über die Business- und API-Angebote der Anbieter. Claude Team und Enterprise, ChatGPT Business und Enterprise sowie die APIs von Anthropic, OpenAI, Google und Mistral beinhalten einen Auftragsverarbeitungsvertrag (AVV) mit Standardvertragsklauseln. Kundendaten werden standardmäßig nicht für das Training verwendet. Für API-Kunden gibt es darüber hinaus Zero-Data-Retention-Optionen, bei denen Eingaben gar nicht erst gespeichert werden. Auch bei der Datenresidenz hat sich viel getan. OpenAI bietet seit Februar 2025 EU-Datenresidenz für API und Enterprise-Workspaces. Microsoft verarbeitet Prompts in der „EU Data Zone" ausschließlich innerhalb der EU. Claude-Modelle laufen über AWS Bedrock in Frankfurt oder Google Vertex AI in EU-Regionen. Bei direkter Nutzung über Anthropic werden Daten dagegen weiterhin in den USA gespeichert. Der französische Anbieter Mistral hostet standardmäßig in der EU. Worauf es beim Vertrag konkret ankommt: Ausschluss des Trainings mit Kundendaten, klare Speicherfristen, EU-Datenresidenz für Verarbeitung und Speicherung, eine nachvollziehbare Liste der Subunternehmer und geregelte Löschprozesse. Diese Punkte lassen sich bei allen großen Anbietern prüfen, bevor ein einziger Prompt gesendet wird. Das klingt nach einem gelösten Problem aber Einschränkungen, wie der US CLOUD Act bleiben. US-Behörden können von US-Unternehmen die Herausgabe von Daten verlangen, unabhängig davon, wo diese gespeichert sind. Eine EU-Region eines US-Hyperscalers schützt davor nicht. Für die meisten Unternehmen ist Option 1 trotzdem der pragmatische Einstieg. Geringer Aufwand, Zugang zu den besten Modellen, solide Vertragslage. Die Abhängigkeit von US-Anbietern und US-Politik bleibt bestehen.

Option 2: Anonymisierung und Pseudonymisierung

Der zweite Ansatz setzt vor der Übermittlung an. Personenbezogene oder andere schützenswerte Daten werden entfernt oder ersetzt, bevor ein Prompt den Anbieter erreicht. Technisch übernehmen das KI-Gateways. Das sind Systeme, die zwischen Nutzer und KI-Anbieter sitzen und unter anderem Namen, Adressen oder Kundennummern automatisch erkennen und maskieren. Rechtlich ist Präzision gefragt. Anonyme Daten fallen nicht unter die DSGVO, aber echte Anonymisierung ist schwer zu erreichen. Werden Namen nur durch Platzhalter ersetzt, liegt Pseudonymisierung vor, und pseudonymisierte Daten bleiben personenbezogen. Der EuGH hat im September 2025 immerhin klargestellt, dass dieselben Daten für einen Empfänger ohne Zuordnungsmöglichkeit nicht personenbezogen sein können. Das stärkt die Gateway-Architekturen, entbindet das übermittelnde Unternehmen aber nicht von seinen Pflichten. Die praktische Grenze liegt im Freitext. Ein Erkennungssystem findet Namen und Telefonnummern zuverlässig. Dass „der Geschäftsführer unseres Betriebs in Wien" auch ohne Namen identifizierbar ist, erkennt es nicht. Und ein Punkt wird gerne übersehen: Die Anonymisierung selbst muss lokal oder auf eigener Infrastruktur laufen. Wer ein Cloud-LLM bittet, Daten zu anonymisieren, hat sie bereits übermittelt. MCP Server sind ein klares Beispiel, bei dem es funktioniert. Beim MCP geht es unter anderem darum, strukturierte Daten für ein LLM zugänglich zu machen. Es kann also genau entschieden werden, welche Daten über den MCP an ein LLM weitergegeben und welche zuvor anonymisiert, pseudonymisiert oder gänzlich herausgefiltert werden. Auch die Aufsichtsbehörden arbeiten noch an der Präzisierung: Der europäische Datenschutzausschuss hat eigene Anonymisierungs-Guidelines für Sommer 2026 angekündigt. Wer heute auf diesen Ansatz setzt, sollte die Entwicklung beobachten. Anonymisierung ist damit eine sinnvolle, zusätzliche Schutzschicht. Als alleinige Compliance-Strategie ist sie aber nur für strukturierte und gut kontrollierbare Daten geeignet.

Option 3: Self-Hosted KI

Wer Daten gar nicht erst an Dritte geben will, betreibt die Modelle selbst. Möglich machen das Open-Weight-Modelle, deren Gewichte frei verfügbar sind. Das Angebot ist 2026 so gut wie nie. Mistral 3 unter Apache-2.0-Lizenz, OpenAIs gpt-oss-Modelle, Qwen oder Llama 3.3. Der Qualitätsabstand großer Open-Weight-Modelle zu den Frontier-Modellen liegt bei geschätzt drei bis sechs Monaten. Für die meisten Geschäftsanwendungen mehr als ausreichend. Ein Detail am Rande zeigt, wie schnell die Lizenzpolitik zur Souveränitätsfrage wird. Metas multimodale Llama-4-Modelle schließen EU-Unternehmen per Lizenz explizit aus. Europäische und offene Alternativen sind hier die verlässlichere Basis. Self-Hosting heißt nicht zwingend eigener Serverraum. Europäische Cloud-Anbieter wie IONOS, StackIT, OVHcloud oder T-Systems bieten Open-Weight-Modelle als Managed Service in deutschen und europäischen Rechenzentren. DSGVO-konform, ohne Training mit Kundendaten und außerhalb der Reichweite des US CLOUD Act. Wer maximale Kontrolle braucht, betreibt Modelle auf eigener Hardware, eine einzelne 80-GB-GPU reicht bereits für ein Modell der 120-Milliarden-Parameter-Klasse. Der Preis ist Aufwand. Betrieb, Skalierung und Modell-Updates brauchen Know-how, eine dedizierte High-End-GPU in der Cloud kostet im Dauerbetrieb schnell mehrere tausend Euro pro Monat und rechnet sich erst bei konstanter Auslastung. Managed Services mit Abrechnung pro Token senken diese Einstiegshürde erheblich. Sie kombinieren europäisches Hosting mit dem Kostenmodell der großen API-Anbieter. Dafür bekommt das Unternehmen etwas, das keine der anderen Optionen bietet, vollständige Datenhoheit und Unabhängigkeit von den Entscheidungen einzelner Anbieter und Regierungen.

Option 4: Lokale KI

Die konsequenteste Variante läuft direkt auf dem Endgerät. Werkzeuge wie Ollama oder LM Studio installieren Open-Weight-Modelle auf Laptop oder Workstation, so verlassen die Daten das Gerät nie. Die Hardware-Hürde fällt bereits, OpenAIs gpt-oss-20b läuft auf jedem besseren Business-Laptop mit 16 GB Speicher, auf Apple-Geräten mit viel Unified Memory laufen auch deutlich größere Modelle. Für Zusammenfassungen, Klassifikation, Textextraktion oder die Suche in Firmendokumenten liefern lokale Modelle heute Ergebnisse, die sich kaum von der Cloud unterscheiden. Bei komplexen, mehrstufigen Aufgaben, anspruchsvollem Code oder juristischer Analyse bleiben die Frontier-Modelle klar vorn. Interessant ist lokale KI vor allem in zwei Szenarien. Für hochsensible Daten, die das Haus unter keinen Umständen verlassen dürfen, wie etwa in Kanzleien, Arztpraxen oder der Personalabteilung. Oder als Vorverarbeitungsstufe, die Daten lokal anonymisiert und filtert, bevor ein Cloud-Modell ins Spiel kommt. Genau diese Kombination löst das Anonymisierungs-Paradoxon aus Option 2.

01b_ki-optionen-uebersicht-kompakt_raleway.png

01c_ki-optionen-kompakt-mobil.png

Mehr als das Modell: der Client entscheidet mit

Bei Self-Hosted und lokaler KI wird ein Punkt regelmäßig unterschätzt. Die Qualität der Ergebnisse hängt nicht nur vom Modell ab, sondern auch vom Client, der es bedient, ab. Kommerzielle KI-Clients wie Claude oder ChatGPT sind längst mehr als Chatfenster. Sie recherchieren live im Web, führen Code aus, analysieren Tabellen, erstellen Visualisierungen und Dokumente, binden über Schnittstellen Firmensysteme an und arbeiten Aufgaben in mehreren Schritten selbstständig ab. Ein erheblicher Teil der Antwortqualität entsteht genau dort. Ein schwächeres Modell, ergänzt mit Websuche und Werkzeugzugriff, schlägt bei vielen Aufgaben ein stärkeres Modell ohne beides. Wer selbst hostet, muss diese Ebene mitdenken. Open-Source-Clients wie Open WebUI oder LibreChat decken Chat, Dokumenten-Upload und Websuche ab, an die Agenten-Fähigkeiten und den Funktionsumfang der kommerziellen Clients reichen sie aber nicht heran. Der faire Vergleich lautet deshalb nicht „Open-Weight-Modell gegen Frontier-Modell", sondern „selbst betriebener Gesamt-Stack gegen integriertes Produkt". Für fokussierte Anwendungsfälle ist der eigene Stack schnell gut genug. Als universeller Assistent für alle Mitarbeitenden ist das integrierte Produkt meist deutlich voraus.

US-Anbieter oder EU-Anbieter?

Die vier Optionen unterscheiden sich nicht nur im Datenschutzniveau, sondern auch darin, wessen Entscheidungen ein Unternehmen ausgesetzt bleibt. Bei US-Anbietern (auch mit AVV und EU-Datenresidenz) bleiben strukturelle Abhängigkeiten wie der CLOUD Act und die Möglichkeit politischer Eingriffe, wie sie der Fable-Vorfall demonstriert hat. Das ist kein Grund zur Panik, aber ein Risiko, das in keiner Risikobewertung fehlen sollte. Die europäische Alternative ist 2026 näher gerückt. Mistral liefert konkurrenzfähige Modelle und baut mit eigener Rechenzentrumsinfrastruktur souveräne KI-Kapazität in Europa auf. IONOS, StackIT, OVHcloud und T-Systems betreiben Open-Weight-Modelle in europäischen Rechenzentren unter europäischem Recht. Ein vollständiger EU-Stack, mit Modell, Infrastruktur, Vertragspartner, ist damit mit wenigen Kompromissen möglich. Realistisch ist für die meisten Unternehmen keine Entweder-oder-Entscheidung, sondern eine bewusste Portfolio-Entscheidung. US-Frontier-Modelle dort, wo die maximale Fähigkeit zählt und die Datenlage es erlaubt. Europäische oder selbst betriebene Alternativen dort, wo sensible Daten verarbeitet werden oder Abhängigkeit zum Risiko wird.

Welche Option passt zu wem?

Ein AVV mit dem Anbieter (Option 1) ist der richtige Start für Unternehmen, die schnell und mit geringem Aufwand rechtskonform arbeiten wollen und mit der US-Abhängigkeit leben können. Anonymisierung (Option 2) ergänzt das sinnvoll überall dort, wo personenbezogene Daten in Prompts nichts verloren haben oder mittels MCP strukturierte Daten abgerufen werden. Self-Hosting in der EU-Cloud (Option 3) passt, wenn sensible Daten im Spiel sind oder Souveränität strategisch zählt. Lokale KI (Option 4) eignet sich für klar umrissene Aufgaben mit hochsensiblen Daten und als Baustein in hybriden Architekturen. In der Praxis setzt sich genau dieses hybride Muster durch. Standardaufgaben laufen auf lokalen oder selbst gehosteten Modellen, für anspruchsvolle Fälle wird gezielt ein Frontier-Modell mit sauberer Vertragsgrundlage angebunden.

Fazit

DSGVO-konforme KI-Nutzung ist 2026 kein Hindernis mehr, sondern eine Auswahlentscheidung. Business-Verträge mit AVV, EU-Datenresidenz, ausgereifte Open-Weight-Modelle und europäische Anbieter decken praktisch jedes Anforderungsprofil ab. Nicht mehr zeitgemäß ist es, Firmendaten in Consumer-Accounts zu verwenden oder die Verfügbarkeit und Abhängigkeit in der KI-Strategie auszublenden. Wer Compliance und Souveränität zusammen denkt, ist für beides gerüstet.

Bereit, Neues ZU BEWEGEN?

CTA_Overlap_blau.png

Lassen Sie uns zusammen Großes erreichen! Füllen Sie einfach unser Kontaktformular aus und starten Sie noch heute Ihr neues Projekt. Wir freuen uns darauf, von Ihnen zu hören und gemeinsam erfolgreich zu sein!

Weitere interessante ARTIKEL

Wir verstehen das GROSSE GANZE

OVL_Planetensystem 2026.png

Mit uns holen Sie sich das Gesamtpaket: Spezialisierte Expert:innen aus Digital Marketing, Consulting, Web Development und AI Automation arbeiten gemeinsam an Ihrem Projekt, um Ihre digitalen Ziele zu erreichen.

blog-thumbnail-cra-anforderungen.png

Anforderungen des Cyber Resilience Act im Detail

Cyber Resilience Act erklärt: Anforderungen für Hersteller – Risikoklassifizierung, Schwachstellenmanagement, CE-Kennzeichnung. Jetzt informieren!

Der Cyber Resilience Act stellt klare Anforderungen an Hersteller digitaler Produkte. Erfahren Sie alles zu Risikoklassen, Schwachstellenmanagement und CE-Kennzeichnung.

CRA Anforderungen: Security by Design & CE-Kennzeichnung

Der Cyber Resilience Act (CRA), offiziell die Verordnung (EU) 2024/2847, ist seit dem 10. Dezember 2024 in Kraft und gilt vollumfänglich ab dem 11. Dezember 2027 verbindlich für alle Produkte mit digitalen Elementen auf dem EU-Markt. Was das konkret bedeutet und welche Anforderungen auf Sie als Hersteller zukommen, erklären wir in diesem Beitrag Schritt für Schritt. Sie möchten zunächst genauer verstehen, was der CRA überhaupt ist? Dann lesen Sie zuerst unseren Grundlagenartikel zum Cyber Resilience Act.

Risikoklassifizierung: Welche Kategorie trifft Ihr Produkt?

Der CRA unterscheidet Produkte nach ihrem Risikopotenzial in vier Klassen. Die Einordnung ist entscheidend: Sie bestimmt, wie aufwändig der Weg zur CE-Kennzeichnung wird.

Standardprodukte

Die große Mehrheit aller vernetzten Produkte fällt in diese Kategorie. Wer hier landet, kann das Konformitätsbewertungsverfahren selbst durchführen. Das bedeutet: Es ist keine externe Prüfstelle erforderlich, aber alle grundlegenden Sicherheitsanforderungen aus Anhang I des CRA müssen dennoch vollständig erfüllt werden. Beispiele: Vernetzte Haushaltsgeräte, einfache IoT-Sensoren, Software ohne sicherheitskritische Funktionen

Wichtige Produkte – Klasse I (Anhang III)

Klasse-I-Produkte haben ein erhöhtes Risikopotenzial, weil ihre Kompromittierung weitreichende Folgen haben kann. Hier sind die Anforderungen strenger. Hersteller können die Konformität selbst bewerten, aber nur dann, wenn sie harmonisierte europäische Normen vollständig anwenden. Liegen keine solchen Normen vor oder werden sie nicht angewendet, ist eine benannte Stelle einzubeziehen. Typische Produkte der Klasse I: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Identitätsmanagementsysteme und Zugangskontrollgeräte</li><li value="2" class="editor-listitem">Passwortmanager</li><li value="3" class="editor-listitem">Browser (eigenständig und eingebettet)</li><li value="4" class="editor-listitem">VPN-Produkte und Fernzugriffssoftware</li><li value="5" class="editor-listitem">Netz- und Konfigurationsmanagementsysteme</li><li value="6" class="editor-listitem">Software für Updates und Patch-Management</li><li value="7" class="editor-listitem">Smart-Home-Produkte mit Sicherheitsfunktionen (z. B. vernetzte Türschlösser, Kameras)</li><li value="8" class="editor-listitem">Betriebssysteme für allgemeine Nutzung</li></ul>

Wichtige Produkte – Klasse II (Anhang III)

Produkte der Klasse II gelten als besonders sicherheitssensibel. Sie betreffen oft kritische Infrastrukturen oder spielen eine zentrale Rolle in der IT-Sicherheit. Hier ist eine externe Konformitätsbewertung durch eine benannte Stelle verpflichtend. Eine Selbstbewertung ist nicht ausreichend. Typische Produkte der Klasse II: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Hypervisoren und Container-Runtime-Systeme</li><li value="2" class="editor-listitem">Firewalls und Intrusion-Detection-Systeme</li><li value="3" class="editor-listitem">Manipulationssichere Mikroprozessoren und Mikrocontroller</li></ul>

Kritische Produkte (Anhang IV)

Für diese Kategorie – darunter beispielsweise Hardwaregeräte mit Sicherheitsboxen, Chipkarten für qualifizierte elektronische Signaturen oder Smart-Meter-Gateways – gelten im CRA die strengsten Anforderungen. Aktuell noch offen: Neben der Prüfung durch benannte Stellen kann für diese Produkte eine europäische Cybersicherheitszertifizierung verpflichtend vorgeschrieben werden.

Jetzt checken, in welche Kategorie Ihr Produkt fällt!

Übersicht: Anforderungen nach Risikoklasse

Grundlegende Sicherheitsanforderungen (Anhang I)

Egal, welcher Risikoklasse Ihr Produkt oder Ihre Software angehört, diese grundlegenden Sicherheitsanforderungen des CRA müssen in jedem Fall erfüllt werden.

1. Security by Design & Security by Default

Das Kernprinzip des CRA ist, Cybersicherheit nicht nachträglich aufzusetzen, sondern es von Anfang an als Teil des Entwicklungsprozesses zu integrieren. Und das über den gesamten Lebenszyklus eines Produkts hinweg: Von der Planung über die Entwicklung und Herstellung bis hin zu Lieferung, Wartung und Außerbetriebnahme.

Security by Design

Was das konkret bedeutet: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Risikobewertung in der Entwicklung: Bereits in der Planungs- und Konzeptionsphase müssen Cybersicherheitsrisiken systematisch identifiziert und bewertet werden. Die Ergebnisse dieser Bewertung müssen in alle weiteren Phasen einfließen und wenn nötig bei Änderungen am Produkt angepasst und neu bewertet werden.</li><li value="2" class="editor-listitem">Minimale Angriffsfläche: Das Produkt soll nur die Funktionen bereitstellen, die tatsächlich benötigt werden. Nicht benötigte Schnittstellen, Dienste oder Funktionen sind zu deaktivieren oder gar nicht erst zu integrieren.</li><li value="3" class="editor-listitem">Datenschutz und Verschlüsselung: Gespeicherte und übertragene Daten müssen angemessen geschützt werden. In der Regel durch Verschlüsselung nach aktuellem Stand der Technik.</li><li value="4" class="editor-listitem">Integrität und Authentizität: Mechanismen zur Überprüfung der Softwareintegrität und zur Authentifizierung von Nutzern und Komponenten müssen eingebaut sein.</li><li value="5" class="editor-listitem">Software Bill of Materials (SBOM): Anforderung des CRA ist die Erstellung einer SBOM. Sie listet alle verwendeten Bibliotheken und Komponenten auf und ist Grundlage für ein effektives Schwachstellenmanagement.</li></ul>

Security by Default

Produkte müssen so ausgeliefert werden, dass Nutzer ohne zusätzliche Konfiguration bereits sicher unterwegs sind: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Keine schwachen Standardpasswörter: Voreingestellte Passwörter müssen stark sein oder beim ersten Login geändert werden müssen.</li><li value="2" class="editor-listitem">Automatische Sicherheitsupdates: Wo technisch möglich und sinnvoll, sollten Updates standardmäßig automatisch eingespielt werden.</li><li value="3" class="editor-listitem">Minimale Datenerhebung: Nur die für den Betrieb tatsächlich notwendigen Daten dürfen in der Standardkonfiguration erhoben werden.</li></ul>

2. Schwachstellenmanagement und Meldepflichten

Ein zentrales Element des CRA ist das aktive und kontinuierliche Schwachstellenmanagement über die gesamte Produktlebensdauer hinweg. Folgende Aspekte müssen im Prozess des Schwachstellenmanagements enthalten sein: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Identifikation und Dokumentation: Hersteller müssen aktiv nach Schwachstellen suchen und diese systematisch dokumentieren.</li><li value="2" class="editor-listitem">Koordinierte Offenlegung: Es muss eine Strategie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) vorliegen. Eine zentrale Kontaktstelle für Schwachstellenmeldungen muss benannt und öffentlich zugänglich sein.</li><li value="3" class="editor-listitem">Komponenten-Weitermeldung: Wird eine Schwachstelle in einer integrierten Komponente (z. B. einer Open-Source-Bibliothek) festgestellt, muss diese an die verantwortliche Person oder Organisation gemeldet werden.</li><li value="4" class="editor-listitem">Kostenlose Sicherheitsupdates: Patches und Updates zur Behebung von Schwachstellen müssen rechtzeitig und ohne zusätzliche Kosten für die Nutzer bereitgestellt werden.</li></ul> Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten klar definierte Meldefristen:

Wichtig: Die Meldepflichten für Schwachstellen und Sicherheitsvorfälle gelten bereits seit dem 11. September 2026. Also über ein Jahr vor der vollständigen Anwendbarkeit des CRA im Dezember 2027. Detaillierte Infos zu den geltenden Fristen finden Sie in unserem Beitrag zu <a href="/blog/fristen-cra" rel="noreferrer" data-page-ref="6a2fbf4007dcc4d451c2571d" class="editor-link">Fristen des CRA</a>.

3. Dokumentations- und Berichtspflichten

Transparenz ist ein tragendes Prinzip des CRA. Sowohl gegenüber Behörden als auch gegenüber Nutzern bestehen umfangreiche Informationspflichten.

Technische Dokumentation (Anhang VII)

Die technische Dokumentation muss vor dem Inverkehrbringen erstellt und über den gesamten Supportzeitraum aktuell gehalten werden. Sie enthält unter anderem: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Beschreibung der Systemarchitektur und der Sicherheitsfunktionen</li><li value="2" class="editor-listitem">Ergebnisse der Risikobewertung und der Sicherheitsanalysen</li><li value="3" class="editor-listitem">Festgelegte Verfahren zur Erkennung und Behebung von Schwachstellen</li><li value="4" class="editor-listitem">Angaben zur SBOM (Software Bill of Materials)</li><li value="5" class="editor-listitem">Dokumentation von Entwicklungs- und Build-Prozessen</li><li value="6" class="editor-listitem">Kontaktadresse für Schwachstellenmeldungen</li></ul>

Nutzerinformationen (Anhang II)

Nutzer müssen klar und verständlich informiert werden über: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Sicherheitsmerkmale des Produkts und deren Funktionsweise</li><li value="2" class="editor-listitem">Anleitung zur sicheren Installation, Konfiguration und Nutzung</li><li value="3" class="editor-listitem">Hinweise auf bekannte Risiken und empfohlene Sicherheitseinstellungen</li><li value="4" class="editor-listitem">Erwartete Produktlebensdauer und Dauer des Sicherheits-Supports</li><li value="5" class="editor-listitem">Kontaktmöglichkeit zur Meldung von Schwachstellen</li><li value="6" class="editor-listitem">Informationen über verfügbare Updates und wie sie eingespielt werden</li></ul>

EU-Konformitätserklärung (Anhang V / VI)

Die EU-Konformitätserklärung ist das formelle Dokument, mit dem der Hersteller bestätigt, dass sein Produkt die Anforderungen des CRA erfüllt. Sie muss in der Sprache jedes Mitgliedstaats verfasst sein, in dem das Produkt vermarktet wird, und kann entweder dem Produkt beigelegt oder über eine Internetadresse zugänglich gemacht werden.

4. CE-Kennzeichnung und Konformitätsbewertung

Ohne CE-Kennzeichnung darf kein Produkt mit digitalen Elementen ab dem 11. Dezember 2027 auf dem EU-Markt in Verkehr gebracht werden. Der Weg dorthin hängt von der Produktklasse ab. Der Ablauf im Überblick: <ol class="editor-list-ol"><li value="1" class="editor-listitem">Produktklasse bestimmen: In welche Risikoklasse fällt das Produkt?</li><li value="2" class="editor-listitem">Risikobewertung durchführen: Für alle Klassen verpflichtend.</li><li value="3" class="editor-listitem">Sicherheitsanforderungen umsetzen: Alle grundlegenden Anforderungen aus Anhang I erfüllen.</li><li value="4" class="editor-listitem">Konformitätsbewertungsverfahren durchlaufen: Je nach Klasse selbst oder mit benannter Stelle.</li><li value="5" class="editor-listitem">Technische Dokumentation erstellen: Vollständig und aktuell.</li><li value="6" class="editor-listitem">EU-Konformitätserklärung ausstellen.</li><li value="7" class="editor-listitem">CE-Kennzeichnung anbringen: Gut sichtbar, leserlich und dauerhaft. Am Produkt selbst, auf der Verpackung oder (bei Software) in der Benutzeroberfläche oder Dokumentation.</li></ol>

Pflichten des CRA entlang der Lieferkette

Der CRA richtet sich nicht nur an Hersteller, auch Importeure und Händler tragen Verantwortung. <ul class="editor-list-ul"><li value="1" class="editor-listitem">Hersteller tragen die Hauptverantwortung: Sie müssen Konformität sicherstellen, Schwachstellen managen, Nutzer informieren und Meldepflichten einhalten. Dazu gehört auch die Prüfpflicht für zugekaufte Komponenten. Drittanbieter-Software oder -Hardware, die ins Produkt einfließt, muss ebenfalls den Anforderungen entsprechen.</li><li value="2" class="editor-listitem">Importeure dürfen ausschließlich konforme Produkte in die EU einführen. Sie müssen sicherstellen, dass der Hersteller die Anforderungen des CRA erfüllt hat, und ihre eigenen Kontaktdaten am Produkt oder der Verpackung angeben.</li><li value="3" class="editor-listitem">Händler haben eine Sorgfaltspflicht: Sie dürfen nur Produkte anbieten, die ordnungsgemäß gekennzeichnet sind und den CRA-Anforderungen entsprechen. Bei Verdacht auf Nicht-Konformität müssen sie Maßnahmen ergreifen oder das Produkt vom Markt nehmen.</li></ul>

Weitere interessante Artikel

CRA Anforderungen: Security by Design & Zertifizierung

blog-thumbnail-cra-fristen.png

Cyber Resilience Act: Alle Fristen im Überblick

Cyber Resilience Act Fristen erklärt. Erfahren Sie wann der CRA in Kraft tritt und welche Deadlines Unternehmen beachten müssen. Jetzt informieren!

Der Cyber Resilience Act ist in Kraft. Erfahren Sie alle kritischen Fristen, Übergangsregelungen und Konsequenzen bei Versäumnis für Ihr Unternehmen.

Cyber Resilience Act: Alle wichtigen Fristen & Deadlines

Der Cyber Resilience Act kurz erklärt

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen einführt: von vernetzten Haushaltsgeräten über IoT-Devices bis hin zu Software. Betroffen sind Hersteller, Importeure und Händler, unabhängig von der Unternehmensgröße. Als EU-Verordnung gilt der CRA direkt in allen Mitgliedstaaten, also auch in Österreich, ohne zusätzliches nationales Umsetzungsgesetz.Du möchtest zunächst genauer verstehen, was der CRA überhaupt ist? Dann lies zuerst unseren <a href="/blog/cra-grundlagen" rel="noreferrer" data-page-ref="6a2fc54783f0485f31db41bb" class="editor-link">Grundlagenartikel zum Cyber Resilience Act</a>.

Die Fristen des CRA auf einen Blick

Der CRA ist keine “Alles-auf-einmal”-Verordnung. Verschiedene Regelungen greifen zu unterschiedlichen Zeitpunkten. Hier finden Sie eine übersichtliche Timeline des Cyber Resilience Acts:

10. Dezember 2024 – Der CRA ist in Kraft getreten

Der CRA ist bereits Realität. Auch wenn viele Hauptpflichten erst 2027 greifen, beginnt die Vorbereitungszeit jetzt. Entwicklungszyklen, Zertifizierungsverfahren und interne Prozessanpassungen brauchen Zeit. Wer jetzt noch wartet, könnte es 2027 schwer haben.

11. Juni 2026 – Benannte Stellen (Kapitel IV)

Ab diesem Datum können Konformitätsbewertungsstellen offiziell notifiziert werden. Das ist vor allem für Hersteller von wichtigen (Klasse II) und kritischen Produkten relevant, die eine externe Konformitätsbewertung benötigen. Wer auf eine Zertifizierung durch eine benannte Stelle angewiesen ist, sollte frühzeitig klären, welche Stellen dafür in Frage kommen, denn Kapazitäten könnten schnell knapp werden.

11. September 2026 – Meldepflicht für Schwachstellen (Artikel 14)

Das ist eine der kritischsten Fristen, die viele unterschätzen: Ab September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei der zuständigen Behörde gemeldet werden. Besonders wichtig: Diese Meldepflicht gilt nicht nur für neue Produkte, sondern für alle Produkte mit digitalen Elementen, die auf dem EU-Markt verfügbar sind. Also auch für jene, die bereits vor 2027 in Verkehr gebracht wurden.Dabei gelten strenge Meldefristen, die eingehalten werden müssen:

crisis_alert_FILL0_wght400_GRAD200_opsz48.svg

Frühwarnung bei aktiv ausgenutzten Schwachstellen oder schwerwiegenden Vorfällen

mail_FILL0_wght400_GRAD200_opsz48.svg

Detaillierte Schwachstellenmeldung mit ersten Bewertungen und Maßnahmen

forward_to_inbox_FILL0_wght400_GRAD200_opsz48.svg

Abschlussbericht für aktiv ausgenutzte Schwachstellen

sync_saved_locally_FILL0_wght400_GRAD200_opsz48.svg

Abschlussbericht für schwerwiegende Sicherheitsvorfälle

Um diese Fristen einhalten zu können, braucht es funktionierende interne Prozesse: Ein Schwachstellenmonitoring, klare Meldewege und definierte Verantwortlichkeiten.

11. Dezember 2027 – Volle Anwendbarkeit

Ab diesem Datum müssen alle Produkte mit digitalen Elementen, die neu in der EU in Verkehr gebracht werden, sämtliche CRA-Anforderungen erfüllen, inklusive&nbsp;<a href="https://europa.eu/youreurope/business/product-requirements/labels-markings/ce-marking/index_de.htm" class="editor-link">CE-Kennzeichnung</a>. Ohne diese darf ein Produkt ab dann nicht mehr auf den EU-Markt.

11. Juni 2028 – Ablauf der EU-Typprüfzertifikate

Bereits bestehende EU-Typprüfzertifikate behalten ihre Gültigkeit, laufen aber spätestens am 11. Juni 2028 aus. Wer solche Zertifikate für seine Produkte nutzt, sollte rechtzeitig prüfen, wann genau sie ablaufen und welche Schritte danach notwendig sind.

Was gilt für Produkte, die bereits auf dem Markt sind?

Eine Frage, die viele beschäftigt: Müssen auch bestehende Produkte nachgerüstet werden? Grundsätzlich gilt, dass Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, nicht automatisch dem CRA unterliegen. Es gibt jedoch zwei wichtige Ausnahmen: <ol class="editor-list-ol"><li value="1" class="editor-listitem">Wesentliche Änderungen: Wird ein bestehendes Produkt nach dem 11. Dezember 2027 wesentlich verändert, greift der CRA vollständig, als wäre es ein neues Produkt.</li><li value="2" class="editor-listitem">Meldepflicht: Die Pflicht zur Meldung von Schwachstellen und Vorfällen gilt bereits ab September 2026 für alle Produkte auf dem EU-Markt, unabhängig vom Inverkehrbringen-Datum.</li></ol>

Was passiert, wenn die Fristen des CRA nicht eingehalten werden?

Nichtstun ist keine Option – das machen die vorgesehenen Konsequenzen deutlich:

Kein Marktzugang

Produkte ohne gültige CE-Kennzeichnung dürfen nach dem 11. Dezember 2027 nicht mehr in der EU verkauft werden.

Rückruf und Marktstopp

Marktüberwachungsbehörden können Produkte sperren, zurückrufen oder deren Bereitstellung untersagen.

Empfindliche Bußgelder

<ul class="editor-list-ul"><li value="1" class="editor-listitem">Bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen.</li><li value="2" class="editor-listitem">Bis zu 10 Mio. EUR oder 2 % des Jahresumsatzes bei sonstigen CRA-Verstößen.</li><li value="3" class="editor-listitem">Bis zu 5 Mio. EUR oder 1 % des Jahresumsatzes bei falschen oder irreführenden Angaben gegenüber Behörden.</li></ul>

Reputationsschäden

Verstöße können öffentlich bekannt gemacht werden. Und das zieht entsprechende Folgen für das Vertrauen von Kunden und Partnern mit sich.

Checkliste: Was sollten Unternehmen jetzt tun?

Die folgende Kurzcheckliste hilft Ihnen, den Einstieg zu strukturieren und keine wichtige Frist zu übersehen: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Eigenes Produktportfolio auf CRA-Relevanz prüfen</li><li value="2" class="editor-listitem">Produktkategorien bestimmen (Standard / Wichtig / Kritisch)</li><li value="3" class="editor-listitem">Interne Prozesse für Schwachstellenmanagement aufsetzen</li><li value="4" class="editor-listitem">Software Bill of Materials (SBOM) einführen</li><li value="5" class="editor-listitem">Meldewege definieren und testen</li><li value="6" class="editor-listitem">Konformitätsbewertungsverfahren einleiten (je nach Kategorie)</li><li value="7" class="editor-listitem">Technische Dokumentation aufbauen</li><li value="8" class="editor-listitem">Zulieferer und Lieferkette auf CRA-Anforderungen prüfen</li><li value="9" class="editor-listitem">Gültigkeit bestehender Typprüfzertifikate prüfen</li></ul>

blog-thumbnail-cra-grundlagen.png

Cyber Resilience Act: Grundlagen und Auswirkungen

Cyber Resilience Act erklärt: Erfahren Sie alles über die EU-Verordnung, betroffene Produkte und erforderliche Sicherheitsstandards. Jetzt informieren!

Der Cyber Resilience Act etabliert einheitliche Cybersicherheitsstandards für digitale Produkte in der EU. Erfahren Sie, wen die Verordnung betrifft.

Erstmals werden einheitliche Mindeststandards für die Sicherheit digitaler Produkte in der gesamten EU etabliert. Für Hersteller, Importeure und Händler bedeutet dies: Cybersicherheit wird zur rechtlichen Pflicht. In diesem Beitrag erfahren Sie, was der Cyber Resilience Act genau ist, wen es betrifft und welche Anforderungen auf Unternehmen zukommen.

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (CRA) – auf Deutsch auch <a href="https://www.bundeskanzleramt.gv.at/themen/cybersicherheit/cyberresilienz-verordnung-cra.html" rel="noreferrer" class="editor-link">Cyberresilienz-Verordnung</a> genannt – ist eine EU-Verordnung, die am 10. Dezember 2024 in Kraft getreten ist. Die offizielle Bezeichnung lautet „Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen“.

Hauptziel des CRA

Das Hauptziel des CRA ist es, ein einheitliches Sicherheitsniveau für alle Produkte mit digitalen Elementen zu schaffen, die in der EU in Verkehr gebracht werden. Die Verordnung verfolgt einen ganzheitlichen Ansatz: Cybersicherheit soll nicht nachträglich aufgesetzt, sondern von Anfang an in den Entwicklungsprozess integriert werden. Es gilt das Prinzip „Security by Design“.

Relevante Fristen des CRA

Der zeitliche Rahmen ist klar definiert: Obwohl die Verordnung bereits in Kraft getreten ist, gelten die meisten Verpflichtungen erst ab dem 11. Dezember 2027. Für bestimmte Berichtspflichten und Prozesse gelten kürzere Übergangsfristen. Diese Vorlaufzeit soll Unternehmen ermöglichen, ihre Produkte und Prozesse anzupassen. Genauere Infos finden Sie in unserem Beitrag über die bestehenden&#160;<a href="/blog/fristen-cra" rel="noreferrer" data-page-ref="6a2fbf4007dcc4d451c2571d" class="editor-link">Fristen des CRA</a>.

Geografischer Geltungsbereich des CRA

Der geografische Geltungsbereich umfasst den gesamten EU-Binnenmarkt. Das bedeutet: Auch Hersteller außerhalb der EU müssen die Anforderungen erfüllen, wenn sie ihre Produkte auf dem europäischen Markt anbieten möchten. Die Cyberresilienz-Verordnung schafft damit einheitliche Spielregeln für alle Marktteilnehmer.

Wer ist vom Cyber Resilience Act betroffen?

Die Cyber Resilience Act betrifft ein breites Spektrum von Akteuren entlang der gesamten Lieferkette: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Hersteller stehen im Zentrum der Verordnung: Sie tragen die Hauptverantwortung für die Einhaltung der Sicherheitsanforderungen. Unabhängig davon, ob sie in der EU ansässig sind oder nicht.</li><li value="2" class="editor-listitem">Importeure übernehmen die Verantwortung: Wenn sie Produkte aus Drittländern in die EU einführen, müssen sie sicherstellen, dass die Produkte den CRA-Anforderungen entsprechen.</li><li value="3" class="editor-listitem">Händler haben eine Sorgfaltspflicht: Sie dürfen nur Produkte anbieten, die den Anforderungen der Cyberresilienz-Verordnung entsprechen und ordnungsgemäß gekennzeichnet sind.</li></ul>

Welche Produkte fallen in den Geltungsbereich des CRA?

Der CRA gilt für „Produkte mit digitalen Elementen“, die direkt oder indirekt mit einem Netzwerk oder einem Gerät verbunden werden können. Ein bewusst weit gefasster Begriff, der sowohl Hardware als auch Software umfasst. Dazu zählen: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Endgeräte &amp; Hardware: Router, Firewalls, Netzwerk-Switches, Computer, Laptops, Tablets, Smartphones, Kameras, Drucker etc.</li><li value="2" class="editor-listitem">Smart Home &amp; IoT: Intelligente Türschlösser, vernetzte Beleuchtungssysteme, Smart Speaker, Wearables, vernetzte Haushaltsgeräte, Sicherheitssysteme etc.</li><li value="3" class="editor-listitem">Software: Betriebssysteme, eigenständige Anwendungen, Apps, Browser, Fernwartungssoftware, VPN-Clients, Antivirus-Programme etc.</li><li value="4" class="editor-listitem">Cloud Lösungen: Software-as-a-Service (SaaS) mit herunterladbaren Komponenten, Cloud-Management-Plattformen, Remote-Access-Tools etc.</li><li value="5" class="editor-listitem">Industrielle Komponenten &amp; Bauteile: Vernetzte Industrieanlagen, industrielle Steuerungssysteme, programmierbare Logikcontroller (PLC), Sensoren und Aktoren mit Netzwerkanbindung, Embedded Systems etc.</li></ul>

Risikokategorien des CRA

Der CRA unterscheidet dabei zwischen drei Risikokategorien, die unterschiedliche Anforderungsniveaus mit sich bringen: <ul class="editor-list-ul"><li value="1" class="editor-listitem">Standardprodukte bilden die Mehrheit der betroffenen Produkte und unterliegen grundlegenden Sicherheitsanforderungen.</li><li value="2" class="editor-listitem">Wichtige Produkte (Klasse I und Klasse II) wie Betriebssysteme, Passwort-Manager oder Firewalls haben ein erhöhtes Risikopotenzial und müssen strengere Auflagen erfüllen.</li><li value="3" class="editor-listitem">Kritische Produkte wie Hardware-Sicherheitsmodule oder Smart Cards für qualifizierte elektronische Signaturen unterliegen den höchsten Sicherheitsanforderungen und einer verpflichtenden Prüfung durch benannte Stellen.</li></ul>

Produkte, die nicht unter den CRA fallen

Wichtig zu wissen: Es gibt Ausnahmen. Medizinprodukte, Kfz-Komponenten und Luftfahrtausrüstung unterliegen eigenen sektorspezifischen Regelungen und fallen nicht unter den CRA der EU. Auch Open-Source-Software, die nicht kommerziell vertrieben wird, ist von vielen Anforderungen ausgenommen.

Jetzt Produkt evaluieren

Die wichtigsten Anforderungen des CRA

Die Cyber Resilience Act stellt umfassende Anforderungen an Hersteller und andere Wirtschaftsakteure. Die zentralen Pflichten umfassen:

Security by Design und by Default

Cybersicherheit muss bereits in der Entwicklungsphase integriert werden. Produkte müssen mit sicheren Standardkonfigurationen ausgeliefert werden und die Angriffsfläche minimieren.

Schwachstellenmanagement

Hersteller müssen ein System zur Identifikation und Behebung von Sicherheitslücken etablieren. Schwerwiegende Schwachstellen sind innerhalb von 24 Stunden an die <a href="https://www.enisa.europa.eu" rel="noreferrer" class="editor-link">ENISA</a> zu melden. Sicherheitsupdates müssen rechtzeitig und kostenlos bereitgestellt werden.

Dokumentation und Transparenz

Erforderlich sind eine EU-Konformitätserklärung, technische Dokumentation sowie klare Nutzerinformationen über Sicherheitsmerkmale, Installation und die erwartete Produktlebensdauer.

CE-Kennzeichnung

Nach erfolgreicher Konformitätsbewertung, je nach Produktklasse durch Selbstbewertung oder durch benannte Stellen, wird die <a href="https://single-market-economy.ec.europa.eu/single-market/goods/ce-marking_en" rel="noreferrer" class="editor-link">CE-Kennzeichnung</a> angebracht.

Konsequenzen bei Nicht-Einhaltung des CRA

Verstöße gegen den Cyber Resilience Act können empfindliche Folgen haben. <ul class="editor-list-ul"><li value="1" class="editor-listitem">Bußgelder sind nach Schwere des Verstoßes gestaffelt und können bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes betragen, je nachdem, welcher Betrag höher ist. Bei weniger schwerwiegenden Verstößen drohen Strafen bis zu 10 bzw. 5 Millionen Euro oder entsprechende Prozentsätze des Umsatzes.</li><li value="2" class="editor-listitem">Marktzugangsverbote können von den Marktüberwachungsbehörden verhängt werden. Produkte, die nicht konform sind, dürfen nicht in Verkehr gebracht werden. Bereits auf dem Markt befindliche Produkte können zurückgerufen werden.</li><li value="3" class="editor-listitem">Reputationsrisiken sollten nicht unterschätzt werden. In einer Zeit, in der Datenschutz und Cybersicherheit zunehmend in den Fokus der Öffentlichkeit rücken, kann die Nicht-Einhaltung des CRA zu erheblichen Imageschäden führen.</li></ul>

Der Cyber Resilience Act zusammengefasst

Der Cyber Resilience Act markiert einen Wendepunkt für die Cybersicherheit in Europa. Er schafft erstmals einheitliche, verbindliche Mindeststandards für alle Produkte mit digitalen Elementen auf dem EU-Markt. Damit wird Cybersicherheit von einer optionalen Zusatzfunktion zur rechtlichen Grundanforderung.Die Übergangszeit mag auf den ersten Blick lang erscheinen, doch die Anpassung von Entwicklungsprozessen, die Implementierung von Schwachstellenmanagement-Systemen und die Erstellung der erforderlichen Dokumentation sind zeitaufwendige Projekte.

Cyber Resilience Act: Grundlagen & Anforderungen

Wir sind OVERLAP: Unser Team stellt sich Ihnen vor

Impressum & Datenschutz

icon-linkedin.svg

retina-logo-color.png

Overlap-Logo.svg

Unser Blog

blog-overview

Entdecken Sie aktuelle Insights, Fachwissen und praxisnahe Beiträge rund um Digitalisierung, Technologie, KI und die digitale Welt.