Etwas ist passiert. Wann haben Sie davon erfahren?

Der Cyber Resilience Act für einen kleinen Softwarehersteller, in zwölf Schritten

Alles, was ein Zehn-Personen-Unternehmen, das installierte Software oder ein Gerät ausliefert, nach dem CRA tun muss, in der Reihenfolge, in der es zu tun ist: die Feststellung des Anwendungsbereichs, die Stufe, das CSIRT und die Durchsetzungsbehörde, das Meldeverfahren, das seit dem 11. September 2026 gilt, dann die technische Dokumentation, die 22 Anforderungen, die SBOM, der Unterstützungszeitraum, die CE-Kennzeichnung und die Erklärung, fällig bis zum 11. Dezember 2027. Jeder Schritt mit seinem Artikel und dem Text, der ihn erklärt.

An welches CSIRT melden Sie nach Artikel 14 CRA? Alle 27 Koordinatoren, wie die ENISA sie aufführt

Jeder Leitfaden zur Meldepflicht des Cyber Resilience Act sagt „melden Sie an Ihr nationales CSIRT“ und hört dort auf. Seit dem 10. September 2026 veröffentlicht die ENISA das als Koordinator benannte CSIRT für jeden der 27 Mitgliedstaaten. Hier ist diese Liste, die Regel, die den Staat bestimmt, und die zwei Staaten, in denen der Koordinator nicht das nationale CSIRT ist.

Wie Sie eine CRA-Meldung auf der zentralen Meldeplattform der ENISA einreichen, aus deren eigenem Handbuch

Die Plattform ging am 11. September 2026 unter portal.cra-srp.enisa.europa.eu in Betrieb. Wer sich anmelden kann, welchen Koordinator Sie wählen, was jede der drei Einreichungen abfragt, was der plattformeigene Zähler falsch macht und wann Sie um eine verzögerte Weitergabe bitten dürfen. Gelesen in den Leitfäden, FAQ, dem Glossar und den Nutzungsbedingungen der ENISA, nicht in einer Zusammenfassung davon.

Wann beginnt die 24-Stunden-Uhr des CRA? „Kenntnis erlangen“, aus den Leitlinien der Kommission

Die 24 und 72 Stunden laufen ab dem Moment, in dem der Hersteller „Kenntnis erlangt“, und die Verordnung sagt nie, was das heißt. Die Leitlinien der Kommission vom 27. Juli 2026 tun es, in den Randnummern 211 bis 218: eine hinreichende Gewissheit nach einer ersten Bewertung, Wort für Wort übernommen aus der NIS2-Durchführungsverordnung und den DSGVO-Leitlinien zu Datenpannen. Was das aus einer Kunden-E-Mail, einer Scanner-Warnung, einer gelisteten CVE in einer Komponente, einem Bug-Bounty-Zero-Day und einer Schwachstelle macht, die Sie schon vor dem 11. September kannten.

Die Frist für den CRA-Abschlussbericht beginnt nicht, wenn Sie Kenntnis erlangen

Die meisten Darstellungen von Artikel 14 des Cyber Resilience Act nennen drei Fristen ab einem Startpunkt: 24 Stunden, 72 Stunden, 14 Tage. Die ersten beiden laufen ab Kenntnis. Die dritte nicht, und bei einer Schwachstelle ist ihr Anker ein Datum, das noch gar nicht existieren muss. Hier steht, was die Verordnung sagt, Absatz für Absatz.

Fällt Ihr Produkt unter den Cyber Resilience Act? Wo SaaS steht

Die meistgestellte CRA-Frage ist nicht, wie man meldet, sondern ob die Verordnung überhaupt für Sie gilt. Reines Software-as-a-Service ist draußen und fällt unter NIS2; installierte und herunterladbare Software ist drin; Fernverarbeitung, ohne die ein Produkt nicht funktioniert, ist wieder drin. Die Feststellung treffen und dokumentieren Sie selbst. Hier steht der Text, der sie entscheidet.

Wann ist Software nach dem CRA „in Verkehr gebracht“, und welcher Ihrer Builds ist ein Produkt? Die Regel der Leitlinien für eigenständige Software

Alles im CRA hängt an einem Datum und einem Substantiv: dem Datum, an dem ein Produkt in Verkehr gebracht wird, und der Frage, ob das, was Sie ausliefern, überhaupt ein Produkt ist. Für eigenständige Software beantworten die Leitlinien der Kommission vom 27. Juli 2026 beides in den Randnummern 13 bis 21: Eine Version wird einmal in Verkehr gebracht, beim ersten Angebot, und jeder spätere Download zählt ab diesem Tag; Builds je Betriebssystem und Funktionspakete sind getrennte Produkte; eine Web-App im Browser ist kein Produkt, eine Browsererweiterung oder ein installierter Client schon. Was das für den 11. Dezember 2027, für Betas und für alte Versionen, die Sie online lassen, bedeutet.

Welche Teile Ihres Backends liegen im CRA? Datenfernverarbeitung, aus den Leitlinien der Kommission

Ein Produkt mit digitalen Elementen umfasst seine Lösungen zur Datenfernverarbeitung, und die Verordnung definiert sie in einem Satz. Die Leitlinien der Kommission vom 27. Juli 2026 machen aus diesem Satz zwei kumulative Tests, eine Abgrenzungsregel, eine Liste dessen, was nie dazugehört (CI/CD, Personal, CRM, Telemetrie, Websites), die Fälle SaaS, PaaS und IaaS und ein durchgerechnetes Mobile-Banking-Beispiel. Für ein Softwareunternehmen mit App und Cloud ist das die Grenze.

Wer setzt den Cyber Resilience Act in Ihrem Mitgliedstaat durch? 7 von 27 haben es gesagt

Der CRA wird national durchgesetzt, durch eine Marktüberwachungsbehörde, die jeder Mitgliedstaat benennt und bei der Kommission registriert. Am 11. September 2026, dem Tag, an dem die Meldepflicht begann, hatten sieben Staaten eine registriert. Hier ist das Register, Staat für Staat, einschließlich der zwanzig, die keine haben, und was das für einen kleinen Hersteller bedeutet, der fragt, wer anklopfen wird.

Ist Ihr Produkt nach dem Cyber Resilience Act wichtig oder kritisch? Anhang III und IV vollständig

Sobald ein Produkt in den Anwendungsbereich des CRA fällt, ist es Standard, wichtig (Klasse I oder II) oder kritisch, und die Stufe entscheidet, ob Sie selbst bewerten dürfen oder eine notifizierte Stelle brauchen. Hier stehen die 19, 4 und 3 Kategorien wörtlich aus dem Amtsblatt, was jede Stufe nach Artikel 32 ändert, und das eine, was die Stufe nicht ändert.

Standard, wichtig oder kritisch: die 26 technischen Beschreibungen der Durchführungsverordnung 2025/2392 und der Kernfunktionalitätstest

Anhang III und IV des CRA nennen 26 Produktkategorien in je einer Zeile. Die Durchführungsverordnung (EU) 2025/2392 der Kommission, in Kraft seit dem 21. Dezember 2025, beschreibt jede technisch, und die Leitlinien der Kommission vom 27. Juli 2026 sagen, wie man sie einstuft: nach der Kernfunktionalität des Produkts, nicht nach dem, was es außerdem tut oder integriert. Alle 26 Beschreibungen wörtlich, die sechs Regeln der Leitlinien mit ihren Beispielen (SOAR ist kein SIEM, ein Log-Viewer ist kein SIEM, ein Router mit Firewall ist ein Router) und was die Einstufung ändert.

CRA Anhang I: die 22 grundlegenden Anforderungen als Checkliste

Anhang I des Cyber Resilience Act ist das, was Ihr Produkt ab dem 11. Dezember 2027 erfüllen und die technische Dokumentation zeigen muss. Teil I sind 14 Produktanforderungen, 13 davon „soweit anwendbar“ auf Grundlage Ihrer Risikobewertung; Teil II sind 8 Anforderungen an die Schwachstellenbehandlung, die immer gelten. Hier stehen sie als eine Tabelle, mit dem, was jede verlangt, und ob Sie sie ausschließen dürfen.

Was in die technische Dokumentation nach dem CRA gehört: Anhang VII, Punkt für Punkt

Ab dem 11. Dezember 2027 braucht jedes Produkt mit digitalen Elementen, das auf dem EU-Markt in Verkehr gebracht wird, vor dem Inverkehrbringen eine technische Dokumentation, aufzubewahren für zehn Jahre oder den Unterstützungszeitraum, je nachdem, was länger ist. Anhang VII sagt in acht Punkten, was sie enthält. Hier stehen sie, was jeder Punkt tatsächlich verlangt, die vier Dokumente, die Teil II des Anhangs I voraussetzt, und wie lange Sie sie aufbewahren.

Verlangt der CRA eine SBOM? Ja, und hier steht genau, was er sagt

Anhang I Teil II Nummer 1 des Cyber Resilience Act verlangt eine Software-Stückliste in einem gebräuchlichen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt. Sie gehört in die technische Dokumentation, wird nicht veröffentlicht, und eine Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern. Die drei Sätze, die das entscheiden, und was sie offenlassen.

Was der CRA für Ihre Abhängigkeiten verlangt: Sorgfaltspflicht, Meldung nach oben und bekannte ausnutzbare Schwachstellen, aus den Leitlinien der Kommission

Ein Softwareprodukt besteht überwiegend aus fremdem Code. Der CRA macht den Hersteller für das Produkt als Ganzes verantwortlich und gibt ihm drei Pflichten gegenüber den Komponenten darin: Sorgfaltspflicht nach Artikel 13(5), Meldung von Schwachstellen an den Betreuer und Weitergabe von Korrekturen nach Artikel 13(6), und das Inverkehrbringen ohne bekannte ausnutzbare Schwachstellen. Die Leitlinien der Kommission vom 27. Juli 2026, Abschnitte 3.4, 7.3 und 9.2, sagen, was jede verlangt und was nicht: keine doppelten Meldungen, keine Pflicht, dass Ihre Korrektur übernommen wird, und eine Definition von „bekannt“, die die CVE-Datenbank und die Nachrichten einschließt.

CRA oder NIS2: Was gilt für ein Softwareunternehmen, und kann es beides sein?

Der Cyber Resilience Act regelt Produkte, die in Verkehr gebracht werden; NIS2 regelt Einrichtungen, die Dienste erbringen. Ein Softwareunternehmen kann unter das eine, das andere, beide oder keines fallen, und die Antwort hängt an zwei Fragen: Bringen Sie ein Produkt in Verkehr, und sind Sie eine mittlere oder größere Einrichtung in einem aufgeführten Sektor. Die Daten, die Meldefristen, die Bußgelder und die Entscheidungstabelle, aus den beiden Texten.

NIS2 oder CRA: Welche Vorfalls-Uhr läuft für ein Softwareunternehmen, und was macht einen Vorfall „erheblich“

Beide Gesetze geben Ihnen 24 Stunden, 72 Stunden und einen Monat, und beide starten die Uhr, wenn Sie „Kenntnis erlangen“. Fast alles andere unterscheidet sich: was sie auslöst, wer sie erhält, auf welcher Plattform und was zählt. NIS2 Artikel 23 und die Durchführungsverordnung 2024/2690 für das Unternehmen, das einen Cloud-Dienst betreibt; CRA Artikel 14 für das Unternehmen, das ein Produkt ausliefert; beides für das Unternehmen, das beides tut. Die Schwellenwerte, Kriterium für Kriterium, und ein Verfahren, das beiden genügt.

Braucht Software nach dem CRA eine CE-Kennzeichnung? Ja, und Artikel 30 sagt, wohin sie gehört

Ab dem 11. Dezember 2027 ist auf jedem Produkt mit digitalen Elementen, das auf dem EU-Markt in Verkehr gebracht wird, eine CE-Kennzeichnung erforderlich, Software eingeschlossen. Bei Software kommt die Kennzeichnung auf die EU-Konformitätserklärung oder auf die Website, die das Produkt begleitet, vor dem Inverkehrbringen. Was die Kennzeichnung behauptet, wer sie anbringen darf, wann die Nummer einer notifizierten Stelle dazukommt und was die Erklärung dahinter enthalten muss.

Die EU-Konformitätserklärung nach dem CRA: Anhang V Punkt für Punkt, die vereinfachte Form und ein ausgearbeitetes Beispiel

Artikel 28 verpflichtet den Hersteller, vor dem Inverkehrbringen eine EU-Konformitätserklärung nach dem Muster in Anhang V auszustellen, und Artikel 28(4) macht die Unterschrift zu dem Akt, mit dem der Hersteller die Verantwortung für das Produkt übernimmt. Die acht Punkte des Anhangs V, die vereinfachte Ein-Satz-Form des Anhangs VI, die Regeln drumherum (Sprachen, die einzige Erklärung, Produktfamilien, 10 Jahre Aufbewahrung), ein ausgearbeitetes Beispiel, und was eine fehlende oder fehlerhafte Erklärung nach Artikel 58 und Artikel 64 kostet.

Selbstbewertung nach dem CRA: Was Modul A tatsächlich verlangt, aus Anhang VIII und den FAQ der Kommission

Die meisten Softwareprodukte werden nie eine notifizierte Stelle sehen. Sie nutzen Modul A, das Verfahren der internen Kontrolle aus Anhang VIII, und „Selbstbewertung“ ist das Wort, das alle dafür verwenden, ohne zu sagen, was es enthält. Anhang VIII Teil I sind fünf Punkte; die FAQ der Kommission ergänzen die Liste der Tätigkeiten, die Tatsache, dass keine Prüfmethodik vorgeschrieben ist, wo ein Softwareprodukt seine CE-Kennzeichnung trägt, die zwei Formen der Konformitätserklärung und den Zeitplan der harmonisierten Normen, der entscheidet, wann Selbstbewertung nicht mehr „direkt gegen Anhang I“ heißt.

Harmonisierte Normen für den CRA: Was der Normungsauftrag M/606 verlangt, bis wann, und was ein Hersteller heute hat

Artikel 27 gibt Produkten, die harmonisierten Normen mit Fundstelle im Amtsblatt folgen, eine Konformitätsvermutung. Am 3. Februar 2025 bat die Kommission CEN, CENELEC und ETSI um 41 davon, mit Fristen vom 30. August 2026 bis zum 30. Oktober 2027; die drei nahmen am 3. April 2025 an. Am 12. September 2026 hat das Verzeichnis harmonisierter Normen der Kommission noch keinen Eintrag für die Verordnung, was für ein Produkt der Klasse I bedeutet: kein Weg der Selbstbewertung nach Artikel 32(2). Was beantragt wurde, die Daten, und wogegen bis dahin zu bauen ist.

Wie lang ist der Unterstützungszeitraum nach dem CRA? Mindestens fünf Jahre, und drei weitere Uhren hängen daran

Artikel 13 Absatz 8 des Cyber Resilience Act verlangt einen Unterstützungszeitraum von mindestens fünf Jahren, oder die erwartete Nutzungsdauer, wenn sie kürzer ist, in dem Schwachstellen behandelt werden. Sein Enddatum muss beim Kauf angezeigt werden, mindestens Monat und Jahr. Sicherheitsupdates müssen zehn Jahre oder den Unterstützungszeitraum verfügbar bleiben. Und technische Dokumentation, Erklärung und Nutzerinformationen werden ebenso lange aufbewahrt. Die vier Uhren, aus dem Text.

Welches Update bringt Ihre bestehende Software unter den CRA? Wesentliche Änderungen, aus den Leitlinien der Kommission

Software, die vor dem 11. Dezember 2027 in Verkehr gebracht wurde, bleibt außerhalb der Design- und Konformitätspflichten des CRA, bis sie wesentlich geändert wird. Die Leitlinien der Kommission vom 27. Juli 2026 sagen in den Randnummern 103 bis 113 und 122 bis 124, was das für ein Software-Update heißt, mit elf durchgerechneten Beispielen: ein Risiko, das nicht in Ihrer Risikobewertung steht, nicht die Größe des Diffs. Sicherheitsupdates sind in der Regel draußen; ein „Angemeldet bleiben“-Kästchen kann drin sein. Was in jedes Release gehört, und was die erste wesentliche Änderung auslöst und was nicht.

Was Sie nach dem CRA melden müssen: die zwei Auslöser, wie die Verordnung sie definiert

Artikel 14 hat zwei Auslöser, und beide sind im Text definiert. Eine aktiv ausgenutzte Schwachstelle ist eine, für die verlässliche Belege vorliegen, dass ein böswilliger Akteur sie ohne Erlaubnis des Eigentümers in einem System ausgenutzt hat (Artikel 3 Nummer 42). Ein schwerwiegender Vorfall ist einer, der die Fähigkeit des Produkts beeinträchtigt oder beeinträchtigen kann, sensible Daten oder Funktionen zu schützen, oder der zu bösartigem Code im Produkt oder in den Systemen eines Nutzers führt oder führen kann (Artikel 14 Absatz 5). Was drin ist, was draußen ist, und die Pflicht, die Nutzer zu informieren, die mit beiden kommt.

Gilt der CRA für Open-Source-Software? Drei Fälle, und die leichte Regelung für Verwalter

Der Cyber Resilience Act erreicht freie und quelloffene Software nur, wenn sie im Rahmen einer gewerblichen Tätigkeit bereitgestellt wird. Ein nicht monetarisiertes Projekt ist draußen. Ein Unternehmen, das ein auf Open-Source-Komponenten gebautes Produkt ausliefert, ist Hersteller dieses Produkts. Und Stiftungen und Unternehmen, die Open-Source-Produkte für gewerbliche Nutzung tragen, sind „Verwalter quelloffener Software“ nach Artikel 24: eine Cybersicherheitsrichtlinie, Zusammenarbeit mit Behörden und eine eingeschränkte Meldepflicht, ohne CE-Kennzeichnung und ohne technische Dokumentation. Die Erwägungsgründe und der Artikel, zitiert.

Ist Ihr Open-Source-Projekt „kommerziell“ im Sinne des CRA? Die sieben Tests der Kommission, mit ihren Beispielen

Der CRA erfasst freie und quelloffene Software nur, wo sie im Rahmen einer Geschäftstätigkeit bereitgestellt wird, und die Verordnung überlässt „kommerziell“ zwei Erwägungsgründen. Die Leitlinien der Kommission vom 27. Juli 2026, Abschnitt 3, machen daraus sieben Tests: ein Preis, eine bezahlte Edition oder Open Core, das Monetarisieren anderer Dienste oder personenbezogener Daten, Supportleistungen, Spenden, Sponsoring und Gemeinnützigkeit, mit 22 Beispielen. Wo ein Maintainer, ein Open-Core-Unternehmen und eine Stiftung jeweils landen, und was ein Pull Request aus Ihnen macht.

Was der CRA von Einführern und Händlern verlangt, und wann er sie zum Hersteller macht

Wer Software oder Geräte in die EU weiterverkauft, statt sie zu bauen, bekommt von den Artikeln 19 und 20 des Cyber Resilience Act eine Checkliste vor dem Verkauf, eine Pflicht, Schwachstellen an den Hersteller weiterzugeben, eine Pflicht, Behörden über erhebliche Risiken zu informieren, und zehn Jahre Aufbewahrung. Artikel 21 macht Sie zum Hersteller, sobald Sie unter eigener Marke verkaufen oder das Produkt wesentlich verändern. Die Pflichten, aus dem Text.

Die eigene CRA-Maschinerie der EU am Tag, an dem die Pflicht begann: 0 notifizierte Stellen, 0 harmonisierte Normen, 7 von 27 Durchsetzungsbehörden

Der Cyber Resilience Act verlangt von Herstellern, bereit zu sein. Hier steht, wie bereit die Institutionen, auf die er sich stützt, am 11. und 12. September 2026 waren, abgelesen von den Registern der Kommission selbst: keine nach dem CRA notifizierte Konformitätsbewertungsstelle, keine im Amtsblatt veröffentlichte harmonisierte Norm, sieben Mitgliedstaaten mit registrierter Marktüberwachungsbehörde, dreizehn mit notifizierender Behörde, und die Liste der Koordinator-CSIRTs am Tag zuvor veröffentlicht, wobei zwei Staaten eine andere Stelle als ihr nationales CSIRT benennen. Was das für einen Hersteller mit einem Produkt der Klasse I bedeutet, und was festzuhalten ist.

Die Cybersicherheitsrisikobewertung nach dem CRA: Was Artikel 13 tatsächlich verlangt, und das eine Ergebnis, das sie liefern muss

Artikel 13 Absätze 2 bis 4 des Cyber Resilience Act machen die Risikobewertung zu dem Dokument, an dem jede andere CRA-Pflicht hängt. Sie muss Risiken aus Zweckbestimmung, vorhersehbarer Verwendung und Nutzungsbedingungen über die erwartete Nutzungsdauer analysieren; angeben, ob und wie jede Anforderung aus Teil I Nummer 2 gilt; sagen, wie Teil I Nummer 1 und Teil II angewandt werden; dokumentiert, über den Unterstützungszeitraum aktuell gehalten und in die technische Dokumentation aufgenommen sein, mit klarer Begründung für jede weggelassene Anforderung. Die vier Absätze, und eine einseitige Struktur, die sie erfüllt.

Die Richtlinie zur koordinierten Offenlegung von Schwachstellen, die der CRA verlangt: drei Vorschriften, und eine einseitige Richtlinie, die sie erfüllt

Anhang I Teil II Nummer 5 des Cyber Resilience Act verlangt von jedem Hersteller im Anwendungsbereich, eine Richtlinie zur koordinierten Offenlegung von Schwachstellen einzuführen und durchzusetzen. Artikel 13 Absatz 17 verlangt eine zentrale Kontaktstelle für Meldungen, die leicht zu finden ist und nicht auf automatisierte Werkzeuge beschränkt; Anhang II Nummer 2 verlangt die Kontaktstelle und den Fundort der Richtlinie in den Nutzerinformationen; Anhang VII Nummer 2 Buchstabe b nimmt beides in die technische Dokumentation auf. Was jede Vorschrift verlangt, was eine Richtlinie sagen muss und was sie nicht versprechen darf.