Sicherheit beginnt vor der ersten Veröffentlichung
Angenommen, in einer verwendeten Softwarebibliothek wird eine schwerwiegende Sicherheitslücke bekannt. Das Entwicklungsteam möchte reagieren. Doch zunächst muss geklärt werden, welche Produktversionen die Bibliothek enthalten, wo diese Versionen eingesetzt werden und ob sich die Komponente ohne größere Umbauten austauschen lässt.
Die eigentliche Schwierigkeit beginnt dann nicht erst beim Schreiben einer Korrektur. Sie liegt in Entscheidungen und Versäumnissen, die möglicherweise weit zurückliegen.
Genau deshalb gehört Sicherheit für mich in die Planung einer Anwendung. Ein abschließender Test kurz vor der Veröffentlichung kann eine unübersichtliche Struktur, fehlende Updatewege und unklare Verantwortlichkeiten nicht vollständig ausgleichen.
Mit dem europäischen Cyber Resilience Act, kurz CRA, bekommt diese Frage zusätzlich rechtliches Gewicht. Für betroffene Hersteller gelten seit dem 11. September 2026 bereits bestimmte Meldepflichten. Die wesentlichen weiteren Verpflichtungen werden ab 11. Dezember 2027 anwendbar. Diese Stufen müssen auseinandergehalten werden. [1][2]
Was schon gilt – und was noch folgt
Der CRA ist die Verordnung (EU) 2024/2847. Er schafft Anforderungen an die Cybersicherheit erfasster Produkte mit digitalen Elementen. Die Europäische Kommission beschreibt dabei ausdrücklich den Zusammenhang zwischen Planung, Entwicklung und späterer Pflege. [1]
Für die zeitliche Einordnung sind insbesondere diese Termine wichtig:
10. Dezember 2024: Inkrafttreten der Verordnung.
11. September 2026: Beginn der Meldepflichten nach Artikel 14 für betroffene Hersteller.
11. Dezember 2027: Beginn der Anwendung der wesentlichen weiteren Verpflichtungen.
Die Übersicht nennt die für diesen Beitrag zentralen Stufen, nicht sämtliche Übergangsregelungen. [1]
Daraus folgt weder, dass sämtliche Anforderungen bereits heute gelten, noch, dass bis Dezember 2027 nichts zu tun wäre.
Eine Anwendung, die jetzt entwickelt wird, kann dann bereits bei Kunden laufen. Ich würde deshalb frühzeitig prüfen, welche Verpflichtungen das konkrete Produkt betreffen und welche technischen Voraussetzungen dafür geschaffen werden müssen.
Welche Software betroffen sein kann
Der CRA betrifft grundsätzlich auf dem EU-Markt bereitgestellte Hardware- und Softwareprodukte, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk umfasst. Bestimmte Produkte sind ausgenommen. Die Kommission erläutert diesen Anwendungsbereich in ihrer am 3. Dezember 2025 aktualisierten Zusammenfassung. [3]
Dabei sollte nicht allein auf das Preisschild geschaut werden. Auch eine kostenlose Bereitstellung kann Bestandteil einer kommerziellen Tätigkeit sein. Für freie und quelloffene Software, die außerhalb einer kommerziellen Tätigkeit bereitgestellt wird, bestehen Ausnahmen; daneben gibt es besondere Regeln für sogenannte Open-Source-Software-Stewards. [4]
Ebenso wenig lässt sich jeder Cloud- oder SaaS-Dienst pauschal einordnen. Erforderliche Fernverarbeitungslösungen eines erfassten Produkts können dazugehören; reine, davon unabhängige Cloudangebote sind nicht automatisch erfasst. [5]
Für ein konkretes Angebot würde ich daher Produkt, Vertriebsmodell und eigene Rolle gemeinsam prüfen lassen. Die Aussage „Wir programmieren nur Software“ beantwortet diese Fragen genauso wenig wie „Unsere Anwendung ist kostenlos“.
Sicherheit braucht überprüfbare Anforderungen
Für die Entwicklung würde ich nicht bei der allgemeinen Vorgabe „Die Anwendung muss sicher sein“ stehen bleiben.
Bei einer Kundenverwaltung wäre zunächst zu klären: Welche Benutzer dürfen welche Daten sehen? Wie werden verschiedene Kundenorganisationen voneinander getrennt? Welche Informationen dürfen exportiert werden? Welche Funktionen benötigen erhöhte Rechte?
Daraus lassen sich konkrete Anforderungen ableiten. Eine normale Benutzerrolle darf keine Administratoren anlegen. Ein Export darf keine Daten anderer Organisationen enthalten. Ein technischer Hintergrunddienst sollte nur die Zugriffe erhalten, die er für seine Aufgabe benötigt.
Das sind Beispiele für eine mögliche Planung, keine vollständige Umsetzungsliste des CRA.
Die Kommission erläutert, dass Hersteller ihre Maßnahmen auf eine Bewertung der Cybersicherheitsrisiken stützen und diese in den Entwicklungs- und Pflegephasen berücksichtigen müssen. Diese Bewertung und die gewählten Maßnahmen gehören zur technischen Dokumentation. [3]
Mein Ziel wäre, jede wichtige Sicherheitsanforderung mit einer verantwortlichen Stelle und einer geeigneten Prüfung zu verbinden. So wird aus einem allgemeinen Anspruch eine Aufgabe, deren Erfüllung nachvollzogen werden kann.
Eine Software-Stückliste schafft Überblick – aber keine Sicherheit allein
Der Begriff SBOM steht für Software Bill of Materials, auf Deutsch Software-Stückliste. Gemeint ist eine strukturierte Übersicht der enthaltenen Softwarebestandteile.
Der CRA verlangt im Rahmen seiner Schwachstellenbehandlung eine gebräuchliche, maschinenlesbare SBOM, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Eine allgemeine Pflicht, sie öffentlich ins Internet zu stellen, folgt daraus nicht. Die Verordnung behandelt eine Bereitstellung an Nutzer gesondert. [5]
Für die tägliche Arbeit würde ich die Stückliste an die tatsächlich ausgelieferte Version binden. Eine irgendwann erstellte Übersicht über das Projekt ist wenig hilfreich, wenn später andere Komponenten ausgeliefert werden.
Auch indirekte Abhängigkeiten würde ich nach Möglichkeit erfassen. Wenn eine verwendete Bibliothek weitere Pakete mitbringt, möchte ich diese bei einer Sicherheitsmeldung nicht erst mühsam zusammensuchen müssen.
Eine Komponentenliste ist allerdings noch keine Bewertung. Sie beantwortet zunächst, was enthalten ist. Ob eine bestimmte Schwachstelle das eigene Produkt betrifft und unter welchen Bedingungen sie ausgenutzt werden könnte, muss anschließend untersucht werden.
Die SBOM ist ein Ausgangspunkt für Entscheidungen, kein Unbedenklichkeitsnachweis.
Austauschbare Komponenten erleichtern die Reaktion
Bei der eingangs beschriebenen Bibliothek würde ich wissen wollen, wie tief sie mit der eigenen Anwendung verbunden ist.
Wird sie über eine klar abgegrenzte Schnittstelle verwendet? Oder greifen zahlreiche Programmteile unmittelbar auf ihre Besonderheiten zu?
Für eine neue Anwendung würde ich fremde Komponenten deshalb möglichst dort einbinden, wo ihre Aufgabe klar begrenzt ist. Ein Austausch lässt sich dann gezielt planen und prüfen.
Das ist kein Argument dafür, jede Bibliothek hinter mehreren zusätzlichen Schichten zu verstecken. Auch unnötige Abstraktion erschwert das Verständnis. Die Trennung sollte dort helfen, wo tatsächlich eine Abhängigkeit beherrscht werden muss.
NIST beschreibt in seinem Secure Software Development Framework vom Februar 2022, wie sichere Entwicklungspraktiken in den gesamten Entwicklungsprozess eingebunden werden können. Der Ansatz reicht über eine einmalige Abschlusskontrolle hinaus und berücksichtigt auch den Umgang mit entdeckten Schwachstellen. [6]
Für mich gehört dazu, die verwendeten Komponenten nicht nur beim Projektstart auszuwählen, sondern ihre weitere Pflege mitzuplanen.
Ein Updateweg gehört zum Produkt
Eine Sicherheitskorrektur ist erst dann beim Nutzer angekommen, wenn sie tatsächlich bereitgestellt und angewendet werden kann.
Für die Architektur würde ich deshalb frühzeitig klären, wie neue Versionen verteilt werden. Wie wird die Herkunft eines Updates überprüft? Was passiert bei einer unterbrochenen Installation? Welche Daten müssen migriert werden? Wie lässt sich auf einen fehlerhaften Veröffentlichungsstand reagieren?
Besonders aufmerksam wäre ich bei Funktionen, die selbst Aktualisierungen ausführen dürfen. Die dafür benötigten Rechte und Schlüssel sollten nicht beiläufig in einem beliebigen Hintergrunddienst landen.
Auch die Dauer der Betreuung muss realistisch geplant werden. Für die grundsätzlich ab Dezember 2027 anzuwendenden Supportpflichten sieht der CRA einen Supportzeitraum von mindestens fünf Jahren vor. Bei einer erwarteten Nutzung von weniger als fünf Jahren entspricht er dieser kürzeren Nutzungszeit. Eine längere erwartete Nutzung ist bei der Festlegung ebenfalls zu berücksichtigen. [5]
Das ist keine Zusage, dass jedes Produkt genau fünf Jahre betreut werden muss und danach jede Verantwortung endet.
Für die Kalkulation bedeutet es: Mit der ersten Auslieferung ist die Entwicklungsarbeit nicht abgeschlossen. Ich würde Zeit für Sicherheitskorrekturen, Tests, unterstützte Versionen und die Kommunikation mit Nutzern vorsehen.
Die Meldepflicht verlangt einen vorbereiteten Ablauf
Nach den am 11. September 2026 aktualisierten Hinweisen der Europäischen Kommission müssen betroffene Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Vorgesehen sind eine Frühwarnung unverzüglich, spätestens innerhalb von 24 Stunden, sowie eine weitergehende Meldung spätestens innerhalb von 72 Stunden nach Kenntniserlangung. [2]
Für den Abschlussbericht unterscheiden sich die Fristen: Bei aktiv ausgenutzten Schwachstellen beträgt sie spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme. Bei schwerwiegenden Sicherheitsvorfällen gilt grundsätzlich ein Monat nach der 72-Stunden-Meldung. Die Meldungen erfolgen über die zentrale CRA-Meldeplattform der ENISA. [2]
Nicht jede Fehlermeldung und nicht jeder gescheiterte Anmeldeversuch erfüllt damit automatisch die gesetzlichen Voraussetzungen. Die Einordnung muss anhand des konkreten Sachverhalts erfolgen.
Außerdem können die Meldepflichten auch erfasste Produkte betreffen, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. [5]
Organisatorisch würde ich dafür einen klaren Weg vorbereiten. Wer nimmt Hinweise entgegen? Wer bewertet die technische Lage? Wer entscheidet über erforderliche Meldungen und wer übernimmt bei Abwesenheit?
Eine Nachricht in einem selten gelesenen Postfach ist für mich noch kein funktionierendes Schwachstellenmanagement.
Dokumentation muss zur ausgelieferten Software passen
Eine umfangreiche Dokumentation hilft wenig, wenn sie einen längst überholten Produktstand beschreibt.
Ich würde deshalb wichtige Nachweise mit den jeweiligen Versionen verbinden: Welche Komponenten waren enthalten? Welche Prüfungen wurden ausgeführt? Welche Einschränkungen waren bekannt? Welche Änderungen sind gegenüber der Vorgängerversion hinzugekommen?
Auch ein gemeldetes Problem sollte nachvollziehbar bearbeitet werden können. Dazu gehören der Eingang des Hinweises, die Bewertung, erforderliche Maßnahmen und der Stand der Korrektur.
Für kleinere Teams muss daraus kein unnötig kompliziertes Verfahren werden. Ein geordnetes Versionsverwaltungssystem, nachvollziehbare Vorgänge und verbindliche Zuständigkeiten können ein sinnvoller Anfang sein.
Die Europäische Kommission veröffentlichte am 27. Juli 2026 zusätzliche, nicht verbindliche Anwendungshinweise zum CRA. Sie behandeln unter anderem den Anwendungsbereich, wesentliche Änderungen, Supportzeiträume und Meldepflichten. Solche Hilfen erleichtern die Orientierung; maßgeblich bleibt die Verordnung. [7]
CE-Kennzeichnung bedeutet nicht, dass nichts mehr passieren kann
Zum CRA gehört auch die Konformitätsbewertung. Welche Verfahren zulässig oder erforderlich sind, hängt von der Produktkategorie ab. Für viele Produkte ist eine Bewertung durch den Hersteller möglich; für bestimmte wichtige oder kritische Kategorien gelten strengere Vorgaben beziehungsweise Anforderungen an die Beteiligung einer unabhängigen Stelle. Das erläutert die Kommission in ihrer am 31. Juli 2026 aktualisierten Übersicht. [8]
Ich würde eine CE-Kennzeichnung deshalb nicht als Werbeversprechen „unhackbar“ verwenden. Die Erfüllung rechtlicher Anforderungen ersetzt weder sorgfältigen Betrieb noch die weitere Beobachtung von Schwachstellen.
Ebenso wenig wäre ein einzelner automatischer Sicherheitsscan für mich bereits der Nachweis vollständiger CRA-Konformität.
Was ich jetzt zuerst angehen würde
Für ein bestehendes Softwareprodukt würde ich mit einer überschaubaren Bestandsaufnahme beginnen: Anwendungsbereich klären, unterstützte Versionen erfassen, Komponenten zuordnen und die vorhandenen Melde- und Updatewege prüfen.
Anschließend würde ich die größten praktischen Lücken priorisieren. Wenn keine verlässliche Komponentenübersicht existiert, muss diese hergestellt werden. Wenn niemand Sicherheitsmeldungen bearbeitet, braucht es eine Zuständigkeit. Wenn Korrekturen nicht kontrolliert ausgeliefert werden können, ist der Updateprozess zu verbessern.
Bei einer neuen Anwendung würde ich diese Punkte direkt in die Architektur- und Projektplanung aufnehmen. Das erscheint mir sinnvoller, als kurz vor einer Frist sämtliche Nachweise und Abläufe nachträglich zusammenzustellen.
Mein Fazit: Sicherheit ist auch eine Frage der Wartbarkeit
Der Cyber Resilience Act macht deutlich, dass die Verantwortung für Software nicht mit ihrer ersten Veröffentlichung endet.
Für mich steckt darin auch eine technische Erkenntnis: Eine verständlich aufgebaute Anwendung lässt sich besser prüfen, gezielter korrigieren und verlässlicher weiterentwickeln. Das hilft nicht nur bei gesetzlichen Anforderungen, sondern auch dann, wenn unter Zeitdruck ein reales Problem behoben werden muss.
Ich würde den CRA deshalb weder auf eine zusätzliche Dokumentenpflicht reduzieren noch als Anlass für pauschale Sicherheitsversprechen verwenden.
Sichere Software braucht einen nachvollziehbaren Aufbau, bekannte Bestandteile und einen funktionierenden Weg vom gemeldeten Problem bis zur überprüften Korrektur.
Einordnung und Recherche
Recherchestand: 9. Oktober 2026. Rechts- und Recherchestand: 9. Oktober 2026. Allgemeine Information, keine rechtliche Prüfung eines konkreten Produkts, Geschäftsmodells oder Einzelfalls. Die Beispiele bilden kein vollständiges Konformitäts- oder Sicherheitskonzept ab. Meldepflichten seit September 2026 und wesentliche weitere Pflichten ab Dezember 2027 sind zu unterscheiden.
Quellen und weiterführende Informationen
Quellenprüfung am 09.10.2026. Abrufdaten sind keine Veröffentlichungsdaten. Hersteller-, Forschungs- und Behördenquellen wurden direkt geprüft.
[1] Europäische Kommission: „Cyber Resilience Act“
Quelle lesen ↗
[2] Europäische Kommission: „Cyber Resilience Act – Reporting obligations“
Quelle lesen ↗
[3] Europäische Kommission: „The Cyber Resilience Act – Summary of the legislative text“
Quelle lesen ↗
[4] Europäische Kommission: „Cyber Resilience Act – Open source“
Quelle lesen ↗
[5] Verordnung (EU) 2024/2847 vom 23. Oktober 2024 – Cyber Resilience Act
Quelle lesen ↗
[6] NIST: „Secure Software Development Framework, Version 1.1“, SP 800-218
Quelle lesen ↗
[7] Europäische Kommission: Anwendungshinweise zum Cyber Resilience Act
Quelle lesen ↗
[8] Europäische Kommission: „Cyber Resilience Act – Conformity assessment“
Quelle lesen ↗