CYBER RESILIENCE ACT

Produktklassen · Secure by Design · SBOM · CVD · CE-Kennzeichnung · Lieferkette

Vorbemerkung

Diese Leitfadenreihe ist aus einer spezifischen Perspektive heraus geschrieben: der einer General Counsel / Senior Vice President, die über viele Jahre in leitender Inhouse-Funktion in regulierten Unternehmen gearbeitet hat – in der Schweiz und in der EU. Die Autorin verfügt über eine juristische und betriebswirtschaftliche Ausbildung in der Schweiz und in Deutschland sowie über langjährige operative Erfahrung als interne Rechts- und Compliance-Verantwortliche in internationalen Konzernen und KMU-Umfeldern.

Diese Kombination – juristische Tiefe, operatives Management-Know-how und direkte Erfahrung mit den Realitäten von Lieferketten, Vertragsverhandlungen und Aufsichtsbehörden – ist der Grund, warum die Texte so geschrieben sind, wie sie sind: nicht als formale Gesetzeskommentare, sondern als Arbeitsinstrumente. Sie richten sich gleichzeitig an Führungskräfte, die schnell einordnen müssen, was eine Regulierung für ihr Unternehmen bedeutet, und an Fachabteilungen, die wissen müssen, was operativ zu tun ist.

Der interdisziplinäre Ansatz ist bewusst: Digitale Regulierung berührt gleichzeitig IT, Recht, Procurement, Geschäftsführung, HR und Lieferkette. Eine Perspektive, die nur eine dieser Dimensionen kennt, liefert unvollständige Antworten. Die Leitfäden versuchen, alle relevanten Dimensionen gleichzeitig zu adressieren – mit dem Bewusstsein, dass in der Praxis selten ein Team allein zuständig ist und die wirklichen Herausforderungen meistens an den Schnittstellen entstehen.

Die Perspektive «Schweizer KMU im EU-Kontext» ist nicht zufällig. Sie spiegelt langjährige Arbeit an der Schnittstelle zwischen Schweizer Geschäftspraxis und europäischem Regulierungsrahmen: die Erfahrung, was es konkret bedeutet, wenn ein EU-Kundenvertrag plötzlich DORA-Klauseln enthält, wenn ein Procurement-Fragebogen AI-Act-Anforderungen stellt oder wenn ein Lieferant keine NIS2-konformen Sicherheitsnachweise liefern kann. Diese Leitfäden sind aus genau diesen Situationen heraus entstanden – nicht aus dem Lesen von Gesetzestexten, sondern aus der Erfahrung ihrer Auswirkungen.

Vorwort: Was der CRA wirklich bedeutet

Der Cyber Resilience Act (CRA, verabschiedet 2024, verpflichtend ab Dezember 2027) ist das erste umfassende EU-Gesetz, das Sicherheitsanforderungen direkt an digitale Produkte knüpft – nicht an deren Betreiber. Das ist ein Paradigmenwechsel.

Mit der vollständigen Anwendbarkeit des CRA müssen erfasste Produkte verbindliche Cybersicherheits- und Konformitätsanforderungen erfüllen; Verstösse können Marktüberwachungsmassnahmen und Sanktionen auslösen. Zivilrechtliche Haftung ergibt sich nicht als neue allgemeine CRA-Haftung, sondern zusätzlich aus Produkthaftungs- und nationalem Recht. Für Schweizer Softwareunternehmen, IoT-Hersteller und alle, die digitale Produkte in der EU verkaufen, ist das eine fundamentale Verschiebung.

1. Bin ich betroffen? – Entscheidungslogik

2. Produktklassifizierung – wo steht Ihr Produkt?

Der CRA teilt Produkte in drei Klassen ein. Die Klasse bestimmt den Aufwand für Konformitätsbewertung und CE-Kennzeichnung. Das Erste, was Sie tun müssen: Jedes Ihrer digitalen Produkte klassifizieren.

2.1 Die drei CRA-Produktklassen

2.2 Was bedeutet 'Produkt mit digitalen Elementen'?

Der CRA-Anwendungsbereich ist weit gefasst. Folgendes fällt unter den CRA:

Software als eigenständiges Produkt: SaaS (wenn auf Kundeninfrastruktur installiert), Desktop-Apps, Mobile Apps, Firmware.

Hardware mit Software: IoT-Geräte, Netzwerkausrüstung, Industriemaschinen mit Steuerungssoftware, Wearables.

Software in anderen Produkten: Betriebssysteme, Middleware, Bibliotheken, die in Endprodukte integriert werden.

Folgendes fällt nicht unter den CRA:

Software as a Service (SaaS), die vollständig remote betrieben wird und nicht auf Kundensystemen installiert wird

Open-Source-Software, die nicht kommerziell vertrieben wird

Produkte, die ausschliesslich für nationale Sicherheit oder Militär entwickelt werden

3. Rollen – wer hat welche Pflichten?

3.1 Hersteller: Die umfassendsten Pflichten

Als Hersteller tragen Sie die vollständige Verantwortung für die CRA-Konformität Ihres Produkts – unabhängig davon, wo es hergestellt wurde.

3.2 Importeure: Was gilt für Schweizer Unternehmen, die EU-Produkte einführen?

Ein Schweizer Unternehmen, das digitale Produkte aus einem Drittstaat in die EU einführt, gilt als Importeur und trägt eigene CRA-Pflichten:

Sicherstellen, dass der Hersteller die CRA-Anforderungen erfüllt hat

Keine Produkte in Verkehr bringen, die den CRA-Anforderungen offensichtlich nicht entsprechen

Kontaktdaten auf dem Produkt oder in der Dokumentation angeben

Konformitätsdokumentation für 10 Jahre aufbewahren

3.3 Integratoren: Das unterschätzte Risiko

Das klassische Integratoren-Problem: Ein Schweizer IT-Unternehmen integriert mehrere digitale Komponenten verschiedener Hersteller zu einer Gesamtlösung und verkauft diese unter eigenem Namen. Wer ist dann Hersteller im Sinne des CRA?

4. Secure by Design – was das konkret bedeutet

'Secure by Design' ist der zentrale Begriff des CRA. Er bedeutet nicht, dass Ihr Produkt unhackbar ist – das ist unmöglich. Er bedeutet, dass Sicherheit systematisch und nachweisbar in den Entwicklungsprozess integriert ist.

4.1 Der Secure Development Lifecycle (SDLC)

4.2 Das Bedrohungsmodell – warum es unumgehbar ist

Ein Bedrohungsmodell ist das Dokument, das beweist, dass Sie die Sicherheitsrisiken Ihres Produkts systematisch analysiert haben. Es ist die Grundlage für alle anderen Sicherheitsmassnahmen – und das Erste, was ein Auditor sehen will.

Was es enthält: Beschreibung des Systems, identifizierte Angreifer und ihre Ziele, mögliche Angriffsvektoren, bewertete Risiken, implementierte Gegenmassnahmen.

Methodik: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) ist der Standard – einfach, dokumentierbar, anerkannt.

Aktualität: Bei jeder wesentlichen Produktänderung aktualisieren. Ein veraltetes Bedrohungsmodell ist schlimmer als keines.

5. SBOM – die Stückliste Ihrer Software

Die Software Bill of Materials (SBOM) ist eine maschinenlesbare Liste der im Produkt enthaltenen Komponenten, Bibliotheken und Abhängigkeiten. Der CRA verlangt, die Komponenten zu identifizieren und zu dokumentieren – einschliesslich einer SBOM zumindest in einem gängigen maschinenlesbaren Format (Anhang I). Das bedeutet nicht, dass jede vollständige SBOM jedem Kunden oder jeder Behörde offengelegt werden muss.

5.1 Was eine SBOM enthält

Jede Komponente: Name, Version, Lizenz, Herkunft

Abhängigkeiten: Direkte und transitive Abhängigkeiten (Bibliotheken, die Ihre Bibliotheken verwenden)

Bekannte Schwachstellen: getrennt zu führen — eine SBOM ist keine Schwachstellendatenbank. Das Mapping zu CVEs bzw. eine VEX-Auswertung ist eine sinnvolle operative Ergänzung, aber nicht zwingender Bestandteil der eigentlichen Stückliste

Herkunft: Woher kommt die Komponente? (SCM, Package Registry, Direct Download)

5.2 SBOM-Tools für KMU

6. Vulnerability Disclosure – der CVD-Prozess

Der CRA verlangt, dass Hersteller einen koordinierten Schwachstellen-Offenlegungsprozess (Coordinated Vulnerability Disclosure, CVD) etablieren. Das bedeutet: Security-Forscher und Kunden müssen Schwachstellen einfach und sicher melden können.

6.1 Was ein CRA-konformer CVD-Prozess enthält

Öffentlicher Meldekanal: Eine E-Mail-Adresse (security@ihredomain.ch), ein Webformular oder ein Bug-Bounty-Programm.

Reaktionsziele (Beispiel, keine allgemeine CRA-Frist): Eingangsbestätigung innerhalb eines Arbeitstages, erste Bewertung innerhalb weniger Tage.

Koordination: Abstimmung mit Melder über Offenlegungszeitpunkt – typischerweise rund 90 Tage nach Meldung (Branchenpraxis, keine CRA-Frist).

ENISA-Meldung (Art. 14 CRA, gestuft): Bei aktiv ausgenutzten Schwachstellen bzw. schwerwiegenden Vorfällen zunächst eine Frühwarnung binnen 24h, dann eine Meldung binnen 72h und schliesslich ein Abschlussbericht binnen 14 Tagen an ENISA und das zuständige CSIRT.

CVE-Beantragung: Für bestätigte Schwachstellen eine CVE-Nummer beantragen.

Update-Deployment: Sicherheitspatches innerhalb der definierten Fristen bereitstellen.

6.2 Minimalaufwand CVD-Policy für KMU

7. CRA-Auswirkungen auf die Lieferkette

Der CRA wirkt nicht nur auf Endprodukte – er wirkt durch die gesamte Software-Lieferkette. Das hat Konsequenzen in beide Richtungen: als Lieferant und als Abnehmer.

7.1 Als Lieferant von Software-Komponenten

Wenn Ihre Software oder Ihre Komponenten in die Produkte anderer Hersteller einfliessen, werden diese Hersteller CRA-Konformitätsnachweise von Ihnen verlangen:

SBOM: Vollständige Komponentenliste Ihrer Lieferung.

Vulnerability-Disclosure-Prozess: Nachweis, dass Sie bekannte Schwachstellen kommunizieren.

Patch-Verfügbarkeit: Sicherheitspatches müssen verfügbar und bereitgestellt werden.

Dokumentation: Bedrohungsmodell und Sicherheitskontrollen für Ihre Komponente.

7.2 Als Abnehmer von Software-Komponenten

Sie sind als Hersteller verantwortlich für alle Komponenten in Ihrem Produkt – auch für zugekaufte oder Open-Source-Komponenten:

Komponentenbewertung: Vor Integration prüfen, ob die Komponente bekannte Schwachstellen hat.

Herkunftsprüfung: Woher stammt die Komponente? Gibt es einen aktiven Maintainer? Wird sie gepatcht?

Abhängigkeits-Monitoring: Laufendes CVE-Monitoring für alle integrierten Komponenten.

Open Source: Open-Source-Komponenten ohne aktiven Maintainer sind ein erhöhtes Risiko. Alternativen evaluieren oder selbst maintainen.

8. Typische Fehler

Fehler 1: CRA als Zertifizierungsprojekt für 2027 behandeln

'Wir fangen 2026 an.' Zu spät. Secure by Design bedeutet, dass Sicherheit im nächsten Release-Zyklus bereits eingebaut sein muss. Ein bestehendes Produkt auf CRA-Konformität nachzurüsten dauert 12–24 Monate – besonders das Bedrohungsmodell, die SBOM-Infrastruktur und der CVD-Prozess.

Fehler 2: Open Source als Freikarte sehen

'Wir verwenden Open-Source-Bibliotheken – die sind nicht unser Problem.' Das stimmt nicht. Als Hersteller tragen Sie die Verantwortung für alle Komponenten in Ihrem Produkt, egal ob selbst entwickelt oder zugekauft. Wenn eine Open-Source-Bibliothek eine kritische CVE enthält und Sie keinen Patch bereitstellen, verstossen Sie gegen den CRA.

Fehler 3: Produktlebensdauer-Pflichten unterschätzen

Der CRA verpflichtet Hersteller zu Sicherheitsupdates für die gesamte erwartete Produktlebensdauer, mindestens aber 5 Jahre. Für IoT-Produkte, die 10 oder 15 Jahre im Einsatz sind, bedeutet das erheblichen langfristigen Aufwand – und muss bei der Produktkalkulation berücksichtigt werden.

Fehler 4: ENISA-Meldepflicht ab 2026 übersehen

Viele KMU planen ihre CRA-Umsetzung auf den vollständigen Anwendungstermin (Dezember 2027). Aber die ENISA-Meldepflicht für aktiv ausgenutzte Schwachstellen gilt bereits ab September 2026. Wer dann keinen Meldeprozess hat, verletzt bereits eine CRA-Pflicht.

9. Was Sie jetzt tun – priorisiert

Kontakt & weitere Informationen