Cyber Resilience Act: Was Software-Anbieter im EU-Markt ändern müssen

Zwei Jahrzehnte lang war "secure by default" eine Marketingphrase, die ein SaaS-Anbieter verwenden konnte, ohne dass ein Regulator sich darum gekümmert hätte, ob sie der Wahrheit entsprach. Der Cyber Resilience Act beendet das. Ab 2026 behandelt die EU Cybersicherheit als Produktsicherheitseigenschaft - vergleichbar mit elektrischer Sicherheit oder Funkstörungen - und ab Dezember 2027 wird fast alle Software, die auf dem EU-Markt platziert wird, eine CE-Kennzeichnung benötigen, die durch echte Engineering-Nachweise gestützt wird. Die Verschiebung ist größer als NIS2, breiter als der AI Act, und die meisten Software-Teams haben noch nicht begonnen, sich vorzubereiten.

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) trat am 10. Dezember 2024 in Kraft. Meldepflichten für Schwachstellen und Vorfälle beginnen ab dem 11. September 2026 zu gelten, und der Großteil der inhaltlichen Verpflichtungen - grundlegende Cybersicherheitsanforderungen, Konformitätsbewertung, CE-Kennzeichnung - wird am 11. Dezember 2027 durchsetzbar. Bis dahin muss jedes "Produkt mit digitalen Elementen", das auf dem EU-Markt platziert wird, Konformität nachweisen, mit Bußgeldern bis zu 15 Millionen Euro oder 2,5% des weltweiten Umsatzes für die schlimmsten Kategorien von Verstößen.

Dieser Beitrag ist eine praktische Orientierung für technische Führungskräfte: Was gilt als betroffenes Produkt, wie behandelt die Verordnung SaaS, was bedeutet "Security-by-Default" in konkreten Engineering-Begriffen, wie die Open-Source-Ausnahme tatsächlich funktioniert, und eine CRA-Bereitschaftscheckliste, die du heute gegen deine Codebasis anwenden kannst.

Wen der CRA tatsächlich abdeckt

Der CRA gilt für "Produkte mit digitalen Elementen" - Hardware- oder Software-Produkte, deren beabsichtigte oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung umfasst. Das ist ein absichtlich weites Netz. Eingebettete Firmware, IoT-Geräte, Desktop-Anwendungen, Mobile Apps, Browser-Extensions, kommerziell ausgelieferte Bibliotheken, On-Premises-Enterprise-Software, Smart-Home-Geräte und verbundene Industriegeräte sitzen alle klar darin. Ebenso Abhängigkeiten: Wenn du eine kommerzielle Komponente auf den Markt bringst, die andere Hersteller integrieren, bist du unter dem CRA ein Hersteller in eigenem Recht.

Die Verordnung klassifiziert Produkte nach Risiko in drei Stufen. Die Standardstufe umfasst die große Mehrheit der Verbraucher- und B2B-Software und erfordert nur eine Selbstbewertung gegen die grundlegenden Cybersicherheitsanforderungen. "Wichtige" Produkte - Klasse I umfasst Passwortmanager, Browser, Netzwerkverwaltungstools und Identitätssysteme; Klasse II umfasst Hypervisoren, Firewalls, HSMs und ähnliche hochvertrauenswürdige Komponenten - erfordern entweder harmonisierte Normen oder eine Drittanbieter-Konformitätsbewertung. "Kritische" Produkte (Smart-Meter-Gateways, Smartcards für hochsichere Authentifizierung) benötigen eine europäische Cybersicherheitszertifizierung nach dem Cybersecurity Act.

Für viele Leser wird es interessant bei SaaS. Reine Cloud-Dienste werden größtenteils von NIS2 und nicht vom CRA geregelt. Aber sobald dein SaaS eine installierbare Komponente ausliefert - einen Desktop-Sync-Agent, eine Mobile App, eine Browser-Extension, eine Self-Hosted-On-Premise-Edition, ein SDK oder CLI, das du an Kunden verteilst - ist diese Komponente ein Produkt mit digitalen Elementen und fällt unter den CRA. Die Definition "Fernverarbeitungslösungen" in der Verordnung zieht auch Cloud-Backends hinein, die für ein betroffenes Produkt notwendig sind, um wie beabsichtigt zu funktionieren. Behandle die Grenze als unscharf und nimm an, dass mehr, nicht weniger deines Stacks im Scope ist.

Was "grundlegende Cybersicherheitsanforderungen" tatsächlich verlangen

Anhang I des CRA ist kurz, aber jede Anforderung entspricht erheblicher Engineering-Arbeit. Drei Blöcke stechen hervor.

Security-by-Default und Security-by-Design. Produkte müssen mit einer sicheren Standardkonfiguration ausgeliefert werden, keine unsicheren Schritte erfordern, um "zum Laufen gebracht zu werden", und die Angriffsfläche minimieren. In der Praxis bedeutet das: keine Standard-Credentials, Ports standardmäßig geschlossen, optionale Features standardmäßig deaktiviert, Principle of Least Privilege überall, und dokumentierte Hardening-Anleitungen. Wenn dein Installer einen Nutzer auffordert, "die Firewall zu deaktivieren, um fortzufahren", hast du ein Problem.

Vertraulichkeit, Integrität, Verfügbarkeit. Die Verordnung erfordert angemessene technische und organisatorische Maßnahmen über den gesamten Lebenszyklus: Verschlüsselung im Ruhezustand und bei der Übertragung mit State-of-the-Art-Algorithmen, Integritätsschutz für gespeicherte Daten und Updates, Schutz von Authentifizierungs-Credentials, Abwehr von Denial-of-Service und Ausfallsicherheit gegenüber unberechtigtem Zugriff. Sicherheitsupdates müssen kostenlos und standardmäßig automatisch für die gesamte Supportperiode geliefert werden, die Hersteller definieren müssen und die die Verordnung erwartet, mit vernünftigen Nutzererwartungen übereinzustimmen - in der Regel fünf Jahre oder die erwartete Produktlebensdauer.

Schwachstellen-Handling über die Supportperiode. Das ist die Verpflichtung, die die meisten Teams unterschätzen. Du musst einen koordinierten Schwachstellen-Offenlegungsprozess (CVD) aufrechterhalten, einen Kontaktkanal für Forscher bereitstellen, Schwachstellen "ohne Verzögerung" beheben und kostenlose Sicherheits-Patches liefern, Fixes in einem Software-Bill-of-Materials dokumentieren, und aktiv ausgenutzte Schwachstellen und schwere Vorfälle an ENISA und das zuständige nationale CSIRT melden - mit einer Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden, einer Meldung innerhalb von 72 Stunden und einem Abschlussbericht innerhalb von 14 Tagen.

Die 24-Stunden-Uhr ist kein Tippfehler. Engineering, Produkt, Recht und Kommunikation brauchen alle vorab genehmigte Playbooks, weil niemand diese um 03:00 Uhr mit einem Live-Exploit gut schreibt.

Die Open-Source-Ausnahme - und was sie nicht abdeckt

Open-Source-Software war der umstrittenste Teil des CRA. Der endgültige Text führt einen neuen Akteur ein - den "Open-Source-Software-Steward" - und stellt klar, dass die nicht-kommerzielle Entwicklung von freier und Open-Source-Software außerhalb der Verordnung liegt. Ein Maintainer, der eine Bibliothek auf GitHub aus Liebe zum Projekt veröffentlicht, wird kein Hersteller. Eine Foundation oder ein Steward, der kritische OSS betreut, hat ein leichteres, prinzipienbasiertes Set von Verpflichtungen statt des vollständigen Herstellerregimes.

Die Linie ist Monetarisierung und Integration. In dem Moment, in dem ein Unternehmen OSS kommerziell anbietet - bezahlter Support, eine gehostete Edition, eine Anbieter-Distribution, ein Hardware-Bundle - ist das kommerzielle Angebot wie jedes andere Produkt reguliert. Und wenn du als Hersteller OSS-Komponenten in dein eigenes kommerzielles Produkt integrierst, bist du für die Cybersicherheitseigenschaften dieser Komponenten in deinem ausgelieferten Produkt verantwortlich. Das wird verändern, wie mittelgroße SaaS-Teams ihren Dependency-Baum behandeln: Eine nicht gewartete transitive Abhängigkeit ist nicht länger nur ein Risikoregister-Eintrag, es ist ein CE-Kennzeichnungs-Blocker.

Eine CRA-Bereitschaftscheckliste für Software-Teams

Die meisten Teams brauchen 12 bis 18 Monate fokussierter Arbeit, um zu echter Compliance zu gelangen. Fang jetzt an. Die ersten 90 Tage sollten konkrete Artefakte produzieren, keine Slide-Decks.

Scope und Inventar. Katalogisiere jedes Produkt oder jede Produktkomponente, die du auf dem EU-Markt platzierst, jeden Vertriebskanal (direkt, OEM, App Stores, White-Label), und wo irgendein installierbares, einbettbares, herunterladbares oder selbst-hostbares Artefakt in deinem Portfolio existiert. Entscheide für jedes, ob es im CRA-Scope, im NIS2-Scope, in beiden oder in keinem ist, und dokumentiere die Begründung. Grenzfälle - Desktop-Agents, Sync-Clients, SDKs, On-Prem-Editionen - brauchen eine schriftliche Rechts-/Engineering-Position.

Software-Bill-of-Materials. Generiere eine SBOM im CycloneDX- oder SPDX-Format für jedes Release jedes betroffenen Produkts, automatisiert in CI, signiert und archiviert. Ohne eine SBOM kannst du die einzige Frage nicht beantworten, die bei einem Log4Shell-ähnlichen Vorfall zählt: "Sind wir betroffen?" Ein ernsthaftes Code-Quality-Audit findet Dependency-Hygiene in der Regel als den schwächsten Link, noch vor der Architektur.

Schwachstellen-Handling. Veröffentliche eine security.txt und eine koordinierte Offenlegungsrichtlinie. Richte ein überwachtes security@-Postfach ein, eine CVE-Nummerierungsvereinbarung (du bist berechtigt, CNA zu werden, sobald du einen Prozess hast), und ein Service-Level für Triage und Patching. Verdrahte die Vorfallsmeldung in dein On-Call-Runbook mit expliziten Eigentümern für die 24-Stunden-ENISA-Frühwarnung.

Secure-by-Default-Review. Führe eine fokussierte Review von Installations-Defaults, Standard-Credentials, standardmäßig offenen Ports, Standard-Telemetrie und dem kleinsten notwendigen Feature-Set zum Start durch. Alles, was einen Nutzer erfordert, die Sicherheit zu schwächen, um das Produkt zu nutzen, muss neu gestaltet, nicht drum-herum-dokumentiert werden.

Update-Infrastruktur. Bestätige, dass du signierte, automatische Sicherheitsupdates an jede unterstützte Installation über die deklarierte Supportperiode liefern kannst. Für Long-Tail-Self-Hosted-Kunden tauchen hier oft unangenehme Wahrheiten auf - air-gapped Installationen, aufgegebene Versionen, vendored Forks. Definiere dein Support-Fenster und beende es explizit für alles andere.

Konformitätsbewertungspfad. Für Standardstufen-Produkte: Bereite technische Dokumentation, eine EU-Konformitätserklärung und einen CE-Kennzeichnungsprozess vor. Für Klasse-I/II-Produkte: Plane harmonisierte Normen oder die Bewertung durch eine benannte Stelle. Budgetiere ein Jahr für Dokumentationsarbeit allein.

Legacy- und erworbener Code. Hier wird die Engineering-Rechnung real. PHP-5-ära-Code, aufgegebene Forks, Drittanbieter-Plugins, die dein Team nicht mehr neu aufbauen kann, Windows-Installer, die seit drei Jahren niemand angefasst hat - keines davon wird ohne Sanierung als CE-gekennzeichnetes Produkt ausgeliefert. Wenn dein Portfolio irgendetwas in dieser Kategorie enthält, braucht dedizierte Legacy-Code-Modernisierungsarbeit einen Slot im Roadmap 2026.

Der strategische Rahmen

Der CRA ist keine Checklistenübung - er ist eine strukturelle Veränderung darin, wie Software-Haftung in Europa funktioniert. Ab Ende 2027 hört "Wir haben es gepatcht, als wir es herausgefunden haben" auf, eine vertretbare Haltung zu sein. Versicherungsprämien, Enterprise-Procurement-Fragebögen und öffentliche Ausschreibungen werden alle CRA-Dokumentation anfragen, bevor sie nach Feature-Listen fragen.

Die Unternehmen, die gut aus dieser Situation hervorgehen, sind die, die die nächsten 18 Monate als erzwungene Gelegenheit behandeln, Security-Engineering zu professionalisieren: echte SBOMs, echtes Schwachstellen-Handling, echte Update-Kanäle, echte Defaults. Der größte Teil dieser Arbeit ist das, was ein kompetentes Engineering-Team bereits tun sollte - die Verordnung beendet lediglich die Ära, in der das Überspringen kostenlos war.

Wenn du als technische Führungskraft in einem europäischen Software-Unternehmen noch unsicher bist, wie der CRA auf dein spezifisches Produkt-Portfolio zutrifft, ist das ein nützliches Gespräch, das früh geführt werden sollte. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io - 18 Jahre europäische Software-Arbeit, einschließlich erheblicher Legacy-Modernisierung unter Regulierungsdruck, stecken hinter jeder Empfehlung, die wir machen.