Was Ihre Website zum Cyber Resilience Act sichtbar macht

Signale prüfen

Der Zeitplan in Kürze

1. 10.12.2024Die Verordnung (EU) 2024/2847, der Cyber Resilience Act (CRA), ist in Kraft getreten.
2. 11.09.2026Die Meldepflichten für Hersteller gelten (Art. 14): aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle bei Produkten mit digitalen Elementen sind den zuständigen Stellen zu melden.
3. 11.12.2027Die Verordnung gilt im Übrigen, darunter die Anforderungen an Produkte und an den Umgang mit Schwachstellen (Anhang I) sowie die Konformitätsbewertung.

Allgemeine Information, Stand 12.10.2026. Maßgeblich ist der Text der Verordnung: Verordnung (EU) 2024/2847 auf EUR-Lex.

Was wir prüfen

Acht Signale, jedes mit den Seiten, die wir gelesen haben, und dem Text, der gepasst hat. Die Spalte „Thema“ nennt, worum es im CRA bei dem Stichwort geht. Sie ist allgemeine Information und keine Aussage über Ihr Produkt.

• CRA-01

  security.txt oder sichtbarer Sicherheitskontakt

  Wir suchen unter /.well-known/security.txt eine Datei nach RFC 9116 mit den Feldern Contact und Expires, oder eine sichtbare Seite mit einem Kontakt für Sicherheitsmeldungen.

  Thema: Anlaufstelle für Meldungen zu Schwachstellen (CRA Anhang I Teil II, Anhang II)

• CRA-02

  Hinweise zur Meldung von Schwachstellen

  Wir suchen deutsche und englische Formulierungen wie „Schwachstelle melden“, „Responsible Disclosure“, „Coordinated Disclosure“ oder „CVD“, außerdem das Feld Policy in einer security.txt.

  Thema: Richtlinie zur koordinierten Offenlegung von Schwachstellen (CRA Anhang I Teil II)

• CRA-03

  Sicherheitshinweise oder PSIRT-Seite

  Wir suchen Hinweise auf eine Seite oder einen Feed für Sicherheitshinweise: „Sicherheitshinweise“, „Security Advisories“, „PSIRT“, „CSAF“.

  Thema: Information über behobene Schwachstellen (CRA Art. 13, Anhang I Teil II)

• CRA-04

  Angabe zur Supportdauer

  Wir suchen auf den gelesenen Seiten Formulierungen wie „Supportdauer“, „Supportzeitraum“, „Sicherheitsupdates bis“ oder „End of Support“.

  Thema: Zeitraum, in dem Sicherheitsupdates bereitgestellt werden (CRA Art. 13)

• CRA-05

  Erwähnung einer SBOM

  Wir suchen die Begriffe „SBOM“, „Software Bill of Materials“, „Software-Stückliste“, „CycloneDX“ und „SPDX“.

  Thema: Software-Stückliste (CRA Anhang I Teil II)

• CRA-06

  Erwähnung der EU-Konformitätserklärung

  Wir suchen „EU-Konformitätserklärung“, „Declaration of Conformity“ und Wendungen zur CE-Kennzeichnung.

  Thema: EU-Konformitätserklärung und CE-Kennzeichnung (CRA Art. 28 bis 30)

• CRA-07

  Schlüssel oder Richtlinie für verschlüsselte Meldungen

  Wir suchen „PGP“, „GPG“ und „OpenPGP“ sowie in einer security.txt die Felder Encryption und Policy.

  Thema: Sicherer Kontaktweg für Schwachstellenmeldungen (CRA Anhang I Teil II)

• CRA-08

  Impressum mit erkennbarem Kontaktweg

  Wir nutzen dieselbe Impressumsprüfung wie im Deckproof-Test und melden nur, welche Art von Kontaktweg wir sehen (E-Mail, Telefon, Formular). Namen, Adressen und Nummern werden weder angezeigt noch gespeichert.

  Thema: Erreichbarkeit des Herstellers (CRA Anhang II)

Was wir nicht prüfen

• Ob der CRA für Ihr Produkt gilt, in welche Produktklasse es fällt und welche Pflichten sich daraus ergeben. Das hängt vom Einzelfall ab und ist Rechtsberatung, die wir nicht leisten.
• Alles hinter einer Anmeldung: Kundenportale, Download-Bereiche, Handbücher und PDFs.
• Ihre Produkte, Ihre Firmware und Ihre Prozesse. Wir führen keine Sicherheitstests durch und prüfen nicht, ob es im Unternehmen ein Verfahren zur Behandlung von Schwachstellen gibt.
• Die ganze Website. Wir lesen höchstens zehn öffentliche Seiten. „Nicht gefunden“ heißt deshalb „nicht auf diesen Seiten gefunden“, nicht „gibt es nicht“.

So gehen wir vor

• Wir rufen nur öffentliche Seiten ab, wie es jeder Browser tut: die Startseite, /.well-known/security.txt, /security, /sicherheit, /psirt, /impressum und bis zu vier Seiten, auf die die Startseite selbst verweist. Zusammen höchstens zehn Seiten.
• Höchstens eine Anfrage pro Sekunde. Eine Seite, die erst im Browser aufgebaut wird, lesen wir zusätzlich einmal in einem echten Browser.
• Eine Website, die in ihrer robots.txt DeckproofBot ausschließt, wird nicht geprüft, und Pfade, die die robots.txt sperrt, rufen wir nicht ab. Das Gleiche gilt für einen maschinenlesbaren TDM-Vorbehalt (tdmrep.json, Header oder Meta-Angabe). Antwortet die Website mit 429 oder 503, hören wir sofort auf.
• Das Ergebnis wird nicht gespeichert. Es wird Ihnen angezeigt und ist danach weg. Personenbezogene Angaben auf den gelesenen Seiten, etwa Namen im Impressum, zeigen wir nicht an und speichern wir nicht.
• Prüfen Sie Websites, die Ihnen gehören oder für die Sie eine Erlaubnis haben.

Auf dem Laufenden bleiben

Automatisierte technische Prüfung öffentlicher Seiten. Die Ergebnisse beschreiben, was auf diesen Seiten technisch gefunden wurde, und verlinken allgemeine Quellen. Deckproof bewertet Ihren Einzelfall nicht und leistet keine Rechtsberatung (keine Rechtsdienstleistung im Sinne des RDG). Ob und wie der Cyber Resilience Act für Ihr Produkt gilt, hängt vom Einzelfall ab; dafür wenden Sie sich an eine Rechtsanwältin oder einen Rechtsanwalt.

Ist ein Ergebnis falsch oder stört Sie etwas an diesem Test? Schreiben Sie uns, wir korrigieren oder nehmen den Test für Ihre Domain heraus: hallo@deckproof.dev