CRA-Meldepflicht ab 11.9.2026 technisch umsetzen

Die CRA-Meldepflicht gilt ab dem 11. September 2026: Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen binnen 24 Stunden vorläufig melden, binnen 72 Stunden vollständig, den Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmassnahme. Die Meldung läuft über die CRA Single Reporting Platform an das CSIRT des Mitgliedstaats der Hauptniederlassung. ENISA erhält sie gleichzeitig, ist nicht die Adressatin.

Was ab dem 11. September 2026 konkret gilt

Artikel 14 der Verordnung (EU) 2024/2847 gilt ab dem 11. September 2026, der Rest des Cyber Resilience Act erst ab dem 11. Dezember 2027. Die Meldepflicht kommt also fünfzehn Monate vor allen anderen Herstellerpflichten. Wer auf die volle Anwendbarkeit wartet, hat die erste Frist bereits verpasst.

Zwei Auslöser, zwei Fristenketten:

Auslöser	Frühwarnung	Meldung	Abschlussbericht
Aktiv ausgenutzte Schwachstelle im Produkt	24 h ab Kenntnis	72 h ab Kenntnis	14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemassnahme
Schwerwiegender Sicherheitsvorfall	24 h ab Kenntnis	72 h ab Kenntnis	ein Monat nach der Vorfallmeldung

Die Frist läuft ab Kenntnis, nicht ab Bestätigung. Wer intern erst eine Freigaberunde dreht, verbrennt die Hälfte des Budgets. Verstösse gegen Artikel 13 und 14 sind nach Artikel 64 Absatz 2 CRA mit Bussgeldern bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes bewehrt, je nachdem, was höher ist.

Gilt der Cyber Resilience Act für Schweizer Unternehmen?

Ja, sobald ein Produkt mit digitalen Elementen in der EU in Verkehr gebracht wird. Der Sitz in Kreuzlingen, Zug oder Zürich ändert daran nichts. Interessant wird nur, an welches CSIRT ein Hersteller ohne Niederlassung in der Union meldet.

Artikel 14 Absatz 7 CRA löst das über eine Kaskade: massgeblich ist der Mitgliedstaat, in dem der Bevollmächtigte für die meisten Produkte sitzt. Fehlt der, der Einführer. Fehlt auch der, der Händler. Bleibt das offen, entscheidet der Mitgliedstaat mit den meisten Nutzern.

Das ist eine Architekturentscheidung, keine juristische Fussnote. Wer heute nicht weiss, welches nationale CSIRT zuständig ist, registriert sich am 11. September nicht mehr rechtzeitig.

Wohin die Meldung geht, und an wen nicht

Die Meldung geht an das CSIRT, nicht an ENISA. Das wird im deutschsprachigen Feld regelmässig falsch dargestellt.

Die Kommission formuliert auf ihrer Seite zu den CRA-Meldepflichten unmissverständlich: „Manufacturers report only once through the CRA Single Reporting Platform (SRP)“, adressiert an das CSIRT des Mitgliedstaats der Hauptniederlassung. ENISA baut und betreibt die Plattform und erhält die Information gleichzeitig. Adressatin ist sie nicht.

Für die Umsetzung sind drei Details aus der ENISA-FAQ zur SRP (Stand 3. August 2026) wichtiger als jede Rechtsfrage:

Es gibt vorerst keine API. Ihr könnt den Weg bis zum Absenden automatisieren, das Absenden selbst tippt ein Mensch in ein Browserformular.
Die Registrierung läuft über EU Login (ecas.ec.europa.eu), die Validierung anschliessend über das zuständige CSIRT. Beides dauert und gehört vor den Ernstfall.
Die Plattform war Mitte August 2026 noch nicht live, die öffentliche URL noch nicht publiziert. Betriebsbereit soll sie zum 11. September sein.

Der letzte Meter eurer Kette ist also manuell. Umso wichtiger, dass die neunundvierzig Meter davor es nicht sind.

Zwei Behörden werden dabei regelmässig falsch einsortiert. Das BSI ist seit Oktober 2025 notifizierende und marktüberwachende Behörde für den CRA in Deutschland. Marktüberwachung ist aber nicht Meldungsentgegennahme.

Und das BACS ist im CRA-Kontext gar keine Adresse. Es ist die Adressatin der Schweizer ISG-Meldepflicht, eines eigenen Regimes mit eigener Rechtsgrundlage. Wer beides zusammenwirft, meldet an der falschen Stelle.

CRA-Meldepflicht und Schweizer ISG-Meldepflicht nebeneinander

Zwei Regime, zwei Adressaten, zwei Rechtsgrundlagen, beide mit einer 24-Stunden-Frist. Ein Schweizer Softwarehersteller, der in die EU liefert und dessen Produkte von Schweizer kritischen Infrastrukturen genutzt werden, fällt unter beide. Wir haben die Gegenüberstellung gebaut, weil wir sie nirgends gefunden haben. Jede Zeile ist am Gesetzestext belegt.

	CRA (EU)	ISG-Meldepflicht (CH)
Rechtsgrundlage	VO (EU) 2024/2847, Art. 14	ISG (SR 128), Art. 74a bis 74h
Gilt seit	11.09.2026	01.04.2025, Sanktionen ab 01.10.2025
Wer meldet	Hersteller von Produkten mit digitalen Elementen	Betreiberinnen kritischer Infrastrukturen, darunter Herstellerinnen von Hard- oder Software mit Fernwartungszugang (Art. 74b Abs. 1 lit. u)
Auslöser	aktiv ausgenutzte Schwachstelle im Produkt oder schwerwiegender Vorfall	Cyberangriff auf die eigenen Informatikmittel nach vier Kriterien (Art. 74d)
Gegenstand	das ausgelieferte Produkt	der eigene Betrieb
Adressat	CSIRT des Mitgliedstaats der Hauptniederlassung, ENISA parallel	BACS
Kanal	CRA Single Reporting Platform, EU-Login-Konto, keine API	Meldeformular im Cyber Security Hub des BACS, alternativ E-Mail-Formular
Erstmeldung	24 h ab Kenntnis	24 h ab Entdeckung (Art. 74e Abs. 1)
Zweite Stufe	72 h	keine
Abschluss	14 Tage nach Verfügbarkeit der Korrektur, bei Vorfällen ein Monat	14 Tage zur Vervollständigung
Nutzer informieren	ja, Art. 14 Abs. 8, möglichst maschinenlesbar	nicht vorgesehen
Extraterritorial	ja, über Inverkehrbringen in der EU	ja, für Angriffe mit Auswirkung in der Schweiz, auch bei Systemen im Ausland (Art. 74b Abs. 3)
Sanktion	bis 15 Mio. EUR oder 2,5 % Weltjahresumsatz (Art. 64 Abs. 2)	Busse bis CHF 100’000 gegen natürliche Personen, subsidiär bis CHF 20’000 gegen den Geschäftsbetrieb (Art. 74h)
Durchsetzung	Marktüberwachungsbehörden der Mitgliedstaaten	BACS setzt Frist, erlässt dann eine Verfügung mit Strafdrohung; Verfolgung durch die Kantone (Art. 74g)

Der interessanteste Unterschied steht in der letzten Zeile. Der CRA sanktioniert das Versäumnis direkt. Das ISG sanktioniert es nicht: Nach Art. 74g ISG setzt das BACS zuerst eine Frist, erlässt dann eine Verfügung, und erst deren vorsätzliche Missachtung ist nach Art. 74h strafbar.

Dieselbe indirekte Konstruktion kennen wir aus dem revDSG, wo der EDÖB ebenfalls keine direkte Sanktionskompetenz hat. Wer die ISG-Meldepflicht deshalb für zahnlos hält, übersieht Art. 74h Abs. 1: Die Busse trifft natürliche Personen, nicht die GmbH.

Die Zahlen dazu kommen vom BACS selbst. Im Halbjahresbericht 2025/2 (publiziert 30.03.2026) verarbeitete das Amt 145 meldepflichtige Cybervorfälle im zweiten Halbjahr 2025, verteilt auf öffentlichen Sektor (25 %), IT und Telekommunikation (18 %) sowie Finanz und Versicherung (15,7 %). Daneben 64’733 freiwillige Meldungen im Gesamtjahr.

Was ihr bauen müsst, damit 24 Stunden reichen

Vier Artefakte müssen fertig sein, bevor die Uhr läuft. Keines lässt sich im Vorfall improvisieren.

Eine SBOM pro Release, unveränderlich gespeichert. Anhang I Teil II Nummer 1 CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten abdeckt. Das ist der Rechtsboden, nicht das Ziel: Wer bei transitiven Abhängigkeiten aufhört zu schauen, findet Log4Shell-Klassen nicht.
Eine rückwärtsgerichtete Auskunft. Die Frage im Ernstfall lautet nicht „ist die Bibliothek verwundbar“, sondern „welche ausgelieferten Versionen enthalten sie und wer betreibt die“. Das muss eine Abfrage sein, keine Rekonstruktion.
Ein Alarmpfad mit benannter Person. Nicht „das Security-Team“, sondern ein Name und eine Stellvertretung, mit Zugriff auf das registrierte EU-Login-Konto. Am Sonntag um drei.
Ein Incident-Log mit UTC-Zeitstempeln. Ihr müsst nicht nur fristgerecht melden, ihr müsst es belegen können.

Fünf Jahre Support, ab dem 11. Dezember 2027

Artikel 13 Absatz 8 CRA legt den Unterstützungszeitraum auf mindestens fünf Jahre fest, kürzer nur, wenn das Produkt erwartbar kürzer im Einsatz ist. Fünf Jahre Security-Updates heissen fünf Jahre lauffähige Build-Pipeline für jeden noch unterstützten Release-Zweig. Das ist die teuerste Pflicht des ganzen CRA, und sie steht in keiner Meldefrist.

Wer nicht sicher ist, ob die eigene Kette von der Detektion bis zum abgesendeten Formular innerhalb eines Arbeitstags trägt, sollte sie einmal an einer echten, bereits behobenen Schwachstelle durchspielen und dabei mitstoppen. Wir machen das mit Kunden an einem Nachmittag. Was auffällt, ist selten das Werkzeug und fast immer die Übergabe zwischen zwei Personen.

SBOM in der Pipeline: ein Aufbau, der rückwirkend Auskunft gibt

Die SBOM gehört an den Image-Digest gebunden, nicht an den Tag. Tags werden überschrieben, Digests nicht. Der folgende Workflow erzeugt beide gängigen Formate, prüft gegen CVE-Feeds und signiert das Ergebnis keyless über OIDC. Versionen vom August 2026: Syft v1.51.0, Grype v0.117.0, cosign v3.1.3.

# .github/workflows/release.yml
name: release
on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write
  id-token: write            # keyless signing, kein Schlüsselmaterial im Repo

jobs:
  sbom:
    runs-on: ubuntu-24.04
    env:
      IMAGE: ghcr.io/${{ github.repository }}
    steps:
      - uses: actions/checkout@v5

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Bauen, pushen, Digest festhalten
        run: |
          docker build -t "$IMAGE:$GITHUB_REF_NAME" .
          docker push "$IMAGE:$GITHUB_REF_NAME"
          DIGEST=$(docker buildx imagetools inspect "$IMAGE:$GITHUB_REF_NAME" \
                     --format '{{ .Manifest.Digest }}')
          echo "REF=$IMAGE@$DIGEST" >> "$GITHUB_ENV"

      - name: Werkzeuge auf feste Versionen pinnen
        run: |
          curl -sSfL https://get.anchore.io/syft  | sh -s -- -b /usr/local/bin v1.51.0
          curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin v0.117.0

      - uses: sigstore/cosign-installer@v3
        with:
          cosign-release: v3.1.3

      - name: SBOM in beiden Formaten erzeugen
        run: |
          syft "$REF" \
            -o cyclonedx-json=sbom.cdx.json \
            -o spdx-json=sbom.spdx.json

      - name: Gegen CVE-Feeds prüfen, Build bei Kritischem stoppen
        run: grype "sbom:sbom.cdx.json" --fail-on critical

      - name: SBOM an den Digest binden und signieren
        run: cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$REF"

      - uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.*.json
          retention-days: 3650     # über den Unterstützungszeitraum hinaus

Der upload-artifact-Schritt ist die schwächste Stelle und bewusst so gelassen: Produktiv gehören die SBOMs in einen Objektspeicher mit Versionierung und Object Lock, abfragbar nach Komponente. GitHub-Artefakte sind ein Zwischenschritt, kein Archiv. Mehr dazu in unserer Arbeit an CI/CD und Supply Chain.

Das Incident-Log, das eure Frist belegt

Ein Incident-Log ist kein Ticket-Verlauf, sondern ein append-only Ereignisstrom mit UTC-Zeitstempeln. NDJSON reicht, eine Zeile pro Ereignis, ts immer zuerst. Entscheidend ist der maschinell festgehaltene Zeitpunkt der Kenntnisnahme, den niemand später aus einer Slack-Historie rekonstruieren muss.

{"ts":"2026-09-14T07:12:41Z","event":"aware","incident":"INC-2026-0007","cve":"CVE-2026-31337","product":"acme-gateway","affected_versions":["3.4.0","3.4.1"],"component":"pkg:golang/github.com/example/parser@1.8.2","evidence":"WAF-Signatur 8841, 3 Treffer aus 2 Quell-ASN","actively_exploited":true,"detected_by":"grype-nightly+SIEM","owner":"r.segi"}
{"ts":"2026-09-14T07:41:02Z","event":"triaged","incident":"INC-2026-0007","regime":["cra","isg"],"cra_trigger":"actively_exploited_vulnerability","due_early_warning":"2026-09-15T07:12:41Z","due_notification":"2026-09-17T07:12:41Z","csirt":"NCSC-NL","owner":"r.segi"}
{"ts":"2026-09-14T09:03:55Z","event":"reported","incident":"INC-2026-0007","channel":"eu-srp","stage":"early_warning","reference":"SRP-2026-114872","elapsed_h":1.85,"submitted_by":"r.segi"}
{"ts":"2026-09-14T10:26:33Z","event":"reported","incident":"INC-2026-0007","channel":"ch-bacs-csh","stage":"erstmeldung","reference":"BACS-2026-3391","elapsed_h":3.23,"submitted_by":"r.segi"}
{"ts":"2026-09-14T11:48:07Z","event":"users_informed","incident":"INC-2026-0007","format":"csaf-2.0","url":"https://acme.example/security/ACME-SA-2026-004"}

Die Fristen im triaged-Ereignis werden gerechnet, nicht getippt. Das ist eine Funktion, kein Kalendereintrag:

// Fristen nach Art. 14 CRA, gerechnet ab Kenntnisnahme in UTC.
type Deadlines struct {
	EarlyWarning time.Time // 24 h ab Kenntnis
	Notification time.Time // 72 h ab Kenntnis
	Final        time.Time // 14 Tage nach Verfügbarkeit der Korrekturmassnahme
}

func CRADeadlines(awareAt, fixAvailableAt time.Time) Deadlines {
	awareAt = awareAt.UTC()
	return Deadlines{
		EarlyWarning: awareAt.Add(24 * time.Hour),
		Notification: awareAt.Add(72 * time.Hour),
		Final:        fixAvailableAt.UTC().AddDate(0, 0, 14),
	}
}

Warum der Aufwand für ein Log, das hoffentlich nie gebraucht wird: Weil im Streitfall die Beweislast bei euch liegt. Wer das Prinzip vertiefen will, findet es in Observability, die man liest und in Architektur-Entscheidungen dokumentieren ausgeführt.

Was ihr jetzt nicht tun solltet

Kauft kein Compliance-Tool, bevor ihr die Meldekette einmal an einer echten Schwachstelle durchgespielt habt. Bei dieser Empfehlung bekommen wir am häufigsten Widerspruch, und wir bleiben dabei.

Der Markt für CRA-Plattformen ist seit Frühjahr 2026 laut, und die Produkte lösen fast alle dasselbe Problem: Sie erzeugen Dokumente. Das Problem, das euch die Frist reisst, ist die Stunde zwischen „ein Alert ist aufgelaufen“ und „jemand mit Zugang hat entschieden, dass das meldepflichtig ist“.

Der Trade-off, ehrlich benannt: Ein Werkzeug ist in zwei Wochen eingekauft, die Probe kostet einen Nachmittag plus die Korrekturen danach. Wer im September 2026 noch gar nichts hat, fährt mit gekauftem Werkzeug plus Probe besser.

Wo unsere Empfehlung nicht passt: Bei mehr als einer Handvoll Produktlinien mit unterschiedlichen Bevollmächtigten in der EU wird „welches Produkt meldet an welches CSIRT“ zur Datenhaltungsfrage. Dann ist ein Werkzeug ab Tag eins richtig. Bei einem Produkt und einem CSIRT ist es Geldverbrennung.

Das Zweite, was ihr nicht tun solltet: die Registrierung auf den Ernstfall verschieben. EU Login anlegen, CSIRT bestimmen, Validierung anstossen. Ein Vormittag, und die einzige Aufgabe, die sich am 11. September nicht nachholen lässt.

Häufige Fragen

Ab wann gilt die CRA-Meldepflicht?

Ab dem 11. September 2026, über Artikel 14 der Verordnung (EU) 2024/2847. Dann laufen drei Fristen: 24 Stunden bis zur Frühwarnung, 72 Stunden bis zur vollständigen Meldung, 14 Tage nach Verfügbarkeit einer Korrekturmassnahme bis zum Abschlussbericht, bei Vorfällen ein Monat. Die übrige Verordnung wird erst am 11. Dezember 2027 anwendbar.

Wer muss nach dem CRA melden?

Der Hersteller des Produkts mit digitalen Elementen, unabhängig vom Sitz, sobald das Produkt in der EU in Verkehr gebracht wird. Meldepflichtig sind aktiv ausgenutzte Schwachstellen im Produkt und schwerwiegende Sicherheitsvorfälle, die dessen Sicherheit beeinträchtigen. Bestandsprodukte sind eingeschlossen. Zusätzlich müssen betroffene Nutzer informiert werden, nach Artikel 14 Absatz 8 möglichst in einem strukturierten, maschinell verarbeitbaren Format.

Was ist eine SBOM und wofür brauche ich sie?

Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Inventar aller Komponenten eines Software-Artefakts, üblicherweise im Format CycloneDX oder SPDX. Der CRA verlangt sie in Anhang I Teil II Nummer 1 mindestens für die Top-Level-Abhängigkeiten. Praktisch braucht ihr sie, um innerhalb von Stunden zu beantworten, welche ausgelieferten Versionen eine gerade bekannt gewordene verwundbare Komponente enthalten.

Muss ein Schweizer Unternehmen doppelt melden?

Möglicherweise ja, aber an verschiedene Stellen und aus verschiedenen Gründen. Der CRA adressiert euch als Hersteller eines EU-Produkts und meint dessen Schwachstellen. Die ISG-Meldepflicht adressiert euch als Betreiberin kritischer Infrastruktur und meint Angriffe auf eure eigenen Systeme. Ein Ransomware-Vorfall in eurem Build-System kann beides gleichzeitig auslösen.

Was passiert, wenn die Single Reporting Platform am 11. September nicht läuft?

Die Meldepflicht entsteht aus Artikel 14, nicht aus der Verfügbarkeit der Plattform. Mitte August 2026 war die SRP noch nicht live und ihre URL noch nicht publiziert. Protokolliert den Zeitpunkt der Kenntnisnahme und jeden Zustellversuch, samt Vermerk, wenn eine Einreichung technisch nicht möglich war. In dieser Lage ist ein lückenloses Log das einzige, was ihr in der Hand habt.

Wenn die Kette noch nicht steht. Bis zum 11. September bleiben wenige Tage, bis zur ersten realistischen Meldung vermutlich länger. Wenn ihr wissen wollt, ob eure Kette von der Detektion bis zum abgesendeten Formular trägt: 30 Minuten mit einem Engineer, der SBOM-Pipelines gebaut und in regulierten Umgebungen wie dem Formularservice für das BIT gearbeitet hat. Kein Verkaufsgespräch, keine Folien.

Termin direkt buchen oder kurz über Kontakt schreiben, was ihr baut. Wir sagen euch, wo wir die Frist reissen sehen.