Am 27. Juli 2026 hat die Europäische Kommission ihre Guidance zur Anwendung des Cyber Resilience Act (Verordnung (EU) 2024/2847, „EU CRA“) als C(2026) 5252 final angenommen. Wir haben die finale Fassung Absatz für Absatz mit dem Konsultationsentwurf vom 3. März 2026 verglichen und beide am Verordnungstext gespiegelt. Das Bild ist differenzierter, als die ersten Schlagzeilen vermuten lassen. Vieles, was gerade als Entlastung gefeiert wird, steckte längst im EU CRA und wird nur erstmals ausbuchstabiert. Anderes ist echte, teils mutige Auslegung, die der Verordnungstext so nicht hergibt. Und an einigen Stellen schließt die Guidance alte Grauzonen, reißt dafür aber neue auf.
Eine kapitelweise Zusammenfassung des gesamten Dokuments, verknüpft mit den betroffenen Artikeln, Erwägungsgründen und Anhängen, findet sich in unserem Überblick zur EU-Kommissions-Guidance, dort auch das Original-PDF.
Was die Guidance ist und was nicht
Rechtsgrundlage ist Art. 26 Abs. 1 EU CRA, der die Kommission verpflichtet, Leitlinien zur Unterstützung der Wirtschaftsakteure zu veröffentlichen, mit besonderem Blick auf Kleinstunternehmen und KMU. Art. 26 Abs. 2 gibt die Mindestthemen vor: Anwendungsbereich (insbesondere Remote Data Processing und Open Source), Supportzeitraum, Zusammenspiel mit anderem EU-Recht und der Begriff der wesentlichen Änderung. Diese Themen bilden das Rückgrat des Dokuments.
Zwei Dinge sollte man beim Lesen durchgehend im Hinterkopf behalten. Die Guidance ist rechtlich unverbindlich. Sie bindet weder Marktüberwachungsbehörden noch Gerichte, die verbindliche Auslegung des EU CRA liegt allein beim EuGH. Überall dort, wo die Guidance den Verordnungstext dehnt, bleibt ein Restrisiko, dass Behörden oder Gerichte anders entscheiden. Hinzu kommt ein neuer Vorbehalt in der finalen Fassung: Die zahlreichen Beispiele sollen „keine Einzelfallprüfung ersetzen“ (Rn. 8). Das ist mehr als eine Floskel. Es ist die Rückversicherung der Kommission gegen den schematischen Rückgriff auf genau jene Beispiele, die sie auf Druck der Konsultation ergänzt hat.
Zur Erinnerung der Zeitplan, den die Guidance selbst mehrfach wiederholt: Die Notifizierungsvorschriften (Kapitel IV) gelten seit dem 11. Juni 2026, die Meldepflichten des Art. 14 greifen ab dem 11. September 2026 (Art. 71 Abs. 2 EU CRA), und vollständig anwendbar ist die Verordnung ab dem 11. Dezember 2027.
Die Konsultation und woher die Kritik kam
Vier Kritikfelder haben die Konsultation (3. März bis 13. April 2026) und die begleitende Fachdebatte geprägt. Wer sie kennt, versteht die finale Fassung besser.
Erstens die Software-Grenze. Der Entwurf ließ ausgerechnet die Frage weitgehend offen, die in der Praxis am meisten zählt: Wann ist Software ein „Produkt mit digitalen Elementen“ und wann bloße Dienstleistung? Kanzleien und Verbände kritisierten unisono die Rechtsunsicherheit bei SaaS, Web-Apps und Hybridmodellen.
Zweitens die Open-Source-Ökonomie. Die Community, organisiert unter anderem in der Open Regulatory Compliance Working Group der Eclipse Foundation, hatte schon im Gesetzgebungsverfahren erreicht, dass die härtesten Klauseln fielen und mit dem „Open Source Steward“ (Art. 24 EU CRA) eine eigene, mildere Pflichtenkategorie entstand. Am Entwurf störten sie die vagen Kriterien für Donations, Support-Leistungen und den Steward-Status, dazu die Sorge, Hersteller könnten ihre Due-Diligence-Pflichten aus Art. 13 Abs. 5 EU CRA auf unbezahlte Maintainer abwälzen.
Drittens die Bestandsprodukte. Der Entwurf verlangte bei jeder wesentlichen Änderung die vollständige Konformität des gesamten Produkts. Für Hersteller langlebiger Investitionsgüter mit großen installierten Flotten hätte diese Regel Updates faktisch bestraft.
Viertens der RDPS-Scope. Vor allem der Finanzsektor fürchtete, über den Begriff der „Remote Data Processing Solution“ könnten ganze Backend-Landschaften, vom Kernbankensystem bis zu Settlement und Clearing, in den Konformitätsbewertungs-Scope einer App rutschen.
Über weite Strecken liest sich die finale Fassung wie eine direkte Antwort auf diese vier Punkte.
1. Anwendungsbereich: Die SaaS-Grenze ist Klarstellung, keine Neuerung
Der neue Abschnitt 2.2 ist die wichtigste Ergänzung des Dokuments, muss aber richtig eingeordnet werden. Dass reines SaaS nicht unter den EU CRA fällt, stand schon im Gesetz: Art. 3 Nr. 1 definiert das Produkt mit digitalen Elementen als Software- oder Hardwareprodukt, und Erwägungsgrund 12 stellt klar, dass Cloud-Lösungen nur insoweit erfasst sind, wie sie Remote Data Processing eines Produkts im Sinne von Art. 3 Nr. 2 darstellen. Ansonsten gilt NIS2. Neu ist, dass die Guidance daraus ein handhabbares Kriterium macht. Ein Softwareprodukt muss dem Nutzer bereitgestellt und auf dessen Seite ausgeführt werden. Web-Apps und PWAs, die ausschließlich im Browser laufen, sowie Websites sind „nicht allein deshalb“ Produkte. Browser-Extensions und lokal ausgeführte Web-Technologie-Anwendungen wie Electron-Apps sind es dagegen eindeutig.
Die alte Grauzone wird kleiner, verschwindet aber nicht. Sie verschiebt sich. (Warum SaaS-Anbieter trotz der Scope-Ausnahme nicht aus dem Schneider sind, Stichworte NIS2, lokale Clients und Kundenverträge, haben wir in Cyber Resilience Act und SaaS beleuchtet. Die finale Guidance bestätigt die dort vorgenommene Abgrenzung jetzt offiziell.) Sobald ein lokaler Client existiert, wird die serverseitige Verarbeitung als Remote Data Processing potenziell Teil des Produkts. Die Architekturentscheidung zwischen PWA und nativem Client wird damit zur Compliance-Entscheidung, und Anbieter werden sie künftig mit Blick auf den EU CRA treffen. Diese Steuerungswirkung dürfte kaum im Sinne des Gesetzgebers sein.
Eine echte Neuerung ohne klare Grundlage in der Verordnung ist die Varianten-Regel in Rn. 14. Builds für verschiedene Betriebssysteme oder Bundles mit unterschiedlichem Funktionsumfang sind „eigenständige Produkte“, jedes mit eigenem Inverkehrbringen, eigener Dokumentation und eigenem Supportzeitraum. Der EU CRA kennt den Begriff der Variante nicht, die Guidance schafft hier also eine neue Frage. Ist ein Build mit anderen Compiler-Flags eine Variante? Ein regionalisierter Funktionsumfang? Ein per Lizenzschlüssel freigeschaltetes Modul desselben Binaries? Die Grenze zwischen Kopie und Variante wird Reibung mit den Marktüberwachungsbehörden erzeugen. Sie steht zudem in Spannung zur Produktfamilien-Logik in Abschnitt 7.4 der Guidance, die gemeinsame Risikobewertungen und eine gemeinsame Konformitätserklärung gerade für Varianten mit identischen Sicherheitseigenschaften erlaubt.
Zwei Korrekturen fielen zugunsten der Hersteller aus. Die USB-Stick-Konstruktion des Entwurfs für physisch vertriebene Software wurde gestrichen, und der Maßstab für komplexe Systeme wurde vom Nachrüsten in Richtung „Stand der Technik“ auf das Erreichen eines „angemessenen“ Niveaus abgesenkt. Letzteres liegt näher am risikobasierten Ansatz des Art. 13 Abs. 1 in Verbindung mit Anhang I Teil I Nr. 1, als es der Entwurf war.
2. Open Source: Die Community hat geliefert und wurde gehört
Kapitel 3 ist das deutlichste Beispiel dafür, dass die Konsultation gewirkt hat. Fast jede Änderung adressiert ein dokumentiertes Anliegen des Ökosystems.
Die FOSS-Definition hängt nicht mehr an einem „offenen Entwicklungsprozess“. Der Entwurf hatte sich auf Erwägungsgrund 18 gestützt, wonach FOSS „offen entwickelt, gepflegt und verbreitet“ wird. Die finale Fassung lässt diese Anleihe fallen und stellt allein auf die Legaldefinition in Art. 3 Nr. 48 ab: eine FOSS-Lizenz mit den vier Freiheiten plus öffentliche Verfügbarkeit des Quellcodes, upstream oder downstream. Das ist bemerkenswert, weil die Guidance hier bewusst vom Wortlaut eines Erwägungsgrunds abrückt, um zu einem praktikablen Ergebnis zu kommen. Intern entwickelte Software, die erst zum Release veröffentlicht wird, kann jetzt als FOSS gelten.
Bei den Donations zieht die Guidance durch, was Erwägungsgrund 15 anlegt: Spenden ohne Gewinnerzielungsabsicht sind keine Geschäftstätigkeit. Das schwammige Entwurfskriterium einer „Absicht, durch die Organisation von Spenden systematisch Gewinn zu erzielen“ wurde gestrichen. Übrig bleiben objektiv prüfbare Merkmale: die Konditionierung des Zugangs und vertragliche Vorteile jenseits üblicher Community-Perks. Für spendenfinanzierte Projekte auf GitHub Sponsors oder Open Collective ist das ein erheblicher Gewinn an Rechtssicherheit.
Das Open-Core-Modell wird erstmals ausdrücklich anerkannt. In Verkehr gebracht wird nur die kommerzielle Erweiterung, nicht die freie Basis, und das korrigierte Betriebssystem-Beispiel stellt klar, dass nur die Bezahl-Edition als in Verkehr gebracht gilt. Die vielleicht wichtigste neue Aussage des Kapitels beantwortet die Abwälzungs-Sorge frontal: Nicht-kommerzielle Maintainer schulden Integratoren nichts. Keine SBOMs, keine Fragebögen, keine Bescheinigungen. Die Due Diligence des Art. 13 Abs. 5 ist und bleibt Pflicht des integrierenden Herstellers, nicht des Upstream-Projekts. Art. 25 zu freiwilligen Sicherheitsbescheinigungen flankiert das, und die Guidance stellt klar, dass aus freiwillig kein faktisch verpflichtend werden darf.
Bei den Stewards (Art. 24 EU CRA) bringt die finale Fassung drei Präzisierungen. Plattform-Hosting allein löst den Steward-Status nicht mehr automatisch aus („may include“ statt „includes“). Die Vorfallsmeldepflicht des Art. 24 Abs. 3 wird auf infrastrukturbezogene Vorfälle verengt. Und, praktisch bedeutsam für Relicensing-Szenarien: Wer ein zuvor betreutes Projekt später monetarisiert, wird erst ab diesem Zeitpunkt Hersteller, ohne rückwirkende Pflichten für die Versionen aus der Steward-Ära.
Im Gegenzug entsteht eine neue Grauzone. Die Klarstellung, dass werbe-, provisions- oder abofinanzierte Apps „monetarisiert“ sind, wirft für die vielen FOSS-Projekte mit gemischten Finanzierungsmodellen frische Abgrenzungsfragen auf. Ab wann kippt ein Projekt mit optionalem Abo-Angebot in die Herstellerrolle?
3. Wesentliche Änderungen: die mutigste Auslegung des Dokuments
Dieses Kapitel enthält den folgenreichsten Positionswechsel und zugleich die rechtlich angreifbarste Stelle der Guidance. Zum Hintergrund: Nach Art. 3 Nr. 30 EU CRA ist eine wesentliche Änderung eine Änderung nach dem Inverkehrbringen, die die Konformität berührt oder die Zweckbestimmung verändert. Erwägungsgrund 39 und die Logik des New Legislative Framework legen nahe, dass ein wesentlich geändertes Produkt als neues Produkt gilt und beim erneuten Inverkehrbringen die Anforderungen erfüllen muss. Der Entwurf sagte genau das („comply with the CRA in its entirety“), und das war bislang auch die herrschende Lesart, die wir selbst im Frühjahr in unseren Friday Facts zu Bestandsprodukten und wesentlichen Änderungen so wiedergegeben haben.
Die finale Fassung kehrt das für Bestandsprodukte in Rn. 124 um. Eine wesentliche Änderung durch den Originalhersteller an einem vor dem 11. Dezember 2027 in Verkehr gebrachten Produkt verlangt nicht, das gesamte Produkt in volle EU-CRA-Konformität zu bringen, es sei denn, die Änderung beeinträchtigt die Cybersicherheit des Gesamtprodukts. Die Pflichten beschränken sich dann auf die wesentlich geänderten Teile. Anker ist der Rechtsgedanke des Art. 22 Abs. 2, der diese Teil-Logik allerdings ausdrücklich nur für Dritte vorsieht, die fremde Produkte verändern. Die Erstreckung auf den Originalhersteller ist eine teleologische Fortbildung, die der Verordnungstext nicht enthält. In der Sache ist sie richtig, denn die Entwurfsregel hätte Hersteller davon abgehalten, sicherheitsrelevante Updates an installierte Flotten auszuliefern, und damit das Ziel der Verordnung konterkariert. Rechtlich bleibt sie exponiert. Eine Marktüberwachungsbehörde, die sich auf Erwägungsgrund 39 stützt, ist an unverbindliche Guidance nicht gebunden. Hersteller sollten den Teil-Compliance-Weg deshalb rigoros dokumentieren, insbesondere die Bewertung, dass die Änderung das Gesamtprodukt nicht beeinträchtigt.
Auch die erweiterten Safe Harbours für Updates verdienen Aufmerksamkeit. Dass Sicherheitsupdates keine wesentliche Änderung darstellen, sagt der EU CRA selbst, in Art. 3 Nr. 30 in Verbindung mit Erwägungsgrund 39; dieser Teil ist bloße Bestätigung. Neu ist: Auch nicht antizipierte neue Funktionen sind unschädlich, solange sie das Risikoprofil nicht verschlechtern, nur negative Effekte zählen, und Bezugspunkt ist die aktuelle Risikobewertung, nicht die ursprüngliche. Da die Risikobewertung nach Art. 13 Abs. 3 ohnehin aktuell zu halten ist, ist dieser letzte Punkt unscheinbar formuliert, hat aber Gewicht. Wer seine Risikobewertung diszipliniert pflegt, verschiebt legitim den Maßstab, an dem künftige Updates gemessen werden.
Bei den Ersatzteilen liest die Guidance den Wortlaut des Art. 2 Abs. 6 („Ersatzteile, die identische Komponenten ersetzen“) funktional. Identisch ist, was die sicherheitsrelevanten Eigenschaften nicht verändert; ein Ersatzmodul mit anderem Chipsatz und aktualisierter Firmware kann also „identisch“ sein. Das dehnt den Begriff spürbar, ist der Realität der Komponenten-Obsoleszenz geschuldet und kehrt die Antwort um, die der Entwurf im selben Beispiel noch gegeben hatte. Es hat allerdings seinen Preis: eine neue prozedurale Hürde ohne ausdrückliche Grundlage in der Verordnung. Die Ausnahme greift nur, wenn der Reparaturzweck aus dem Lieferkontext hervorgeht, und „supporting evidence“ ist für die Marktüberwachung vorzuhalten. Was als Nachweis genügt, ob Bestellprozesse, After-Sales-Kanäle oder Einzelfalldokumentation, lässt die Guidance offen. Das ist die nächste Grauzone.
4. Supportzeitraum: kreative Lösung mit Restrisiko
Art. 13 Abs. 8 EU CRA verlangt einen Supportzeitraum, der die erwartete Nutzungsdauer abbildet, mindestens aber fünf Jahre, sofern die Nutzungsdauer nicht kürzer ist. Da jede wesentliche Änderung als neues Inverkehrbringen gilt, ließ der Entwurf eine naheliegende Anschlussfrage unbeantwortet: Startet die Fünf-Jahres-Uhr mit jedem wesentlich geänderten Release neu? Zu Ende gedacht hätte das für kontinuierlich weiterentwickelte Produkte ewige Supportpflichten bedeutet.
Der neue Abschnitt 5.1 löst das auf. Eine wesentliche Änderung löst eine Neubewertung anhand der Kriterien des Art. 13 Abs. 8 aus, führt aber nicht automatisch zu Neustart oder Verlängerung. Bleiben die nutzungsdauerbestimmenden Faktoren unberührt, etwa nach einer Backend-Neuarchitektur, während die Hardware die Lebensdauer des Produkts bestimmt, gilt die verbleibende erwartete Nutzungsdauer, ausdrücklich auch unterhalb von fünf Jahren. Nur wenn sich die bestimmenden Faktoren ändern, etwa durch revitalisierende Hardware-Modifikationen oder ein Rewrite der Kernsoftware, wird der Supportzeitraum neu berechnet.
Es gilt derselbe Vorbehalt wie oben: praktisch überzeugend, dogmatisch nicht zwingend. Der Wortlaut des Art. 13 Abs. 8 knüpft die Fünf-Jahres-Grenze an das Inverkehrbringen des Produkts, und das wesentlich geänderte Produkt ist nach der Logik des Systems ein neu in Verkehr gebrachtes. Die Rest-Nutzungsdauer-Lesart ist eine herstellerfreundliche Auslegung, die die Guidance trägt, der Verordnungstext aber nicht ausdrücklich deckt.
Geklärt wurde auch das Verhältnis zum bezahlten Support, und hier vollzieht die Guidance nur das Gesetz nach. Anhang I Teil II Nr. 8 verlangt kostenlose Sicherheitsupdates nur innerhalb der Update-Mechanik des Produkts, und Art. 13 Abs. 10 regelt den Fall auseinanderlaufender Versionen. Die Guidance folgert: Bezahlter Extended Support für ältere Versionen ist zulässig, solange der kostenlose Upgrade-Pfad offensteht. Kommerzielle LTS-Modelle stehen damit auf solidem Grund. Bemerkenswert: Die konkrete Acht-Jahres-Angabe im Smartphone-Beispiel des Entwurfs wurde durch „X Jahre“ ersetzt. Die Kommission will sichtbar keine Branchen-Benchmarks setzen und verweist stattdessen erstmals auf künftige ADCO-Guidance als Orientierungsquelle. Das ist für sich genommen eine neue Unbekannte, denn die eigentliche Konkretisierung der Supportzeiträume wird an ein Gremium delegiert, dessen Verlautbarungen noch weniger formalisiert sind als die Guidance.
5. Wichtige und kritische Produkte: Hier werden die Schrauben angezogen
Kapitel 6 ist das Gegengewicht zu den Entlastungen. Der Begriff der Kernfunktionalität, entscheidend für die Einstufung nach Art. 7 und 8 in Verbindung mit den Anhängen III und IV, wird objektiviert. Es zählen die tatsächlichen technischen Merkmale, „nicht die Art und Weise, wie das Produkt beschrieben oder vermarktet wird“. Der Entwurf hatte die eigenen Angaben des Herstellers in Anleitung und Marketing zum primären Maßstab gemacht, ein Einfallstor für die Deklassifizierung auf dem Papier, das die finale Fassung schließt. Konsequent die Ergänzung: Funktionen, die die Kernfunktionalität lediglich ergänzen oder verbessern, holen das Produkt nicht aus der Kategorie heraus. Feature-Stuffing als Klassifizierungsstrategie ist vom Tisch.
Die praktisch schärfste Neuerung ist die Modul-Regel. Werden Module einer Suite auch separat vermarktet, ob per Kauf, Lizenz oder Abo, sind sie eigenständige Produkte und einzeln einzustufen. Das neue Beispiel zeigt, was das bedeutet: Das SIEM-Modul einer Security-Suite landet in Klasse I, das Intrusion-Detection-Modul in Klasse II mit Drittprüfpflicht nach Art. 32 Abs. 3, das Analytics-Modul in der Default-Kategorie. Das Vertriebsmodell wird damit unmittelbar compliance-relevant, was zugleich eine neue Grauzone und einen Steuerungsanreiz schafft. Wer Module nur im Bundle anbietet, stuft auf Suite-Ebene ein. Ob Marktüberwachungsbehörden reine Bundling-Strategien als Umgehung werten, ist offen, aber die Anti-Umgehungs-Logik der Guidance liefert ihnen die Argumente.
Auf der Entlastungsseite entsteht die Konformitätsvermutung des Art. 27 partiell, für die von einer harmonisierten Norm abgedeckten Risiken, und nicht erst bei Vollabdeckung, wie der Entwurf nahelegte. Das entspricht gefestigter New-Legislative-Framework-Doktrin, wie sie der Blue Guide festhält, und ist damit weniger Kurswechsel als Fehlerkorrektur.
6. Remote Data Processing: Verengung mit offener Flanke
Art. 3 Nr. 2 EU CRA definiert Remote Data Processing als Datenverarbeitung aus der Ferne, deren Software vom Hersteller oder unter seiner Verantwortung entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte. Der Entwurf operationalisierte das über Datentrennung. Die finale Fassung ersetzt das durch ein klares Zwei-Ebenen-Modell: RDPS umfasst nur die Software-Module, mit denen das Produkt direkt interagiert, plus deren Schnittstellen. Nachgelagerte Systeme, im Banking-Beispiel ausdrücklich Kontoführung, Ledger, Settlement und Clearing, sind kein RDPS.
Das ist die Klarstellung, die der Finanzsektor gefordert hatte, und sie ist dogmatisch ehrlicher als der Entwurf. Die Guidance räumt offen ein, dass die Verfügbarkeit dieser Backends „für den Abschluss einer Funktion erforderlich sein kann“, nach dem reinen Wortlaut des Art. 3 Nr. 2 wären sie also durchaus erfasst. Das Kriterium der direkten Interaktion steht nicht im Verordnungstext. Es ist eine teleologische Verengung, die den Konformitätsbewertungs-Scope handhabbar macht, praktisch dringend nötig, aber nicht die einzig mögliche Lesart des Gesetzes.
Eine Änderung wirkt in die Gegenrichtung. Der Entwurf erkannte auftragsentwickelte Software nur dann als RDPS „unter Verantwortung des Herstellers“ an, wenn die Technologie dem Hersteller gehört und nicht bloß lizenziert ist. Dieser Satz wurde ersatzlos gestrichen. Maßgeblich ist jetzt allein, dass die Software von oder für den Hersteller nach dessen Designs und Spezifikationen gebaut wurde; vertragliche Konstruktionen mit dem Entwicklungsdienstleister schirmen also nicht mehr gegen die Qualifikation ab. Neu anerkannt wird außerdem das Shared-Responsibility-Modell der Cloud-Anbieter als Erfüllungsbeitrag. In der Sache deckt sich das mit dem, was risikobasierte Due Diligence nach Art. 13 Abs. 5 ohnehin erlaubt, wird aber erstmals ausdrücklich benannt.
7. Meldepflichten: Bestätigung der herrschenden Lesart, mit wertvollen neuen Ausnahmen
Kapitel 9 wurde am stärksten ausgebaut. Seine Kernaussage ist keine Überraschung, sondern konsequenter Nachvollzug dessen, worüber sich die Fachwelt längst einig war: Die Meldepflichten des Art. 14 EU CRA (Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht, jeweils an ENISA und das CSIRT über die zentrale Meldeplattform des Art. 16) gelten ab dem 11. September 2026 für alle Produkte im Scope, ausdrücklich auch für Bestandsprodukte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, und sie laufen über das Ende des Supportzeitraums hinaus.
Ein Blick ins Gesetz zeigt, warum das nie ernsthaft strittig war. Art. 71 Abs. 2 ordnet die vorgezogene Geltung des Art. 14 an, und anders als die Schwachstellenbehandlungspflichten des Anhangs I Teil II, die Art. 13 Abs. 8 an den Supportzeitraum bindet, kennt Art. 14 keine zeitliche Begrenzung. Dass die Guidance das jetzt schwarz auf weiß festhält, ist schlicht konsequent. Wir hatten diese Lesart bereits im April in unseren Friday Facts zu Bestandsprodukten vertreten. Der Wert liegt in der ausdrücklichen Bestätigung: Wer intern noch die Gegenposition vertreten hat, hat diese Verteidigungslinie jetzt endgültig verloren. Die Konsequenz bleibt bestehen. Melde-Monitoring braucht es auch für abgekündigte Produkte, allerdings ohne Patching-Pflicht, denn spiegelbildlich stellt die Guidance klar, dass für Bestands- und Post-Support-Produkte keine Pflichten aus Anhang I Teil II gelten.
Was die Meldepflicht ab dem 11. September 2026 operativ bedeutet, von Fristen und Pflichtfeldern je Meldestufe über den Kenntnisnahme-Zeitpunkt bis zu Prozesskarte und Vorbereitungs-Checkliste, haben wir in unserem Leitfaden EU-CRA-Meldepflichten: der einzige Artikel, den Sie vor dem 11. September 2026 lesen müssen Klausel für Klausel seziert. Die dort beschriebene Trennung zwischen Hinweiseingang und verifizierter Kenntnis deckt sich exakt mit der Linie der finalen Guidance. Zu den Sanktionsrisiken, Verstöße gegen Art. 14 liegen im höchsten Bußgeldrahmen, siehe unsere Übersicht der EU-CRA-Bußgelder bei Verstößen.
Abgefedert wird die Pflicht auf drei Wegen, und hier hat die Konsultation sichtbar gewirkt. Es gibt keine Rückwirkung: Vor dem Stichtag bereits bekannte aktive Ausnutzungen müssen nicht nachgemeldet werden. Es gibt eine VEX-artige Ausnahme für Schwachstellen in Drittkomponenten, die im eigenen Produkt nicht ausnutzbar sind, etwa weil der verwundbare Code nicht erreichbar ist. Das ist eine massive Entlastung gegen die CVE-Flut in Dependency-Trees, die der Entwurf noch nicht enthielt, und sie ist ohne aktuelle SBOM und sauberes Schwachstellenmanagement praktisch nicht nutzbar, denn die Ausnutzbarkeitsanalyse setzt voraus, die eigenen Komponenten zu kennen. Und OSS-Maintainer erhalten Schutz beim Upstream-Reporting nach Art. 13 Abs. 6: Gemeldet werden soll über die CVD-Kanäle des Maintainers, Duplikatsmeldungen bereits bekannter Schwachstellen sind nicht erforderlich, und das Teilen von Fixes wurde von „required“ auf „should“ abgeschwächt.
Zwei Details verdienen Aufmerksamkeit. Die Kommission hat den ausdrücklichen Verweis auf die von MITRE geführte CVE-Liste gestrichen; als Datenbank namentlich genannt bleibt nur die europäische EUVD. Vor dem Hintergrund der Debatten um die Finanzierung des US-CVE-Systems liest sich das als Signal digitaler Souveränität. Erstmals hält die Guidance außerdem fest, dass KI-gestützte Schwachstellenfunde Kenntnis begründen, relevant für die „bekannte ausnutzbare Schwachstelle“ nach Art. 3 Nr. 41 und die Pflichten vor dem Inverkehrbringen. Das ist konsequent, schafft aber einen schiefen Anreiz: Wer aggressiv mit KI-Scannern testet, produziert Kenntnis und damit Pflichten, die der zurückhaltendere Wettbewerber nicht hat. Die neue Flexibilität bei Release-Entscheidungen, bei denen die Risiken eines zurückgehaltenen Releases abgewogen werden dürfen, und das anlassbezogene statt kalenderbasierte Test-Regime des neuen Abschnitts 9.2.3 gleichen das nur teilweise aus.
Bilanz: drei Kategorien von Änderungen
Wer die finale Guidance bewertet, sollte drei Kategorien auseinanderhalten.
Die erste: Nachvollzug des Gesetzes oder der herrschenden Lesart, wichtig, aber nicht neu. Dazu gehören die SaaS-Grenze (Art. 3 Nr. 1, Erwägungsgrund 12), die Donations-Kriterien (Erwägungsgrund 15), die Unschädlichkeit von Sicherheitsupdates (Art. 3 Nr. 30), die vorgezogene Geltung der Meldepflichten für Bestandsprodukte (Art. 71 Abs. 2, unter Praktikern nie ernsthaft strittig), die Zulässigkeit von bezahltem Extended Support (Art. 13 Abs. 10, Anhang I Teil II Nr. 8) und die partielle Konformitätsvermutung (Art. 27, NLF-Doktrin).
Die zweite: echte, teils mutige Auslegung, praktisch wertvoll und rechtlich exponiert, weil der Verordnungstext sie nicht ausdrücklich trägt. Das betrifft die Teil-Compliance bei wesentlichen Änderungen durch den Originalhersteller (Erstreckung des Rechtsgedankens von Art. 22 Abs. 2 über seinen Anwendungsbereich hinaus), den Nicht-Neustart des Supportzeitraums einschließlich Unterschreitung der Fünf-Jahres-Grenze, die funktionale Lesart von „identisch“ bei Ersatzteilen (Art. 2 Abs. 6) und das Kriterium der direkten Interaktion beim RDPS (eine Verengung von Art. 3 Nr. 2). Auf diese Positionen kann man sich stützen, man sollte aber wissen, dass sie eine unverbindliche Guidance trägt und nicht der Gesetzestext, und seine Dokumentation entsprechend aufsetzen.
Die dritte: neue Grauzonen, Fragen, die die Guidance aufwirft und die es vorher nicht gab. Was ist eine „Variante“ (Rn. 14)? Wo endet „lediglich ergänzen oder verbessern“ bei der Anti-Umgehungs-Regel? Macht das Bundling separat vermarktbarer Module die Einstufung steuerbar, und ab wann wird das zur Umgehung? Welche „supporting evidence“ genügt bei Ersatzteilen? Wie weist man die „bestätigte Kenntnis“ eines Upstream-Maintainers nach, um sich die Duplikatsmeldung zu sparen? Und wie viel Konkretisierung darf man von der ADCO erwarten, an die die Guidance die Supportzeitraum-Praxis delegiert?
Was jetzt zu tun ist
Fünf Punkte gehören im dritten Quartal 2026 auf jede EU-CRA-Agenda. Das Produktportfolio gegen Abschnitt 2.2 und die Varianten-Regel prüfen: Was ist Produkt, was Dienstleistung, was zählt als eigenständige Variante? Separat vermarktete Module einzeln einstufen und die Vertriebsstruktur bewusst entscheiden, denn hier lauern ungeplante Drittprüfpflichten. Bis zum 11. September 2026 einen Art.-14-Meldeprozess aufbauen, der Bestands- und Post-Support-Produkte einschließt und die VEX-Ausnahme über eine Ausnutzbarkeitsanalyse operationalisiert; die konkrete Schritt-für-Schritt-Vorbereitung samt Checkliste steht in unserem Meldepflichten-Leitfaden, die Einordnung in den Gesamtzeitplan in der EU-CRA-Roadmap 2026/2027. Update- und Change-Prozesse an der Teil-Compliance-Logik und der laufend gepflegten Risikobewertung als Bezugspunkt ausrichten, mit belastbarer Dokumentation, gerade weil die Guidance hier über den Gesetzestext hinausgeht. Und den Ersatzteilvertrieb mit dokumentiertem Reparaturzweck aufsetzen.
Eine übergreifende Leitplanke bleibt. Die Guidance ist Orientierung, kein Freibrief. Sie bindet keine Behörde und kein Gericht, und ihre großzügigsten Passagen sind zugleich ihre angreifbarsten. Wer sich auf sie stützt, sollte das ausdrücklich und dokumentiert tun. Im Streitfall ist das zumindest ein starkes Argument für vertretbares, gutgläubiges Handeln.
Dieser Artikel beruht auf einem vollständigen Absatz-für-Absatz-Vergleich des Konsultationsentwurfs vom 3. März 2026 mit der am 27. Juli 2026 angenommenen Fassung C(2026) 5252 final sowie dem Text der Verordnung (EU) 2024/2847. Er stellt keine Rechtsberatung dar. Sprechen Sie uns an, wenn Sie die Auswirkungen auf Ihr Produktportfolio bewerten möchten.
Weiterlesen im Kunnus-Blog
- EU-CRA-Meldepflichten: Der einzige Artikel, den Sie vor dem 11. September 2026 lesen müssen
- CRA Friday Facts: Wenn der CRA auch Bestandsgeräte trifft
- Cyber Resilience Act und SaaS
- Schwachstellenmanagement unter dem EU CRA
- SBOM erstellen: Der Praxis-Leitfaden
- EU-CRA-Countdown: Compliance-Roadmap 2026–2027
- EU-CRA-Bußgelder bei Verstößen
Quellen und weiterführende Links
- EU-Kommissions-Guidance C(2026) 5252 final, Original-PDF und unser kapitelweiser Überblick
- Europäische Kommission: Cyber-Resilience-Act-Seite
- „Have your say“-Konsultationsportal mit Stakeholder-Feedback
- ORC Working Group (Eclipse Foundation): Open Source Software Stewards and the CRA
- GitHub Blog: What the EU's new software legislation means for developers