I

Anhang I

GRUNDLEGENDE CYBERSICHERHEITSANFORDERUNGEN

Verordnung (EU) 2024/2847 — veröffentlicht 10. Dezember 2024 · Letzte Prüfung durch Kunnus: März 2026

Schnellantwort für Hersteller

Anhang I ist das Herzstück des CRA: die wesentlichen Cybersicherheitsanforderungen. Teil I listet 13 Eigenschaften, die jedes Produkt mit digitalen Elementen erfüllen muss. Teil II definiert sechs Anforderungen an den Schwachstellenbehandlungsprozess.

Diese Schnellantwort + FAQ ergänzen den Original-Rechtstext mit praxisorientierter Auslegung. Rechtsverbindlich ist allein der Originaltext.

Teil I Cybersicherheitsanforderungen in Bezug auf die Eigenschaften von Produkten mit digitalen Elementen

(1)

Produkte mit digitalen Elementen werden so konzipiert, entwickelt und hergestellt, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten.

(2)

Auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Artikel 13 Absatz 2 müssen Produkte mit digitalen Elementen, soweit zutreffend,

a)

ohne bekannte ausnutzbare Schwachstellen auf dem Markt bereitgestellt werden,

b)

mit einer sicheren Standardkonfiguration auf dem Markt bereitgestellt werden, sofern zwischen dem Hersteller und dem gewerblichen Nutzer in Bezug auf ein maßgeschneidertes Produkt mit digitalen Elementen nichts anderes vereinbart wurde, und die Möglichkeit bieten, das Produkt in seinen ursprünglichen Zustand zurückzusetzen,

c)

sicherstellen, dass Schwachstellen durch Sicherheitsaktualisierungen behoben werden können, gegebenenfalls auch durch automatische Sicherheitsaktualisierungen, die als Standardeinstellung innerhalb eines angemessenen Zeitrahmens installiert werden sowie über einen klaren und benutzerfreundlichen Opt-out-Mechanismus verfügen, bei dem die Nutzer über verfügbare Aktualisierungen informiert werden und sie vorübergehend verschieben können;

d)

durch geeignete Kontrollmechanismen Schutz vor unbefugtem Zugriff bieten, darunter u. a. zumindest Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme, und einen möglicherweise unbefugten Zugriff melden,

e)

die Vertraulichkeit gespeicherter, übermittelter oder anderweitig verarbeiteter personenbezogener oder sonstiger Daten schützen, z. B. durch Verschlüsselung relevanter Daten, die gespeichert sind oder gerade verwendet oder übermittelt werden, durch modernste Mechanismen und durch den Einsatz anderer technischer Mittel,

f)

die Integrität gespeicherter, übermittelter oder anderweitig verarbeiteter Daten, ob personenbezogener oder sonstiger Daten, Befehle, Programme und Konfigurationen vor einer vom Nutzer nicht genehmigten Manipulation oder Veränderung schützen und deren Beschädigung melden,

g)

die Verarbeitung personenbezogener oder sonstiger Daten auf solche, die angemessen und von Bedeutung sind, und auf das für die Zweckbestimmung des Produkts mit digitalen Elementen erforderliche Maß beschränken („Datenminimierung“),

h)

die Verfügbarkeit wesentlicher und grundlegender Funktionen, auch nach einem Sicherheitsvorfall, einschließlich über Abwehr- und Eindämmungsmaßnahmen gegen Überlastungsangriffe auf Server (Denial-of-Service-Angriffe), sicherstellen,

i)

die negativen Auswirkungen von den Produkten selbst oder von vernetzten Geräten auf die Verfügbarkeit der von anderen Geräten oder Netzen bereitgestellten Dienste minimieren,

j)

so konzipiert, entwickelt und hergestellt werden, dass sie — auch bei externen Schnittstellen — möglichst geringe Angriffsflächen bieten,

k)

so konzipiert, entwickelt und hergestellt werden, dass die Auswirkungen eines Sicherheitsvorfalls durch geeignete Mechanismen und Techniken zur Minderung der möglichen Ausnutzung verringert werden,

l)

sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge wie Zugang zu Daten, Diensten oder Funktionen und Änderungen daran bereitstellen und den Nutzern einen Opt-out-Mechanismus zur Verfügung stellen,

m)

den Nutzern die Möglichkeit bieten, alle Daten und Einstellungen dauerhaft sicher und einfach zu löschen, und, wenn diese Daten auf andere Produkte oder Systeme übertragen werden können, sicherstellen, dass dies auf sichere Weise geschieht.

Teil II Anforderungen an die Behandlung von Schwachstellen Die Hersteller von Produkten mit digitalen Elementen müssen

(1)

Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen;

(2)

im Hinblick auf die Risiken im Zusammenhang mit den Produkten mit digitalen Elementen unverzüglich Schwachstellen behandeln und beheben, unter anderem durch Bereitstellung von Sicherheitsaktualisierungen; soweit technisch machbar, müssen neue Sicherheitsaktualisierungen getrennt von den Funktionsaktualisierungen bereitgestellt werden;

(3)

die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen;

(4)

sobald eine Sicherheitsaktualisierung bereitgestellt worden ist, Informationen über beseitigte Schwachstellen teilen und veröffentlichen, einschließlich einer Beschreibung der Schwachstellen mit Angaben, anhand deren die Nutzer das betroffene Produkt mit digitalen Elementen, die Auswirkungen der Schwachstellen und ihre Schwere erkennen können, sowie eindeutige und verständliche Informationen, die den Nutzern helfen, die Schwachstellen zu beheben; in hinreichend begründeten Fällen, in denen die Hersteller der Auffassung sind, dass die Risiken der Veröffentlichung die Vorteile in Bezug auf die Sicherheit überwiegen, können sie die Veröffentlichung von Informationen über eine behobene Schwachstelle so lange aufschieben, bis den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden;

(5)

eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen;

(6)

Maßnahmen ergreifen, um den Austausch von Informationen über mögliche Schwachstellen in ihrem Produkt mit digitalen Elementen und darin enthaltenen Komponenten Dritter zu erleichtern, und dazu u. a. eine Kontaktadresse für die Meldung der in dem Produkt mit digitalen Elementen entdeckten Schwachstellen angeben;

(7)

Mechanismen für die sichere Verbreitung von Aktualisierungen für Produkte mit digitalen Elementen bereitstellen, damit Schwachstellen rechtzeitig und im Falle von Sicherheitsaktualisierungen gegebenenfalls automatisch behoben oder eingedämmt werden;

(8)

dafür sorgen, dass Sicherheitsaktualisierungen, die zur Bewältigung festgestellter Sicherheitsprobleme zur Verfügung stehen, unverzüglich und — sofern zwischen dem Hersteller und dem gewerblichen Nutzer in Bezug auf ein maßgeschneidertes Produkt mit digitalen Elementen nichts anderes vereinbart wurde — kostenlos verbreitet werden, zusammen mit Hinweisen und einschlägigen Informationen, auch über zu treffende mögliche Maßnahmen.

Auslegung der EU-Kommission

Guidance vom 27. Juli 2026

Die EU-Kommissions-Guidance vom 27. Juli 2026 enthält offizielle Auslegungshinweise zu dieser Vorschrift. Jeder Abschnitt: Kurzfassung, Kernaussagen und was das konkret für Sie bedeutet.

Abschnitt 2.6Komplexe Systeme und Interoperabilitäts-Constraints

Komplexe Systeme mit langen Entwicklungszyklen, Alt-Komponenten und Interoperabilitätszwängen sind nicht vom CRA ausgenommen — ihre Constraints fließen aber in den risikobasierten Ansatz ein. Wo einzelne wesentliche Anforderungen nicht oder nicht voll umsetzbar sind (vgl. Erwägungsgrund 55), müssen Hersteller die Constraints dokumentieren, die Risiken bewerten und kompensierende Maßnahmen treffen.

Kernaussagen

  • Ein unsicheres Legacy-Protokoll darf implementiert werden, wenn es für Interoperabilität nötig ist und die Risiken anderweitig mitigiert werden; unterstützt das Produkt beide Protokolle, muss das sichere der Default sein (Beispiel 10).
  • Constraints, Risiken und Mitigationen gehören transparent in die technische Dokumentation (Art. 31, Anhang VII) und die Nutzerinformationen (Anhang II).
  • Constraints sind während des Supportzeitraums regelmäßig neu zu bewerten; entfallen sie, muss das Produkt entsprechend nachgezogen werden.
  • Vor CRA-Geltung beschaffte Komponenten dürfen integriert werden, wenn die Risikobewertung keine spezifischen Risiken ergibt und das Gesamtprodukt die Anforderungen erfüllt (Beispiel 11).

Für die Praxis

Legen Sie für jede nicht (voll) erfüllbare Anforderung ein Constraint-Dossier an: Warum nicht umsetzbar (z. B. Interoperabilitätszwang), welches Risiko entsteht, welche Kompensationsmaßnahme greift — und terminieren Sie die Neubewertung. Genau diese Dokumentation wird die Marktüberwachung sehen wollen.

Abschnitt im Guidance-Überblick
Abschnitt 2.7Vor CRA-Geltung entwickelte Produkte — kein Redesign-Zwang

Produkte, die vor dem 11. Dezember 2027 entworfen, aber danach in Verkehr gebracht werden, müssen nicht zwingend neu designt werden. Der Hersteller führt eine aktuelle Risikobewertung durch; zeigt sie, dass vorhandene Maßnahmen die Risiken adressieren, kann er darauf die Konformität stützen. Historische Design- und Testdokumentation muss nicht rekonstruiert werden.

Kernaussagen

  • Konformitätsbewertungsverfahren, EU-Konformitätserklärung und CE-Kennzeichnung bleiben in jedem Fall Pflicht.
  • Keine Pflicht, Testnachweise aus der ursprünglichen Designphase nachzuliefern; Tests können über Produktfamilien gebündelt werden (Abschnitt 7.4 der Leitlinien).
  • Schwachstellenbehandlung (Anhang I Teil II), aktuelle Risikobewertung (Art. 13 Abs. 3) und Nutzerinformationen (Art. 13 Abs. 18) gelten uneingeschränkt.

Beispiel aus der Guidance

Ein vor CRA-Geltung entwickelter Mikrocontroller darf ohne Redesign weiter in Verkehr gebracht werden, wenn eine aktuelle Risikobewertung zeigt, dass die vorhandenen Sicherheitsmaßnahmen die identifizierten Risiken abdecken (Beispiel 12).

Für die Praxis

Planen Sie für Bestandsdesigns kein Redesign ein, bevor die Risikobewertung eines verlangt: Eine aktuelle Risikobewertung plus der Nachweis, dass vorhandene Maßnahmen die Risiken abdecken, genügt. Historische Design- und Testdoku müssen Sie nicht rekonstruieren — Konformitätserklärung und CE-Kennzeichnung bleiben aber Pflicht.

Abschnitt im Guidance-Überblick
Abschnitt 5 – 5.1Supportzeitraum — Bestimmung, Art. 13 Abs. 10 und wesentliche Änderungen

Fünf Jahre sind Untergrenze, nicht Default: Der Supportzeitraum richtet sich nach der erwarteten Nutzungsdauer; länger genutzte Produkte brauchen längeren Support. Artikel 13 Abs. 10 erlaubt, die Schwachstellenbehebung auf die zuletzt in Verkehr gebrachte Version zu konzentrieren, wenn Nutzer kostenlos und ohne Zusatzkosten upgraden können. Eine wesentliche Änderung setzt den Supportzeitraum nicht automatisch zurück.

Kernaussagen

  • „Zusatzkosten“ im Sinne von Art. 13 Abs. 10 meint Hardware-Neukauf oder Infrastrukturwechsel — nicht normalen Update-Aufwand wie Personalzeit, Tests oder Konfigurationsanpassungen.
  • Jede wesentlich geänderte Version braucht bei Inverkehrbringen einen eigenen deklarierten Supportzeitraum nach Art. 13 Abs. 8.
  • Bestimmen unveränderte Faktoren (z. B. Hardware-Lebensdauer) weiterhin die Nutzungsdauer, bleibt der ursprüngliche Supportzeitraum maßgeblich — auch wenn die Restlaufzeit unter fünf Jahren liegt (Beispiele 54/55: Saugroboter, Industriemaschine mit neuem Cloud-Backend).
  • Verändert die Modifikation die Nutzungsdauer-Faktoren selbst (z. B. neue Rechenplattform verlängert Lebensdauer einer SPS), ist der Supportzeitraum neu zu berechnen (Beispiel 56).
  • Enddatum des Supports beim Kauf angeben (mindestens Monat/Jahr) und EOL-Benachrichtigung anzeigen, wo technisch machbar (Art. 13 Abs. 19).
  • Hersteller dürfen ältere Versionen freiwillig weiter patchen — auch kostenpflichtig; der CRA verlangt dafür keine Gratis-Updates.

Für die Praxis

Leiten Sie den Supportzeitraum dokumentiert aus der erwarteten Nutzungsdauer ab — pauschal „5 Jahre“ ist angreifbar, wenn Ihr Produkt erkennbar länger genutzt wird. Nennen Sie das Enddatum schon im Kaufprozess (mindestens Monat/Jahr). Bei Software: Prüfen Sie, ob Sie mit der Art.-13-Abs.-10-Regel nur die jeweils letzte Version patchen müssen — das setzt kostenlose Upgrades ohne Hardware-/Infrastrukturzwang voraus.

Abschnitt im Guidance-Überblick
Abschnitt 7.1 – 7.2Risikobewertung: kein eigener Risikoappetit, kein Risikotransfer

Anders als im organisatorischen Risikomanagement zählt nicht der eigene Risikoappetit: Restrisiken sind am Maßstab des „angemessenen Cybersicherheitsniveaus“ des Produkts zu messen. Kosten oder kommerzielle Erwägungen rechtfertigen keine unbehandelten Risiken — notfalls sind Design, Funktionsumfang oder Zweckbestimmung zu ändern. Ein Transfer von Risiken auf Nutzer oder Dritte ist keine zulässige Compliance-Strategie.

Kernaussagen

  • Zulässige Mitigationen umfassen auch Zweckbeschränkung plus klare Nutzerinformation — etwa ein Industriesensor, der nur für vertrauenswürdige Umgebungen bestimmt ist (Beispiel 66).
  • Hersteller dürfen auf reife Plattform-Funktionen setzen, z. B. native Verschlüsselung und Key-Management des Betriebssystems statt Eigenbau (Beispiel 67).
  • Anhang I Teil I Nr. 1 („angemessenes Cybersicherheitsniveau“) wirkt als Auffangnorm: erfüllt, wenn alle Risiken über die übrigen wesentlichen Anforderungen adressiert sind — sonst sind zusätzliche produktseitige Maßnahmen nötig.

Für die Praxis

Streichen Sie „akzeptiertes Restrisiko aus Kosten-/Geschäftsgründen“ aus Ihren Risiko-Templates — dieses Argument trägt unter dem CRA nicht. Zulässige Hebel sind: technische Maßnahmen, Zweckbeschränkung plus klare Nutzerinformation, Rückgriff auf reife Plattform-Funktionen (z. B. OS-Verschlüsselung) — und notfalls Änderung von Design oder Funktionsumfang.

Abschnitt im Guidance-Überblick
Abschnitt 7.3Externe Abhängigkeiten vs. Due Diligence für Komponenten

Zwei komplementäre Pflichten: Die Risikobewertung (Art. 13 Abs. 2) erfasst auch externe Risiken — Backends, Infrastruktur, Umgebung —, die produktseitig zu mitigieren sind; der CRA regelt nicht, wie fremde Infrastruktur betrieben wird. Die Due Diligence (Art. 13 Abs. 5) betrifft integrierte Dritt-Komponenten: Der Hersteller definiert, was die Komponente leisten muss, und verifiziert das risikobasiert.

Kernaussagen

  • Beispiele produktseitiger Mitigation externer Risiken: kryptografische Authentisierung von Remote-Kommandos, Integritätsprüfung von Konfigurationsänderungen, sichere Zustände bei Ausfall externer Dienste.
  • Due-Diligence-Nachweise: technische Spezifikationen und Sicherheitsdokumentation des Komponenten-Herstellers, Konformitäts-/Assurance-Doku, ggf. eigene Tests.
  • Integrierte Dritt-Komponenten gehören in die Risikobewertung, werden aber als extern gelieferte Teile behandelt, deren Eigenschaften bei Integration verifiziert werden (Erwägungsgrund 34).

Für die Praxis

Trennen Sie Ihre Risikoliste in zwei Spalten: externe Abhängigkeiten (fremde Backends, Netze, Umgebung) → produktseitig mitigieren, etwa durch authentisierte Remote-Kommandos und sichere Fail-States; integrierte Dritt-Komponenten → Anforderungen definieren und Nachweise einsammeln (Hersteller-Doku, Zertifikate, eigene Tests). Wie der externe Anbieter seinen Betrieb organisiert, ist nicht Ihr CRA-Problem.

Abschnitt im Guidance-Überblick
Abschnitt 8.2RDPS in Doku, Risikobewertung und Konformitätsbewertung

RDPS gehören in Risikobewertung, technische Dokumentation und Konformitätsbewertung des Produkts — beschränkt auf die Software-Module, die die Produktfunktion tragen, und deren Schnittstellen. Nachgelagerte Backend-Systeme ohne direkte Produkt-Interaktion sind kein RDPS, bleiben aber externe Abhängigkeiten, deren Risiken produktseitig zu mitigieren sind.

Kernaussagen

  • Ein RDPS, das mehrere Produkte bedient, ist in jeder Produkt-Doku zu deklarieren — die RDPS-Dokumentation darf über Konformitätsbewertungen hinweg wiederverwendet werden.
  • Wiederverwendbare Assurance-Nachweise für Dritt-Services: NIS-2-Nachweise (DVO (EU) 2024/2690), DORA-Nachweise, Zertifikate nach EU-Cybersicherheits-Schemata, ISO/IEC 27001/27017.
  • Änderungen an Dritt-Services sind keine wesentliche Änderung des Produkts — Hersteller sollten sich aber vertraglich (SLAs) Informationen und Sicherheitsgarantien zusichern lassen und die Risikobewertung nachziehen.

Für die Praxis

Legen Sie ein zentrales RDPS-Dossier an — betroffene Software-Module, Schnittstellen, genutzte Provider samt Nachweisen (ISO 27001/27017, NIS-2-, DORA-Evidenz, EUCC-Zertifikate) — und referenzieren Sie es aus jeder Produkt-Doku. Verankern Sie in Provider-SLAs, dass Sie über wesentliche Änderungen informiert werden: Die lösen zwar keine neue Konformitätsbewertung aus, wohl aber ein Update Ihrer Risikobewertung.

Abschnitt im Guidance-Überblick
Abschnitt 9.1Meldepflichten: ab 11.09.2026, „Bewusstwerden“ und Nutzerinformation

Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 für alle Produkte im CRA-Scope — auch für vor dem 11. Dezember 2027 in Verkehr gebrachte und für Produkte nach Supportende. „Bewusstwerden“ heißt: hinreichende Gewissheit nach unverzüglicher Erstbewertung — ab dann laufen die Fristen (24 h Frühwarnung, 72 h Meldung, 14 Tage bzw. 1 Monat Abschlussbericht).

Kernaussagen

  • Keine retroaktive Meldung: Aktive Ausnutzung, die dem Hersteller schon vor dem 11.09.2026 bekannt war, ist nicht meldepflichtig; wird die Ausnutzung erst danach bekannt, greift die Pflicht.
  • Dritt-Komponenten: Meldepflichtig ist nur eine aktiv ausgenutzte Schwachstelle, die im eigenen Produkt ausnutzbar ist bzw. ausgenutzt wurde — sonst nur freiwillige Meldung (Art. 15) plus Upstream-Meldung an den Komponenten-Maintainer (Art. 13 Abs. 6).
  • Der Begriff „Bewusstwerden“ ist bewusst konsistent mit der NIS-2-Durchführungsverordnung und den GDPR-Guidelines ausgelegt.
  • Nutzerinformation (Art. 14 Abs. 8) ist risikobasiert: keine indiskriminierte Veröffentlichung — bei sensiblen Umgebungen darf die Detailinformation auf betroffene Nutzer beschränkt werden; breitere Offenlegung nach Behebung, Pflicht-Veröffentlichung fixer Schwachstellen nach Anhang I Teil II Nr. 4.
  • Die Meldepflichten laufen — anders als die Schwachstellenbehandlung — auch nach Ende des Supportzeitraums weiter.

Für die Praxis

Definieren Sie jetzt, wer Verdachtsfälle wie schnell erstbewertet — ab „hinreichender Gewissheit“ läuft die 24-Stunden-Frist. Der Prozess muss zum 11. September 2026 stehen und deckt auch Altprodukte und Produkte nach Supportende ab. Legen Sie zusätzlich fest, wie Sie Nutzer risikobasiert informieren: erst betroffene Kunden gezielt, breite Veröffentlichung nach der Behebung.

Abschnitt im Guidance-Überblick
Abschnitt 9.2Schwachstellenbehandlung: Upstream-Meldung, bekannte Schwachstellen, Tests

Die Leitlinien präzisieren drei Pflichten: das Upstream-Melden von Komponenten-Schwachstellen und Teilen von Security-Fixes (Art. 13 Abs. 6), das Verbot, Produkte mit bekannten ausnutzbaren Schwachstellen in Verkehr zu bringen (Anhang I Teil I), und die „effektiven und regelmäßigen Tests“ (Anhang I Teil II Nr. 3) — die keine mechanische Testwiederholung verlangen, sondern anlassbezogene Review und Anpassung.

Kernaussagen

  • Upstream nur für die tatsächlich integrierte Version und gemäß CVD-Prozessen des Maintainers; keine Pflicht bei bereits bekannter Schwachstelle (Duplikate vermeiden: Datenbanken/Advisories prüfen) oder bei verwaisten Projekten ohne Maintainer.
  • Nur Schwachstellen der Komponente selbst sind zu melden — nicht solche, die erst durch die eigene Integration entstehen.
  • Security-Fixes maschinenlesbar und lizenzkompatibel teilen; weder muss der Maintainer den Fix annehmen, noch der Hersteller den Fix des Maintainers übernehmen.
  • „Bekannt“ ist eine Schwachstelle bei Listung in relevanten öffentlichen Datenbanken (z. B. Europäische Schwachstellendatenbank), bei Coordinated Disclosure, eigenen Tests (inkl. KI-gestützter Analyse) oder prominenter Medienberichterstattung — eine kurze Prüf-/Verifikationszeit ist zulässig.
  • Kurz vor Release entdeckte Schwachstellen: risikobasierte Entscheidung, ob das Release verschoben wird — abwägen mit den Risiken der Verzögerung (z. B. wenn das Release andere Schwachstellen schließt).

Für die Praxis

Ergänzen Sie Ihren Schwachstellen-Prozess um drei Bausteine: (1) Datenbank-/Advisory-Check vor jeder Upstream-Meldung, um Duplikate zu vermeiden; (2) lizenzkonformes, maschinenlesbares Teilen eigener Fixes mit dem Maintainer; (3) ein dokumentierter Release-Entscheid für spät gefundene Schwachstellen — abwägen zwischen Fix-vor-Release und den Risiken der Verzögerung.

Abschnitt im Guidance-Überblick
Alle Guidance-Kapitel im Überblick

EU-Kommissions-Guidance (C(2026) 5252 final)Die Guidance gibt die Auslegung der Europäischen Kommission wieder und ist rechtlich nicht bindend. Eine verbindliche Auslegung des EU CRA kann nur der Gerichtshof der Europäischen Union vornehmen.

Häufige Hersteller-Fragen

Was steht in Anhang I Teil I (Produkteigenschaften)?

13 Anforderungen: sicheres Default-Setup, Schutz vor unbefugtem Zugriff, Vertraulichkeit/Integrität gespeicherter und übertragener Daten, Verfügbarkeit, Minimierung der Angriffsfläche, Begrenzung von Auswirkungen sicherheitsrelevanter Vorfälle, sicheres Update, Logging — und mehr.

Was steht in Anhang I Teil II (Schwachstellenbehandlung)?

6 Anforderungen: Identifizierung und Dokumentation von Schwachstellen und Komponenten (inkl. SBOM), Behebung ohne Verzögerung durch Sicherheitsupdates, regelmäßige Tests, Veröffentlichung von Informationen über behobene Schwachstellen, Policy für koordinierte Offenlegung, Verteilung der Updates über sichere Kanäle.

Wo wird die SBOM-Pflicht konkret verankert?

In Anhang I Teil II Punkt 1: „Identifikation und Dokumentation von Schwachstellen und Komponenten, einschließlich der Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format“. CycloneDX und SPDX gelten als „gängige Formate“.

Gelten alle 13 + 6 Anforderungen für jedes Produkt?

Nicht automatisch. Erwägungsgrund 55 erlaubt es, bestimmte Anforderungen als nicht anwendbar zu deklarieren — mit Begründung in der Risikobewertung in der Technischen Dokumentation.

Dieser Text wurde aus der Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 übernommen. Die Darstellung dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Maßgeblich ist allein der im Amtsblatt der Europäischen Union veröffentlichte Wortlaut. Originaltext auf EUR-Lex