Zum Inhalt springen
Treffen auf der it-sa 2026
DE, Sprache: Deutsch

CRA-Nachweise für vernetzte Produkte

Von einem ausgelieferten Release eines vernetzten Produkts zu unabhängig überprüfbaren Nachweisen darüber, wovon der Hersteller Kenntnis hatte, was er entschied und was er tat.

Treffen auf der it-sa 2026So geht’s
Zeitachse vom Signal zum Bericht: Ein Signal wird anhand einer internen Prüffrist bewertet; die Erklärung des Herstellers zur Kenntnis startet die im CRA vorgesehene Zeitmessung; eine namentlich benannte Person erfasst die Entscheidung; die 24 Stunden für die Frühwarnung und die 72 Stunden für die Meldung von Schwachstellen laufen ab Kenntnis, die 14 Tage für den Abschlussbericht ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme (bei Sicherheitsvorfällen ein Monat ab Übermittlung der Meldung des Sicherheitsvorfalls innerhalb von 72 Stunden); der Bericht wird als Entwurf erstellt und seine Übermittlung erfasst; ein Nachweisprotokoll umfasst die gesamte Kette. Die Bögen sind nicht maßstabsgetreu.

  1. Ein Befund, ein KEV-Eintrag, ein Lieferantenhinweis.

  2. Interne Bewertung des Produkts.

  3. Die Erklärung des Herstellers: tatsächlicher Zeitpunkt, Grundlage, Verfasser. Ab diesem Zeitpunkt läuft die Uhr.die Uhr läuft ab dem tatsächlichen Zeitpunkt, nicht ab der Erfassung

  4. Zu melden / nicht zu melden, mit angegebener Begründung; von einer namentlich benannten Person erfasst.

  5. 24 hFrühwarnung
  6. 72 hMeldung von SchwachstellenMeldung
  7. Korrektur- oder Risikominderungsmaßnahme verfügbarMaßnahme verfügbar
  8. 14 TageAbschlussbericht, ab Verfügbarkeit einer Korrektur- oder RisikominderungsmaßnahmeAbschlussbericht, ab Verfügbarkeit der Maßnahmebei Sicherheitsvorfällen ein Monat ab der 72-h-Meldung des Sicherheitsvorfallsbei Sicherheitsvorfällen ein Monat ab der 72-h-Meldung

  9. Entwurf → Übermittlung erfasst.

  1. Signal Ein Befund, ein KEV-Eintrag, ein Lieferantenhinweis.
  2. Bewertung Interne Bewertung des Produkts.
  3. Kenntnis Die Erklärung des Herstellers: tatsächlicher Zeitpunkt, Grundlage, Verfasser. Ab diesem Zeitpunkt läuft die Uhr.
  4. Entscheidung Zu melden / nicht zu melden, mit angegebener Begründung; von einer namentlich benannten Person erfasst.
  5. Bericht Entwurf → Übermittlung erfasst.
Nachweisprotokoll: wer wann wovon Kenntnis hatteBei später Erfassung wird die bereits verstrichene Zeit angezeigt.Station auswählen, um Details zu sehen
Für
Hersteller von Produkten mit digitalen Elementen
Quellen
OSV, GitHub Advisories, NVD, CISA KEV und EPSS
Exporte
PDF und JSON
CRA-Termine
11. September 2026 · Meldepflichten gelten11. Dezember 2027 · CRA gilt vollständig

Zwei Termine. Beide gehören zusammen.

Die Cyberresilienz-Verordnung (CRA) sieht eine Meldepflicht und ab einem späteren Zeitpunkt Geldbußen vor. Eine Aussage zu einem der beiden Termine ist ohne den anderen unvollständig.

  1. Meldepflicht gilt: Art. 14 CRA

    • 24 hFrühwarnung
    • 72 hMeldung von Schwachstellen
    • 14 TageAbschlussbericht, ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme
    • ein Monatab der 72-h-Meldung des Sicherheitsvorfalls

    Ab diesem Datum müssen Hersteller eine aktiv ausgenutzte Schwachstelle in ihrem Produkt oder einen schwerwiegenden Sicherheitsvorfall, der sich auf die Sicherheit des Produkts auswirkt, melden: eine Frühwarnung unverzüglich, in jedem Fall aber innerhalb von 24 Stunden, nachdem sie davon Kenntnis erlangt haben, eine Meldung von Schwachstellen beziehungsweise eine Meldung des Sicherheitsvorfalls innerhalb von 72 Stunden und einen Abschlussbericht innerhalb von 14 Tagen, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht (bei Sicherheitsvorfällen innerhalb eines Monats nach der Meldung des Sicherheitsvorfalls). Dies gilt auch für bereits auf dem Markt befindliche Produkte im Anwendungsbereich.

  2. Geldbußen gelten: Art. 64 CRA

    Ab diesem Datum können Verstöße gegen Art. 13, Art. 14 und Anhang I mit Geldbußen von bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.

Was ein Hersteller ab dem 11. September 2026 auf Anfrage zeigen können sollte

Wann er Kenntnis erlangt hat, auf welcher Grundlage, was er entschieden hat, wer die Entscheidung getroffen hat und was wann gemeldet wurde, mit den Nachweisen zu jedem Schritt.

So funktioniert es

Vier Schritte vom ausgelieferten Release bis zu einer Dokumentation, die Sie übergeben können. Echte Ansichten. Keine Mock-Daten, keine Kundendaten.

  1. Schritt 1: Erstellen

    Erstellen Sie die SBOM lokal. Laden Sie die Nachweise hoch, nicht Ihren Quellcode.

    Erstellen Sie die Software-Stückliste (SBOM) in Ihrer eigenen Infrastruktur mit dem Open-Source-Werkzeug crAcken SBOM oder laden Sie SPDX / CycloneDX aus Ihrer Pipeline hoch. Jedes Release wird als eigene Version aufbewahrt.

    ./cracken-sbom generate --target-type rootfs --target /work/firmware/rootfs --target-id firmware-2026.10.04 --output /work/evidence/firmware-2026.10.04
    • sbom.cdx.jsonminimiertes CycloneDX-Inventar, die Datei, die Sie hochladen
    • provenance.jsonwie und wann es erstellt wurde, lokal gespeichert
    • quality.jsonPaketanzahl und erkannte Lücken, lokal gespeichert
    Das Open-Source-SBOM-Tool von crAcken: ein Befehl, drei Dateien

    Akzeptierte UploadsSPDXCycloneDX

    Integriert
    Ihre eigene Infrastruktur
    Hochgeladen
    die Nachweise, nicht Ihr Quellcode

    crAcken SBOM auf GitHub (öffnet sich in einem neuen Tab)

  2. Schritt 2: Überwachen

    Erkennen Sie, welches ausgelieferte Release betroffen ist, wenn sich Informationen zu Schwachstellen ändern.

    Befunde aus OSV, GitHub Advisories, NVD, CISA KEV und EPSS, zugeordnet zu Ihren ausgelieferten Releases. Ein KEV-Eintrag erscheint als Signal für eine Ausnutzung: Die Schwachstelle wird bekanntermaßen andernorts ausgenutzt, prüfen Sie Ihr Produkt. EPSS erscheint als Wahrscheinlichkeit. Keines von beidem startet die Zeitmessung. Der Vergleich von Release zu Release zeigt, was sich zwischen den ausgelieferten Versionen geändert hat.

    Ansicht
    Befunde nach Komponenten: log4j-core mit dem Signal für eine Ausnutzung und dem Datum der ersten Erkennung im Produkt.

  3. Schritt 3: Entscheiden

    Machen Sie aus einem Signal eine CRA-Entscheidung mit klarer Zuständigkeit, dokumentiert durch eine namentlich benannte Person.

    Ein Befund ist ein Signal, niemals Kenntnis. Ein Meldefall wird mit einer internen Prüffrist eröffnet, die als intern gekennzeichnet ist. Der Hersteller dokumentiert, wann und auf welcher Grundlage er Kenntnis erlangt hat. Die Zeitberechnung nach der CRA beginnt mit diesem tatsächlichen Zeitpunkt, nicht mit dem Zeitpunkt der Dokumentation; bei später Dokumentation wird die bereits verstrichene Zeit angezeigt.

    • Signal: keine Kenntnis
    • Von einer namentlich benannten Person erfasst
    Ansicht
    Ein Meldefall: die interne Prüfzeit mit internen Prüffristen von 24 h und 72 h. Nur interne Prüfung, keine Übermittlung.

  4. Schritt 4: Nachweise

    Bereiten Sie den erforderlichen Meldeablauf anhand desselben Nachweisprotokolls vor.

    Entwürfe für Frühwarnung, Meldung von Schwachstellen beziehungsweise Meldung des Sicherheitsvorfalls und Abschlussbericht, exportiert als PDF und JSON. Eine Übermittlung wird dokumentiert, niemals als erfolgt vorausgesetzt. Der Fallverlauf hält fest, was wann bekannt war, damit auch eine nicht beteiligte Person die Dokumentation prüfen kann.

    Ansicht
    Die Berichtsvorschau: Übermittlungsnachweise für Frühwarnung, Meldung von Schwachstellen und Abschlussbericht, jeweils nicht dokumentiert. crAcken übermittelt keine Meldungen.

Was crAcken anders macht

  • Der damalige Kenntnisstand

    Was wusste die Organisation zum Zeitpunkt T? crAcken dokumentiert, wann jeder Befund erstmals in Ihrem Produkt erkannt wurde, und jede Fallentscheidung mit ihrem Zeitpunkt. So können Sie zeigen, was damals bekannt war, nicht was das System heute weiß.

  • Nachweise statt Dashboards

    Das Ergebnis ist eine Dokumentation für einen Prüfer, einen Kunden oder eine Behörde: wer was wusste, wer was entschieden hat und wann.

  • Ein Modell der Kenntnis, das zur CRA passt

    Kenntnis startet die Zeitmessung, nicht eine CVE-Veröffentlichung, ein CVSS-Wert oder ein KEV-Eintrag. crAcken unterscheidet zwischen Erkennung, Kenntnis und Dokumentation. Wird Kenntnis später dokumentiert, verschiebt das den Beginn der Zeitmessung nicht.

  • KI mit klaren Grenzen

    Das KI-Memo ruft Nachweise ab, erklärt und erstellt Entwürfe. Es darf Empfehlungen geben. Es entscheidet niemals darüber, wann der Hersteller Kenntnis erlangt hat, welche Zeitvorgaben gelten, ob eine Meldung erforderlich ist oder ob die CRA-Anforderungen erfüllt sind. Eine namentlich benannte Person dokumentiert jede Festlegung.

Für wen

Hersteller von Produkten mit digitalen Elementen: eingebettete, industrielle und vernetzte Geräte.

  1. Der Ingenieur der die SBOM pflegt, Befunde bewertet und wissen muss, welches ausgelieferte Release betroffen ist.

  2. Der Produktverantwortliche der entscheidet, was ein Signal für ein Produkt auf dem Markt bedeutet, und den Meldefall verantwortet.

  3. Die unterzeichnende Person die den Bericht freigibt und zeigen können muss, auf welcher Grundlage er erstellt wurde.

Wer hinter crAcken steht

Hinter crAcken steht ein europäisches Team praktisch tätiger Ingenieure für eingebettete Systeme, Cybersicherheit und Post-Quanten-Sicherheit. crAcken entstand, als wir die Anforderungen der CRA für unsere eigenen vernetzten Produkte erfüllen mussten. Wir nutzen es in unserer täglichen Arbeit, und jeder bearbeitete Fall verbessert es, weil wir vernetzte Produkte und die Welt um sie herum vor Cyberbedrohungen schützen wollen.

Wo Sie uns treffen

  • Bisher

    NXP Tech Days Stuttgart

    crAcken wurde im Mai 2026 auf Einladung von NXP und Avnet am Avnet-Stand auf den NXP Tech Days Stuttgart vorgestellt.

Kontakt

Teilen Sie uns mit, ob Sie uns auf der it-sa 2026 treffen oder crAcken testen möchten. Wir antworten per E-Mail.

Vielen Dank. Ihre Nachricht wurde gesendet.

Bitte prüfen Sie die betroffenen Felder im Formular und senden Sie es erneut.

Senden fehlgeschlagen. Schreiben Sie uns an alex.v@mcsq.tech oder auf LinkedIn (öffnet sich in einem neuen Tab).

Alle Felder außer Firma sind Pflichtfelder.

Thema

Bis zu 2000 Zeichen.

Wir verwenden Ihre Angaben nur zur Bearbeitung Ihrer Anfrage. Mehr dazu unter Datenschutz.