Cyber Resilience Act 2026: Was Hersteller jetzt entscheiden müssen

Warum die CRA jetzt auf die Geschäftsführungs-Agenda gehört

Wenn Ihr Unternehmen ein vernetztes Produkt vertreibt — eine Maschine mit Cloud-Anbindung, ein IoT-Sensor, eine App, ein Backend, eine SaaS-Plattform mit Kunden in der EU — dann legt die EU-Verordnung 2024/2847, der Cyber Resilience Act (CRA), fest, was Ihr Produkt ab 11.12.2027 erfüllen muss, um auf dem EU-Markt bleiben zu dürfen. Es geht nicht um eine technische Detailfrage. Es geht um Markt-Zulassung, Haftung und Strafmaß bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes.

Die Verordnung ist am 10.12.2024 in Kraft getreten und entfaltet ihre Wirkung in drei Stufen. Die Meldepflichten nach Artikel 14 greifen ab dem 11.09.2026 — das sind, beim Erscheinen dieses Texts, gut sechzehn Monate. Volle Anwendbarkeit aller Anforderungen folgt am 11.12.2027. Die Entscheidungen, die Sie als Geschäftsführung, IT-Leitung oder Produktverantwortliche:r 2026 treffen, bestimmen, ob Sie zum Stichtag liefern oder unter Zeitdruck nachrüsten. Beides ist möglich. Eines ist deutlich teurer.

Dieser Artikel beschreibt, was die CRA tatsächlich verlangt — Stand der konsolidierten Fassung in EUR-Lex und der ergänzenden Q&A der EU-Kommission — und macht klar, welche Entscheidungen jetzt auf den Tisch gehören und welche Investitionen sich daraus ableiten. Kein juristischer Leitfaden. Eine Entscheidungs-Handreichung für die Verantwortlichen — und die technische Tiefe, mit der Sie die Aufwandsschätzungen Ihres Entwicklungs-Teams einordnen können.

Was die CRA tatsächlich verlangt

Die CRA legt horizontale Cybersicherheitsanforderungen für „Produkte mit digitalen Elementen“ fest, die auf dem EU-Markt bereitgestellt werden. Der Geltungsbereich ist breit: Hardware mit Software, eigenständige Software, Komponenten — alles, was über eine Daten- oder Netzwerkverbindung mit anderen Geräten oder Netzen kommunizieren kann oder dafür gedacht ist.

Wesentliche Anforderungen aus Anhang I

Anhang I der Verordnung gliedert sich in zwei Teile. Teil I beschreibt Produkteigenschaften — Sicherheit ab Entwurf und Standardeinstellung, minimaler Angriffspunkt, Schutz vor unbefugtem Zugriff, Vertraulichkeit gespeicherter und übertragener Daten, Integrität von Code, gespeicherten Daten und Konfiguration, Datenminimierung, Verfügbarkeit, Resilienz gegen Denial-of-Service, Logging sicherheitsrelevanter Aktivitäten, sichere Updates. Teil II beschreibt das Vulnerability Handling über den gesamten Supportzeitraum: Identifizierung und Dokumentation von Komponenten und Schwachstellen — explizit unter Einschluss eines SBOM in maschinenlesbarem Format —, zeitnahe Bereitstellung von Sicherheitsupdates, koordinierte Offenlegung von Schwachstellen.

Meldepflichten nach Artikel 14

Ab dem 11.09.2026 müssen Hersteller über die Single Reporting Platform der ENISA aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Die Fristen sind eng:

Frühwarnung: binnen 24 Stunden nach Kenntniserlangung
Vorfallsmeldung: binnen 72 Stunden nach Kenntniserlangung
Abschlussbericht: bei Schwachstellen binnen 14 Tagen nach Verfügbarkeit einer Korrektur, bei schwerwiegenden Vorfällen binnen einem Monat

Die Bedeutung dieser Fristen für die Architektur ist konkret: Sie brauchen Telemetrie und Tooling, das einen sicherheitsrelevanten Vorfall in einer Form an Ihr Team eskaliert, die innerhalb von Stunden — nicht Tagen — eine fundierte Erstmeldung erlaubt. Ein Logfile, das alle 24 Stunden gerollt wird und niemand liest, erfüllt das nicht.

Konformitätsbewertung und CE-Kennzeichnung

Vor der Bereitstellung auf dem Markt müssen Hersteller eine Konformitätsbewertung durchführen, eine technische Dokumentation pflegen, eine EU-Konformitätserklärung ausstellen und das Produkt mit der CE-Kennzeichnung versehen. Welche Bewertungstiefe erforderlich ist, hängt von der Produktklasse ab — dazu gleich mehr.

Supportzeitraum

Der Hersteller legt einen Supportzeitraum fest — mindestens fünf Jahre, oder die typische Nutzungsdauer des Produkts, je nachdem, was länger ist. In diesem Zeitraum müssen Schwachstellen identifiziert und behoben, Sicherheitsupdates bereitgestellt und die technische Dokumentation aktuell gehalten werden. Käufer:innen müssen das Enddatum des Supports zum Zeitpunkt des Kaufs kennen — mindestens auf Monat und Jahr genau.

Wen es betrifft — und wen nicht

„Produkte mit digitalen Elementen“ ist absichtlich breit definiert. Wer eine industrielle Maschine mit Cloud-Anbindung baut, ist drin. Wer eine Mobile-App vertreibt, die mit einem Backend kommuniziert, ist drin. Wer Firmware für ein IoT-Gerät schreibt, ist drin. Wer eine SaaS-Plattform betreibt, deren Software Bestandteil eines Produkts ist, das in der EU bereitgestellt wird, ist drin.

Ausgenommen sind im Wesentlichen Bereiche, die anderen sektorspezifischen Verordnungen unterliegen — Medizinprodukte (MDR/IVDR), Kraftfahrzeuge (UN R155/R156), zivile Luftfahrt, bestimmte maritime Ausrüstung — sowie Produkte, die ausschließlich für die nationale Sicherheit oder Verteidigung entwickelt wurden. Reine SaaS-Dienste ohne Produktcharakter sind nicht direkt erfasst, fallen aber häufig unter NIS2.

Vier Produktkategorien, drei Bewertungspfade

Die CRA strukturiert Produkte in vier Kategorien mit unterschiedlich strengen Konformitätsbewertungen:

Standardklasse — der Großteil der Produkte. Selbstbewertung möglich, unabhängig von angewandten Standards.
Wichtige Produkte Klasse I (Anhang III) — z. B. Identitätsmanagement-Systeme, Browser, Passwort-Manager, VPN, Router, SIEM-Tools, smarte Türschlösser, Heimautomatisierung mit Sicherheitsfunktion. Selbstbewertung nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Cybersicherheits-Zertifizierungsschema angewandt werden — andernfalls Drittprüfung über eine notifizierte Stelle.
Wichtige Produkte Klasse II (Anhang III) — z. B. Hypervisoren, Firewalls, Intrusion-Detection-Systeme. Drittprüfung verpflichtend.
Kritische Produkte (Anhang IV) — z. B. Smart-Meter-Gateways, Hardware-Security-Module, Smartcards mit Sicherheitselementen. Europäische Cybersicherheits-Zertifizierung über eine notifizierte Stelle verpflichtend.

Für die meisten Mittelstands-Hersteller vernetzter Industrieprodukte ist die Standardklasse der Default. Wer aber sicherheitsrelevante Funktionen baut — Authentifizierung, Verschlüsselung, Zugriffskontrolle als Produktmerkmal — sollte früh prüfen, ob er in Anhang III rutscht. Das verändert den Aufwand für die Konformitätsbewertung deutlich.

Architektur-Implikationen — wo das tatsächlich ankommt

Die CRA ist keine Compliance-Übung, die sich am Ende mit einem PDF erschlagen lässt. Sie verändert, was eine vernetzte Plattform leisten muss. Fünf Punkte sind aus Architektursicht entscheidend.

SBOM heißt: Build-Pipeline plus Schwachstellen-Scan

Anhang I Teil II Nummer 1 verlangt, dass Hersteller Komponenten und Schwachstellen in ihren Produkten identifizieren und dokumentieren — mindestens auf Ebene der direkten Abhängigkeiten, in einem allgemein gebräuchlichen, maschinenlesbaren Format. Die Verordnung schreibt kein konkretes Format vor; in der Praxis sind SPDX und CycloneDX die etablierten Optionen. Die Kommission kann per delegiertem Rechtsakt zusätzliche Vorgaben machen.

Architektonisch heißt das: Der SBOM darf nicht eine Excel-Liste sein, die jemand vor dem Audit zusammensucht. Er muss Bestandteil des Build-Outputs werden. Konkret: in der CI-Pipeline ein Schritt, der den SBOM beim Build erzeugt (Syft, CycloneDX-Maven-Plugin, npm-cyclonedx, gradle-cyclonedx, Trivy mit `--format cyclonedx`); ein Schritt, der ihn gegen Vulnerability-Datenbanken prüft (Grype, OSV-Scanner, Trivy); eine Ablage, die SBOMs pro Release versionsgebunden archiviert und beim Marktaufsichts-Auskunftsersuchen verfügbar macht. Software Composition Analysis ist damit nicht mehr Kür, sondern in Datenmodell und API-Schicht der Build-Infrastruktur verankert.

Vulnerability Handling heißt: Hotfix-Pfad, Audit-Trail, Versionierung

Schwachstellen müssen über den gesamten Supportzeitraum behandelt werden — also mindestens fünf Jahre, oft länger. Das hat zwei Architektur-Konsequenzen, die häufig unterschätzt werden.

Erstens: Sie brauchen einen Hotfix-Pfad, der nicht das ganze Release-Train-Modell durchläuft. Wenn eine kritische Schwachstelle in einer Library auftaucht, die Sie verwenden, müssen Sie patchen, signieren, ausrollen und Kunden informieren — schnell. Eine Architektur, die jedes Update durch eine sechswöchige QA-Schleife schickt, kollidiert mit der Realität dieser Verordnung.

Zweitens: Sie brauchen einen revisionssicheren Audit-Trail darüber, welche Version eines Produkts welche Komponenten enthielt, wann eine Schwachstelle bekannt wurde, wann sie behoben wurde, wann ein Update beim Endkunden ankam. Append-only Eventlogs in der Plattform-Datenbank — pro Geräte-/Produkt-Instanz — sind hier ein robustes Architekturmuster. Was wir bei LITE BLOX als Lifecycle-Datenmodell mit Geburts-Snapshot pro Einheit gebaut haben, deckt genau diesen Anforderungstyp ab.

Incident Reporting heißt: Echtzeit-Telemetrie und ein klarer Eskalationspfad

24 Stunden ist nicht viel. „Aktiv ausgenutzt“ heißt: Sie haben Hinweise, dass jemand die Schwachstelle in freier Wildbahn ausnutzt — nicht erst, wenn der Schaden eingetreten ist. Damit Ihr Team das in der Stundenmarke erkennt, brauchen Sie:

Runtime-Instrumentierung, die Anomalien sichtbar macht — Sentry für Application-Errors, Grafana/Prometheus oder vergleichbar für Metriken, strukturiertes Logging mit Korrelation-IDs für die Forensik
Alerting, das eine Eskalation an einen Bereitschafts-Verantwortlichen auslöst — nicht eine E-Mail, die montags gelesen wird
Eine dokumentierte Incident-Response-Prozedur, die festlegt, wer die ENISA-Meldung bestätigt und absendet, in welcher Form, mit welcher Vorlage

Die ENISA Single Reporting Platform soll bis zum 11.09.2026 betriebsbereit sein. Bis dahin lohnt sich ein Trockenlauf an einem fiktiven Vorfall: Wer würde was tun, in welcher Reihenfolge, mit welchen Daten zur Hand?

Security-by-default heißt nicht „Compliance-by-Design“

Die Verordnung verlangt, dass Produkte mit einer sicheren Standardkonfiguration ausgeliefert werden, dass Authentifizierung, Identitäts- und Zugriffskontrolle dem Stand der Technik entsprechen, dass Daten in Ruhe und in Transit geschützt sind, dass nur die für den Zweck notwendigen Daten verarbeitet werden. Das sind keine neuen Erkenntnisse — aber sie müssen in Datenmodell-Schemata, Authentication-Layern und API-Verträgen verankert sein. Konkret bedeutet das:

Default-Passwörter sind ausgeschlossen — Erstkonfiguration mit erzwungener Credential-Setzung
TLS 1.2+ als Mindestanforderung an alle externen Schnittstellen, mTLS für Geräte-zu-Backend
Secrets-Management als eigenständige Architektur-Komponente (HashiCorp Vault, Cloud-KMS, oder bei eigener Infrastruktur ein dediziertes Secret-Storage), nicht Umgebungsvariablen im Repo
Rollenmodell und Berechtigungsmatrix im Datenmodell sichtbar — nicht als nachgelagerter Filter in der UI

Drei regulatorische Strömungen, eine Architektur

Die CRA steht nicht allein. Sie trifft auf den EU Data Act (anwendbar seit 12.09.2025), der Nutzer:innen Zugriff auf die Daten gibt, die ihre vernetzten Produkte erzeugen, und auf die DSGVO, die regelt, was mit personenbezogenen Daten passieren darf. Drei Verordnungen, die auf dasselbe Datenmodell zugreifen — Telemetrie aus dem Feld, Nutzungsdaten, Wartungs-Logs — und unterschiedliche Pflichten erzeugen. Eine Plattform, die das nachträglich zusammenstrickt, baut sich Schulden ein. Eine Plattform, die Datenherkunft, Zweckbindung, Retentionspolitik und Zugriffsrechte als Felder im Modell führt, kann auf alle drei antworten, ohne sich neu zu erfinden.

Was Sie 2026 konkret bauen sollten

Wer heute eine neue vernetzte Plattform aufsetzt — oder ein Bestandssystem refactort —, sollte folgende Bausteine als Architekturziele für 2026 setzen:

SBOM-Generierung in der CI-Pipeline bei jedem Release-Build, mit automatisiertem Scan gegen NVD/OSV und einem Quality Gate, das kritische bekannte Schwachstellen blockiert
Append-only Eventlog pro Produkt-/Geräte-Instanz für sicherheitsrelevante Ereignisse — Auth-Versuche, Konfigurationsänderungen, Update-Installationen, Vorfallsbezüge
Hotfix-Release-Kanal, der unabhängig vom regulären Release-Zyklus ausspielen kann, mit signierten Updates und Rollback-Pfad
Secrets-Management als First-Class-Komponente, getrennt von Anwendungsconfig, mit auditierbarer Zugriffskontrolle
Runtime-Instrumentierung (z. B. Sentry für Application-Errors, Grafana für Metriken), gekoppelt an einen Eskalationskanal mit Bereitschaft
Vulnerability-Disclosure-Policy öffentlich auf der Produktseite, mit security@-Mailadresse oder Hackerone-/Open-Bug-Bounty-Kanal — die CRA verlangt einen koordinierten Offenlegungsprozess, nicht den heroischen Einzelfall
Dokumentierte Support-Endzeitpunkte pro Produkt-/Hardware-Generation, sichtbar im Vertriebs- und Käuferprozess

Jeder dieser Punkte ist für sich betrachtet kein neues Konzept. Was die CRA verändert, ist der Verbindlichkeitsgrad: Was bisher „best practice“ war, wird zur regulatorischen Pflicht — mit Marktaufsicht, Bußgeld und potenziellem Marktentzug bei Nichteinhaltung.

OSS und Standard-Bibliotheken

Open-Source-Software ist nicht pauschal von der CRA befreit, sondern in einer eigenen Logik geregelt. Wer freie Software ohne kommerzielle Tätigkeit veröffentlicht — der klassische Maintainer eines GitHub-Repos —, fällt nicht unter die Hersteller-Pflichten. Die Verordnung schafft aber die neue Rolle des Open-Source-Software-Stewards: juristische Personen, die systematisch und dauerhaft Entwicklung von OSS unterstützen, die für kommerzielle Aktivitäten gedacht ist (typischerweise Foundations wie Apache, Eclipse, Linux Foundation oder ähnliche Träger). Stewards haben reduzierte Pflichten — eine dokumentierte Cybersecurity-Policy, Meldepflicht für aktiv ausgenutzte Schwachstellen, Kooperation mit Marktaufsichtsbehörden — und sind ausdrücklich nicht bußgeldpflichtig.

Für Sie als gewerblichen Hersteller bedeutet das nicht „OSS = sicher“. Wenn Sie eine OSS-Library in Ihr Produkt einbinden und das Produkt kommerziell auf dem EU-Markt bereitstellen, sind Sie für die Sicherheit dieses Produkts verantwortlich — einschließlich der OSS-Komponenten. Das ist die praktische Konsequenz für Lieferkette und SBOM: Sie müssen wissen, was drin ist, müssen Schwachstellen verfolgen, müssen patchen oder austauschen. Die OSS-Community liefert das Material — die Verantwortung für das Endprodukt bleibt bei Ihnen.

Strafmaß und Durchsetzung

Die CRA sieht ein dreistufiges Bußgeldregime vor (Artikel 64). Es gilt jeweils der höhere der beiden Beträge, gemessen am Umsatz des vorangegangenen Geschäftsjahres:

Bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes — bei Verstößen gegen die wesentlichen Anforderungen aus Anhang I sowie die Hersteller-Kernpflichten der Artikel 13 und 14 (Vulnerability Handling und Meldungen)
Bis zu 10 Mio. € oder 2 % — bei sonstigen CRA-Pflichten, einschließlich Pflichten von Importeuren, Händlern und der Konformitätsbewertung
Bis zu 5 Mio. € oder 1 % — bei falschen, unvollständigen oder irreführenden Angaben gegenüber Behörden oder notifizierten Stellen

Open-Source-Stewards sind ausdrücklich von Bußgeldern ausgenommen. Kleinst- und Kleinunternehmen können nicht für die Überschreitung der 24-Stunden-Frist zur Frühwarnung sanktioniert werden. Marktaufsicht in Deutschland übernimmt das BSI — die Bundesregierung hat das Durchführungsgesetz auf den Weg gebracht, das BSI als zentrale Marktüberwachungs- und notifizierende Behörde benennt. Das BSI wird auch Sensibilisierung und Schulung für KMU und OSS-Verwalter bereitstellen.

Wie wir das angehen

Wir verkaufen keine „CRA-Compliance-as-a-Service“. Compliance ist kein Produkt — sie ist die Konsequenz einer sauber gebauten Architektur. Was wir tun: wir bauen Plattformen für vernetzte Produkte, in denen die Pflichten aus CRA, EU Data Act und DSGVO nicht nachträglich angeschraubt werden, sondern in Datenmodell und API-Schicht verankert sind. Append-only Eventlog pro Produkt-Instanz, SBOM in der Build-Pipeline, signierte Updates, Audit-Trail revisionssicher — als Architekturmuster, das wir konkret umgesetzt haben.

Das B2B-IoT-Projekt LITE BLOX ist genau der Anwendungsfall, in dem diese Anforderungen landen: vernetzte Industrieeinheiten im Feld, Lifecycle-Datenmodell mit Geburts-Snapshot pro Einheit, kontinuierliche Telemetrie, Update-Pfad. Wenn Sie ein vergleichbares Vorhaben verantworten — neue Plattform oder Refactor eines Bestandssystems —, sprechen wir gerne über die Architektur, bevor das Pflichtenheft den ersten Sprint erreicht.

Ressourcen

EU-Verordnung 2024/2847 (Cyber Resilience Act), konsolidierte Fassung: eur-lex.europa.eu/eli/reg/2024/2847
EU-Kommission, Q&A zum Cyber Resilience Act: digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
EU-Kommission, Zusammenfassung des Rechtstexts: digital-strategy.ec.europa.eu/en/policies/cra-summary
EU-Kommission, Open Source unter der CRA: digital-strategy.ec.europa.eu/en/policies/cra-open-source
BSI, Cyber Resilience Act in Deutschland: bsi.bund.de — Cyber Resilience Act
ENISA, technische Leitlinien zur Cybersicherheit: enisa.europa.eu

Stand: Mai 2026. Die Auslegung einzelner Artikel kann sich durch Durchführungsrechtsakte, harmonisierte Normen (Standardisierungsauftrag M/606) und nationale Umsetzungsgesetze noch ändern. Für rechtsverbindliche Beurteilung Ihres konkreten Falls verweisen wir auf qualifizierte Rechtsberatung.