Provetry
ENFRFrühen Zugang anfragen
Kostenloser Check
Frühen Zugang anfragen

Provetry startet im November 2026. Der kostenlose CRA-Check, die Werkzeuge und die Leitfäden sind schon jetzt verfügbar.

CRA Anhang I: die grundlegenden Anforderungen im Einzelnen

12 Min. Lesezeit

Auf dieser Seite
  1. Mit der Risikobewertung beginnen
  2. Teil I: Sicherheitseigenschaften des Produkts
  3. Teil II: Umgang mit Schwachstellen
  4. Wie Sie die Erfüllung belegen
  5. Wie Provetry hilft
  6. Quellen

Anhang I des Cyber Resilience Act legt fest, was jedes Produkt mit digitalen Elementen erfüllen muss, um ab dem 11. Dezember 2027 in der EU verkauft zu werden. Er hat zwei Teile: Teil I, die Sicherheitseigenschaften des Produkts selbst, und Teil II, wie der Hersteller während des Unterstützungszeitraums mit den Schwachstellen umgeht.

Die Anforderungen sind als Ergebnisse formuliert, nicht als Techniken. Harmonisierte Normen werden anerkannte Wege beschreiben, sie zu erfüllen; bis sie im Amtsblatt zitiert sind, belegen Sie die Konformität, indem Sie in Ihrer technischen Dokumentation die gewählten Lösungen erläutern. Nutzen Sie diesen Leitfaden als Checkliste: Notieren Sie für jede Anforderung, wie Ihr Produkt sie erfüllt oder warum sie nicht anwendbar ist.

Mit der Risikobewertung beginnen

Artikel 13 verlangt, dass Sie vor allem anderen die Cybersicherheitsrisiken des Produkts bewerten und diese Bewertung während des Unterstützungszeitraums aktuell halten. Sie entscheidet, wie jede Anforderung aus Teil I für Ihr Produkt gilt: Die ganze Liste von a bis m steht unter dem Vorbehalt, dass sie auf Grundlage der Cybersicherheitsrisikobewertung und soweit anwendbar gilt. Eine Anforderung, die Sie für nicht anwendbar halten, muss in der Risikobewertung selbst klar begründet werden, und diese gehört in die technische Akte.

Teil I: Sicherheitseigenschaften des Produkts

Die erste Anforderung ist allgemein: Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass sie ausgehend von den Risiken ein angemessenes Cybersicherheitsniveau gewährleisten. Dann muss das Produkt, auf Grundlage der Risikobewertung und soweit anwendbar:

a) Ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden

Beim Inverkehrbringen darf keine Ihnen bekannte, ausnutzbare Schwachstelle mehr vorhanden sein. In der Praxis: Gleichen Sie die Komponenten jeder Version vor der Auslieferung mit Schwachstellendatenbanken ab und halten Sie fest, warum ein verbleibender Befund nicht ausgenutzt werden kann (eine VEX-Aussage).

b) Standardmäßig sicher sein

Das Produkt wird mit einer sicheren Konfiguration ausgeliefert, sofern mit einem gewerblichen Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart ist, und der Nutzer kann es auf den Ursprungszustand zurücksetzen. Keine geräteübergreifend gleichen Standardpasswörter, unnötige Dienste aus, Debug-Schnittstellen geschlossen.

c) Sicherheitsupdates erhalten

Schwachstellen müssen sich durch Sicherheitsupdates beheben lassen, gegebenenfalls auch durch automatische Updates, die innerhalb einer angemessenen Frist installiert werden und standardmäßig aktiviert sind, mit einer klaren Möglichkeit zur Deaktivierung. Nutzer werden informiert, wenn ein Update verfügbar ist, und können es eine Zeit lang aufschieben.

d) Vor unbefugtem Zugriff schützen

Authentifizierung, Identitäts- und Zugangsverwaltung, die dem Produkt angemessen sind, und eine Meldung, wenn ein unbefugter Zugriff stattgefunden haben könnte. Denken Sie an Schutz vor Brute-Force-Angriffen, gerätespezifische Zugangsdaten, minimale Berechtigungen.

e) Die Vertraulichkeit schützen

Daten, die das Produkt speichert, überträgt oder verarbeitet, personenbezogen oder nicht, bleiben vertraulich: Verschlüsselung im Ruhezustand und bei der Übertragung mit aktuellen Algorithmen, und andere technische Mittel, wo nötig.

f) Die Integrität schützen

Daten, Befehle, Programme und Konfiguration sind vor Manipulation oder Änderung geschützt, die der Nutzer nicht genehmigt hat, und Beschädigungen werden gemeldet. Signierte Firmware und signierte Updates, verifizierter Systemstart, geprüfte Konfiguration.

g) Daten minimieren

Es werden nur Daten verarbeitet, die dem Zweck angemessen und erheblich sind und sich auf das beschränken, was die Zweckbestimmung des Produkts erfordert.

h) Wesentliche Funktionen verfügbar halten

Wesentliche und grundlegende Funktionen bleiben verfügbar, auch nach einem Sicherheitsvorfall, mit Widerstandsfähigkeit und Abwehrmaßnahmen gegen Denial-of-Service-Angriffe.

i) Anderen nicht schaden

Das Produkt begrenzt die negativen Auswirkungen, die es selbst oder mit ihm verbundene Geräte auf die Verfügbarkeit von Diensten anderer Geräte oder Netze haben. Ein kompromittiertes Gerät soll nicht leicht Teil eines Botnetzes werden, das andere überflutet.

j) Die Angriffsfläche begrenzen

Weniger offene Schnittstellen, weniger offene Ports, weniger Komponenten: Die Angriffsfläche, einschließlich externer Schnittstellen, beschränkt sich auf das, was das Produkt braucht.

k) Die Auswirkungen von Vorfällen verringern

Mechanismen und Techniken zur Eindämmung von Ausnutzung: speichersichere Sprachen oder Härtung, Sandboxing, Trennung von Berechtigungen, damit eine einzige Schwachstelle nicht alles preisgibt.

l) Sicherheitsereignisse aufzeichnen

Das Produkt liefert sicherheitsrelevante Informationen, indem es relevante interne Aktivitäten aufzeichnet und überwacht, etwa den Zugriff auf Daten, Dienste oder Funktionen oder deren Änderung, mit einer Möglichkeit zur Deaktivierung für den Nutzer.

m) Nutzern das Löschen und Übertragen ihrer Daten ermöglichen

Nutzer können alle Daten und Einstellungen sicher, einfach und dauerhaft entfernen und, wo Daten auf andere Produkte oder Systeme übertragen werden können, dies sicher tun.

Teil II: Umgang mit Schwachstellen

Diese Anforderungen gelten beim Inverkehrbringen des Produkts und während des gesamten Unterstützungszeitraums. Hersteller müssen:

1. Wissen, was im Produkt steckt

Die im Produkt enthaltenen Schwachstellen und Komponenten ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Siehe Was ist eine SBOM? und die SBOM für den CRA.

2. Unverzüglich beheben

Schwachstellen im Verhältnis zu ihren Risiken unverzüglich angehen und beheben, auch durch Sicherheitsupdates. Wo technisch machbar, werden Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt, damit Nutzer für eine Korrektur keine neuen Funktionen übernehmen müssen.

3. Regelmäßig testen

Wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts durchführen: Code-Reviews, Abhängigkeitsscans, Penetrationstests, Fuzzing, ausgewählt nach den Risiken.

4. Veröffentlichen, was behoben wurde

Sobald ein Sicherheitsupdate verfügbar ist, Informationen über die behobenen Schwachstellen teilen und öffentlich bekannt machen: eine Beschreibung, die betroffenen Produkte, Auswirkung und Schwere sowie klare Informationen, die Nutzern bei der Behebung helfen. In hinreichend begründeten Fällen, wenn die Sicherheitsrisiken einer Veröffentlichung ihren Nutzen überwiegen, kann die Veröffentlichung warten, bis die Nutzer den Patch einspielen konnten. Maschinenlesbare Sicherheitshinweise (CSAF) sind der übliche Weg.

5. Eine Offenlegungsstrategie haben

Eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen. Unser kostenloser Generator für Offenlegungsstrategien erstellt sie aus Ihren Antworten.

6. Erreichbar sein

Maßnahmen treffen, um den Austausch von Informationen über mögliche Schwachstellen im Produkt und seinen Drittkomponenten zu erleichtern, unter anderem durch eine Kontaktadresse für deren Meldung. Eine security.txt-Datei ist der übliche Weg, sie zu veröffentlichen.

7. Updates sicher verteilen

Mechanismen bereitstellen, um Updates sicher zu verteilen, damit Schwachstellen rechtzeitig behoben oder eingedämmt werden und, wo bei Sicherheitsupdates anwendbar, automatisch.

8. Korrekturen kostenlos und erklärt bereitstellen

Sicherheitsupdates unverzüglich und, sofern mit einem gewerblichen Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart ist, kostenlos verbreiten, mit Hinweisen, die Nutzern sagen, was sie wissen und tun müssen.

Wie Sie die Erfüllung belegen

Für jede Anforderung sollte die technische Dokumentation (Anhang VII) sagen, wie sie erfüllt wird: die Designentscheidung, der Test, die Norm oder der Prozess, und wo der Nachweis liegt. Führen Sie sie pro Produkt und pro Version:

  • die Risikobewertung und ihre Schlussfolgerungen, Anforderung für Anforderung;
  • die SBOM jeder Version und die gefundenen Schwachstellen mit Ihren Entscheidungen;
  • Testberichte;
  • die Offenlegungsstrategie, die Kontaktstelle und die veröffentlichten Hinweise;
  • wie Updates gebaut, signiert und verteilt werden.

Harmonisierte Normen werden das erleichtern, sobald sie zitiert sind: Wer sie anwendet, profitiert von einer Konformitätsvermutung. Bis dahin sind die Normentwürfe der Reihe EN 40000, etwa prEN 40000-1-3 zum Umgang mit Schwachstellen, eine gute Orientierung dafür, worauf Prüfer achten werden.

Wie Provetry hilft

Provetry deckt den größten Teil von Teil II für Sie ab: eine SBOM für jede Version, täglicher Abgleich mit neuen und ausgenutzten Schwachstellen, VEX-Entscheidungen, Ihre Offenlegungsstrategie und security.txt, CSAF-Hinweise und die Meldeuhr. Seine Konformitätsakte geht Teil I Anforderung für Anforderung durch und bewahrt die Antworten in Ihrer technischen Akte auf.

Dieser Leitfaden ist eine allgemeine Information, keine Rechtsberatung.

Quellen