Cyber Resilience Act: Was der CRA für Schweizer Unternehmen bedeutet

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (CRA) ist die Verordnung (EU) 2024/2847. Sie wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und ist am 10. Dezember 2024 in Kraft getreten. Als Verordnung gilt sie unmittelbar in allen Mitgliedstaaten; eine nationale Umsetzung wie bei einer Richtlinie entfällt.

Regelungsgegenstand sind sogenannte Produkte mit digitalen Elementen (PDE). Der Begriff ist bewusst weit gefasst: Erfasst sind Hard- und Softwareprodukte, die eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk herstellen können – physisch oder logisch, etwa über WLAN, Bluetooth, Ethernet, USB, eine API oder eine Cloud-Schnittstelle. Vom Industrie-PC über die Steuerung, das IoT-Gateway und die Firmware bis zur Desktop-Anwendung, der Mobile App und dem Betriebssystem fällt praktisch die gesamte vernetzte Produktwelt darunter.

Die vier Kernpflichten

Der CRA verlangt von Herstellern im Wesentlichen vier Dinge:

• Security by Design und Secure by Default: Produkte müssen so entwickelt und ausgeliefert werden, dass sie ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden und in einer sicheren Standardkonfiguration betrieben werden.
• Schwachstellenmanagement über den Supportzeitraum: Sicherheitsupdates müssen während des festgelegten Supportzeitraums kostenlos und – wo technisch möglich – getrennt von Funktionsupdates bereitgestellt werden. Der Supportzeitraum beträgt in der Regel mindestens fünf Jahre, oder die erwartete Produktlebensdauer, falls diese kürzer ist.
• Software Bill of Materials (SBOM): Hersteller müssen eine maschinenlesbare Stückliste aller enthaltenen Softwarekomponenten und Abhängigkeiten erstellen und aktuell halten – mindestens auf Ebene der Top-Level-Abhängigkeiten.
• Meldepflichten und Konformitätsnachweis: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind zu melden; das Produkt trägt nach bestandener Konformitätsbewertung die CE-Kennzeichnung, gestützt auf eine technische Dokumentation und eine EU-Konformitätserklärung.

Bei Verstössen gegen die grundlegenden Anforderungen und die Meldepflichten drohen Bussen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist. Der praktisch schwerwiegendere Effekt ist jedoch der Verlust des EU-Marktzugangs: Ohne Konformität darf das Produkt schlicht nicht mehr angeboten werden.

Wer in der Schweiz betroffen ist

Der CRA knüpft an die Rolle im Markt an, nicht an die Staatszugehörigkeit. Für Schweizer Unternehmen ergeben sich vier typische Konstellationen:

• Direkter EU-Vertrieb: Sie bringen Software, Hardware oder IoT-Produkte in der EU in Verkehr – über eigene Kanäle, App Stores oder Marktplätze. Sie sind Hersteller im Sinne des CRA und benötigen in der Regel einen EU-Bevollmächtigten.
• Zulieferung: Sie liefern Komponenten, Firmware oder Softwaremodule an Hersteller, die in der EU verkaufen. Formal sind Sie nicht Adressat der Verordnung, faktisch werden SBOM-, Offenlegungs- und Supportzusagen vertraglich an Sie durchgereicht.
• Eigenmarke und wesentliche Änderung: Wer ein fremdes Produkt unter eigenem Namen vertreibt oder es wesentlich verändert, wird selbst zum Hersteller mit dem vollen Pflichtenprogramm.
• Import und Handel in Richtung EU: Auch Importeure und Händler tragen Prüf- und Sorgfaltspflichten.

Ein rein binnenschweizerischer Vertrieb ohne EU-Bezug fällt heute nicht unter den CRA. Diese Ausgangslage ist allerdings zeitlich begrenzt – dazu weiter unten mehr.

Der wichtige Sonderfall Cloud und SaaS

Für Anbieter, die «nur Software as a Service» betreiben, lohnt eine genaue Prüfung, denn hier wird der Anwendungsbereich häufig falsch eingeschätzt. Reine Cloud-Dienste ohne installierbare Komponente fallen grundsätzlich nicht unter den CRA, sondern unter die NIS-2-Richtlinie. Zwei Konstellationen ziehen ein SaaS-Angebot jedoch in den Anwendungsbereich hinein:

Erstens ist jedes ausgelieferte installierbare Artefakt ein eigenständiges Produkt mit digitalen Elementen – der Desktop-Client, die Mobile App, das CLI-Werkzeug, die Browser-Erweiterung, der lokale Agent oder eine Self-Hosted-Variante für Enterprise-Kunden.

Zweitens erfasst der CRA sogenannte Fernverarbeitungslösungen. Eine Cloud-Komponente wird gemeinsam mit dem Produkt bewertet, wenn zwei Bedingungen kumulativ vorliegen: Die Software wurde vom Hersteller selbst oder unter dessen Verantwortung entwickelt, und das Produkt könnte ohne sie eine seiner Funktionen nicht erfüllen. Ein vernetztes Gerät, dessen Kernfunktion vom herstellereigenen Backend abhängt, zieht dieses Backend also in die Bewertung hinein.

Unterschiede: CRA vs. NIS-2

CRA und NIS-2 werden regelmässig verwechselt, adressieren aber unterschiedliche Ebenen: Der CRA reguliert Produkte, NIS-2 reguliert Organisationen. Beide können gleichzeitig gelten – ein Maschinenbauer kann als Betreiber NIS-2-pflichtig und als Hersteller CRA-pflichtig sein.

Die praktische Konsequenz für Schweizer Unternehmen

Für die meisten Schweizer KMU ist der CRA der relevantere der beiden Rechtsakte, weil er ohne EU-Niederlassung greift. NIS-2 wirkt dagegen typischerweise mittelbar: Ihre EU-Kunden sind NIS-2-pflichtig und geben ihre Lieferkettenanforderungen vertraglich an Sie weiter. In der Praxis erreichen viele Schweizer Zulieferer die Regulierung deshalb zuerst über einen Fragebogen ihres Kunden – nicht über eine Behörde.

Zeitplan: die Fristen im Überblick

Der CRA wird gestaffelt wirksam. Entscheidend für die Planung ist, dass die Meldepflichten deutlich vor der Vollanwendung greifen und einen anderen Geltungsbereich haben.

Der 11. September 2026 wird in der Praxis regelmässig unterschätzt. Anders als die Herstellerpflichten ab Dezember 2027, die nur für neu in Verkehr gebrachte Produkte gelten, erfassen die Meldepflichten Ihr gesamtes heutiges Portfolio. Ein 2021 ausgeliefertes Gerät, das noch im Feld ist, löst also ab diesem Datum eine 24-Stunden-Meldepflicht aus, sobald eine Schwachstelle aktiv ausgenutzt wird.

Die dreistufige Meldekette

Die Fristen laufen ab Kenntnisnahme:

• 24 Stunden – Frühwarnung: erste Meldung an das zuständige CSIRT und die ENISA, auch bei unvollständiger Faktenlage.
• 72 Stunden – Schwachstellenmeldung: Angaben zur Schwachstelle, zu ergriffenen Gegenmassnahmen und zur Betroffenheit.
• 14 Tage – Abschlussbericht: abschliessende Beschreibung inklusive Behebung. Bei schwerwiegenden Sicherheitsvorfällen gilt für den Abschlussbericht ein Monat.

Gemeldet wird über eine zentrale, von der ENISA betriebene Meldeplattform, deren Betriebsbereitschaft auf den 11. September 2026 angekündigt ist. Welches CSIRT zuständig ist, richtet sich nach Artikel 14 Absatz 7 CRA – massgeblich ist der Mitgliedstaat, in dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden. Für Schweizer Hersteller ohne EU-Niederlassung führt das zwingend über den EU-Bevollmächtigten, dessen Bestimmung deshalb keine Formalie ist, sondern eine Voraussetzung für die Meldefähigkeit.

Zwei Erleichterungen sind zu beachten: Nach der Berichtigung des CRA vom 2. Juli 2025 werden Kleinst- und Kleinunternehmen nicht mit Bussen belegt, wenn sie die 24-Stunden-Frist für die Frühwarnung versäumen. Und am 27. Juli 2026 hat die EU-Kommission einen über 80-seitigen Praxisleitfaden mit 67 Anwendungsbeispielen veröffentlicht, der insbesondere Abgrenzungsfragen zu Fernverarbeitungslösungen, Open Source und Supportzeiträumen klärt.

Die Schweizer Parallelentwicklung

Am 20. August 2025 hat der Bundesrat das Bundesamt für Cybersicherheit (BACS) beauftragt, gemeinsam mit dem BAKOM und dem SECO bis Herbst 2026 eine Vernehmlassungsvorlage zur «Schaffung einer Gesetzgebung zur Cyberresilienz von digitalen Produkten» zu erarbeiten. Die Vorlage soll sich ausdrücklich am internationalen Kontext und namentlich am EU-CRA orientieren, den administrativen Aufwand für Unternehmen aber möglichst tief halten. Vorgesehen sind Sicherheitsanforderungen an digitale Produkte, eine Marktüberwachung sowie Grundlagen für ein Import- und Vertriebsverbot unsicherer Geräte.

Für Schweizer Hersteller bedeutet das eine regulatorische Doppelwelle: EU-CRA jetzt, ein Schweizer Pendant voraussichtlich ab 2027 oder 2028. Wer die CRA-Logik heute aufbaut, arbeitet für beide Regelwerke.

Davon zu unterscheiden ist die bereits geltende Meldepflicht nach dem Informationssicherheitsgesetz (ISG): Seit dem 1. April 2025 müssen Betreiberinnen kritischer Infrastrukturen Cyberangriffe innerhalb von 24 Stunden dem BACS melden, mit einer Nachfrist von 14 Tagen zur Vervollständigung. Seit dem 1. Oktober 2025 sind Bussen bis 100'000 Franken vorgesehen. Diese Pflicht knüpft an den Betrieb kritischer Infrastruktur an, nicht an das Produkt – sie ersetzt die CRA-Meldepflicht also nicht, sondern kann parallel bestehen.

Selbst-Check: Sind Sie betroffen?

Beantworten Sie die folgenden fünf Fragen. Ein «Ja» bei den Fragen 1 bis 3 begründet in der Regel eine Betroffenheit.

1. Bieten Sie ein Produkt an, das Daten mit einem Gerät oder Netzwerk austauschen kann – Hardware, Software, Firmware, App oder Erweiterung?
2. Erreicht dieses Produkt den EU- oder EWR-Markt, direkt oder über Distributoren, Marktplätze oder App Stores?
3. Liefern Sie eine installierbare Komponente, eine Self-Hosted-Variante oder ein Backend aus, ohne das Ihr Produkt eine seiner Funktionen nicht erfüllen könnte?
4. Vertreiben Sie fremde Produkte unter eigener Marke oder verändern Sie diese wesentlich?
5. Beliefern Sie Hersteller, die in der EU verkaufen, mit Software- oder Hardwarekomponenten?

Wer bei Frage 4 zustimmt, ist selbst Hersteller. Wer nur bei Frage 5 zustimmt, ist formal nicht Adressat, wird die Anforderungen aber vertraglich übernehmen müssen.

Schritt für Schritt: Was Schweizer Unternehmen jetzt tun sollten

Schritt 1 – Produktinventar erstellen und Betroffenheit dokumentieren

Listen Sie sämtliche Produkte, Varianten und Auslieferungsartefakte auf. Jedes einzelne Artefakt ist eine eigene Prüfeinheit – der Agent, das CLI, die App, die Firmware-Variante. Halten Sie je Produkt fest, ob es den EU-Markt erreicht und über welchen Kanal. Diese Dokumentation ist die Grundlage jeder späteren Diskussion mit Kunden, Auditoren und Behörden.

Schritt 2 – Rolle und Risikoklasse bestimmen

Klären Sie je Produkt Ihre Rolle: Hersteller, Importeur, Händler oder Open-Source-Steward. Ordnen Sie anschliessend die Risikoklasse ein – Standardprodukte durchlaufen eine Selbstbewertung, «wichtige» Produkte der Klassen I und II sowie «kritische» Produkte unterliegen strengeren Konformitätsbewertungsverfahren, teilweise unter Einbezug einer notifizierten Stelle. Die Klasse bestimmt Aufwand und Vorlaufzeit ganz erheblich.

Schritt 3 – EU-Bevollmächtigten benennen

Ohne Niederlassung in der EU benötigen Sie in aller Regel einen Bevollmächtigten in der Union. Dieser Schritt hat Priorität, weil er die Zuständigkeit des CSIRT bestimmt und damit Voraussetzung dafür ist, dass Sie ab dem 11. September 2026 überhaupt meldefähig sind.

Schritt 4 – CVD-Kontaktstelle einrichten und publizieren

Der CRA verlangt eine Anlaufstelle für Coordinated Vulnerability Disclosure, und zwar ebenfalls ab dem 11. September 2026 und auch für Bestandsprodukte. Praktisch bedeutet das: eine öffentlich auffindbare Sicherheitsseite auf Ihrer Domain, eine security.txt nach RFC 9116, eine überwachte Mailbox wie security@ihredomain.ch und eine dokumentierte Reaktionszeit. Diese Kontaktstelle muss auch dann funktionieren, wenn Ihr Marketing-Team im Sommerurlaub ist.

Schritt 5 – Meldeprozess operativ machen

Eine 24-Stunden-Frist lässt sich nicht improvisieren. Legen Sie fest, wer meldet, wer ausserhalb der Bürozeiten erreichbar ist, wer die Meldung freigibt und in welcher Rechtsform sie erfolgt. Halten Sie Meldetextbausteine bereit und üben Sie den Ablauf mindestens einmal. Der organisatorische Teil – Zuständigkeit, Eskalationspfad, Vollmacht – ist erfahrungsgemäss schwieriger als der technische.

Schritt 6 – SBOM aufbauen

Erzeugen Sie für jedes Produkt eine maschinenlesbare Stückliste in einem etablierten Format wie CycloneDX oder SPDX, mindestens auf Ebene der direkten Abhängigkeiten. Verankern Sie die Erzeugung in der Build-Pipeline, nicht in einem manuellen Prozess – eine SBOM, die nur zum Auditzeitpunkt existiert, erfüllt ihren Zweck nicht. Sie brauchen sie im Ernstfall, um innerhalb von Stunden zu beantworten, welche Ihrer Produkte eine neu bekannt gewordene Schwachstelle enthalten.

Schritt 7 – Supportzeitraum festlegen und kommunizieren

Bestimmen Sie je Produkt den Supportzeitraum – in der Regel mindestens fünf Jahre – und kommunizieren Sie ihn klar gegenüber Kunden. Stellen Sie sicher, dass Sie Sicherheitsupdates während dieser Zeit kostenlos und getrennt von Funktionsupdates ausliefern können. Das ist keine Dokumentationsfrage, sondern eine Architekturfrage: Ein Produkt ohne funktionierenden Update-Kanal ist über fünf Jahre nicht supportfähig.

Schritt 8 – Security by Design in den Entwicklungsprozess verankern

Integrieren Sie Threat Modeling, sichere Standardkonfigurationen und Schwachstellentests in Ihren Software Development Life Cycle. Prüfen Sie insbesondere die Klassiker, die in Audits regelmässig auffallen: fest kodierte Passwörter, Standard-Benutzernamen, offene Debug-Schnittstellen und unverschlüsselte Kommunikationswege.

Schritt 9 – Technische Dokumentation und Konformitätsbewertung vorbereiten

Bis zum 11. Dezember 2027 müssen technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung vorliegen. Für Produkte, die eine notifizierte Stelle benötigen, sollten Sie Kapazitäten frühzeitig reservieren – der Markt für Konformitätsbewertungsstellen wird gegen Ende der Frist voraussichtlich eng.

Schritt 10 – Die Schweizer Vorlage beobachten

Verfolgen Sie die für Herbst 2026 angekündigte Vernehmlassungsvorlage des BACS. Wer heute CRA-konform aufgestellt ist, wird für das Schweizer Pendant nur noch Delta-Arbeit leisten müssen. Wer wartet, macht die Arbeit zweimal.

Häufige Fragen zum Cyber Resilience Act

Gilt der Cyber Resilience Act für Schweizer Unternehmen?

Ja. Der CRA gilt für alle Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden – unabhängig vom Sitz des Herstellers. Schweizer Unternehmen, die in die EU liefern, unterliegen denselben Pflichten wie EU-Unternehmen und benötigen in der Regel zusätzlich einen EU-Bevollmächtigten. Ein rein binnenschweizerischer Vertrieb ohne EU-Bezug fällt derzeit nicht unter den CRA.

Was ist der Unterschied zwischen CRA und NIS-2?

Der CRA reguliert Produkte, NIS-2 reguliert Organisationen. Der CRA ist eine unmittelbar geltende Verordnung und adressiert Hersteller, Importeure und Händler von Produkten mit digitalen Elementen. NIS-2 ist eine Richtlinie, die von den Mitgliedstaaten in nationales Recht überführt wird und Betreiber wesentlicher und wichtiger Einrichtungen in 18 Sektoren verpflichtet. Beide Regelwerke können auf dasselbe Unternehmen gleichzeitig anwendbar sein.

Ab wann gilt die CRA-Meldepflicht?

Ab dem 11. September 2026. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden als Frühwarnung melden, innerhalb von 72 Stunden eine vollständige Meldung nachreichen und innerhalb von 14 Tagen einen Abschlussbericht liefern. Die Meldepflicht gilt auch für Produkte, die bereits vor diesem Datum in Verkehr gebracht wurden.

Fällt SaaS unter den Cyber Resilience Act?

Überwiegend nicht. Reine Cloud-Dienste ohne installierbare Komponente unterliegen NIS-2, nicht dem CRA. Sobald Sie jedoch ein installierbares Artefakt ausliefern – Desktop-Client, Mobile App, CLI-Werkzeug, Browser-Erweiterung, lokaler Agent oder Self-Hosted-Variante –, ist diese Komponente ein Produkt mit digitalen Elementen. Zusätzlich werden Fernverarbeitungslösungen mitbewertet, wenn das Produkt ohne sie eine seiner Funktionen nicht erfüllen könnte.

Wie hoch sind die Bussen bei Verstössen gegen den CRA?

Bei Verstössen gegen die grundlegenden Anforderungen und die Meldepflichten drohen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für andere Pflichtverstösse und für unrichtige Angaben gelten niedrigere Rahmen. Nach der Berichtigung vom 2. Juli 2025 werden Kleinst- und Kleinunternehmen bei Versäumnis der 24-Stunden-Frühwarnfrist nicht mit Bussen belegt.

Plant die Schweiz ein eigenes Cyberresilienzgesetz?

Ja. Der Bundesrat hat am 20. August 2025 das BACS beauftragt, zusammen mit BAKOM und SECO bis Herbst 2026 eine Vernehmlassungsvorlage für eine Gesetzgebung zur Cyberresilienz digitaler Produkte zu erarbeiten. Die Vorlage soll sich am EU-CRA orientieren und den Aufwand für Unternehmen möglichst tief halten.

Ersetzt die Schweizer ISG-Meldepflicht die CRA-Meldung?

Nein. Die Meldepflicht nach dem Informationssicherheitsgesetz gilt seit dem 1. April 2025 für Betreiberinnen kritischer Infrastrukturen und knüpft an den Betrieb an, nicht an das Produkt. Sie verlangt eine Meldung an das BACS innerhalb von 24 Stunden nach Entdeckung eines Cyberangriffs. Die CRA-Meldepflicht richtet sich dagegen an Hersteller und geht an das zuständige CSIRT sowie die ENISA. Beide können nebeneinander bestehen.

Die passende Infrastruktur für CRA-konforme Prozesse

Der CRA verlangt keine bestimmte Hosting-Architektur – und Schweizer Rechenzentren befreien niemanden von der Verordnung. Sehr wohl aber verlangt er Prozesse, die technisch unterlegt sein müssen. Drei davon scheitern in der Praxis regelmässig nicht am Wissen, sondern an fehlender Infrastruktur:

Die Erreichbarkeit Ihrer CVD-Kontaktstelle. Die Meldestelle für Sicherheitsforscher muss ab dem 11. September 2026 öffentlich auffindbar und dauerhaft erreichbar sein. Das setzt eine stabile Domain, eine zuverlässig zustellende Mailbox und eine verlässlich verfügbare Sicherheitsseite voraus. Mit einer .ch- oder .swiss-Domain, professionellen E-Mail-Adressen und Hosting aus Schweizer Rechenzentren richten Sie diese Anlaufstelle so ein, dass sie im Ernstfall trägt. Der vorgeschaltete MX-Filter Spamfilter sorgt dabei dafür, dass eine echte Schwachstellenmeldung nicht zwischen automatisierten Anfragen untergeht – bei einer 24-Stunden-Frist ist eine übersehene Mail ein regulatorisches Problem.

Reproduzierbare Build- und Testumgebungen für Ihre SBOM. Eine belastbare Software Bill of Materials entsteht in der Pipeline, nicht in der Tabellenkalkulation. Dafür brauchen Sie dedizierte, isolierte Umgebungen für Build, Test und Staging. Ein VPS eignet sich für einzelne Build-Runner und abgegrenzte Testumgebungen, ein Managed Cloud Server nimmt Ihnen den Betrieb ab, wenn Ihr Team seine Kapazität in der Produktentwicklung braucht statt in der Systemadministration. Für Hersteller mit mehreren Produktlinien und getrennten Mandanten bietet das Virtual Data Center die nötige Segmentierung bei planbaren Ressourcen.

Update-Disziplin auf den Systemen, die Sie selbst betreiben. Der CRA fordert von Ihnen Sicherheitsupdates über den gesamten Supportzeitraum. Diese Erwartung an sich selbst wird unglaubwürdig, wenn die eigene Website oder das Kundenportal auf einer veralteten Installation läuft. Managed WordPress Hosting nimmt Ihnen die Update-Routine für Core und Umgebung ab; für individuelle Anwendungen bieten unsere Server-Lösungen die Kontrolle über Patch-Stände, PHP-Versionen und Zugriffswege, die Sie für eine dokumentierte Sicherheitsarchitektur benötigen.

Unser Support in Zürich beantwortet technische Rückfragen zu Konfiguration, Zugriffskonzepten und Betriebsarchitektur direkt und ohne Ticket-Schleifen – auf Augenhöhe mit Ihrem Entwicklungsteam.