Cyber Resilience Act: Warum die Meldepflicht ab 11.09.2026 die stille Zäsur für Hersteller und Käufer ist

Am 11. September 2026 wird der Cyber Resilience Act (CRA) für Hersteller in Europa erstmals operational spürbar. Zu diesem Datum treten die Melde­pflichten in Kraft: 24 Stunden Früh­warnung, 72 Stunden vollständige Meldung, 14 Tage Abschluss­bericht. Nicht 2027, wenn die vollen Konformitäts­pflichten greifen. Sondern 2026 — und für viele DACH-Unternehmen deutlich früher, als ihre internen Prozesse darauf vorbereitet sind.

Die weit verbreitete Annahme, der CRA sei ein Thema "bis Dezember 2027", ist falsch. Zwischen den beiden Daten liegen 15 Monate, in denen ein Hersteller aktiv ausgenutzte Schwach­stellen und schwere Sicherheits­vorfälle melden muss — bevor er die zugrundeliegenden Konformitäts­anforderungen überhaupt vollständig umgesetzt haben muss. Es ist ein Zeit­fenster, in dem operative Melde­diszi­plin verlangt wird, während die Substanz noch entsteht.

Für Hersteller mit vernetzten Produkten, für Software-Anbieter und für institutionelle Käufer in laufenden M&A-Prozessen ist der 11.09.2026 damit kein Compliance-Meilenstein. Er ist ein Belastungs­test für Governance, Incident-Response-Fähigkeit und interne Berichts­wege.

Was der CRA konkret verlangt — und warum die Meldepflicht zuerst greift

Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten. Sie führt erstmals verbindliche Cyber­sicherheits­anforderungen für alle „Produkte mit digitalen Elementen" ein, die auf dem Unions­markt bereit­gestellt werden — Hardware, Software, IoT, industrielle Steuerungs­komponenten, Betriebs­systeme, Firmware, separat vertriebene digitale Bauteile.

Die zentrale zeitliche Struktur des CRA:

| Datum | Was greift | |---|---| | 10.12.2024 | CRA tritt in Kraft | | 11.09.2026 | Meldepflichten für aktiv ausgenutzte Schwach­stellen und schwere Vorfälle | | 11.12.2027 | Vollständige Anwendbarkeit — nur noch CRA-konforme Produkte mit CE-Kennzeichnung |

Die Melde­kette ist bewusst kurz getaktet und in Artikel 14 CRA geregelt:

• Innerhalb von 24 Stunden nach Kenntnis­nahme: initiale Frühwarnung an das zuständige nationale Computer Security Incident Response Team (CSIRT) und an ENISA
• Innerhalb von 72 Stunden: vollständige Meldung mit verfügbaren Details
• Spätestens 14 Tage nach Bereit­stellung einer Korrektur­maßnahme (bzw. innerhalb eines Monats bei schweren Vorfällen): Abschluss­bericht

Diese Meldungen laufen über die von ENISA betriebene Single Reporting Platform (SRP) — eine zentrale Anlaufstelle für die gesamte Union. Meldung an einer Stelle; automatische Weiterleitung an das jeweils zuständige CSIRT.

Der wesentliche Punkt für Geschäfts­führer: Die Melde­pflicht gilt auch für Produkte, die bereits vor dem 11. Dezember 2027 auf dem Markt waren. Es gibt keinen Bestands­schutz für Alt­geräte. Wer heute vernetzte Produkte in Verkehr gebracht hat und sie 2026 noch am Markt hat, ist ab 11.09.2026 melde­pflichtig — unabhängig davon, ob die volle CRA-Konformität schon steht.

Deutschland: Das BSI wird digitaler TÜV

Parallel zur europäischen Regelung hat der Bundes­tag am 11. Juni 2026 in erster Lesung den Entwurf des CRA-Durch­führungs­gesetzes beraten; der Bundes­rat hat den Gesetz­entwurf am 12. Juni 2026 ohne Einwendungen passieren lassen (Deutscher Bundestag Drs. 21/6134). Das Gesetz schafft den nationalen Rahmen für die Durchsetzung des CRA in Deutschland — und die Zuständig­keits­struktur ist eindeutig.

Das Bundes­amt für Sicherheit in der Informations­technik (BSI) wird als zentrale Markt­überwachungs­behörde für den CRA benannt (§ 65 BSIG-E). Es prüft Produkt­konformität, ordnet Maßnahmen an und wird gleichzeitig Notifizierungs­stelle für die Konformitäts­bewertungs­stellen (§ 66 BSIG-E), die bei besonders kritischen Produkt­kategorien die formale Prüfung übernehmen.

Der Gesetz­entwurf sieht darüber hinaus ein Cyber-Resilienz-Reallabor mit einem Budget von 7,5 Millionen Euro vor (§ 67 BSIG-E) — eine Struktur, in der Hersteller ihre Produkte in einem regulatorisch begleiteten Umfeld testen können, bevor sie sie in Verkehr bringen.

Heise fasst das treffend zusammen: „BSI wird digitaler TÜV für vernetzte Produkte." Was das für Hersteller bedeutet: Die Behörde, die bisher primär Empfehlungen aussprach, wird 2026 zur durchsetzungs­befugten Aufsicht.

Wer wirklich betroffen ist — und wo die Grauzonen liegen

Der Anwendungs­bereich des CRA ist breiter als vielen bewusst ist. Erfasst sind sämtliche Produkte mit digitalen Elementen — nicht nur klassische IoT-Geräte, sondern auch:

• Betriebs­systeme und Anwendungs­software (auch B2B)
• Firmware und Middleware
• Netzwerk­geräte, industrielle Steuerungen (ICS/OT)
• Separat vertriebene digitale Komponenten und Bibliotheken

Nicht in den CRA fallen dagegen — Stand Commission Guidance vom März 2026 — reine SaaS-Angebote. Das war lange strittig; die Kommission hat die Grenze in einer Draft-Guidance im März 2026 geklärt: Standalone-SaaS ist außerhalb des Anwendungs­bereichs. Der wichtige Vorbehalt: Sobald ein SaaS-Dienst den dreiteiligen „Remote Data Processing Services"-Test (RDPS) erfüllt — also für die Kern­funktion eines Produkts mit digitalen Elementen essentiell ist — fällt er wieder unter den CRA.

Für Software-Anbieter im DACH-Mittelstand bedeutet das eine juristisch komplexe Ausgangs­lage:

1. Reines SaaS-Geschäftsmodell — vermutlich nicht CRA-pflichtig, aber die RDPS-Bewertung muss dokumentiert vorliegen.
2. Hybrid-Angebote (On-Prem-Komponente + Cloud-Backend) — die On-Prem-Komponente fällt eindeutig unter den CRA; das Backend wird als Komponente behandelt und in die Lieferketten­sorgfalt einbezogen.
3. Software-Bibliotheken, SDKs, npm-Pakete mit kommerzieller Absicht — im CRA-Fokus, insbesondere in der Verbindung mit der aktuellen Supply-Chain-Angriffsserie auf npm, Ruby Gems und SAP-Pakete.

Der Open-Source-Software-Steward — ein neuer Vertragsakteur

Eine der strukturellen Neuerungen des CRA ist die Kategorie des Open-Source-Software-Stewards: eine juristische Person, die systematisch und dauerhaft die Entwicklung von Open-Source-Software unterstützt, ohne selbst Hersteller im klassischen Sinne zu sein.

Stewards unterliegen einem bewusst leichteren Regime als Hersteller — im Kern drei Pflichten: eine dokumentierte Cyber­sicherheits­richtlinie, die Melde­pflicht für aktiv ausgenutzte Schwach­stellen und aktive Kommunikation mit der Nutzer­gemein­schaft. Keine vollständige Konformitäts­bewertung, keine CE-Kennzeichnung, keine technische Dokumentation im vollen Umfang.

Die Open Source Business Alliance (OSBA) hat in ihrer Stellungnahme zum Durch­führungs­gesetz explizit darauf hingewiesen, dass Stewards häufig sehr begrenzte personelle und finanzielle Ressourcen haben und aktive Unter­stützung durch das BSI brauchen. Ob diese Unter­stützung in der Praxis so aussieht, wie der Regelungs­geber sie sich vorstellt, wird sich zwischen September 2026 und Ende 2027 zeigen.

Für Unternehmen bedeutet die Steward-Kategorie zweierlei: Erstens ist zu prüfen, ob eigene Open-Source-Aktivitäten die Steward-Rolle auslösen. Zweitens ist bei kritischen Open-Source-Abhängig­keiten in der eigenen Produkt­architektur zu klären, wer als Steward benannt ist — und wie belastbar dessen Melde­kette tatsächlich ist.

Der Standards-Engpass 2026

Die 41 harmonisierten Standards, die die konkrete technische Ausgestaltung der CRA-Anforderungen liefern sollen, sind derzeit in aktiver Entwicklung, aber noch nicht final. CEN, CENELEC und ETSI haben im April 2025 den Standardisierungs­auftrag M/606 angenommen und arbeiten auf Q3 2026 als Ziel­termin hin. Die öffentliche Konsultation der Entwürfe ist für Mitte Juli bis Mitte November 2026 vorgesehen.

Verzögerungen sind eingepreist. Die Standardisierungs­organisationen haben sich zwar auf eine Lieferung mindestens ein Jahr vor voller CRA-Anwendbarkeit verpflichtet — aber das enge Zeit­fenster gilt als sportlich. Das bedeutet für Hersteller: Wer wartet, bis die finalen Standards vorliegen, verliert 2026 als operative Vorbereitungs­phase.

Ein pragmatischer Weg — bereits von führenden Rechts­beratern empfohlen — ist die Ausrichtung an der bereits publizierten EN 18031-Reihe (aus der RED Delegated Act-Umsetzung), auf der die horizontalen CRA-Standards aufbauen. Rund zwei Drittel der Anforderungen der geplanten CRA-Standards decken sich mit EN 18031. Hersteller, die die EN 18031 bereits umgesetzt haben, verfügen über einen substanziellen Vorsprung.

Was der CRA für M&A und Vendor Due Diligence bedeutet

Der Punkt, der in der öffentlichen CRA-Diskussion noch unter­schätzt wird — und der für institutionelle Käufer im DACH-Raum bereits jetzt handlungs­leitend sein sollte — betrifft die Übertragung der Melde­pflicht bei Unternehmens­transaktionen.

Wer 2026 oder 2027 einen Software-Hersteller, einen IoT-Anbieter oder ein Industrie­unternehmen mit vernetzten Produkten erwirbt, übernimmt die vollständige CRA-Historie: bereits gemeldete Schwach­stellen, offene Melde­pflichten, technische Dokumentations­lücken, unvollständige CE-Kennzeichnungen. Ein Target, das die 24-Stunden-Frühwarnung im September 2026 verpasst hat, trägt die entsprechenden Sanktions­risiken mit — und der Käufer erbt sie mit dem Closing.

Konkret sollten CRA-relevante Fragen in jede M&A Cyber Due Diligence eines Software- oder Hardware-Herstellers integriert werden:

• Anwendungs­bereich: Welche Produkte des Targets fallen unter den CRA? Ist die RDPS-Bewertung dokumentiert?
• Melde­historie: Wurden aktiv ausgenutzte Schwach­stellen zwischen 11.09.2026 und Closing gemeldet? Wenn nein — warum nicht?
• Incident-Response-Fähigkeit: Ist die 24/72-Stunden-Melde­kette prozessual belastbar, oder existiert sie nur auf dem Papier?
• Standards-Konformität: Ist die EN 18031-Basislinie umgesetzt? Welche horizontalen CRA-Standards sind bereits adressiert?
• Lieferketten­sorgfalt: Welche Software-Kompo­nenten und SBOM-Prozesse sind etabliert? Wie belastbar ist die Nachweis­kette für kritische Open-Source-Abhängig­keiten?
• Konformitäts­bewertung: Ist der Weg zur CE-Kennzeichnung bis 11.12.2027 definiert und mit Ressourcen unterlegt?

Diese Fragen sind nicht abstrakt. Sie werden — spätestens ab Herbst 2026 — Gegenstand harter Preis­verhandlungen sein. Der Kaufpreis­hebel einer sauberen Cyber Due Diligence verschiebt sich in Deals mit CRA-Exponierung strukturell nach oben.

Das Zusammenspiel mit NIS2, DORA und dem SBOM-Regime

Der CRA steht nicht allein. Er greift in ein enger werdendes europäisches Regulierungs­geflecht, das für DACH-Unternehmen mittlerweile aus mindestens vier ineinander­greifenden Rechts­akten besteht:

• NIS2 (in Deutschland seit Oktober 2024 in Umsetzung) — Governance-Pflichten für „wesentliche" und „wichtige" Einrichtungen, persönliche Haftung der Geschäfts­führung, Meldepflichten für Betreiber.
• CRA — Produkt­sicherheits­pflichten für Hersteller.
• DORA — spezifische digitale Betriebs­stabilität für den Finanz­sektor.
• Product Liability Directive (überarbeitet) — zivil­rechtliche Produkt­haftung, die Software und digitale Elemente explizit einschließt.

Für einen Hersteller, der gleich­zeitig als NIS2-„wichtige Einrichtung" gilt und ein CRA-pflichtiges Produkt in Verkehr bringt, überlagern sich die Melde­pflichten: NIS2-Meldung an das BSI als CSIRT-Betreiber-Behörde plus CRA-Meldung an die Single Reporting Platform. Ein einheitlicher, dokumentierter Melde­prozess ist ab September 2026 kein Optionen­punkt mehr. Er ist die operative Vor­aus­setzung, um beide Regime nicht gegen­einander laufen zu lassen.

Drei Maßnahmen mit Wirkung — vor September 2026

1. CRA-Anwendungs­bereich klären und dokumentieren

Nicht jedes Produkt fällt unter den CRA; nicht jedes vermeintliche „SaaS" ist außerhalb. Die dokumentierte Bewertung der Anwendbar­keit — inklusive RDPS-Test für SaaS-Komponenten — ist der Ausgangs­punkt jeder CRA-Vorbereitung und die erste Frage, die eine Marktüberwachungs­behörde bei einem Vorfall stellen wird.

2. Melde­kette bis zur Board-Ebene bauen

Die 24-Stunden-Frühwarnung ist keine IT-Aufgabe. Sie ist eine Governance-Aufgabe. In der Praxis scheitern Meldungen selten am fehlenden Schwach­stellen-Detektions­system, sondern an unklaren Eskalations­wegen zwischen Security-Team, Rechts­abteilung und Geschäfts­führung. Ein dokumentierter Incident-Playbook mit klaren Zeit­marken (T+2h Interne Eskalation, T+8h Legal-Review, T+18h ENISA-Meldung) ist die operative Basis, auf der die 24/72/14-Kadenz überhaupt einhaltbar wird.

Ein strukturiertes vCISO-Mandat etabliert genau diese Kette — mit Geschäfts­führungs­berichterstattung, klarer Rollen­verteilung und einem laufenden Meldeprozess, der im Fall der Fälle nicht neu erfunden werden muss.

3. Supply-Chain-Nachweise vor jede M&A-Transaktion ziehen

Für Käufer, die 2026/2027 Software- oder Hardware-Hersteller adressieren, gehört eine CRA-spezifische Prüf­schicht in die Due-Diligence-Architektur — als eigen­ständige Prüfungs­dimension, nicht als Zusatz zur klassischen IT-Prüfung. Fragen zu SBOM, RDPS, Melde­historie und Standards-Konformität sind in M&A Cyber Due Diligence mittlerweile Standard-Bestandteil; die CRA-Erweiterung wird ab Herbst 2026 zur Voraussetzung, um post-Closing-Sanktions­risiken sauber zu quantifizieren.

Für Portfolio­gesellschaften, die selbst betroffen sind, empfiehlt sich ein strukturierter Compliance Sprint, der die Anwendungs­bereichs­analyse, den Melde­prozess und die Standards-Basislinie in einer dokumentier­baren Form zusammen­führt.

Warum Woodlands

Woodlands Advisory ist auf regulatorisch getriebene Cyber-Beratung im institutionellen Kapital­markt spezialisiert. Der Gründer verantwortet aktuell die Global Security Advisory Lead-Funktion bei SAP und hat die Post-Acquisition-Cyber-Integration von Signavio nach der SAP-Übernahme geleitet — eine Rolle, in der Regulierungs­geflechte wie NIS2, CRA und das aufkommende AI-Regime auf reale Deal-Realitäten treffen.

Die Delivery erfolgt durch ein kuratiertes Team aus Senior-Praktikern mit Cloud-, Identity-, AppSec- und Compliance-Schwerpunkt — kein Outsourcing, keine Junior-Substitution. Der Partner­stack für Tooling (Vanta, Kertos, Aikido) und Kanzlei-Partner für vertragliche und regulatorische Fragen sind strukturell eingebunden, nicht ad hoc improvisiert.

Für PE-Häuser, Family Offices und M&A-Advisors im DACH-Raum liefert Woodlands CRA-relevante Bewertungen in einer Form, die im Investment-Committee und in SPA-Verhand­lungen belastbar ist: als Risiko­quantifizierung mit Kaufpreis­bezug, nicht als Framework-Zitat.

---

Wenn Sie Ihre eigene CRA-Exponierung, die Ihres Portfolios oder eines aktuellen Targets einordnen möchten, sprechen wir vertraulich.

Erstgespräch vereinbaren →

---

Quellen (Tier 1 & Tier 2):

1. Europäische Kommission — Cyber Resilience Act Policy Page & CRA Reporting Obligations & CRA Standardisation
2. ENISA — Single Reporting Platform (SRP)
3. Deutscher Bundestag — Drucksache 21/6134 (26.05.2026) — Gesetzentwurf zur Durchführung der Cyberresilienz-Verordnung
4. BMI — Gesetzgebungsverfahren Cyberresilienz-Verordnung
5. BSI — Cyber Resilience Act — Themenseite
6. DLA Piper — Cyber Resilience Act: The Fine Line Between SaaS and Digital Products (Feb 2026)
7. Open Source Business Alliance — Stellungnahme zum CRA-Durchführungsgesetz
8. Crowell & Moring LLP — EU CRA: September 11, 2026 Reporting Deadline
9. Heise Online — BSI wird digitaler TÜV für vernetzte Produkte