NIS-2 soll Unternehmen sicherer machen, der Cyber Resilience Act (CRA) ihre Produkte. Seit 2024 gibt es erstmals EU-weite Cybersicherheitsregeln für alles mit digitalen Elementen, von der App bis zum vernetzten Gerät. Sicherheit wird zur Produkteigenschaft wie bisher Produktsicherheit oder Brandschutz. Betroffen sind nicht nur Gerätehersteller: Software- und App-Anbieter sowie Cloud-Funktionen sind schnell dabei. Und die ersten Pflichten gelten bereits.
Das Wichtigste in Kürze
- Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden – Frühwarnung binnen 24 Stunden.
- Ab dem 11. Dezember 2027 gilt der CRA vollständig: Security by Design, Schwachstellenmanagement, Konformitätsbewertung, CE-Kennzeichnung.
- Software zählt als Produkt. Installierbare Software und Apps sind erfasst – ebenso Cloud-Backends, ohne die das Produkt nicht funktioniert.
- Reines SaaS ist grundsätzlich nicht erfasst. Aber: Desktop-Client, Mobile App, Browser-Extension oder Agent beim Kunden – und schon ist man wieder im Spiel.
- Der Hersteller haftet für das ganze Produkt, auch für zugekaufte und Open-Source-Komponenten. Wer Updates zusagen muss, muss sie auch einkaufen.
- Bußgelder bis 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes.
Zeitplan: Was gilt seit wann?
Der CRA (Verordnung (EU) 2024/2847) ist seit Dezember 2024 in Kraft und wird gestaffelt anwendbar.
| Datum | Was passiert | Bedeutung für Sie |
|---|---|---|
| 10.12.2024 | CRA tritt in Kraft | Übergangsfrist läuft |
| 11.06.2026 | Regeln zu Prüfstellen (notifizierte Stellen) gelten | Relevant, wenn Ihr Produkt eine Drittprüfung braucht |
| 27.07.2026 | Leitlinien der EU-Kommission veröffentlicht | Klärt u. a. Cloud-Backends, Support-Zeitraum, Meldeauslöser |
| 11.09.2026 | Meldepflichten gelten (Art. 14 CRA) | Gilt jetzt – auch für Produkte, die schon auf dem Markt sind |
| 11.12.2027 | CRA gilt vollständig | Nur noch konforme Produkte mit CE-Kennzeichen in Verkehr bringen |
Praxishinweis: Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden, müssen die Produktanforderungen erst erfüllen, wenn sie danach wesentlich geändert werden. Die Meldepflichten gelten dagegen schon heute für den gesamten Bestand. Bei Software mit regelmäßigen Releases kommt die „wesentliche Änderung“ schneller, als man denkt – etwa durch neue Funktionen mit neuen Angriffsflächen.
Betroffen? Software, Apps und Cloud im Check
Erfasst sind „Produkte mit digitalen Elementen“: Hard- und Software, die bestimmungsgemäß direkt oder indirekt mit einem Gerät oder Netz verbunden wird. Das ist fast jede Software. Spannend wird es bei der Cloud. Der CRA erfasst auch die „Datenfernverarbeitung“ (Remote Data Processing Solution, RDPS): Software, die der Hersteller selbst oder unter seiner Verantwortung entwickelt hat und ohne die das Produkt eine seiner Funktionen nicht erfüllen kann. Diese Cloud-Funktion wird Teil des Produkts – mit allen Pflichten.
| Konstellation | CRA? | Worauf es ankommt |
|---|---|---|
| Installierbare Software, Desktop- oder Mobile-App (B2B oder B2C) | Ja | Klassisches Produkt mit digitalen Elementen |
| App mit eigenem Backend, ohne das sie nicht funktioniert (Login, Sync, Steuerung) | Ja – inklusive Backend | Backend ist RDPS und Teil der Konformität |
| Vernetztes Gerät mit Hersteller-Cloud (Fernsteuerung, OTA-Updates) | Ja – inklusive Cloud-Funktion | Auch der Update-Server gehört dazu |
| Eigenes Backend läuft bei AWS, Azure & Co. | Ja | Wer die Infrastruktur betreibt, ist egal. Entscheidend ist, wer die Software verantwortet. |
| Anbindung an Drittdienste, die nicht unter Ihrer Verantwortung entwickelt werden (z. B. Zahlungs-API) | Kein RDPS | Aber: Abhängigkeit mit Sorgfaltspflicht (Due Diligence) |
| Nachgelagerte Systeme ohne direkte Interaktion mit dem Produkt (Analytics, BI, Data Warehouse) | Kein RDPS | So die Leitlinien der Kommission |
| Reines SaaS, nur im Browser genutzt | Grundsätzlich nein | Prüfen Sie NIS-2. Und: Gibt es Clients, Plug-ins, Agents oder Apps? Dann sind diese erfasst. |
| Kostenlose App oder Software | Möglich | Kostenlos heißt nicht automatisch nicht-kommerziell, etwa bei Monetarisierung über Daten oder Premium-Funktionen |
| Open-Source-Bibliothek im eigenen Produkt | Ja, über Ihr Produkt | Sie sind Hersteller des Gesamtprodukts und verantworten auch die Komponente |
| Rein interne Tools für den Eigengebrauch | Regelmäßig nein | Kein Bereitstellen auf dem Markt. Anders, sobald Dritte das Tool nutzen. |
Ausgenommen sind Bereiche mit eigenem Sektorrecht, etwa Medizinprodukte und Kraftfahrzeuge. Die genaue Abgrenzung ist oft Einzelfallarbeit. Dokumentieren Sie Ihr Ergebnis Produkt für Produkt und Funktion für Funktion – darauf baut alles Weitere auf.
Wer ist „Hersteller“? Wer ein Produkt entwickelt oder entwickeln lässt und unter eigenem Namen vermarktet. Auch wer ein fremdes Produkt unter eigener Marke vertreibt oder ein Produkt wesentlich ändert, kann zum Hersteller werden. Importeure und Händler haben eigene, geringere Pflichten.
Was Hersteller konkret tun müssen
Der CRA verlangt Sicherheit über den gesamten Lebenszyklus: vom Design über den Vertrieb bis zum Ende des Supports.
| Pflicht | Kurz erklärt | Praxis-Tipp |
|---|---|---|
| Risikobewertung | Cybersicherheitsrisiken des Produkts bewerten und aktuell halten | Je Produkt ein Dokument, bei jedem größeren Release prüfen |
| Security by Design & by Default | U. a. keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, sichere Standardkonfiguration, Zugriffsschutz, Verschlüsselung, Protokollierung, minimale Angriffsfläche | Gegen anerkannte Standards entwickeln (z. B. OWASP, IEC 62443, BSI TR-03183) |
| Schwachstellenmanagement | Schwachstellen unverzüglich beheben, regelmäßig testen, behobene Schwachstellen veröffentlichen | Prozess mit Rollen, Fristen nach Schweregrad und Nachweisen |
| SBOM | Stückliste der Softwarekomponenten, mindestens der obersten Ebene | Automatisiert in der Build-Pipeline erzeugen (SPDX, CycloneDX) |
| Sicherheitsupdates | Kostenlos, möglichst getrennt von Funktionsupdates, wo sinnvoll automatisch mit Opt-out | Update-Mechanik und -Kanäle früh festlegen |
| Support-Zeitraum | Mindestens 5 Jahre, außer die erwartete Nutzungsdauer ist kürzer. Enddatum beim Kauf angeben. | 5 Jahre sind eine Untergrenze, kein Standardwert. Kleine Bugfixes starten die Frist laut Kommission nicht neu. |
| Meldepflichten | Aktiv ausgenutzte Schwachstellen und schwere Vorfälle melden | Gilt schon jetzt – siehe unten |
| Technische Doku & Konformität | Dokumentation, Konformitätsbewertung, EU-Konformitätserklärung, CE-Kennzeichen | Bei „wichtigen“ oder „kritischen“ Produkten (z. B. Passwortmanager, VPN, Firewalls) ggf. Drittprüfung |
| Nutzerinformation | Kontaktstelle für Schwachstellen, Sicherheitshinweise, Support-Ende | In AGB, EULA, Produktseite und Doku verankern |
Unser Tipp für die Vertragsseite: Prüfen Sie Ihre Kunden-AGB und EULAs. Support-Zeitraum, Update-Pflichten und automatische Updates müssen zu dem passen, was der CRA verlangt – und zu dem, was Sie tatsächlich leisten können.
Lieferkette: Support und Updates einkaufen
Der CRA kennt keine Ausrede „Das war die Komponente des Lieferanten“. Der Hersteller muss bei der Integration fremder Komponenten – auch Open Source – die gebotene Sorgfalt walten lassen (Art. 13 Abs. 5 CRA). Schwachstellen muss er über den gesamten Support-Zeitraum beheben, auch in zugekauften Teilen. Wer selbst fünf Jahre Sicherheitsupdates zusagen muss, braucht also Lieferanten, die mindestens so lange liefern. Das ist eine Einkaufs- und Vertragsfrage.
| Regelungspunkt | Warum | Praxis-Empfehlung |
|---|---|---|
| Support- und Update-Laufzeit | Ihr Support-Zeitraum hängt an dem Ihrer Lieferanten | Mindestens Ihre Support-Dauer plus Puffer, ab Ende Ihres Vertriebs gerechnet |
| Patch-Fristen nach Schweregrad | „Unverzüglich beheben“ braucht messbare Zusagen | SLA z. B. kritisch: Workaround in 48 h, Patch in 7 Tagen (an Ihr Risiko anpassen) |
| Informationspflicht bei Schwachstellen und Vorfällen | Ihre 24-Stunden-Frist läuft ab Ihrer Kenntnis | Meldung an Sie deutlich unter 24 h, inkl. Angabe, ob aktiv ausgenutzt |
| SBOM und Komponenteninfos | Ohne SBOM kein Schwachstellen-Abgleich | Maschinenlesbare SBOM bei jedem Release |
| Mitwirkung bei Meldungen und Konformität | Sie brauchen Daten für 72-h-Meldung und Abschlussbericht | Auskunfts- und Mitwirkungspflicht, Testberichte, Doku |
| End-of-Life-Ankündigung | Abkündigungen ohne Vorlauf reißen Lücken in Ihren Support | Z. B. 24 Monate Vorlauf, Last-Buy- oder Migrationsoption |
| Plan B bei Ausfall des Lieferanten | Insolvenz oder Abkündigung entbinden Sie nicht | Quellcode-Hinterlegung (Escrow), Bearbeitungsrechte zur Selbsthilfe |
| Kosten über die Laufzeit | Sicherheitsupdates müssen für Kunden kostenlos sein | Wartungsentgelte für die gesamte Laufzeit fixieren oder deckeln |
| Nachweise und Audit | Sorgfalt muss belegbar sein | Zertifikate (z. B. ISO 27001), Pentest-Berichte, Auditrechte |
| Weitergabe in die Kette | Ihr Lieferant hat auch Lieferanten | Flow-down-Klausel an Subunternehmer |
| Haftung und Freistellung | Kosten für Patches, Rückrufe, Kundenmaßnahmen | Freistellung und angemessene Haftungsgrenzen. Der Regress von Bußgeldern ist rechtlich umstritten – darauf allein sollten Sie nicht setzen. |
Open Source: Hier gibt es meist keinen Vertragspartner. Sie brauchen daher einen internen Prozess: Auswahlkriterien (Pflegezustand, Community, Sicherheitshistorie), laufendes Monitoring und die Fähigkeit, notfalls selbst zu patchen. Schwachstellen in einer Komponente müssen Sie außerdem an deren Betreuer melden (Art. 13 Abs. 6 CRA).
Sie sind selbst Zulieferer? Dann rechnen Sie damit, dass Ihre Kunden genau diese Klauseln verlangen. Ein vorbereiteter CRA-Anhang zu Ihren Verträgen spart Verhandlungszeit – und Sie bestimmen die Ausgangsposition.
Monitoring und Meldung: Was seit September gilt
Seit dem 11. September 2026 laufen die Meldepflichten. Gemeldet wird einmal über die Single Reporting Platform (SRP) der ENISA. Die Meldung geht von dort an das zuständige CSIRT – in Deutschland das BSI – und an die ENISA.
Was, bis wann?
| Ereignis | Frühwarnung | Meldung | Abschlussbericht |
|---|---|---|---|
| Aktiv ausgenutzte Schwachstelle im Produkt | 24 Stunden | 72 Stunden | Spätestens 14 Tage, nachdem eine Korrektur oder Abhilfe verfügbar ist |
| Schwerwiegender Sicherheitsvorfall mit Auswirkung auf die Produktsicherheit | 24 Stunden | 72 Stunden | Binnen eines Monats nach der 72-Stunden-Meldung |
Zusätzlich müssen Sie die betroffenen Nutzer informieren – über den Vorfall und über Gegenmaßnahmen, die sie selbst ergreifen können.
Wann läuft die Uhr?
- Ab Kenntnis. Laut den Leitlinien der Kommission noch nicht beim ersten Verdacht. Sondern sobald eine erste Bewertung mit hinreichender Sicherheit ergibt, dass ein meldepflichtiges Ereignis vorliegt. Diese Bewertung muss aber unverzüglich erfolgen.
- CVE in einer Komponente: Startet die Frist nicht automatisch. Ist die Schwachstelle in Ihrem Produkt nicht erreichbar oder dort nicht ausgenutzt, besteht keine Pflichtmeldung.
- Schwerer Vorfall ist z. B. ein kompromittierter Update-Server oder eine manipulierte Build-Pipeline – alles, was Schadcode in Ihr Produkt oder zu Ihren Kunden bringen kann.
- Altfälle: Keine rückwirkende Meldung für Ausnutzungen, die Sie schon vor dem 11.09.2026 kannten.
- Nach Support-Ende: Die Meldepflicht endet nicht mit dem Support-Zeitraum.
Achtung Mehfachmeldung: Ein Vorfall kann zugleich nach CRA (ENISA-Plattform), NIS-2 (BSI) und DSGVO (Datenschutzbehörde) meldepflichtig sein. Unterschiedliche Kanäle, ähnliche Fristen. Ein gemeinsamer Meldeprozess für alle Regime spart im Ernstfall wertvolle Stunden.
Unsere Empfehlungen für das Monitoring
| Baustein | Was konkret |
|---|---|
| SBOM als Basis | Aktuelle SBOM je Produkt und Version, automatisiert erzeugt |
| Automatischer Schwachstellen-Abgleich | SBOM laufend gegen Datenbanken abgleichen, z. B. EUVD (ENISA), NVD, CISA-Katalog bekannter ausgenutzter Schwachstellen (KEV) |
| Signal für „aktiv ausgenutzt“ | KEV-Listen, Threat Intelligence, Hinweise von Kunden und Forschern, eigene Logs und Telemetrie |
| Meldekanal nach außen | Richtlinie zur koordinierten Offenlegung (CVD), Kontaktadresse, security.txt auf der Website |
| Verantwortlichkeiten | PSIRT oder benannte Verantwortliche mit Vertretung. Die Frist läuft auch am Wochenende. |
| Entscheidungsbaum | Wer bewertet? Wer entscheidet über die Meldung? Wer gibt frei? |
| Zugang zur Plattform | EU-Login-Konten für die SRP vorab einrichten, mehrere Personen berechtigen |
| Vorlagen | Textbausteine für 24-h-, 72-h- und Abschlussmeldung sowie Kundeninformation |
| Dokumentation | Kenntniszeitpunkt und Bewertung festhalten. Die Plattform erfasst ihn nicht – im Streitfall müssen Sie ihn belegen. |
| Lieferanten einbinden | Vertragliche Meldefristen der Zulieferer in den Prozess integrieren |
| Üben | Einmal jährlich eine Planspiel-Übung mit realistischem Szenario |
Bußgelder und Aufsicht
| Verstoß | Bußgeld bis zu |
|---|---|
| Grundlegende Anforderungen, Herstellerpflichten (Art. 13) und Meldepflichten (Art. 14) | 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes |
| Sonstige Pflichten (z. B. Importeure, Händler, Konformität, CE) | 10 Mio. Euro oder 2 % |
| Falsche, unvollständige oder irreführende Angaben gegenüber Behörden | 5 Mio. Euro oder 1 % |
Maßgeblich ist jeweils der höhere Betrag. Kleinst- und Kleinunternehmen werden für eine versäumte 24-Stunden-Frühwarnung nicht mit Bußgeld belegt – die übrigen Pflichten gelten aber auch für sie.
In Deutschland wird das BSI zentrale CRA-Behörde. Es koordiniert bereits seit September die Meldungen und übernimmt die Marktüberwachung. Das nationale CRA-Durchführungsgesetz hat der Bundestag verabschiedet. Das BSI kann danach Produkte prüfen, Nachbesserungen verlangen und unsichere Produkte vom Markt nehmen lassen. Neben dem Bußgeld sind gerade diese Maßnahmen für Softwareanbieter das eigentliche Geschäftsrisiko.
In 8 Schritten CRA-ready
- Produktinventar: Welche Software, Apps, Clients und Geräte bieten Sie an? Welche Cloud-Funktionen hängen daran?
- Betroffenheit prüfen: Produkt für Produkt, inklusive Cloud-Backend (RDPS). Ergebnis dokumentieren.
- Rolle und Klasse bestimmen: Hersteller, Importeur oder Händler? Standardprodukt oder „wichtiges“ bzw. „kritisches“ Produkt?
- Meldeprozess sofort aufsetzen: Verantwortliche, Erreichbarkeit, SRP-Zugang, Vorlagen. Diese Pflicht gilt bereits.
- SBOM und Monitoring einrichten: Automatisiert, je Version, mit Abgleich gegen Schwachstellen-Datenbanken.
- Lieferantenverträge prüfen und nachverhandeln: Laufzeiten, Patch-SLAs, Meldefristen, SBOM, End-of-Life.
- Kundenverträge anpassen: Support-Zeitraum, Update-Regeln und Nutzerinformationen in AGB und EULA.
- Roadmap bis Dezember 2027: Gap-Analyse gegen die grundlegenden Anforderungen, Budget und Verantwortliche festlegen.
Fazit
Der CRA macht Cybersicherheit zur Produkteigenschaft – wie Brandschutz bei Elektrogeräten. Für Softwareanbieter heißt das: Wer eine App, einen Client oder ein Gerät mit Cloud-Anbindung anbietet, ist meist drin. Die Meldepflichten laufen schon. Und die Update-Zusagen der nächsten Jahre entscheiden sich heute im Einkauf.
Betroffen? Wir prüfen Ihre Produkte, gestalten Lieferanten- und Kundenverträge CRA-fest und helfen beim Aufbau eines belastbaren Meldeprozesses. Sprechen Sie uns an
Quellen
- Verordnung (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- Leitlinien der EU-Kommission zur Anwendung des CRA, C(2026) 5252 vom 27.07.2026
- ENISA: Single Reporting Platform (SRP)
- BSI: Informationen zum Cyber Resilience Act
