Cyber Resilience Act 2026: Wer ist betroffen und welche Fristen gelten?
Kurzantwort
Der Cyber Resilience Act gilt grundsätzlich für Produkte mit digitalen Elementen, die in der EU auf dem Markt bereitgestellt werden, von der vernetzten Maschine bis zur eigenständig vertriebenen Software. In die Pflicht genommen werden Hersteller, Importeure und Händler. Die Verordnung ist seit dem 10. Dezember 2024 in Kraft, die Pflichten greifen gestaffelt: Ab dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden, ab dem 11. Dezember 2027 gelten die übrigen Anforderungen.
Aktueller Stand und Fristen
Die Verordnung (EU) 2024/2847[1] ist bereits geltendes Recht. Gestaffelt ist die Anwendbarkeit der einzelnen Pflichten.
| Datum | Was anwendbar wird | Status |
|---|---|---|
| 10. Dezember 2024 | Verordnung in Kraft getreten | erledigt |
| 11. Juni 2026 | Regelungen zur Benennung von Konformitätsbewertungsstellen | anwendbar |
| 11. September 2026 | Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle | steht unmittelbar bevor |
| 11. Dezember 2027 | übrige Anforderungen für neu in Verkehr gebrachte Produkte | Vorbereitungszeit |
Die Meldepflichten kommen zuerst. Wer bis dahin keine benannte Kontaktstelle und keinen festgelegten Ablauf hat, wird die 24-Stunden-Frist im Ernstfall kaum halten können.
Wer ist betroffen?
Die Verordnung nimmt drei Rollen in die Pflicht.
| Rolle | Was die Verordnung vorsieht |
|---|---|
| Hersteller | Sicherheitsanforderungen umsetzen, Konformität bewerten, technische Dokumentation führen, Schwachstellen über den Unterstützungszeitraum behandeln, Meldungen absetzen |
| Importeur | vor der Bereitstellung prüfen, ob Konformitätsbewertung, Kennzeichnung und Unterlagen vorliegen |
| Händler | prüfen, ob Kennzeichnung und Herstellerangaben vorhanden sind, und bei Anhaltspunkten für Mängel handeln |
Der Punkt, der im Mittelstand am häufigsten übersehen wird: Wer eine Maschine mit eigener Steuerungssoftware, ein Gerät mit Netzanbindung oder eine Softwarelösung in Verkehr bringt, ist regelmäßig Hersteller im Sinne der Verordnung. Das gilt auch dann, wenn sich das Unternehmen selbst als Maschinenbauer versteht und die Software als Beiwerk betrachtet.
Anwendungsbereich: welche Produkte erfasst sind
Erfasst sind grundsätzlich Produkte mit digitalen Elementen, also Hardware und Software, die eine Datenverbindung zu einem Gerät oder Netz herstellen können und in der EU auf dem Markt bereitgestellt werden[2]. Dazu zählen vernetzte Geräte ebenso wie eigenständig vertriebene Software, etwa Buchhaltungsprogramme oder mobile Anwendungen.
Ausgenommen sind unter anderem Bereiche, die bereits durch gleichwertige sektorspezifische Regelungen abgedeckt sind, darunter Medizinprodukte, Fahrzeuge und Luftfahrtausrüstung.
Sonderfall quelloffene Software
Maßgeblich ist, ob die Software im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Quelloffene Software außerhalb einer solchen Tätigkeit fällt nicht in den Anwendungsbereich; nach den Auslegungshinweisen der Kommission machen freiwillige Beiträge, öffentliche Förderung oder Sponsoring eine Bereitstellung für sich genommen noch nicht kommerziell. Wer quelloffene Software verkauft, kostenpflichtige Unternehmensversionen anbietet oder sie anderweitig monetarisiert, wird regelmäßig als Hersteller behandelt.
Daneben kennt Artikel 24 die Rolle des Verwalters quelloffener Software, also einer Einrichtung, die die Entwicklung solcher Software dauerhaft unterstützt. Für sie sieht die Verordnung deutlich geringere Pflichten vor, im Kern eine Cybersicherheitsstrategie, aber keine CE-Kennzeichnung und keine förmliche Konformitätsbewertung. Wird quelloffene Software Bestandteil eines Produkts, das ein Unternehmen in Verkehr bringt, richtet sich die Verantwortung für dieses Produkt nach den Herstellerpflichten.
Produktklassen und Anhang III
Der Nachweisaufwand hängt an der Einstufung des Produkts. Die Verordnung unterscheidet vier Gruppen.
| Gruppe | Beispiele | Konformitätsbewertung |
|---|---|---|
| Sonstige Produkte mit digitalen Elementen | der größte Teil aller erfassten Produkte | Selbstbewertung durch den Hersteller |
| Wichtige Produkte, Klasse I (Anhang III) | Passwortmanager, Netzwerkverwaltung, Virenschutz, VPN | Selbstbewertung bei vollständiger Anwendung einer harmonisierten Norm, sonst benannte Stelle |
| Wichtige Produkte, Klasse II (Anhang III) | Firewalls, Systeme zur Angriffserkennung | benannte Stelle oder Zertifizierung vorgesehen |
| Kritische Produkte (Anhang IV) | Smartcards, Smart-Meter-Gateways | Zertifizierung nach europäischem Schema vorgesehen |
In der Praxis fällt ein Großteil der Produkte im Mittelstand in die erste Zeile und kommt mit einer dokumentierten Selbstbewertung aus. Aufwendiger wird es, sobald ein Produkt selbst eine Sicherheitsfunktion übernimmt. Ein früher Blick in Anhang III lohnt deshalb, weil die Einstufung über Zeitplan und Budget entscheidet.
Was Hersteller jetzt vorbereiten können
Der Begriff der CRA-konformen Softwareentwicklung klingt größer, als er ist. Auf die Entwicklungspraxis heruntergebrochen geht es um vier Themen.
Sichere Voreinstellungen
Das Produkt wird in einem sicheren Zustand ausgeliefert: keine Standardpasswörter, keine unnötig offenen Dienste, Verschlüsselung dort, wo Daten übertragen werden. Wer die Absicherung dem Kunden überlässt, erfüllt die Anforderung nicht.
Bekannte Bestandteile
Eine Stückliste der verwendeten Komponenten samt Versionen. Ohne diese Liste lässt sich bei einer neu bekannt gewordenen Schwachstelle die eigene Betroffenheit nicht beantworten. Genau diese Frage stellt im Ernstfall der Kunde, und zwar am selben Tag.
Ein Prozess für Schwachstellen
Eine erreichbare Kontaktstelle für Meldungen, ein Verfahren zur Bewertung, ein Weg, Updates auszuliefern, und eine Aufzeichnung darüber, was wann behoben wurde. Der Unterstützungszeitraum ist festzulegen und für Käufer erkennbar zu machen.
Nachweisbare Dokumentation
Risikobewertung, Testergebnisse, Konformitätserklärung. Ohne Unterlagen ist die Bewertung nicht belegbar, auch wenn die Technik in Ordnung ist. Erfahrungsgemäß dauert dieser Teil länger als erwartet.
Die Meldepflichten ab September 2026
Meldungen erfolgen ab dem 11. September 2026 über die CRA Single Reporting Platform an das zuständige CSIRT[2].
| Zeitpunkt | Was vorgesehen ist |
|---|---|
| 24 Stunden | Frühwarnung nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls |
| 72 Stunden | weitere Angaben, soweit verfügbar |
| 14 Tage | Abschlussbericht zur Schwachstelle, gerechnet ab Bereitstellung eines Updates |
| 1 Monat | Abschlussbericht zu einem Sicherheitsvorfall |
Die Fristen ähneln denen aus NIS2, richten sich aber an einen anderen Adressaten: NIS2 nimmt den Betreiber in die Pflicht, der CRA den Hersteller. Ein Unternehmen kann beides zugleich sein.
Welche Rolle der Betriebsort beim CRA spielt
Der CRA ist Produktrecht. Maßgeblich ist, was ein Unternehmen in Verkehr bringt, nicht, wo seine Systeme stehen. Ein lokal betriebenes KI-System macht aus einem nicht konformen Produkt daher kein konformes.
Einen Unterschied macht der Betriebsort bei den Nachweisen. Liegen Entwicklung, Test und Auslieferung in der eigenen Hand, lassen sich Komponentenstände, Konfigurationen und Testergebnisse ohne Umweg belegen. Hängt ein Teil der Verarbeitung an einem externen Dienst, ist dessen Beitrag in die eigene Dokumentation aufzunehmen, ohne ihn selbst kontrollieren zu können.
| Anforderung | Wirkung des lokalen Betriebs |
|---|---|
| Nachweis der ausgelieferten Komponentenstände | leichter, wenn alle Stände im eigenen Haus geführt werden |
| Reproduzierbare Tests vor der Auslieferung | leichter, wenn keine Abhängigkeit von fremden Modellständen besteht |
| Einhaltung der 24-Stunden-Frist | teilweise, die benötigten Informationen können schneller verfügbar sein |
| Einstufung nach Anhang III | keine Änderung, richtet sich nach dem Produkt |
| Konformitätsbewertung und technische Dokumentation | keine Änderung, bleibt eigene Aufgabe |
| Unterstützungszeitraum und Update-Auslieferung | keine Änderung, vertragliche und organisatorische Zusage |
conn.AI als Lieferant im CRA-Kontext
Der CRA betrifft uns selbst. Wer einen Edge-Server mit Software ausliefert, steht vor denselben Fragen wie jeder andere Hersteller: bekannte Bestandteile, sichere Voreinstellungen, ein Verfahren für Schwachstellen, ein festgelegter Unterstützungszeitraum. Dokumentierter Betrieb und geplante Updates sind bei conn.AI deshalb Teil des Leistungsumfangs.
Für die von conn.AI bereitgestellten Komponenten dokumentieren wir unter anderem Softwarestände, Updateprozesse und relevante Betriebsinformationen. Diese Unterlagen können in die eigene technische Dokumentation und Bewertung des Kunden einfließen. Die Einstufung und Konformitätsbewertung des Produkts, das ein Kunde selbst in Verkehr bringt, bleibt davon unberührt.
Häufige Fragen
Wer ist vom Cyber Resilience Act betroffen?
Die Verordnung nimmt Hersteller, Importeure und Händler von Produkten mit digitalen Elementen in die Pflicht, die in der EU auf dem Markt bereitgestellt werden. Der größte Teil der Anforderungen richtet sich an Hersteller: Sie haben die Sicherheitsanforderungen umzusetzen, die Konformität zu bewerten, die technische Dokumentation zu führen und Schwachstellen über den Unterstützungszeitraum zu behandeln. Importeure und Händler haben zu prüfen, ob die erforderlichen Nachweise und Kennzeichnungen vorliegen. Für den Mittelstand ist vor allem eines relevant: Wer eine Maschine mit eigener Steuerungssoftware oder ein Gerät mit Netzanbindung in Verkehr bringt, ist regelmäßig Hersteller im Sinne der Verordnung, auch wenn sich das Unternehmen nicht als Softwarehersteller versteht.
Ab wann gilt der Cyber Resilience Act?
Die Verordnung ist am 10. Dezember 2024 in Kraft getreten, die Pflichten greifen gestaffelt. Seit dem 11. Juni 2026 gelten die Regelungen zur Benennung von Konformitätsbewertungsstellen. Ab dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden. Ab dem 11. Dezember 2027 gelten die übrigen Anforderungen für Produkte, die neu in Verkehr gebracht werden.
Was ist ein wichtiges Produkt nach Anhang III?
Anhang III führt Produktkategorien mit erhöhtem Risiko auf, unterteilt in Klasse I und Klasse II. Zu Klasse I zählen unter anderem Passwortmanager, Netzwerkverwaltung, Virenschutz und VPN-Software. Klasse II umfasst Kategorien mit höherem Risiko, etwa Firewalls und Systeme zur Angriffserkennung. Der Unterschied liegt im Nachweisweg: Für Klasse I sieht die Verordnung eine Selbstbewertung vor, wenn eine harmonisierte Norm vollständig angewendet wird, andernfalls ist eine benannte Stelle einzubeziehen. Für Klasse II ist die Beteiligung einer benannten Stelle oder eine Zertifizierung vorgesehen.
Gilt der CRA auch für reine Software?
Ja. Der Anwendungsbereich umfasst Produkte mit digitalen Elementen, und dazu zählt eigenständig vertriebene Software ebenso wie Hardware mit Software darin. Buchhaltungsprogramme, mobile Anwendungen und Spiele fallen darunter. Maßgeblich ist, dass das Produkt eine Datenverbindung zu einem Gerät oder Netz herstellen kann und in der EU auf dem Markt bereitgestellt wird.
Fällt Open Source unter den Cyber Resilience Act?
Maßgeblich ist, ob die Software im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird. Quelloffene Software, die außerhalb einer solchen Tätigkeit bereitgestellt wird, fällt nicht in den Anwendungsbereich; nach den Auslegungshinweisen der Kommission machen freiwillige Beiträge, öffentliche Förderung oder Sponsoring eine Bereitstellung für sich genommen noch nicht kommerziell. Wer quelloffene Software verkauft, kostenpflichtige Unternehmensversionen anbietet oder sie anderweitig monetarisiert, wird regelmäßig als Hersteller behandelt. Artikel 24 schafft daneben die Rolle des Verwalters quelloffener Software mit deutlich geringeren Pflichten. Wird quelloffene Software Bestandteil eines Produkts, das ein Unternehmen in Verkehr bringt, richtet sich die Verantwortung für dieses Produkt nach den Herstellerpflichten.
Was bedeutet CRA-konforme Softwareentwicklung?
Im Kern vier Themen. Erstens sichere Voreinstellungen, also keine Standardpasswörter und keine unnötig offenen Dienste im Auslieferungszustand. Zweitens eine Stückliste der verwendeten Komponenten, damit sich bei einer neu bekannt gewordenen Schwachstelle die eigene Betroffenheit beantworten lässt. Drittens ein Prozess, der Schwachstellen aufnimmt, bewertet und Updates ausliefert, mitsamt einer erreichbaren Kontaktstelle für Meldungen. Viertens die Dokumentation dieser Punkte, weil die Konformitätsbewertung sonst nicht belegbar ist. Technisch ist davon wenig neu, organisatorisch für viele Unternehmen schon.
Was ist ab dem 11. September 2026 zu melden?
Aktiv ausgenutzte Schwachstellen in einem Produkt und schwerwiegende Sicherheitsvorfälle, die dessen Sicherheit beeinträchtigen. Die Meldungen erfolgen über die CRA Single Reporting Platform an das zuständige CSIRT. Die Verordnung sieht eine Frühwarnung binnen 24 Stunden vor, nach 72 Stunden weitere Angaben. Der Abschlussbericht ist bei Schwachstellen binnen 14 Tagen nach Bereitstellung eines Updates vorgesehen, bei Sicherheitsvorfällen binnen eines Monats. Diese Pflicht greift, bevor die übrigen Anforderungen im Dezember 2027 anwendbar werden.
Wie lange sind Sicherheitsupdates bereitzustellen?
Über den Unterstützungszeitraum, den der Hersteller festlegt und angibt. Er richtet sich nach der erwarteten Lebensdauer des Produkts und beträgt nach der Verordnung grundsätzlich mindestens fünf Jahre, sofern die erwartete Lebensdauer nicht kürzer ist. Der Zeitraum muss für Käufer erkennbar sein. Bei Investitionsgütern mit zehn oder fünfzehn Jahren Nutzungsdauer wird das zu einer Frage der Kalkulation.
Quellen und Verweise
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), Volltext auf EUR-Lex: eur-lex.europa.eu/eli/reg/2024/2847/oj
- Bundesamt für Sicherheit in der Informationstechnik (BSI), Themenseite Cyber Resilience Act: bsi.bund.de · Cyber Resilience Act
- Europäische Kommission, Informationsseite zum Cyber Resilience Act: digital-strategy.ec.europa.eu · Cyber Resilience Act
- ENISA, European Union Agency for Cybersecurity: enisa.europa.eu
Zuletzt aktualisiert: 18. August 2026. Rechtsstand geprüft an Verordnung (EU) 2024/2847 und den Veröffentlichungen des BSI. Dieser Text ist eine allgemeine Einordnung und dient der Information. Er ersetzt keine Rechtsberatung. Ob und welche Pflichten im Einzelfall gelten, hängt von der konkreten Situation ab.