Der CRA erhält seine Bedienungsanleitung: Was die Leitlinien der Kommission für Sie bedeuten

Der Cyber Resilience Act liegt seit Ende 2024 im Wortlaut vor. Was fehlte, war eine Bedienungsanleitung. Am 3. März 2026 hat die Europäische Kommission genau das veröffentlicht: den Entwurf der Mitteilung Ares(2026)2319816 — rund 70 Seiten praktische Leitlinien zur Auslegung der Verordnung.

Dies sind die nach Artikel 26 erwarteten Leitlinien, auf die die Branche gewartet hat. Hier erfahren Sie, was darin steht und was das für Sie bedeutet.

Einleitung

Der Entwurf der Mitteilung Ares(2026)2319816 vom 3. März 2026 ist das erste umfassende Leitliniendokument der Europäischen Kommission zum Cyber Resilience Act. Mit rund 70 Seiten behandelt er Fragen, die Compliance-Teams nachts nicht schlafen lassen: Was zählt als „Fernverarbeitung von Daten"? Müssen Altprodukte vollständig neu konzipiert werden? Wann wird ein Software-Update zu einem neuen Produkt?

Dieser Artikel destilliert die neun folgenreichsten Entscheidungen zu praktischen Leitlinien für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen.

1. SaaS und Cloud: Der RDPS-Test

Die Kommission führt einen strengen Drei-Fragen-Test ein, um zu bestimmen, ob eine Cloud- oder SaaS-Komponente als „Fernverarbeitungslösung für Daten" (RDPS) qualifiziert und damit in den Konformitätsgeltungsbereich des Produkts fällt.

flowchart TD
    A["Verarbeitet die Lösung Daten
'aus der Ferne'?"] -->|Nein| B["Kein RDPS"]
    A -->|Ja| C["Würde das Produkt eine Kernfunktion verlieren,
ohne diese Lösung?"]
    C -->|Nein| D["Kein RDPS
(als Komponente behandeln,
Due-Diligence gem. Art. 13(5))"]
    C -->|Ja| E["Vom Hersteller oder unter seiner
Verantwortung konzipiert?"]
    E -->|Nein| F["Kein RDPS
(Drittanbieter-SaaS = Komponente,
Due-Diligence gem. Art. 13(5))"]
    E -->|Ja| G["RDPS: im Konformitätsbewertungsumfang
des Produkts"]

Die Leitlinien veranschaulichen dies anhand von fünf konkreten Szenarien: einer Banking-App, einem intelligenten Thermostat, einem E-Reader, einem Industrieroboter und einem Mobilfunkgerät.

2. Altprodukte

Produkte, die bereits vor Dezember 2027 auf dem EU-Markt bereitgestellt wurden, müssen nicht von Grund auf neu konzipiert werden. Sie sind jedoch auch nicht ausgenommen.

Die Kommission stellt drei Dinge klar:

Keine historische Rekonstruktion erforderlich. Sie müssen keine Entwicklungsdokumentation aus früheren Jahren rekonstruieren. Entscheidend ist eine aktuelle Cybersicherheits-Risikobewertung, die nachweist, dass das Produkt die wesentlichen Anforderungen bezogen auf seinen Verwendungszweck erfüllt.

Produktfamilien können zusammengefasst werden. Wenn mehrere Altprodukte dieselbe Architektur und dasselbe Risikoprofil aufweisen, kann eine einzige Risikobewertung für die gesamte Familie durchgeführt werden, anstatt jede einzelne SKU zu bewerten.

Vollständige Konformität gilt weiterhin. Altprodukte benötigen weiterhin eine CE-Kennzeichnung, eine Konformitätserklärung und eine aktive Schwachstellenbehandlung. Die Erleichterung betrifft die Dokumentationshistorie, nicht die Pflichten selbst.

Eine detaillierte Beschreibung des Konformitätsbewertungsverfahrens finden Sie in unserem Leitfaden zur Konformitätsbewertungsentscheidung. Zur Planung von Supportzeiträumen für Altprodukte siehe Supportzeitraum-Planung.

3. Software und „unendliche Kopien"

Wann wird Software „auf dem Markt bereitgestellt"? Die Kommission bestätigt: einmalig. Die erstmalige digitale Distribution stellt die Bereitstellung dar. Nachfolgende kleinere Updates (z. B. von v1.0.0 auf v1.0.1) setzen die Regulierungsuhr nicht zurück.

Dies gilt speziell für eigenständige Software, die digital vertrieben wird. Hardware-Produkte mit eingebetteter Software folgen den standardmäßigen Bereitstellungsregeln für physische Güter.

4. Wann Updates zu „wesentlichen Änderungen" werden

Dieser Abschnitt ist der handlungsrelevanteste Teil der gesamten Leitlinien. Die Kommission liefert konkrete Beispiele, die Routineupdates von Änderungen unterscheiden, die eine neue Konformitätsbewertung auslösen.

Die Kommission schlägt vier Fragen vor, die jeder Hersteller vor der Veröffentlichung eines Updates stellen sollte:

1. Führt das Update neue Angriffsvektoren ein?
2. Ermöglicht es neue Angriffsszenarien?
3. Ändert es die Wahrscheinlichkeit bestehender Angriffsszenarien?
4. Ändert es die Auswirkung bestehender Angriffsszenarien?

Wenn eine dieser Fragen mit Ja beantwortet wird, stellt das Update wahrscheinlich eine wesentliche Änderung dar, die eine neue Konformitätsbewertung erfordert.

Weitere Informationen zur Produktklassifizierung und deren Wechselwirkung mit Änderungen finden Sie in unserem Produktklassifizierungsleitfaden.

5. Open-Source-Regeln

Die Leitlinien enthalten mehrere wichtige Klarstellungen zur Anwendung des CRA auf Open-Source-Software:

• Die Veröffentlichung von Quellcode in öffentlichen Repositories stellt kein „Bereitstellen auf dem Markt" dar. Der CRA greift bei der kommerziellen Verteilung, nicht bei der Verfügbarkeit des Codes.
• Community Edition vs. kostenpflichtige Edition = unterschiedliche Produkte. Wenn Sie eine kostenlose Community-Version und eine kostenpflichtige kommerzielle Version anbieten, löst nur die kostenpflichtige Version Herstellerpflichten aus.
• Spenden allein machen FOSS nicht kommerziell — es sei denn, der Zugang zur Software ist an eine Spende geknüpft. Freiwillige Spenden sind ausdrücklich ausgeschlossen.
• Gemeinnützige Einrichtungen, deren Überschuss vollständig gemeinnützigen Zwecken zugute kommt, sind von Herstellerpflichten befreit, auch wenn sie monetarisieren.
• Mitwirkende ohne Kontrolle über Veröffentlichungen, Roadmap oder Governance gelten NICHT als Hersteller — auch wenn sie Commit-Zugang haben. Die Verantwortung liegt bei denjenigen, die den Veröffentlichungsprozess kontrollieren.
• Pflichten von Open-Source-Stewards skalieren mit dem Umfang des bereitgestellten Supports. Nicht-technisches Stewardship ist mit geringeren Pflichten verbunden als vollständiger kommerzieller Support.

Verwandte Leitlinien zur koordinierten Schwachstellenoffenlegung in Open-Source-Kontexten finden Sie in unserer CVD-Richtlinienvorlage.

6. Supportzeitraum: Fünf Jahre sind eine Untergrenze

Die Kommission stellt klar, dass der standardmäßige Fünfjahres-Supportzeitraum ein Minimum ist, kein Ziel. Produkte, die voraussichtlich länger als fünf Jahre im Einsatz bleiben, müssen proportional längere Supportzeiträume haben.

Die Leitlinien klären auch den Weg nach Artikel 13(10): Hersteller können das Patchen älterer Versionen einstellen, wenn Nutzer kostenlos auf eine unterstützte Version upgraden können. „Zusätzliche Kosten" in diesem Zusammenhang bedeutet zwingend notwendige Hardware-Anschaffungen — routinemäßige Tests, Neukonfiguration oder Bereitstellungsaufwand seitens des Nutzers fallen nicht darunter.

Detaillierte Planungsstrategien finden Sie in unserem Leitfaden zur Supportzeitraum-Planung.

7. Risikobewertung: Interne Risikobereitschaft ist irrelevant

Die Kommission ist unmissverständlich: Risikobewertungen im Rahmen des CRA müssen auf objektiven Cybersicherheitskriterien basieren, nicht auf der internen Risikobereitschaft des Herstellers. Konkret gilt:

• Geschäftsstrategie und Kostenerwägungen fließen nicht in die Cybersicherheits-Risikobewertung ein.
• Cybersicherheitsrisiken können nicht durch Dokumentation, Haftungsausschlüsse oder Nutzungsbedingungen auf Nutzer übertragen werden.
• Wenn identifizierte Risiken nicht durch technische oder organisatorische Maßnahmen adressiert werden können, muss das Produkt möglicherweise vor der Marktbereitstellung neu konzipiert werden.

Dies ist eine bedeutsame Aussage. Sie bedeutet, dass ein Hersteller ein Produkt mit nicht beherrschten Cybersicherheitsrisiken nicht wissentlich auf den Markt bringen darf, nur weil das Unternehmen dieses Risiko „akzeptiert" hat.

Einen Überblick über die Kostenimplikationen der Compliance finden Sie in unserem Leitfaden zur Compliance-Kostenschätzung.

8. Bekannte ausnutzbare Schwachstellen

Die Leitlinien klären, was „bekannt" im Kontext der CRA-Anforderung bedeutet, Produkte ohne bekannte ausnutzbare Schwachstellen auf den Markt zu bringen:

• In öffentlichen Datenbanken gelistet: EU-Schwachstellendatenbank, CVE/MITRE, NVD.
• Über nicht-öffentliche Kanäle offengelegt: Programme zur koordinierten Schwachstellenoffenlegung, interne Sicherheitstests, Penetrationstests durch Dritte.
• In zuverlässigen Medien prominent berichtet: Eine schwerwiegende Schwachstelle, die von maßgeblichen Cybersicherheitspublikationen behandelt wird, gilt als „bekannt".

Hersteller erhalten ein begrenztes Untersuchungsfenster, um zu bestätigen, ob eine gemeldete Schwachstelle tatsächlich auf ihr Produkt zutrifft. „Untersuchung" ist jedoch kein Schlupfloch — die Uhr läuft ab dem Zeitpunkt der Kenntnis, und Verzögerungen werden genau geprüft.

Praktische Leitlinien zur Schwachstellendokumentation finden Sie in unserem VEX-Leitfaden.

9. Meldepflichten (September 2026)

Die Meldepflichten ab September 2026 sind die erste CRA-Frist mit echten Durchsetzungsmaßnahmen. Die Leitlinien bestätigen die Zeitrahmenstruktur:

• 24 Stunden: Frühwarnung an ENISA nach Bekanntwerden einer aktiven Ausnutzung
• 72 Stunden: Detaillierte Meldung mit technischen Indikatoren
• 14 Tage: Abschlussbericht bei Schwachstellen / 30 Tage bei Vorfällen

„Kenntnis" bedeutet hinreichende Gewissheit nach einer ersten Bewertung — keine vollständige forensische Bestätigung. Wenn glaubwürdige Hinweise auf eine aktive Ausnutzung vorliegen, läuft die Uhr bereits.

Zur Nutzerbenachrichtigung bestätigt die Kommission, dass diese risikobasiert und verhältnismäßig erfolgen sollte. Es besteht keine obligatorische öffentliche Offenlegungspflicht, wenn die Offenlegung das Sicherheitsrisiko erhöhen würde.

Eine vollständige Beschreibung des Meldeverfahrens finden Sie in unserem Leitfaden zur ENISA-24-Stunden-Meldung. Den vollständigen Compliance-Zeitplan finden Sie in unserem Implementierungszeitplan.

Was das für Sie bedeutet

Diese Leitlinien ändern nicht, was der CRA fordert. Sie ändern jedoch, wie viel Rätselraten erforderlich ist. Hersteller verfügen jetzt über konkrete Tests (RDPS), konkrete Beispiele (wesentliche Änderungen) und konkrete Zeitrahmen (Meldung), mit denen sie arbeiten können.

Drei sofortige Maßnahmen:

1. Führen Sie den RDPS-Test für jeden Cloud-Dienst durch, von dem Ihr Produkt abhängt. CRA Evidence automatisiert diese Bewertung als Teil der Produkt-Risikoanalyse.
2. Überprüfen Sie Ihren Update-Prozess anhand der vier Fragen zu wesentlichen Änderungen. Integrieren Sie diese in Ihre Veröffentlichungs-Checkliste.
3. Bereiten Sie sich auf die Meldepflichten ab September 2026 vor. Interne Triage-Prozesse, Eskalationspfade und Berichtsvorlagen müssen vor der Frist vorhanden sein.

Die Rückmeldefrist ist über das Better-Regulation-Portal geöffnet. Wenn Sie Anmerkungen zu den Leitlinien haben, ist jetzt der richtige Zeitpunkt.

Einen schrittweisen Ansatz zur CRA-Bereitschaft finden Sie in unserem Startup-Compliance-Leitfaden.

Dieser Artikel basiert auf dem Entwurf der Mitteilung Ares(2026)2319816 vom 3. März 2026. Diese Leitlinien wurden von der Europäischen Kommission noch nicht förmlich angenommen und werden finalisiert, sobald alle EU-Sprachversionen verfügbar sind.