Cyber Resilience Act (CRA): Pflichten, Fristen und Umsetzung 2026–2027

Der Cyber Resilience Act (CRA) ist die EU-Verordnung 2024/2847 für die Cybersicherheit von Produkten mit digitalen Elementen. Er betrifft einen großen Teil der Hard- und Software, die im EU-Markt bereitgestellt wird. Für Unternehmen ist 2026 kein Vorbereitungsjahr mehr: Seit 11. Juni 2026 gelten bereits die Regeln für Konformitätsbewertungsstellen, ab 11. September 2026 greifen die Meldepflichten nach Artikel 14 und ab 11. Dezember 2027 gilt der CRA grundsätzlich vollständig.

Direkt vertiefen: Für die technische Umsetzung sind besonders die CRA-Risikobewertung, die Software Bill of Materials (SBOM) und der CRA-Supportzeitraum mit Sicherheitsupdates relevant. Diese drei Seiten führen die zentralen Herstellerpflichten jeweils bis in den praktischen Prozess weiter.

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act ist ein unmittelbar geltender EU-Rechtsrahmen für die Cybersicherheit von Hardware- und Softwareprodukten. Anders als klassische IT-Sicherheitsvorgaben, die vor allem den Betrieb eines Unternehmens oder einer kritischen Einrichtung adressieren, setzt der CRA am Produkt selbst und an seinem Lebenszyklus an. Hersteller müssen Sicherheitsanforderungen bereits bei Konzeption und Entwicklung berücksichtigen, Schwachstellen während des Supportzeitraums behandeln und nachweisen können, wie sie die Anforderungen erfüllen.

Der zentrale Begriff ist das „Produkt mit digitalen Elementen“. Dazu gehören nach Artikel 3 Software- oder Hardwareprodukte und bestimmte Datenfernverarbeitungslösungen sowie separat in Verkehr gebrachte Software- oder Hardwarekomponenten. Damit kann der CRA vom vernetzten Haushaltsgerät über Router und Betriebssysteme bis zur mobilen App oder Softwarekomponente reichen. Reine Websites oder allgemeine Cloud-Dienste fallen dagegen nicht automatisch unter den CRA. Entscheidend ist, ob die jeweilige Remote-Verarbeitung für eine Funktion des Produkts notwendig ist und unter der Verantwortung des Herstellers entwickelt wurde.

Wer die eigene Betroffenheit prüfen möchte, findet im Ratgeber CRA-Anwendungsbereich: Welche Unternehmen und Produkte sind betroffen? die Abgrenzung nach Produkt und Rolle.

Welche CRA-Fristen gelten 2026 und 2027?

Die drei wichtigsten Daten sind der 11. Juni 2026, der 11. September 2026 und der 11. Dezember 2027. Diese Stufen stehen direkt in Artikel 71 der Verordnung.

Die Übergangsregeln sind wichtig: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, werden nicht allein durch das Datum automatisch vollständig CRA-pflichtig. Die Verordnung enthält aber Regeln für wesentliche Änderungen. Die Meldepflichten ab September 2026 können außerdem auch Produkte erfassen, die bereits vorher im EU-Markt bereitgestellt wurden. Deshalb darf ein Unternehmen die Vorbereitung auf das Jahr 2027 nicht verschieben.

Eine detaillierte Zeitleiste mit Vorbereitungsschritten steht auf CRA-Fristen 2026–2027.

Wer trägt die Verantwortung nach dem CRA?

Die weitreichendsten Pflichten treffen Hersteller. Ein Hersteller ist nicht nur derjenige, der Hardware in einer eigenen Fabrik produziert. Hersteller kann auch ein Unternehmen sein, das Software oder Hardware entwickeln lässt und das Produkt anschließend unter dem eigenen Namen oder der eigenen Marke vermarktet. Der Begriff erfasst damit viele Softwarehäuser, App-Anbieter, IoT-Unternehmen, Gerätehersteller und Anbieter von White-Label-Produkten.

Welche Rolle haben Importeure?

Importeure müssen vor dem Inverkehrbringen unter anderem prüfen, ob der Hersteller das geeignete Konformitätsbewertungsverfahren durchgeführt hat, die technische Dokumentation erstellt wurde, CE-Kennzeichnung und EU-Konformitätserklärung vorhanden sind und bestimmte Herstellerangaben eingehalten werden. Wer Produkte aus einem Drittstaat in die EU einführt, kann sich daher nicht darauf verlassen, dass ausschließlich der ausländische Hersteller verantwortlich ist.

Welche Rolle haben Händler?

Händler müssen mit der gebotenen Sorgfalt handeln. Sie prüfen vor der Bereitstellung unter anderem, ob die CE-Kennzeichnung vorhanden ist und ob Hersteller beziehungsweise Importeur bestimmte Informations- und Kennzeichnungspflichten erfüllt haben. Bei erkennbarer Nichtkonformität darf das Produkt nicht einfach weiter angeboten werden.

Welche grundlegenden Cybersicherheitsanforderungen verlangt der CRA?

Der CRA verlangt kein einzelnes Sicherheitsprodukt und keine bestimmte Checkliste für alle Fälle. Ausgangspunkt ist die Cybersicherheitsrisikobewertung. Hersteller müssen die Risiken des konkreten Produkts bewerten und die Ergebnisse über Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung berücksichtigen.

Anhang I Teil I nennt Anforderungen an die Eigenschaften des Produkts. Dazu gehört insbesondere, dass Produkte risikogerecht sicher konzipiert, entwickelt und hergestellt werden. Der CRA nennt unter anderem sichere Standardkonfigurationen, angemessene Zugangskontrollen, Schutz der Vertraulichkeit und Integrität von Daten, Minimierung der Angriffsfläche, Begrenzung negativer Auswirkungen von Vorfällen und die Möglichkeit, Sicherheitsaktualisierungen bereitzustellen.

Was bedeutet „secure by default“?

Secure by default bedeutet, dass ein Produkt nicht erst durch umfangreiche Nacharbeit des Nutzers in einen sicheren Grundzustand gebracht werden darf. Unsichere Standardpasswörter, unnötig offene Dienste oder ab Werk aktivierte Funktionen ohne Sicherheitsbedarf sind typische Punkte, die Unternehmen in ihrem Produktdesign kritisch prüfen sollten. Welche Maßnahmen angemessen sind, hängt vom Produkt und der Risikobewertung ab.

Welche Rolle spielt die Software-Stückliste?

Anhang I Teil II verlangt, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren. Dazu gehört eine Software-Stückliste, häufig als SBOM bezeichnet, in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten des Produkts sichtbar macht. Für Unternehmen bedeutet das: Abhängigkeiten dürfen nicht nur im Build-System existieren. Sie müssen strukturiert nachvollziehbar sein, damit Schwachstellen in Komponenten schnell einem Produkt und betroffenen Versionen zugeordnet werden können.

Welche Herstellerpflichten gehören in den Produktprozess?

Die CRA-Umsetzung funktioniert am besten, wenn die Anforderungen nicht als separate Dokumentationsübung kurz vor Markteinführung behandelt werden. Die Pflichten gehören in Entwicklung, Produktmanagement, Release, Support und Incident Response.

Zu den zentralen Aufgaben zählen die dokumentierte Cybersicherheitsrisikobewertung, angemessene technische und organisatorische Sicherheitsmaßnahmen, die Behandlung von Schwachstellen, Sicherheitsprüfungen, die technische Dokumentation, die Auswahl und Durchführung des Konformitätsbewertungsverfahrens, die EU-Konformitätserklärung, die CE-Kennzeichnung sowie Informationen und Anleitungen für Nutzer.

Hinzu kommt der Supportzeitraum. Hersteller müssen festlegen, wie lange Schwachstellen des Produkts wirksam behandelt werden. Das Enddatum des Supportzeitraums muss beim Kauf klar und verständlich angegeben werden. Wer bisher Produktpflege nur intern geplant hat, braucht deshalb künftig einen belastbaren Zusammenhang zwischen erwarteter Nutzungsdauer, Updatefähigkeit, Verantwortlichkeiten und Kundeninformation.

Die ausführliche Umsetzung ist im Cluster CRA-Herstellerpflichten: Schritt für Schritt zur Umsetzung beschrieben.

Was muss beim Schwachstellenmanagement vorbereitet werden?

Der CRA betrachtet Schwachstellenmanagement als laufende Produktpflicht. Hersteller müssen Schwachstellen und Komponenten ermitteln und dokumentieren, Risiken bewerten, Schwachstellen unverzüglich behandeln und Sicherheitsaktualisierungen bereitstellen. Soweit technisch machbar, sollen neue Sicherheitsupdates getrennt von Funktionsupdates bereitgestellt werden. Produkte und die zugehörigen Prozesse müssen regelmäßig und wirksam auf Sicherheit geprüft werden.

In der Praxis braucht es deshalb einen Eingangskanal für Vulnerability Reports, klare Zuständigkeiten für Triage und Bewertung, eine Zuordnung zu betroffenen Produktversionen, einen Patch- und Release-Prozess sowie einen Plan für Kundenkommunikation. Eine öffentlich auffindbare Kontaktstelle für Schwachstellenmeldungen ist ebenfalls Teil der Herstellerpflichten.

Was ändert sich bei Meldepflichten ab 11. September 2026?

Ab dem 11. September 2026 gilt Artikel 14. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, von denen sie Kenntnis erlangen, über die einheitliche Meldeplattform an das zuständige CSIRT und die ENISA melden.

Bei einer aktiv ausgenutzten Schwachstelle ist eine Frühwarnung innerhalb von 24 Stunden vorgesehen, die weitergehende Meldung grundsätzlich innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist. Für schwere Sicherheitsvorfälle gelten ebenfalls abgestufte Fristen. Diese kurzen Zeitfenster machen einen internen Meldeprozess zwingend.

Die Einzelheiten, Definitionen und ein praxistauglicher Eskalationsablauf stehen im Ratgeber CRA-Meldepflichten: 24 Stunden, 72 Stunden und Abschlussbericht.

Wie funktioniert die Konformitätsbewertung?

Die Konformitätsbewertung hängt von der Produktkategorie ab. Viele Standardprodukte dürfen grundsätzlich im Wege der Selbstbewertung durch den Hersteller bewertet werden. Für wichtige Produkte gelten strengere Anforderungen. In bestimmten Fällen muss eine benannte Stelle beteiligt werden. Für kritische Produkte ist die Drittbewertung grundsätzlich verpflichtend.

Die Europäische Kommission nennt als typische Standardprodukte beispielsweise mobile Apps, Computerspiele oder smarte Lautsprecher. Zu wichtigen Produkten gehören je nach Kategorie unter anderem Betriebssysteme, Antivirusprodukte, Router oder Firewalls. Kritische Produkte umfassen beispielsweise bestimmte sichere Elemente oder Smart-Meter-Gateways. Die technische Beschreibung der wichtigen und kritischen Produktkategorien wurde durch die Durchführungsverordnung (EU) 2025/2392 weiter konkretisiert.

Der komplette Entscheidungsweg ist auf CRA-Konformitätsbewertung und CE-Kennzeichnung beschrieben.

Wie behandelt der CRA Open Source?

Der CRA enthält besondere Regeln für freie und quelloffene Software. Nicht jede Veröffentlichung von Open-Source-Code macht einen privaten Entwickler zum CRA-Hersteller. Nach der aktuellen Erläuterung der Europäischen Kommission fällt freie und quelloffene Software insbesondere dann in den regulären Anwendungsbereich, wenn sie im Rahmen einer kommerziellen Tätigkeit auf dem Markt bereitgestellt wird. Für juristische Personen, die bestimmte Open-Source-Produkte nachhaltig unterstützen und deren Lebensfähigkeit sicherstellen, führt der CRA die Rolle des Open-Source-Software-Stewards ein.

Unternehmen sollten Open Source deshalb nicht pauschal als „ausgenommen“ behandeln. Entscheidend sind Bereitstellung, Monetarisierung, Verantwortung und die konkrete Rolle. Mehr dazu steht unter CRA und Open Source.

Wie sollte ein Unternehmen die CRA-Umsetzung organisieren?

Ein praxistauglicher Start ist eine Bestandsaufnahme auf Produktebene. Die häufigste Fehlentscheidung wäre, zuerst eine allgemeine Sicherheitsrichtlinie zu schreiben und erst danach zu prüfen, welche Produkte und Rollen überhaupt betroffen sind.

1. Produkte inventarisieren: Produktname, Versionen, Zielmarkt, Komponenten, Remote-Funktionen und erwartete Nutzungsdauer dokumentieren.
2. Rolle bestimmen: Hersteller, Importeur, Händler, Bevollmächtigter oder Kombination.
3. Produktkategorie bestimmen: Standard, wichtig Klasse I/II oder kritisch.
4. Risikobewertung etablieren: Bedrohungen, Schutzgüter, vorhersehbare Nutzung und Fehlanwendung erfassen.
5. Secure-Development-Prozess prüfen: Anforderungen, Code- und Architekturprüfung, Tests, Build-Sicherheit und Release-Freigaben nachvollziehbar machen.
6. Komponentenmanagement aufbauen: SBOM, Abhängigkeiten, Schwachstellenquellen und Verantwortlichkeiten verbinden.
7. Vulnerability Handling definieren: Meldung, Triage, Bewertung, Fix, Veröffentlichung und Update-Verteilung festlegen.
8. 24/72-Stunden-Prozess testen: Verantwortliche, Vertretung, Eskalation und Informationen für die EU-Meldung vorbereiten.
9. Dokumentation strukturieren: Technische Unterlagen nicht erst am Ende sammeln, sondern aus dem Entwicklungsprozess erzeugen.
10. Konformitätspfad festlegen: Prüfen, ob Selbstbewertung möglich ist oder eine benannte Stelle benötigt wird.

Welche Fehler sollten Unternehmen vermeiden?

Den CRA nur als CE-Projekt behandeln

Die CE-Kennzeichnung steht am Ende eines längeren Sicherheits- und Nachweisprozesses. Wer erst kurz vor Markteinführung mit CRA-Dokumentation beginnt, muss Risikobewertung, Entwicklung, Komponentenwissen und Vulnerability Handling nachträglich rekonstruieren.

Nur neue Produkte betrachten

Die Meldepflichten starten früher als die vollständige Anwendung des CRA. Bestandsprodukte und bestehende Incident-Prozesse müssen deshalb separat geprüft werden.

Open Source pauschal ausnehmen

Open Source hat Sonderregeln, ist aber nicht generell außerhalb des CRA. Besonders kommerzielle Bereitstellung und die Rolle als Hersteller oder Steward müssen sauber eingeordnet werden.

Supportzeitraum und Updatefähigkeit getrennt planen

Ein zugesagter Supportzeitraum ist nur belastbar, wenn das Produkt tatsächlich aktualisierbar ist, Komponenten überwacht werden und Ressourcen für Sicherheitsupdates eingeplant sind.

Wo steht der verbindliche Rechtstext?

Maßgeblich ist die Verordnung (EU) 2024/2847 im EUR-Lex-Portal. CRA Experte übersetzt die Anforderungen in eine verständliche Struktur und praktische Arbeitsschritte, ersetzt aber nicht den verbindlichen Wortlaut oder eine individuelle rechtliche Bewertung.

Was sollten Unternehmen jetzt als Nächstes tun?

Unternehmen sollten zuerst die eigene Betroffenheit und Rolle klären und danach die Fristen gegen den heutigen Reifegrad halten. Für 2026 ist besonders der Meldeprozess dringend: Innerhalb von 24 beziehungsweise 72 Stunden lässt sich keine Verantwortlichkeitsstruktur improvisieren. Parallel sollten Produktklassifizierung, Risikobewertung, SBOM, Secure Development, Supportzeitraum und Konformitätspfad so weit vorbereitet werden, dass 2027 nicht zu einem reinen Dokumentationsprojekt wird.

Der schnellste Einstieg führt über den Betroffenheitscheck und danach über die CRA-Fristen. Hersteller sollten anschließend direkt mit den Herstellerpflichten und den Meldepflichten weiterarbeiten.