Die CRA-Fristen sind gestaffelt: Ab September 2026 gilt die Meldepflicht für Schwachstellen, ab Dezember 2027 die vollständige Anwendung — parallel zu NIS2 und AI Act Fristen. Für Hersteller, Importeure und produktnahe Softwareanbieter ist deshalb nicht die Frage, ob der Cyber Resilience Act relevant wird, sondern welche Pflichten bis zum 11. September 2026 und welche erst bis zum 11. Dezember 2027 umgesetzt sein müssen.
Dieser Beitrag ordnet die Stichtage des Cyber Resilience Act nach der Verordnung (EU) 2024/2847 ein, erklärt die Übergangsfristen für bestehende Produkte und zeigt, wie Sie den CRA mit Cyber Resilience Act Grundlagen, den CRA Anforderungen, dem Vergleich CRA vs. NIS2 und den KI-Schulungsfristen 2026 zusammendenken. Wenn Sie die Management-Perspektive auf Governance-Systeme ergänzen wollen, lohnt sich außerdem der Blick auf den NIS2-Hub und den ISO-42001-Hub.
Timeline des Cyber Resilience Act (EU-VO 2024/2847)
Die Timeline des CRA lässt sich auf drei Daten verdichten: 10. Dezember 2024, 11. September 2026 und 11. Dezember 2027. Seit dem 10. Dezember 2024 ist die Verordnung formal in Kraft. Praktisch spürbar wird sie aber erst in zwei Stufen: zunächst mit den Meldepflichten ab September 2026, dann mit der vollen Anwendbarkeit sämtlicher Produkt- und Prozesspflichten ab Dezember 2027.
Für Unternehmen ist diese Staffelung wichtig, weil sie die Priorisierung vorgibt. Bis September 2026 muss vor allem das Incident- und Vulnerability-Reporting belastbar funktionieren. Bis Dezember 2027 müssen zusätzlich die breiteren Anforderungen an Security by Design, technische Dokumentation, Schwachstellenmanagement, Support-Zeiträume, Konformitätsbewertung und Marktbereitstellung stehen.
| Datum | CRA-Meilenstein | Praktische Bedeutung |
|---|---|---|
| 10. Dezember 2024 | Inkrafttreten der EU-VO 2024/2847 | Der Rechtsrahmen ist verbindlich, Unternehmen beginnen mit Scope-, Produkt- und Gap-Analysen. |
| 11. September 2026 | Meldepflichten starten | Aktiv ausgenutzte Schwachstellen und schwere Vorfälle müssen fristgerecht gemeldet werden. |
| 11. Dezember 2027 | Vollständige Anwendung | Alle übrigen CRA-Pflichten gelten für betroffene Produkte mit digitalen Elementen vollumfänglich. |
Die wichtigste Konsequenz daraus lautet: 2026 ist kein Wartemodus, sondern die operative Vorbereitungsphase. Wer Reporting-Prozesse, Verantwortlichkeiten und technische Nachweise erst Ende 2027 aufbaut, verpasst die erste relevante Stufe bereits mehr als ein Jahr früher.
September 2026 — Meldepflicht für aktiv ausgenutzte Schwachstellen
Ab dem 11. September 2026 müssen Hersteller nach dem CRA bestimmte Sicherheitsereignisse melden. Besonders relevant sind aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle bei Produkten mit digitalen Elementen. Damit zieht die Verordnung den Meldeprozess zeitlich vor die vollständige Anwendung des restlichen Pflichtenpakets.
Für die Praxis bedeutet das: Sie brauchen spätestens bis September 2026 einen belastbaren Prozess, um Sicherheitsmeldungen intern zu erkennen, zu bewerten, zu eskalieren und fristgerecht an die zuständigen Stellen weiterzugeben. Reine Produktentwicklung genügt dann nicht mehr. Notwendig sind auch klare Zuständigkeiten zwischen Product Security, Incident Response, Legal, Compliance, Support und gegebenenfalls externen CERT- oder PSIRT-Strukturen.
Gerade mittelständische Hersteller unterschätzen diesen Punkt häufig. Viele Teams haben zwar bereits Ticketing, Patching oder CVE-Beobachtung, aber keinen formalisierten CRA-Meldeweg. Der CRA verlangt jedoch keinen unverbindlichen Best-Effort-Prozess, sondern eine belastbare Meldefähigkeit. Ohne definierte Trigger, Freigabewege, Kontaktpunkte und Evidenzdokumentation wird aus einer technischen Schwachstelle schnell ein Governance-Problem.
Bis September 2026 sollten deshalb mindestens fünf Bausteine stehen:
- Ein zentrales Register aller betroffenen Produkte mit digitalen Elementen.
- Ein Verfahren zur Erkennung aktiv ausgenutzter Schwachstellen, etwa über interne Telemetrie, Bug-Bounty-Kanäle, CERT-Meldungen oder Lieferantenhinweise.
- Ein klarer Bewertungsprozess für die Frage, ob ein Fall meldepflichtig ist.
- Eine dokumentierte Eskalationskette mit Verantwortlichen und Vertretungen.
- Vorlagen für Erstmeldung, Nachmeldung und Kundenkommunikation.
Besonders wichtig ist die Abgrenzung: Der CRA macht aus September 2026 keine vollständige Produktkonformitätsfrist. Unternehmen müssen also nicht bis zu diesem Datum bereits das gesamte Konformitätsregime umgesetzt haben. Sie müssen aber meldereif sein. Genau darin liegt der Unterschied zwischen der ersten und der zweiten Stufe.
Dezember 2027 — Vollständige Anwendung aller Pflichten
Ab dem 11. Dezember 2027 gilt der Cyber Resilience Act vollständig. Dann reicht ein Reporting-Prozess allein nicht mehr aus. Hersteller müssen sämtliche einschlägigen Pflichten für Produkte mit digitalen Elementen umsetzen, bevor neue Produkte auf dem EU-Markt bereitgestellt oder in Verkehr gebracht werden.
Im Kern geht es ab diesem Datum um fünf große Pflichtengruppen:
- Security by Design und Security by Default. Sicherheitsanforderungen müssen bereits in Konzeption, Entwicklung, Test und Release berücksichtigt werden.
- Technische Dokumentation und Risikoanalyse. Produkte brauchen nachvollziehbare Unterlagen zu Bedrohungen, Schutzmaßnahmen, Grenzen und Konformität.
- Schwachstellenmanagement über den gesamten Lebenszyklus. Schwachstellen müssen beobachtet, priorisiert, behoben und dokumentiert werden.
- Support- und Update-Logik. Sicherheitsupdates, Supportdauer und End-of-Life-Kommunikation müssen sauber geregelt sein.
- Konformitätsbewertung und Marktbereitstellung. Je nach Produktkategorie sind interne oder formalisierte Bewertungsverfahren, Erklärungen und Kennzeichnungen erforderlich.
Für viele Unternehmen ist Dezember 2027 deshalb die eigentliche Produktdeadline. Ab diesem Stichtag wird aus einem Vorbereitungsprojekt ein Marktzugangsthema. Wer danach ein nicht konformes Produkt neu in Verkehr bringt, riskiert nicht nur Nachfragen der Marktüberwachung, sondern auch Vertriebsstopps, Rücknahmen oder Bußgelder.
Wichtig ist auch die Organisationsperspektive: Die vollständige CRA-Anwendung betrifft nicht nur Security-Teams. Einkauf muss Lieferantenanforderungen vertraglich absichern, Produktmanagement muss Supportzusagen sauber definieren, Entwicklung braucht sichere Standards für Build- und Release-Prozesse, und Rechts- bzw. Compliance-Funktionen müssen die Dokumentation auditierbar halten. Der CRA ist damit kein reines Engineering-Thema, sondern ein Produkt-Compliance-Regime.
Übergangsfristen für bestehende Produkte
Für bestehende Produkte ist die Übergangsfrage entscheidend: Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, werden nicht allein durch den Kalender rückwirkend zu „neuen“ CRA-Produkten. Praktisch relevant ist aber, ob nach dem Stichtag neue Produktversionen, wesentliche Änderungen oder weitere Marktbereitstellungen erfolgen, die eine neue CRA-Prüfung auslösen können.
Die operative Faustregel lautet deshalb: Bestandsprodukte verschaffen Zeit, aber keine dauerhafte Entwarnung. Wer ein Produktportfolio mit langer Lebensdauer hat, sollte nicht nur auf Neuprodukte schauen, sondern ein Migrationsmodell für bestehende Linien aufsetzen. Dazu gehört die Frage, welche Produkte noch vor Dezember 2027 abverkauft werden, welche danach weiterentwickelt werden und welche aus Support- oder Sicherheitsgründen ohnehin neu bewertet werden müssen.
Für KMU ist das besonders wichtig. Kleine Hersteller neigen dazu, ein Gerät oder eine Softwarelinie über Jahre inkrementell weiterzuführen. Gerade diese Kontinuität kann regulatorisch heikel werden, wenn technische Änderungen, neue Konnektivität, neue Cloud-Anbindung oder sicherheitsrelevante Architekturwechsel hinzukommen. Die Übergangsfrist ist daher kein Freibrief, sondern ein Zeitfenster für Portfolio-Bereinigung und dokumentierte Entscheidungen.
Sinnvoll ist eine Dreiteilung des Bestands:
- Produkte, die vor Dezember 2027 auslaufen und nur noch kontrolliert supportet werden.
- Produkte, die nach Dezember 2027 weiter vertrieben werden und deshalb frühzeitig CRA-konform umgestellt werden müssen.
- Produkte, bei denen unklar ist, ob Änderungen wesentlich sind und die deshalb juristisch-technisch gesondert bewertet werden sollten.
Wer diese Segmentierung 2026 oder 2027 nicht macht, bekommt im Herbst 2027 regelmäßig ein Ressourcenproblem: zu viele Produkte, zu wenig Dokumentation, unklare Verantwortlichkeiten und hektische Priorisierung kurz vor dem Stichtag.
Zusätzlich empfiehlt sich eine einfache Portfolio-Matrix mit den Achsen Marktrelevanz und CRA-Aufwand. Hochrelevante Produkte mit hoher Marge oder strategischer Kundenbindung sollten zuerst in die CRA-Umstellung gehen. Niedrigrelevante Produkte mit hohem Nachrüstaufwand gehören dagegen früh auf den Prüfstand, ob sie überhaupt noch wirtschaftlich weitergeführt werden sollen. Genau diese Entscheidung spart 2027 oft mehr Budget als jede späte Prozessoptimierung.
Wechselwirkung mit NIS2 und AI Act Fristen
CRA, NIS2 und AI Act greifen auf unterschiedlichen Ebenen, überschneiden sich aber in den Abläufen. NIS2 adressiert die Cybersicherheits-Governance von Organisationen, der CRA die Sicherheit von Produkten mit digitalen Elementen und der AI Act die Regeln für KI-Systeme und deren Einsatz. Unternehmen mit vernetzten Produkten und KI-Funktionen müssen diese Zeitachsen deshalb gemeinsam lesen.
Der europäische Vergleich sieht chronologisch so aus:
| Datum | CRA | NIS2 | AI Act |
|---|---|---|---|
| 17. Oktober 2024 | Noch keine operative Anwendung | Frist für die Umsetzung der NIS2-Richtlinie in den Mitgliedstaaten | Noch nicht anwendbar |
| 10. Dezember 2024 | CRA tritt in Kraft | NIS2-Umsetzung und Aufsicht bauen sich national auf | Vorbereitungsphase |
| 2. Februar 2025 | Vorbereitungsphase | NIS2-Pflichten laufen national an | Allgemeine Vorschriften und Verbote gelten; Art. 4 zur KI-Kompetenz ist anwendbar |
| 2. August 2026 | Vorbereitungsphase kurz vor Meldepflicht | Laufende Governance- und Sicherheitsanforderungen | Breite Anwendung zentraler AI-Act-Pflichten für Hochrisiko-Bereiche |
| 11. September 2026 | CRA-Meldepflichten starten | Melde- und Governance-Prozesse bleiben parallel relevant | AI-Act-Pflichten laufen parallel weiter |
| 11. Dezember 2027 | CRA vollständig anwendbar | NIS2 dauerhaft im Betriebsregime | Letzte große AI-Act-Stufe für bestimmte Produktsicherheitsfälle nähert sich bzw. gilt |
Die Wechselwirkung ist vor allem operativ relevant. Ein Unternehmen kann unter NIS2 seine organisatorische Cybersicherheit stärken, unter dem CRA aber trotzdem produktbezogene Lücken haben. Ebenso kann ein Unternehmen AI-Act-Schulungen sauber dokumentieren und trotzdem CRA-relevante Produktpflichten verfehlen. Die bessere Strategie ist ein gemeinsames Programm mit getrennten Pflichtmappen: Governance unter NIS2, Produktkonformität unter dem CRA und KI-spezifische Pflichten unter dem AI Act.
Wenn Sie die Abgrenzung vertiefen wollen, sind der Beitrag CRA vs. NIS2, die Seite Cyber Resilience Act Grundlagen und unser Überblick zu den KI-Schulungsfristen 2026 die sinnvollsten Anschlussartikel.
Fristen-Checkliste — Was bis wann erledigt sein muss
Die richtige CRA-Checkliste trennt zwischen bis September 2026 und bis Dezember 2027. Wer beide Stufen vermischt, setzt oft die falschen Prioritäten.
Bis 11. September 2026
- Scope festlegen: Welche Produkte mit digitalen Elementen fallen überhaupt unter den CRA?
- Produktregister aufbauen: Versionen, Verantwortliche, Supportstatus, Lieferketten und Kontaktstellen dokumentieren.
- PSIRT- oder Incident-Response-Prozess definieren: Wer bewertet Schwachstellen und Vorfälle?
- Meldekriterien schriftlich festlegen: Was gilt als aktiv ausgenutzte Schwachstelle, was als schwerer Vorfall?
- Meldewege testen: Templates, Freigaben, Zuständigkeiten und Erreichbarkeit der Ansprechpartner prüfen.
- Lieferanten einbinden: Sicherheitsmeldungen aus Komponenten, Bibliotheken und OEM-Beziehungen vertraglich absichern.
- Kommunikationsbausteine vorbereiten: Kundeninformation, interne Eskalation, Nachmeldungen und Dokumentationspflichten.
Bis 11. Dezember 2027
- Security-by-Design-Anforderungen in Entwicklung und Produktfreigabe verankern.
- Technische Dokumentation, Risikoanalyse und Produktunterlagen vervollständigen.
- Schwachstellenmanagement über den Lebenszyklus organisieren, inklusive Updates und End-of-Life-Regeln.
- Konformitätsbewertung für betroffene Produktkategorien planen und durchführen.
- Supportdauer, Patchprozesse und Nutzerinformationen transparent festlegen.
- Bestandsprodukte klassifizieren: auslaufend, umzustellen oder gesondert zu prüfen.
- Management, Product Security, Entwicklung, QA, Einkauf und Recht auf gemeinsame CRA-Verantwortung ausrichten.
Der Nutzen dieser Zweiteilung ist praktisch sofort sichtbar: September 2026 wird zum Reporting-Meilenstein, Dezember 2027 zum Produkt- und Marktzugangsmeilenstein. Das reduziert Aktionismus und macht Budgets planbar.
Häufig gestellte Fragen (FAQ)
Ab wann gilt der CRA?
Der CRA gilt formal seit dem 10. Dezember 2024, weil die Verordnung (EU) 2024/2847 an diesem Tag in Kraft getreten ist. Für die operative Umsetzung sind aber zwei spätere Stichtage wichtiger: 11. September 2026 für die Meldepflichten und 11. Dezember 2027 für die vollständige Anwendung aller übrigen Pflichten.
Was passiert bei Fristversäumnis?
Bei Fristversäumnis drohen nicht nur Geldbußen, sondern auch Marktmaßnahmen. Je nach Verstoß können Behörden Nachbesserungen verlangen, Produkte vom Markt nehmen, Bereitstellungen untersagen oder zusätzliche Informationspflichten anordnen. Besonders kritisch ist ein fehlender Meldeprozess ab September 2026 oder ein nicht konformes Inverkehrbringen neuer Produkte ab Dezember 2027.
Gelten die Fristen auch für KMU?
Ja. Die CRA-Fristen gelten grundsätzlich auch für kleine und mittlere Unternehmen. Es gibt keine generelle KMU-Ausnahme vom 11. September 2026 oder 11. Dezember 2027. Wer als Hersteller, Importeur oder in einer vergleichbaren Rolle Produkte mit digitalen Elementen auf dem EU-Markt bereitstellt, muss die Stichtage einhalten.
Wie hängen CRA- und NIS2-Fristen zusammen?
CRA und NIS2 regeln unterschiedliche Dinge. NIS2 fokussiert auf Organisationen, Vorfallsteuerung und Governance in betroffenen Sektoren. Der CRA fokussiert auf Produkte mit digitalen Elementen. Zeitlich liegt NIS2 mit der Umsetzungsfrist vom 17. Oktober 2024 früher, während der CRA mit 11. September 2026 und 11. Dezember 2027 in zwei Stufen greift. Unternehmen mit vernetzten Produkten brauchen deshalb meist beide Perspektiven.
Gibt es Ausnahmen von den CRA-Fristen?
Von den Grundstichtagen gibt es keine allgemeine Befreiung für KMU oder Standardprodukte. Ausnahmen und Sonderlogiken betreffen eher den sachlichen Anwendungsbereich, etwa bestimmte ausgeschlossene Produktgruppen oder besondere Konstellationen bei frei und offen geteiltem Open-Source-Code. Für kommerziell bereitgestellte Produkte sollte aber grundsätzlich mit voller CRA-Relevanz gerechnet werden, bis eine belastbare Gegenprüfung etwas anderes ergibt.
Was jetzt sinnvoll ist
Die beste CRA-Vorbereitung beginnt nicht 2027, sondern mit einem sauberen Fahrplan im Jahr 2026. Unternehmen sollten jetzt Reporting-Fähigkeit für September 2026 aufbauen, parallel die vollständige Produkt-Compliance für Dezember 2027 planen und die Überschneidungen mit CRA Anforderungen, CRA vs. NIS2 und den AI-Act-Fristen 2026 in einem gemeinsamen Programm steuern.
Wenn Sie neben den technischen und regulatorischen Fristen auch die Schulungsseite sauber abbilden wollen, ist unsere EU AI Act Schulung der pragmatische Einstieg für Management, Compliance und Fachbereiche. So schaffen Sie parallel zu CRA- und NIS2-Projekten einen dokumentierten Mindeststandard für KI-Kompetenz, Rollenverständnis und Nachweisfähigkeit im Unternehmen.