Technik

Ab 11. September 2026 gelten CRA-Meldepflichten: 6 Prüfschritte für Produktteams

CRA-Meldepflichten ab 11. September 2026: Sechs Prüfschritte helfen Produktteams, Rollen, Auslöser und Eskalationswege sauber vorzubereiten.

Von Wolfgang

29. Juli 20266 Min. Lesezeit

CRA-Meldepflichten ab 11. September 2026: Sechs Prüfschritte helfen Produktteams, Rollen, Auslöser und Eskalationswege sauber vorzubereiten.

Ab dem 11. September 2026 müssen Unternehmen mögliche CRA-Meldefälle früher und geordneter behandeln als bisher. Für Produktteams geht es jetzt weniger um eine abstrakte Verordnung als um eine praktische Frage: Wer erkennt einen kritischen Sicherheitsfall, wer ordnet ihn ein und wer bringt die nötigen Informationen rechtzeitig zusammen?

Das Wichtigste in 30 Sekunden

Die vorgezogenen CRA-Berichtspflichten beginnen am 11. September 2026. Die volle Anwendung der Verordnung folgt erst am 11. Dezember 2027.
Die Europäische Kommission hat am 27. Juli 2026 eine unverbindliche Leitlinie mit 67 Beispielen, Fallkonstellationen, Flussdiagrammen und Grafiken veröffentlicht.
Die Leitlinie ersetzt weder die Verordnung (EU) 2024/2847 noch die Prüfung eines konkreten Produkts oder Vorfalls.
Hilfreich ist ein dokumentierter Prüfpfad: Produkt und Rolle klären, mögliche Auslöser trennen, Zuständigkeiten festlegen und offene Fragen sichtbar weitergeben.

Drei Fachleute besprechen an einem Arbeitstisch ein neutrales vernetztes Gerät, Skizzen und Unterlagen. — Vor einem möglichen Meldefall müssen technische Fakten, Produktkontext und Zuständigkeiten zusammenkommen – durch KI erzeugt

Ein Sicherheitsfund wird schnell zum Organisationsproblem, wenn Entwicklung, Product Security, Support und Rechtsprüfung unterschiedliche Informationen haben. Genau an diesen Übergaben entstehen Verzögerungen: Ein Team kennt die technische Schwachstelle, ein anderes den Produktkontext, ein drittes den Vertriebsweg. Die neue CRA-Leitlinie der Europäischen Kommission hilft nicht mit einer Pauschalantwort. Sie macht die Fragen sichtbar, die Teams vor einem möglichen Meldefall sauber sortieren sollten.

Was am 11. September beginnt – und was 2027 folgt

Die beiden Termine werden oft vermischt. Das wäre für die Vorbereitung ein Fehler. Ab dem 11. September 2026 greifen die vorgezogenen Berichtspflichten für die im Cyber Resilience Act geregelten aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfälle. Die volle Anwendung des CRA ist für den 11. Dezember 2027 vorgesehen.

Datum	Einordnung	Praktische Folge
11. September 2026	Beginn der vorgezogenen Berichtspflichten	Teams sollten mögliche einschlägige Fälle intern erkennen, einordnen und weiterleiten können.
11. Dezember 2027	Volle Anwendung des CRA	Die weiteren Anforderungen der Verordnung greifen; der frühere Meldetermin bleibt weiterhin relevant.

Das bedeutet nicht, dass jedes digitale Produkt, jeder Fehler oder jedes Update automatisch einen Meldefall auslöst. Auch die Übergangsregeln sind kein Freibrief für pauschale Annahmen. Entscheidend ist der konkrete Sachverhalt.

Warum die neue Leitlinie praktisch hilft

Die Kommission veröffentlichte ihre erste praktische CRA-Leitlinie am 27. Juli 2026. Sie enthält 67 Beispiele und greift Themen auf, die in Produktorganisationen häufig auseinanderlaufen: Geltungsbereich, Remote-Datenverarbeitung, freie und Open-Source-Software, wesentliche Änderungen, Supportzeiträume, Risikoanalysen und Meldungen.

Der Wert dieser Guidance liegt in der Struktur, nicht in einer neuen Rechtslage. Sie ist ausdrücklich unverbindlich. Verbindlich bleibt die Verordnung (EU) 2024/2847. Wer eine konkrete Produkt- oder Vorfallfrage entscheiden muss, braucht deshalb weiterhin den Gesetzestext und gegebenenfalls qualifizierte Rechtsprüfung. Für die interne Vorbereitung kann die Leitlinie trotzdem sehr nützlich sein: Sie verhindert, dass Teams erst im Ernstfall beginnen, Rollen und Informationswege zu suchen.

Eine sachliche Arbeitsgrafik verbindet technisches Gerät, Produktkarte, interne Kontaktstelle und offenen Prüfungsordner. — Ein technischer Fund wird erst mit Produktkontext, Eskalation und fachlicher Prüfung sinnvoll eingeordnet – durch KI erzeugt

Sechs Prüfschritte für Produktteams

Produkt und eigene Rolle kartieren. Halten Sie fest, welches Produkt mit digitalen Elementen betrachtet wird, wie es bereitgestellt wird und welche wirtschaftliche Rolle das eigene Unternehmen einnimmt. Ein Schlagwort wie „Software“ oder „Open Source“ reicht für die Einordnung nicht aus. Als Ergebnis sollte eine nachvollziehbare Produkt- und Rollenbeschreibung vorliegen.
Mögliche Meldeauslöser von gewöhnlichen Fehlern trennen. Aktiv ausgenutzte Schwachstellen, schwere Sicherheitsvorfälle und normale Fehlerbilder dürfen nicht in einen Topf fallen. Der Prüfschritt beantwortet nicht selbst die Rechtsfrage; er sorgt dafür, dass ein potenziell relevanter Fall rechtzeitig an die richtigen Stellen gelangt. Hilfreich ist eine kurze Dokumentation, warum eine Eskalation ausgelöst oder nicht ausgelöst wurde.
Erkennung, Eskalation und Prüfung festlegen. Entwicklung, Product Security, Management und Rechtsprüfung brauchen eine erkennbare Reihenfolge. Wer informiert wen? Welche technischen Fakten müssen bereitstehen? Wer dokumentiert die Entscheidung? Ein Ablauf ist nur dann brauchbar, wenn er nicht allein in den Köpfen einzelner Personen existiert.
Open-Source-Konstellationen getrennt betrachten. Nicht-kommerzielle Beiträge, kommerzielle Bereitstellung und die Rolle eines Open-Source-Software-Stewards sind unterschiedliche Konstellationen. Die Guidance und Artikel 24 des CRA verlangen hier eine fallbezogene Betrachtung. Teams sollten deshalb Unterstützung, Verantwortung und Produktbezug dokumentieren, statt Open Source pauschal ein- oder auszuschließen.
Änderungen am Produkt nachvollziehbar machen. Ein normales Wartungsupdate ist nicht automatisch eine wesentliche Änderung. Relevant ist, wie sich Produkt, Funktion und Verantwortung im konkreten Fall verändern. Eine kurze Entscheidungsspur mit Anlass, Verantwortlichen und Begründung verhindert späteres Rätselraten.
Support, Risikoarbeit und Nachweise zusammenführen. Supportzeitraum, bekannte Schwachstellen, Risikobewertung und Zuständigkeiten liegen in vielen Organisationen in getrennten Systemen. Vor dem Reporting-Start sollten Teams prüfen, ob diese Informationen bei einem kritischen Fall zusammengeführt werden können. Offene Rechts- oder Security-Fragen müssen sichtbar an Product Security und Rechtsprüfung zur Prüfung übergeben werden, statt in einer stillschweigenden Annahme zu verschwinden.

Open Source und Updates richtig einordnen

Gerade bei Open Source führt eine Ja-Nein-Logik in die Irre. Die Kommissionsleitlinie behandelt nicht-kommerzielle Beiträge, kommerzielle Bereitstellung und Open-Source-Software-Stewards als getrennte Konstellationen. Bei Stewards kann die Reichweite einzelner Pflichten von der Art der tatsächlich geleisteten Unterstützung abhängen. Das ist kein Grund, die Frage aufzuschieben. Es ist ein Grund, sie sauber zu dokumentieren.

Ähnlich vorsichtig sollten Teams mit Updates umgehen. Nicht jede Aktualisierung verändert ein Produkt rechtlich in derselben Weise. Sinnvoll ist daher kein Automatismus, sondern ein wiederholbarer Prüfvermerk: Was wurde geändert, welche Rolle hat das Team dabei und weshalb wird der Fall so eingeordnet? Damit bleibt die Entscheidung auch dann nachvollziehbar, wenn später andere Beteiligte hinzukommen.

Ein Werkbank-Stillleben zeigt eine neutrale Platine, unlesbare Notizen, drei Karten, ein Modul und einen Aktenordner. — Bei Open Source und Produktänderungen entscheidet der konkrete Fall, nicht ein einzelnes Schlagwort – durch KI erzeugt

Typische Fehlstarts vermeiden

Alle Vorfälle gleich behandeln: Das erzeugt Lärm und verdeckt mögliche relevante Fälle.
2026 und 2027 zusammenziehen: Berichtspflichten ab September 2026 sind nicht mit der vollen Anwendung ab Dezember 2027 gleichzusetzen.
Die Guidance wie Gesetz lesen: Sie ist eine praktische Orientierung, keine bindende Einzelfallentscheidung.
FOSS pauschal behandeln: Rolle, Unterstützung und konkrete Bereitstellung müssen getrennt betrachtet werden.
Zuständigkeiten offenlassen: Ein guter Prozess scheitert, wenn technische Fakten und Entscheidungswege erst im Ereignisfall gesucht werden.

Woran eine brauchbare Vorbereitung zu erkennen ist

Ein Team muss damit noch nicht „CRA-konform“ sein. Eine brauchbare Vorbereitung zeigt sich an einfacheren Dingen: Die betroffenen Produkte und Rollen sind auffindbar, potenzielle Auslöser werden nicht mit jedem Fehler verwechselt, für die Eskalation sind klare Verantwortliche benannt und Entscheidungen lassen sich mit Fakten und Verantwortlichkeiten nachvollziehen. Wo diese Kette reißt, liegt der nächste Prüfauftrag.

FAQ

Gilt ab 11. September 2026 der gesamte Cyber Resilience Act?

Nein. Zu diesem Datum beginnen die vorgezogenen Berichtspflichten für die im CRA geregelten aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfälle. Die volle Anwendung der Verordnung ist für den 11. Dezember 2027 vorgesehen.

Ist jedes Softwareprojekt oder jedes Update automatisch vom CRA betroffen?

Nein. Der konkrete Produktbezug, die eigene Rolle und die Art der Änderung müssen im Einzelfall geprüft werden. Die Kommissionsleitlinie hilft beim Strukturieren dieser Fragen, ersetzt die Prüfung aber nicht.

Ist die Sechs-Schritte-Liste ein Compliance-Nachweis?

Nein. Sie ist eine redaktionelle Vorbereitungshilfe. Sie kann Teams helfen, Zuständigkeiten und Informationen zu ordnen, trifft aber keine verbindliche rechtliche Einordnung.