24 Stunden Meldefrist. Auch für Produkte, die Sie
längst ausgeliefert haben.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden. Melden kann nur, wer erkennt. Wir bauen die technische Seite: Produkt-Pentests, Schwachstellenerkennung, SBOM-Review und einen Meldeprozess, der im Ernstfall trägt.
Die Meldepflicht gilt. Die Erkennung fehlt meistens.
Der Cyber Resilience Act hat eine unbequeme Eigenschaft: Die Pflicht zu melden greift früher als die Pflicht, systematisch zu suchen. Seit dem 11. September 2026 läuft bei einer aktiv ausgenutzten Schwachstelle eine 24-Stunden-Uhr — ab Kenntnis. Die vollständigen Anforderungen an die Schwachstellenbehandlung werden dagegen erst zum 11. Dezember 2027 verbindlich. Für Hersteller heißt das: Sie haften bereits für Vorfälle, deren Erkennung Sie erst später aufbauen müssen. Wer diese Lücke jetzt nicht schließt, meldet im Ernstfall entweder zu spät — oder gar nicht, weil niemand etwas bemerkt hat.
Verordnung (EU) 2024/2847
Cyber Resilience Act — was wann gilt
Zwei Termine entscheiden: einer ist vorbei, einer kommt.
- Meldepflichten seit
11. September 2026 — bindend
Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind meldepflichtig. Diese Pflicht greift auch für Produkte, die bereits im Markt sind — nicht nur für Neuware.
- Meldefristen
24 Stunden Frühwarnung · 72 Stunden Meldung · Abschlussbericht
Frühwarnung an das zuständige CSIRT und die ENISA über die europäische Meldeplattform. Für aktiv ausgenutzte Schwachstellen folgt der Abschlussbericht spätestens 14 Tage nach Bereitstellung einer Korrektur; bei schwerwiegenden Vorfällen spätestens einen Monat nach der 72-Stunden-Meldung (Art. 14 CRA).
- Vollständige Anwendung ab
11. Dezember 2027
Dann gelten die grundlegenden Cybersicherheitsanforderungen aus Anhang I, die Anforderungen an die Schwachstellenbehandlung, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung.
- Betroffen sind
Produkte mit digitalen Elementen
Hardware und Software, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden kann — von der vernetzten Maschine über das IoT-Gerät bis zur verkauften Softwarekomponente. Für einzelne Produktkategorien gelten Ausnahmen und Sonderregime.
- Schwachstellenbehandlung
Erkennen, dokumentieren, beheben, offenlegen — über den gesamten Unterstützungszeitraum
Anhang I Teil II verlangt unter anderem eine SBOM in maschinenlesbarem Format, regelmäßige Tests und Überprüfungen der Produktsicherheit, eine Policy zur koordinierten Offenlegung und eine Kontaktstelle für Schwachstellenmeldungen.
- Unterstützungszeitraum
In der Regel mindestens fünf Jahre
Sicherheitsupdates müssen über den festgelegten Zeitraum bereitgestellt werden — bei längerer erwarteter Lebensdauer entsprechend länger.
- Bußgeldrahmen
Bis zu €15 Mio. oder 2,5 % des weltweiten Jahresumsatzes
Für Verstöße gegen die grundlegenden Anforderungen sowie die Hersteller- und Meldepflichten (Art. 64 CRA). Für andere Pflichtverletzungen sind niedrigere Rahmen vorgesehen. Kleinst- und Kleinunternehmen werden für eine verpasste 24-Stunden-Frühwarnung nicht mit Geldbußen belegt — die Pflicht selbst gilt für sie trotzdem.
Diese Seite beschreibt die technische Umsetzung von Anforderungen aus dem Cyber Resilience Act und ersetzt keine Rechtsberatung. Ob Ihr Produkt in den Anwendungsbereich fällt, in welche Kategorie es eingestuft wird und welches Konformitätsverfahren gilt, klären Sie bitte mit Ihrer Rechtsabteilung oder einer spezialisierten Kanzlei.
Sind Sie heute meldefähig?
Viele Hersteller unterschätzen die Meldepflicht: Sie gilt für das ganze Produkt — Gerät, App und das Backend, mit dem es spricht — und auch für Produkte, die längst im Markt sind. Der Check zeigt in drei Minuten, wo Ihre Meldekette reißt.
- Ergebnis sofort, mit Ihren drei wichtigsten Lücken — auch per E-Mail
- Automatische Prüfung Ihres Meldewegs (security.txt)
- Danach auf Wunsch: kostenloser Sicherheits-Scan Ihrer Domain mit DevShield
Kostenloser CRA-Meldefähigkeits-Check
10 Fragen, 3 Minuten, Ergebnis sofort.
Woraus besteht Ihr Produkt?
Mehrfachauswahl. Apps und Backends, ohne die ein Gerät oder eine Software eine Funktion nicht erfüllt, gehören unter dem CRA zum Produkt — auch bei Waschmaschine, Wallbox oder Maschine. Ihre Web-Anwendung ist auch Backend für ein Gerät oder eine App? Dann wählen Sie „Cloud-Backend“.
Für wen das jetzt relevant ist
Wenn Sie etwas verkaufen, das sich verbinden kann, sind Sie Hersteller im Sinne der Verordnung
IoT- und Geräte-Hersteller
Firmware, Mobil-App, Cloud-Backend — drei Angriffsflächen, ein Produkt. Die Meldepflicht kennt diese Trennung nicht: Sie haften für das Gesamtprodukt.
Softwarehersteller und SaaS mit Produktanteil
Verkaufte Softwarekomponenten, On-Premise-Installationen, SDKs und Bibliotheken. Auch wer nur ein Modul liefert, liefert ein Produkt mit digitalen Elementen.
Zulieferer und Komponentenhersteller
Ihre Kunden brauchen für ihre eigene Konformität Angaben zu Ihren Komponenten — SBOM, Supportzeitraum, Schwachstellenkontakt. Diese Anfragen kommen bereits, lange vor 2027.
Alle, die 2027 für weit weg halten
Konformitätsbewertung, technische Dokumentation und ein belastbarer Schwachstellenprozess entstehen nicht in einem Quartal. Und die Meldepflicht gilt, wie gesagt, bereits heute.
Anhang I Teil II in der Praxis
Welche Pflicht wir technisch abbilden
Der CRA verlangt einen funktionierenden Umgang mit Schwachstellen über den gesamten Unterstützungszeitraum. Das ist kein Dokument, sondern ein Prozess.
Anforderung aus dem CRA
Unsere Leistung
Schwachstellen und Komponenten identifizieren und dokumentieren, inklusive SBOM in maschinenlesbarem Format
Anhang I Teil II
SBOM- und Abhängigkeits-Review: Wir prüfen, ob Ihre Stückliste vollständig ist, ob sie automatisiert entsteht und ob bekannte Schwachstellen in den enthaltenen Komponenten überhaupt auffallen würden.
Regelmäßige Tests und Überprüfungen der Sicherheit des Produkts
Anhang I Teil II
Produkt-Penetrationstest — Firmware, Gerät, API, Backend und Update-Mechanismus. Wiederholbar pro Major-Release statt einmalig vor der Markteinführung.
Schwachstellen unverzüglich durch Sicherheitsupdates beheben
Anhang I Teil II
Priorisierte Findings mit konkretem Fix-Vorschlag, auf Wunsch Umsetzung durch unser Entwicklungsteam, anschließend Re-Test. Der Update-Verteilmechanismus selbst wird mitgeprüft.
Policy zur koordinierten Offenlegung von Schwachstellen (CVD)
Anhang I Teil II
Wir richten den Meldeweg technisch ein: security.txt, Kontaktstelle, Triage-Ablauf, Bewertungsschema und Eskalationspfad bis zur 24-Stunden-Meldung. Inklusive Trockenübung.
Kontaktstelle für Schwachstellenmeldungen bereitstellen
Anhang I Teil II
Einrichtung und Überwachung des Meldekanals — plus Angriffsflächen-Monitoring, damit Sie nicht ausschließlich darauf angewiesen sind, dass jemand Sie informiert.
Aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden
Artikel 14
Die Meldung schreiben Sie — wir sorgen dafür, dass Sie überhaupt etwas zu melden haben: Erkennung über Monitoring, Leak- und Exploit-Beobachtung sowie ein definierter Ablauf, wer innerhalb welcher Stunde was entscheidet.
Sicherheit über den gesamten Unterstützungszeitraum gewährleisten
Artikel 13
Laufende Begleitung: Monitoring Ihrer Komponenten, Tests pro Release, Re-Tests nach Behebung — dokumentiert und datiert, also auch gegenüber einer Marktaufsicht vorzeigbar.
Der Weg zum belastbaren Schwachstellenprozess
Vom heutigen Stand zu einem Ablauf, der die 24-Stunden-Frist aushält
Erstgespräch (30 Minuten, kostenlos)
Welche Produkte, welche Softwarebasis, welcher Supportzeitraum, welche Meldewege gibt es heute? Danach wissen Sie, wo Sie stehen.
Kostenloser CRA-Meldefähigkeits-Check
10 Fragen, Ergebnis in 3 Minuten, dazu eine automatische Prüfung Ihrer security.txt. Auf Wunsch scannen wir Ihre Domain kostenlos mit DevShield und zeigen, welche Angriffsfläche von außen sichtbar ist.
SBOM- und Abhängigkeits-Review
Ist die Stückliste vollständig, aktuell und maschinenlesbar? Welche bekannten Schwachstellen stecken heute in Ihren Komponenten — und wer würde es merken?
Produkt-Penetrationstest
Firmware, Gerät, API, Backend, Update-Pfad. Wir testen das Produkt so, wie ein Angreifer es nach dem Kauf in die Hände bekommt.
Meldeprozess und CVD-Policy
Kontaktstelle, security.txt, Triage, Bewertung, Eskalation bis zur Frühwarnung. Einmal als Trockenübung durchgespielt, damit im Ernstfall niemand improvisiert.
Laufende Erkennung
Angriffsflächen- und Leak-Monitoring plus Beobachtung Ihrer Komponenten. Ohne Erkennung ist jede Meldefrist theoretisch.
Wiederholung pro Release
Sicherheit über den Unterstützungszeitraum heißt: erneut testen, wenn sich das Produkt ändert. Als laufende Begleitung geplant, nicht jedes Mal neu verhandelt.
Was wir tun — und was nicht
Wir machen die technische Seite der CRA-Konformität. Für den formalen Teil brauchen Sie andere Partner.
Das übernehmen wir
- Kostenloser CRA-Meldefähigkeits-Check mit DevShield-Scan Ihrer Domain
- Produkt-, Firmware-, API- und Backend-Penetrationstests
- SBOM- und Abhängigkeits-Review inklusive Toolchain
- Aufbau von CVD-Policy, Meldekanal und Triage-Ablauf
- Angriffsflächen- und Komponenten-Monitoring als Erkennungsgrundlage
- Secure-SDLC-Review und Entwickler-Workshop
- Wiederkehrende Tests pro Release als laufende Begleitung
Das übernehmen wir nicht
- Rechtliche Einstufung Ihres Produkts nach CRA-Kategorien
- Konformitätsbewertung und CE-Kennzeichnung — wir sind keine benannte Stelle
- Erstellung der vollständigen technischen Dokumentation im Rechtssinne
- Meldungen an CSIRT oder ENISA in Ihrem Namen
- Produkthaftungs- und Vertragsberatung
- 24/7-Bereitschaft für Ihre Meldefristen
Die 24-Stunden-Frist bleibt Ihre Pflicht — wir sorgen dafür, dass Sie den Auslöser rechtzeitig sehen und wissen, was zu tun ist. Für Konformitätsbewertung und Rechtsfragen vermitteln wir an spezialisierte Partner.
Unser Angebot zum CRA
Kostenlos einsteigen, danach Beratung und Tests nach Tagessatz, so viel Sie brauchen.
CRA-Begleitung
Schwachstellenprozess aufbauen und betreiben
- Monitoring Ihrer Komponenten: SBOM gegen CVE und KEV
- Ablauf für Schwachstellen: CVD-Policy, Kontaktstelle, Triage
- Meldekette für 24 h, 72 h und Abschlussbericht
- Trockenübung, damit im Ernstfall niemand improvisiert
- Laufende Erkennung über den Unterstützungszeitraum
CRA-Meldefähigkeits-Check
Wo stehen Sie bei der 24-Stunden-Meldepflicht?
- 10 Fragen zu Erkennung, Meldeweg und Updates
- Automatische Prüfung Ihrer security.txt
- Ergebnis mit konkreten nächsten Schritten
- Auf Wunsch: kostenloser DevShield-Scan Ihrer Domain
Produkt-Penetrationstest
Regelmäßige Tests im Sinne des CRA
- Firmware, Gerät, App, API und Backend
- Prüfung des Update-Mechanismus
- CVSS-priorisierte Findings
- Bericht für Technik und Management
- Re-Test nach Behebung inklusive
- Wiederholbar pro Major-Release
Häufige Fragen zum Cyber Resilience Act
Technische Einordnung — keine Rechtsberatung
Die Meldepflichten. Hersteller müssen aktiv ausgenutzte Schwachstellen in ihren Produkten sowie schwerwiegende Sicherheitsvorfälle melden: Frühwarnung binnen 24 Stunden an das zuständige CSIRT und die ENISA, gefolgt von einer ausführlicheren Meldung binnen 72 Stunden und einem Abschlussbericht. Die übrigen Anforderungen — grundlegende Cybersicherheitsanforderungen, Schwachstellenbehandlung, technische Dokumentation, CE-Kennzeichnung — werden zum 11. Dezember 2027 vollständig wirksam.
Bauen Sie die Erkennung, bevor Sie die Meldung brauchen
30 Minuten Erstgespräch: Wir schauen uns ein Produkt an, benennen die technischen Lücken zwischen heutigem Stand und Meldefähigkeit und sagen Ihnen, was davon vor Dezember 2027 stehen muss.