Ab dem 11. September 2026 läuft eine 24-Stunden-Uhr. Wer seine Stückliste nicht kennt, kann sie nicht anhalten.

Was passiert am 11. September 2026 wirklich?

Die meisten Hersteller haben den Cyber Resilience Act als Thema für 2027 abgelegt. Das ist nachvollziehbar und falsch. Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten, ihre Sicherheitsanforderungen greifen in voller Breite ab dem 11. Dezember 2027. Dazwischen liegen zwei vorgezogene Stichtage. Seit dem 11. Juni 2026 gilt Kapitel IV zur Notifizierung von Konformitätsbewertungsstellen, also die Artikel 35 bis 51. Und ab dem 11. September 2026 gilt Artikel 14: die Meldepflicht (Art. 71 Abs. 2).

Der Abstand zwischen diesen beiden Daten ist keine juristische Feinheit, sondern eine Frage der Betriebsbereitschaft. Am 11. Dezember 2027 musst du nachweisen, dass ein Produkt sicher entwickelt wurde. Am 11. September 2026 musst du binnen 24 Stunden eine Meldung absetzen können, die voraussetzt, dass du weißt, was in deinen Produkten steckt, wer sie im Feld betreibt und wer bei dir nachts das Telefon abnimmt. Das erste ist ein Entwicklungsprojekt mit 15 Monaten Vorlauf. Das zweite ist eine organisatorische Fähigkeit, die es entweder gibt oder nicht.

Genau diese Reihenfolge ist das Problem. Die Meldepflicht kommt zuerst, die Bauanforderungen später. Wer die Verordnung von hinten liest, plant für 2027 eine sichere Entwicklung und übersieht, dass er 2026 bereits über unsichere Altprodukte berichten muss.

Warum die drei Fristen härter sind, als sie klingen

Artikel 14 kennt zwei Auslöser und je drei Berichte. Der erste Auslöser ist eine in einem Produkt enthaltene, aktiv ausgenutzte Schwachstelle. Der zweite ist ein schwerwiegender Vorfall, der die Cybersicherheit des Produkts beeinträchtigt. Beide Auslöser haben eigene Fristenketten, und die Bezugspunkte sind unterschiedlich.

Die beiden Abschlussberichte hängen an völlig verschiedenen Ankern. Bei der Schwachstelle läuft die Uhr ab dem Moment, in dem eine Gegenmaßnahme verfügbar ist. Der Verordnungstext spricht dabei ausdrücklich von einer korrigierenden oder risikomindernden Maßnahme. Ein dokumentiertes Workaround-Verfahren löst die 14 Tage also genauso aus wie ein fertiger Patch. Beim Vorfall dagegen zählt die Einreichung der 72-Stunden-Meldung, nicht die Kenntniserlangung und nicht die Verfügbarkeit einer Lösung. Wer diese beiden Anker verwechselt, plant den falschen Kalender.

Dazu kommt eine oft übersehene Klausel: Nach Art. 14 Abs. 6 kann der zuständige CSIRT jederzeit einen Zwischenbericht zum Stand der Dinge anfordern. Die drei Fristen sind eine Untergrenze, keine abschließende Berichtslast. Wer für 24, 72 und 14 plant, aber keine Kapazität für Rückfragen einplant, hat die Ressourcen falsch dimensioniert.

Was zählt überhaupt als schwerwiegender Vorfall?

Art. 14 Abs. 5 liefert eine Legaldefinition, und sie enthält bewusst keinen CVSS-Schwellenwert. Schwerwiegend ist ein Vorfall, wenn er die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen. Ebenso, wenn er zur Einschleusung oder Ausführung von Schadcode geführt hat oder führen kann (Art. 14).

Das “kann” ist der teure Teil. Die Schwelle ist potenzialbasiert, nicht schadensbasiert. Ein Unternehmen, dessen interne Eskalationsregel lautet “wir melden ab CVSS 9,0”, hat sich eine Regel gegeben, die im Verordnungstext keine Entsprechung findet. Die Bewertung muss produktbezogen erfolgen, und sie muss innerhalb von Stunden erfolgen, nicht im nächsten Security-Board.

Die vergessene vierte Pflicht

Art. 14 Abs. 8 verlangt zusätzlich, dass der Hersteller die betroffenen Nutzer und gegebenenfalls alle Nutzer über die Schwachstelle oder den Vorfall informiert, einschließlich der Risikominderungs- und Abhilfemaßnahmen. Und zwar in einem maschinenlesbaren, automatisiert verarbeitbaren Format. Unterlässt er das, können die CSIRTs die Nutzer selbst informieren.

Das ist der Punkt, an dem viele Meldeprozesse organisatorisch reißen. Die Behördenmeldung ist ein Formular. Die Nutzerinformation ist eine Verteilerliste, ein Kanal und ein maschinenlesbares Advisory-Format, das jemand vorher aufgesetzt haben muss. Beides gleichzeitig unter Zeitdruck zu improvisieren, funktioniert nicht.

Warum End-of-Life-Abhängigkeiten das größte Risiko sind

Hier liegt die eigentliche Sprengladung. Art. 69 Abs. 2 stellt Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, weitgehend frei: Die übrigen CRA-Anforderungen greifen bei ihnen erst, wenn sie ab diesem Datum wesentlich verändert werden. Genau davon macht Absatz 3 eine Ausnahme, und zwar im Wortlaut: “By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027” (Art. 69).

Übersetzt in Betriebssprache: Für den kompletten Altbestand musst du melden, aber du musst ihn nicht sicher gebaut haben. Die Nachweispflicht ist ausgesetzt, die Berichtspflicht nicht.

Das trifft exakt die Produkte, über die niemand mehr gern spricht. Die Appliance-Generation von 2019 mit einer eingefrorenen Linux-Distribution. Der Industrie-Gateway mit einer OpenSSL-Version, für die es seit Jahren keine Updates mehr gibt. Die mobile App, deren SDK-Anbieter abgekündigt wurde. Für all das brauchst du ab dem 11. September 2026 keine Konformitätserklärung, aber eine belastbare Antwort auf die Frage: Ist diese Schwachstelle in einem unserer ausgelieferten Produkte enthalten und wird sie ausgenutzt.

Bei End-of-Life-Abhängigkeiten ist diese Antwort strukturell schwierig. Es gibt keinen Upstream-Advisory-Feed mehr, keine gepflegten Versionsbereiche, oft nicht einmal einen verlässlichen Paketnamen. Die Schwachstelle taucht in einem Exploit-Bericht auf, und niemand im Unternehmen kann in 24 Stunden sagen, in welchen Firmware-Ständen die betroffene Bibliothek steckt. Genau deshalb ist die technische Vorarbeit für die Meldepflicht keine Compliance-Aufgabe, sondern eine Frage der Sicherheitsarchitektur.

Warum ohne Stückliste keine 24-Stunden-Meldung möglich ist

Eine Frühwarnung nach 24 Stunden verlangt drei Angaben, die kein Ticketsystem der Welt aus dem Nichts erzeugt: welches Produkt betroffen ist, in welchen ausgelieferten Versionen, und wer diese Versionen einsetzt. Wer diese drei Angaben erst im Vorfall recherchiert, verliert die Frist beim ersten Anruf.

Eine Software Bill of Materials ist deshalb keine Dokumentationspflicht, sondern die Datenstruktur, an der die Frist hängt. Entscheidend ist nicht, dass eine SBOM existiert, sondern dass sie pro ausgeliefertem Release existiert, unveränderlich abgelegt ist und maschinell abfragbar bleibt. Eine SBOM, die nur im Build-Verzeichnis des letzten CI-Laufs liegt, hilft bei einer Schwachstelle in einer drei Jahre alten Version genau null.

Der erste Baustein ist die Erzeugung im Release-Prozess, nicht danach:

# .github/workflows/release.yml (Auszug)
- name: SBOM erzeugen und signieren
  run: |
    syft dir:. -o cyclonedx-json > sbom-${GITHUB_REF_NAME}.cdx.json
    cosign attest --type cyclonedx \
      --predicate sbom-${GITHUB_REF_NAME}.cdx.json \
      ghcr.io/acme/gateway:${GITHUB_REF_NAME}

- name: SBOM unveränderlich in die Release-Registry schreiben
  run: |
    curl -sSf -X POST "$SBOM_REGISTRY/api/releases" \
      -H "Authorization: Bearer $SBOM_TOKEN" \
      -F "product=acme-gateway" \
      -F "version=${GITHUB_REF_NAME}" \
      -F "shipped_at=$(date -u +%FT%TZ)" \
      -F "sbom=@sbom-${GITHUB_REF_NAME}.cdx.json"

Der zweite Baustein ist die Abfrage. Sie muss in Minuten beantworten, was sonst Tage kostet, und sie muss den Altbestand mit einschließen:

def betroffene_releases(cve_id: str) -> list[dict]:
    """Liefert die Datenbasis für die 24-Stunden-Frühwarnung
    und für die Nutzerinformation nach Art. 14 Abs. 8."""
    advisory = advisory_feed.get(cve_id)
    treffer = []

    for release in sbom_registry.alle_ausgelieferten_releases():
        for komponente in release["components"]:
            if komponente["purl"] not in advisory["affected_purls"]:
                continue
            if not version_betroffen(komponente["version"], advisory["ranges"]):
                continue

            treffer.append({
                "produkt": release["product"],
                "version": release["version"],
                "komponente": komponente["purl"],
                "eol": komponente.get("end_of_life", False),
                "patch_vorhanden": advisory.get("fixed_version") is not None,
                "nutzer": kundenregister.lookup(release["product"], release["version"]),
            })

    return treffer

Die letzten Felder im Rückgabewert sind die wichtigsten: Ein Treffer mit eol: true und patch_vorhanden: false bedeutet, dass die 14-Tage-Uhr des Abschlussberichts erst mit einer dokumentierten Risikominderungsmaßnahme zu laufen beginnt. Diese Maßnahme muss beschrieben, freigegeben und an die Nutzer kommuniziert werden. Das ist Arbeit, die man vor dem Vorfall erledigt oder gar nicht.

Praktisch bedeutet das drei Integrationen: die SBOM-Registry an den Release-Prozess, das Kundenregister an die Versionsstände, und beides an einen kontinuierlich beobachteten Advisory- und Exploit-Feed. Ohne die dritte Verbindung erfährst du von der Ausnutzung durch einen Kunden, und dann sind von den 24 Stunden schon zwölf weg.

Wer meldet an wen, und über welches Werkzeug?

Die Meldung erfolgt einmalig. Die Kommission formuliert es in ihrer Übersicht unmissverständlich: “Manufacturers report only once through the CRA Single Reporting Platform (SRP)” (Kommission, CRA reporting). Die Plattform leitet die Meldung gleichzeitig an den als Koordinator benannten CSIRT und an ENISA weiter (Art. 14 Abs. 1 und Abs. 3). Errichtet wird sie nach Art. 16 Abs. 1 von ENISA, die sie auch im Tagesbetrieb betreibt und wartet.

Zuständig ist der CSIRT des Mitgliedstaats deiner Hauptniederlassung. Der CRA definiert diese nicht über den Handelsregistereintrag, sondern über den Ort, an dem die Entscheidungen zur Cybersicherheit der Produkte überwiegend getroffen werden (Art. 14 Abs. 7). Für Hersteller aus Drittstaaten greift eine Kaskade: zuerst der Bevollmächtigte, dann der Importeur, dann der Händler, andernfalls der Mitgliedstaat mit den meisten Nutzern. Wer Entwicklung, Produktsicherheit und Geschäftsleitung über mehrere Länder verteilt hat, sollte diese Zuordnung schriftlich festhalten, bevor sie im Ernstfall bestritten wird.

Zwei Einschränkungen gehören dazu. Erstens ist die parallele Weitergabe an ENISA kein Automatismus: Nach Art. 16 kann ein CSIRT die Weiterverbreitung einer Meldung aus begründeten Cybersicherheitsgründen zurückhalten, insbesondere während einer laufenden koordinierten Offenlegung. Er muss ENISA dann unverzüglich über die Entscheidung, die Begründung und den geplanten Verbreitungszeitpunkt informieren (Art. 16). Zweitens ist die Liste der benannten Koordinator-CSIRTs nach Angaben von ENISA noch nicht veröffentlicht. Für Deutschland entwickelt das BSI parallel die Technische Richtlinie BSI TR-03183, um die CRA-Anforderungen für Hersteller und Produkte zu konkretisieren, und bringt sich in CEN, CENELEC und ETSI ein.

Der Zugang zur Plattform läuft über ein EU-Login-Konto. Die Bevollmächtigung wird laut ENISA nach dem ersten Plattformzugriff durch den benannten Koordinator-CSIRT validiert, und zwar parallel zum laufenden Meldeprozess. Praktisch heißt das: Das Konto sollte lange vor dem ersten Vorfall existieren.

Ein Detail, das man einplanen sollte: Der Fachdienst cyberresilienceact.eu stellte am 29. Juni 2026 fest, dass die Single Reporting Platform noch nicht live war, während ENISA Zugangs- und Registrierungsanleitungen, Schulungen und Probelaufmaterial für Juni 2026 zugesagt hatte. Ob sich das inzwischen geändert hat, lässt sich nicht verlässlich sagen. Die Fristen aus Artikel 14 gelten unabhängig von der Verfügbarkeit des Werkzeugs. Ein Meldeprozess, der ausschließlich auf ein Portal setzt, hat keinen Rückfallpfad.

Was in den verbleibenden Wochen organisatorisch stehen muss

Die technische Vorarbeit ist die eine Hälfte. Die andere ist eine Handvoll Festlegungen, die sich nicht kaufen lassen.

Der Rest ist Ablauf. Wer die Meldung, die interne Eskalation und die Nutzerinformation als eine durchgängig automatisierte Kette baut, spart im Ernstfall nicht Minuten, sondern die Stunden, die zwischen Kenntniserlangung und der ersten Managemententscheidung verloren gehen. Und er erzeugt nebenbei den Nachweis, wann wer was wusste, den man spätestens beim Abschlussbericht braucht.

Neu hinzugekommen ist ein Hilfsmittel: Die Kommission hat am 27. Juli 2026 ihre erste offizielle Anwendungsleitlinie zum CRA veröffentlicht, die Mitteilung C(2026) 5252 nebst Anhang, gestützt auf Art. 26 CRA. Sie behandelt unter anderem den Anwendungsbereich, die wesentliche Veränderung, den Unterstützungszeitraum sowie die Melde- und Risikobewertungspflichten, enthält 67 praktische Beispiele und richtet sich vorrangig an Kleinst- und mittlere Unternehmen (Kommission, 27.07.2026). Sie ist ausdrücklich unverbindlich, aber sie ist der beste verfügbare Anhaltspunkt dafür, wie die Aufsicht die offenen Begriffe auslegen wird.

Was das Versäumnis kostet

Art. 64 setzt den Rahmen. Verstöße gegen die Anforderungen aus Anhang I sowie gegen die Pflichten aus Art. 13 und Art. 14 sind mit Geldbußen bis zu 15 Millionen Euro oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahrs bedroht, je nachdem, welcher Betrag höher ist. Für weitere Verstöße liegt die Obergrenze bei 10 Millionen Euro oder 2 Prozent, für falsche oder unvollständige Angaben gegenüber Marktüberwachungsbehörden bei 5 Millionen Euro oder 1 Prozent (Art. 64).

Zwei Ausnahmen sind wichtig und werden häufig überlesen. Kleinst- und Kleinunternehmen sind von Geldbußen ausgenommen, wenn sie die 24-Stunden-Frühwarnung nach Art. 14 Abs. 2 lit. a oder Art. 14 Abs. 4 lit. a versäumen; die übrigen Fristen und Pflichten des Artikels 14 sind davon nicht erfasst. Open-Source-Software-Stewards sind von Geldbußen für Verstöße gegen die Verordnung ausgenommen. Beides entschärft die Frist in der Sanktion, nicht in der Pflicht. Wer die Meldung unterlässt, hat weiterhin gegen Artikel 14 verstoßen, mit allen marktaufsichtsrechtlichen Folgen, die daran hängen.

Wie die Pflicht durch die Lieferkette nach unten wandert

Die interessantere Durchsetzung findet ohnehin nicht über Bußgelder statt, sondern über Verträge. Honeywell betreibt eine öffentliche CRA-Lieferantenseite und verlangt dort von Lieferanten, bis zum 11. September 2026 funktionsfähige Schwachstellen- und Vorfallsmeldeprozesse einschließlich Registrierung auf der ENISA Single Reporting Platform vorzuhalten, bis zum vierten Quartal 2026 CRA-Compliance-Attestierungen oder detaillierte Fahrpläne für alle in EU-Produkte einfließenden Komponenten zu liefern und bis zum 11. Dezember 2027 volle CRA-Konformität inklusive Konformitätsbewertung, CE-Kennzeichnung und EU-Konformitätserklärung zu erreichen (Honeywell).

Das ist der Mechanismus, der die Frist real macht. Ein Zulieferer, der selbst unterhalb jeder Bußgeldschwelle liegt, verliert den Rahmenvertrag, wenn er die Attestierung nicht liefern kann.

Parallel formiert sich die Antwort im Open-Source-Bereich. Sieben Stiftungen, darunter Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation und Eclipse Foundation, kündigten am 2. April 2024 an, gemeinsame Spezifikationen für sichere Softwareentwicklung zur CRA-Umsetzung zu erarbeiten (Eclipse). Die daraus hervorgegangene Open Regulatory Compliance Working Group der Eclipse Foundation zählt inzwischen über 50 Mitglieder, darunter Microsoft, Red Hat, GitHub, Google, Nokia, Mercedes-Benz, ekxide und Open Source Matters, und hat am 14. August 2025 erste CRA-Ressourcen sowie einen Fahrplan für weitere Ergebnisse veröffentlicht (Eclipse Newsroom).

Was du diese Woche entscheiden musst

Die Verordnung stellt bis zum 11. September 2026 keine Frage nach der Qualität deiner Software. Sie stellt eine Frage nach der Reaktionsfähigkeit deiner Organisation: Kannst du innerhalb eines Arbeitstags sagen, ob eine aktiv ausgenutzte Schwachstelle in einem deiner ausgelieferten Produkte steckt, und kannst du die Betroffenen erreichen.

Diese Fähigkeit lässt sich auf drei Entscheidungen herunterbrechen. Erstens: eine Person mit Namen, die die Uhr startet, und eine Vertretung. Zweitens: eine SBOM pro ausgeliefertem Release, unveränderlich abgelegt, für den Altbestand rückwirkend erzeugt. Drittens: ein maschinenlesbarer Kanal zu den Nutzern, der nicht erst im Ernstfall gebaut wird.

Alles andere hat bis 2027 Zeit. Diese drei nicht. Wenn du wissen willst, wie diese Kette in einer bestehenden Produktlandschaft konkret aussieht, sprich mit uns.

Quellen

• Kommission: Cyber Resilience Act (Übersicht)
• Kommission: CRA reporting obligations
• Kommission: Anwendungsleitlinie C(2026) 5252, 27.07.2026
• ENISA: Single Reporting Platform
• BSI: Cyber Resilience Act
• CRA Art. 14 (Meldepflichten)
• CRA Art. 14, Volltext mit Absatzgliederung
• CRA Art. 16 (Single Reporting Platform, Vertraulichkeit)
• CRA Art. 64 (Sanktionen)
• CRA Art. 69 (Übergangsbestimmungen)
• CRA Art. 71 (Inkrafttreten und Geltung)
• VulnCheck: State of Exploitation, Auswertung für 2025, veröffentlicht 21.01.2026
• cyberresilienceact.eu: Single Reporting Platform noch nicht live, 29.06.2026
• Honeywell: EU Cyber Resilience Act, Lieferanteninformation
• Eclipse Foundation: Open Regulatory Compliance Working Group
• Eclipse Foundation: Sieben Stiftungen zu gemeinsamen CRA-Spezifikationen, 02.04.2024
• EUR-Lex: Verordnung (EU) 2024/2847