Cyber Resilience Act (CRA): Was Schweizer Hersteller ab 2027 wissen müssen
Der EU Cyber Resilience Act (CRA) verpflichtet Hersteller digitaler Produkte zur Einhaltung strenger Sicherheitsstandards. Auch Schweizer Unternehmen, die digitale Produkte in der EU vertreiben, sind betroffen. Dieser Artikel erklärt die Anforderungen, Fristen und was Sie jetzt tun müssen.
Was ist der Cyber Resilience Act?
Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die im September 2024 verabschiedet wurde. Er gilt für alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden — von Smartphones über Industriesteuerungen bis zu Software-as-a-Service. Ziel ist es, Sicherheitslücken bereits beim Design zu vermeiden und über den gesamten Produktlebenszyklus Transparenz zu schaffen.
Wer ist vom CRA betroffen?
Der CRA definiert verschiedene Rollen und Produktkategorien:
Betroffene Rollen
| Rolle | Definition | Beispiele |
|---|---|---|
| Hersteller | Entwickelt oder herstellt Produkte mit digitalen Elementen | Software-Häuser, Hardware-Hersteller, IoT-Anbieter |
| Importeur | Bringt Produkte aus Drittstaaten (z.B. Schweiz) in die EU | Schweizer Firmen mit EU-Vertrieb |
| Händler / Distributor | Vertreibt Produkte innerhalb der EU | Reseller, Value-Added-Distributoren |
| Open-Source-Stewards | Kommerzielle Anbieter von Open-Source-Komponenten | Firmen, die Open-Source-Produkte supporten |
Produktkategorien
Der CRA unterteilt Produkte in zwei Klassen:
- Default-Produkte (Klasse I): Alle Produkte mit digitalen Elementen, die nicht als "important" eingestuft sind. Beispiele: Smartphones, Tablets, Smart-Home-Geräte, gewerbliche Software.
- Important-Produkte (Klasse II): Produkte mit besonderer Relevanz für die Sicherheit. Beispiele: Betriebssysteme, Industrial-Control-Systeme, Netzwerk-Hardware, Passwort-Manager, Browser, VPN-Lösungen.
Die zentralen CRA-Anforderungen
Der CRA verpflichtet Hersteller zu einem umfassenden Security-by-Design-Ansatz. Die wichtigsten Anforderungen:
1. Security by Design und by Default (Art. 10)
Produkte müssen so entwickelt werden, dass sie von Grund auf sicher sind. Dazu gehören:
- Schutz vor unbefugtem Zugriff (Authentifizierung, Verschlüsselung)
- Vertraulichkeit, Integrität und Verfügbarkeit der Daten
- Minimierung der Angriffsfläche (keine unnötigen Dienste oder Ports)
- Sichere Software-Updates über den gesamten Lebenszyklus
2. Vulnerability-Management (Art. 13)
Hersteller müssen:
- Sicherheitslücken systematisch identifizieren, dokumentieren und beheben
- Security-Patches innerhalb von 24 Stunden für aktive Exploits bereitstellen
- Regelmässige Sicherheitsupdates über den definierten Supportzeitraum anbieten
- Ein Coordinated Vulnerability Disclosure (CVD) Verfahren etablieren
3. Transparenz und Dokumentation (Art. 14)
Hersteller müssen folgende Dokumente bereitstellen:
- EU Declaration of Conformity: Bestätigung, dass das Produkt den CRA-Anforderungen entspricht
- Technische Dokumentation: Architektur, Sicherheitsmassnahmen, Risikoanalyse
- Software Bill of Materials (SBOM): Liste aller Software-Komponenten und Abhängigkeiten
- Instructions for Use: Sicherheitshinweise für Endnutzer und Administratoren
4. Meldeverpflichtungen (Art. 14)
Hersteller müssen unverzüglich (innerhalb von 24 Stunden) melden:
- Aktive Ausnutzung von Sicherheitslücken (exploited vulnerabilities)
- Schwere Sicherheitsvorfälle, die die Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigen
Innerhalb von 72 Stunden muss eine erste Bewertung vorliegen, innerhalb von 14 Tagen eine abschliessende Meldung mit Gegenmassnahmen.
Was bedeutet der CRA für Schweizer Unternehmen?
Schweizer Unternehmen sind dann betroffen, wenn sie:
- Software, Hardware oder IoT-Produkte direkt in der EU vertreiben (z.B. über App Stores, Amazon, eigene Vertriebskanäle)
- als Importeur oder Distributor für EU-Produkte fungieren
- Open-Source-Komponenten kommerziell anbieten oder supporten
Ein reiner Schweizer Vertrieb ohne EU-Bezug fällt nicht unter den CRA. Sobald aber ein EU-Markt erschlossen wird, greift die Verordnung.
Beispiele betroffener Schweizer Unternehmen
- Schweizer Software-Haus mit SaaS-Lösung für EU-Kunden
- IoT-Hersteller (Smart-Home, Industrie 4.0) mit EU-Vertrieb
- Fintech-Start-up mit Banking-App im EU-App-Store
- Medizintechnik-Anbieter mit vernetzten Geräten in EU-Spitäern
- Cybersecurity-Anbieter (VPN, Antivirus, Endpoint-Security) mit EU-Kunden
Der CRA-Zeitplan: Wichtige Fristen
| Datum | Meilenstein |
|---|---|
| September 2024 | CRA in Kraft getreten (Veröffentlichung im EU-Amtsblatt) |
| Dezember 2026 | Ende der Übergangsfrist für die meisten Anforderungen (36 Monate) |
| September 2027 | Vollständige Anwendbarkeit für Default-Produkte |
| September 2027 | Meldeverpflichtungen gelten ab diesem Datum |
| Dezember 2029 | Vollständige Anwendbarkeit für Important-Produkte (längere Übergangsfrist) |
Was müssen Hersteller jetzt tun? Der CRA-Checklist
Produkt- und Entwicklungsprozess
- Security-by-Design in den SDLC (Software Development Life Cycle) integrieren
- Threat Modeling für alle neuen Produkte und Major-Releases durchführen
- Secure Coding Guidelines für Entwickler etablieren und durchsetzen
- Automatisierte Sicherheitstests (SAST, DAST, SCA) in CI/CD-Pipelines einbauen
- Penetrationstests für wichtige Produkte vor Release durchführen
- Software Bill of Materials (SBOM) für jedes Produkt erstellen und pflegen
Vulnerability- und Incident-Management
- Prozess für die Annahme, Bewertung und Behebung von Sicherheitslücken definieren
- 24-Stunden-Meldeprozess für aktive Exploits etablieren (intern + an ENISA)
- Coordinated Vulnerability Disclosure (CVD) Policy veröffentlichen
- Bug-Bounty-Programm oder Responsible Disclosure Kanal einrichten
- Patch-Management-Prozess für den gesamten Supportzeitraum definieren
Dokumentation und Konformität
- EU Declaration of Conformity erstellen und für jedes Produkt führen
- Technische Dokumentation (Architektur, Massnahmen, Risikoanalyse) systematisieren
- CE-Kennzeichnung vorbereiten (für Produkte mit digitalen Elementen)
- Anweisungen für sichere Installation, Konfiguration und Nutzung verfassen
Organisation und Lieferkette
- Verantwortliche Person für Produktsicherheit benennen (ähnlich DSB bei DSGVO)
- Lieferantenverträge um Security-Anforderungen erweitern
- Open-Source-Abhängigkeiten auf Schwachstellen und Lizenzen prüfen
- Interne Audits des Security-Prozesses planen und durchführen
Strafen und Sanktionen
Die Strafen unter dem CRA sind deutlich höher als bei vielen anderen Regulierungen:
| Verstoss | Maximale Strafe |
|---|---|
| Verstoss gegen wesentliche Sicherheitsanforderungen (Art. 53) | Bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes |
| Verstoss gegen Melde- oder Dokumentationspflichten | Bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes |
Zusätzlich drohen:
- Marktverbot für nicht konforme Produkte in der EU
- Rückrufaktionen und Verpflichtung zur Informierung der Nutzer
- Schadenersatzforderungen von Kunden und Partnern
- Reputationsverlust und Vertrauensverlust im Markt
Wie unterscheidet sich der CRA von NIS2?
Beide Regulierungen ergänzen sich, betreffen aber unterschiedliche Akteure:
| Aspekt | CRA | NIS2 |
|---|---|---|
| Zielgruppe | Hersteller von Produkten mit digitalen Elementen | Betreiber kritischer Infrastrukturen und wichtiger Einrichtungen |
| Fokus | Produktsicherheit über den Lebenszyklus | Organisationale Sicherheit und Resilienz |
| Rechtsform | EU-Verordnung (direkt anwendbar) | EU-Richtlinie (muss in nationales Recht umgesetzt werden) |
| Geografische Reichweite | Alle, die Produkte in die EU bringen | EU-Mitgliedstaaten (indirekt auch Schweiz über KRITIS) |
| Meldefristen | 24h (exploited), 72h (erste Bewertung) | 24h (kritisch), 72h (nicht kritisch) |
| Strafen | Bis 15 Mio. EUR / 2,5 % Umsatz | Bis 10 Mio. EUR / 2 % Umsatz |
Ein Unternehmen kann gleichzeitig unter CRA und NIS2 fallen — z.B. ein schweizerischer IoT-Hersteller, der seine eigenen Geräte in der EU betreibt (CRA als Hersteller, NIS2 als KRITIS-Betreiber).
Häufige Fragen (FAQ)
Gilt der CRA für reine Software?
Ja. Der CRA gilt für alle "Produkte mit digitalen Elementen" — das umfasst Hardware, Software und SaaS-Lösungen, sofern sie in der EU in Verkehr gebracht werden. Auch mobile Apps und Cloud-Services fallen unter die Definition.
Müssen Open-Source-Projekte den CRA erfüllen?
Nicht automatisch. Non-kommerzielle Open-Source-Projekte sind explizit ausgenommen. Sobald aber ein kommerzieller Anbieter das Projekt supportet, als Dienstleistung anbietet oder in ein kommerzielles Produkt integriert, greift der CRA.
Wer prüft die CRA-Konformität?
Hersteller müssen die Konformität grundsätzlich selbst attestieren (Internal Production Control, Modul A). Für Important-Produkte ist eine unabhängige Prüfung durch eine benannte Stelle (Notified Body) erforderlich. Diese Stellen werden von den EU-Mitgliedstaaten benannt.
Was ist eine Software Bill of Materials (SBOM)?
Eine SBOM ist eine detaillierte Aufstellung aller Software-Komponenten, Bibliotheken und Abhängigkeiten eines Produkts. Sie ermöglicht es, bekannte Schwachstellen (z.B. durch CVEs) schnell zu identifizieren und zu beheben. Formate wie SPDX oder CycloneDX sind etabliert.
Wie bereite ich mich als Schweizer Unternehmen vor?
Starten Sie jetzt mit einer Gap-Analyse: Prüfen Sie, ob Sie Produkte in die EU bringen, klassifizieren Sie Ihre Produkte (Default vs. Important), und erstellen Sie einen Umsetzungsplan mit klaren Verantwortlichkeiten. Involvieren Sie frühzeitig Entwicklung, Legal und Compliance.
Weiterführende Links
- Cyber Resilience Act Audit — Prüfung der CRA-Konformität
- ISO 27001 Zertifizierung — Fundament für Security-by-Design
- NIS2 & KRITIS Audit — Ergänzende regulatorische Prüfung
- ENISA Cyber Resilience Act — Offizielle EU-Informationen
CRA-Konformität prüfen lassen
Ich helfe Schweizer Herstellern, die CRA-Anforderungen zu verstehen, zu bewerten und umzusetzen — von der Gap-Analyse bis zur technischen Dokumentation.
CRA-Gap-Analyse anfragen