Drei CRA-Szenarien: Was der Cyber Resilience Act für Ihr Unternehmen bedeutet

Schlüsselfakten

Das CRA-Reporting beginnt früher als die vollständige Compliance: Pflichten zur Meldung von Schwachstellen und Sicherheitsvorfällen gelten ab dem 11. September 2026, während die vollständigen CRA-Anforderungen erst ab dem 11. Dezember 2027 wirksam werden.
Der Anwendungsbereich hängt von Architektur und Vertriebsmodell ab: Reine Cloud-SaaS-Lösungen können ausgenommen sein, aber clientseitige Software, vernetzte Geräte, Mobile Apps und entfernte Datenverarbeitung in Verbindung mit Produkten fallen unter die Regelungen.
Auch alte oder abgekündigte Produkte schaffen Verpflichtungen: Selbst eingestellte Geräte unterliegen weiterhin der Schwachstellenüberwachung und Berichtspflicht, sofern sie noch genutzt werden oder an aktive Back-End-Systeme angeschlossen sind.
Für jedes Produkt ist ein Lifecycle-Sicherheitsmanagement erforderlich: Egal, ob Sie eine SaaS-Plattform, zwei Gerätegenerationen oder zehn Mobile Apps betreuen, Sie müssen SBOMs, technische Dokumentation und Prozesse zur Schwachstellenbearbeitung während des gesamten Supportzeitraums (mindestens fünf Jahre) pflegen.

Der EU Cyber Resilience Act gilt weitreichend für Produkte mit digitalen Elementen, die auf dem europäischen Markt verkauft werden. „Weitreichend“ bedeutet jedoch nicht „einheitlich“. Die Pflichten variieren je nach Produkttyp, Geschäftsmodell und Position in der Lieferkette.

Dieser Artikel erläutert drei realistische Szenarien und erklärt die CRA-Auswirkungen für jedes. Ob Sie ein SaaS-Startup, ein Hardwarehersteller oder ein unabhängiger App-Entwickler sind – die Kenntnis Ihres spezifischen Risikos ist der erste Schritt zu praktischer Compliance.

Szenario 1: B2B-SaaS-Startup mit Launch im Januar 2027

Profil: Sie entwickeln eine B2B-SaaS-Plattform für EU-Unternehmenskunden. Ihr Produkt läuft vollständig in der Cloud. Der kommerzielle Launch ist für Januar 2027 geplant.

Sind Sie im Geltungsbereich?

Das hängt von Ihrer Architektur ab.

Wenn Ihre Software vollständig auf Ihrer Infrastruktur läuft und Kunden über Browser oder API darauf zugreifen (reines SaaS), fällt sie in der Regel nicht unter den CRA. Die Verordnung richtet sich an „Produkte mit digitalen Elementen“, also Software oder Hardware, die in Verkehr gebracht und dem Nutzer bereitgestellt wird.

Sie fallen jedoch unter den Geltungsbereich, wenn Ihr SaaS Folgendes umfasst:

eine clientseitige Komponente (Desktop-Agent, mobile App, Browser-Erweiterung), die Kunden installieren;
Remote-Datenverarbeitung, die für die Funktion eines verbundenen Produkts wesentlich ist und vom Hersteller oder in dessen Auftrag entwickelt wurde.

Wenn Ihr SaaS Backend-Verarbeitung für ein IoT-Gerät oder installierte Software eines Kunden bereitstellt, gelten die Regeln für Remote-Datenverarbeitung. In diesem Fall behandelt der CRA Ihr Backend als Teil des Sicherheitsperimeters des Produkts.

Bedeutung für einen Launch im Januar 2027

Wenn Sie unter den Geltungsbereich fallen, sieht der Zeitplan wie folgt aus:

11. September 2026: Die Meldepflichten nach Artikel 14 für Schwachstellen und Vorfälle treten in Kraft. Sie müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden melden und Folgebenachrichtigungen innerhalb von 72 Stunden einreichen.
11. Dezember 2027: Vollständige CRA-Anforderungen gelten, einschließlich Konformitätsbewertung, technischer Dokumentation (Anhang VII), CE-Kennzeichnung und SBOM.

Ein Launch im Januar 2027 bedeutet, dass Sie vor der vollständigen Anwendung des CRA, aber nach Beginn der Meldepflichten auf den Markt gehen. Wenn im ersten Quartal 2027 eine Schwachstelle Ihr Produkt betrifft, muss die operative Meldeinfrastruktur bereits vorhanden sein.

Praktische Vorbereitung

Geltungsbereich früh klären. Wenn Sie clientseitige Komponenten oder Remote-Processing-Abhängigkeiten haben, gehen Sie davon aus, dass Sie unter den Geltungsbereich fallen.
SBOM jetzt in CI/CD integrieren. Maschinenlesbare Daten zur Softwarezusammensetzung sind Voraussetzung für eine schnelle Schwachstellen-Triage.
Workflow für Schwachstellenreaktionen einrichten. Legen Sie Eigentümer, Eskalationswege und Meldetemplates vor dem Go-Live fest.
Anhang-VII-Dokumentation vorbereiten. Technische Dateien müssen vor dem Inverkehrbringen des Produkts bereitstehen.

Wie SaM Solutions unterstützen kann

Für ein Startup bedeutet der Aufbau einer CRA-konformen Infrastruktur von Grund auf, während gleichzeitig das Produkt ausgeliefert wird, einen Ressourcenkonflikt. Ein Engineering-Partner kann den Compliance-Aufwand übernehmen, ohne Ihre Roadmap zu verlangsamen.

Wir unterstützen SaaS-Startups mit:

Integration von SBOM-Pipelines in bestehende CI/CD-Prozesse, verknüpft mit Release-Versionen und Build-Artefakten;
Sicheren Entwicklungspraktiken, die in den täglichen Engineering-Prozess eingebettet sind und nicht erst zum Audit-Zeitpunkt hinzugefügt werden;
Schwachstellen-Monitoring und Triage als laufendem Service zur Reduzierung der internen Belastung;
Vorbereitung der technischen Dokumentation im Einklang mit den Anforderungen von Anhang VII.

Dies ermöglicht Startups, mit bereits vorhandener Meldefähigkeit zu starten, statt diese reaktiv nach dem Go-Live aufzubauen.

Szenario 2: Wearable-Hersteller mit einem noch genutzten EOL-Gerät

Profil: Sie stellen smarte Wearables her. Ihr Gerät der ersten Generation wurde 2024 eingestellt (EOL) und durch ein Modell der zweiten Generation ersetzt. Das neue Gerät wird aktiv unterstützt. Das alte Gerät wird nicht mehr verkauft, aber Tausende Einheiten befinden sich weiterhin bei Kunden. Diese Geräte verbinden sich noch mit Ihrem Backend zur Synchronisierung von Benutzerprofilen und für bestimmte Funktionen.

Fallen Sie unter den Geltungsbereich?

Ja – für beide Geräte, jedoch mit unterschiedlichen Verpflichtungsprofilen.

Das neue Gerät ist eindeutig: Es handelt sich um ein aktives Produkt mit digitalen Elementen, das ab Dezember 2027 den vollständigen CRA-Verpflichtungen und ab September 2026 den Meldepflichten unterliegt.

Das Altgerät ist komplexer. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen nicht rückwirkend den vollständigen CRA-Anforderungen, es sei denn, sie erfahren nach diesem Datum eine „wesentliche Änderung“. Allerdings gilt:

Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 für alle bereits in Verkehr gebrachten Produkte, einschließlich Altgeräten.
Wenn sich Ihr EOL-Gerät weiterhin mit Ihrem Backend verbindet und eine Schwachstelle im Backend oder in der Geräte-Firmware aktiv ausgenutzt wird, müssen Sie diese gemäß dem 24-/72-Stunden-Zeitplan melden.

Die Tatsache, dass ein Gerät EOL ist, hebt Ihre Meldepflicht nicht auf. Sie entbindet Sie von der Verpflichtung, neue Funktionen bereitzustellen, nicht jedoch von der Pflicht, Sicherheitsvorfälle zu überwachen, zu erkennen und zu melden.

Die Backend-Komplikation

Ihr Alt-Wearable greift weiterhin auf Ihr Backend für Benutzerprofile und Funktionen zu. Dieses Backend bedient wahrscheinlich sowohl alte als auch neue Geräte. Eine Schwachstelle in der gemeinsamen Infrastruktur löst Meldepflichten für beide Produktlinien aus.

Ein häufiges Muster ist, das Gerät auslaufen zu lassen, während das Backend für Bestandsnutzer weiter betrieben wird, ohne Sicherheitsüberwachung oder Incident-Response-Abdeckung für diesen Legacy-Pfad aufrechtzuerhalten. Unter dem CRA führt dies zu einer nicht adressierten Compliance-Exponierung.

Praktische Vorbereitung

Legacy-Exponierung erfassen. Identifizieren Sie, welche Backend-Komponenten EOL-Geräte bedienen und welche Datenflüsse weiterhin aktiv sind.
Entscheiden: weiter betreiben oder stilllegen. Wenn Sie den Backend-Zugriff aufrechterhalten, akzeptieren Sie fortlaufende Überwachungs- und Meldepflichten. Wenn Sie die Sicherheitsunterstützung nicht aufrechterhalten können, planen Sie eine sichere Stilllegung mit Kundenbenachrichtigung.
SBOM-Abdeckung auf Legacy-Firmware ausweiten. Wenn eine CVE in einer Komponente veröffentlicht wird, die von Ihrem EOL-Gerät genutzt wird, müssen Sie dies innerhalb von Stunden wissen – nicht erst nach Wochen.
Supportgrenzen kommunizieren. Der CRA verlangt, dass Hersteller das Ende der Supportperiode gegenüber Nutzern klar angeben. Wenn Ihr Altgerät seine Supportperiode überschritten hat, muss dies dokumentiert und kommuniziert werden.

Der CRA schreibt eine Mindest-Supportperiode von 5 Jahren ab dem Datum des Inverkehrbringens vor (Artikel 13). Wurde Ihr Altgerät 2022 verkauft und 2024 eingestellt, können Supportpflichten dennoch bis 2027 bestehen.

Wie SaM Solutions unterstützen kann

Das Management von zwei Produktgenerationen mit unterschiedlichen Supportniveaus – bei gleichzeitig gemeinsam genutzter Infrastruktur – erfordert eine sorgfältige Architektur- und Prozessdisziplin.

Wir unterstützen Wearable-Hersteller mit:

Embedded-Firmware-Entwicklung und -Wartung, einschließlich Sicherheits-Patching für Legacy-Codebasen;
IoT-Backend-Architektur, die Legacy- und aktuelle Geräteunterstützung klar trennt und eine gezielte Stilllegung ermöglicht;
Kontinuierlichem Schwachstellen-Monitoring über aktuelle und Legacy-Firmware hinweg, mit CVE-zu-Produkt-Zuordnung;
Sicherer EOL-Transitionsplanung, einschließlich Kundenkommunikation und Backend-Abschaltverfahren.

Unsere Embedded- und IoT-Teams verfügen über Erfahrung im Management langlebiger Geräteflotten, bei denen die Sicherheitsunterstützung über die aktive Verkaufsphase hinaus fortgeführt werden muss.

Szenario 3: Unabhängiger iOS-Entwickler mit zehn Apps

Profil: Sie sind ein Einzelentwickler oder ein kleines Team. In den letzten acht Jahren haben Sie zehn iOS-Apps im App Store veröffentlicht. Die Apps erzielen laufende Einnahmen durch kostenpflichtige Downloads. Sie funktionieren überwiegend offline oder nutzen frei zugängliche öffentliche APIs (Wetter, Wechselkurse usw.). Keine davon verbindet sich mit einem von Ihnen betriebenen Backend.

Fallen Sie unter den Geltungsbereich?

Ja, mobile Apps, die in der EU vertrieben werden, fallen unter den CRA.

Die Verordnung schließt Softwareanwendungen ausdrücklich ein, und das Europäische Parlament hat klargestellt, dass mobile Apps in den Geltungsbereich fallen. Die Tatsache, dass Ihre Apps auf der Plattform von Apple laufen, überträgt die Herstellerpflicht nicht auf Apple. Sie als Entwickler, der die App in Verkehr bringt, gelten nach dem CRA als Hersteller.

Die gute Nachricht

Ihr Risiko ist aus mehreren Gründen geringer als das eines SaaS-Unternehmens oder Geräteherstellers:

Keine Remote-Datenverarbeitung. Wenn Ihre Apps sich nicht mit einem von Ihnen kontrollierten Backend verbinden, vermeiden Sie die Komplexität der „Remote-Datenverarbeitungslösung“, die Cloud-Infrastruktur in den Geltungsbereich einbezieht.
Wahrscheinlich Standardkategorie. Verbraucher-Apps ohne kritische Sicherheitsfunktionen fallen in der Regel in die Standardkategorie, was eine Selbsteinschätzung (Modul A) anstelle einer Konformitätsbewertung durch Dritte ermöglicht.
Reduzierte Sanktionen für Kleinst- und kleine Unternehmen. KMU und Kleinstunternehmen können finanziell nicht sanktioniert werden, wenn sie die Meldefristen nach Artikel 14 nicht einhalten. Die Verpflichtung besteht weiterhin, aber das Sanktionsrisiko ist geringer.

Die Herausforderungen

Sie bleiben der Hersteller. Jede App, die Sie verkaufen, ist ein Produkt mit digitalen Elementen. Sie müssen die wesentlichen Cybersicherheitsanforderungen erfüllen, technische Dokumentation vorhalten und Schwachstellen während der gesamten Supportperiode behandeln.
Drittanbieter-Abhängigkeiten liegen in Ihrer Verantwortung. Wenn Ihre App eine Bibliothek mit einer bekannten Schwachstelle verwendet, ist das unter dem CRA Ihr Problem. Sie müssen Abhängigkeiten überwachen und Updates bereitstellen.
Zehn Apps bedeuten zehn Produkte. Jede App kann unterschiedliche Abhängigkeiten, unterschiedliche Release-Zweige und unterschiedliche Nutzerbasen haben. SBOM und Schwachstellenreaktion über zehn Produkte hinweg als Einzelentwickler zu managen, ist operativ anspruchsvoll.
Verpflichtungen zur Supportperiode. Sie müssen Sicherheitsupdates für die erwartete Produktlebensdauer oder mindestens 5 Jahre bereitstellen. Wenn Sie eine App aufgeben, sie aber im Store belassen, bleiben Sie verantwortlich.

Praktische Vorbereitung

Portfolio konsolidieren. Entscheiden Sie, welche Apps Sie aktiv pflegen und welche Sie aus dem Verkauf nehmen. Eine geringere Produktanzahl reduziert Ihre Compliance-Fläche.
SBOM-Generierung automatisieren. Verwenden Sie Tools wie Syft oder OWASP Dependency-Track, um maschinenlesbare Komponentenverzeichnisse für jede App zu erstellen.
Abhängigkeits-Monitoring einrichten. Abonnieren Sie CVE-Feeds für Ihre wichtigsten Abhängigkeiten. Für einen Einzelentwickler kann dies so einfach sein wie GitHub Dependabot oder die kostenlose Version von Snyk.
Supportperioden dokumentieren. Geben Sie in Ihren App-Store-Beschreibungen und Datenschutzerklärungen klar an, wie lange Sie Sicherheitsunterstützung bereitstellen.
Minimale technische Dokumentation vorbereiten. Anhang VII verlangt eine Cybersicherheits-Risikobewertung, eine SBOM und eine Konformitätserklärung. Beginnen Sie jetzt mit der Ausarbeitung.

Wie SaM Solutions unterstützen kann

Für einen unabhängigen Entwickler rechnet sich die Beschäftigung von Vollzeit-Compliancepersonal wirtschaftlich nicht. Die Verpflichtungen bleiben jedoch bestehen. Ein Outsourcing-Partner kann gezielte Unterstützung ohne fixe Overhead-Kosten bieten.

Wir unterstützen Indie-Entwickler und kleine Studios mit:

iOS-App-Wartung und Sicherheitsupdates, einschließlich Abhängigkeits-Updates und Regressionstests;
SBOM-Erstellung und Schwachstellen-Monitoring als Managed Service für Ihr gesamtes App-Portfolio;
Vorbereitung der technischen Dokumentation für Anhang VII, angepasst an die Größenordnung eines kleinen Entwicklers.

Dieser Ansatz hält Apps compliant und umsatzgenerierend, während der Anteil der Entwicklungszeit für regulatorische Anforderungen begrenzt wird.

Zusammenfassung: Drei Unternehmen, drei Compliance-Profile

Szenario	Im Geltungsbereich?	Wichtige Frist	Hauptproblem	SaM Solutions Unterstützung
B2B-SaaS-Startup	Abhängig von der Architektur	Sept 2026 (Meldung)	Aufbau der Compliance-Infrastruktur während des Launch	SBOM-Pipeline, sicheres SDLC, Schwachstellen-Monitoring
Wearable-Hersteller	Ja (beide Geräte)	Sept 2026 (Meldung)	Verpflichtungen für Legacy-Gerät und geteiltes Backend	Embedded-Wartung, IoT-Architektur, EOL-Planung
Indie-iOS-Entwickler	Ja (alle Apps)	Dez 2027 (vollständig)	Verwaltung von 10 Produkten als kleines Team	App-Wartung, SBOM-Service, Dokumentation

Final Takeaway

Der CRA gilt nicht für jedes Unternehmen identisch. Ein SaaS-Startup, das 2027 startet, steht unter anderen zeitlichen Druckbedingungen als ein Hardware-Hersteller mit Legacy-Geräten. Ein Indie-Entwickler mit zehn Apps hat andere Ressourcenbeschränkungen als ein Unternehmen mit eigenem Sicherheitsteam.

Gemeinsam ist allen ein klarer Zeitplan: Die Meldepflichten beginnen im September 2026, also lange vor der vollständigen Anwendung des CRA im Dezember 2027. Die Infrastruktur zur Erkennung, Bewertung und Meldung von Schwachstellen muss zu diesem früheren Datum funktionsfähig sein, unabhängig vom Geschäftsmodell.

Der richtige Partner hilft dabei, diese Infrastruktur effizient aufzubauen, wobei der Aufwand an das tatsächliche Risikoprofil angepasst wird, anstatt ein „One-Size-Fits-All“-Compliance-Programm anzuwenden.

Für detaillierte CRA-Zeitpläne, Sanktionsstrukturen und Meldeanforderungen siehe unseren Begleitartikel: EU CRA 2026 Readiness: Deadlines, Decisions, and Do-Nows.

Informationen dazu, wie ein Engineering-Partner bei der CRA-Bereitschaft unterstützt, finden Sie unter: CRA Compliance for SaaS: How to Prepare in 2026 and How an Engineering Partner Can Help.