Kurz vorweg: Der CRA (Verordnung (EU) 2024/2847) ist die erste EU-weite Cyber-Sicherheits-Pflicht für Hardware und Software „mit digitalen Elementen". Hersteller (auch Schweizer) müssen CE-konforme Produkte in Verkehr bringen, Schwachstellen melden und mindestens 5 Jahre Sicherheits-Updates liefern. 90 % der Produkte sind „Standard" (Selbst-Bewertung), 10 % sind wichtig/kritisch und brauchen externe Stellen. SaaS bleibt aussen vor (NIS2). Realistische Aufwände: CHF 25–80k für Standard, CHF 60–150k für Class I, CHF 120–300k für Class II.
Wer ist betroffen?
Hersteller
Wer ein Produkt mit digitalen Elementen unter eigenem Namen oder Marke in der EU in Verkehr bringt. Trifft Schweizer Industrie-KMU mit IoT, Maschinen, Steuerungen, eigene Software/Apps.
Importeure
Wer Produkte aus Drittländern in die EU einführt. Schweizer Distributoren mit EU-Niederlassung können in diese Rolle rutschen.
Händler
Wer Produkte auf dem EU-Markt bereitstellt. Schlankere Pflichten (Prüfen, Aufbewahren, Mitwirken bei Vorfällen).
Komponenten-Lieferanten
Bibliotheken, Module, Firmware, SDKs – auch wenn nicht an Endkunden verkauft. Pflichten an Hersteller weitergeben, SBOM liefern.
Open-Source-Stewards
Stiftungen / Foundations, die OSS kommerziell verantworten. Schlankere Pflichten als Hersteller, aber Vulnerability-Handling-Prozess Pflicht.
Nicht betroffen
Reine SaaS-Cloud (NIS2-Pflicht), MedTech (MDR), Auto (Type Approval), Luftfahrt, Militär – sektorspezifische Regeln dominieren.
Produktklassen & Konformitätsverfahren
Standard (ca. 90 % aller Produkte)
Selbst-Bewertung (Modul A): IoT-Endgeräte, Apps, Spiele, Smart-Home-Geräte mit moderatem Risiko. Hersteller dokumentiert Konformität selbst, CE-Kennzeichen anbringen, technische Doku 10 Jahre archivieren.
Wichtige Produkte – Klasse I (Annex III)
Browser, Passwort-Manager, Antivirus, VPN, Netzwerk-Management, SIEM-Komponenten, Identitätsmanagement, smarte Haushaltsroboter, smarte Türschlösser. Konformität über harmonisierte Norm + Selbst-Bewertung ODER Modul B+C/Modul H (Vollständiges Qualitätsmanagement).
Wichtige Produkte – Klasse II (Annex III)
Firewalls, IDS/IPS, Mikroprozessoren mit Sicherheitsfunktion, Hypervisoren, Container-Runtime, PKI-Komponenten. Konformität nur über Modul B+C oder H – notifizierte Stelle (Notified Body) Pflicht.
Kritische Produkte (Annex IV)
Smartcards, Smart-Meter-Gateways, Hardware Security Modules (HSM), CPUs mit Sicherheitskern, sichere Elemente. Kommission kann verpflichtende EU-Cybersecurity-Zertifizierung (z. B. EUCC) verlangen.
Free & Open Source (FOSS)
Reine OSS-Veröffentlichung ohne kommerzielle Aktivität: ausgenommen. Sobald monetarisiert (Support, SaaS-Bundle, kommerzielle Version): CRA gilt. Open-Source-Stewards mit schlankeren Pflichten (Vulnerability-Handling, Kooperation).
Grundlegende Anforderungen (Annex I)
- Security by Design: Risikoanalyse für die Schutzziele, sichere Default-Konfiguration, minimale Angriffsfläche.
- Schutz vor unautorisiertem Zugriff: Authentisierung, Zugangskontrolle, Identitätsmanagement.
- Vertraulichkeit & Integrität: Verschlüsselung in Ruhe und Transport, sichere Schlüsselverwaltung.
- Verfügbarkeit & DoS-Schutz: Resilienz gegen typische Last-Angriffe und Ressourcenerschöpfung.
- Daten-Minimierung: nur das Notwendige verarbeiten, persönliche Daten geschützt.
- Sichere Update-Mechanismen: signierte Updates, automatisch oder einfach für Nutzer einspielbar.
- Vulnerability-Handling: Coordinated Vulnerability Disclosure (CVD), Security.txt, SBOM in maschinenlesbarem Format (SPDX/CycloneDX).
- Mindest-Support-Periode: 5 Jahre Sicherheits-Updates ab Inverkehrbringen, in der EU klar kommuniziert.
Meldepflichten (ab 11.9.2026)
Frühwarnung
Aktive Ausnutzung einer Schwachstelle oder schweren Vorfall, der die Sicherheit des Produkts beeinträchtigt – Frühwarnung an ENISA und nationale CSIRT via Single-Reporting-Portal.
Vorfalls-Meldung
Detaillierte Meldung: Schwere, betroffene Nutzer, ergriffene Massnahmen, Mitigation. Auch wenn noch nicht alle Details vorhanden.
Abschlussbericht
Vollständige Wurzel-Ursache, finale Mitigation, Patch-Ausrolldatum, lessons learned. Bei aktiv ausgenutzten Schwachstellen vorgeschalteter Patch.
Nutzer-Information
Betroffene Nutzer in der EU sind ohne unangemessene Verzögerung zu informieren – Empfehlungen, ob Update verfügbar, wie zu schützen.
12-Monats-Roadmap CRA
Monat 1–2: Scoping & Inventar
Produkt-Portfolio analysieren: Welche Produkte fallen unter CRA? Klassifikation Standard/Class I/Class II/Critical. EU-Markt-Volumen pro Produkt prüfen. Stop-Sell-Risiko bewerten.
Monat 3–4: SBOM & Inventar
Software-Stückliste in SPDX oder CycloneDX für jedes Produkt. Alle Komponenten, Versionen, Lizenzen, Anbieter. Auto-Generation in CI/CD integrieren (Syft, Trivy, GitHub Dependency Graph).
Monat 5–6: Vulnerability-Handling
CVD-Prozess: security.txt, PSIRT-Mailbox, Disclosure-Policy, CVSS-Bewertung, SLA. CVE-Numbering-Authority (CNA) erwägen. Patch-Pipeline mit signierten Updates.
Monat 7–8: Security-Architektur
Annex-I-Anforderungen pro Produkt durchgehen: Default-Sicherheit, Auth, Crypto, Logging, Update-Mechanismus. Threat-Modell (STRIDE) dokumentieren. Lücken schliessen.
Monat 9–10: Konformitätsbewertung
Modulauswahl nach Klasse. Standard: technische Doku, EU-Konformitätserklärung, CE. Class I/II: harmonisierte Norm oder notifizierte Stelle. Class Critical: EU-Schema (EUCC).
Monat 11–12: Markteinführung & Operate
CE/CRA-Kennzeichnung, EU-Konformitätserklärung, Importeur/Bevollmächtigter benannt, Customer-Information (Support-Periode, CVD), Marktüberwachungs-Anfragen-Prozess.
Typische Stolpersteine
- CRA mit NIS2 verwechselt: NIS2 regelt Betreiber (Cloud, KMU als Anwender), CRA regelt Produkte. KMU als Hersteller einer IoT-Lampe ist CRA, als Cloud-Nutzer NIS2.
- SaaS als „Produkt" eingestuft: reine Cloud-Dienste fallen unter NIS2, nicht CRA. Mischformen (SaaS + Mobile App) brauchen Sub-Scope-Analyse.
- SBOM nur einmal erstellt: SBOM muss bei jedem Release aktualisiert werden, automatisch in CI/CD. Statische SBOM ist nach 2 Wochen veraltet.
- 5-Jahre-Support unterschätzt: Maintenance-Plan, Engineering-Reserven, klare Kommunikation an Kunden – sonst Schadenersatz und Verbraucherklagen.
- Kein EU-Bevollmächtigter benannt: Schweizer Hersteller braucht zwingend einen EU-Bevollmächtigten als Single Point of Contact für Marktüberwachung.
- CVD-Prozess fehlt: Forscher melden Schwachstellen, niemand reagiert – Eskalation an Behörde, schlechte Presse, Reputationsschaden.
- Open-Source-Komponenten ohne Lizenz-/Sicherheits-Review: ungepatchte Libraries in SBOM, CVE-Treffer, manuelle Aufholjagd nach Veröffentlichung.
- CE-Kennzeichnung ohne CRA-Doku: bei Marktüberwachungs-Kontrolle wird das Produkt aus dem Verkehr gezogen – innert 30 Tagen Doku liefern oder Rückruf.
- Modulwahl falsch: Class I als Standard deklariert, Marktüberwachung stellt um – nachträgliche Konformität dauert 9–18 Monate.
- Lieferanten-SBOM fehlt: Komponenten-Hersteller liefert keine SBOM – eigene Konformität blockiert. Vertragspflicht aufnehmen.
Fazit: CRA ist Pflicht – aber lösbar
Der CRA ändert die Spielregeln für jeden Schweizer Hersteller mit EU-Marktanteil. Wer sein Produkt-Portfolio jetzt klassifiziert, SBOM in die CI/CD bringt, CVD etabliert und einen Konformitäts-Track für Q3 2026 startet, ist bis Dezember 2027 sauber aufgestellt. Wer wartet, riskiert Stop-Sell, Rückrufe und EUR-Millionen-Bussen – auch ohne EU-Sitz.
Für Standard-Produkte (90 % der Fälle) reicht ein 12-Monats-Plan mit klarer Linie: SBOM aus dem Build, security.txt + PSIRT-Mailbox, signierte Updates über 5 Jahre, technische Doku und Selbst-Konformitätserklärung. Class I und Class II brauchen früh die notifizierte Stelle. Wer schon nach ISO 27001 zertifiziert ist oder NIS2-Reife hat, kommt mit 30–50 % Delta-Aufwand zum CRA. Tipp: Konformität pro Produktfamilie standardisieren, nicht pro SKU.
CRA-Konformität für Ihre Produkte
Wir klassifizieren Ihr Produkt-Portfolio, bauen SBOM in die CI/CD, etablieren CVD und führen Sie durch die Konformitätsbewertung – realistisch in 12 Monaten bis zur CE/CRA-Erklärung.
Beratung anfragen