CRA erklärt

Was ist der Cyber Resilience Act? Ein Überblick für KMU.

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die seit dem 10. Dezember 2024 in Kraft ist. Sie verpflichtet Hersteller von Software und vernetzter Hardware, grundlegende Cybersicherheitsanforderungen zu erfüllen — von der Produktentwicklung über das Schwachstellenmanagement bis hin zu Meldepflichten.

Das Wichtigste in 60 Sekunden

  • Inkrafttreten: 10. Dezember 2024 (Art. 71 Abs. 1 CRA — 20 Tage nach Veröffentlichung im Amtsblatt am 20.11.2024).
  • Meldepflichten: ab 11. September 2026 (Art. 71 Abs. 2 CRA i. V. m. Art. 14).
  • Vollanwendung: ab 11. Dezember 2027 (Art. 71 Abs. 2 CRA — Hauptregel; Abs. 3 enthält Übergangsbestimmungen für vor diesem Datum in Verkehr gebrachte Produkte).
  • Bussgelder: ab 11.12.2027 bis zu €15 Mio oder 2,5 % des weltweiten Jahresumsatzes (Art. 64 Abs. 2 CRA). Kleinst- und Kleinunternehmen sind für die 24-h-Frühwarnung nach Art. 64 Abs. 10 lit. a CRA von Bussgeldern ausgenommen.
  • Geltungsbereich: alle Produkte mit digitalen Elementen, die in der EU bereitgestellt werden.

Warum gibt es den CRA?

Der überwiegende Teil der Software- und Hardwareprodukte auf dem EU-Markt erfüllte keine grundlegenden Cybersicherheitsanforderungen. Es gab keine horizontale EU-Gesetzgebung für einheitliche Mindeststandards. Die Zahl der Cyberangriffe auf Lieferketten hat dramatisch zugenommen — wie der Log4Shell-Vorfall Ende 2021 eindrücklich gezeigt hat.

Im März 2024 folgte die XZ Utils Backdoor — der „neue Log4Shell". Ein gezielter Supply-Chain-Angriff auf eine weitverbreitete Open-Source-Bibliothek hätte Millionen Linux-Systeme kompromittieren können. Der Angriff war auf Monate angelegt und zeigt: Lieferkettensicherheit ist keine abstrakte Anforderung — sie ist bereits gängige Angriffspraxis.

Im Juli 2024 lähmte ein fehlerhaftes CrowdStrike-Update 8,5 Millionen Windows-Systeme weltweit — der grösste IT-Ausfall der Geschichte. Auslöser war ein Sicherheits-Update ohne ausreichende Tests. Genau solche Szenarien will der CRA mit verpflichtenden Schwachstellen-Prozessen, Tests und Update-Disziplin verhindern.

Wer ist betroffen?

Kurz: Fast jedes Softwareunternehmen, das in der EU verkauft. Im Detail:

  • Hersteller von Software-Anwendungen (Desktop, Web, Mobile)
  • Hersteller eingebetteter Software / Firmware
  • Hersteller von Hardware mit Software-Komponenten (IoT, Steuerung, Sensorik)
  • Anbieter lokaler Agents/Clients/Plugins
  • Anbieter von APIs/SDKs, die in EU-Produkte eingebettet werden
  • Open-Source-Software-Betreuer (mit kommerziellem Geschäft)

Nicht als RDPS erfasst sind rein interne Software und reine Cloud-Dienste ohne Datenfernverarbeitung im Sinne der RDPS-Definition. Auch ohne RDPS-Eigenschaft können nach Art. 13 Abs. 5–8 CRA abgestufte Pflichten greifen — insbesondere Due-Diligence für Drittkomponenten und Risikobewertung für nicht-funktionale Datenverbindungen. Die Abgrenzung ist nicht trivial — siehe unsere Artikel zu RDPS und SaaS & CRA.

Was verlangt der CRA konkret?

Mit Quellenzuordnung zu Anhang/Artikel der Verordnung (EU) 2024/2847.

  1. Cybersicherheits-Risikobeurteilung — Art. 13 Abs. 2 CRA
  2. Keine bekannten Schwachstellen bei Marktbereitstellung — Anhang I Teil I Nr. 1
  3. Sichere Standardeinstellungen + Reset — Anhang I Teil I Nr. 3
  4. Automatische Sicherheits-Updates mit Opt-out — Anhang I Teil I Nr. 5
  5. Schutz vor unbefugtem Zugriff — Anhang I Teil I Nr. 4
  6. Verschlüsselung at rest und in transit — Anhang I Teil I Nr. 6
  7. Datenintegrität — Anhang I Teil I Nr. 7
  8. Datenminimierung — Anhang I Teil I Nr. 8
  9. DoS-Resilienz — Anhang I Teil I Nr. 9
  10. Reduktion der Angriffsfläche — Anhang I Teil I Nr. 10
  11. Eindämmung von Vorfällen — Anhang I Teil I Nr. 11
  12. Logging sicherheitsrelevanter Vorgänge — Anhang I Teil I Nr. 12
  13. Sichere Datenlöschung und -übertragung — Anhang I Teil I Nr. 13
  14. SBOM in maschinenlesbarem Format — Anhang I Teil II Nr. 1
  15. Schwachstellenbehandlung mit getrennten Sicherheits-Updates — Anhang I Teil II Nr. 2
  16. Regelmässige Sicherheitstests — Anhang I Teil II Nr. 3
  17. Veröffentlichung beseitigter Schwachstellen — Anhang I Teil II Nr. 4
  18. Coordinated Vulnerability Disclosure-Strategie — Anhang I Teil II Nr. 5
  19. Kontaktadresse für Schwachstellenmeldungen — Anhang I Teil II Nr. 6
  20. Sichere Update-Distribution — Anhang I Teil II Nr. 7
  21. Kostenlose Sicherheits-Updates — Anhang I Teil II Nr. 8
  22. Anhang-VII-Dokumentation einschliesslich Risikoanalyse — Art. 31, Anhang VII CRA
  23. EU-Konformitätserklärung nach Anhang V — Art. 28, Anhang V CRA
  24. CE-Kennzeichnung — Art. 30 CRA
  25. Klare Nutzeranweisungen nach Anhang II — Art. 13 Abs. 18, Anhang II CRA
  26. Meldepflichten 24h/72h/14 Tage — Art. 14 CRA
  27. Information betroffener Nutzer über Schwachstellen und Vorfälle — Art. 13 Abs. 8, Anhang I Teil II Nr. 4

Was sollten Sie jetzt tun?

1

Klassifizieren

Prüfen Sie, ob Ihr Produkt unter den CRA fällt — nutzen Sie unseren kostenlosen CRA-Quick-Check.

2

SBOM beginnen

Eine Software-Stückliste ist Pflicht (Anhang I Teil II Nr. 1) und Grundlage für vieles weitere.

3

Meldepflichten einplanen

Ab September 2026 läuft die 24-Stunden-Uhr (Art. 14 CRA).

Zum kostenlosen CRA-Quick-Check →