> ## Content Index > Fetch the complete content index at: https://silentmonkey.io/llms.txt > Use this file to discover other available public pages before exploring further. # Cyber Resilience Act – Wenn Sicherheit Teil des Produkts wird - URL: https://silentmonkey.io/cyber-resilience-act-wenn-sicherheit-teil-des-produkts-wird/ - Published: 2026-09-22T19:28:42.000Z - Updated: 2026-09-22T19:28:42.000Z - Author: Andreas Roßmann # **Stand: September 2026** Ein digitales Produkt wird verkauft, installiert und irgendwann vielleicht vergessen. Ein Router läuft jahrelang. Eine Kamera hängt an der Wand. Eine Smartwatch wird täglich getragen. Eine Software bleibt auf einem Rechner installiert, obwohl ihr Hersteller längst eine neue Version entwickelt. Was aber passiert, wenn in einem solchen Produkt eine Sicherheitslücke entdeckt wird? Wer muss davon wissen? Wer muss handeln? Und wer muss die Sicherheitslücke melden, wenn sie bereits aktiv ausgenutzt wird? Mit dem **Cyber Resilience Act (CRA)** hat die Europäische Union dafür einen neuen regulatorischen Rahmen geschaffen. Ein wichtiger Schritt ist am **11\. September 2026** in Kraft getreten: Seit diesem Datum müssen Hersteller bestimmte aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Dafür hat die EU-Agentur für Cybersicherheit **ENISA** eine zentrale Meldestelle eingerichtet. Die wesentlichen Cybersecurity-Anforderungen des CRA gelten allerdings erst ab **11\. Dezember 2027**. Das ist ein wichtiger Unterschied. --- ## Was ist der Cyber Resilience Act? Der **Cyber Resilience Act**, kurz **CRA**, ist die EU-Verordnung über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Der Begriff „horizontal“ bedeutet hier: Die Verordnung richtet sich nicht nur an einen einzelnen Wirtschaftszweig. Sie schafft grundsätzlich geltende Cybersecurity-Anforderungen für eine große Bandbreite digitaler Produkte. Dazu gehören beispielsweise Hardware und Software, die mit Netzwerken oder anderen digitalen Systemen verbunden sind. Das kann ein Router sein. Eine Überwachungskamera. Ein Smart Home-Gerät. Eine industrielle Software. Ein Netzwerkgerät. Oder eine Anwendung, die als eigenständiges Produkt auf dem europäischen Markt angeboten wird. Der CRA betrachtet dabei nicht nur den Zeitpunkt, an dem ein Produkt entwickelt und verkauft wird. Er betrachtet seinen **Lebenszyklus**. --- ## Sicherheit endet nicht mit der Auslieferung Genau hier liegt die eigentliche Bedeutung des CRA. Traditionell konnte Produktsicherheit vereinfacht als etwas betrachtet werden, das vor der Auslieferung geprüft wird: Produkt entwickeln → testen → verkaufen. Bei Software und vernetzten Produkten funktioniert dieses Modell schon lange nicht mehr. Nach der Auslieferung können neue Schwachstellen entdeckt werden. Angriffsmethoden verändern sich. Abhängigkeiten werden aktualisiert. Bibliotheken erhalten Sicherheitslücken. Neue Angriffstechniken entstehen. Ein Produkt, das bei seiner Veröffentlichung sicher war, kann deshalb einige Jahre später ein erhebliches Sicherheitsrisiko darstellen. Der CRA trägt dieser Realität Rechnung. Die Verordnung verlangt unter anderem, dass Produkte mit digitalen Elementen entsprechend dem Risiko entwickelt, produziert und bereitgestellt werden und dass Sicherheitsanforderungen über den Lebenszyklus berücksichtigt werden. Dazu gehört auch, dass Produkte grundsätzlich ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden und sicher voreingestellt sein sollen. Sicherheit wird damit zu einer **laufenden Produkteigenschaft**. --- ## Der 11\. September 2026 Seit dem **11\. September 2026** gilt ein besonders konkreter Teil des CRA: Hersteller müssen bestimmte **aktiv ausgenutzte Schwachstellen** und **schwerwiegende Sicherheitsvorfälle** melden. Dafür hat ENISA die **CRA Single Reporting Platform (SRP)** eingerichtet. Die Plattform soll den Meldeprozess vereinfachen: Hersteller müssen ihre Meldung nicht separat an verschiedene zuständige Stellen in mehreren Mitgliedstaaten senden. Die Informationen werden über die zentrale Plattform an die zuständigen Stellen weitergeleitet. Das ist mehr als eine neue Website für Meldungen. Es verändert die Erwartung an Hersteller. Wenn eine Schwachstelle aktiv ausgenutzt wird, reicht es nicht mehr aus, irgendwann einen Patch bereitzustellen und das Problem intern zu dokumentieren. Es entsteht ein definierter Prozess: **Erkennen → Bewerten → Melden → Reagieren → Beheben** --- ## Was ist eine „aktiv ausgenutzte Schwachstelle“? Nicht jede Sicherheitslücke löst automatisch diese Meldepflicht aus. Der CRA unterscheidet unter anderem zwischen einer Schwachstelle und einer **aktiv ausgenutzten Schwachstelle**. Gemeint ist eine Schwachstelle, für die zuverlässige Hinweise vorliegen, dass ein Angreifer sie tatsächlich unbefugt ausgenutzt hat. Das ist ein wichtiger Unterschied. Eine neu entdeckte Schwachstelle kann zunächst ein technisches Problem sein. Wird dieselbe Schwachstelle nachweislich bei Angriffen ausgenutzt, verändert sich ihre Bedeutung. Aus einem technischen Befund wird ein konkretes Sicherheitsereignis. Und genau an diesem Übergang setzt die Meldepflicht an. --- ## 24 Stunden. 72 Stunden. Und danach? Der CRA definiert für die verpflichtenden Meldungen konkrete Fristen. ### Innerhalb von 24 Stunden Nach Kenntnis einer aktiv ausgenutzten Schwachstelle oder eines entsprechenden schwerwiegenden Sicherheitsvorfalls muss eine **Frühwarnung** erfolgen – ohne unangemessene Verzögerung und spätestens innerhalb von 24 Stunden. ### Innerhalb von 72 Stunden Spätestens innerhalb von 72 Stunden folgt die ausführlichere Meldung mit allgemeinen Informationen und einer ersten Bewertung. ### Danach Bei einer aktiv ausgenutzten Schwachstelle muss spätestens **14 Tage nachdem eine korrigierende oder mildernde Maßnahme verfügbar ist** ein Abschlussbericht erfolgen. Bei einem schwerwiegenden Sicherheitsvorfall ist der Abschlussbericht **innerhalb eines Monats nach der 72-Stunden-Meldung** einzureichen. Damit wird aus Vulnerability Management ein zeitkritischer Prozess. --- ## Und wer muss melden? Die Meldepflicht nach Artikel 14 richtet sich zunächst an **Hersteller von Produkten mit digitalen Elementen**. Für Open-Source-Software-Stewards gelten entsprechende Verpflichtungen zu einem späteren Zeitpunkt, soweit sie in den Anwendungsbereich der Regelung fallen. Diese Verpflichtungen nach Artikel 24 Absatz 3 beginnen am **11\. Dezember 2027**. Das ist für Unternehmen wichtig. Nicht jedes Unternehmen, das ein digitales Produkt verwendet, wird dadurch automatisch zum Hersteller im Sinne des CRA. Wer allerdings ein Produkt entwickelt und unter eigener Verantwortung auf dem EU-Markt bereitstellt, muss genau prüfen, welche Rolle er innerhalb des CRA einnimmt. --- ## Der CRA ist kein neues ISO-27001-Zertifikat Auch hier lohnt eine klare Abgrenzung. Der CRA schreibt nicht einfach vor: > „Unternehmen müssen ISO 27001 zertifiziert sein.“ Der CRA formuliert **gesetzliche Anforderungen an Produkte mit digitalen Elementen**. ISO/IEC 27001 dagegen beschreibt Anforderungen an ein **Informationssicherheitsmanagementsystem (ISMS)**. Beide Regelwerke verfolgen unterschiedliche Ziele. Trotzdem gibt es eine wichtige Verbindung. Wer ein digitales Produkt dauerhaft sicher entwickeln und betreiben möchte, braucht Prozesse: - für Risikobewertungen, - für Schwachstellen, - für Sicherheitsupdates, - für Verantwortlichkeiten, - für Lieferketten, - für Vorfälle, - für Dokumentation, - und für die Überprüfung der Wirksamkeit. Genau diese Prozesse sind klassische Bestandteile eines systematischen Informationssicherheitsmanagements. Der CRA macht damit etwas sichtbar, das in der Informationssicherheit schon lange bekannt ist: **Sicherheit entsteht nicht durch ein einzelnes Produkt. Sie entsteht durch funktionierende Prozesse.** --- ## Security by Design statt Security als Nachrüstung Ein besonders interessanter Aspekt des CRA ist deshalb die Verschiebung der Perspektive. Sicherheit soll nicht erst dann beginnen, wenn ein Produkt bereits auf dem Markt ist und eine Schwachstelle bekannt wird. Sie soll bereits in der Entwicklung berücksichtigt werden. Das wird häufig mit **Security by Design** bezeichnet. Security by Design bedeutet vereinfacht: > Sicherheitsanforderungen werden bereits bei der Entwicklung eines Produkts berücksichtigt und nicht erst nachträglich auf ein fertiges Produkt aufgesetzt. Dazu gehört beispielsweise die Frage, welche Daten ein Produkt verarbeitet, welche Schnittstellen es besitzt, welche Zugriffe möglich sind und wie Sicherheitsupdates später bereitgestellt werden können. Das klingt zunächst technisch. Tatsächlich ist es aber auch eine Governance-Frage. Denn jemand muss entscheiden: **Welche Risiken akzeptieren wir?** **Welche Sicherheitsanforderungen gelten für das Produkt?** **Wer überprüft ihre Umsetzung?** **Wie lange wird das Produkt unterstützt?** **Was passiert, wenn eine Schwachstelle entdeckt wird?** --- ## Ein Produkt hat einen Lebenszyklus Der CRA führt damit zu einer Perspektive, die auch für die Informationssicherheit von Unternehmen interessant ist. Ein Produkt beginnt nicht mit dem Verkauf. Und es endet nicht mit dem Verkauf. Dazwischen liegen Entwicklung, Prüfung, Bereitstellung, Wartung, Updates, Schwachstellenmanagement und möglicherweise das Ende des Supports. Man könnte diesen Lebenszyklus vereinfacht so darstellen: **DESIGN → DEVELOP → RELEASE → MONITOR → UPDATE → RETIRE** An jeder Stelle können Sicherheitsrisiken entstehen. Und an jeder Stelle braucht es Verantwortlichkeiten. Das ist vielleicht die wichtigste Verbindung zwischen Produktentwicklung und Information Security. --- ## Was bedeutet das für Unternehmen? Für Hersteller bedeutet der CRA unter anderem, dass Cybersecurity stärker in Produktentwicklung und Produktmanagement integriert werden muss. Für Unternehmen, die digitale Produkte entwickeln oder unter eigener Verantwortung vermarkten, lohnt sich deshalb eine Bestandsaufnahme: ### Produkt Welche Produkte mit digitalen Elementen werden angeboten? ### Verantwortung Welche Rolle hat das Unternehmen innerhalb der Lieferkette? ### Schwachstellen Wie werden Schwachstellen erkannt, bewertet und priorisiert? ### Updates Wie werden Sicherheitsupdates entwickelt, getestet und verteilt? ### Vorfälle Wer entscheidet bei einem Sicherheitsvorfall? ### Meldungen Ist klar, wer innerhalb von 24 beziehungsweise 72 Stunden handeln kann? ### Lieferkette Welche Abhängigkeiten bestehen zu Softwarekomponenten und Drittanbietern? ### Dokumentation Kann das Unternehmen nachvollziehbar zeigen, wie Sicherheitsentscheidungen getroffen wurden? Diese Fragen sind nicht nur für den CRA relevant. Sie sind grundlegende Fragen eines funktionierenden Security Managements. --- ## Der interessante Teil kommt erst 2027 Der **11\. September 2026** ist deshalb nicht das Ende der CRA-Einführung. Er ist ein wichtiger erster Schritt. Die umfassenderen Cybersecurity-Anforderungen des CRA werden ab **11\. Dezember 2027** anwendbar. Dazu gehören die zentralen Anforderungen an die Cybersecurity von Produkten mit digitalen Elementen über ihren Lebenszyklus hinweg. Damit beginnt für Hersteller eine längere Vorbereitungsphase. Wer erst im Dezember 2027 damit beginnt, seine Produktentwicklung, Schwachstellenprozesse und Verantwortlichkeiten zu überprüfen, hat einen großen Teil der Arbeit noch vor sich. --- ## Was sich mit dem CRA verändert Der vielleicht wichtigste Gedanke lässt sich deshalb in einem Satz zusammenfassen: > **Ein digitales Produkt ist nicht sicher, weil es einmal sicher getestet wurde.** Sicherheit muss über den gesamten Lebenszyklus erhalten, überprüft und weiterentwickelt werden. Der Cyber Resilience Act macht daraus eine regulatorische Anforderung. Das verändert auch die Rolle von Informationssicherheit. Sie wird zunehmend zu einem Bestandteil von **Produktentwicklung, Unternehmensführung und Governance**. Und damit verschiebt sich die Frage: Nicht mehr nur: **„Ist dieses Produkt sicher?“** Sondern: **„Wie stellen wir sicher, dass dieses Produkt während seines gesamten Lebenszyklus sicher bleibt?“** Das ist eine wesentlich anspruchsvollere Frage. Und wahrscheinlich die interessantere. --- ### Regulatory Status **Stand: September 2026** Dieser Artikel beschreibt den Rechts- und Sachstand zum Zeitpunkt der Veröffentlichung. Die Meldepflichten nach Artikel 14 des Cyber Resilience Act gelten seit **11\. September 2026**. Die zentralen weiteren Cybersecurity-Anforderungen des CRA werden ab **11\. Dezember 2027** anwendbar. Bei wesentlichen Änderungen wird dieser Artikel aktualisiert. --- ### Quellen und weiterführende Informationen **Europäische Kommission** – Informationen zum Cyber Resilience Act und seinen Meldepflichten. **ENISA** – CRA Single Reporting Platform und aktuelle Umsetzungshinweise. **EUR-Lex** – Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. --- 💡 ****Haben Sie eine Frage zu Information Security, ISMS, Audit oder einem konkreten Projekt?**