Das ist ein Irrtum.
Wenn euer Unternehmen ein Produkt mit digitalen Elementen herstellt, importiert oder vertreibt, das auf dem EU-Markt landet, und das trifft auf überraschend viele Schweizer Firmen zu, dann gelten ab September 2026 Meldepflichten und ab Dezember 2027 sämtliche Anforderungen des CRA. Inklusive Bussen von bis zu 15 Millionen Euro.
In diesem Artikel ordnen wir ein, was der CRA für Schweizer Unternehmen bedeutet, ohne Panikmache, aber mit der nötigen Klarheit.
Der Cyber Resilience Act (EU-Verordnung 2024/2847) ist die erste EU-weite Regulierung, die verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen vorschreibt. Nicht nur für kritische Infrastruktur. Nicht nur für Medizingeräte. Für alles, was Software enthält und kommuniziert.
Jedes Hardware- oder Softwareprodukt, das direkt oder indirekt mit anderen Systemen kommuniziert. Die Kommunikation kann über Netzwerk, USB, Bluetooth, WLAN, NFC oder andere Schnittstellen erfolgen.
Konkret:
Der CRA gilt nicht nach Firmensitz, sondern nach Markt. Entscheidend ist: Wird das Produkt auf dem EU-Markt in Verkehr gebracht? Wenn ja, gelten die Regeln, egal ob der Hersteller in Zürich, Luzern oder Shanghai sitzt.
Für Schweizer Unternehmen, die in die EU exportieren, und das sind viele, ist der CRA kein fernes EU-Thema, sondern direkte Marktzugangsvoraussetzung.
Beantwortet diese vier Fragen:
1. Stellt ihr ein Produkt her, das Software enthält oder Software ist?
Das umfasst nicht nur physische Geräte. Auch eine reine SaaS-Plattform oder eine App kann betroffen sein, wenn sie als Produkt auf dem EU-Markt bereitgestellt wird.
2. Kommuniziert dieses Produkt mit anderen Systemen?
Über das Internet, API, Bluetooth, USB: jede Form der Datenübertragung zählt.
3. Wird dieses Produkt auf dem EU-Markt angeboten?
Direkt oder über Distributoren, Importeure, Händler, auch indirekt.
4. Fällt euer Produkt unter keine der Ausnahmen?
Ausgenommen sind unter anderem: Medizinprodukte (eigene Regulierung), Kraftfahrzeuge, Produkte für militärische Zwecke, und Open-Source-Software, die nicht kommerziell vertrieben wird.
Viermal Ja? Dann seid ihr betroffen.
Und "betroffen" heisst nicht "vielleicht irgendwann relevant". Es heisst: Ab September 2026 müsst ihr Sicherheitsvorfälle innerhalb von 24 Stunden melden. Ab Dezember 2027 müsst ihr alle Anforderungen erfüllen, oder euer Produkt darf nicht mehr auf den EU-Markt.
Der CRA definiert keine vagen Prinzipien, sondern konkrete Pflichten. Die wichtigsten:
Cybersicherheit muss von Anfang an integraler Bestandteil der Produktentwicklung sein. Nicht als nachträglicher Audit, nicht als Checkliste vor dem Release, sondern als Teil jeder Architektur-Entscheidung, jeder Code-Review, jeder Deployment-Pipeline.
Konkret bedeutet das:
Ihr müsst einen dokumentierten Prozess betreiben, um Schwachstellen zu identifizieren, zu melden und zu beheben. Sicherheitsupdates müssen kostenlos bereitgestellt werden, während der gesamten erwarteten Nutzungsdauer des Produkts.
Ihr müsst dokumentieren, welche Komponenten in eurem Produkt stecken, inklusive Drittanbieter-Bibliotheken und Open-Source-Abhängigkeiten. Wer schon einmal ein composer.lock oder package-lock.json gesehen hat, kennt die Idee. Der CRA macht daraus eine Pflicht.
Bei aktiv ausgenutzten Schwachstellen:
Bei schwerwiegenden Sicherheitsvorfällen gelten ähnliche Fristen, plus eine Pflicht zur Information der betroffenen Nutzer.
Je nach Risikoklasse eures Produkts:
Die meisten KMU-Softwareprodukte fallen in die Kategorie Standardprodukte oder Klasse I: Selbstdeklaration ist also realistisch, wenn ihr eure Prozesse im Griff habt.
Datum
| Was passiert
|
|---|---|
| 20.11.2024 | CRA veröffentlicht und in Kraft |
| 11.09.2026 | Meldepflichten gelten, ihr müsst Sicherheitsvorfälle innerhalb von 24h melden können |
| 11.12.2027 | Alle Anforderungen gelten, volle Konformität oder kein EU-Marktzugang |
Wir schreiben Juli 2026. Bis die Meldepflichten greifen, bleiben noch gut zwei Monate. Habt ihr einen Prozess, um aktiv ausgenutzte Schwachstellen in 24 Stunden an die ENISA zu melden? Falls nicht, wird es jetzt eng.
Bei Nichtkonformität drohen:
Das ist kein Papiertiger.
Die EU hat mit der DSGVO gezeigt, dass sie Bussen durchsetzt, und der CRA folgt demselben Muster.
Der CRA klingt nach Bürokratie. In der Praxis ist er vor allem ein Grund, Dinge zu tun, die ihr sowieso tun solltet, aber strukturiert und nachweisbar.
Von "wir machen schon Security" zu "wir können es beweisen"
Viele Entwicklungsteams haben ein implizites Sicherheitsverständnis. Code Reviews, Dependency-Updates, sichere Konfiguration: das passiert, aber undokumentiert. Der CRA verlangt den Nachweis: dokumentierte Prozesse, nachvollziehbare Entscheidungen, technische Dokumentation.
Von reaktiv zu proaktiv
Die meisten Unternehmen reagieren auf Sicherheitsvorfälle, wenn sie passieren. Der CRA verlangt, dass ihr aktiv sucht: regelmässige Schwachstellen-Scans, Penetrationstests, kontinuierliches Monitoring. Und dass ihr Schwachstellen behebt, bevor sie ausgenutzt werden.
Von "unser Code" zu "unsere gesamte Supply Chain"
Der CRA betrifft nicht nur euren eigenen Code. Er betrifft jede Bibliothek, jedes Framework, jede Open-Source-Komponente in eurem Produkt. Wenn eine Schwachstelle in einer Abhängigkeit auftaucht, seid ihr in der Pflicht, nicht der Maintainer des Open-Source-Pakets.
Gute Software-Entwicklung. Wer heute schon sauber arbeitet, hat den grössten Teil des Weges bereits hinter sich: Code Reviews, automatisierte Tests, Dependency-Management, sichere Deployment-Pipelines, Monitoring. Der CRA formalisiert, was gute Praxis sowieso ist.
1. Bestandsaufnahme machen
Welche eurer Produkte fallen unter den CRA? Welche haben digitale Elemente, die auf dem EU-Markt sind? Das klingt trivial, ist es aber oft nicht, besonders bei Unternehmen mit gewachsenem Produktportfolio.
2. Meldeprozess aufbauen (Priorität 1)
Die Meldepflichten greifen ab September 2026. Ihr braucht einen funktionierenden Prozess: Wer erkennt einen Vorfall? Wer meldet ihn? Über welchen Kanal? In welchem Format? Das lässt sich in wenigen Wochen aufsetzen, wenn ihr jetzt anfangt.
3. SBOM erstellen
Dokumentiert die Abhängigkeiten eurer Produkte. Welche Bibliotheken, welche Versionen, welche bekannten Schwachstellen? Tools dafür existieren (Syft, Trivy, Grype, Dependency-Track). Das ist kein Hexenwerk, aber es muss gemacht werden.
4. Entwicklungsprozesse prüfen
Security by Design ist kein Zusatzprojekt. Es ist eine Eigenschaft eures Entwicklungsprozesses. Prüft: Gibt es Code Reviews mit Security-Fokus? Automatisierte Schwachstellen-Scans in der CI/CD-Pipeline? Sichere Standardkonfigurationen? Dokumentierte Architektur-Entscheidungen?
5. Technische Dokumentation aufbauen
Der CRA verlangt eine nachvollziehbare technische Dokumentation. Nicht 500 Seiten, aber genug, um nachweisen zu können, dass ihr die Anforderungen kennt und umsetzt.
Panik. Der CRA ist anspruchsvoll, aber machbar. Besonders für Standardprodukte (Selbstdeklaration) ist der Aufwand überschaubar, wenn die Grundlagen stimmen.
Kein "CRA-Projekt" mit Big-Bang-Ansatz. Wer versucht, in 6 Monaten alles auf einmal umzusetzen, wird scheitern. Besser: schrittweise in den bestehenden Entwicklungsprozess integrieren. Meldeprozess zuerst, dann SBOM, dann Dokumentation.
Keine Angst vor dem SBOM. Es klingt kompliziert, ist aber im Kern ein automatisierter Export eurer Dependency-Dateien in einem standardisierten Format. Wenn eure Codebasis sauber gemanagt ist, ist das ein Tool-Setup, kein Projekt.
Der CRA ist kein bürokratisches Monster. Er ist eine Formalisierung von Dingen, die in einer professionellen Software-Entwicklung sowieso Standard sein sollten. Security by Design, Schwachstellenmanagement, transparente Abhängigkeiten, dokumentierte Prozesse.
Für Schweizer Unternehmen, die Produkte mit digitalen Elementen in die EU liefern, ist er aber auch eine harte Marktzugangsvoraussetzung mit konkreten Fristen und empfindlichen Sanktionen. Wer das ignoriert, riskiert nicht nur Bussen, sondern den Zugang zum wichtigsten Exportmarkt.
Die gute Nachricht: Wer schon heute mit einem Partner arbeitet, der Security als integralen Bestandteil der Entwicklung versteht, hat den grössten Teil des Weges bereits hinter sich. Nicht als Zusatzleistung, sondern als Arbeitsweise.
Und wer noch nicht so weit ist: Die Fristen sind eng, aber der Weg ist klar. Fangt mit dem Meldeprozess an. Der Rest kommt Schritt für Schritt.
Wir bauen seit über 20 Jahren geschäftskritische Plattformen. Security by Design ist dabei Selbstverständlichkeit. Als ISO-27001-zertifiziertes Team sind dokumentierte Sicherheitsprozesse, Schwachstellenmanagement und sichere Entwicklungspraktiken Teil unserer täglichen Arbeit.
"Wenn ihr unsicher seid, ob eure Produkte CRA-konform sind oder was euch noch fehlt: Ein erstes Gespräch schafft Klarheit, ehrlich und unverbindlich."
Im nächsten Schritt fragen wir dich noch nach deiner E-Mail Adresse.
Senden
Wir schaffen technisch hochstehende digitale Lösungen auf Basis von tiefem User-Verständnis – damit du in der digitalen Welt erfolgreich bist.
