CRA-Meldepflicht ab 11.9.2026 technisch umsetzen

Die CRA-Meldepflicht trifft Hersteller von Produkten mit digitalen Elementen ab dem 11. September 2026: 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. Gemeldet wird nach Art. 14 Abs. 1 CRA gleichzeitig an das koordinierende CSIRT und an die ENISA, über eine einzige Einreichung.

Was ab dem 11. September 2026 konkret gilt

Artikel 14 der Verordnung (EU) 2024/2847 gilt ab dem 11. September 2026, die übrigen Herstellerpflichten erst ab dem 11. Dezember 2027. Die Meldepflicht kommt also fünfzehn Monate vor allem anderen, was einen Hersteller trifft. Wer auf die volle Anwendbarkeit wartet, hat die erste Frist bereits verpasst.

Ein drittes Datum geht dabei regelmässig unter: Kapitel IV zu den notifizierten Stellen (Artikel 35 bis 51) gilt schon seit dem 11. Juni 2026. Es betrifft die Konformitätsbewertungsstellen, nicht Sie als Hersteller.

Zwei Auslöser, zwei Fristenketten:

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 wer Ihre Gegenstelle ist

Die Meldung hat zwei Empfänger und wird trotzdem nur einmal abgesetzt. Artikel 14 Absatz 1 CRA verpflichtet den Hersteller, eine aktiv ausgenutzte Schwachstelle gleichzeitig dem als Koordinator benannten CSIRT und der ENISA zu melden. Für schwerwiegende Sicherheitsvorfälle sagt Absatz 3 dasselbe.

Der technische Weg ist einer. Nach Artikel 14 Absatz 7 CRA läuft die Meldung über den Meldeendpunkt des CSIRT, das im Mitgliedstaat der Hauptniederlassung als Koordinator benannt ist, und ist gleichzeitig für die ENISA zugänglich. Die Kommission fasst das auf ihrer Seite zu den CRA-Meldepflichten so: „Manufacturers report only once through the CRA Single Reporting Platform (SRP)”.

Wer zurückfragt, ist das CSIRT. Nach Artikel 14 Absatz 6 kann es einen Zwischenbericht verlangen, und es validiert vorab Ihren Zugang zur Plattform. Die ENISA baut und betreibt sie. Wer wissen will, bei wem er im Ernstfall anruft: beim CSIRT der Hauptniederlassung.

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. Sie können 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 Ihrer 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.

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 Sie bauen müssen, damit 24 Stunden reichen

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

1. 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.
2. 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.
3. 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.
4. Ein Incident-Log mit UTC-Zeitstempeln. Sie müssen nicht nur fristgerecht melden, Sie müssen 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. Als Übung ist das ein 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@v7

      - uses: docker/login-action@v4
        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@v4
        with:
          cosign-release: v3.1.3

      - name: SBOM in beiden Formaten erzeugen
        run: |
          syft registry:"$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@v7
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.*.json
          retention-days: 90       # GitHubs Maximum, deshalb nur ein Puffer

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 Ihre 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. Dieselbe Disziplin verlangt das revDSG für Personendaten; wie ein Audit-Log aussieht, das eine Auskunftsanfrage übersteht, haben wir separat beschrieben.

{"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 Ihnen liegt. Wer das Prinzip vertiefen will, findet es in Observability, die man liest und in Architektur-Entscheidungen dokumentieren ausgeführt.

Was Sie jetzt nicht tun sollten

Kaufen Sie kein Compliance-Tool, bevor Sie die Meldekette einmal an einer echten Schwachstelle durchgespielt haben. 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 Ihnen 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 Sie nicht tun sollten: 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 übrigen Herstellerpflichten werden erst am 11. Dezember 2027 anwendbar. Kapitel IV zu den notifizierten Stellen gilt bereits seit dem 11. Juni 2026.

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 brauchen Sie 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 Sie als Hersteller eines EU-Produkts und meint dessen Schwachstellen. Die ISG-Meldepflicht adressiert Sie als Betreiberin kritischer Infrastruktur und meint Angriffe auf Ihre eigenen Systeme. Ein Ransomware-Vorfall in Ihrem 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. Protokollieren Sie 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 Sie in der Hand haben.

---

Wenn die Kette noch nicht steht. Bis zum 11. September bleiben zwei Wochen, bis zur ersten realistischen Meldung vermutlich länger. Wenn Sie wissen wollen, ob Ihre 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 Sie bauen. Wir sagen Ihnen, wo wir die Frist reissen sehen.

Alle Rechtsangaben geprüft am 19.08.2026 an EUR-Lex und Fedlex. Dieser Beitrag beschreibt die technische Umsetzung, er ist keine Rechtsberatung.