Cyber Resilience Act: was die Verordnung an Software auferlegt und seit wann

Kurz gesagt:

• Seit dem 11. September 2026: Jeder Hersteller eines Produkts mit digitalen Elementen muss der ENISA aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden. Die Fristen sind eine Benachrichtigung innerhalb von 24 h, eine Meldung innerhalb von 72 h und dann ein Schlussbericht innerhalb von 14 Tagen nach Bereitstellung eines Patches.
• Ab dem 11. Dezember 2027: Das Inverkehrbringen im europäischen Markt wird an die Anforderungen der Verordnung geknüpft sein. Es geht um Sicherheit durch Design und Standardeinstellungen, das Fehlen bekannter, ausnutzbarer Schwachstellen, ein Inventar von Softwarekomponenten (SBOM, Software Bill of Materials), Sicherheitskorrekturen während mindestens fünf Jahren nach der ersten Inverkehrbringung und eine koordinierte Richtlinie zur Offenlegung von Schwachstellen, die es Dritten ermöglicht, eine Lücke zu melden.

Als Tech- und AI-Partner von über 800 Unternehmen entwickelt und pflegt Galadrim zahlreiche Software und Anwendungen. Bei diesen Projekten wenden unsere Ingenieure bereits die bewährten Praktiken an, die der Cyber Resilience Act (CRA) nun vorschreibt: Sicherheit durch Design, sichere Entwicklung, Verwaltung von Abhängigkeiten, Überwachung von Schwachstellen, schnelle Bereitstellung von Korrekturen und Aufrechterhaltung der Sicherheit. Sie sind jedoch noch wenig verbreitet, und viele Anwendungen müssen konform gemacht werden. Diese Verantwortung obliegt dem Hersteller, das heisst dem Unternehmen, das das Produkt unter seinem Namen vermarktet und das die Verordnung als Hersteller bezeichnet.

Ein Simulator, weiter unten im Artikel, zeigt Ihnen, ob Ihr Produkt betroffen ist.

Was der CRA von einem digitalen Produkt verlangt

Der Cyber Resilience Act ist eine europäische Verordnung, die wie die DSGVO direkt anwendbar ist. Er wurde am 12. März 2024 vom Europäischen Parlament angenommen. Es ist der erste europäische Rechtsakt, der Cybersicherheitsanforderungen für alle «Produkte mit digitalen Elementen» vorschreibt.

Nur die Meldepflicht ist seit dem 11. September 2026 in Kraft; die Sicherheitsanforderungen gelten ab dem 11. Dezember 2027.

Seit dem 11. September 2026: Die Meldepflicht

Der Hersteller muss zwei Arten von Ereignissen melden:

• eine aktiv ausgenutzte Schwachstelle, das heisst, wenn zuverlässige Anhaltspunkte darauf hindeuten, dass ein böswilliger Akteur sie zur Kompromittierung eines Systems genutzt hat;
• ein schwerwiegender Vorfall, das heisst ein Ereignis, das den Datenschutz und die Funktionen des Produkts bedroht oder bösartigen Code einschleust.

Die Meldung muss über die einheitliche Meldeplattform der ENISA. Ab der Identifizierung des Vorfalls oder der Schwachstelle sind Sie verpflichtet, folgende Fristen einzuhalten:

• 24 h: Frühwarnung;
• 72 h: Detaillierte Meldung, mit der Art der Ausnutzung, den Korrekturmassnahmen und den empfohlenen Massnahmen für die Nutzer;
• Schlussbericht: 14 Tage nach Bereitstellung eines Patches für eine Schwachstelle oder einen Monat nach der Meldung für einen Vorfall.

Der Anbieter muss auch die betroffenen Nutzer über die Schwachstelle oder den Vorfall informieren und über die Massnahmen, die zum Schutz davor zu ergreifen sind, in einem strukturierten und maschinenlesbaren Format.

Die Einhaltung der 24-h-Frist setzt voraus, jederzeit zu wissen, welche Produktversionen im Einsatz sind und welche Komponenten jeweils enthalten sind, das Backend zu überwachen, um eine Ausnutzung zu erkennen, und über einen Meldeprozess mit einem benannten Verantwortlichen zu verfügen.

Möchten Sie sich vorbereiten, oder ist Ihr Produkt von einer Sicherheitslücke betroffen? Unsere Teams helfen Ihnen, sich zu organisieren, um innerhalb der Fristen zu melden und zu korrigieren. Sprechen Sie mit unseren Experten

Ab dem 11. Dezember 2027: Die Sicherheitsanforderungen

Der Hersteller darf nur ein Produkt in Verkehr bringen, das den Anforderungen der Verordnung entspricht. Er muss:

• ein Produkt standardmässig sicher gestalten: sichere Konfiguration ab der Installation, reduzierte Angriffsfläche, Zugriffe und Daten geschützt durch Authentifizierung, Verschlüsselung und Protokollierung;
• ein Produkt ohne bekannte, ausnutzbare Schwachstellen liefern, was für alle enthaltenen Abhängigkeiten überprüft wird, nicht nur für den intern entwickelten Code;
• eine SBOM führen, das maschinenlesbare Inventar der Produktkomponenten;
• jede Schwachstelle sofort nach ihrer Entdeckung beheben, durch kostenlose Sicherheitsupdates, die von funktionalen Weiterentwicklungen getrennt sind;
• diese Updates sicher verbreiten, zum Beispiel signiert, damit das Gerät überprüfen kann, dass sie tatsächlich vom Hersteller stammen;
• diese Überwachung für mindestens fünf Jahre nach der ersten Inverkehrbringung sicherstellen;
• eine koordinierte Offenlegungsrichtlinie für Schwachstellen veröffentlichen: eine Kontaktstelle und ein Verfahren, damit Dritte ihm eine Schwachstelle melden können.

Diese bewährten Praktiken wenden wir bei den Softwares an, die wir entwickeln und warten.

Warum Compliance zuerst eine technische Aufgabe ist

Die Abhängigkeiten. Eine Applikation enthält Hunderte von Open-Source-Komponenten, von der Sprache bis zu den Bibliotheken. Jede kann eine Schwachstelle einführen, durch Fehler oder absichtlich während eines Angriffs auf die Lieferkette (supply chain attack). Sobald bekannt, kann die Schwachstelle automatisch auf allen nicht aktualisierten Versionen ausgenutzt werden: die PHP2Shell Schwachstellen, veröffentlicht am 21. Oktober 2026, wurden sofort nach ihrer Offenlegung ausgenutzt. Bei einem alten Projekt erfordert die Korrektur oft ein Versions-Upgrade eines Frameworks, das nicht mehr gewartet wird.

Die kontinuierliche Überwachung. Während der gesamten Support-Periode müssen die veröffentlichten Schwachstellen (CVE, Hinweise des CERT-FR) für jede Komponente überwacht werden.

Mit dem Aufkommen von AI in der Entwicklung steigt das produzierte Code-Volumen, und AI-gestützte Analysetools erkennen Schwachstellen immer schneller. Der Engpass wird zur Behebung: Sortieren, Beheben, Testen und Bereitstellen auf allen im Umlauf befindlichen Versionen vor der Ausnutzung.

Wir können diese Praktiken bei Ihrem Produkt implementieren oder Ihre Teams begleiten. Sprechen Sie mit unseren Experten

Ist Ihr Produkt betroffen?

Der CRA gilt für Produkte mit digitalen Elementen, die im Rahmen einer kommerziellen Tätigkeit in der Europäischen Union verkauft oder vertrieben werden. Ein Produkt ist betroffen, wenn der Nutzer eine Software auf seinem Gerät installiert. Dies ist der Fall bei einer mobilen Applikation, einer Desktop-Anwendung, einer Browser-Erweiterung, einer auf den Servern des Kunden bereitgestellten Software oder einer eingebetteten Software eines vernetzten Objekts. Die für die Funktion dieser Software unerlässlichen Server sind ebenfalls betroffen, zum Beispiel das Backend einer mobilen Applikation oder ihr Zahlungsmodul. Ausgeschlossen sind:

• Web-Anwendungen, die ausschliesslich im Browser genutzt werden, ohne etwas installieren zu müssen, es sei denn, sie sind für die Funktion einer betroffenen Software unerlässlich;
• Software, die ausschliesslich intern entwickelt und genutzt wird;
• Produkte, die unter eine sektorspezifische Regulierung fallen: Medizinprodukte, Fahrzeuge, zertifizierte Luftfahrt, Schiffsausrüstung und Verteidigung.

Das Unternehmen, das das Produkt vermarktet, ist für dessen Konformität verantwortlich, aber der für die Entwicklung zuständige Dienstleister hat auch Pflichten: die SBOM bereitzustellen, Schwachstellen fristgerecht zu beheben und den Support über die vorgesehene Dauer sicherzustellen.

Für ein bereits vermarktetes Produkt gilt die Meldepflicht ab heute. Die Anforderungen von 2027 gelten nur bei einer wesentlichen Änderung nach dem 11. Dezember 2027, d.h. einer Entwicklung, welche die vorgesehene Nutzung des Produkts ändert oder dessen Konformität beeinträchtigt. Sicherheitskorrekturen gehören nicht dazu.

Verstösse können mit einer Busse von bis zu 15 Mio. € oder 2,5 % des weltweiten Umsatzes geahndet werden und zum Rückzug des Produkts vom Markt führen.

Simulator: Ist Ihr Produkt betroffen?

Beantworten Sie vier Fragen, um herauszufinden, ob der CRA auf Ihr Produkt zutrifft.

Über diese Diagnose hinaus begleiten wir Unternehmen bei der gesamten Umsetzung ihrer Konformität, vom Audit bis zur Korrektur der Schwachstellen. Sprechen Sie mit unseren Experten

Glossar

• Schwachstelle : Schwachstelle eines IT-Systems, die es einem Angreifer ermöglicht, dessen normale Funktion zu beeinträchtigen oder die Vertraulichkeit oder Integrität der darin enthaltenen Daten zu gefährden (ANSSI).
• Schwachstelle : Schwäche oder Mangel eines Produkts, der durch eine Bedrohung ausgenutzt werden kann.
• Aktiv ausgenutzte Schwachstelle : Schwachstelle, bei der zuverlässige Anhaltspunkte darauf hindeuten, dass ein böswilliger Akteur sie ohne die Genehmigung des Systeminhabers genutzt hat.
• Schwerwiegender Vorfall : Ereignis, das die Verfügbarkeit, Integrität oder Vertraulichkeit von Daten oder Funktionen eines Produkts beeinträchtigt oder beeinträchtigen kann oder das bösartigen Code einschleust.
• SBOM (Software Bill of Materials) : formales Inventar der Softwarekomponenten, ihrer Versionen und ihrer Abhängigkeiten.
• CVE (Common Vulnerabilities and Exposures) : standardisierter öffentlicher Bezeichner, der einer bekannten Schwachstelle zugewiesen wird.
• ENISA : Agentur der Europäischen Union für Cybersicherheit, die die CRA-Meldeplattform.
• CSIRT : Zentrum für die Reaktion auf IT-Sicherheitsvorfälle. In Frankreich ist das CERT-FR, betrieben von der ANSSI, das nationale CSIRT (ANSSI).
• CI/CD (kontinuierliche Integration und Bereitstellung) : automatisierte Kette, die jede Code-Änderung testet und dann in Produktion nimmt.

Über den Autor

Harold Stern ist Cybersicherheit- und Compliance-Experte bei Galadrim. Er entwickelt dieses Angebot, zusammen mit dem Team für Anwendungssicherheit.