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.
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.
- 11. September 2026 — bindendAktiv 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.
- 24 Stunden Frühwarnung · 72 Stunden Meldung · AbschlussberichtFrü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).
- 11. Dezember 2027Dann gelten die grundlegenden Cybersicherheitsanforderungen aus Anhang I, die Anforderungen an die Schwachstellenbehandlung, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung.
- Produkte mit digitalen ElementenHardware 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.
- Erkennen, dokumentieren, beheben, offenlegen — über den gesamten UnterstützungszeitraumAnhang 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.
- In der Regel mindestens fünf JahreSicherheitsupdates müssen über den festgelegten Zeitraum bereitgestellt werden — bei längerer erwarteter Lebensdauer entsprechend länger.
- Bis zu €15 Mio. oder 2,5 % des weltweiten JahresumsatzesFü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.
Kostenlos · Ergebnis in 3 Minuten
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
Maschinen- und Anlagenbau
Vernetzte Maschinen, Steuerungen, Fernwartungszugänge. Der klassische Fall: Ein Produkt, das 15 Jahre im Feld steht, mit einer Softwarebasis, die seit der Auslieferung nicht angefasst wurde.
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.
Doppelt betroffene Unternehmen
Wer Produkte herstellt und gleichzeitig unter NIS2 fällt, muss beides bedienen. Die gute Nachricht: Die technische Basis — Erkennung, Test, Behebung, Nachweis — ist dieselbe.
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 | 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 | 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 | 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) | 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 | 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 | 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 | 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
Welche Produkte, welche Softwarebasis, welcher Supportzeitraum, welche Meldewege gibt es heute? Danach wissen Sie, wo Sie stehen.
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.
Ist die Stückliste vollständig, aktuell und maschinenlesbar? Welche bekannten Schwachstellen stecken heute in Ihren Komponenten — und wer würde es merken?
Firmware, Gerät, API, Backend, Update-Pfad. Wir testen das Produkt so, wie ein Angreifer es nach dem Kauf in die Hände bekommt.
Kontaktstelle, security.txt, Triage, Bewertung, Eskalation bis zur Frühwarnung. Einmal als Trockenübung durchgespielt, damit im Ernstfall niemand improvisiert.
Angriffsflächen- und Leak-Monitoring plus Beobachtung Ihrer Komponenten. Ohne Erkennung ist jede Meldefrist theoretisch.
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.
- 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
- 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.
Ja, und genau das wird regelmäßig übersehen. Wenn eine Schwachstelle in einem Ihrer bereits ausgelieferten Produkte aktiv ausgenutzt wird und Sie davon Kenntnis erlangen, beginnt die 24-Stunden-Frist. Für Hersteller mit langlebigen Produkten im Feld ist das die unangenehmste Eigenschaft der Verordnung — und der beste Grund, jetzt mit systematischer Erkennung anzufangen.
Nicht mit diesem Wort. Anhang I Teil II verlangt aber wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts. Ein Penetrationstest ist die übliche Auslegung dieser Anforderung, weil er das Produkt aus Angreiferperspektive prüft statt nur die eigene Testabdeckung zu bestätigen. Für die Marktaufsicht zählt später, dass Sie regelmäßig getestet und die Ergebnisse dokumentiert haben.
Es ist die Voraussetzung, nicht die Lösung. Eine SBOM sagt, was drin ist — nicht, ob es angreifbar ist, ob Ihr Update-Mechanismus funktioniert oder ob eine kritische Komponente überhaupt aktualisierbar ist. In der Praxis scheitert es selten an der Liste und häufig daran, dass niemand sie auswertet oder dass ein Update im Feld gar nicht ankommt.
Sehr wahrscheinlich ja — und unabhängig davon werden Ihre Kunden auf Sie zukommen, weil sie für ihre eigene Konformität Angaben von Ihnen brauchen: SBOM, Supportzeitraum, Schwachstellenkontakt, Update-Zusagen. Diese Anfragen laufen bereits, lange vor 2027. Wer sie sauber beantworten kann, hat einen Vertriebsvorteil, keinen Kostenblock.
Der Check und der DevShield-Scan Ihrer Domain sind kostenlos. Danach rechnen wir nach Tagessatz ab: CRA-Begleitung ab €800 pro Tag, Produkt-Penetrationstests ab €400 pro Tag. Wie viele Tage es braucht, hängt davon ab, wie viele Produkte Sie haben, woraus sie bestehen (Backend, App, Firmware, Gerät) und was an Erkennung und Meldeweg schon existiert. Im Erstgespräch schätzen wir den Aufwand für Ihren Fall ehrlich ein.
Mit dem kostenlosen CRA-Meldefähigkeits-Check auf dieser Seite: 10 Fragen, Ergebnis in 3 Minuten, dazu eine automatische Prüfung Ihrer security.txt. Die häufigste Erkenntnis daraus: Melden könnten Sie — bemerken würden Sie es nicht. Deshalb ist der nächste Schritt meist Erkennung, nicht Dokumentation: ein kostenloser DevShield-Scan Ihrer Domain und ein Erstgespräch, in dem wir festlegen, was zuerst stehen muss.
Die Uhr läuft bereits
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.
Yen Ngoc Phan · Manuel Gruschka