--- title: "Cyber Resilience Act: Technische Produktsicherheit | SKAFFON" description: "CRA technisch umsetzen: SBOM, Schwachstellenprozess, Patch-Management und Meldekette nach Anhang I und Art. 14, zugeordnet zu Controls und Nachweisen." url: https://skaffon.de/cybersecurity/cra-software-sicherheit/ --- ![Ein Zahlenschloss liegt auf einer silbernen Computertastatur, Symbolbild für Cybersicherheit](/_astro/zahlenschloss-auf-tastatur.WknPzVph_zIVVL.jpg) 1. [Startseite](/) 2. [Cybersecurity](/cybersecurity/) 3. Cyber Resilience Act: Technische Produktsicherheit Cyber Resilience Act für Softwarehersteller # Cyber Resilience Act: Technische Produktsicherheit Aus Anhang I und Artikel 14 der Verordnung wird Pipeline-, Prozess- und Betriebsarbeit: SBOM, Schwachstellenprozess, signierte Updates und eine Meldekette, die 24-Stunden-Fristen hält. Für IT-Leitung, CTO und Produktverantwortliche. [Projekt anfragen](/projekt-anfragen/) [Zur Pflichten-Zuordnung](/cybersecurity/cra-software-sicherheit/#pflichten-zuordnung) - Meldepflichten nach Art. 14 gelten seit 11\. September 2026 - Technische Umsetzung, keine Rechtsberatung Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Rechtsstand, geprüft am 13\. November 2026 ## Drei Stichtage, einer davon ist schon vorbei Der CRA ist die [Verordnung (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Nach Artikel 71 gilt sie ab Dezember 2027, zwei Teile weichen davon ab. - 11.06.2026Kapitel IV gilt (Artikel 35 bis 51, Notifizierung von Konformitätsbewertungsstellen). - 11.09.2026Artikel 14 gilt: Hersteller müssen aktiv ausgenutzte Schwachstellen melden können, auch bei Produkten, die schon auf dem Markt sind. - 11.12.2027Allgemeine Geltung der Verordnung nach Artikel 71. ## Bußgelder und die Frage, ob Ihr Produkt überhaupt betroffen ist Verstöße gegen die wesentlichen Cybersicherheitsanforderungen aus Anhang I und gegen die Pflichten der Artikel 13 und 14 können nach [Artikel 64](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) mit Geldbußen von bis zu 15 Millionen Euro oder, bei Unternehmen, bis zu 2,5 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Die Mitgliedstaaten legen die konkreten Sanktionsregeln fest. Die einheitliche Meldeplattform nach Artikel 16 betreibt die ENISA. Nach den [FAQ der ENISA zur CRA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) ist sie seit dem 11\. September 2026 in Betrieb, dem Tag, ab dem Artikel 14 nach [Artikel 71 Absatz 2](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) gilt (Stand: 13.11.2026). Hersteller melden über das Portal mit einem EU-Login-Konto, wählen dabei das als Koordinator benannte CSIRT, und die Meldung geht gleichzeitig an dieses CSIRT und an die ENISA; in Deutschland ist das koordinierende CSIRT laut [BSI](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber%5FResilience%5FAct/Single%5FReporting%5FPlatform-CRA/single%5Freporting%5Fplatform-cra%5Fnode.html) das CERT-Bund im BSI. ### Zwei Anhaltspunkte aus dem Verordnungstext Ob der CRA Ihr Produkt betrifft, ist eine rechtliche Frage, die wir nicht beantworten. Für die Vorbereitung helfen zwei Stellen des Textes: - Nach Artikel 3 Nr. 1 ist ein „Produkt mit digitalen Elementen“ ein Software- oder Hardwareprodukt **einschließlich seiner Fernverarbeitungslösungen**. Fernverarbeitung ist die Datenverarbeitung auf Distanz, deren Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte (Artikel 3 Nr. 2). - Nach den Erwägungsgründen sind Cloud-Lösungen nur dann Fernverarbeitungslösungen im Sinne der Verordnung, wenn sie diese Definition erfüllen. Cloud-Dienste, die außerhalb der Verantwortung eines Herstellers eines Produkts mit digitalen Elementen entwickelt wurden, fallen nach den Erwägungsgründen nicht in den Anwendungsbereich; für Cloud-Computing-Dienste verweisen sie auf die NIS-2-Richtlinie (EU) 2022/2555. Einordnung gehört in die Rechtsberatung Für Ihre Einordnung brauchen Sie eine Rechtsberatung oder die Auskunft der zuständigen Behörden. Sobald das Ergebnis vorliegt, bestimmen wir mit Ihnen den technischen Scope. ## Wenn niemand belegen kann, was im Produkt steckt In diesen Lagen sprechen uns Unternehmen an: - Ein Produkt wird mit Software-Komponenten Dritter und Open-Source-Bibliotheken gebaut, aber niemand kann belegen, was genau darin steckt. - Schwachstellen werden bekannt, und der Weg von der Meldung bis zum ausgelieferten Update ist nicht definiert. - Es gibt keinen öffentlichen Meldeweg für Sicherheitslücken in Ihrem Produkt. - Die Geschäftsleitung hat die Artikel 13 und 14 gelesen und will wissen, was davon technisch schon da ist und was fehlt. ![Nahaufnahme eines Laptop-Bildschirms mit Quellcode in einem Code-Editor mit Dateibaum, im Dunkeln fotografiert](/_astro/quellcode-editor-bildschirm.4PnFuxcW_2c4eYj.jpg) Modular beauftragbar ## Von der Produktgrenze bis zur Übergabe an Ihr Team Sie können den Ablauf komplett oder ab einem beliebigen Schritt beauftragen. 1. 01 ### Scope festlegen Schritt 1 Wir legen fest, welche Produkte, Komponenten, Repositories, Build-Pipelines und Update-Wege betrachtet werden. Die rechtliche Einordnung bringen Sie mit. 2. 02 ### Gap-Analyse gegen den tatsächlichen Stand Schritt 2 Jede technische Anforderung aus Anhang I Teil II (Schwachstellenbehandlung) und die technisch prüfbaren Punkte aus Teil I (Produkteigenschaften) werden geprüft. Quelle sind Repositories, Pipeline-Konfigurationen, Registry-Inhalte und Interviews mit Ihren Entwicklerinnen und Entwicklern. 3. 03 ### Maßnahmenplan Schritt 3 Priorisierte, technisch konkrete Arbeitspakete mit Abhängigkeiten. 4. 04 ### Umsetzung in Pipeline und Betrieb Schritt 4 SBOM-Erzeugung und -Ablage, Schwachstellenscan, signierte Artefakte, Update-Verteilung, Meldekette, Veröffentlichung der Meldeadresse. Die Bausteine beschreibt die Seite [DevSecOps und sichere Software-Lieferketten](/cybersecurity/devsecops-supply-chain/). 5. 05 ### Nachweise ablegen Schritt 5 Konfigurationsstände, Pipeline-Läufe, SBOM-Beispiele und Runbooks werden so abgelegt, dass sie Ihre technische Dokumentation nach Artikel 31 und Anhang VII stützen. 6. 06 ### Übergabe oder laufender Betrieb Schritt 6 Übergabe an Ihr Team mit Einweisung; optional laufender Betrieb der Plattform über [Managed Services](/managed-services/). ## Welche CRA-Pflicht welches Control und welchen Nachweis verlangt Die Tabelle übersetzt die Schwachstellenbehandlung aus Anhang I Teil II und Artikel 14 in Arbeitspakete. Sie ist unsere fachliche Übersetzung des Verordnungstextes und keine amtliche Auslegung; verbindlich ist allein der [Text der Verordnung](https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Die Spalte „Bleibt bei Ihnen“ benennt, was kein Dienstleister für Sie übernehmen kann. __Zuordnung von CRA-Pflichten zu technischen Controls, Nachweis-Artefakten und Verantwortung__ | Pflicht (Anhang I Teil II, Art. 13/14) | Konkretes technisches Control | Nachweis-Artefakt | Bleibt bei Ihnen | | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Nr. 1: Schwachstellen und Komponenten identifizieren und dokumentieren, SBOM in gängigem maschinenlesbarem Format, mindestens oberste Abhängigkeiten | SBOM-Erzeugung pro Build (CycloneDX oder SPDX), Ablage zusammen mit dem Artefakt, Abgleich neuer Schwachstellenmeldungen gegen gespeicherte SBOMs | SBOM je Release, Abgleich-Protokoll | Welche Komponenten zu Ihrem Produkt zählen; Pflege der Produktgrenze | | Nr. 2: Schwachstellen ohne Verzug beheben, Sicherheitsupdates möglichst getrennt von Funktionsupdates | Branch- und Release-Modell mit separaten Sicherheits-Releases; Abhängigkeits-Updates automatisiert vorgeschlagen; Regel, welcher Schweregrad welche Frist auslöst | Release-Prozess-Beschreibung, Statistik der Behebungszeiten aus dem Ticketsystem | Festlegung der Fristen und Prioritäten aus Produktsicht | | Nr. 3: Wirksame und regelmäßige Tests und Überprüfungen der Sicherheit | Schwachstellenscan (Trivy) und Abhängigkeitsprüfung bei jedem Build, IaC-Prüfung, geplante Wiederholung für ausgelieferte Versionen | Scan-Berichte mit Datum, Pipeline-Konfiguration | Unabhängige Sicherheitstests und Penetrationstests (nicht Teil dieser Leistung) | | Nr. 4: Behobene Schwachstellen nach Update-Bereitstellung veröffentlichen | Vorlage und Ablauf für Sicherheitshinweise mit betroffenen Versionen, Schweregrad, Abhilfe; Ablage auf Ihrer Website oder im Portal | Veröffentlichungs-Runbook, Hinweis-Vorlage | Inhaltliche Freigabe jeder Veröffentlichung | | Nr. 5 und 6: Richtlinie zur koordinierten Offenlegung (CVD), Kontaktadresse für Meldungen | Technischer Betrieb des Meldekanals (Adresse, Verschlüsselung, Zuständigkeit), security.txt nach [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) auf Ihrer Website, interne Weiterleitung | Veröffentlichte CVD-Richtlinie, Test der Meldekette | Inhalt der Richtlinie, rechtliche Prüfung, benannte Ansprechperson (Art. 13 Abs. 17) | | Nr. 7 und 8: Updates sicher und möglichst automatisch verteilen, ohne Verzug und kostenlos mit Hinweisen | Signierte Artefakte (Cosign), Verifikation beim Ausrollen, definierter Update-Kanal; bei Produkten mit Auto-Update die Signaturprüfung im Client | Signatur- und Verifikationsprotokoll, Update-Architektur | Vertragliche Regelung zu Updates bei maßgeschneiderten Produkten | | Art. 13 Abs. 8 und 9: Support-Zeitraum, Verfügbarkeit der Updates | Technische Vorhaltung der Update-Artefakte für den Support-Zeitraum, Archivierung von Build-Metadaten | Archiv-Konzept, Aufbewahrungsregel | Festlegung des Support-Zeitraums (mindestens fünf Jahre, bei kürzer erwarteter Nutzung entsprechend kürzer) | | Art. 14: Meldung aktiv ausgenutzter Schwachstellen und schwerer Vorfälle | Technische Anbindung: Alarmierungsweg, Zeitstempel ab Kenntnis, Vorlage mit den geforderten Angaben, Rollen für Rufbereitschaft | Meldekette-Runbook, Übungsprotokoll | Die Meldung selbst, die Entscheidung, ob ein Fall meldepflichtig ist | Aus Teil I (Produkteigenschaften) betreffen mehrere Punkte direkt den Entwicklungs- und Betriebsprozess, zum Beispiel: keine bekannten ausnutzbaren Schwachstellen bei Marktbereitstellung, sichere Standardkonfiguration, Aktualisierbarkeit, Zugriffsschutz, Verschlüsselung gespeicherter und übertragener Daten, Datenminimierung, Begrenzung der Angriffsfläche und Protokollierung relevanter Aktivitäten. Welche davon für Ihr Produkt gelten, folgt aus Ihrer Cybersicherheits-Risikobewertung nach Artikel 13 Absatz 2; sie ist Aufgabe des Herstellers. Wir übersetzen das Ergebnis in Konfiguration und Prüfungen. ## 24 Stunden, 72 Stunden, 14 Tage: die Meldekette auf einer Zeitachse Die Fristen laufen ab dem Moment, in dem Sie von der Ausnutzung einer Schwachstelle Kenntnis erhalten. Darunter die technische Spur, die sie einhaltbar macht. Meldekette nach Art. 14 CRA, technische Sicht, keine Rechtsauskunft. Meldekette nach Art. 14 CRA, technische Sicht, keine Rechtsauskunft. ## Runbook: Was in den ersten Stunden nach Kenntnis passiert Artikel 14 Absatz 1 und 2 verlangt eine Meldung über die zentrale Meldeplattform (Artikel 16) gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA. Der Ablauf zeigt, welche technische Vorbereitung die Fristen überhaupt einhaltbar macht. 1. 01 ### Kenntnis feststellen und festhalten Sofort Eingang über den CVD-Kanal, Monitoring oder Dritte; sofort Zeitstempel und Ticket anlegen. Ohne belegbaren Startzeitpunkt sind Fristen nicht prüfbar. 2. 02 ### Erstbewertung über die SBOMs Minuten Betroffene Produkte und Versionen über die gespeicherten SBOMs bestimmen. Das beantwortet in Minuten, ob die Komponente in Auslieferungsständen steckt. 3. 03 ### Frühwarnung 24 Stunden Nach Art. 14 Abs. 2 Buchst. a unverzüglich, spätestens 24 Stunden nach Kenntnis, mit Angabe der Mitgliedstaaten, in denen das Produkt bereitgestellt wurde. 4. 04 ### Schwachstellenmeldung 72 Stunden Nach Buchst. b: allgemeine Produktangaben, Art des Exploits und der Schwachstelle, getroffene und für Nutzer mögliche Abhilfemaßnahmen. 5. 05 ### Abschlussbericht 14 Tage nach Abhilfe Nach Buchst. c spätestens 14 Tage nach Verfügbarkeit einer Abhilfe: Beschreibung der Schwachstelle mit Schweregrad und Auswirkung, soweit bekannt Angaben zu Angreifern, Details zum Sicherheitsupdate. 6. 06 ### Update bauen, signieren, verteilen Parallel Anschließend wird nach Anhang I Teil II Nr. 4 die Information veröffentlicht. ## Die Technik bereiten wir vor, die Meldung unterzeichnen Sie Für schwere Vorfälle mit Auswirkung auf die Produktsicherheit nennt Artikel 14 Absatz 3 und 4 dieselbe Staffelung. Wir üben den Ablauf mit Ihrem Team als Tischübung; die Meldung unterzeichnet und verantwortet Ihr Unternehmen. [Meldekette gemeinsam üben](/projekt-anfragen/) ## Austauschbare Bausteine, ausgewählt nach Ihrer Pipeline Die Wahl richtet sich nach Ihrer vorhandenen Pipeline und Ihren Souveränitätsanforderungen. Die Referenzpipeline mit allen Stufen steht auf [DevSecOps und sichere Software-Lieferketten](/cybersecurity/devsecops-supply-chain/); hier geht es um die Frage, welche CRA-Pflicht welchen Baustein verlangt. SBOM - Erzeugung im Build - CycloneDX - SPDX - Ablage mit dem Artefakt Schwachstellenscan - Trivy für Images - Trivy für Abhängigkeiten - Trivy für IaC-Dateien Signierung und Herkunft - Cosign für Signatur - Cosign für Attestierungen - SLSA Build-Track als Orientierung Schwachstellenprozess - Ticket-Workflow - Fristen nach Schweregrad - Veröffentlichungsvorlage - CVD-Kanal Patch-Management - Automatisierte Abhängigkeits-Updates - Release-Kanäle - Archivierung für den Support-Zeitraum Herkunftsnachweise orientieren sich am Build-Track von [SLSA](https://slsa.dev/spec/v1.0/levels). Welche SLSA-Stufe wir zusagen, belegen wir mit der Provenance aus Ihrer Pipeline. ## Vier Rollen, klar getrennt: Wer im CRA-Projekt was verantwortet - ### Ihre Geschäftsleitung und Produktverantwortung Einordnung als Hersteller, Risikobewertung nach Artikel 13, Festlegung des Support-Zeitraums, Entscheidung über Meldungen, Konformitätsbewertung nach Artikel 32, EU-Konformitätserklärung und CE-Kennzeichnung. - ### Ihre Rechtsberatung Anwendungsbereich, Rolle (Hersteller, Importeur, Händler), Sanktionsrisiko, Inhalt der CVD-Richtlinie. - ### Benannte Stellen und Prüfer Unabhängige Bewertung, soweit das Verfahren sie vorsieht. - ### SKAFFON Analyse, Planung und Umsetzung der technischen Controls, Nachweis-Artefakte, Übung der Meldekette, Übergabe oder Betrieb. ## Was wir für den Start von Ihnen brauchen - Lesender Zugriff auf Repositories, CI/CD-Konfiguration, Registries und Release-Prozess. - Ihre Einordnung (Produktliste, Rolle, Anwendungsbereich) und, falls vorhanden, bestehende Dokumentation zur Produktsicherheit. - Eine entscheidungsbefugte Person für Prioritäten und Fristen. - Verfügbarkeit von Entwicklungsteams für Rückfragen und Abnahmen. ## Technische Umsetzung ja, Rechtsurteil und Zertifikat nein Den Aufwand bestimmen vor allem die Anzahl der Produkte und Repositories, die Zahl der Build-Pipelines und Sprachen oder Ökosysteme (Container, Pakete, Firmware), der Reifegrad von Automatisierung und Dokumentation, die Tiefe der Umsetzung (nur Analyse, Analyse mit Umsetzung oder Umsetzung mit Betrieb) und die Frage, ob Hardware- oder Embedded-Komponenten einbezogen sind. Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang. ### In Pipeline und Betrieb setzen wir um - Die technische Umsetzung der Anforderungen aus Anhang I und Artikel 14. - Die Artefakte, die Ihre technische Dokumentation und Ihre Konformitätsbewertung stützen. - Übergabe an Ihr Team oder optional laufender Betrieb. ### Bei Ihnen, Ihrer Kanzlei oder Prüfern bleibt - Rechtsberatung oder ein Gutachten zur Betroffenheit. Das übernimmt eine Kanzlei. - Konformitätsbewertung, CE-Kennzeichnung, Zertifikat oder Konformitätsbescheinigung. - Unabhängige Penetrationstests oder einen Sicherheitsbetrieb (SOC) als eigenständige Leistung. - Reine Richtlinien und Dokumente ohne technische Umsetzung. ## Häufige Fragen Können Sie bestätigen, dass unser Produkt CRA-konform ist? Nein. Wir setzen technische Anforderungen um und dokumentieren den Stand. Die Konformitätsbewertung liegt bei Ihnen und, soweit vorgesehen, bei einer benannten Stelle. Gilt der CRA auch für interne Software, die wir nur selbst betreiben? Der Verordnungstext spricht von Produkten, die auf dem Markt bereitgestellt werden. Die Einordnung Ihres Falls gehört zur rechtlichen Klärung. Was ist früher fällig als die allgemeine Geltung ab Dezember 2027? Artikel 14 mit den Meldepflichten gilt bereits seit dem 11\. September 2026\. Die SBOM- und Schwachstellenprozess-Arbeit ist die Voraussetzung dafür, dass diese Meldungen überhaupt belastbar möglich sind. ## Produkt, Pipeline und Ziel beschreiben, den Scope klären wir Schildern Sie Ihr Produkt und Ihre Pipeline, wir klären den technischen Scope. Weiterführend: [Cybersecurity-Überblick](/cybersecurity/) und [NIS2-Beratung](/cybersecurity/nis2-beratung/). [Projekt anfragen](/projekt-anfragen/) [Cybersecurity im Überblick](/cybersecurity/)