Cyber Resilience: Was Entscheider beim Kauf von Individualsoftware wissen müssen

© Vadym

Kein reines Herstellerthema

Wenn neue EU-Regulierung kommt, ist der erste Reflex oft: Das betrifft die anderen. Beim Cyber Resilience Act, kurz CRA, der Verordnung (EU) 2024/2847, liegt dieser Reflex nahe, weil die Pflichten formal beim Hersteller digitaler Produkte ansetzen. Und Hersteller, das sind doch die großen Softwarekonzerne, die Apps und Betriebssysteme verkaufen. Oder?

Nicht ganz. Wer als Unternehmen oder Behörde eine individuelle Softwarelösung in Auftrag gibt, sitzt dem beauftragten Entwickler gegenüber und trägt indirekt das Risiko, wenn dieser seinen CRA-Pflichten nicht nachkommt. In der Praxis heißt das: Verträge, die vor zwei Jahren noch vollständig waren, haben heute Lücken. Ausschreibungsunterlagen ohne CRA-Bezug werden ein Problem. Und Dienstleister, die auf Nachfrage nicht sagen können, was eine SBOM ist, sollten zumindest eine rote Flagge setzen.

Der CRA ist seit dem 10. Dezember 2024 in Kraft (Verordnung (EU) 2024/2847). Er tritt schrittweise in Anwendung, die erste wirklich relevante Frist für Hersteller folgt am 11. September 2026. Wer heute ein Software-Projekt vergibt, das 2027 oder später produktiv läuft, beschafft unter CRA-Bedingungen, ob er das in den Vertragsunterlagen stehen hat oder nicht.

Was der CRA eigentlich regelt

Im Kern verpflichtet die Verordnung alle, die Software oder vernetzte Hardware auf dem EU-Markt bereitstellen, zu nachweisbarer IT-Sicherheit, und zwar nicht nur zum Zeitpunkt der Lieferung, sondern über die gesamte Nutzungsdauer.

Die wichtigsten Pflichten auf einen Blick:

Security by Design heißt, dass Sicherheit nicht am Ende eines Projekts eingekauft oder einfach einem bestehenden System aufgedrückt werden darf. Sie muss von der Anforderungsanalyse an mitgedacht werden, in der Architektur, in den Code-Reviews, in den Tests. Das betrifft insbesondere die Authentifizierung in Unternehmenssoftware (und damit auch die klare Abgrenzung zwischen Authentifizierung und Autorisierung), die von Beginn an als fester Bestandteil der Sicherheitsarchitektur geplant werden sollte. Gleiches gilt für die Absicherung von APIs, über die moderne Anwendungen mit Partnern, Cloud-Diensten und internen Systemen kommunizieren. Security by Design ist keine neue Idee, aber erstmals eine verbindliche Anforderung mit regulatorischem Rücken.

Software Bill of Materials (SBOM): Jeder Entwickler muss nachvollziehbar dokumentieren, welche Bibliotheken, Frameworks und Drittkomponenten in seiner Software stecken. Warum das wichtig ist, zeigt sich immer dann, wenn eine kritische Lücke in einer weit verbreiteten Bibliothek bekannt wird. Log4Shell hat das 2021 eindrücklich vorgeführt, der Supply-Chain-Angriff auf Trivy im März 2026 bestätigte es erneut. Ohne SBOM weiß niemand, ob die eigene Anwendung betroffen ist.

Sicherheitsupdates über einen definierten Support-Zeitraum: Nach Art. 13 Abs. 8 der Verordnung muss der Support-Zeitraum die erwartete Lebensdauer des Produkts abbilden und beträgt in der Regel mindestens fünf Jahre. Kürzer darf er nur ausfallen, wenn die erwartete Lebensdauer selbst unter fünf Jahren liegt. Für Behörden mit langen Nutzungszyklen oder Unternehmen mit komplexen Migrationsprozessen ist das eigentlich eine gute Nachricht, ersetzt aber keine vertragliche Festlegung.

Meldepflicht bei aktiv ausgenutzten Schwachstellen: Hersteller müssen ENISA und die zuständigen nationalen Behörden innerhalb von 24 Stunden informieren, wenn eine Schwachstelle in ihrem Produkt aktiv ausgenutzt wird. Voraussetzung dafür ist ein funktionierendes Schwachstellenmanagement, das Lücken überhaupt erst erkennt. Diese Pflicht gilt nach Art. 14 der Verordnung ab dem 11. September 2026.

Dazu kommen technische Dokumentationspflichten, Anforderungen an Risikobewertungen und, für die höchste Risikokategorie, eine verpflichtende Prüfung durch unabhängige Stellen. Wer ein dokumentiertes Schwachstellenmanagement-Konzept aufsetzt, erfüllt große Teile dieser Pflichten auf einen Schlag.

Ebenso relevant ist ein durchdachtes Berechtigungsmanagement, das über den gesamten Lebenszyklus einer Software regelt, wer auf welche Funktionen und Daten zugreifen darf. Mehr zum Thema IT-Security ist im Leitfaden zum IT-Sicherheitsmanagement zu finden.

Wie passt der CRA zu NIS2 und dem AI Act?

Kurze Antwort: Er ergänzt beide, ersetzt keinen. NIS2 richtet sich an die Betreiber kritischer Infrastrukturen und schreibt ihnen vor, wie sie ihre Systeme absichern müssen. Der CRA richtet sich an die Hersteller der Software, die in diesen Systemen läuft. Wer also als Behörde oder Energieversorger Software beschafft, muss potenziell beide Regelwerke gleichzeitig im Blick haben, einmal als Betreiber (NIS2), einmal als Auftraggeber gegenüber dem Hersteller (CRA).

Beim AI Act kommt noch eine weitere Ebene dazu, sobald KI-Komponenten in der Individualsoftware zum Einsatz kommen. Das wird bei modernen Anwendungen zunehmend der Standard.

Gilt das auch für maßgeschneiderte Softwareentwicklung?

Das ist die Frage, die wir in Gesprächen mit IT-Verantwortlichen am häufigsten hören. Und die Antwort lautet: im Regelfall ja.

Der CRA definiert seinen Anwendungsbereich über “Produkte mit digitalen Elementen”, die auf dem Markt bereitgestellt werden. Individualsoftware, die ein Dienstleister für einen konkreten Auftraggeber entwickelt, fällt dann darunter, wenn sie (was bei praktisch jeder Business-Anwendung der Fall ist) Netzwerkverbindungen nutzt, über Schnittstellen mit anderen Systemen kommuniziert oder auf kommerziellen bzw. quelloffenen Drittkomponenten aufbaut.

Eine Ausnahme gibt es für rein interne Software ohne externe Bereitstellung und für nicht-kommerziell vertriebene Open-Source-Projekte. Beide Ausnahmen greifen in der typischen Auftraggeber-Dienstleister-Konstellation aber nicht.

Hier liegt ein häufiges Missverständnis: Formal ist der Entwickler der Hersteller im Sinne des CRA, nicht der Auftraggeber. Aber wer einen Dienstleister beauftragt, der die CRA-Anforderungen ignoriert, sitzt am Ende mit einer Software, die gegen EU-Recht verstößt. Im Behördenkontext ist das besonders heikel, weil es Vergabeverfahren, Prüfungen und Haftungsfragen berührt.

Was das für die Dienstleisterauswahl bedeutet

Wer einen Software-Dienstleister beauftragt, sollte spätestens jetzt wissen, welche Fragen er stellen muss. Nicht als bürokratische Übung, sondern weil die Antworten echte Hinweise auf die Qualität der Zusammenarbeit geben.

Zum Entwicklungsprozess: Kann der Anbieter seinen Secure Development Lifecycle dokumentieren? Wie geht er mit bekannten Schwachstellen in eingesetzten Bibliotheken um, und wie schnell? Gibt es automatisierte Sicherheitstests als festen Bestandteil der Entwicklungspipeline?

Zur SBOM: Liefert der Anbieter bei Projektabschluss eine vollständige Übersicht aller verwendeten Komponenten? Und aktualisiert er diese bei jeder relevanten Änderung?

Zu Zertifizierungen: Eine ISO-27001-Zertifizierung ist kein direkter CRA-Nachweis, zeigt aber, dass Informationssicherheit im Unternehmen systematisch verankert ist und nicht nur auf dem Papier existiert. Wie ISO 27001 konkret in der Softwareentwicklung umgesetzt wird, ist dabei besonders relevant.

Zu Incident-Prozessen: Was passiert, wenn nach der Übergabe eine kritische Lücke bekannt wird? Gibt es einen definierten Ablauf, einen Ansprechpartner, eine SLA für die Reaktionszeit?

Ehrlich gesagt: Viele Dienstleister werden auf diese Fragen noch keine vollständigen Antworten haben. Das liegt nicht unbedingt an fehlender Kompetenz, sondern daran, dass die CRA-Pflichten für viele kleinere Entwicklungsbetriebe Neuland sind. Wichtiger als eine perfekte Antwort ist, dass der Anbieter das Thema ernst nimmt und zeigen kann, wie er damit umgeht.

Verträge neu denken

Der vielleicht konkreteste Handlungsbedarf liegt bei den Vertragsunterlagen. Softwareverträge, die vor 2025 entstanden sind, enthalten typischerweise keinen Bezug auf CRA-Anforderungen. Das ist verständlich, die Verordnung gab es noch nicht. Aber es wäre ein Fehler, neue Projekte mit alten Vertragsvorlagen zu vergeben.

Was in jeden Entwicklungsvertrag gehört:

• Pflicht zur Bereitstellung einer SBOM bei Lieferung und bei wesentlichen Änderungen
• Explizite Regelung zur Laufzeit von Sicherheitsupdates (gesetzlicher Regelfall sind fünf Jahre, kürzer nur bei kürzerer erwarteter Produktlebensdauer)
• Vereinbarte Reaktionszeiten bei bekannt gewordenen Schwachstellen (zum Beispiel kritische Patches innerhalb von 72 Stunden)
• Meldepflichten des Dienstleisters gegenüber dem Auftraggeber bei Sicherheitsvorfällen
• Recht des Auftraggebers auf Einsicht in die technische Sicherheitsdokumentation
• Regelung zur Nutzung und Absicherung von Drittkomponenten

Für die öffentliche Hand kommt noch etwas dazu: CRA-Konformität des Anbieters ist ein legitimes und zunehmend notwendiges Zuschlagskriterium in Ausschreibungen. Vergaberechtlich ist das eine Tür, die jetzt genutzt werden sollte, bevor sie durch Präzedenzfälle geöffnet und wieder kompliziert wird.

Application Management, also die laufende Pflege einer Anwendung nach dem Go-live, gehört ebenfalls in diese Überlegung. Wer nach Projektabschluss keine Betreuung vereinbart hat, kann Sicherheits-Patches nicht systematisch einspielen. Das war schon vorher ein Risiko. Unter dem CRA wird es ein strukturelles Problem.

Die Fristen, die jetzt zählen

Der CRA tritt nicht an einem einzigen Datum vollständig in Kraft, sondern in Stufen. Für Auftraggeber relevant:

Das bedeutet: Wer heute ein Projekt startet, das Ende 2026 oder 2027 abgeliefert wird, beschafft Software, die beim Go-live vollständig unter dem CRA steht. Die Anforderungen sollten also nicht erst bei der Abnahme, sondern schon in der Ausschreibung stehen.

Individualsoftware vs. Standardsoftware: Ändert der CRA die Abwägung?

Manchmal, ja. Bei großen Standardsoftware-Anbietern sind CRA-konforme Prozesse entweder bereits vorhanden oder werden kurzfristig implementiert. Der Haken: Auftraggeber haben wenig Einfluss darauf, was in diesen Produkten steckt. SBOMs werden nicht immer auf Anfrage herausgegeben, technische Dokumentation ist selten vollständig zugänglich.

Bei Individualsoftware sieht das anders aus. Hier lässt sich vertraglich einfordern, was gebraucht wird: SBOM, Sicherheitskonzept, Update-Verpflichtung, Dokumentation. Die Verantwortung liegt bei einem Dienstleister, der direkt ansprechbar ist. Das setzt natürlich voraus, dass die richtigen Fragen gestellt und die Antworten im Vertrag verankert werden.

Cybersicherheit hat sich schon länger von einem IT-Thema zu einem Governance-Thema entwickelt. Der CRA beschleunigt das und macht deutlich, dass Sicherheit bei der Softwarebeschaffung kein Anhang im Lastenheft ist, sondern ein zentrales Vergabekriterium sein muss.

Was jetzt sinnvoll ist

Kein Grund zur Panik, aber ein guter Zeitpunkt für eine ehrliche Bestandsaufnahme. Drei Fragen helfen weiter:

Welche laufenden Verträge haben keinen CRA-Bezug? Gerade bei Software, die noch Jahre im Einsatz sein wird, lohnt es sich, Nachträge zu vereinbaren, bevor ein Vorfall die Frage aufwirft, wer eigentlich zuständig war.

Was steht in den aktuellen Ausschreibungsvorlagen? Wenn IT-Compliance dort auftaucht, aber CRA-spezifische Anforderungen fehlen, ist das eine Lücke, die sich schließen lässt.

Wissen die eigenen Teams, was sie einfordern müssen? Einkauf, IT und Rechtsabteilung reden nicht immer dieselbe Sprache, wenn es um Software-Sicherheitsanforderungen geht. Das zu ändern kostet weniger als ein nachträgliches Audit.

Der Cyber Resilience Act ist kein perfektes Gesetz, keine EU-Verordnung ist das. Aber er verschiebt etwas Grundlegendes: Sicherheit ist jetzt eine Herstellerpflicht, keine Kulanzleistung. Wer das bei der nächsten Softwarevergabe nicht mitdenkt, verschenkt einen echten Hebel.

Weiterführende Informationen

• Cyber Resilience Act im Glossar: Definition, Pflichten und Fristen kompakt
• NIS-2-Anforderungen an Softwareanbieter: Was IT-Dienstleister über NIS-2 wissen müssen
• Sichere Softwareentwicklung: Prinzipien und Best Practices
• DSGVO-konforme Softwareentwicklung: Privacy by Design in der Praxis
• Softwareentwicklung für KRITIS: Sichere Lösungen für kritische Infrastrukturen