Autor: TJC Group Content Team
Ab dem 11. September 2026 stehen Hersteller von Produkten mit digitalen Elementen, die unter den EU Cyber Resilience Act (CRA) fallen, vor einer neuen Meldepflicht. Wenn sie Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erhalten, der die Kriterien des Artikels 14 erfüllt, muss die erste Meldung innerhalb von 24 Stunden erfolgen.
Für Softwareentwickler, einschließlich Unternehmen, die Produkte für SAP-Umgebungen entwickeln, ist es nun zwingend erforderlich zu wissen, was meldepflichtig ist und wie die erforderlichen Informationen fristgerecht die Behörden erreichen. Wenn Kunden solche Probleme identifizieren, müssen sie den Lieferanten informieren.
Die wichtigsten Erkenntnisse
- Die Meldepflichten gemäß CRA Artikel 14 gelten ab dem 11. September 2026.
- Der CRA gilt für relevante Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden.
- Hersteller müssen bestimmte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, die Produkte mit digitalen Elementen betreffen.
- Eine erste Frühwarnung ist unverzüglich und innerhalb von 24 Stunden nach Kenntnisnahme erforderlich.
- Eine detailliertere Meldung folgt innerhalb von 72 Stunden.
- Nicht jede Schwachstelle löst Artikel 14 aus. Die Meldepflicht für Schwachstellen gilt, wenn zuverlässige Beweise für eine böswillige Ausnutzung vorliegen.
- Meldungen werden über die Europäische Agentur für Cybersicherheit (ENISA) CRA Single Reporting Platform eingereicht, wobei das zuständige CSIRT als Koordinator benannt ist.
- Für SAP-Partner, die eigene Softwareprodukte entwickeln, sollte die Vorbereitung auf eine schnelle Bewertung, definierte Verantwortlichkeiten, Dokumentation und Eskalation abzielen.
Was ist der EU Cyber Resilience Act?
Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die darauf abzielt, die Cybersicherheit von Hardware- und Softwareprodukten mit digitalen Elementen, die auf dem europäischen Markt bereitgestellt werden, zu stärken.
Die Europäische Kommission hat den Gesetzesentwurf am 15. September 2022 vorgeschlagen. Die endgültige Verordnung trat am 10. Dezember 2024 in Kraft, während die meisten Bestimmungen ab dem 11. Dezember 2027 vollständig anwendbar werden. Die Meldepflichten gemäß Artikel 14 treten früher in Kraft, nämlich ab dem 11. September 2026.
Der CRA zielt darauf ab, Cybersicherheitsanforderungen für die Entwicklung und Wartung digitaler Produkte festzulegen und den Nutzern bessere Informationen über die Sicherheit der von ihnen gekauften und verwendeten Produkte zu geben.
Die Cybersicherheitsverantwortung endet nicht mit der Veröffentlichung von Software. Hersteller müssen auch die richtigen Prozesse implementieren, um Schwachstellen zu identifizieren, Sicherheitsvorfälle zu handhaben, Produkte zu warten und Sicherheitsupdates während des gesamten relevanten Produktlebenszyklus bereitzustellen.
Artikel 14 fügt dieser umfassenderen Verantwortung eine zeitkritische Meldepflicht hinzu.
Für Softwareentwickler im SAP-Ökosystem wird der CRA besonders relevant, wenn sie eigene Produkte mit digitalen Elementen auf dem EU-Markt entwickeln und bereitstellen.
Was verlangt CRA Artikel 14?
Artikel 14 konzentriert sich auf zwei spezifische Arten von Sicherheitsereignissen.
Aktiv ausgenutzte Schwachstellen
Eine aktiv ausgenutzte Schwachstelle ist eine Schwachstelle, für die es zuverlässige Beweise gibt, dass ein böswilliger Akteur sie in einem System ohne die Erlaubnis des Systeminhabers ausgenutzt hat.
Dies bedeutet nicht, dass jede in einem Softwareprodukt entdeckte Schwachstelle zu einem Artikel-14-Bericht wird. Die Unterscheidung hängt vom Nachweis der Ausnutzung und nicht allein von der Entdeckung der Schwachstelle ab.
Ein Entwicklungsteam kann beispielsweise während interner Tests eine Schwachstelle identifizieren und diese beheben, bevor es Beweise für eine böswillige Ausnutzung gibt. Die Schwachstelle erfordert weiterhin eine angemessene Behandlung, erfüllt aber nicht die Definition einer aktiv ausgenutzten Schwachstelle gemäß Artikel 14, nur weil sie existiert.
Dies ist nicht dasselbe wie die bloße Entdeckung einer CVE oder Schwachstelle. Eine CVE, die UI5, Node.js, Java, eine SAP BTP-Abhängigkeit oder eine ABAP-Komponente betrifft, ist nicht automatisch gemäß Artikel 14 meldepflichtig. Dasselbe gilt für einen auf GitHub veröffentlichten Exploit, eine Feststellung eines Penetrationstests, einen von einem autorisierten Forscher demonstrierten PoC oder einen Bug-Bounty-Bericht ohne Nachweis einer böswilligen Nutzung. Die CRA Hub FAQ unterscheidet ausdrücklich zwischen gutgläubiger Sicherheitsforschung und böswilliger Ausnutzung.
Schwerwiegende Sicherheitsvorfälle
Artikel 14 umfasst auch schwerwiegende Vorfälle, die Auswirkungen auf die Sicherheit eines Produkts mit digitalen Elementen haben.
Die ENISA beschreibt einen Vorfall, der die Produktsicherheit beeinträchtigt, als einen, der die Fähigkeit des Produkts, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit seiner Daten oder Funktionen zu schützen, negativ beeinflusst oder beeinflussen kann. Artikel 14 legt dann den Schwellenwert fest, ab dem ein solcher Vorfall als schwerwiegend gilt.
CRA Artikel 14 definiert einen schwerwiegenden Vorfall als einen, der sensible/wichtige Daten oder Funktionen beeinträchtigen kann oder bei dem bösartiger Code in das Produkt oder das Netzwerk des Benutzers eingeführt/ausgeführt wurde oder werden könnte.
Die zugrunde liegende Definition eines „Vorfalls“ stammt aus der NIS2-Richtlinie und bezieht sich auf „ein Ereignis, das die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit beeinträchtigt“. Mit anderen Worten, eine rein theoretische Schwachstelle ist selbst kein Vorfall.
Ein routinemäßiger Softwarefehler oder ein geringfügiges technisches Problem sollte nicht automatisch als Artikel-14-Ereignis behandelt werden. Der Hersteller muss die Art des Vorfalls und seine tatsächlichen oder potenziellen Sicherheitsauswirkungen bewerten.
Wann beginnt die Meldefrist?
Der Meldeprozess beginnt, wenn der Hersteller Kenntnis von der aktiv ausgenutzten Schwachstelle oder dem schwerwiegenden Sicherheitsvorfall erlangt.
Dies macht die interne Eskalation besonders wichtig.
Ein Sicherheitsproblem kann zunächst einen Entwickler, ein Support-Team, einen kundennahen Mitarbeiter oder einen Cybersicherheitsspezialisten erreichen. Wenn die Organisation keinen klaren Weg zur Eskalation potenzieller Artikel-14-Ereignisse hat, kann ein Teil des Meldezeitraums verstreichen, bevor das richtige Team involviert wird.
Zeitplan für die Meldung gemäß Artikel 14
| Meldestufe | Aktiv ausgenutzte Schwachstelle | Schwerwiegender Sicherheitsvorfall |
|---|---|---|
| Frühwarnung | Innerhalb von 24 Stunden nach Kenntnisnahme | Innerhalb von 24 Stunden nach Kenntnisnahme |
| Detaillierte Meldung | Innerhalb von 72 Stunden nach Kenntnisnahme | Innerhalb von 72 Stunden nach Kenntnisnahme |
| Abschlussbericht | Spätestens 14 Tage nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist | Innerhalb eines Monats nach der 72-Stunden-Meldung |
Die Europäische Kommission und die ENISA bestätigen beide diese Meldestufen.
Was Artikel 14 für Softwareentwickler und SAP-Partner bedeutet
Für Organisationen, die Software in der SAP-Landschaft entwickeln, macht Artikel 14 die Qualifizierung von Sicherheitsereignissen zu einem zeitkritischen Prozess.
Schnelle Schwachstellenbewertung
Entwicklungs- und Sicherheitsteams müssen unterscheiden zwischen:
- einem gewöhnlichen Softwarefehler;
- einer Schwachstelle, die behoben werden muss;
- einer aktiv ausgenutzten Schwachstelle;
- einem Sicherheitsvorfall; und
- einem Vorfall, der schwerwiegend genug ist, um die Kriterien des Artikels 14 zu erfüllen.
Ziel ist es, sicherzustellen, dass potenziell meldepflichtige Ereignisse schnell genug die richtigen Personen erreichen, damit eine Entscheidung getroffen werden kann.
Wer ist für die Reaktion verantwortlich?
Hersteller müssen nun die Person(en) oder das Team(s) benennen, die verantwortlich sind für:
- die Bewertung, ob der Vorfall gemeldet werden muss; und
- die ordnungsgemäße Meldung an die ENISA innerhalb des 24-Stunden-Fensters.
Eine klare Aufzeichnung der Reaktion führen
Eine zuverlässige Aufzeichnung der Reaktion sollte ebenfalls aufbewahrt werden. Es sollte möglich sein festzustellen, wann das Problem erstmals identifiziert wurde, wann der Hersteller davon Kenntnis erlangte, welches Produkt und welche Version betroffen waren, welche Beweise verfügbar waren und wie die erste Sicherheitsbewertung erfolgte.
Die aktuelle Anleitung der ENISA für die Single Reporting Platform enthält Felder, die Bereiche wie Produkt, Produktversion, Zeitpunkt der Kenntnisnahme, Auswirkungen, Minderung und ereignisspezifische Informationen abdecken.
Was Artikel 14 für SAP-Kunden bedeutet
Sind SAP-Kunden verpflichtet, aktiv ausgenutzte Produktschwachstellen zu melden? Die Antwort ist nein. Gemäß Artikel 14 des EU Cyber Resilience Act (CRA) ist ein gewöhnlicher SAP-Kunde nicht verpflichtet, Schwachstellen in TJC Group- oder SAP-Produkten an die ENISA oder ein nationales CSIRT zu melden. Dennoch sollten Kunden Lieferanten wie die TJC Group informieren, damit wir darauf reagieren können.
Artikel 14 legt die Meldepflichten hauptsächlich den Herstellern auf, aber auch Kunden haben ein Interesse daran zu verstehen, wie ihre Softwareanbieter mit schwerwiegenden Sicherheitsereignissen umgehen.
Unabhängig davon können SAP-Kunden separate Meldepflichten gemäß Gesetzen wie NIS2, DORA, DSGVO, sektorspezifischen Vorschriften usw. haben.
Wie bereitet sich die TJC Group auf den CRA Artikel 14 vor?
Wir haben die Anforderungen von CRA Artikel 14 überprüft und die richtigen Prozesse implementiert, um innerhalb des 24/72-Stunden-Fensters zu reagieren. Wenn die TJC Group Kenntnis davon erlangt, dass eine Schwachstelle in einem TJC-Produkt böswillig aktiv ausgenutzt wurde und die in diesem Artikel dargelegten Kriterien erfüllt sind, werden wir dies ordnungsgemäß über die CRA Single Reporting Platform an die ENISA melden. Denselben Mechanismus wenden wir an, wenn wir ein Problem in unseren internen Systemen identifizieren.
Wenn Ihre Organisation ein Produkt der TJC Group verwendet und Sie weitere Informationen darüber wünschen, wen Sie im Falle einer Aktivierung von Artikel 14 kontaktieren können, wenden Sie sich bitte an Ihren lokalen TJC-Vertreter, und wir werden uns umgehend mit Ihnen in Verbindung setzen.
TJC Group, ISO 27001-zertifiziert
Die TJC Group hat im Jahr 2024 die ISO 27001-Zertifizierung nach der Einrichtung eines Informationssicherheits-Managementsystems (ISMS) gemäß den Anforderungen des Standards erhalten.
ISO 27001 bietet einen international anerkannten Rahmen für das Management von Informationssicherheitsrisiken durch definierte Richtlinien, Kontrollen und Prozesse.
Die Zertifizierung der TJC Group spiegelt ihr Engagement wider, die Vertraulichkeit, Integrität und Verfügbarkeit sensibler Informationen zu schützen und ihr ISMS kontinuierlich zu pflegen und zu verbessern.
Die ISO 27001-Zertifizierung ersetzt nicht die spezifischen Verpflichtungen, die durch den CRA eingeführt wurden, bietet aber eine strukturierte Grundlage für das Management von Informationssicherheitsrisiken, Verantwortlichkeiten und Prozessen.
Cybersicherheit in der SAP-Landschaft
Cybersicherheit ist nicht auf die Reaktion auf Vorfälle beschränkt. Sie umfasst auch, wie Produkte entwickelt, Schwachstellen bewertet, Zugriffe kontrolliert, Systeme gewartet und Informationen während ihres gesamten Lebenszyklus geschützt werden.
Diese umfassenderen Prioritäten werden in dem Leitfaden der TJC Group zur Datensicherheit im Jahr 2026 weiter untersucht.
Cybersicherheit überschneidet sich auch mit dem SAP-Datenmanagement. Die Reduzierung unnötiger Exposition, die Kontrolle des Zugriffs auf historische Informationen und die Aufrechterhaltung geeigneter Umgebungen tragen alle zu einer stärkeren Sicherheitslage bei. Die Beziehung zwischen Datenarchivierung und Cybersicherheit ist in diesem Zusammenhang besonders relevant.
Ältere Anwendungen können auch dann weiterhin Risiken schaffen, wenn sie nicht mehr aktiv entwickelt werden, weshalb die Sicherheit von Altsystemen neben den neueren CRA-Verpflichtungen relevant bleibt.
Weitere Anleitungen finden Sie in den Cybersicherheitsressourcen der TJC Group.
Fazit
CRA Artikel 14 teilt Herstellern mit, was sie tun müssen, wenn sie schwerwiegende Cybersicherheitsprobleme entdecken, die ihre digitalen Produkte betreffen. Ein Hersteller muss aktiv ausgenutzte Schwachstellen, die seine Produkte betreffen, dem zuständigen nationalen CSIRT und der ENISA melden.
Artikel 14 verlangt nicht von Herstellern, jede „schwerwiegende Schwachstelle“ zu melden. Er verlangt die Meldung von zwei spezifischen Dingen:
- einer aktiv ausgenutzten Schwachstelle; und
- einem schwerwiegenden Vorfall, der Auswirkungen auf die Sicherheit des Produkts hat.
SAP-Kunden können einen schwerwiegenden Vorfall dem Hersteller melden, indem sie sich an die benannte Kontaktstelle wenden. SAP-Kunden sind dazu nicht verpflichtet; es liegt jedoch in ihrem besten Interesse, den Hersteller so schnell wie möglich zu informieren, damit Maßnahmen ergriffen werden können.
Wenn Sie ein Kunde der TJC Group sind und Fragen zu CRA Artikel 14 haben, zögern Sie nicht, uns zu kontaktieren.
Quellen für Informationen
Europäische Kommission: Cyber Resilience Act
Europäische Kommission: CRA-Meldepflichten
ENISA: CRA Single Reporting Platform FAQs
Cyber Resilience Act Artikel 14
Leitfaden zum Cyber Resilience Act für Softwareentwickler
Häufig gestellte Fragen
Q1. Wann gilt CRA Artikel 14?
Answer:
Die Meldepflichten gemäß Artikel 14 gelten ab dem 11. September 2026. Die meisten der umfassenderen Anforderungen des CRA werden ab dem 11. Dezember 2027 vollständig anwendbar.
Q2. Was ist eine aktiv ausgenutzte Schwachstelle?
Answer:
Es handelt sich um eine Schwachstelle, für die es zuverlässige Beweise gibt, dass ein böswilliger Akteur sie in einem System ohne die Erlaubnis des Systeminhabers ausgenutzt hat.
Q3. Was gilt als schwerwiegender Sicherheitsvorfall?
Answer:
Ein schwerwiegender Vorfall wird anhand der Kriterien in Artikel 14 bewertet. Die zugrunde liegende Definition umfasst Vorfälle, die die Fähigkeit eines Produkts, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen zu schützen, negativ beeinflussen oder beeinflussen können.
Q4. Wer muss gemäß CRA Artikel 14 Meldung erstatten?
Answer:
Die hier erörterten Pflichten gelten für Hersteller von Produkten mit digitalen Elementen, die in den Anwendungsbereich des CRA fallen.
Ob sie für ein bestimmtes Softwareunternehmen gelten, hängt von dessen Rolle und dem betreffenden Produkt ab.
Q5. Wie schnell muss ein Ereignis gemeldet werden?
Answer:
Die erste Frühwarnung muss unverzüglich und in jedem Fall innerhalb von 24 Stunden nach Kenntnisnahme übermittelt werden. Eine detailliertere Meldung folgt innerhalb von 72 Stunden.
Q6. Wo werden Meldungen gemäß CRA Artikel 14 eingereicht?
Answer:
Meldungen werden über die CRA Single Reporting Platform der ENISA eingereicht. Der Hersteller wählt bei der Einreichung das entsprechende CSIRT aus, das als Koordinator benannt ist.
Q7. Gilt Artikel 14 auch für Produkte, die bereits auf dem Markt sind?
Answer:
Ja. Die ENISA stellt klar, dass die Meldepflichten ab dem 11. September 2026 für EU-Produkte mit digitalen Elementen gelten, die in den Anwendungsbereich des CRA fallen, einschließlich relevanter Produkte, die vor der vollständigen Anwendbarkeit des CRA im Dezember 2027 auf den Markt gebracht wurden.
Q8. Wie bereitet sich die TJC Group auf den Cyber Resilience Act (CRA) Artikel 14 vor?
Answer:
Wir haben unsere Kunden über die Aktualisierungen zu Artikel 14 des Cyber Resilience Act informiert und die richtigen Mechanismen implementiert, um bei Bedarf darauf zu reagieren. Die TJC Group ist bereits nach ISO 27001 zertifiziert, was bedeutet, dass ein Informationssicherheits-Managementsystem vorhanden ist, um Bedrohungen oder Cybersicherheitsvorfälle als fortlaufende operative Verantwortung effizient zu verwalten.
