Cyber Resilience Act: Für welche Sicherheitslücken ab 11. September 2026 eine Meldepflicht gilt

Für Hersteller vernetzter Produkte beginnt am 11. September 2026 eine neue Phase: Bestimmte aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle müssen nach dem Cyber Resilience Act, kurz CRA, gemeldet werden. Das ist nicht der vorgezogene Start aller Produktpflichten.

Die umfassenden Anforderungen an Entwicklung, Dokumentation, Konformität und Schwachstellenbehandlung gelten grundsätzlich erst ab 11. Dezember 2027. Wer bis dahin mit allen Vorbereitungen wartet, kann jedoch die ab September 2026 geltenden Meldeabläufe verpassen.

Der CRA-Zeitplan in drei Stufen

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt gestaffelt. Seit dem 11. Juni 2026 können vorgesehene Konformitätsbewertungsstellen Aufgaben im CRA-Rahmen wahrnehmen. Am 11. September 2026 beginnen die Meldepflichten für bestimmte Schwachstellen und Sicherheitsvorfälle. Erst am 11. Dezember 2027 gilt der große Anwendungsschritt mit den grundlegenden Anforderungen für Produkte mit digitalen Elementen.

Das BSI stellt die Stufen des CRA dar. Für Unternehmen bedeutet das: Bereits 2026 braucht es einen belastbaren Prozess zum Erkennen, Bewerten und Melden. Die vollständige technische und organisatorische Produktkonformität muss parallel für 2027 aufgebaut werden.

Der Stichtag ersetzt keine anderen Pflichten. Datenschutzverletzungen, sektorspezifische Vorfälle, vertragliche Informationspflichten und freiwillige koordinierte Schwachstellenmeldungen können schon vorher oder daneben relevant sein.

Welche Produkte grundsätzlich erfasst sein können

Der CRA betrifft Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz umfasst. Dazu können Software, Router, Kameras, smarte Haushaltsgeräte, industrielle Steuerungen, Apps und eingebettete Systeme gehören. Entscheidend ist nicht, ob ein Produkt als „smart“ beworben wird.

Ausnahmen und andere Rechtsrahmen müssen sorgfältig geprüft werden. Medizinprodukte, bestimmte Fahrzeuge, Luftfahrtprodukte oder Produkte für nationale Sicherheit können besonderen Regelungen unterliegen. Auch freie und quelloffene Software wird differenziert behandelt. Nichtkommerzielle Entwicklung ist nicht pauschal gleichzusetzen mit einem Unternehmen, das ein Open-Source-Bauteil wirtschaftlich vertreibt, integriert oder dauerhaft unterstützt.

Als praktische Grundlage sollten Hersteller Produktfamilien, Versionen, Unterstützungslaufzeiten, Softwarekomponenten und verantwortliche Rechtseinheiten erfassen. Händler und Importeure brauchen klare Ansprechpartner bei ihren Lieferanten. Eine Tabelle allein genügt nicht, wenn niemand für einen Eintrag, eine Sicherheitsentscheidung oder die Eskalation verantwortlich ist.

Was aktiv ausgenutzte Schwachstellen sind

Die Meldepflicht betrifft nicht jede theoretische Sicherheitslücke. Besonders relevant ist eine aktiv ausgenutzte Schwachstelle. Vereinfacht geht es um eine Schwäche, für die verlässliche Hinweise bestehen, dass Angreifer sie ohne Erlaubnis in einem System genutzt haben. Ein öffentliches Proof of Concept ist nicht zwingend ein Nachweis realer Ausnutzung, kann die Risikobewertung aber deutlich verändern.

Unternehmen brauchen Kriterien für die Evidenz. Hinweise können aus eigener Telemetrie, Kundenmeldungen, Incident-Response-Untersuchungen, Sicherheitsforschern, Behördenwarnungen oder vertrauenswürdigen Bedrohungsdaten kommen. Eine Behauptung in einem Forum darf nicht automatisch als bestätigter Angriff gelten. Umgekehrt ist absolute forensische Gewissheit nicht immer realistisch, bevor eine frühe Meldung erforderlich wird.

Dokumentieren Sie Quelle, Zeitpunkt, betroffene Version, beobachtetes Verhalten und Vertrauensgrad. Trennen Sie Tatsachen von Annahmen. Wird eine erste Einschätzung später korrigiert, muss auch die interne Fallakte aktualisiert werden. Das verbessert sowohl die Behördenmeldung als auch die Kommunikation mit Kunden.

Wann ein schwerer Sicherheitsvorfall vorliegt

Neben aktiv ausgenutzten Schwachstellen erfasst der CRA schwere Vorfälle, die die Sicherheit eines Produkts mit digitalen Elementen beeinträchtigen. Nicht jeder Absturz oder Supportfall ist ein solcher Vorfall. Wichtig sind insbesondere Ereignisse, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit erheblich beeinträchtigen und Folgen für Nutzer oder andere Systeme haben.

Beispiel: Eine Cloud-Funktion für smarte Türschlösser ist zwei Minuten nicht erreichbar, arbeitet danach normal und zeigt keine Manipulation. Das kann ein Betriebsproblem sein. Werden dagegen fremde Konten verknüpft, Zugangsdaten offengelegt oder Schlösser unbefugt steuerbar, entsteht eine deutlich andere Risikolage. Die Bewertung muss Produktzweck, Reichweite, Dauer, betroffene Nutzer und mögliche Folgeschäden berücksichtigen.

Ein Ereignis kann mehrere Rechtsregime zugleich berühren. Ein Datenabfluss kann eine Prüfung nach DSGVO auslösen. Betreiber kritischer oder wichtiger Einrichtungen können NIS2-bezogene Pflichten haben. Finanzunternehmen müssen gegebenenfalls DORA beachten. Ein gemeinsames Incident-Team kann Informationen koordinieren, darf aber nicht annehmen, dass eine CRA-Meldung andere Meldepflichten automatisch erfüllt.

Meldeweg und Informationsstände vorbereiten

Die Europäische Kommission erläutert in ihrer Leitlinie vom 27. Juli 2026 unter anderem Produktumfang, wesentliche Änderungen, Unterstützungslaufzeiten und Meldepflichten. Verantwortliche sollten vor dem Stichtag aktuelle offizielle Angaben zum Meldezugang, zu Registrierung und Rollenverteilung prüfen.

Gestufte Verfahren verlangen zwei Fähigkeiten zugleich: rasch warnen und dennoch verlässlich bleiben. Das gelingt mit klar gekennzeichneten Informationsständen. Verwenden Sie zum Beispiel die Kategorien „bestätigt“, „wahrscheinlich“ und „noch zu prüfen“. Nennen Sie außerdem, zu welchem Zeitpunkt die Einschätzung erstellt wurde.

Bereiten Sie einen Datensatz vor: Produktname, Modell, Version, Hersteller, Sicherheitskontakt, Art der Schwachstelle, bekannte Ausnutzung, betroffene Länder, Auswirkungen und bereits ergriffene Maßnahmen. Regeln Sie, wer eine Meldung freigibt, wenn Geschäftsleitung oder Rechtsabteilung nicht erreichbar sind. Eine kurze Frist ist kein geeigneter Moment, Vertretungsregeln erst zu erfinden.

Beispiel: Ein Sicherheitsvorfall bei einem smarten Router

Am Montag um 08:20 Uhr meldet ein Sicherheitsforscher, dass eine Authentifizierungsschwäche in Router-Version 5.4 aktiv ausgenutzt werde. Um 10:00 Uhr bestätigt der Hersteller verdächtige Anmeldeversuche bei mehreren Kunden. Nun beginnt nicht nur technische Analyse: Das Product-Security-Team eröffnet einen Vorgang, bewahrt Logs, bewertet die Hinweise und informiert die CRA-Meldeverantwortlichen.

Parallel wird geprüft, welche Modelle dieselbe Komponente nutzen, ob die Cloud oder nur lokal erreichbare Geräte betroffen sind und welche vorläufige Maßnahme das Risiko reduziert. Öffentlichkeitsarbeit sollte keine beruhigende Aussage veröffentlichen, bevor Umfang und Ursache klarer sind. Der Support benötigt dennoch eine freigegebene Zwischeninformation. Die erste Meldung beschreibt den bekannten Sachstand und markiert offene Punkte klar.

Nach einem Patch überwacht das Unternehmen Signatur, Rolloutquote und Installationsprobleme. Kunden erhalten klare Versionsangaben, ohne ausnutzbare technische Details unnötig zu verbreiten. Der Abschluss dokumentiert Ursache, Zeitlinie, Auswirkungen und Abhilfe. Danach folgt die Frage, warum die Schwäche nicht früher erkannt wurde und ob ähnliche Produkte überprüft werden müssen.

Was kleine Unternehmen vor September vorbereiten können

Ein kleiner Hersteller braucht kein rund um die Uhr besetztes Security Operations Center. Er braucht aber eindeutige Verantwortlichkeit. Benennen Sie eine primäre und eine stellvertretende Kontaktperson. Richten Sie eine überwachte Sicherheitsadresse ein. Definieren Sie, wer technische Schwere, rechtliche Meldepflicht und Kundenkommunikation bewertet.

Priorisieren Sie fünf Grundlagen: Produktinventar, Komponentenliste, Schwachstellenkanal, Incident-Playbook und Meldevorlage. Testen Sie den Ablauf mit einer kurzen Tabletop-Übung. Ein Moderator legt ein realistisches Szenario vor, das Team trifft Entscheidungen und notiert jede Unklarheit. Ziel ist nicht Perfektion, sondern das Sichtbarmachen von Lücken vor einem echten Vorfall.

Die ENISA-Seite zur Single Reporting Platform erläutert Zweck, Nutzer und aktuelle Anleitungen für den CRA-Meldeweg. Prüfen Sie außerdem Verträge mit Cloud-, Firmware- und Entwicklungsdienstleistern. Wenn ein Zulieferer einen Sicherheitsvorfall erst nach Tagen mitteilt, kann der Hersteller eigene Fristen möglicherweise nicht einhalten.

Häufige Fehlannahmen

Fehlannahme eins lautet: „Bis Dezember 2027 gilt gar nichts.“ Das stimmt nicht, denn bestimmte Meldepflichten beginnen am 11. September 2026. Fehlannahme zwei: „Ab September muss jedes bestehende Produkt vollständig CRA-konform sein.“ Auch das ist falsch. Die umfassenden Anforderungen greifen grundsätzlich erst am 11. Dezember 2027.

Fehlannahme drei lautet: „Nur Hardware ist betroffen.“ Der CRA kann auch Software erfassen. Fehlannahme vier: „Eine CVE-Nummer entscheidet automatisch über die Meldepflicht.“ Eine CVE ist nützlich, ersetzt aber nicht die Prüfung von Ausnutzung, Produktbezug und Vorfallsschwere. Fehlannahme fünf: „Der IT-Dienstleister meldet schon.“ Verantwortung lässt sich nicht durch Hoffnung delegieren.

CRA-Compliance ist kein einmaliger Auditordner. Sicherheitsupdates, Komponentenänderungen und neue Angriffskenntnisse verändern das Risiko über den gesamten Produktlebenszyklus. Ein Prozess, der nur vor Verkaufsstart existiert, verfehlt diesen Kern.

Checkliste für die letzten Wochen vor dem Meldestart

• Produkte, Versionen und verantwortliche Rechtseinheiten inventarisieren.
• Ausnahmen und sektorale Regeln prüfen.
• Sicherheitskontakt und Stellvertretung verbindlich benennen.
• Kriterien für aktive Ausnutzung und schwere Vorfälle dokumentieren.
• Offiziellen Meldezugang und Benutzerrollen prüfen.
• Vorlagen mit klar gekennzeichneten Unsicherheiten vorbereiten.
• Lieferanten zu raschen Sicherheitsmeldungen verpflichten.
• DSGVO-, NIS2-, DORA- und CRA-Abläufe abgleichen.
• Eine Tabletop-Übung durchführen und Aufgaben nachverfolgen.
• Die vollständige CRA-Roadmap bis Dezember 2027 getrennt weiterführen.

Der zentrale Punkt ist die Trennung der Termine: Ab 11. September 2026 gelten die relevanten CRA-Meldepflichten. Die vollständigen Anforderungen gelten grundsätzlich erst ab 11. Dezember 2027. Unternehmen sollten deshalb weder den frühen Meldestart übersehen noch den späteren umfassenden Anwendungstermin vorziehen.

Eine belastbare interne Entscheidungskette aufbauen

Die eigentliche Herausforderung einer CRA-Meldung liegt häufig nicht im Ausfüllen eines Formulars, sondern in der Frage, wie ein Unternehmen in kurzer Zeit zu einer nachvollziehbaren Entscheidung kommt. Sicherheitsinformationen treffen oft unvollständig ein. Ein Kunde berichtet über verdächtiges Verhalten, ein Sicherheitsforscher sendet einen technischen Hinweis oder ein Dienstleister meldet ein mögliches Problem in einer verwendeten Komponente. Diese Informationen müssen schnell an die richtigen Personen gelangen, ohne dass sie auf dem Weg verloren gehen oder voreilig nach außen kommuniziert werden.

Deshalb braucht jedes betroffene Unternehmen einen eindeutigen Eingangskanal für Sicherheitsmeldungen. Dieser Kanal sollte überwacht werden und klar regeln, wer einen Vorgang eröffnet. Eine Nachricht darf nicht in einem allgemeinen Supportpostfach liegen bleiben, nur weil sie technisch formuliert ist oder nicht sofort einem Produkt zugeordnet werden kann. Ebenso wichtig ist eine Vertretung. Wenn die einzige Person mit Sicherheitswissen nicht erreichbar ist, muss klar sein, wer die erste Bewertung veranlasst, wer technische Logs sichert und wer Entscheidungen eskalieren darf.

Die erste Bewertung sollte nicht versuchen, jede Ursache sofort abschließend zu erklären. Sie sollte vielmehr festhalten, was bekannt ist, welche Produkte oder Versionen möglicherweise betroffen sind, welche Belege vorliegen und welche Untersuchungsschritte laufen. Dabei hilft eine gemeinsame Sprache für den Vertrauensgrad. Fakten aus eigenen Protokollen, Aussagen von Kunden, Angaben eines Lieferanten und bloße Vermutungen sollten nicht vermischt werden. Wer diese Ebenen trennt, kann früh reagieren und spätere Erkenntnisse sauber nachtragen, ohne den Eindruck zu erzeugen, frühere Aussagen seien willkürlich gewesen.

In der Praxis ist eine Rollenmatrix nützlich. Das Product-Security-Team beurteilt den technischen Sachstand. Produktverantwortliche ordnen ein, welche Varianten, Vertriebswege und Kunden betroffen sein können. Recht oder Compliance prüft die regulatorische Einordnung. Kommunikation und Support bereiten verständliche Informationen für betroffene Nutzer vor. Die Geschäftsleitung muss nicht jede operative Feststellung selbst treffen, sollte aber wissen, welche Entscheidungen eskalationspflichtig sind. Wichtig ist, dass nicht mehrere Abteilungen darauf warten, dass jemand anderes die Meldung veranlasst.

Diese Struktur darf nicht zu einem starren Freigabeprozess werden. Bei Sicherheitsereignissen kann es notwendig sein, mit einem vorläufigen Sachstand zu handeln. Ein festgelegter Bereitschaftsweg hilft, wenn die reguläre Leitung nicht erreichbar ist. Dokumentieren Sie, wer auf welcher Grundlage entschieden hat. Eine kurze, sachliche Notiz zur Abwägung ist wertvoller als eine nachträglich rekonstruierte Erinnerung. Sie macht sichtbar, dass das Unternehmen nicht nur technische Maßnahmen, sondern auch seine Meldeentscheidung kontrolliert gesteuert hat.

Ein Incident-Playbook sollte außerdem die Übergabe zwischen Teams abdecken. Die Person, die einen Hinweis entgegennimmt, braucht keine vollständige forensische Expertise. Sie muss aber wissen, welche Informationen sofort zu sichern sind, an wen sie weitergeleitet werden und welche vertraulichen Daten nicht über unsichere Kanäle versendet werden dürfen. Ein klarer Ablauf verhindert, dass Logs überschrieben, Beweismittel verändert oder sensible technische Details zu früh verbreitet werden. Gerade kleinere Hersteller profitieren von einfachen, regelmäßig getesteten Regeln mehr als von umfangreichen Dokumenten, die im Ernstfall niemand findet.

Lieferkette, Komponenten und Produktvarianten beherrschbar machen

Viele Sicherheitsvorfälle betreffen nicht nur ein einzelnes Produkt, sondern eine Komponente, die in mehreren Varianten oder Produktfamilien eingesetzt wird. Eine Schwachstelle in einer Bibliothek, einem Cloud-Dienst, einer Firmware-Komponente oder einem Verwaltungsportal kann deshalb Auswirkungen haben, die zu Beginn nicht sichtbar sind. Unternehmen sollten vor einem Vorfall nachvollziehen können, welche Softwarebestandteile wo verwendet werden und welche verantwortliche Stelle für Updates zuständig ist.

Dafür genügt es nicht, lediglich Einkaufslisten oder Quellcode-Archive zu besitzen. Entscheidend ist die Verbindung zwischen Komponente, ausgelieferter Version, Produktvariante, Kundenumgebung und Wartungszuständigkeit. Wenn ein Lieferant eine Sicherheitswarnung versendet, muss schnell erkennbar sein, ob das eigene Produkt betroffen sein könnte, ob eine abgeschaltete Funktion dennoch erreichbar ist und ob ältere Versionen weiterhin unterstützt werden. Diese Transparenz beschleunigt sowohl die technische Bewertung als auch die Vorbereitung einer möglichen Meldung.

Verträge mit Lieferanten und Entwicklungsdienstleistern sollten den Umgang mit Sicherheitsinformationen praktisch regelbar machen. Dazu gehören benannte Sicherheitskontakte, eine Pflicht zur raschen Weitergabe relevanter Erkenntnisse, ein Verfahren für vertrauliche technische Details und klare Erwartungen an Unterstützung bei Analyse und Abhilfe. Ein Lieferant kann für eine Komponente wichtiges Wissen haben. Dennoch bleibt die Frage bestehen, wer für das Produkt auf dem Markt die Gesamtübersicht hat und die erforderlichen Schritte koordiniert. Diese Verantwortung sollte nicht erst während eines Vorfalls ausgehandelt werden.

Besonders anspruchsvoll sind Produkte mit Cloud-Anbindung. Ein Problem kann im Gerät, in einer mobilen Anwendung, in einem Identitätsdienst oder in einer serverseitigen Schnittstelle liegen. Für Nutzer ist die technische Grenze oft unsichtbar. Die interne Bewertung muss sie dennoch sauber ziehen. Halten Sie fest, welche Funktion ausfällt oder manipulierbar ist, welche Schutzwirkung dadurch beeinträchtigt wird und ob alternative Zugänge bestehen. Eine präzise technische Abgrenzung hilft, Schutzmaßnahmen zielgerichtet zu wählen und die Auswirkungen verständlich zu beschreiben.

Auch Produktänderungen brauchen einen geregelten Sicherheitsblick. Ein neues Firmware-Modul, ein Wechsel des Hosting-Anbieters oder eine veränderte Authentifizierung kann die bisherige Risikobewertung verändern. Deshalb sollte der Sicherheitsprozess nicht nur reagieren, wenn eine externe Warnung eingeht. Er sollte bei wesentlichen Änderungen sicherstellen, dass Inventar, Ansprechpartner, Logging und Rückfallmöglichkeiten weiterhin passen. Wer nach einer Änderung nicht mehr weiß, welche Version im Feld läuft, kann einen Sicherheitsvorfall nur schwer eingrenzen.

Unternehmen sollten ferner zwischen bekannten und tatsächlich betroffenen Komponenten unterscheiden. Der Umstand, dass eine Schwachstelle öffentlich diskutiert wird, bedeutet nicht automatisch, dass jedes Produkt mit einem ähnlich benannten Baustein betroffen ist. Umgekehrt kann eine abweichende interne Anpassung einen Fall erschweren, weil Standardinformationen nicht unmittelbar passen. Eine dokumentierte Prüfung mit Ergebnis, Belegen und Zuständigkeit ist daher sinnvoll, auch wenn sich am Ende herausstellt, dass keine Auswirkung vorliegt. Sie schafft Wiederholbarkeit für ähnliche Hinweise.

Kommunikation mit Kunden und Behörden getrennt, aber abgestimmt führen

Technische Untersuchung, behördliche Meldung und Kundenkommunikation verfolgen unterschiedliche Ziele. Sie müssen abgestimmt sein, sollten jedoch nicht denselben Text verwenden. Eine Meldung benötigt einen möglichst genauen Sachstand und kann offene Punkte ausdrücklich kennzeichnen. Kunden benötigen vor allem verständliche Hinweise dazu, ob sie betroffen sein könnten, welche Schutzmaßnahmen sie ergreifen sollen und wo sie Hilfe bekommen. Eine öffentliche Nachricht darf weder Risiken verharmlosen noch detaillierte Ausnutzungsanleitungen liefern.

Bereiten Sie vorab Textbausteine für verschiedene Lagen vor. Dazu gehören eine Eingangsbestätigung für Sicherheitsforscher, eine interne Information an Support und Vertrieb, ein Hinweis für betroffene Kunden sowie eine aktualisierte Meldung nach neuen Erkenntnissen. Solche Vorlagen müssen flexibel bleiben. Sie sollten keine Tatsachen behaupten, die noch nicht bestätigt sind. Nützlich sind klare Formulierungen wie „wir untersuchen“, „nach derzeitiger Bewertung“ oder „folgende Schutzmaßnahme steht zur Verfügung“. Ergänzen Sie immer einen Kontaktweg für Rückfragen.

Der Support ist während eines Vorfalls ein wichtiger Teil der Sicherheitsreaktion. Mitarbeitende benötigen eine freigegebene, aktuelle Antwort und eine klare Eskalationsregel. Ohne diese Vorbereitung entstehen widersprüchliche Aussagen, die Vertrauen beschädigen und die Lage für Kunden unübersichtlich machen. Supportteams sollten wissen, welche Informationen sie abfragen dürfen, wie verdächtige Beobachtungen weitergeleitet werden und wann sie keine weitere technische Einschätzung abgeben sollen. Besonders bei Produkten mit physischen Auswirkungen kann eine verständliche Handlungsanweisung wichtiger sein als eine lange Hintergrundbeschreibung.

Kommunikation sollte auch die Phase nach einem Patch abdecken. Ein bereitgestelltes Update ist nicht automatisch auf allen Geräten installiert. Prüfen Sie deshalb, wie Nutzer über die Verfügbarkeit informiert werden, wie Installationsprobleme sichtbar werden und wie mit nicht mehr unterstützten Varianten umgegangen wird. Wenn eine Zwischenmaßnahme empfohlen wird, muss sie realistisch umsetzbar sein. Eine Anweisung, die Zugangsdaten, Fachwissen oder dauerhafte Überwachung voraussetzt, hilft vielen Kunden nur begrenzt.

Nach Abschluss der akuten Reaktion lohnt sich eine strukturierte Nachbesprechung. Dabei geht es nicht um Schuldzuweisung, sondern um die Frage, wo der Ablauf verlässlich war und wo Reibung entstand. Wurde ein Hinweis schnell genug erkannt? Waren Produktdaten vollständig? Konnte die richtige Person erreicht werden? Waren Kundeninformationen verständlich? Wurden Erkenntnisse aus Lieferantenmeldungen ohne Verzögerung verarbeitet? Die Antworten sollten in konkrete Verbesserungen münden, etwa in angepasste Verträge, bessere Inventardaten, zusätzliche Übungen oder präzisere Vorlagen.

So wird die Meldepflicht Teil eines dauerhaften Produkt-Sicherheitsprozesses. Ein Unternehmen, das Zuständigkeiten, Komponentenwissen und Kommunikation vor einem realen Vorfall vorbereitet, kann schneller und ruhiger handeln. Das verbessert nicht nur die regulatorische Reaktionsfähigkeit. Es hilft vor allem dabei, Risiken für Nutzer früh einzugrenzen, technische Maßnahmen nachvollziehbar umzusetzen und Vertrauen nicht durch widersprüchliche oder verspätete Informationen zu verlieren.

Quellen und weiterführende Informationen

• EUR-Lex: Cyber Resilience Act im Wortlaut
• BSI: Zeitplan und Anwendungsbereich
• Europäische Kommission: Umsetzungsleitlinie
• Europäische Kommission: CRA-Übersicht
• ENISA: Single Reporting Platform zum CRA