Am 11. September 2026 beginnt für Hersteller von Produkten mit digitalen Elementen eine der frühesten operativen Pflichten des Cyber Resilience Act (CRA): Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen über die neue zentrale Meldeplattform angezeigt werden. Das ist mehr als eine neue Compliance-Frist. Innerhalb weniger Stunden müssen Produktidentität, betroffene Märkte, technische Bewertung und Maßnahmen zusammengeführt werden.
Ein Digitaler Produktpass oder eine QR-verknüpfte Produktseite kann dabei helfen, ein Gerät eindeutig zuzuordnen und Nutzer später über ein Update zu informieren. Er ist aber weder der gesetzliche Meldeweg noch der richtige Speicherort für vertrauliche Exploit-Details. Hersteller sollten deshalb jetzt drei Datenpfade trennen: die Behördenmeldung, die öffentliche Produktinformation und die interne Update-Historie.
Der neue Anlass: Leitlinien vom 27. und 31. Juli
Die Europäische Kommission veröffentlichte am 27. Juli 2026 ihre erste umfassende CRA-Leitlinie. Sie behandelt unter anderem Meldepflichten, Risikobewertung, Supportzeiträume und wesentliche Änderungen. Die Leitlinie ist nicht bindend, konkretisiert aber mit 67 Beispielen, wie Unternehmen die Verordnung praktisch anwenden können.
Vier Tage später, am 31. Juli, aktualisierte ENISA ihre Informationen zur Single Reporting Platform. Dort stehen inzwischen der geplante Ablauf, die vorgesehenen Eingabefelder und Hinweise zur Registrierung. Die Plattform soll bis 11. September 2026 betriebsbereit sein; Funktions- und Sicherheitstests laufen nach Angaben der Kommission bereits.
Die zeitliche Staffelung ist wichtig: Die Hauptpflichten des CRA gelten grundsätzlich ab 11. Dezember 2027. Artikel 14 mit den Meldepflichten gilt jedoch schon ab 11. September 2026. Das bestätigt sowohl Artikel 71 der Verordnung (EU) 2024/2847 als auch die am 31. Juli aktualisierte Übersicht der Kommission zum CRA-Meldeverfahren.
Drei Datenräume statt eines überladenen Produktpasses
Die CRA-Meldung und eine öffentliche Produktseite verfolgen unterschiedliche Ziele. Wer beide in einem einzigen Datensatz abbildet, riskiert entweder zu wenig Information für das Incident-Team oder zu viele sensible Details im öffentlichen Web.
1. Vertrauliche Meldung an SRP, CSIRT und ENISA
Die Single Reporting Platform ist der gesetzliche Eingangskanal. Gemeldet werden müssen zwei Ereignistypen: eine aktiv ausgenutzte Schwachstelle, für die verlässliche Hinweise auf eine unbefugte Ausnutzung vorliegen, und ein schwerwiegender Vorfall, der Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder Funktionen beeinträchtigt.
Die Meldung enthält nicht nur eine Produktbezeichnung. ENISA führt unter anderem betroffene Mitgliedstaaten, eine erste Bewertung, bereits getroffene Gegenmaßnahmen, mögliche Nutzermaßnahmen und die Sensitivität der Information als Felder auf. Spätere Stufen können Schweregrad, Auswirkungen, Angreiferinformationen und technische Details zum Sicherheitsupdate enthalten. Solche Informationen gehören nicht automatisch auf eine frei erreichbare DPP-Seite.
2. Öffentliche Produkt- und Sicherheitsinformation
Der öffentliche Datenpfad beantwortet andere Fragen: Welches Produkt und welche Version habe ich? Wird sie noch unterstützt? Ist ein Sicherheitsupdate verfügbar? Was muss ich als Nutzer konkret tun? Dafür kann eine stabile Produktseite hinter einem QR-Code oder einem anderen Datenträger sinnvoll sein.
Die öffentliche Seite sollte nur freigegebene Informationen zeigen: betroffene Modell- und Versionsbereiche, verfügbare sichere Version, Installationshinweise, Supportkontakt und Veröffentlichungszeitpunkt. Exploit-Details, interne Erkennungsregeln, ungepatchte Angriffswege oder personenbezogene Vorfalldaten bleiben im geschützten Verfahren. Die Entscheidung über eine öffentliche Warnung liegt nicht beim QR-Code: Nach Artikel 17 CRA kann das koordinierende CSIRT die Öffentlichkeit informieren oder den Hersteller dazu auffordern, wenn dies zur Prävention oder Eindämmung erforderlich ist.
3. Interne Update- und Evidenzhistorie
Der dritte Pfad ist die nachvollziehbare Arbeitsakte. Sie verbindet Produkt-ID, Hardware- und Softwareversion, Softwarestückliste, Zeitpunkt der Kenntniserlangung, Triage-Entscheidungen, Meldestufen, Patch-Freigabe und öffentliche Mitteilung. Diese Historie muss Änderungen versionieren, statt ältere Bewertungen still zu überschreiben.
Für einen DPP-Betrieb ist dieser Unterschied zentral: Die öffentliche Ansicht zeigt den aktuellen freigegebenen Zustand; die interne Historie belegt, wie er entstanden ist. Wer Produktdaten bereits ereignisbasiert pflegt, kann dafür dasselbe Prinzip nutzen wie bei DPP-Updates und Webhooks: Ein Ereignis löst Folgeprozesse aus, doch jeder Empfänger bekommt nur die für seine Rolle vorgesehenen Felder.
Die CRA-Uhr beginnt mit der Kenntnis
Artikel 14 arbeitet mit gestuften Fristen. Für eine aktiv ausgenutzte Schwachstelle ist ohne unangemessene Verzögerung, spätestens innerhalb von 24 Stunden nach Kenntnis, eine Frühwarnung nötig. Innerhalb von 72 Stunden folgt die ausführlichere Schwachstellenmeldung. Der Abschlussbericht ist spätestens 14 Tage verfügbar, nachdem eine Korrektur- oder Minderungsmaßnahme bereitsteht.
Bei einem schwerwiegenden Sicherheitsvorfall gelten ebenfalls 24 Stunden für die Frühwarnung und 72 Stunden für die Vorfallmeldung. Der Abschlussbericht folgt innerhalb eines Monats nach der 72-Stunden-Meldung. Die Fristen laufen also nicht ab Veröffentlichung eines CVE und nicht ab dem nächsten regulären Release, sondern ab dem Zeitpunkt, zu dem der Hersteller als informiert gilt.
Für die Praxis empfiehlt sich ein klarer Ablauf:
- Eingang aus Support, Monitoring, Forschung oder Lieferkette mit Zeitstempel erfassen.
- Produkt und Version gegen eine stabile interne Produkt-ID auflösen.
- Ausnutzung beziehungsweise Vorfallschwere durch das zuständige Team bewerten.
- Den 24-Stunden-Datensatz aus bestätigten Mindestangaben erzeugen und über die SRP einreichen.
- Technische Erkenntnisse bis zur 72-Stunden-Stufe ergänzen, ohne den ursprünglichen Stand zu verlieren.
- Patch, Nutzermaßnahme und öffentliche Information getrennt freigeben.
- Abschlussbericht und interne Historie miteinander verknüpfen.
Diese Kette sollte vor September als Übung durchgespielt werden. ENISA weist darauf hin, dass Organisationen ihre internen Abläufe und Datenbanken automatisieren können, die Plattform zum Start aber keine API anbieten wird. Deshalb ist ein Export- und Vier-Augen-Prozess realistischer als eine ungeprüfte Direktintegration.
Eine gemeinsame Produkt-ID, aber getrennte Zugriffsrechte
Trennung bedeutet nicht, drei unverbundene Kopien zu pflegen. Der bessere Ansatz ist eine gemeinsame, unveränderliche Produktreferenz mit rollenabhängigen Ansichten.
Mindestens diese Zuordnungen sollten vorliegen:
- interne Produkt-ID sowie Modell-, Chargen- oder Serienbezug;
- Hardware-, Firmware- und Softwareversion;
- Mitgliedstaaten, in denen die betroffene Ausführung bereitgestellt wurde;
- Status der Sicherheitsbewertung und Zeitpunkt der Kenntniserlangung;
- Referenzen auf 24- und 72-Stunden-Meldung sowie Abschlussbericht;
- freigegebene Nutzermaßnahme und sichere Zielversion;
- Veröffentlichungsstatus der öffentlichen Produktseite.
Die Autorisierung sollte feldweise gedacht werden. Incident-Team und CRA-Verantwortliche benötigen die vollständige Akte. Support und Vertrieb brauchen eine freigegebene Handlungsanweisung. Nutzer sehen nur die öffentliche Meldung. Ein QR-Code transportiert dabei idealerweise lediglich eine stabile Produktadresse; die Plattform dahinter entscheidet anhand von Status und Rolle, welche Information ausgeliefert wird.
Was Hersteller bis September testen sollten
Ein sinnvoller Testfall braucht keine echte Schwachstelle. Wählen Sie ein vernetztes Produkt, eine betroffene Firmware-Version und drei Mitgliedstaaten. Simulieren Sie die Kenntniserlangung an einem Werktag und prüfen Sie:
- Kann das Team innerhalb von 24 Stunden die Produktabdeckung und Mindestangaben bestätigen?
- Ist klar, wer als Vertreter über EU Login auf die SRP zugreifen soll?
- Lassen sich 72-Stunden-Informationen ergänzen, ohne vertrauliche Details öffentlich zu machen?
- Führt die Patch-Freigabe zu einer geprüften Nutzerinformation in allen erforderlichen Sprachen?
- Bleibt die öffentliche URL stabil, wenn sich Version und Maßnahmen ändern?
- Ist nachvollziehbar, wer welchen Stand wann freigegeben hat?
Für den letzten Punkt hilft eine konsequente, versionierte Datenpflege. Der qr3-Beitrag über laufende DPP-Aktualisierung zeigt die Grundidee: Identität bleibt stabil, während fachliche Daten kontrolliert fortgeschrieben werden. Im CRA-Prozess kommt eine strengere Vertraulichkeits- und Freigabeschicht hinzu.
Fazit: Der Produktpass ist Verteiler, nicht Meldestelle
Die neuen Leitlinien machen den September-Termin operativ greifbar. Hersteller müssen keine vertrauliche Schwachstellendatenbank in ihren Digitalen Produktpass einbauen. Sie benötigen vielmehr einen belastbaren Übergang zwischen drei klar getrennten Bereichen: Behördenmeldung, interne Evidenz und freigegebene Nutzerinformation.
Eine gemeinsame Produkt-ID hält diese Bereiche zusammen. Rollen, Freigaben und Versionierung verhindern, dass vertrauliche Details nach außen gelangen oder Nutzer zu spät von einer verfügbaren Maßnahme erfahren. Der QR-Code bleibt dabei nützlich, aber bewusst unspektakulär: Er führt dauerhaft zum richtigen Produktkontext. Die eigentliche CRA-Compliance entsteht in den Prozessen dahinter.
