CRA für Cloud-Anbieter: Bin ich ausgenommen?

Die Grundregel und warum sie trügerisch ist

„Bin ich Cloud-Anbieter oder Software-Hersteller?” — für viele B2B-SaaS-Produkte lässt sich das nicht mit einem Satz beantworten. Besonders nicht, wenn es einen Self-Hosted-Modus gibt.

Artikel 2 Absatz 7 der EU-Verordnung 2024/2847 (Cyber Resilience Act) legt fest: Reine Ferndienstleistungen sind vom Anwendungsbereich ausgenommen, soweit sie nicht als Produkt mit digitalen Elementen qualifizieren.¹ Klingt nach einer klaren Freistellung für Cloud-Dienste. Ist es aber nicht. Denn in der Praxis liefern zahlreiche B2B-Anbieter neben ihrem Dienst auch Software aus — und genau das bringt sie unter den CRA.

Was der CRA unter „Produkten mit digitalen Elementen” versteht

Der CRA definiert „Produkte mit digitalen Elementen” als Software oder Hardware, die über eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz verfügt.¹ Entscheidend ist das Merkmal des Inverkehrbringens: Wer Software an Kunden ausliefert — zum Download, zur Installation, zur lokalen Ausführung — handelt als Hersteller im Sinne des CRA, nicht als Dienstleister.

Ein reiner SaaS-Dienst, bei dem Kunden ausschließlich über einen Browser oder eine API auf Ihren Server zugreifen und niemals Software herunterladen oder installieren, fällt unter die Ausnahme. Der Dienst selbst ist kein Produkt, das in Verkehr gebracht wird.

Sobald der Kunde jedoch Software herunterlädt, installiert oder in seiner eigenen Infrastruktur betreibt — ändert sich die Qualifikation.

Der Entscheidungsbaum: Drei Fragen

Frage 1: Lädt Ihr Kunde Software herunter oder installiert etwas?

Nein → Ihr Angebot ist ein reiner Fernzugriffsdienst. Die CRA-Ausnahme für Dienste greift, sofern kein Softwarepaket übergeben wird.

Ja → Weiter zu Frage 2.

Beispiele für „Ja”:

• Docker-Image aus Ihrer Registry
• VM-Image (OVA, AMI, Azure Marketplace VM)
• Kubernetes-Operator oder Helm-Chart das auf dem Cluster des Kunden läuft
• Installierbare Software (Debian-Paket, Windows-Installer, macOS-App)
• CLI-Tool das der Kunde lokal ausführt
• Mobil-App die ein Backend-Service begleitet

Frage 2: Wird die Software kommerziell bereitgestellt?

Nein (rein nicht-kommerziell, kein Support, kein SLA, keine Gegenleistung) → Mögliche OSS-Ausnahme prüfen (Erwägungsgrund 18, 19). Die Ausnahme greift bei echter nicht-kommerzieller Open-Source-Bereitstellung — nicht bei Freemium-Modellen.

Ja → CRA gilt. Weiter zu Frage 3.

Frage 3: Welche Risikoklasse hat Ihr Produkt?

Die meisten SaaS-Begleitprodukte (CLI-Tools, SDKs, Operatoren) fallen in die Default-Klasse und erfordern eine Selbstbewertung. Ausnahmen gelten für Produkte in Anhang III des CRA (Klasse I) und Anhang IV (Klasse II), die strengere Konformitätsbewertungen erfordern — zum Beispiel Firewalls, VPNs oder Netzwerkmanagement-Software.

Der CRA RouteCheck-Klassifikator hilft Ihnen, die Klasse Ihres Produkts in unter 5 Minuten zu bestimmen.

Die häufigsten Grenzfälle für Cloud-Anbieter

Docker-Images und Container-Registry

Ein Docker-Image ist ein Softwarepaket, das in Verkehr gebracht wird — es enthält ein komplettes Dateisystem mit ausführbarem Code und Abhängigkeiten. Veröffentlichen Sie ein Docker-Image auf Docker Hub, GitHub Container Registry oder einer eigenen Registry, und laden Kunden dieses Image herunter und betreiben es: Dann sind Sie Hersteller im Sinne des CRA. Punkt.

Was viele CRA-Berater nicht sagen: Das gilt auch dann, wenn das Image „nur” eine Verwaltungskomponente für bestehende Hardware ist. Ein IoT-Startup, das industrielle MQTT-Gateways verkauft — Hardware beim Kunden, Verwaltungssoftware als Docker-Image ausgeliefert — bringt ein Produkt mit digitalen Elementen in Verkehr. Das Image landet in der Kundeninfrastruktur, enthält ausführbaren Code, hat Netzwerkverbindungen. CRA-relevant. Kein Graubereich.

Konsequenz: Das Image braucht eine SBOM (alle enthaltenen Pakete, Bibliotheken, Versionen), eine Vulnerability-Disclosure-Policy und einen Prozess für Sicherheitsupdates. Tools wie Syft (Anchore) oder Trivy können automatisch SBOMs aus Container-Images generieren und in CI/CD-Pipelines integriert werden.

Das bedeutet nicht, dass jedes Docker-Image eines kleinen Teams sofort eine vollständige CRA-Konformitätsbewertung mit CE-Kennzeichnung braucht — die Kennzeichnungspflicht gilt für das Inverkehrbringen auf dem EU-Markt im kommerziellen Kontext. Interne Images oder Images für eigene Produktionsinfrastruktur sind keine Produkte, die in Verkehr gebracht werden.

VM-Images und Marketplace-Angebote

AWS Marketplace, Azure Marketplace und Google Cloud Marketplace-Angebote in Form von VM-Images sind eindeutig CRA-relevant: Kunden laden das Image herunter (oder starten eine Instanz auf Basis des Images) und betreiben es in ihrer eigenen Cloud-Umgebung. Was viele hier übersehen: Es spielt keine Rolle, ob der Marketplace das Image technisch „ausliefert” — rechtlich bringen Sie das Produkt in Verkehr.

Für diese Produkte gelten alle Anforderungen aus Anhang I des CRA: Schwachstellenmanagement, Security-Updates, SBOM, sichere Authentifizierungsverfahren und die Pflicht, Updates bereitzustellen.

Kubernetes-Operatoren und Helm-Charts

Kubernetes-Operatoren laufen im Cluster des Kunden — nicht auf Ihrer Infrastruktur. Typischerweise greifen sie mit erhöhten Rechten auf Cluster-Ressourcen zu. Das macht sie sicherheitskritisch und CRA-relevant.

Helm-Charts, die reine Konfigurationstemplates ohne eigene ausführbare Software sind, fallen in eine Grauzone: Verweist der Chart ausschließlich auf Images aus anderen Quellen, bringen Sie kein neues ausführbares Produkt in Verkehr. Enthält der Chart eigene Images Ihres Unternehmens, sind diese CRA-relevant.

Self-Hosted-Optionen bei B2B-SaaS

Viele B2B-SaaS-Anbieter — besonders im Maschinenbau und bei Industrie-4.0-Plattformen — bieten eine Self-Hosted-Option für Enterprise-Kunden an: Die gesamte Anwendung läuft dann in der Infrastruktur des Kunden, nicht mehr in Ihrer Cloud.

Das ist der Punkt, den viele übersehen: Sobald Sie eine solche Option anbieten — auch wenn nur 5% Ihrer Kunden sie nutzen — bringen Sie Software in Verkehr. Das Self-Hosted-Paket (egal ob Docker Compose, Kubernetes, RPM-Paket) ist ein Produkt mit digitalen Elementen und fällt unter den CRA.

Das hat praktische Implikationen: Ihre SaaS-Architektur ist mit Blick auf den CRA irrelevant — entscheidend ist das ausgelieferte Paket. Enthält Ihr Self-Hosted-Image eine ältere Software-Version als Ihr gehosteter Dienst, müssen Sie trotzdem Sicherheitsupdates für das Self-Hosted-Paket bereitstellen und CVEs darin kommunizieren.

Ein Beispiel aus der Praxis: Ein Industrie-4.0-Anbieter für Fertigungsanalytik betreibt seinen Dienst als SaaS, liefert aber auf Kundenwunsch ein Docker-Compose-Paket für den Einsatz im Werk — ohne Internetverbindung, aus Datenschutzgründen. Dieses Paket ist CRA-pflichtig, auch wenn es nur an drei Enterprise-Kunden geht.

Freemium-Modelle: Die OSS-Ausnahme greift nicht

Die OSS-Ausnahme des CRA (Erwägungsgründe 18 und 19) gilt für Software, die nicht-kommerziell bereitgestellt wird — also ohne finanzielle Gegenleistung, ohne kommerziellen Support und ohne Gewinnerzielungsabsicht.

Freemium-Modelle sind keine nicht-kommerzielle Bereitstellung. Wer eine kostenlose Tier anbietet, um zahlende Kunden zu gewinnen, betreibt eine kommerzielle Aktivität — auch wenn der einzelne Nutzer nichts zahlt. In der Praxis erleben wir genau das als häufigsten Irrtum: SaaS-Anbieter, die ihr kostenloses Tier für OSS-befreit halten, obwohl dahinter ein klares Upsell-Modell steckt.

Auch der Verkauf von Support-Verträgen oder SLAs für eine ansonsten kostenlos verfügbare Software hebt die OSS-Ausnahme auf: Wer kommerziellen Support für Open-Source-Software verkauft, gilt nach dem CRA als Hersteller im kommerziellen Kontext (Erwägungsgrund 19).¹

Was Sie konkret tun müssen

Kommen Sie zu dem Ergebnis, dass Ihr Produkt unter den CRA fällt, sind dies die wichtigsten Schritte:

SBOM erstellen und aktuell halten: Für Container-Images empfehlen sich Syft oder Trivy in CI/CD. Für Software-Pakete: SPDX oder CycloneDX sind die etablierten Standards. Die SBOM muss auf Anfrage der Marktaufsichtsbehörde vorliegen — Hersteller müssen sie also nicht proaktiv veröffentlichen, aber jederzeit bereitstellen können.

Vulnerability-Disclosure-Policy veröffentlichen: Gebraucht wird eine öffentlich zugängliche Seite (z.B. /security), die erklärt, wie Sicherheitsforschende Schwachstellen melden können und wie Sie reagieren. Das ist eine explizite Anforderung aus Anhang I, Teil II.¹

CVE-Monitoring für Ihre Abhängigkeiten: Container-Images haben oft hunderte transitiver Abhängigkeiten. Automated Scanning in der CI/CD-Pipeline (Trivy, Snyk, Grype) ist kein Luxus — es ist eine Voraussetzung für das gesetzlich geforderte Schwachstellenmanagement.

Update-Kanal definieren: Wie informieren Sie Kunden über kritische Sicherheitsupdates? Email, Changelog, RSS, Security-Advisory-Feed — irgendeine Form der aktiven Kommunikation muss existieren.

Meldepflicht ab September 2026: Aktiv ausgenutzte Schwachstellen in Ihren Produkten müssen Hersteller innerhalb von 24 Stunden an ENISA melden (Artikel 14).¹ Legen Sie jetzt fest, wer in Ihrem Team für diese Meldung zuständig ist und über welchen Kanal. Das klingt nach bürokratischem Aufwand. Ist es auch. Aber wer diesen Prozess nicht vor dem Stichtag aufgebaut hat, steht im Ernstfall ohne Ansprechpartner und ohne Dokumentation da.

Zusammenfassung

Konkret bedeutet das: Wer Software ausliefert, die Kunden herunterladen, installieren oder in eigener Infrastruktur betreiben — geht von CRA-Relevanz aus und prüft dann Ausnahmen. Nicht umgekehrt.

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, Erwägungsgründe 18, 19: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Cyber Resilience Act, Einordnung und Anforderungen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. ENISA — CRA Implementation Guidance: https://www.enisa.europa.eu/topics/cyber-resilience-act
4. Anchore Syft — SBOM-Generator für Container: https://github.com/anchore/syft
5. Aqua Trivy — Container-Vulnerability-Scanner: https://github.com/aquasecurity/trivy

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.