CRA für Software-Hersteller ohne Hardware

Software ohne Hardware: Auch hier greift der CRA

Ein Developer-Tool mit 5.000 zahlenden Nutzern, das in CI/CD-Pipelines läuft, ist ein legitimes Angriffsziel — CRA-relevant, auch wenn der Hersteller ein 3-Mann-Startup ist.

Der Cyber Resilience Act (EU-Verordnung 2024/2847) macht keine Unterscheidung zwischen Hardware- und reinen Software-Produkten. „Produkte mit digitalen Elementen” umfassen ausdrücklich auch Software, die als eigenständiges Produkt in Verkehr gebracht wird — ohne begleitende Hardware.¹ Für Softwareentwickler, die Desktop-Anwendungen, CLI-Tools, Browser-Extensions oder Server-Software kommerziell anbieten, bedeutet das: Der CRA gilt.

Dieser Artikel klärt, welche Softwareprodukte betroffen sind, welche Ausnahmen tatsächlich greifen und was Hersteller konkret tun müssen.

Welche Softwareprodukte unter den CRA fallen

Desktop-Applikationen

Kommerziell vertriebene Desktop-Software fällt grundsätzlich unter den CRA, sofern sie eine Netzwerkverbindung herstellt — direkt oder indirekt. Das schließt Software ein, die:

• Daten über das Internet überträgt (Updates, Synchronisierung, Telemetrie)
• Netzwerkprotokolle implementiert oder exponiert
• Lokale Netzwerkdienste startet (z.B. ein lokaler Webserver als App-Backend)

Reine Offline-Software ohne jede Netzwerkfunktionalität könnte aus dem Anwendungsbereich fallen — aber in der Praxis ist das eine sehr enge Kategorie. Die meisten modernen Desktop-Anwendungen haben mindestens eine Update-Funktion, die eine Verbindung herstellt.

Browser-Extensions

Browser-Extensions sind ausführbarer Code, der im Browser des Nutzers läuft, auf Webseitendaten zugreift und typischerweise mit externen Diensten kommuniziert. Vertrieben werden sie über Browser-Stores (Chrome Web Store, Firefox Add-Ons, Edge Add-Ons) — das ist Inverkehrbringen von Software.

Kommerzielle Browser-Extensions fallen unter den CRA — sei es über direkte Zahlung, Freemium mit In-App-Käufen oder als Teil eines SaaS-Abonnements. Betroffen sind zum Beispiel:

• Passwort-Manager (Browser-Extension-Anteil)
• Produktivitäts-Tools (Scraper, Automatisierungen)
• Sicherheits-Extensions (Ad-Blocker mit kommerzieller Lizenz, VPN-Extensions)
• Developer-Tools (HTTP-Inspection, API-Debugging)

Server-Software zur Installation beim Kunden

Software, die Kunden auf eigenen Servern, in eigenen Clouds oder auf eigener Hardware installieren, ist ein klassisches Produkt mit digitalen Elementen. Dazu gehören:

• Self-Hosted-Varianten von SaaS-Produkten (vgl. Artikel zu CRA für Cloud-Anbieter)
• Datenbank-Management-Software
• Monitoring- und Observability-Stacks
• Backup- und Storage-Software
• CI/CD-Server-Komponenten

Entscheidend: Das Produkt wird ausgeliefert und läuft in der Infrastruktur des Kunden. Das unterscheidet es von einem SaaS-Dienst, bei dem Sie die Infrastruktur kontrollieren.

CLI-Tools und Developer-Tools

CLI-Tools, die kommerziell vertrieben werden — auch über Paketmanager wie npm, pip, Homebrew oder apt — fallen unter den CRA, sofern sie Netzwerkverbindungen herstellen. Betroffen sind:

• Deployment-Tools (Terraform-Plugins, Ansible-Collections)
• Datenbank-Clients und Migrations-Tools
• API-Testing-Tools (Postman CLI, ähnliche)
• Security-Scanner, die als kommerzielles Produkt vertrieben werden
• Build-Tools und Code-Generatoren mit Netzwerkfunktion

Was viele hier falsch verstehen: Die Tatsache, dass ein Tool „nur” in Entwicklungs- oder CI/CD-Umgebungen läuft, macht es nicht CRA-irrelevant. Im Gegenteil — Tools in Deployment-Pipelines haben oft erhöhte Rechte und direkten Zugriff auf produktive Systeme. Das ist kein Randfall, das ist ein bevorzugtes Angriffsziel.

Die OSS-Ausnahme: Eng auslegen

Erwägungsgrund 18 und 19 des CRA legen fest, dass nicht-kommerziell bereitgestellte Open-Source-Software aus dem Anwendungsbereich ausgenommen ist.¹ Diese Ausnahme existiert, weil das OSS-Ökosystem eine wichtige Grundlage für Innovation und Sicherheit in der Digitalwirtschaft darstellt und nicht durch bürokratische Anforderungen belastet werden soll.

Die Ausnahme greift, wenn:

• Die Software unter einer anerkannten Open-Source-Lizenz (OSI-approved) bereitgestellt wird
• Keine finanzielle Gegenleistung für die Software selbst verlangt wird
• Keine kommerziellen Support-Verträge oder SLAs für die Software verkauft werden
• Keine Gewinnerzielungsabsicht im Zusammenhang mit der Software besteht

Die Ausnahme greift nicht, wenn:

Kommerzieller Support oder SLA: Sobald Support-Verträge, Wartungsverträge oder SLAs für eine OSS-Software verkauft werden, handelt der Anbieter als Hersteller im kommerziellen Sinne. Das ist eine explizite Festlegung in Erwägungsgrund 19.¹ Unternehmen wie Red Hat, HashiCorp (vor der Lizenzänderung) und viele andere, die das Open-Core- oder Enterprise-Support-Modell nutzen, wären nach dieser Logik CRA-pflichtig.

Dual Licensing: Wer eine OSS-Version kostenlos anbietet und eine kommerzielle Lizenz für den Enterprise-Einsatz verkauft, betreibt mit der kommerziellen Version ein CRA-pflichtiges Produkt. Die kostenlose OSS-Version könnte unter die Ausnahme fallen — aber jede Version braucht eine separate Prüfung.

Hosted Version eines OSS-Projekts: Wer eine kommerzielle Hosted-Version der eigenen OSS-Software anbietet (SaaS-Modell auf Basis der OSS-Codebasis), kann sich nicht automatisch auf die Ausnahme berufen. Die Software, die Kunden als Self-Hosted-Option herunterladen, ist CRA-relevant.

Freemium-Modelle: Der tricky Fall

Freemium ist für den CRA kein geschütztes Modell. Ob die OSS-Ausnahme greift oder CRA-Pflicht besteht, hängt nicht daran, ob ein einzelner Nutzer zahlt — sondern ob das Produkt in einem kommerziellen Kontext bereitgestellt wird.

Wer:

• eine Free-Tier anbietet mit dem Ziel, zahlende Nutzer zu gewinnen
• Paid-Features in der gleichen Software hat (Feature-Gating)
• Werbung in der kostenlosen Version schaltet
• Nutzerdaten aus der kostenlosen Version für kommerzielle Zwecke verwendet

…betreibt ein kommerzielles Produkt — unabhängig davon, dass ein Teil der Nutzer nichts zahlt. Die OSS-Ausnahme greift hier nicht.

Praktisches Beispiel: Ein Entwickler-Tool, das auf GitHub als Open Source verfügbar ist, eine kostenlose Tier hat und eine Pro-Lizenz für 10 USD/Monat anbietet, ist ein kommerzielles Produkt mit digitalen Elementen. Es braucht SBOM, Schwachstellenmanagement und einen Update-Kanal — unabhängig davon, wie viele Nutzer die Free-Tier nutzen.

Der Update-Kanal als Pflicht

Anhang I, Teil II des CRA schreibt explizit vor, dass Hersteller Sicherheitsupdates für den gesamten Supportzeitraum bereitstellen und Nutzer über verfügbare Updates informieren müssen.¹ Für Software-Hersteller ohne Hardware bedeutet das konkret:

Was zwingend erforderlich ist:

• Ein definierter Kanal, über den Nutzer über Sicherheitsupdates informiert werden — mindestens eine öffentliche Security-Advisory-Seite oder ein Release-Changelog, der zwischen Security-Updates und Feature-Updates unterscheidet
• Ein Prozess, um kritische Schwachstellen zeitnah zu patchen und auszurollen
• Für Software mit automatischer Update-Funktion: Sicherheitsupdates müssen separat von optionalen Feature-Updates verfügbar sein — Nutzer dürfen Sicherheitsupdates nicht blockieren können

Was optional, aber empfehlenswert ist:

• Signierte Software-Pakete (Authenticode für Windows, notarisierte macOS-Apps, GPG-signierte Linux-Pakete)
• Automatische Sicherheitsupdates, die ohne Nutzerinteraktion eingespielt werden können
• CVE-Advisory-Feed (RSS oder Atom) für Nutzer, die Updates über eigene Systeme verwalten

Für Browser-Extensions gilt: Browserhersteller (Google, Mozilla, Microsoft) erzwingen Updates über ihre Stores bereits. Das ist kein Grund zur Entwarnung — Hersteller brauchen trotzdem einen Prozess, der sicherstellt, dass CVEs in Abhängigkeiten bemerkt und gepatcht werden.

Meldepflichten ab September 2026

Artikel 14 des CRA definiert Meldepflichten für Hersteller, die ab dem 11. September 2026 gelten:¹

• 24 Stunden: Vorläufige Meldung an ENISA (über das nationale CERT) wenn eine Schwachstelle aktiv ausgenutzt wird
• 72 Stunden: Vollständige technische Meldung mit bekannten Details zur Schwachstelle
• Laufend: Updates zur Behebung der Schwachstelle bis zum Abschluss

Für Software-Hersteller ohne eigenes Security-Team klingt das nach Überforderung. In der Praxis: Es ist ein definierter Prozess, keine Vollzeit-Stelle. Drei Dinge brauchen Hersteller:

1. Eine Vulnerability-Disclosure-Policy, die extern kommuniziert, wie Sicherheitsforschende Schwachstellen melden
2. Eine interne Eskalationsroutine, die bestimmt, wer die ENISA-Meldung erstellt
3. Zugang zur Meldeplattform des BSI (für deutsche Hersteller: BSI-CERT als nationale Anlaufstelle)

In der Praxis erleben wir, dass besonders IoT-Startups und embedded-Software-Hersteller diesen Schritt unterschätzen — nicht weil der Prozess komplex ist, sondern weil niemand ihn aufgeschrieben hat, bevor der Ernstfall eintritt.

Konformitätsbewertung für Software-Produkte

Die meisten reinen Software-Produkte fallen in die Default-Klasse des CRA — keine Listung in Anhang III oder IV. Für diese Klasse reicht eine Selbstbewertung (internal conformity assessment) aus.

Klasse I oder II können relevant werden für:

• Firewalls und Intrusion-Detection-Software (Anhang III, Klasse I)
• VPN-Software (Anhang III, Klasse I)
• Browser (Anhang III, Klasse I)
• Password-Manager (Anhang III, Klasse I)
• Betriebssysteme für allgemeine Zwecke (Anhang III, Klasse I)
• Betriebssysteme für Server und Netzwerk (Anhang III, Klasse II)

Fällt Ihr Produkt in eine dieser Kategorien, ist eine harmonisierte Norm (z.B. EN 303 645 für IoT, IEC 62443 für industrielle Software) oder eine externe Prüfung durch eine notifizierte Stelle erforderlich.

Der CRA RouteCheck-Klassifikator ermittelt die Risikoklasse Ihres Produkts auf Basis Ihrer Angaben.

Die wichtigsten Schritte für Software-Hersteller

Schritt 1 — Klarheit über Anwendungsbereich: Prüfen Sie für jedes Produkt: Wird es kommerziell bereitgestellt? Stellt es eine Netzwerkverbindung her? Wenn beides zutrifft: CRA-pflichtig.

Schritt 2 — SBOM erstellen: Für Software-Projekte mit etablierten Paketmanagern ist SBOM-Generierung heute weitgehend automatisierbar: syft, cdxgen, cyclonedx-cli für diverse Ökosysteme (npm, pip, Maven, Go, Cargo). Das Ergebnis ist eine CycloneDX- oder SPDX-Datei, die alle Abhängigkeiten mit Versionen listet. Diese SBOM muss aktuell gehalten und der Marktaufsicht auf Anfrage vorgelegt werden können.

Schritt 3 — CVE-Monitoring: Integrieren Sie einen Vulnerability-Scanner in Ihre CI/CD-Pipeline. Tools wie Snyk, Dependabot (GitHub), Grype oder OWASP Dependency-Check prüfen Abhängigkeiten kontinuierlich gegen bekannte CVE-Datenbanken. Einrichten und vergessen reicht nicht — Hersteller brauchen einen definierten Prozess, wie sie mit gemeldeten Schwachstellen umgehen.

Schritt 4 — Security-Seite und Vulnerability-Disclosure-Policy: Veröffentlichen Sie unter /security oder einer ähnlichen URL eine Policy, die erklärt, wie Schwachstellen gemeldet werden können, wie schnell Sie reagieren und über welchen Kanal Sie über Fixes informieren. Das ist eine explizite Anforderung aus Anhang I, Teil II.¹

Schritt 5 — Support-Zeitraum kommunizieren: Definieren und kommunizieren Sie, wie lange Sie Sicherheitsupdates für jede Version bereitstellen. Das schützt vor der Situation, dass ein Nutzer eine veraltete Version betreibt und den Hersteller für fehlende Updates haftbar macht.

Quellen

1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Artikel 13, Artikel 14, Anhang I, Anhang III, Erwägungsgründe 18, 19: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Cyber Resilience Act, Anforderungen für Softwareprodukte: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. ENISA — CRA Technical Guidance: https://www.enisa.europa.eu/topics/cyber-resilience-act
4. OWASP CycloneDX — SBOM Standard: https://cyclonedx.org
5. Linux Foundation — SPDX (ISO/IEC 5962:2021): https://spdx.dev
6. OSI — Open Source Definition und anerkannte Lizenzen: https://opensource.org/licenses

Keine Rechtsberatung. Diese Seite bietet eine indikative Einschätzung auf Basis Ihrer Angaben und öffentlich verfügbarer Informationen. Für rechtsverbindliche Beurteilungen wenden Sie sich an einen zugelassenen Rechtsanwalt oder eine akkreditierte Konformitätsbewertungsstelle.