EU CRA für Software und SaaS
Im eigenen Takt ausliefern, mit Nachweisen im selben Takt.
Desktop-Client, App, SDK, Backend, eigene Open-Source-Projekte: Softwarehersteller klären zuerst, was davon der Cyber Resilience Act als Produkt erfasst. Danach entscheidet der Release-Prozess, wie viel Dokumentation ein Update nach sich zieht.
Autor: Maximilian HeckGeprüft von: Dr. Martin McCafferyStand:
- Volle Anwendung
- 11. Dezember 2027
- Frühwarnung
- 24 Stunden · Art. 14 Abs. 2 a
- Unterstützungszeitraum
- mind. 5 Jahre · Art. 13 Abs. 8
- Höchste Klasse in dieser Branche
- Wichtiges Produkt, Klasse II
Welche Software ist ein Produkt mit digitalen Elementen im Sinne des EU Cyber Resilience Act?
Software ist ein Produkt mit digitalen Elementen im Sinne des EU Cyber Resilience Act, wenn der Hersteller sie dem Nutzer bereitstellt und sie auf dessen System läuft (Art. 3 Nr. 1 EU CRA; EU-Kommissions-Guidance (C(2026) 5252), Abschnitt 2.2). Darunter fallen Desktop-Clients, auch solche auf Basis von Web-Technologien, mobile Apps, Browser-Extensions, Kommandozeilen-Tools und SDKs. Voraussetzung ist eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz (Art. 2 Abs. 1).
Produktklassen
Welche Softwareprodukte fallen unter den EU CRA, und in welche Klasse?
Der EU CRA erfasst Software, die im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird, gegen Bezahlung oder kostenlos (Art. 3 Nr. 22). Als Hersteller gilt, wer die Software unter eigenem Namen oder eigener Marke vermarktet (Art. 3 Nr. 13). Die Zuordnungen sind eine Einschätzung anhand typischer Kernfunktionen.
Verteilung in dieser Branche
Produkt auswählen
Desktop-Client für Windows, macOS oder Linux, auch auf Electron-Basis
Warum diese Klasse
Keine Kategorie aus Anhang III oder IV; Selbstbewertung nach Art. 32 Abs. 1.
Konformitätsweg
- 1Risikobewertung
- 2Eigene Konformitätsbewertung (Modul A)
- EU-Konformitätserklärung + CE
Konformitätsbewertung in Eigenverantwortung, Art. 32 Abs. 1 EU CRA.
Einschätzung anhand typischer Kernfunktionen. Maßgeblich sind Zweckbestimmung und Aufbau Ihres Produkts.
Alle Produktbeispiele als Tabelle+
| Produkt | Klasse nach EU CRA | Begründung |
|---|---|---|
| Desktop-Client für Windows, macOS oder Linux, auch auf Electron-Basis | Standardprodukt | Keine Kategorie aus Anhang III oder IV; Selbstbewertung nach Art. 32 Abs. 1. |
| Mobile App, Browser-Extension oder Kommandozeilen-Tool | Standardprodukt | Keine Anhang-III-Kategorie, solange die Kernfunktion keiner entspricht. |
| SDK oder Bibliothek mit kommerzieller Lizenz | Standardprodukt | Getrennt in Verkehr gebrachte Komponente, Art. 3 Nr. 1. |
| Quellcode, den Kunden gegen Lizenzgebühr erhalten und selbst kompilieren | Standardprodukt | In Verkehr gebracht laut EU-Kommissions-Guidance, Abschnitt 2.3 (Beispiel 7). |
| Identitätsmanagement und Software für privilegierte Zugänge | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 1. |
| Passwort-Manager, auch als Open-Source-Projekt mit bezahltem Support | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 3; als freie und quelloffene Software mit den Verfahren der Standardklasse, wenn die technische Dokumentation öffentlich ist (Art. 32 Abs. 5). |
| VPN-Client, Anti-Malware-Software | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 5 und 4. |
| SIEM-System, Netzmanagement-Software | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 7 und 6; Modul A bei vollständig angewandter harmonisierter Norm (Art. 32 Abs. 2). |
| Betriebssystem, eigenständiger oder eingebetteter Browser | Wichtiges Produkt, Klasse I (Anhang III) | Anhang III Klasse I Nr. 11 und 2. |
| Hypervisor, Container-Runtime, Software-Firewall oder IDS/IPS | Wichtiges Produkt, Klasse II (Anhang III) | Anhang III Klasse II Nr. 1 und 2; Drittbewertung nach Art. 32 Abs. 3. Die Regeln zu notifizierten Stellen in Kapitel IV gelten seit dem 11. Juni 2026. |
Ihr Produkt ist nicht dabei? Die Reifegradanalyse gibt eine erste Einordnung für Ihr eigenes Produkt. EU-CRA-Assessment starten →
Anhang IV EU CRA enthält keine reine Softwarekategorie; kritische Produkte sind dort Hardware wie Chipkarten, Sicherheitselemente und Smart-Meter-Gateways. Eine Beta oder ein Release Candidate darf nach Art. 4 Abs. 3 mit sichtbarem Hinweis auf die fehlende Konformität für die Testdauer bereitgestellt werden.
Pflichten
Welche Pflichten hat ein Softwarehersteller unter dem EU Cyber Resilience Act?
- 01
Eine Stückliste für jede ausgelieferte Version
Anhang I Teil II Nr. 1 EU CRA verlangt, die Komponenten eines Produkts zu dokumentieren, unter anderem mit einer Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene erfasst.
- 02
Neue Bewertung nur bei verändertem Risiko
Art. 3 Nr. 30 EU CRA; EU-Kommissions-Guidance, Abschnitt 4.3
Eine wesentliche Änderung liegt nach Art. 3 Nr. 30 EU CRA vor, wenn ein Update die Erfüllung von Anhang I Teil I berührt oder die bewertete Zweckbestimmung ändert. Abschnitt 4.3 der EU-Kommissions-Guidance prüft das an vier Kriterien: neue Bedrohungsvektoren, neue Angriffsszenarien, veränderte Eintrittswahrscheinlichkeit, veränderte Auswirkung bekannter Szenarien. Sicherheitsupdates erfüllen sie in der Regel nicht, ein Remember-me-Login mit lokal gespeicherten Tokens dagegen schon (Beispiel 44).
- 03
Fixes dürfen sich auf die neueste Version beschränken
Der Unterstützungszeitraum beträgt nach Art. 13 Abs. 8 EU CRA mindestens fünf Jahre, kürzer nur bei voraussichtlich kürzerer Nutzung; sein Enddatum nennt der Hersteller beim Kauf mit mindestens Monat und Jahr (Abs. 19). Sobald wesentlich geänderte Nachfolgeversionen auf dem Markt sind, darf er Schwachstellen nur noch in der zuletzt in Verkehr gebrachten Version beheben, sofern Nutzer älterer Versionen diese kostenlos und ohne Zusatzkosten für ihre Hardware- und Softwareumgebung erhalten (Abs. 10).
- 04
Sorgfalt bei fremdem Code
Art. 13 Abs. 5 und 6 EU CRA; Erwägungsgrund 34
Wer Komponenten von Dritten integriert, auch nicht kommerziell bereitgestellte Open-Source-Bibliotheken, lässt nach Art. 13 Abs. 5 EU CRA die gebotene Sorgfalt walten. Erwägungsgrund 34 nennt dafür etwa die bisherigen Sicherheitsaktualisierungen und den Abgleich mit öffentlichen Schwachstellendatenbanken. Für die Konformität der Komponente selbst ist der integrierende Hersteller nicht verantwortlich (EU-Kommissions-Guidance, Abschnitt 3.4). Eine Schwachstelle in einer integrierten Komponente meldet er deren Maintainer und teilt seinen Fix (Abs. 6).
- 05
Frühwarnung binnen 24 Stunden
Art. 14 Abs. 1 und 2, Art. 69 Abs. 3 EU CRA
Eine aktiv ausgenutzte Schwachstelle meldet der Hersteller über die einheitliche Meldeplattform nach Art. 16 EU CRA gleichzeitig dem koordinierenden CSIRT und der ENISA (Art. 14 Abs. 1). Die Frühwarnung ist seit dem 11. September 2026 innerhalb von 24 Stunden nach Kenntnis fällig, die Meldung innerhalb von 72 Stunden, der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur (Art. 14 Abs. 2). Die Meldepflicht gilt nach Art. 69 Abs. 3 auch für Software, die vor dem 11. Dezember 2027 in Verkehr gebracht wurde.
Angrenzende Regulierung
Welche Regeln gelten neben dem EU CRA für Softwarehersteller?
NIS2-Richtlinie (EU) 2022/2555
Ein Unternehmen kann der NIS2 als Anbieter eines Cloud-Dienstes und zugleich dem EU CRA als Hersteller seiner Clients unterliegen. NIS2-Nachweise eines Cloud-Anbieters nach der Durchführungsverordnung (EU) 2024/2690 darf ein Hersteller für Dritt-Dienste wiederverwenden (EU-Kommissions-Guidance, Abschnitt 8.2).
DORA, Verordnung (EU) 2022/2554
Software im Finanzsektor kann zugleich unter DORA und den EU CRA fallen. DORA-Nachweise eines Dienstleisters zählen nach Abschnitt 8.2 der EU-Kommissions-Guidance ebenfalls zu den wiederverwendbaren Belegen.
Medizinprodukte, VO (EU) 2017/745 und 2017/746
Software, die als Medizinprodukt oder In-vitro-Diagnostikum unter eine dieser Verordnungen fällt, nimmt Art. 2 Abs. 2 a und b EU CRA aus dem Anwendungsbereich heraus.
KI-Verordnung (EU) 2024/1689
Wenn ein Softwareprodukt zugleich ein Hochrisiko-KI-System nach Art. 6 KI-VO ist, gilt es bei den Cybersicherheitsanforderungen aus Art. 15 KI-VO als konform, sofern es Anhang I des EU CRA erfüllt und die EU-Konformitätserklärung das belegt (Art. 12 Abs. 1).
Aus der Praxis
Woran Softwareteams in der Umsetzung hängen bleiben
Funktionen hinter Feature-Flags
Wer Funktionen dunkel ausliefert und später per Feature-Flag freischaltet, braucht sie schon in der ursprünglichen Risikobewertung. Nur dann löst das Freischalten laut EU-Kommissions-Guidance (Abschnitt 4.3, Beispiele 42 und 43) keine wesentliche Änderung aus. Fehlt die Funktion dort, wird das Freischalten an denselben vier Kriterien gemessen wie ein neues Feature.
Die Produktgrenze wandert mit der Architektur
Mit einem Desktop-Wrapper oder einer Browser-Extension wird aus einer Web-App ein Produkt, wo vorher keines war. Wenn Logik vom Client ins Backend wandert, verschiebt sich, was als Datenfernverarbeitung in die Dokumentation gehört.
Abhängigkeiten, die niemand mehr pflegt
Wenn eine transitive Abhängigkeit aus einem verwaisten Projekt stammt, fehlt für die Meldung nach Art. 13 Abs. 6 EU CRA der Empfänger. Den Fix baut dann das eigene Team und trägt ihn als Fork weiter, über alle Releases des Unterstützungszeitraums.
Dritt-SaaS im eigenen Produkt
Login-Anbieter, Zahlungsdienst oder Support-Chat eines Dritten sind keine Datenfernverarbeitung des Herstellers; laut EU-Kommissions-Guidance (Abschnitt 8.1) behandelt er sie wie Dritt-Komponenten. Sobald der Anbieter seinen Dienst ändert, muss die Risikobewertung nachziehen (Abschnitt 8.2). Davon erfährt der Hersteller nur, wenn der Vertrag eine Informationspflicht vorsieht.
Mit Kunnus
Wie Kunnus Softwarehersteller unterstützt
Kunnus deckt die EU-CRA-Schicht der Konformität ab. Pflichten aus NIS2 oder DORA bleiben in den Prozessen, die Sie dafür bereits haben.
Rechenbeispiel
Wie viele Nachweisstände erzeugt ein Software-Portfolio im Jahr?
Angenommen, ein Softwarehersteller baut aus einer Codebasis sieben lokal laufende Artefakte und ein gemeinsames Backend und liefert alle zwei Wochen aus.
- 1ArtefakteDesktop-Client für Windows, macOS und Linux, Apps für iOS und Android, ein Kommandozeilen-Tool, eine Browser-Extension
- 2Produkte7, weil Builds je Betriebssystem als eigenständige Produkte zählen (EU-Kommissions-Guidance, Abschnitt 2.1)
- 3Backend1 Dossier, deklariert in allen 7 Produktdokumentationen (Abschnitt 8.2)
- 4Nicht im DossierNutzungstelemetrie für Statistik, CI/CD-Pipeline und CRM (Abschnitt 8.1)
- 5Pro Jahr7 Produkte × 26 Releases = 182 Stücklisten und 182 dokumentierte Antworten auf die Prüffrage zur wesentlichen Änderung
- 6Über den Unterstützungszeitraum910 Stücklisten in 5 Jahren, der Mindestdauer nach Art. 13 Abs. 8
Beispiel mit angenommenen Zahlen, keine Marktdaten.
Häufige Fragen
Wann fällt eine SaaS-Lösung unter den EU CRA?+
Für SaaS als Cloud-Dienstmodell verweist Erwägungsgrund 12 auf die NIS2-Richtlinie (EU) 2022/2555, die Anbieter ab der Größe eines mittleren Unternehmens erfasst. Ein kleinerer Anbieter, der nur einen Cloud-Dienst betreibt, fällt womöglich unter keine der beiden Regelungen. In den Anwendungsbereich gerät eine SaaS, sobald der Anbieter dazu Software ausliefert, die beim Kunden läuft und auf den Dienst angewiesen ist, etwa einen Sync-Client oder ein Plugin. Die Abgrenzung im Detail behandelt der Beitrag zum Cyber Resilience Act und SaaS.
Ist eine reine Browser-Anwendung ein Produkt im Sinne des EU CRA?+
Eine Web-Anwendung oder Progressive Web App, die ausschließlich im Browser läuft, ist kein Produkt mit digitalen Elementen (EU-Kommissions-Guidance, Abschnitt 2.2; Erwägungsgründe 11 und 12). Zu einem Produkt gehören kann ein Browser-Frontend nur als Datenfernverarbeitung, etwa ein Anmeldeportal, das Tokens für einen Desktop-Client ausstellt (Abschnitt 8.1). Eine Informations-Website gehört nicht dazu, auch wenn das Produkt auf sie verlinkt.
Wann gilt unser Backend als Datenfernverarbeitung?+
Ein Backend ist Datenfernverarbeitung nach Art. 3 Nr. 2 EU CRA, wenn zwei Fragen aus Abschnitt 8.1 der EU-Kommissions-Guidance mit Ja beantwortet werden. Fällt ohne das Backend eine Funktion des Produkts aus, Onboarding, Synchronisation, Konfiguration, Update-Verteilung und Login eingeschlossen? Und hat der Hersteller die Software entwickelt oder nach seinen Vorgaben entwickeln lassen? Wer das Backend betreibt und wo es läuft, spielt keine Rolle.
Welche Softwarekategorien sind wichtige Produkte nach Anhang III?+
In Anhang III EU CRA können die Positionen Nr. 1 bis 11 der Klasse I und Nr. 1 und 2 der Klasse II reine Software sein. Ob ein Produkt darunter fällt, entscheidet laut EU-Kommissions-Guidance (Abschnitt 6.1) allein seine Kernfunktion: SOAR-Software ist kein SIEM (Beispiel 59), ein Log-Sammler ohne Korrelation auch nicht (Beispiel 60).
Wann wird ein eigenes Open-Source-Projekt zum Produkt unter dem EU CRA?+
Ein Open-Source-Projekt, das ein Softwarehersteller selbst veröffentlicht, wird nach Abschnitt 3.1 der EU-Kommissions-Guidance zum Produkt, wenn er es monetarisiert: mit einem Preis für Binaries, einer verpflichtenden Verarbeitung personenbezogener Daten oder einer Bezahlversion mit Support. Spenden und Sponsoring Dritter reichen dafür nicht. Community- und Bezahlversion eines Open-Core-Modells sind zwei verschiedene Produkte. Wer ein Projekt nachhaltig unterstützt, ohne es in Verkehr zu bringen, ist unter Umständen Verwalter quelloffener Software mit den Pflichten aus Art. 24.
Was ist der Zusammenhang zwischen EU CRA und CE-Kennzeichnung für Software?+
Die CE-Kennzeichnung zeigt an, dass Produkt und Verfahren Anhang I der Verordnung erfüllen (Art. 3 Nr. 31). Bei Software steht sie nach Art. 30 Abs. 1 auf der EU-Konformitätserklärung nach Art. 28 oder auf der Website zum Produkt, in einem für Verbraucher leicht zugänglichen Abschnitt. Angebracht wird sie vor dem Inverkehrbringen, bei Beteiligung einer notifizierten Stelle mit deren Kennnummer (Art. 30 Abs. 3 und 4).
Wo steht Ihr Software-Portfolio beim EU CRA?
Mit dem EU-CRA-Assessment erhalten Sie in wenigen Minuten eine erste Einschätzung zu Klasse, Pflichten und nächsten Schritten für Ihr Software-Portfolio.
Weiterlesen
Weitere Branchen
EU-CRA-Compliance in anderen Branchen
Quelle: Verordnung (EU) 2024/2847 (Cyber Resilience Act), Amtsblatt der EU. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Diese Seite ist eine Orientierung zum Cyber Resilience Act für diese Branche, keine Rechtsberatung. Ob und wie die Verordnung für ein konkretes Produkt greift, hängt von dessen Zweckbestimmung und Aufbau ab.