Es ist Donnerstag, 14:32 Uhr, und Petra Lechner – CTO der fiktiven Lechner-Hydraulik GmbH aus Schwäbisch Gmünd, 180 Mitarbeitende, vier Standorte, eigener Produktconfigurator und ein Kunden-Portal, das auf 17 Open-Source-Bibliotheken aufsetzt – sitzt vor einer E-Mail mit dem Betreff "Frage zu Ihrer Software-Stückliste". Absender ist der Einkauf eines bayerischen Automobil-Tier-1-Zulieferers. Anhang: ein dreiseitiges PDF mit 28 Pflichtangaben, davon zwölf rot markiert. Frist: vier Wochen. Petra weiß, dass das nicht der Anfang, sondern bereits das Mittelstadium einer Welle ist, die ab dem 11. September 2026 alle Hersteller von Software in Europa erfasst – auch jene, die sich bisher nicht als "Hersteller von Software" verstanden haben.

Wovon wir reden, wenn wir vom CRA reden

Der EU Cyber Resilience Act (Verordnung 2024/2847) ist im Dezember 2024 in Kraft getreten und gibt einen mehrstufigen Zeitplan vor. Drei Daten sollten in jeder Mittelstands-Roadmap stehen:

  • 11. September 2026 – Beginn der Meldepflichten. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden bei ENISA und der zuständigen nationalen Behörde melden, mit Folgeberichten nach 72 Stunden und 14 Tagen.
  • 11. Dezember 2027 – Vollanwendung. Ohne CE-Kennzeichnung darf kein "Produkt mit digitalen Elementen" mehr in der EU in Verkehr gebracht werden. SBOM, technische Dokumentation, Konformitätsbewertung und Lifecycle-Verpflichtungen sind dann zwingend.
  • Strafen: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes – je nachdem, was höher ist.

Was viele Mittelständler unterschätzen: Der CRA gilt nicht nur für Standardsoftware. Auch der Konfigurator, den die Lechner-Hydraulik aus React, einer Java-Backend-API und einem Postgres-Setup für ihre B2B-Kunden bereitstellt, ist ein "Produkt mit digitalen Elementen", sobald er in irgendeiner Form vermarktet wird – selbst eingebettet in eine Hardware-Lieferung. Selbst eine kostenlos abgegebene Konfigurator-App rutscht in den Anwendungsbereich, sobald sie kommerzieller Bestandteil eines Geschäftsmodells ist.

Die User Story: Wie Petras Team den September 2026 vorbereitet

Zurück zu Petra Lechner. Nach der Anfrage des Tier-1-Kunden ruft sie ihren Head of Engineering, Markus, in den Konferenzraum. Markus hat bereits zwei Open-Source-Tools auf der Liste: Syft für die SBOM-Generierung im CycloneDX-Format und Grype für die kontinuierliche Schwachstellen-Korrelation. "Das funktioniert in der Pipeline", sagt er. "Aber wir haben drei Probleme, die nicht technisch sind."

Problem 1: Der Konfigurator hat sechs Jahre Geschichte

Die Codebasis startete 2019 als Praktikantenprojekt. Niemand kann heute mit Sicherheit sagen, welche der eingebundenen Bibliotheken noch unterstützt werden, welche aktiv gepflegt sind und welche faktisch verwaist. Eine erste SBOM zeigt 287 transitive Dependencies, davon 11 mit bekannten kritischen CVEs. Für Petra ist die Diagnose unangenehm, aber wertvoll: Ohne SBOM hätte sie diesen Zustand bei einer Marktaufsicht nicht erklären können – und ein Tier-1-Audit hätte ihr Team in den nächsten Wochen unter Zeitdruck zur gleichen Erkenntnis gezwungen.

Problem 2: Die Meldekette ist unklar

Wer meldet im Ernstfall an wen? Markus' Team kennt die operativen Abläufe für interne Vorfälle, aber die 24-Stunden-Frist des CRA verlangt eine andere Logik: Sie startet, sobald der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erhält – nicht erst, wenn der eigene Betrieb betroffen ist. Das verschiebt die Verantwortung von der IT zum Produktmanagement, das oft keinen direkten Draht zu CSIRT-Strukturen hat. In Petras Fall heißt das konkret: Ein anonymer Bug-Bounty-Reporter, der eine Authentifizierungs-Lücke im Konfigurator findet und auf Twitter veröffentlicht, würde die Uhr genauso starten lassen wie ein interner Pentest-Befund.

Problem 3: Lieferanten-Verträge müssen nachziehen

Die Lechner-Hydraulik bezieht ihre Continuous-Integration-Plattform von einem deutschen SaaS-Anbieter, der wiederum AWS und ein paar Drittanbieter nutzt. Die bestehenden Verträge sehen weder eine SBOM-Klausel noch eine 24-Stunden-Informationspflicht vor. Petra weiß: Das ist nicht nur ihr Problem, sondern eine branchenweite Inkongruenz, die in den nächsten Monaten in Tausenden Verträgen nachverhandelt werden muss. Der Einkauf rollt mit den Augen, das Recht reibt sich die Hände – beides verständlich, beides wird Petras Roadmap kosten.

Technische Analyse: Was eine CRA-konforme SBOM wirklich enthalten muss

Die EU schreibt die Formate nicht endgültig fest, aber die "Implementing Acts" der Kommission und die Empfehlungen von ENISA konvergieren auf zwei De-facto-Standards: CycloneDX (OWASP Foundation) und SPDX (Linux Foundation). Beide sind maschinenlesbar, beide unterstützen Vulnerability Disclosure Reports (VDR/VEX), und beide werden von praktisch allen modernen Build-Werkzeugen erzeugt.

Die Mindestanforderungen für eine CRA-taugliche SBOM lassen sich auf sieben Felder pro Komponente reduzieren:

  1. Name der Komponente (z. B. "log4j-core")
  2. Version (semver oder Hersteller-eigene Versionierung)
  3. Hersteller oder Maintainer der Komponente
  4. Lizenz (SPDX-Identifier)
  5. Hash der Komponente (SHA-256 oder besser)
  6. PURL (Package URL) als eindeutiger Identifier
  7. Beziehung zur übergeordneten Komponente (Dependency-Tree)

Mehr verlangt der CRA nicht, aber weniger ist nicht ausreichend. Wichtig: Die SBOM muss top-level Dependencies abdecken; transitive Abhängigkeiten sind nicht zwingend dokumentationspflichtig, aber ohne sie bleibt die Sicherheitsanalyse stumpf. Wer eine SBOM nur als Compliance-Pflicht sieht, wird sie nicht nutzen. Wer sie als Inventarwerkzeug versteht, baut darauf einen Schwachstellen-Workflow auf, der NIS-2, ISO 27001 und ESG-Reporting gleichzeitig bedient.

Ein typischer CycloneDX-Eintrag sieht so aus:

{
  "type": "library",
  "name": "log4j-core",
  "version": "2.17.1",
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
  "hashes": [{ "alg": "SHA-256", "content": "5d36..." }],
  "licenses": [{ "license": { "id": "Apache-2.0" } }],
  "supplier": { "name": "Apache Software Foundation" }
}

Was hier nicht sichtbar, aber entscheidend ist: Diese SBOM muss bei jedem Build neu erzeugt und versioniert werden. Eine SBOM von vor sechs Monaten ist im Auditfall wertlos – sie spiegelt nicht den heutigen Zustand wider.

Wie sich CRA, NIS-2 und der EU AI Act verhaken

Mittelständler reiben sich die Augen, wenn sie den Regulierungs-Kalender betrachten. Drei Verordnungen, drei Geltungsbereiche, drei Auditlogiken – aber dieselbe Datenbasis. Wer in der eigenen IT keinen integrierten Ansatz fährt, wiederholt jede Inventarisierung, jede Risikoanalyse und jede Schulung dreimal. Die Compliance-Praxis 2026 verlangt deshalb eine zentrale Komponenten-, Risiko- und Vorfalldatenbank, aus der die unterschiedlichen Berichtsformate abgeleitet werden.

Beispiel: Eine kritische Schwachstelle in einer Open-Source-Bibliothek der Lechner-Hydraulik kann gleichzeitig …

  • … eine Meldung an die zuständige NIS-2-Aufsicht auslösen, wenn der Konfigurator als wesentliche Funktion eines KRITIS-Kunden gilt;
  • … eine CRA-Vorfallsmeldung an ENISA und das BSI auslösen, wenn die Schwachstelle aktiv ausgenutzt wird;
  • … ein EU-AI-Act-Logging erforderlich machen, wenn die Bibliothek in einem Hochrisiko-KI-System genutzt wird.

Drei Regelwerke, ein Vorfall. Wer das nicht mit einer einzigen Wahrheitsquelle verwaltet, verliert den Überblick – und produziert im Ernstfall widersprüchliche Meldungen, die später als Indiz für mangelnde Sorgfalt gegen das Unternehmen verwendet werden können.

Praktische Umsetzung in 90 Tagen

Die folgende Roadmap haben wir mit mehreren Mittelständlern in vergleichbaren Situationen durchgespielt. Sie ist kein Patentrezept, aber ein realistischer Pfad zwischen "schon spät" und "noch machbar".

Tag 1–14: Inventur und Sichtbarkeit

Erzeugen Sie für jedes vermarktete Software-Produkt eine erste SBOM. Tools wie Syft, Trivy oder kommerzielle Lösungen (z. B. Snyk, JFrog Xray, Anchore) können das in einer Pipeline weitgehend automatisieren. Ziel ist nicht Perfektion, sondern eine vollständige Liste, die als Diskussionsgrundlage taugt. In 14 Tagen weiß das Team, welche Dependencies es überhaupt gibt – und wo die kritischsten Risiken sitzen.

Konkreter Schritt: In einer typischen GitLab-CI-Pipeline ergänzen Sie einen Job vor dem Deployment:

sbom:
  stage: build
  script:
    - syft dir:. -o cyclonedx-json > sbom.json
    - grype sbom:sbom.json --fail-on critical
  artifacts:
    paths: [sbom.json]

Damit ist die SBOM Teil jedes Releases, und kritische Schwachstellen brechen den Build. Diese 15 Zeilen YAML sind in 80 Prozent der mittelständischen Pipelines die wirksamste Einzelmaßnahme der nächsten zwölf Monate.

Tag 15–45: Vulnerability-Workflow etablieren

Verbinden Sie die SBOM mit einem CVE-Feed (z. B. NVD, GitHub Advisory Database, OSV). Definieren Sie SLAs: Critical-CVEs werden binnen 7 Tagen, High-CVEs binnen 30 Tagen behandelt. Dokumentieren Sie die Entscheidungslogik – auch das "Wir patchen nicht, weil die Komponente nicht erreichbar ist" – als Vulnerability Exploitability Exchange (VEX) Statement. Das ist später Ihre Verteidigung gegenüber einer Marktaufsicht.

Ein VEX-Statement ist ein einfaches JSON, das pro Schwachstelle festhält, ob sie ausnutzbar ist und falls nicht, warum. Beispiel: "log4j-core 2.17.1 ist eingebunden, aber nur im Build-Prozess, nicht im ausgelieferten Artefakt – status: not_affected, justification: vulnerable_code_not_in_execute_path". Solche Aussagen sind die Brücke zwischen automatisierter SBOM und menschlicher Risiko-Beurteilung.

Tag 46–75: Meldekette konstruieren

Definieren Sie zwei Trigger: erstens "interner Vorfall" (klassisch IT/SOC), zweitens "Produktvorfall" (CRA). Für CRA-Vorfälle muss klar sein, wer binnen 24 Stunden ein erstes Statement an ENISA schickt – das ist in der Regel ein Mitglied der Geschäftsleitung oder ein dedizierter Product Security Officer. Hinterlegen Sie Vorlagen für die drei vorgeschriebenen Berichte (24h, 72h, 14 Tage) und üben Sie den Ablauf in einem Tabletop-Exercise.

Eine pragmatische Eskalationsmatrix für ein 180-Personen-Unternehmen: ein Slack-Channel "#cra-security", in dem jede Meldung sichtbar wird; ein RACI mit Petra (CTO) als Accountable, Markus (Head of Engineering) als Responsible, dem CISO als Consulted und dem CFO als Informed. Mehr Komplexität braucht es selten – mehr Klarheit dagegen schon.

Tag 76–90: Verträge und Lieferantendialog

Setzen Sie Standard-Klauseln in Lieferantenverträgen auf: SBOM-Pflicht, 24-Stunden-Informationspflicht bei kritischen Schwachstellen, Audit-Recht für Code-Reviews bei sicherheitskritischen Komponenten. Beginnen Sie mit den Top-10-Lieferanten – nicht mit allen 200. Eine vollständige Vertragsmigration über alle Lieferanten dauert 9–18 Monate; die Top-Lieferanten dürfen den September 2026 nicht ungeklärt erleben.

Was Petra Lechner heute anders macht

Drei Wochen nach der Anfrage des Tier-1-Kunden hat Petras Team die erste SBOM für den Konfigurator erzeugt – im CycloneDX-Format, automatisiert in der GitLab-Pipeline. Die elf kritischen CVEs sind auf vier reduziert; drei Bibliotheken wurden ersetzt, eine wurde gegen Risiko-Akzeptanz mit Kompensationskontrollen dokumentiert. Markus' Team hat eine Service-Account-Adresse für ENISA-Meldungen vorbereitet und die ersten zehn Lieferantenverträge für die Nachverhandlung markiert. Petra hat ihrem Vorstand letzte Woche im Quartalsbericht eine schlichte Zeile geschrieben: "CRA-Readiness: 64 Prozent, Plan-Stand 11. September 2026." Sie weiß, dass das nicht reicht. Aber sie weiß auch, dass sie nicht mehr blind ist – und das ist 2026 die wichtigste Voraussetzung dafür, dass aus einer Anfrage eines Tier-1-Kunden kein Auftragsverlust wird.

Drei Wochen später meldet sich der Tier-1-Einkauf erneut, diesmal mit einer Nachfrage zu drei Komponenten. Petra schickt das aktuelle SBOM-Diff, ein VEX-Statement zu zwei Komponenten und eine Roadmap für die dritte. Die Antwort kommt am nächsten Morgen: "Danke, das reicht uns." Der Auftrag bleibt.

Breitere Einordnung: Warum der CRA das Spielfeld neu sortiert

Der CRA ist die erste europäische Regulierung, die Hersteller-Sorgfaltspflichten für Software systematisch festlegt – mit einer Verschärfung, die bisher nur in der Medizinprodukte- und der Automobilbranche üblich war. Drei strategische Folgen lassen sich heute schon absehen:

Erstens, die Marktbereinigung. Anbieter, die ihre Lieferketten nicht dokumentieren können, verlieren ab 2027 ihre CE-Kennzeichnung. Das wird kleinere Open-Source-Projekte, die als kommerzielle Bestandteile vermarktet werden, vor existenzielle Fragen stellen – und verschiebt Wertschöpfung in Richtung jener Anbieter, die SBOM, VEX und SLA-Reporting industrialisiert haben.

Zweitens, die Verschiebung der Beweislast. Wer heute mit einem Standard-Verweis auf "wir patchen, sobald wir Zeit haben" durchgekommen ist, muss ab September 2026 begründen, warum eine Schwachstelle nicht innerhalb der definierten SLA behandelt wurde. Das ist eine kulturelle Veränderung, nicht nur eine technische. Sie verlangt Schulung, Prozesse und – nicht zuletzt – die Bereitschaft, "Wir sind nicht fertig" als legitime Antwort zu akzeptieren, solange sie dokumentiert ist.

Drittens, die Konvergenz mit dem AI Act. Hochrisiko-KI-Systeme nach EU AI Act benötigen ein Risikomanagement, das auf den gleichen technischen Daten aufsetzt wie die CRA-Dokumentation. Wer beides getrennt implementiert, wird die Auditkosten doppelt zahlen. Wer integriert, kann denselben SBOM-Datensatz für beide Zwecke nutzen – und reduziert seine Compliance-Kosten um etwa 30–40 Prozent, je nach Implementation. Auch hier gilt: Ein integrierter Ansatz zur KI-Strategie spart später Doppelarbeit.

Ausblick: Was nach September 2026 kommt

Die Meldepflicht ist erst der Anfang. Ab Dezember 2027 wird die Marktaufsicht – in Deutschland federführend das BSI – aktiv Stichproben prüfen. ENISA wird eine zentrale Datenbank für CRA-Vorfälle aufbauen, deren Kennzahlen vermutlich Eingang in die Cyber-Versicherungs-Prämienrechnung finden. Das heißt: Wer 2027 eine Cyber-Versicherung verlängert, wird neben der NIS-2-Compliance auch die CRA-Reife belegen müssen, andernfalls drohen entweder Prämiensprünge oder Deckungslücken.

Mittelfristig wird der CRA das Verhältnis zwischen Software-Anbieter und -Kunde transparenter machen. Heute kauft ein Mittelständler Software wie eine Black Box; ab 2027 kauft er ein Produkt mit dokumentierter Stückliste, vereinbartem Wartungszeitraum und festgelegten Reaktionsfristen. Das ist gut für die Sicherheit – und es ist gut für den Markt, weil es schlechten Anbietern den Wettbewerb erschwert.

Spätestens ab 2028 erwarten wir, dass Versicherer und Wirtschaftsprüfer SBOM-Reife als KPI in der Risikobewertung verlangen. Dann wird aus dem Compliance-Thema ein bilanzielles Thema – und damit ein Vorstandsthema. Wer heute investiert, hat 2028 nicht nur weniger Aufwand, sondern auch bessere Konditionen.

pleXtec-Empfehlung

Der CRA ist keine Aufgabe, die in der IT bleibt. Er verlangt Geschäftsleitung, Produktmanagement, Recht, Einkauf und IT in einem Raum. Wir empfehlen unseren Kunden, im zweiten Quartal 2026 zwei konkrete Schritte zu gehen: erstens eine SBOM-Pilotierung für ein zentrales Produkt mit anschließender Risikoanalyse, zweitens einen Tabletop-Workshop zur Meldekette, in dem der Ernstfall durchgespielt wird. Beides liefert in unter sechs Wochen belastbare Ergebnisse – und ersetzt das diffuse "wir müssen mal etwas tun" durch eine prüffähige Roadmap.

Wer dabei Unterstützung braucht – sei es bei der Pipeline-Integration der SBOM-Tools, bei der Risikoanalyse, beim Vertragsmuster für Lieferanten oder beim Tabletop-Setup – findet bei uns ein Team, das CRA, NIS-2 und EU AI Act gemeinsam denkt. Über das Kontaktformular erreichen Sie uns kurzfristig.

Petra Lechner hat noch knapp vier Monate. Mehr braucht es nicht – aber weniger reicht nicht.