Warum der Cyber Resilience Act alles verändert

Am 3. März 2026 hat die Europäische Kommission den finalen Leitfaden zur Umsetzung des Cyber Resilience Act (CRA) veröffentlicht. Damit wird erstmals ein horizontaler Rechtsrahmen geschaffen, der alle Produkte mit digitalen Elementen auf dem EU-Binnenmarkt erfasst – von Firmware über Standalone-Software bis hin zu Cloud-basierten Datenverarbeitungslösungen. Anders als bisherige sektorspezifische Regelungen (NIS-2 für Betreiber, DORA für Finanzdienstleister) richtet sich der CRA direkt an Hersteller und Importeure.

Die Tragweite ist enorm: Schätzungen gehen davon aus, dass über 90 % aller Softwareprodukte in die Default-Kategorie fallen und damit einer Selbstbewertung unterliegen. Doch auch die Selbstbewertung erfordert erhebliche technische und organisatorische Maßnahmen. Die ersten harten Deadlines greifen bereits ab September 2026 – wer jetzt nicht handelt, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.

Zeitplan: Die vier kritischen Meilensteine

Der CRA tritt nicht auf einen Schlag in Kraft, sondern folgt einem gestaffelten Zeitplan. Für Entwicklungsteams und IT-Entscheider sind vier Daten entscheidend:

  1. August 2026: Meldepflicht für Konformitätsbewertungsstellen – relevant für Hersteller von Produkten der Klassen I und II, die eine Drittprüfung benötigen.
  2. 11. September 2026: Die Vulnerability Reporting Obligation greift. Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden an die zuständige CSIRT-Behörde melden – mit einem vollständigen Bericht innerhalb von 72 Stunden.
  3. Oktober 2026: Konformitätsbewertung für bestimmte Produktkategorien muss abgeschlossen sein.
  4. Dezember 2027: Vollständige Anwendbarkeit aller CRA-Anforderungen für alle Produktkategorien.

Die vier Risikokategorien: Wo steht Ihr Produkt?

Der CRA klassifiziert Produkte anhand ihres Risikoprofils in vier Stufen. Die Einstufung bestimmt, welches Konformitätsbewertungsverfahren angewendet werden muss:

  • Default-Kategorie (~90 % aller Produkte): Selbstbewertung durch den Hersteller reicht aus. Beispiele: Standard-Business-Software, mobile Apps, Bibliotheken ohne sicherheitskritische Funktion.
  • Important Class I: Selbstbewertung möglich, wenn harmonisierte europäische Normen (hEN) angewendet werden; andernfalls Drittprüfung. Beispiele: Passwort-Manager, Firewalls, VPN-Software, SIEM-Systeme.
  • Important Class II: Zwingend Drittprüfung durch eine notifizierte Stelle. Beispiele: Betriebssysteme, Hypervisoren, Container-Runtimes, Public-Key-Infrastruktur, Hardware-Security-Module (HSM).
  • Critical Products: Europäisches Zertifizierungsschema erforderlich. Beispiele: Smartcard-Chips, sichere Elemente in Kryptowährungswallets.

Für die meisten deutschen Mittelständler, die B2B-Software entwickeln, gilt die Default-Kategorie. Das ist keine Entwarnung – die technischen Anforderungen der Selbstbewertung sind substanziell.

Security by Design: Die sechs Kernpflichten

Der CRA kodifiziert erstmals verbindliche Essential Cybersecurity Requirements. Die folgenden Pflichten müssen in den Softwareentwicklungsprozess integriert werden:

1. Cybersecurity Risk Assessment

Vor der Markteinführung muss ein formales Cybersecurity-Risiko-Assessment durchgeführt und dokumentiert werden. Dies umfasst die Identifikation aller Angriffsvektoren (Netzwerk, lokaler Zugriff, Supply Chain), eine Bewertung der Auswirkungen bei Kompromittierung und die Definition risikoangemessener Gegenmaßnahmen. Das Assessment muss über den gesamten Supportzeitraum des Produkts aktualisiert werden.

2. Secure Default Configuration

Produkte müssen in einer sicheren Standardkonfiguration ausgeliefert werden. Konkret bedeutet das: Keine hartcodierten Default-Credentials, kein offener Debug-Port, keine unnötigen Netzwerkschnittstellen. Jede Konfigurationsänderung durch den Nutzer muss auf eine sichere Baseline zurücksetzbar sein.

3. Schutz vor unbefugtem Zugriff

Authentifizierungs- und Autorisierungsmechanismen sind Pflicht. Das schließt die sichere Speicherung von Credentials (z. B. via Key Derivation Functions wie Argon2id), verschlüsselte Kommunikation (TLS 1.3 als Minimum) und den Schutz gespeicherter Daten ein.

4. Software-Update-Mechanismus

Jedes Produkt muss einen sicheren, automatisierbaren Update-Mechanismus bereitstellen. Updates müssen kryptografisch signiert und über sichere Kanäle verteilt werden. Der Hersteller verpflichtet sich, Sicherheitsupdates über den gesamten erwarteten Produktlebenszyklus bereitzustellen – mindestens jedoch fünf Jahre.

5. Vulnerability Handling Process

Hersteller müssen einen koordinierten Vulnerability-Disclosure-Prozess implementieren. Das bedeutet: Eine öffentlich erreichbare Meldestelle (z. B. security.txt nach RFC 9116), definierte Reaktionszeiten, eine interne Triage-Struktur und die Fähigkeit, Patches zeitnah bereitzustellen.

6. Technische Dokumentation und CE-Kennzeichnung

Die technische Dokumentation muss das Cybersecurity-Risiko-Assessment, die implementierten Schutzmaßnahmen, den Supportzeitraum und die Software Bill of Materials (SBOM) umfassen. Erst nach Abschluss der Konformitätsbewertung darf das CE-Zeichen angebracht werden.

SBOM: Das technische Herzstück der CRA-Compliance

Die Software Bill of Materials ist das zentrale Artefakt der CRA-Compliance. Sie dokumentiert alle Komponenten eines Softwareprodukts – inklusive Open-Source-Bibliotheken, transitiver Abhängigkeiten und deren Lizenzen. Der CRA verlangt die SBOM als Teil der technischen Dokumentation, die den Marktüberwachungsbehörden auf Anfrage vorgelegt werden muss.

SBOM-Formate: CycloneDX vs. SPDX

In der Praxis haben sich zwei Formate etabliert:

  • CycloneDX (OWASP): Leichtgewichtiges JSON/XML-Format, speziell für Security-Anwendungsfälle konzipiert. Unterstützt nativ Vulnerability-Referenzen (VEX) und Service-Dependency-Mapping. Empfohlen für Teams, die Security-First denken.
  • SPDX (Linux Foundation / ISO 5962): Umfassenderes Format mit starkem Fokus auf Lizenz-Compliance. Seit 2021 ISO-Standard. Besser geeignet, wenn neben Security auch License-Compliance ein Haupttreiber ist.

Integration in die CI/CD-Pipeline

Manuelle SBOM-Erstellung ist bei agilen Release-Zyklen nicht praktikabel. Die Generierung muss automatisiert in der Build-Pipeline erfolgen. Ein beispielhafter Workflow:


# GitHub Actions – SBOM Generation + Vulnerability Check
name: CRA Compliance Pipeline
on:
  push:
    branches: [main, release/*]

jobs:
  sbom-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # SBOM generieren mit Syft
      - name: Generate SBOM (CycloneDX)
        uses: anchore/sbom-action@v0
        with:
          format: cyclonedx-json
          output-file: sbom.cdx.json

      # Schwachstellen-Scan gegen SBOM
      - name: Vulnerability Scan (Grype)
        uses: anchore/scan-action@v4
        with:
          sbom: sbom.cdx.json
          fail-build: true
          severity-cutoff: high

      # SBOM als Build-Artefakt archivieren
      - name: Archive SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom.cdx.json
          retention-days: 1825  # 5 Jahre Aufbewahrung

Entscheidend ist die Aufbewahrungsfrist: Der CRA verlangt, dass die technische Dokumentation mindestens zehn Jahre nach Inverkehrbringen des Produkts verfügbar ist. Die SBOM sollte daher nicht nur als CI-Artefakt, sondern in einem dedizierten Archiv (z. B. einem S3-Bucket mit Object Lock) versioniert gespeichert werden.

Vulnerability Disclosure: Von der Meldepflicht zur Infrastruktur

Ab September 2026 besteht eine Meldepflicht für aktiv ausgenutzte Schwachstellen. Das ist kein reiner Compliance-Formalismus, sondern erfordert eine funktionierende technische Infrastruktur:

  • Externe Meldestelle: Eine /.well-known/security.txt nach RFC 9116 auf der Produktwebsite. Dort definiert: Kontaktadresse, PGP-Schlüssel, bevorzugte Sprachen, Anerkennungsrichtlinie.
  • Internes Triage-System: Eingehende Meldungen müssen klassifiziert werden (CVSS 4.0 Scoring), False Positives müssen aussortiert, und für bestätigte Findings muss ein CVE über eine CNA (CVE Numbering Authority) beantragt werden.
  • Meldekette zur CSIRT: Innerhalb von 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle muss eine Erstmeldung an die zuständige nationale CSIRT erfolgen. In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) zuständig. Innerhalb von 72 Stunden folgt der vollständige Bericht mit betroffenen Versionen, Angriffsvektor und Mitigationsmaßnahmen.

Open Source: Sonderregelungen und der "Open-Source Steward"

Ein häufiges Missverständnis: Der CRA betrifft nicht nur kommerzielle Software. Die Abgrenzung ist differenzierter:

  • Exempt: Nicht-kommerziell entwickelte und vertriebene Open-Source-Software fällt nicht unter den CRA. Das betrifft den klassischen Hobby-Entwickler, der eine Bibliothek auf GitHub veröffentlicht.
  • Erfasst: Sobald OSS kommerziell genutzt wird – sei es durch bezahlten Support, SaaS-Angebote oder Einbettung in ein kommerzielles Produkt – gelten die CRA-Pflichten für den kommerziellen Verwender (nicht für den ursprünglichen OSS-Autor).
  • Open-Source Steward: Für Stiftungen und Organisationen, die dauerhaft kritische OSS-Projekte pflegen (z. B. Apache Foundation, Eclipse Foundation), führt der CRA eine neue Rolle ein. Stewards müssen eine Cybersecurity-Policy veröffentlichen und mit Marktüberwachungsbehörden kooperieren, unterliegen aber nicht der vollen Konformitätsbewertung.

Für Entwicklungsteams bedeutet das: Jede Open-Source-Abhängigkeit in Ihrer SBOM muss auf ihre Herkunft, Wartungsintensität und bekannte Schwachstellen geprüft werden. Tools wie scorecard (OpenSSF) bewerten die Sicherheitsreife von OSS-Projekten automatisiert.

Zusammenspiel mit NIS-2, DORA und dem EU AI Act

Der CRA existiert nicht im Vakuum. Für viele Unternehmen entsteht ein komplexes regulatorisches Geflecht:

  • NIS-2 (seit Dezember 2025 in Deutschland): Betrifft Betreiber wesentlicher und wichtiger Einrichtungen. Wenn Sie Software herstellen und selbst als Betreiber unter NIS-2 fallen, müssen Sie beide Regelwerke erfüllen. Der CRA regelt die Produktsicherheit, NIS-2 die Betriebssicherheit.
  • DORA (seit Januar 2025): Für den Finanzsektor gelten zusätzliche Anforderungen an die digitale Betriebsstabilität. CRA-konforme Produkte erleichtern die DORA-Compliance für Finanzdienstleister erheblich.
  • EU AI Act: KI-Systeme, die als "Hochrisiko" eingestuft sind, unterliegen sowohl dem AI Act als auch dem CRA. Die Cybersecurity-Anforderungen beider Verordnungen müssen kumulativ erfüllt werden.

Praktische Roadmap für Entwicklungsteams

Basierend auf unserer Beratungserfahrung empfehlen wir folgende priorisierte Schritte:

  1. Sofort (März–April 2026): Produktklassifizierung durchführen. In welche CRA-Risikokategorie fallen Ihre Produkte? Dokumentieren Sie die Begründung.
  2. Q2 2026: SBOM-Generierung in die CI/CD-Pipeline integrieren. Vulnerability-Scanning automatisieren. security.txt auf allen Produktwebsites bereitstellen.
  3. Bis August 2026: Vulnerability-Handling-Prozess formalisieren: Triage-Team benennen, CVSS-Scoring-Kompetenz aufbauen, Meldekette zum BSI testen.
  4. Bis September 2026: Meldepflicht-Infrastruktur operativ bereit. Erste Vulnerability-Reports probeweise durchspielen.
  5. Q4 2026 – Q2 2027: Vollständige technische Dokumentation erstellen. Cybersecurity-Risiko-Assessment für alle Produkte abschließen. CE-Konformitätserklärung vorbereiten.

Der Cyber Resilience Act ist kein bürokratisches Hindernis – er ist eine Chance, Security Engineering als messbaren Qualitätsstandard in der europäischen Softwareentwicklung zu verankern. Wer jetzt die technischen Grundlagen legt, verschafft sich nicht nur Compliance, sondern einen echten Wettbewerbsvorteil.