Die Cyberresilienz-Verordnung (CRA) legt Anforderungen an die Produktsicherheit und den Umgang mit Schwachstellen fest. Sie schreibt nicht für jedes Gerät ein externes TPM, eine bestimmte MCU, einen OTA-Transportmechanismus oder einen A/B-Bootloader vor. Wählen Sie technische Kontrollmaßnahmen auf der Grundlage der Cybersicherheits-Risikobewertung des Produkts und dokumentieren Sie, wie diese die anwendbaren Anforderungen erfüllen.
Anwendungsbereich und Produktkategorie
Prüfen Sie Artikel 2 der CRA: Die Verordnung gilt für Produkte mit digitalen Elementen, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Sektorspezifische Ausnahmen gelten für Produkte, die unter bestimmte Rechtsvorschriften für Medizinprodukte, Fahrzeuge und die Luftfahrt fallen. Nicht kommerzielle freie und quelloffene Software wird anders behandelt; für die Verwalter quelloffener Software gelten gesonderte Verpflichtungen.
Dokumentieren Sie die Kernfunktionalität und die Kategorie des Produkts. Anhang III unterscheidet zwischen wichtigen Produkten der Klasse I und der Klasse II. Zur Klasse II gehören Hypervisoren/Container-Laufzeitumgebungen, die virtualisierte Betriebssysteme unterstützen, Firewalls/IDS/IPS sowie manipulationsresistente Mikroprozessoren und Mikrocontroller. Anhang IV deckt kritische Kategorien wie Chipkarten und ähnliche Geräte, einschließlich sicherer Elemente, ab. Nicht jeder intelligente Zähler oder jede Sicherheitskomponente gehört zur Klasse II. Verwenden Sie die technischen Beschreibungen der Durchführungsverordnung 2025/2392 für den Abgleich mit einer Kategorie.
Sicherheit durch Technikgestaltung (Security by Design)
Definieren Sie Assets, Vertrauensgrenzen, Bedrohungen und vorhersehbare Fehlanwendungen. Ordnen Sie die anwendbaren Anforderungen aus Anhang I den Kontrollmaßnahmen und Testnachweisen zu. Verwenden Sie sichere Standardeinstellungen, angemessene Zugriffskontrollen, Datenminimierung sowie den Schutz von Vertraulichkeit und Integrität. Halten Sie fest, warum eine Kontrollmaßnahme anwendbar ist oder nicht; ein Häkchen in einer Checkliste ist keine Risikobewertung.
Vertrauensanker (Root of Trust) in der Hardware
Secure Boot (authentifizierter Systemstart), geschützte Schlüsselspeicherung, Debug-Beschränkungen und Manipulationsschutzmaßnahmen können identifizierte Risiken absichern. Sie sind Implementierungsentscheidungen und keine universelle gesetzliche Verpflichtung, ein separates TPM zu installieren oder jede Debug-Schnittstelle unwiderruflich zu sperren. Validieren Sie die tatsächliche Boot-Kette, die Provisionierung in der Fertigung und den Wiederherstellungsprozess.
Sichere Kommunikation
Identifizieren Sie jede Schnittstelle und ihre Vertrauensgrenze. Wählen Sie eine Authentifizierung und einen kryptografischen Schutz, die den Risiken angemessen sind. Testen Sie die Zertifikatsvalidierung, den Lebenszyklus von Anmeldeinformationen und die Fehlerbehandlung. Die bloße Nennung einer TLS-Version ist kein ausreichender Nachweis dafür, dass ein Produkt die wesentlichen Anforderungen erfüllt.
Management von Schwachstellen
Benennen Sie Verantwortliche für die Entgegennahme, Triage, Behebung und Offenlegung von Schwachstellen. Veröffentlichen Sie einen Sicherheitskontakt und definieren Sie einen Eskalationsprozess für Zulieferer. Legen Sie gemäß Artikel 13 den Supportzeitraum unter Berücksichtigung der erwarteten Nutzungsdauer fest: normalerweise mindestens fünf Jahre, aber wenn die erwartete Nutzungsdauer kürzer ist, entspricht der Supportzeitraum dieser erwarteten Nutzungsdauer. Ein langlebiges Produkt kann einen längeren Support erfordern. Kommunizieren Sie das Enddatum des Supports und planen Sie die Ressourcen, um diese Zusage einzuhalten.
Softwarestückliste (SBOM)
Anhang I Teil II fordert eine maschinenlesbare SBOM, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Ein detaillierteres internes Verzeichnis ist für die Triage von Schwachstellen nützlich. Identifizieren Sie Versionen und aktualisieren Sie das Release-Verzeichnis; unterscheiden Sie diese Anforderung von der Verpflichtung, die gesamte SBOM öffentlich zu machen, was keine pauschale CRA-Verpflichtung ist.
Update-Infrastruktur
Stellen Sie einen sicheren Mechanismus zur Verteilung von Sicherheitsupdates bereit, der für das Produkt geeignet ist. Authentizität, Integrität, Wiederherstellung und die Benutzerfreundlichkeit von Updates sind wichtig. OTA, A/B-Slots und Anti-Rollback können geeignete Kontrollmaßnahmen sein, sind aber keine universell vorgeschriebenen Technologien. Testen Sie unterbrochene Updates und die Schlüsselrotation mit der gewählten Architektur.
Meldung von Vorfällen
Die Meldepflicht nach Artikel 14 gilt seit dem 11. September 2026. Sie betrifft aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Produktsicherheit beeinträchtigen, nicht jede in einer Abhängigkeit entdeckte CVE. Sowohl die 24-Stunden-Frühwarnung als auch die 72-Stunden-Meldung beginnen ab dem Zeitpunkt der Kenntnisnahme. Die Meldung erfolgt über die zentrale Meldeplattform an das koordinierende CSIRT und die ENISA, vorbehaltlich der Verbreitungsbestimmungen der Verordnung. Die Fristen für den Abschlussbericht finden Sie im Leitfaden zum Meldeprozess.
Dokumentation und Konformität
Die Hauptanforderungen der CRA gelten ab dem 11. Dezember 2027. Bereiten Sie die Risikobewertung, die technische Dokumentation, Tests, Nachweise zum Umgang mit Schwachstellen und die EU-Konformitätserklärung für den anwendbaren Bewertungsweg vor. Für die Standardkategorie ist eine interne Kontrolle verfügbar. Die Eigenbewertung für Klasse I ist an die Bedingung geknüpft, dass die relevanten harmonisierten Normen, gemeinsamen Spezifikationen oder qualifizierenden Zertifizierungen die anwendbaren Anforderungen abdecken; andernfalls ist eine Bewertung durch Dritte erforderlich. Für Klasse II sind die festgelegten Wege der Bewertung durch Dritte vorgeschrieben. Kritische Produkte unterliegen Artikel 32 und allen anwendbaren Durchführungsrechtsakten zur Zertifizierung nach Artikel 8; Anhang IV allein macht EUCC heute nicht zwingend erforderlich.
Das PSA/SESIP-Zertifikat einer Komponente kann deren bewertete Eigenschaften belegen, aber die Konformität des integrierten Produkts bleibt in der Verantwortung des Herstellers.
Unterstützung bei der EU-Konformität · Besprechen Sie den Bewertungsweg für Ihr Produkt
Häufig gestellte Fragen
Schreibt die CRA ein TPM und OTA-Updates für jedes Produkt vor?
Nein. Die CRA legt risikobasierte wesentliche Anforderungen fest. Ein TPM, Secure Boot, OTA- oder A/B-Updates können geeignete Kontrollmaßnahmen sein, aber das Gesetz schreibt diese spezifischen Technologien nicht universell vor.
Beträgt der Supportzeitraum immer fünf Jahre?
Artikel 13 legt normalerweise mindestens fünf Jahre fest, wobei die erwartete Nutzungsdauer berücksichtigt wird. Wenn die erwartete Nutzungsdauer kürzer ist, entspricht der Supportzeitraum dieser erwarteten Nutzungsdauer; langlebigere Produkte können einen längeren Zeitraum erfordern.
Muss jede entdeckte CVE innerhalb von 24 Stunden gemeldet werden?
Nein. Die Meldepflicht nach Artikel 14 betrifft aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, die die Produktsicherheit beeinträchtigen. Andere Schwachstellen müssen weiterhin im Rahmen der geltenden Verpflichtungen behandelt werden.
Können wichtige Produkte der Klasse I immer eine Eigenbewertung verwenden?
Nein. Die interne Kontrolle hängt davon ab, ob die qualifizierenden Normen, Spezifikationen oder Zertifizierungen die anwendbaren Anforderungen abdecken. Andernfalls ist der vorgeschriebene Weg der Bewertung durch Dritte erforderlich.
Primärquellen
Technische und regulatorische Referenzen, geprüft am 1. Oktober 2026.