Cyber Resilience Act: Was die neue Leitlinie der EU-Kommission für Hersteller konkret bedeutet

Am 27. Juli 2026 hat die Europäische Kommission den Entwurf ihrer Leitlinie zur Anwendung des Cyber Resilience Act (Verordnung (EU) 2024/2847) gebilligt. Auf 83 Seiten beantwortet das Dokument genau die Fragen, an denen sich Produktverantwortliche seit Monaten abarbeiten: Wann gilt Software als „in Verkehr gebracht"? Wann macht ein Update eine neue Konformitätsbewertung nötig? Wann ist die eigene Cloud Teil des Produkts?

Die Leitlinie ist rechtlich nicht bindend, denn verbindlich auslegen kann den CRA nur der EuGH. Sie zeigt aber, wie die Kommission die Verordnung versteht, und Marktüberwachungsbehörden werden sich daran orientieren. Wer sein Compliance-Programm gerade aufsetzt, sollte die Kernaussagen kennen.

Die Fristen, die zählen

Drei Daten strukturieren die gesamte Umsetzung:

• 11. September 2026: Die Meldepflichten nach Artikel 14 greifen. Und zwar für alle Produkte im Anwendungsbereich, auch für solche, die vor der vollen Anwendung des CRA in Verkehr gebracht wurden. Diese Pflicht endet auch dann nicht, wenn der Supportzeitraum eines Produkts ausgelaufen ist.

• 11. Dezember 2027: Der CRA gilt vollständig. Ab hier braucht jedes neu in Verkehr gebrachte Produkt Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung.

• 11. Juni 2028: EU-Baumusterprüfbescheinigungen aus anderen Harmonisierungsrechtsakten verlieren ihre Übergangswirkung.

Der erste Termin ist der unterschätzte. Er ist in wenigen Wochen erreicht und verlangt funktionierende interne Prozesse: Wer bewertet einen gemeldeten Vorfall? Wer entscheidet, ob eine Schwachstelle aktiv ausgenutzt wird? Wer meldet binnen 24 Stunden an ENISA und das koordinierende CSIRT?

Anwendungsbereich: Wann Software „in Verkehr gebracht" ist

Bei Hardware ist das Inverkehrbringen ein eingespieltes Konzept. Bei eigenständiger Software war bislang unklar, ob jeder einzelne Download ein neues Inverkehrbringen darstellt. Die Kommission stellt klar: Nein. Sobald die Herstellungsphase abgeschlossen ist und die Software erstmals zum Vertrieb oder zur Nutzung angeboten wird, gelten alle Kopien dieser Version als gleichzeitig in Verkehr gebracht, unabhängig davon, wann der einzelne Nutzer sie herunterlädt.

Zwei Einschränkungen sind wichtig:

Was kein Produkt mit digitalen Elementen ist

Die Abgrenzung verläuft entlang der Frage, wo die Software ausgeführt wird. Entscheidend ist, dass sie dem Nutzer bereitgestellt wird und auf dessen System läuft.

Erfasst	Nicht erfasst
Mobile App aus dem App Store	Web-App, die ausschließlich im Browser läuft
Desktop-Anwendung, auch wenn mit Webtechnologie gebaut	Progressive Web App im Browser
Browser-Erweiterung	Website, die nur Informationen darstellt
Lokal installierter Client einer Cloud-Anwendung

Websites fallen nur dann in den Anwendungsbereich, wenn sie eine Funktion eines Produkts unterstützen und damit als Remote-Datenverarbeitung qualifizieren. Ein Authentifizierungsportal, das für den Betrieb nötige Token ausstellt, ist erfasst. Eine Seite mit der Bedienungsanleitung nicht, auch dann nicht, wenn das Produkt dorthin verlinkt.

Hardware und Software gehören zusammen

Maßgeblich ist nicht der Vertriebsweg, sondern ob die Software für die bestimmungsgemäße Funktion nötig ist. Der Netzwerkdrucker und die von der Website geladenen Treiber sind ein Produkt. Das Fitness-Wearable und die zugehörige App, ohne die sich weder Messwerte anzeigen noch das Gerät konfigurieren lässt, ebenfalls.

Quellcode

Quell- und Maschinencode sind beide „Software" im Sinne des CRA. Aber: Wer Code auf einem öffentlichen Repository teilt, unfertigen Code zum Testen bereitstellt oder Beispielcode in Tutorials veröffentlicht, bringt nichts in Verkehr. Wer hingegen Quellcode als Produkt an Kunden lizenziert, schon, und zwar auch dann, wenn der Kunde ihn noch anpassen und kompilieren muss.

Free and Open Source Software: das umfangreichste Kapitel

Der CRA erfasst FOSS nur, wenn sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Die Leitlinie arbeitet sich in drei Schritten vor.

Erstens: Ist es überhaupt FOSS? Artikel 3 Nr. 48 verlangt kumulativ eine freie Lizenz mit allen Rechten und öffentlich geteilten Quellcode. Software unter freier Lizenz, deren Quellcode nur zahlende Kunden erhalten, ist im Sinne des CRA keine FOSS.

Zweitens: Liegt sie in meiner Verantwortung? Maßgeblich sind die Maintainer, also diejenigen, die veröffentlichen und primäre Kontrolle über Entwicklung, Releases und Vertriebsentscheidungen ausüben. Wer Code beisteuert, ohne Releases, Roadmap oder Governance zu steuern, ist Contributor und trägt keine Pflichten. Commit-Rechte allein begründen keine Verantwortung.

Drittens: Wird sie kommerziell bereitgestellt? Hier wird es praxisrelevant:

• Preis verlangen → Inverkehrbringen. Wer daneben eine kostenlose Community-Version anbietet: Die ist nicht in Verkehr gebracht, für sie greifen bei juristischen Personen aber die Steward-Pflichten.
• Andere Dienste monetarisieren → Inverkehrbringen. Der Open-Source-Marktplatz mit Provisionen, das kostenlose VPN mit kostenpflichtigen Zusatzservern.
• Bezahlte Supportleistungen → kommt darauf an. Frei herunterladbare Software plus optionale Beratung: kein Inverkehrbringen. Eine kostenpflichtige Enterprise-Edition mit technischem Support: Inverkehrbringen. Entscheidend ist, ob der Zugang zur Software selbst von einer Vergütung abhängt.
• Spenden → grundsätzlich kein Inverkehrbringen, selbst wenn die Summen die Entwicklungskosten übersteigen. Die Grenze verläuft dort, wo Spenden faktisch zum Preis werden: Wenn Releases, Binaries oder Sicherheitsupdates nur Spendern zur Verfügung stehen, liegt Inverkehrbringen vor.
• Fremdfinanzierung → irrelevant. Dass ein Unternehmen ein Feature bezahlt hat, ändert nichts am Status der Software.
• Gemeinnützige Träger, deren Einnahmen nach Kosten gemeinnützigen Zwecken dienen → kein Inverkehrbringen; sie sind Steward.

Die Rolle des Open-Source-Software-Stewards

Der Steward ist eine juristische Person, die FOSS systematisch und nachhaltig unterstützt, deren Lebensfähigkeit sichert und die für kommerzielle Zwecke bestimmt ist, ohne sie selbst in Verkehr zu bringen. Ihn treffen nur die Pflichten aus Artikel 24, und diese sind nach Unterstützungstiefe gestaffelt:

• Nur nicht-technische Unterstützung (Branding, Governance, Community-Events): keine Meldepflicht für ausgenutzte Schwachstellen, keine Vorfallmeldung. Erlangt der Steward dennoch Kenntnis, soll er die Maintainer informieren.
• Bereitstellung der IT-Infrastruktur (Repository-Hosting, Versionskontrolle, Signaturschlüssel): Meldepflicht für schwere Vorfälle an ENISA und CSIRTs.
• Engineering-Ressourcen (angestellte Entwickler, Release-Management, Bearbeitung von Schwachstellenmeldungen): volle Meldepflicht für aktiv ausgenutzte Schwachstellen.

Dieselbe Organisation kann für ein Projekt Steward und für ein anderes Hersteller sein. Die Prüfung erfolgt projektbezogen.

Für Integratoren gilt: Wer FOSS-Komponenten in eigene Produkte einbaut, wird nicht für deren Konformität verantwortlich, schuldet aber Sorgfalt nach Artikel 13 Abs. 5 und muss Schwachstellen nach Artikel 13 Abs. 6 upstream melden.

Wesentliche Veränderung: die Zwei-Fragen-Prüfung

Eine wesentliche Veränderung liegt vor, wenn eine Änderung nach dem Inverkehrbringen entweder die Konformität mit den wesentlichen Anforderungen berührt oder die Zweckbestimmung ändert. Die Folge: Das Produkt gilt als neu und wird bei Bereitstellung neu in Verkehr gebracht.

Bei Software hat die Kommission vier Prüfkriterien formuliert. Führt das Update

1. neue Bedrohungsvektoren ein (Schnittstellen, Kommunikationskanäle, externe Abhängigkeiten)?
2. neue Angriffsszenarien?
3. zu veränderter Eintrittswahrscheinlichkeit bekannter Szenarien?
4. zu veränderter Auswirkung bekannter Szenarien?

Viermal Nein spricht gegen eine wesentliche Veränderung.

Zwei Punkte verdienen Aufmerksamkeit:

Umfang ist kein Kriterium. Ein „Angemeldet bleiben"-Feature, das Authentifizierungstoken lokal speichert, kann eine wesentliche Veränderung sein, weil Token-Diebstahl und Session-Hijacking nicht bewertet waren. Ein neues Diagnose-Log, das sensible Betriebsdaten unverschlüsselt ablegt, ebenso.

Sicherheitsupdates sind grundsätzlich keine wesentliche Veränderung, auch bei erheblichen technischen Eingriffen. Das gilt für Bugfixes, verschärfte Firewall-Regeln, erzwungene Mehrfaktor-Authentifizierung oder die Abschaltung veralteter Krypto-Algorithmen. Die Ausnahme greift, wenn das Update die Zweckbestimmung verschiebt oder neue Abhängigkeiten schafft: Wer lokale Dateiverschlüsselung durch einen eigenen Remote-Dienst ersetzt oder auf einen externen Key-Management-Dienst umstellt, verändert wesentlich.

Wer modifiziert, wird Hersteller, allerdings verhältnismäßig. Berührt die Veränderung die Sicherheit des Gesamtprodukts nicht, beschränken sich die Pflichten auf den geänderten Teil. Der Originalhersteller bleibt für den unveränderten Rest zuständig. Auch der Originalhersteller darf vorhandene Dokumentation und Tests für nicht betroffene Teile wiederverwenden.

Ersatzteile sind nach Artikel 2 Abs. 6 ausgenommen, wenn sie identisch und nach denselben Spezifikationen gefertigt sind. „Identisch" bemisst sich nach der funktionalen Rolle und den sicherheitsrelevanten Eigenschaften. Abweichende kryptografische Implementierungen oder ein anderer Secure-Boot-Mechanismus brechen die Identität. Wichtig: Der Reparaturzweck muss aus dem Kontext erkennbar sein, etwa durch Produktidentifikation im Angebot oder Lieferung über After-Sales-Kanäle.

Supportzeitraum: Fünf Jahre sind kein Standardwert

Der CRA verlangt mindestens fünf Jahre, doch die Kommission stellt klar, dass dies nur eine Untergrenze ist. Maßgeblich ist die erwartete Nutzungsdauer, bemessen an der Produktnatur, berechtigten Nutzererwartungen und einschlägigem Unionsrecht. Produkte, die erwartbar länger genutzt werden, brauchen längere Supportzeiträume.

Artikel 13 Abs. 10 verschafft Softwareherstellern Luft: Schwachstellen müssen nur in der zuletzt in Verkehr gebrachten Version behoben werden, sofern Nutzer kostenlos und ohne Zusatzkosten upgraden können. „Zusatzkosten" meint dabei nicht den normalen Betriebsaufwand: Personalzeit, Tests und Konfigurationsanpassungen zählen nicht dazu. Gemeint sind Hardwarekäufe oder grundlegende Infrastrukturwechsel.

Eine wesentliche Veränderung setzt den Supportzeitraum nicht automatisch zurück. Zu prüfen ist, ob sie die Faktoren berührt, die die Nutzungsdauer ursprünglich bestimmt haben. Ein Software-Update am Saugroboter ändert nichts an der physischen Haltbarkeit der Hardware, der ursprüngliche Zeitraum läuft also weiter. Wird dagegen die Rechenplattform einer SPS gegen eine Generation mit deutlich längerer Lebensdauer getauscht, ist neu zu rechnen.

Wichtige und kritische Produkte: die Kernfunktionalität entscheidet

Ob ein Produkt in Anhang III oder IV fällt, hängt an seiner Kernfunktionalität, also den Hauptmerkmalen, ohne die die Zweckbestimmung nicht erreichbar wäre. Beurteilt wird anhand von Bedienungsanleitung, Werbematerial und technischer Dokumentation.

Vier Klarstellungen:

• Ein Produkt hat genau eine Kernfunktionalität. Sie ist in der technischen Dokumentation zu benennen.
• Integration allein reicht nicht. Ein Smartphone mit Betriebssystem hat nicht die Kernfunktionalität eines Betriebssystems.
• Über- und Unterschreitung sind möglich. SOAR-Software geht über SIEM hinaus, ein Log-Viewer ohne Korrelation bleibt darunter. Beide sind keine SIEM-Systeme.
• Getrennt vermarktete Module sind eigene Produkte. Wer eine Security-Suite auch modulweise verkauft, klassifiziert jedes Modul einzeln.

Eine Fehldarstellung der Kernfunktionalität, um dem strengeren Verfahren zu entgehen, kann Bußgelder nach Artikel 64 Abs. 3 auslösen, erkennbar etwa an Widersprüchen zwischen Werbematerial und technischer Dokumentation.

Zur Konformitätsvermutung: Eine harmonisierte Norm trägt die Vermutung nur für die von ihr abgedeckten Risiken. Ein Virenscanner mit zusätzlicher Festplattenbereinigung und Anti-Tracking darf zwar die interne Kontrolle nutzen, wenn die Norm die Kernfunktionalität abdeckt. Für die Zusatzfunktionen gilt die Vermutung aber nicht.

Risikobewertung: Was nicht zählt

Die vielleicht schärfste Aussage der Leitlinie betrifft die Risikoakzeptanz. Im betrieblichen Risikomanagement wird gegen den eigenen Risikoappetit bewertet. Unter dem CRA gilt das ausdrücklich nicht:

Die interne Risikotoleranz des Herstellers, seine Geschäftsstrategie oder bloße Kostenerwägungen sind für die Frage, ob Risiken hinreichend adressiert wurden, ohne Bedeutung.

Restrisiko ist unvermeidbar, aber nicht nach Belieben akzeptierbar. Ebenso wenig lässt sich Risiko auf Nutzer oder Dritte verlagern, um Designdefizite auszugleichen. Wo sich identifizierte Risiken nicht angemessen behandeln lassen, kann Konformität Änderungen an Design, Funktionalität oder Zweckbestimmung erfordern.

Erleichterung bei Produktfamilien: Varianten mit gleicher Architektur, gleichem sicherheitsrelevantem Design und gleichem Risikoprofil dürfen mit einer Risikobewertung, einer technischen Dokumentation, einer Konformitätsbewertung und einer EU-Konformitätserklärung abgedeckt werden. Unterschiede in Farbe, Formfaktor oder Speichergröße sind unerheblich; abweichende Kommunikationsschnittstellen oder Update-Mechanismen nicht.

Remote-Datenverarbeitung: zwei Fragen, kumulativ

Ob die eigene Cloud Teil des Produkts ist, entscheiden zwei Fragen, die beide bejaht werden müssen:

1. Würde ihr Fehlen das Produkt daran hindern, eine seiner Funktionen zu erfüllen? Erfasst sind nicht nur Kernfunktionen: Befehle senden, Dateien synchronisieren, Nutzer-Onboarding, Konfiguration, automatische Update-Verteilung, Identitäts- und Zugriffsverwaltung. Rein statistische Telemetrie fällt heraus.
2. Wurde die Software vom Hersteller oder unter seiner Verantwortung entwickelt? „Unter seiner Verantwortung" meint maßgeschneiderte Lösungen, nicht das bloße Lizenzieren eines fertigen Angebots.

Daraus folgt für die gängigen Cloud-Modelle:

• IaaS von Dritten: Die eigene Software darauf ist RDPS.
• PaaS von Dritten: Die eigene Anwendung ist RDPS.
• SaaS von Dritten: kein RDPS, aber wie eine Drittkomponente zu behandeln, also Risiken bewerten, auf Produktebene mitigieren, Sorgfalt ausüben.

Wer betreibt, ist irrelevant. Der CRA knüpft an Design und Entwicklung an, nicht an den Betrieb.

Nur direkt interagierende Module zählen. Bei einer Banking-App ist das Banking-Interface RDPS; die dahinterliegenden Konto- und Ledger-Systeme, mit denen die App nicht direkt kommuniziert, sind es nicht. Sie bleiben aber externe Abhängigkeiten, deren Risiken auf Produktebene zu adressieren sind, etwa durch Integritätsschutz der Transaktionsdaten und Validierung der Antworten.

Nicht erfasst sind die allgemeine Unternehmens-IT (HR, Payroll, CRM, CI/CD-Pipelines) sowie Audit- und Testaktivitäten wie Penetrationstests oder Red Teaming. Auch das Mobilfunknetz ist kein RDPS, sondern bloßer Kommunikationskanal, weshalb gegenüber dem Netzbetreiber keine Sorgfaltspflicht besteht.

Nachweise lassen sich wiederverwenden: NIS-2-Nachweise nach Durchführungsverordnung (EU) 2024/2690, DORA-Nachweise, EU-Cybersicherheitszertifikate sowie ISO/IEC 27001:2022 und 27017:2015.

Meldepflichten: der Countdown läuft

Ab dem 11. September 2026 sind aktiv ausgenutzte Schwachstellen und schwere Vorfälle gleichzeitig an das koordinierende CSIRT und ENISA zu melden. Der Ablauf ist gestuft: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Abhilfemaßnahme (bei Schwachstellen) beziehungsweise binnen eines Monats nach der 72-Stunden-Meldung (bei Vorfällen).

„Kenntnis erlangt" bedeutet: nach einer ersten Bewertung mit hinreichender Gewissheit. Die Kommission betont die Pflicht zur zügigen Erstbewertung: Ein Hinweis von außen darf nicht liegen bleiben.

Keine Rückwirkung: Wer vor dem 11. September 2026 bereits von einer aktiven Ausnutzung wusste, muss nicht nachmelden. Wer eine Schwachstelle kannte, aber nichts von einer Ausnutzung, ist meldepflichtig, sobald diese danach eintritt oder bekannt wird.

Drittkomponenten: Meldepflichtig sind nur Schwachstellen, die im eigenen Produkt tatsächlich ausnutzbar sind und ausgenutzt werden. Ist der verwundbare Code nicht erreichbar, entfällt die Pflicht. Schwachstellenbehandlung und Upstream-Meldung bleiben davon unberührt.

Nutzerinformation ist risikobasiert. Sie verlangt keine unterschiedslose Veröffentlichung. Bei Produkten in sensiblen Umgebungen kann eine Beschränkung auf betroffene Kunden angezeigt sein; breitere Offenlegung folgt, sobald die Schwachstelle behoben ist.

Was jetzt zu tun ist

1. Meldeprozess bis September 2026 aufsetzen. Zuständigkeiten, Erstbewertung, Eskalationspfad, Kontaktwege zu ENISA und CSIRT. Dies ist die erste harte Frist.
2. Produktinventar erstellen und je Produkt die Kernfunktionalität bestimmen, denn sie entscheidet über das Konformitätsbewertungsverfahren.
3. RDPS-Analyse durchführen. Zwei Fragen je Backend-Komponente, Ergebnis in der technischen Dokumentation festhalten.
4. Kriterien für wesentliche Veränderungen in den Release-Prozess integrieren, damit Produktteams die Prüfung nicht ad hoc machen.
5. Supportzeiträume begründet festlegen, nicht reflexhaft fünf Jahre, und das Enddatum kaufzeitpunktbezogen kommunizieren.
6. FOSS-Rollen klären: Wo sind wir Hersteller, wo Steward, wo bloß Contributor? Für integrierte Komponenten die Sorgfaltsdokumentation aufbauen.
7. Altzertifikate prüfen. RED- oder Maschinen-Zertifikate tragen bis 11. Juni 2028, aber nur für die dort abgedeckten Risiken. Die Lücken müssen identifiziert und geschlossen werden.

Quelle: Europäische Kommission, C(2026) 5252 final vom 27. Juli 2026, Anhang: Entwurf einer Mitteilung der Kommission mit Leitlinien zur Anwendung der Verordnung (EU) 2024/2847 (Cyber Resilience Act). Die Leitlinie ist für Wirtschaftsakteure nicht bindend; eine verbindliche Auslegung des CRA obliegt allein dem Gerichtshof der Europäischen Union. Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall.