Cyber Resilience Act für Softwarehersteller: SBOM, Schwachstellenprozess und 24-Stunden-Meldung praktisch aufsetzen

Die Meldepflichten gelten bereits seit dem 11.09.2026. Dieser Leitfaden zeigt, wie Sie SBOM, Schwachstellenprozess und Meldung so aufsetzen, dass sie im Alltag funktionieren.

Gilt der CRA für meine Software?

Der CRA erfasst Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden: Software und Hardware samt Firmware, ob eigenständig verkauft oder als Teil eines Geräts. Auch Desktop-Programme, mobile Apps und Bibliotheken, die Sie kommerziell vertreiben, fallen darunter. Das gilt auch für Hersteller außerhalb der EU, deren Produkte in der EU verkauft werden.

Drei Grenzfälle sollten Sie genau prüfen:

• Open Source: Freie Software, die außerhalb einer Geschäftstätigkeit entwickelt wird, ist nicht erfasst. Wer Open Source in ein kommerzielles Produkt einbaut, ist für das ganze Produkt verantwortlich, auch für die übernommenen Komponenten.
• Reines SaaS: Ein Dienst, der nur im Browser läuft und nicht Teil eines Produkts ist, fällt in der Regel nicht unter den CRA, kann aber unter NIS2 fallen. Gehört eine Cloud-Funktion fest zu einem Produkt, etwa die Steuerung eines Geräts per App, ist sie Teil dieses Produkts.
• Wichtige und kritische Produkte: Für bestimmte Produktklassen, etwa Passwortmanager, VPN, Firewalls oder Betriebssysteme, gelten strengere Verfahren der Konformitätsbewertung.

Eine erste Einschätzung für Ihr Unternehmen gibt der kostenlose Betroffenheits-Check.

Seit 11.09.2026: Melden innerhalb von 24 Stunden

Seit dem 11.09.2026 müssen Hersteller zwei Arten von Ereignissen melden (Art. 14 CRA), und zwar auch für Produkte, die schon vor diesem Tag auf dem Markt waren:

• aktiv ausgenutzte Schwachstellen in ihrem Produkt,
• schwerwiegende Sicherheitsvorfälle, die die Sicherheit des Produkts beeinträchtigen.

Die Meldung geht über die zentrale Meldeplattform der ENISA an das zuständige CSIRT. Sie läuft in Stufen:

Die Uhr läuft ab dem Zeitpunkt, an dem Sie Kenntnis erlangen, nicht ab dem Ende Ihrer Analyse. Zusätzlich informieren Sie die betroffenen Nutzer Ihres Produkts über die Schwachstelle oder den Vorfall und über Maßnahmen, die sie selbst ergreifen können.

Welche Fristen in Ihrem Fall gelten, rechnet der kostenlose CRA-Meldefristen-Rechner aus.

Die Meldefrist beginnt mit der Kenntnis. Bereiten Sie den Ablauf vor dem ersten Fall vor.

Ab 11.12.2027: alle übrigen Pflichten

Ab dem 11.12.2027 dürfen nur noch Produkte auf den Markt, die alle Anforderungen des CRA erfüllen:

• Grundlegende Anforderungen (Anhang I): sichere Voreinstellungen, Schutz vor unbefugtem Zugriff, Sicherheitsupdates, Schwachstellenbehandlung über die Supportzeit.
• Technische Dokumentation: Risikobewertung, Beschreibung des Produkts, SBOM, Nachweise der Prüfungen.
• Konformitätsbewertung: für die meisten Produkte als Selbstbewertung, für wichtige und kritische Produkte mit strengeren Verfahren, teils durch eine benannte Stelle.
• EU-Konformitätserklärung und CE-Kennzeichnung.
• Supportzeit: Sie legen fest, wie lange Sie Sicherheitsupdates liefern, in der Regel mindestens fünf Jahre.

Die Zeit bis dahin klingt lang. Für ein Produkt mit mehreren Releases im Jahr sind es aber nur wenige Entwicklungszyklen.

SBOM in der Praxis

Eine Software-Stückliste (SBOM) listet alle Komponenten Ihres Produkts mit Version und Herkunft. Der CRA verlangt sie ausdrücklich (Anhang I Teil II Nr. 1 CRA), und sie gehört zur technischen Dokumentation.

Format. Etabliert sind CycloneDX und SPDX. Die BSI TR-03183-2 (Version 2.1.0) akzeptiert CycloneDX ab Version 1.6 und SPDX ab Version 3.0.1.

Tiefe. Mindestens die direkten Abhängigkeiten, besser auch die transitiven. Eine SBOM, die nur die oberste Ebene zeigt, hilft bei der nächsten Schwachstelle in einer tief eingebundenen Bibliothek nicht weiter.

Aktualität. Erzeugen Sie die SBOM bei jedem Release automatisch im Build, nicht einmal im Jahr von Hand. Jede ausgelieferte Version braucht ihre eigene SBOM.

Verknüpfung. Eine SBOM entfaltet ihren Nutzen erst, wenn Sie sie mit Schwachstellendaten abgleichen: Welche meiner ausgelieferten Versionen enthält die betroffene Komponente?

Eine SBOM nützt nur, wenn sie aktuell ist und mit Schwachstellendaten verknüpft wird.

Schwachstellen behandeln: der Ablauf

1. Eingang: Schwachstellen erreichen Sie aus Datenbanken wie CVE, aus Hinweisen Ihrer Zulieferer, über Ihre Meldeadresse oder aus eigenen Tests. Veröffentlichen Sie eine Kontaktadresse und eine Richtlinie zur koordinierten Offenlegung.
2. Bewertung: Ist Ihr Produkt betroffen, in welchen Versionen, wie schwer? Wird die Schwachstelle aktiv ausgenutzt? Dann läuft die 24-Stunden-Frist.
3. Korrektur: Sicherheitsupdate entwickeln, testen, ausliefern. Wo möglich getrennt von Funktionsupdates.
4. Hinweis: Behobene Schwachstellen veröffentlichen Sie mit Beschreibung, betroffenen Versionen, Schweregrad und Abhilfe, maschinenlesbar zum Beispiel als CSAF.
5. Kundeninformation: Betroffene Nutzer erfahren, was sie tun sollen, und Sie können später zeigen, dass Sie informiert haben.

Rollen und Bereitschaft

Klären Sie vor dem ersten Fall, wer was tut:

• Wer meldet? Eine benannte Person mit Vertretung, die Zugang zur Meldeplattform hat.
• Wer entscheidet? Ob eine Schwachstelle aktiv ausgenutzt wird oder ein Vorfall schwerwiegend ist, entscheidet jemand mit Befugnis, auch am Wochenende.
• Wer informiert Kunden? Produktmanagement, Support oder Kommunikation, mit abgestimmten Textbausteinen.

Viele Hersteller bündeln diese Aufgaben in einem Product Security Incident Response Team (PSIRT). In kleinen Teams genügen zwei bis drei Personen mit klaren Zuständigkeiten und einer erreichbaren Bereitschaft.

CRA-Arbeit ist Produktarbeit. Sie gehört in den Release-Prozess, nicht in ein jährliches Audit.

So unterstützt Complass

• CRA-Regelwerk: Anforderungen Schritt für Schritt, mit Erklärungen und Vorlagen.
• SBOM je Produkt: Export als CycloneDX 1.6 und SPDX 3.0.1.
• Schwachstellenmanagement: mit CVE-Daten, CSAF-Hinweisen und Herstellerhinweisen, abgeglichen mit Ihren Produkten.
• Vorfälle mit Fristen: Complass verfolgt die Fristen nach Art. 14 Abs. 1 und Abs. 3 CRA, nach NIS2 und nach DSGVO und bereitet die Inhalte vor. Die Meldung selbst geben Sie über die Meldeplattform ab.
• CRA-Sicherheitshinweise und PSIRT: Hinweise schreiben, als CSAF veröffentlichen, an Ihre Nutzer senden und den Versand belegen.
• Kostenloser CRA-Meldefristen-Rechner auf unserer Website, ohne Anmeldung.

Demo anfragen CRA-Meldefristen berechnen

Checkliste

• Geprüft, welche Produkte unter den CRA fallen und in welche Klasse.
• Meldeverantwortliche Person mit Vertretung benannt, Zugang zur Meldeplattform geklärt.
• Ablauf für die 24-Stunden-Frühwarnung beschrieben und einmal geübt.
• Kontaktadresse und Richtlinie zur koordinierten Offenlegung veröffentlicht.
• SBOM wird bei jedem Release automatisch erzeugt, in CycloneDX oder SPDX.
• SBOM wird laufend mit Schwachstellendaten abgeglichen.
• Sicherheitshinweise werden maschinenlesbar veröffentlicht (z. B. CSAF).
• Nutzer können über Schwachstellen und Vorfälle informiert werden.
• Supportzeit je Produkt festgelegt.
• Plan für technische Dokumentation und Konformitätsbewertung bis 11.12.2027 steht.

Fristen auf einen Blick

Weiterlesen

• Whitepaper „Cyber Resilience Act für Hersteller von Hardware und Software“
• Whitepaper „Secure Development für Hersteller“
• Whitepaper „Wenn es passiert ist: Meldepflichten nach NIS2, CRA und DSGVO in einem Ablauf“
• CRA-Meldefristen-Rechner

Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall.