CRA Anhang I: 13 Sicherheitsanforderungen erklärt

Warum Anhang I das Herzstück des CRA ist

Anhang I der EU-Verordnung 2024/2847 definiert die grundlegenden Cybersicherheitsanforderungen, die jedes Produkt mit digitalen Elementen vor dem Inverkehrbringen und während seines gesamten Supportzeitraums erfüllen muss. Unabhängig von der Risikoklasse — ob Default, Important oder Critical: Anhang I gilt für alle.

Was sich nach Klasse unterscheidet, ist das Konformitätsbewertungsverfahren (Selbstbewertung vs. Notified Body). Die inhaltlichen Anforderungen aus Anhang I sind dagegen identisch.¹

Anhang I ist in zwei Teile gegliedert:

Teil I: 13 grundlegende Sicherheitsanforderungen an das Produkt selbst
Teil II: 6 Anforderungen an das Schwachstellenmanagement des Herstellers

Zur Lesart dieses Artikels: Jede Anforderung ist klar als gesetzliche Pflicht nach EU-Verordnung 2024/2847 gekennzeichnet. Empfehlungen zur Umsetzung sind Hinweise auf bewährte Vorgehensweisen — nicht vom CRA vorgeschrieben, aber Stand der Technik. Die konkrete Umsetzung liegt im Ermessen des Herstellers, solange das gesetzliche Ziel erreicht wird.

13 Punkte. Klingt überschaubar. In der Praxis sind es 13 eigenständige Compliance-Bereiche — manche, insbesondere Punkt 1, Punkt 10 und Punkt 13, erfordern vollständige interne Programme. Wer glaubt, Anhang I lässt sich an einem Nachmittag abhaken, unterschätzt den Aufwand erheblich.

Teil I: 13 grundlegende Sicherheitsanforderungen

1. Keine bekannten ausnutzbaren Schwachstellen bei Inverkehrbringen

Pflicht nach Anhang I Teil I Nr. 1 CRA: Produkte dürfen zum Zeitpunkt des Inverkehrbringens keine bekannten ausnutzbaren Schwachstellen (exploitable vulnerabilities) enthalten.¹

Was das bedeutet: Vor dem Release müssen Hersteller alle öffentlich bekannten Schwachstellen in eingesetzten Komponenten identifizieren und bewerten. Als bekannt gilt, was in der NVD (National Vulnerability Database) oder CVE-Datenbank veröffentlicht ist. Schwachstellen, die nicht ausnutzbar sind (z. B. Code-Path nicht erreichbar), müssen dokumentiert, aber nicht zwingend behoben werden.

Praxis-Einschätzung: Diese Anforderung klingt selbstverständlich. Die Herausforderung liegt im Detail: Transitive Abhängigkeiten — also Bibliotheken, die Ihre Bibliotheken verwenden — umfassen in modernen Node.js-, Python- oder Java-Projekten leicht 500+ Pakete. Ein IoT-Startup, das ein embedded-Linux-Gateway für Industrie-4.0-Anbindung entwickelt, hat schnell hunderte Pakete im Blick zu behalten — Firmware, Treiber, Middleware. Ohne automatisierte CVE-Überwachung fehlt schlicht der vollständige Überblick. Die Pflicht nach Nr. 1 setzt also de facto einen funktionierenden SBOM- und Monitoring-Prozess voraus — auch wenn das nirgends so explizit steht.

Empfehlung (nicht vom CRA vorgeschrieben, aber Stand der Technik): Schwachstellen-Scan als fester Schritt im Release-Prozess; Dependency-Updates vor jeder Veröffentlichung; dokumentierte Bewertung aller offenen CVEs mit Begründung (ausnutzbar vs. nicht ausnutzbar).

2. Secure-by-Default-Konfiguration

Pflicht nach Anhang I Teil I Nr. 2 CRA: Produkte müssen ab Werk in einer sicheren Standardkonfiguration ausgeliefert werden.¹

Was das bedeutet: Beim ersten Start darf keine unsichere Konfiguration aktiv sein. Klassische Verstöße: voreingestellte Standardpasswörter für alle Instanzen identisch, unnötige Dienste und Schnittstellen standardmäßig aktiviert, Debug-Modus im Produktions-Release aktiv.

Praxis-Einschätzung: Besonders kritisch ist Nr. 2 für Hersteller industrieller MQTT-Gateways — ein physisch zugängliches Gerät mit Standard-SSH-Passwort ist ein offenes Einfallstor. Für SaaS-Anbieter mit lokalem Agent ist die Frage relevanter, welche Ports der Agent standardmäßig öffnet und ob Debug-Endpunkte im Release aktiv sind. Die Pflicht gilt in beiden Fällen, die Risiken sind nur unterschiedlich.

Empfehlung: Checkliste für Standardkonfiguration vor Release; Penetrationstest auf frischer Installation; kein Default-Passwort — stattdessen Pflicht zur individuellen Passwortvergabe beim Erstkauf oder automatisch generierte einmalige Passwörter.

3. Schutz vor unbefugtem Zugriff (Authentifizierung und Zugriffskontrolle)

Pflicht nach Anhang I Teil I Nr. 3 CRA: Produkte müssen Mechanismen zur Authentifizierung und Zugriffskontrolle implementieren, die unbefugten Zugriff auf Systeme, Daten und Funktionen verhindern.¹

Was das bedeutet: Mindest-Anforderungen sind eine funktionsfähige Authentifizierung für alle Zugangspunkte, rollenbasierte Zugriffskontrolle (RBAC), keine hartkodierten Zugangsdaten im Code sowie sichere Passwortspeicherung (bcrypt, Argon2 oder vergleichbare Algorithmen).

Praxis-Einschätzung: Für einen Maschinenbauer, der seiner CNC-Steuerung erstmals eine Weboberfläche spendiert, ist Nr. 3 oft der größte Sprung. „Kein Passwort im Produktionsnetz nötig” — dieses Argument zieht nicht mehr. Der CRA kennt keine Ausnahme für Intranet-Geräte. Bedeutet konkret: Auth-Konzept vor der ersten Zeile UI-Code.

Empfehlung: Auth-Bibliothek mit aktivem Wartungs-Support einsetzen; MFA anbieten (für privilegierte Accounts empfohlen, nicht zwingend vorgeschrieben); regelmäßiges Review der Zugriffsrechte; keine Hardcoded Credentials im Quellcode (Pre-Commit-Hooks sind ein bewährtes Mittel).

4. Schutz der Vertraulichkeit (Verschlüsselung)

Pflicht nach Anhang I Teil I Nr. 4 CRA: Produkte müssen personenbezogene Daten und andere sensible Daten sowohl bei der Übertragung als auch bei der Speicherung schützen.¹

Was das bedeutet: Transportverschlüsselung (TLS 1.2 oder höher) für alle Netzwerkkommunikation; Verschlüsselung gespeicherter sensibler Daten (at rest encryption); keine unsicheren Protokolle (HTTP, FTP, Telnet) für sensible Datenübertragungen.

Praxis-Einschätzung: TLS ist nicht neu — aber die Pflicht gilt auch für interne Kommunikation zwischen Diensten, für embedded-Software mit MQTT-Anbindung und für lokale APIs. Wer heute noch unverschlüsseltes HTTP zwischen Microservices betreibt, hat Handlungsbedarf.

Empfehlung: TLS-Konfiguration mit aktuellen Cipher-Suites (BSI TR-02102-2 als Referenz für den deutschen Markt); Key-Management-Prozess für Verschlüsselungsschlüssel; kryptographische Algorithmen nur aus geprüften Bibliotheken (keine Eigenimplementierungen).

5. Schutz der Integrität (Manipulationsschutz)

Pflicht nach Anhang I Teil I Nr. 5 CRA: Produkte müssen die Integrität von Daten, Software und Konfigurationen schützen — sowohl gegen zufällige Fehler als auch gegen absichtliche Manipulation.¹

Was das bedeutet: Software-Updates müssen kryptographisch signiert sein; das Produkt muss die Signatur vor der Installation verifizieren; Konfigurationsänderungen sollten protokolliert werden; Manipulationen an Systemdateien sollten erkennbar sein.

Praxis-Einschätzung: Code-Signing ist bekannt, aber viele Teams signieren nur den Installer, nicht die einzelnen Binaries oder Konfigurationsdateien. Für embedded-Software für Heizungssteuerungen oder Gebäudeautomation bedeutet Nr. 5 oft einen tiefergreifenden Umbau der Update-Infrastruktur — aufwändiger als ein Code-Signing-Zertifikat zu kaufen. Das klingt nach bürokratischem Aufwand. Ist es auch. Aber es ist Pflicht.

Empfehlung: Code-Signing-Zertifikat für Software-Releases; Update-Verifizierung im Update-Client implementieren; Integritätsprüfung kritischer Konfigurationsdateien; Audit-Log für sicherheitsrelevante Aktionen.

6. Minimierung der Angriffsfläche

Pflicht nach Anhang I Teil I Nr. 6 CRA: Produkte müssen so gestaltet sein, dass die Angriffsfläche auf das für den Zweck notwendige Minimum reduziert wird.¹

Was das bedeutet: Unnötige Dienste, Ports und Schnittstellen sind zu deaktivieren oder zu entfernen. Jede aktivierte Schnittstelle muss einen dokumentierten Zweck haben. Exposure-Prinzip: nichts offen lassen, was nicht offen sein muss.

Praxis-Einschätzung: Container-Images sind hier ein typisches Problemfeld: Wer einen Standard-Node.js-Basis-Image nimmt, liefert oft Dutzende nicht benötigte Pakete mit. Der Distroless-Ansatz ist gut, erfordert aber Disziplin beim Build-Prozess. Die Compliance-Frage ist eindeutig: Können Sie für jeden offenen Port und jeden aktivierten Dienst begründen, warum er notwendig ist?

Empfehlung: Port-Scan auf die Produktinstallation als Teil des Release-Prozesses; Firewall-Regeln dokumentieren; unnötige Betriebssystem-Pakete in Container-Images nicht mitliefern (Distroless-Ansatz); regelmäßige Überprüfung aktivierter Features gegen aktive Nutzung.

7. Verfügbarkeit der Grundfunktionen (Resilience gegen DoS)

Pflicht nach Anhang I Teil I Nr. 7 CRA: Produkte müssen gegen Denial-of-Service-Angriffe resistent sein und die Verfügbarkeit ihrer Grundfunktionen auch unter Angriffen sicherstellen.¹

Was das bedeutet: Grundfunktionen des Produkts sollen nicht durch einfache Überlastungsangriffe außer Funktion gesetzt werden können. Das schließt Rate Limiting, ressourcen-schonendes Design und einen definierten Degradation-Modus ein.

Was hier viele falsch verstehen: Nr. 7 ist keine Pflicht zur Hochverfügbarkeit. Es geht um Resilienz gegen einfache Angriffe, nicht um 99,99%-SLAs. Vernünftiges Rate Limiting und dokumentiertes Graceful-Degradation-Verhalten reichen in den meisten Fällen aus. Entscheidend ist, dass das Verhalten unter Last dokumentiert und getestet ist.

Empfehlung: Rate Limiting für alle API-Endpunkte; Connection-Limits und Timeouts konfigurieren; Lasttest als Teil der Qualitätssicherung; Graceful-Degradation dokumentieren (was passiert bei Teilausfall).

8. Minimale Datenverarbeitung (Privacy by Design)

Pflicht nach Anhang I Teil I Nr. 8 CRA: Produkte müssen nach dem Prinzip der Datenminimierung konzipiert sein: Erheben, verarbeiten und speichern dürfen Hersteller nur Daten, die für den vorgesehenen Zweck zwingend notwendig sind.¹

Was das bedeutet: Kein Data Hoarding auf Vorrat; Löschkonzepte für alle gespeicherten Datenkategorien; keine versteckte Telemetrie ohne Zustimmung; Verarbeitungszwecke dokumentieren.

Praxis-Einschätzung: Diese Anforderung überschneidet sich mit DSGVO-Anforderungen — wer bereits Privacy-by-Design umgesetzt hat, ist hier oft schon gut aufgestellt. Der CRA fügt eine produktspezifische Dimension hinzu: Die Datenminimierung bezieht sich nicht nur auf personenbezogene Daten, sondern auf alle von der Funktion nicht zwingend benötigten Daten.

Empfehlung: Datenflussanalyse vor der Implementierung; Privacy-by-Design-Review in der Designphase; Retention-Policies für alle Datenkategorien; Privacy Impact Assessment bei neuen Funktionen mit erhöhtem Risiko.

9. Schutz von Daten nach Zugriffsverlust

Pflicht nach Anhang I Teil I Nr. 9 CRA: Produkte müssen sicherstellen, dass Daten nach Ablauf der Nutzung, nach Geräteentsorgung oder nach Verlust des Zugriffs nicht unbefugt ausgelesen werden können.¹

Was das bedeutet: Beim Zurücksetzen auf Werkseinstellungen müssen Hersteller alle Nutzerdaten sicher löschen; bei Geräteentsorgung sollte eine sichere Datenlöschung möglich sein; Verschlüsselung gespeicherter Daten ist Voraussetzung für sicheres Löschen.

Praxis-Einschätzung: Für SaaS-Produkte mit lokalem Agent — ein verbreitetes Muster — stellt sich die Frage: Was bleibt auf dem Client nach der Deinstallation? Log-Dateien, Konfigurationen, Caches? Die Pflicht nach Nr. 9 verlangt, dass auch der Client einen sauberen Reset-Pfad hat. Gerade wenn der Fokus auf dem Cloud-Backend liegt, wird das gerne vergessen.

Empfehlung: Sicherer Reset-Mechanismus implementieren und testen; verschlüsselte Speicherung (dann reicht Key-Löschung statt Überschreiben); Dokumentation des Löschvorgangs für Nutzer.

10. Sicherheitsupdates über den Lebenszyklus

Pflicht nach Anhang I Teil I Nr. 10 CRA: Hersteller müssen Sicherheitsupdates für den gesamten Unterstützungszeitraum — mindestens 5 Jahre — bereitstellen. Updates müssen kostenlos sein und separat von Funktionsupdates möglich sein.¹

Was das bedeutet: Kunden dürfen Hersteller nicht zwingen, ein kostenpflichtiges Upgrade auf eine neue Hauptversion zu kaufen, um einen Sicherheitspatch zu erhalten. Die Update-Bereitstellung muss automatisierbar sein; der Update-Kanal muss sicher (signierte Updates) sein.

Praxis-Einschätzung: Nr. 10 ist für viele Hersteller die wirtschaftlich folgenschwerste Anforderung. Fünf Jahre Sicherheitssupport bedeuten: langfristige Ressourcenplanung, LTS-Versionen, und die Bereitschaft, für ältere Produktlinien Patches zu entwickeln, obwohl das Team längst an Version 4.0 arbeitet. Besonders hart trifft das Maschinenbau-Unternehmen: Maschinen laufen Jahrzehnte, aber Software-Support-Zyklen wurden bisher kürzer gedacht. Wer heute schon Kunden hat, die auf veralteten Versionen festsitzen, weil Upgrades kostenpflichtig sind, muss sein Lizenzmodell überdenken.

Empfehlung: Update-Prozess als Produkt-Feature von Beginn an mitdenken; Branching-Strategie für Long-Term-Support-Versionen; Kommunikationskanal für Sicherheits-Updates (Security Advisories); automatische Update-Funktion anbieten.

11. Überwachung auf Schwachstellen (CVE-Monitoring)

Pflicht nach Anhang I Teil I Nr. 11 CRA: Hersteller müssen bekannte Schwachstellen in den Komponenten ihrer Produkte kontinuierlich überwachen.¹

Was das bedeutet: Passive Überwachung von CVE-Datenbanken für alle eingesetzten Drittkomponenten; aktive Benachrichtigungsmechanismen (z. B. GitHub Dependabot, OSV.dev Alerts) nutzen; Prozess für die Bewertung und Reaktion auf neu entdeckte Schwachstellen.

Praxis-Einschätzung: Automatisierte CVE-Überwachung ist technisch lösbar — Dependabot ist kostenlos. Die eigentliche Herausforderung: Wer bewertet eingehende Alerts in einem KMU ohne dediziertes Security-Team? Und was passiert am Freitagabend, wenn ein kritisches CVE für eine Ihrer Kernbibliotheken veröffentlicht wird? Die Pflicht nach Nr. 11 erfordert nicht nur ein Tool, sondern einen Prozess mit klaren Verantwortlichkeiten.

Empfehlung: Automatisierte CVE-Überwachung mit geeigneten Tools wie OWASP Dependency-Check, Dependabot oder Renovate; SLA für die Bewertung neuer CVEs (z. B. kritische CVEs innerhalb von 24h bewerten); SBOM als Grundlage für den Abgleich gegen CVE-Datenbanken. Mehr zur SBOM-Erstellung unter SBOM erstellen: Anleitung für CRA-Pflicht.

12. Vulnerability-Disclosure-Policy (VDP)

Pflicht nach Anhang I Teil I Nr. 12 CRA: Hersteller müssen einen öffentlich zugänglichen Kanal für die Meldung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) bereitstellen und Meldungen systematisch bearbeiten.¹

Was das bedeutet: Eine E-Mail-Adresse (security@…) oder ein Webformular für Sicherheitsmeldungen; eine dokumentierte Policy, die beschreibt, wie der Hersteller mit eingehenden Meldungen umgeht (Bestätigung, Zeitrahmen, Koordination); kein juristisches Vorgehen gegen gutgläubige Sicherheitsforscher (Safe Harbour).

Praxis-Einschätzung: Eine VDP ist das am einfachsten umsetzbare Element auf dieser Liste. Eine security@-Adresse und ein öffentliches Dokument auf der Website sind in einem Nachmittag erledigt. Der interne Prozess dahinter — wer liest diese Mails, wer entscheidet über die Reaktion, wer koordiniert mit dem Forscher — das ist die eigentliche Arbeit.

Empfehlung: security.txt auf der Produktwebseite veröffentlichen (RFC 9116); VDP-Dokument öffentlich zugänglich machen; internen Prozess für die Bearbeitung von Meldungen etablieren; Koordination mit ENISA-Plattform für aktiv ausgenutzte Schwachstellen (Meldepflicht nach Artikel 14).

13. SBOM-Pflicht (Software Bill of Materials)

Pflicht nach Anhang I Teil I Nr. 13 CRA: Hersteller müssen eine maschinenlesbare Software Bill of Materials (SBOM) erstellen und aktuell halten.¹

Was das bedeutet: Eine vollständige Komponentenliste aller Software-Bestandteile des Produkts (inkl. Open-Source-Abhängigkeiten) in einem standardisierten Format (CycloneDX oder SPDX). Die SBOM ist Grundlage für das CVE-Monitoring (Punkt 11) und für die Nachweispflicht gegenüber Marktaufsichtsbehörden.

Praxis-Einschätzung: SBOM-Tools wie Syft oder cdxgen sind gut — aber die eigentliche Arbeit ist nicht das Tool, sondern sicherzustellen, dass jede Dependency tatsächlich erfasst ist. Bei Monorepos mit 50+ Packages, bei Projekten mit nativen Binaries und mehreren Laufzeitumgebungen passieren hier regelmäßig Lücken. Eine SBOM ist nur so gut wie die Vollständigkeit ihrer Quellen.

Empfehlung: SBOM-Erzeugung in CI/CD-Pipeline integrieren; bei jedem Release neue SBOM generieren; Aufbewahrung zusammen mit technischer Dokumentation. Eine detaillierte Anleitung finden Sie unter SBOM erstellen: Anleitung für CRA-Pflicht.

Teil II: 6 Anforderungen an das Schwachstellenmanagement

Teil II von Anhang I richtet sich nicht an das Produkt selbst, sondern an die Prozesse und Strukturen des Herstellers rund um Schwachstellen-Behandlung. Alle sechs Punkte sind Pflicht nach EU-Verordnung 2024/2847, Anhang I Teil II.¹

#	Anforderung	Erläuterung
1	Identifikation und Dokumentation von Schwachstellen	Prozess zur systematischen Erkennung, Dokumentation und Nachverfolgung von Schwachstellen im gesamten Produktportfolio
2	Regelmäßige Tests und Sicherheitsbewertungen	Penetrationstests, Schwachstellen-Scans und sicherheitsbezogene Code-Reviews als regulärer Bestandteil des Entwicklungsprozesses
3	Koordinierte Schwachstellen-Offenlegung (CVD-Policy)	Öffentlicher Prozess, der es Sicherheitsforschern ermöglicht, Schwachstellen verantwortungsvoll zu melden (Koordination, Bestätigungspflicht, Zeitrahmen bis Disclosure)
4	Sicherheitsupdates ohne Verzögerung	Bereitstellung von Patches für bekannte ausnutzbare Schwachstellen ohne unnötige Verzögerung; Trennung von Security-Patches und Feature-Updates
5	Meldung aktiv ausgenutzter Schwachstellen	Meldepflicht nach Artikel 14: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen innerhalb von 24 Stunden an ENISA gemeldet werden — diese Pflicht gilt bereits ab September 2026
6	Öffentliche Offenlegung nach Behebung	Nach Bereitstellung eines Patches: koordinierte Offenlegung der Schwachstellen-Details, z. B. als CVE-Eintrag oder Security Advisory

Übersicht: Anforderungen nach Schwierigkeit und typischer Umsetzung

Anforderung	Schwierigkeit	Typische Umsetzung
1 — Keine bekannten Schwachstellen	Mittel	Dependency-Check im CI/CD, CVE-Scan vor Release
2 — Secure by Default	Niedrig	Konfigurationscheckliste, kein Default-Passwort
3 — Authentifizierung / Zugriffskontrolle	Mittel	RBAC, MFA, keine Hardcoded Credentials
4 — Verschlüsselung	Niedrig–Mittel	TLS 1.2+, Key Management, BSI TR-02102
5 — Integrität	Mittel	Code-Signing, Update-Verifikation, Audit-Logs
6 — Angriffsfläche minimieren	Niedrig	Port-Scan, Distroless-Container, Feature-Flags
7 — DoS-Resilience	Mittel	Rate Limiting, Lasttest, Graceful Degradation
8 — Datenminimierung	Mittel	Datenflussanalyse, Retention-Policies
9 — Datenschutz nach Zugriffsverlust	Niedrig–Mittel	Sicherer Reset, verschlüsselte Speicherung
10 — Sicherheitsupdates	Hoch	Update-Mechanismus, LTS-Strategie, 5+ Jahre
11 — CVE-Monitoring	Niedrig–Mittel	Dependabot/Renovate, OSV.dev, SBOM-Abgleich
12 — Vulnerability Disclosure Policy	Niedrig	security.txt, VDP-Dokument, Interner Prozess
13 — SBOM	Niedrig–Mittel	cdxgen/Syft in CI/CD, CycloneDX 1.6

Was sind harmonisierte Normen und wie helfen sie?

Neben den Anforderungen aus Anhang I gibt es harmonisierte europäische Normen, deren vollständige Anwendung eine Konformitätsvermutung erzeugt. Das bedeutet: Wer eine harmonisierte Norm vollständig anwendet, gilt als konform mit den entsprechenden Anforderungen aus Anhang I — ohne jeden Aspekt separat nachzuweisen.

Für den CRA sind insbesondere relevant:

EN 18031 (in Entwicklung): Horizontale Cybersicherheitsnorm für netzwerkfähige Produkte, direkt auf CRA Anhang I ausgerichtet. Die Veröffentlichung der harmonisierten Version im EU-Amtsblatt wird für 2025/2026 erwartet.
ETSI EN 303 645: Bewährter Standard für Consumer-IoT-Geräte. Bereits heute als Grundlage für Selbstbewertung von Important Class I nutzbar, sofern als harmonisierter Standard im Amtsblatt gelistet.
IEC 62443: International anerkannter Standard für industrielle Cyber-Sicherheit. Hohe inhaltliche Überlappung mit CRA Anhang I (~70–80 %), aber kein direktes Mapping.

Praktische Einschätzung: Der Stand der harmonisierten Normen entwickelt sich dynamisch. Prüfen Sie die aktuelle Liste harmonisierter Normen regelmäßig im Amtsblatt der EU (Reihe C). Wer Important Class I anstrebt und keine Notified-Body-Prüfung möchte, muss eine vollständig harmonisierte Norm anwenden — was zum jetzigen Zeitpunkt (2026) noch nicht in allen Bereichen möglich ist.

Anhang I in der Praxis: Welche Anforderungen sind für wen kritisch?

Nicht alle Anforderungen haben für jedes Produkt das gleiche Gewicht. Die folgende Einschätzung bezieht sich auf gängige B2B-Softwareprodukte.

Für Cloud-native SaaS-Produkte sind die kritischsten Anforderungen: Nr. 3 (Zugriffskontrolle), Nr. 4 (Verschlüsselung), Nr. 10 (Update-Bereitstellung) und Nr. 12 (VDP) — da diese direkt den Kundendaten-Schutz und die Hersteller-Compliance betreffen.

Für SaaS-Produkte mit lokalem Agent (ein verbreitetes B2B-Muster) kommen Nr. 2 (Secure by Default des Clients), Nr. 9 (Datenlöschung nach Deinstallation) und Nr. 5 (Integrität der Client-Updates) besonders zum Tragen.

Für eingebettete Systeme und IoT-Hardware — z.B. industrielle MQTT-Gateways oder embedded-Software für Heizungssteuerungen — sind Nr. 2 (Secure by Default), Nr. 6 (Angriffsfläche) und Nr. 13 (SBOM) besonders herausfordernd. Firmware-Updates und Komponentenermittlung sind bei Hardware-Produkten aufwändiger als bei reiner Software. Wer ein solches Gerät verkauft, merkt das spätestens beim ersten SBOM-Versuch.

Für Maschinenbau-Unternehmen mit Software-Anteil stellt Nr. 10 (5 Jahre Sicherheitsupdates) oft die größte Umstellung dar: Maschinen laufen Jahrzehnte, aber Software-Support-Zyklen wurden bisher kürzer gedacht.

Für alle Produkttypen gilt Nr. 10 (Sicherheitsupdates über 5+ Jahre) als hohe Hürde, da sie langfristige Ressourcenplanung erfordert.

Nächste Schritte zur CRA-Konformität

Sinnvoll ist diese Reihenfolge:

Risikoklasse bestimmen — die Anforderungen gelten für alle, aber der Nachweis-Aufwand variiert. Zur kostenlosen Klassifizierung.
SBOM erstellen — Grundlage für Nr. 11 und Nr. 13. Anleitung: SBOM erstellen
Gap-Analyse — Welche der 13 Anforderungen sind bereits umgesetzt, welche fehlen?
Maßnahmenplan — priorisiert nach Schwierigkeit (Tabelle oben)
Dokumentation — Risikoanalyse, technische Dokumentation, Konformitätserklärung

Für einen vollständigen Überblick aller Hersteller-Pflichten lesen Sie CRA-Pflichten für Hersteller. Das Evidence Pack enthält strukturierte Dokumentationsvorlagen für alle Anf