Cyber Resilience Act und Individualsoftware: Welche Pflichten bei Auftragsentwicklung ab dem 11.09.2026 gelten

Gilt die Verordnung auch für Software, die Sie in Auftrag geben?

Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten und gilt vollständig ab dem 11. Dezember 2027. Erfasst sind Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden. Entscheidend ist nicht, ob eine Anwendung für tausend Kunden oder für genau einen entsteht, sondern ob sie im Rahmen einer Geschäftstätigkeit an einen anderen Rechtsträger abgegeben wird.

Eine Individualentwicklung, die Sie extern beauftragen und anschließend im eigenen Haus einsetzen, liegt damit nach überwiegender Auslegung im Anwendungsbereich. Außen vor bleibt reine Eigenentwicklung, die ein Unternehmen nur intern nutzt und niemals abgibt. Wer heute Angebote einholt, sollte diese Frage vor der Beauftragung klären — nachträglich wird sie teuer.

Hersteller, Auftraggeber, Entwicklungspartner — wer trägt welche Pflicht?

Hersteller im Sinne der Verordnung ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke auf dem Markt bereitstellt. Bei Auftragsentwicklung ist diese Rolle nicht automatisch verteilt: Sie kann beim Entwicklungspartner liegen, der die Lösung liefert, ebenso beim Auftraggeber, der sie unter eigenem Namen einsetzt oder weitergibt.

Beide Konstellationen kommen vor, und die Abgrenzung ist juristisch umstritten — sie gehört deshalb früh auf den Tisch Ihrer Rechtsberatung und anschließend in den Vertrag. Praktisch heißt das: In die Ausschreibung gehört eine Zeile, die die Herstellerrolle benennt und die Zuarbeit des jeweils anderen Partners beschreibt. Ohne diese Zeile entsteht eine Lücke, die erst im Ernstfall sichtbar wird — dann, wenn eine Meldefrist läuft.

Der 11. September 2026: Meldewege, Fristen, Zuständigkeiten

Aktiv ausgenutzte Schwachstellen erfordern eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden. Adressaten sind die zuständige CSIRT-Stelle und die ENISA über die vorgesehene Meldeplattform; ein Abschlussbericht folgt nach den in der Verordnung genannten Fristen.

Damit das im Alltag funktioniert, braucht ein Unternehmen drei Dinge, bevor der Termin erreicht ist:

• eine benannte Person mit Vertretung, die Meldungen verantwortet;
• einen dokumentierten Ablauf vom Betriebsteam bis zur Behörde;
• eine vertragliche Zusage des Entwicklungspartners, innerhalb welcher Reaktionszeit er technische Analysen beisteuert.

24 Stunden sind keine Frist, die sich improvisieren lässt — schon gar nicht am Wochenende.

Bis zum 11. Dezember 2027: Nachweise, die im Projekt entstehen müssen

Der Unterstützungszeitraum beträgt nach der Verordnung (EU) 2024/2847 mindestens fünf Jahre, sofern die Produktlebensdauer nicht kürzer ist. Daraus folgt eine Liste an Artefakten, die nicht am Ende, sondern während des Projekts entstehen:

• Risikobetrachtung zur Cybersicherheit;
• technische Dokumentation;
• Software-Stückliste (SBOM) mindestens für die obersten Abhängigkeitsebenen;
• ein Prozess für Sicherheitsupdates;
• eine Kontaktstelle für Schwachstellenmeldungen;
• Nutzerinformationen zur sicheren Inbetriebnahme.

Wer diese Punkte erst nach dem Go-live angeht, zahlt sie zweimal: einmal für die nachträgliche Rekonstruktion und einmal für die Verzögerung. Wir ordnen sie deshalb den Projektphasen zu, so wie es die Arbeitsweise auf unserer Seite zu Individualsoftware und Systemintegration beschreibt.

Fünf Klauseln, die in den Entwicklungsvertrag gehören

Fünf Klauseln verteilen bei Auftragsentwicklung die Pflichten aus dem Cyber Resilience Act:

1. Rollenzuweisung: Wer ist Hersteller, wer Zulieferer, wer verantwortet die CE-Kennzeichnung.
2. Lieferpflicht für SBOM und technische Dokumentation als Teil jeder Release-Abnahme, nicht als Anlage danach.
3. Reaktionszeit für sicherheitsrelevante Befunde, abgestimmt auf die Frist von 24 Stunden.
4. Update-Verpflichtung über den vereinbarten Unterstützungszeitraum inklusive Regelung für das Ende der Zusammenarbeit — Stichwort Quellcode-Hinterlegung und Wissenstransfer.
5. Behandlung von Open-Source-Komponenten samt Verantwortung für deren Aktualisierung.

Selbstcheck in acht Fragen — direkt hier durchgehen

Acht Prüffragen ordnen den CRA-Status eines laufenden Entwicklungsprojekts ein. Jede Frage, die Sie nicht mit einem klaren Ja beantworten, ist eine offene Position.

1. Wird die Software an einen anderen Rechtsträger abgegeben?
2. Ist im Vertrag benannt, wer Hersteller ist?
3. Existiert eine aktuelle SBOM zum letzten Release?
4. Gibt es eine dokumentierte Kontaktstelle für Schwachstellenmeldungen?
5. Ist der Unterstützungszeitraum schriftlich festgelegt?
6. Liegt ein Ablauf für die 24-Stunden-Frühwarnung mit benannter Vertretung vor?
7. Sind Fernverarbeitungsdienste und Schnittstellen in der technischen Dokumentation erfasst?
8. Ist geregelt, wer Sicherheitsupdates nach Projektende liefert?

Schicken Sie uns Ihre Antworten in einer kurzen E-Mail an info@primessio.com — wir gehen die offenen Punkte in einem Gespräch mit Ihnen durch und ordnen sie den Projektphasen zu.

Wie wir Compliance-Anforderungen in Projekten führen

Das Team von Primessio hat 50+ Projekte abgeschlossen und arbeitet seit 20+ Jahren an IT-Projekten in Teams von 5 bis 75 Personen. Dazu zählt Erfahrung aus Projekten bei der Staatlichen Feuerwehr Polens — ein System mit 22.000 Nutzern und 20,3 Mio. PLN Projektbudget — sowie Erfahrung aus Projekten bei BNP Paribas und Bank BGŻ. Diese Nennungen beschreiben Projekterfahrung des Teams und sind nicht als Kundenliste von Primessio zu verstehen.

Regulatorische Anforderungen behandeln wir dort wie jedes andere Projektrisiko: benannt, terminiert, einem Verantwortlichen zugeordnet. „Klarer Umfang zu Beginn, kurze Zyklen und empirische Prüfung jeder Änderung. Warnsignale erkenne ich früh — wenn eine Korrektur noch günstig ist — und Sie haben einen einzigen Verantwortlichen für das Ergebnis“, beschreibt Dariusz Wtykło, Inhaber und CEO von Primessio, die Arbeitsweise.

Wir unterstützen die Konformität mit den Anforderungen; die rechtliche Bewertung Ihres Einzelfalls bleibt bei Ihrer Rechtsberatung. Wir arbeiten aus Warschau für Kunden im DACH-Raum — 1 bis 2 Flugstunden entfernt, in derselben Zeitzone (CET), mit Datenhaltung in der EU.

Quellen, Autor, Stand und Grenzen dieses Beitrags

Die Verordnung (EU) 2024/2847 sieht Geldbußen von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes vor. Alle Termin- und Fristangaben in diesem Beitrag stammen aus dem Verordnungstext, abrufbar über EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj.

Autor: Dariusz Wtykło, Inhaber und CEO von Primessio (ACTIVE IT), Methoden PRINCE2, Agile und IPMA. Stand: 08.2026. Dieser Beitrag fasst den Regelungsrahmen für die Projektplanung zusammen und ersetzt keine Rechtsberatung; er enthält keine Zusicherung eines bestimmten regulatorischen Ergebnisses. Für die Einordnung Ihres konkreten Produkts, insbesondere bei hybriden Architekturen mit Fernverarbeitungsdiensten, ziehen Sie bitte eine spezialisierte Kanzlei hinzu — die technische Seite arbeiten wir gerne zu.

Gehen Sie den Selbstcheck aus acht Fragen für Ihr Projekt durch und schicken Sie uns Ihre Antworten in einer kurzen E-Mail an info@primessio.com oder über die Kontaktseite. Wir vereinbaren ein Gespräch, ordnen die offenen Punkte den Projektphasen zu und sagen Ihnen klar, was technisch bis September 2026 stehen muss — und was Ihre Rechtsberatung entscheiden sollte.

Häufige Fragen

Gilt der Cyber Resilience Act auch für Individualsoftware?

Ja, in aller Regel. Die Verordnung (EU) 2024/2847 knüpft nicht an die Stückzahl an, sondern an die Bereitstellung eines Produkts mit digitalen Elementen auf dem Unionsmarkt im Rahmen einer Geschäftstätigkeit. Eine Software, die ein Dienstleister entwickelt und an Ihr Unternehmen liefert, ist damit erfasst. Außerhalb bleibt reine Eigenentwicklung, die ein Unternehmen ausschließlich intern nutzt und nie an einen anderen Rechtsträger abgibt. Die Einordnung im Einzelfall gehört auf den Tisch Ihrer Rechtsberatung, nicht in eine Blog-Checkliste.

Wer ist bei Auftragsentwicklung Hersteller im Sinne der CRA?

Hersteller ist, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke auf dem Markt bereitstellt. Bei Auftragsentwicklung ist die Rolle nicht automatisch verteilt: Sie kann beim Entwicklungspartner liegen, der die Lösung liefert, ebenso beim Auftraggeber, der sie unter eigenem Namen einsetzt oder weitergibt. Die Abgrenzung ist juristisch umstritten und im Einzelfall rechtlich zu prüfen — geklärt und im Vertrag abgebildet gehört sie, bevor die erste Zeile Code entsteht.

Was passiert am 11. September 2026?

Ab dem 11. September 2026 gelten die Meldepflichten der Verordnung (EU) 2024/2847. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die zuständige CSIRT-Stelle und die ENISA melden: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht nach den in der Verordnung genannten Fristen. Praktisch heißt das: benannte Zuständigkeit, erreichbarer Kontaktweg und ein dokumentierter Ablauf müssen vorher stehen — im September ist keine Zeit für Organisation.

Fällt SaaS unter den Cyber Resilience Act?

Reine Cloud-Dienste sind primär Gegenstand anderer Regelwerke wie NIS2. Erfasst werden jedoch Fernverarbeitungslösungen, deren Funktion für das Produkt mit digitalen Elementen erforderlich ist — etwa ein Backend, ohne das Ihre Anwendung nicht arbeitet. Bei hybriden Architekturen aus lokaler Anwendung und angebundenem Dienst lohnt sich die Abgrenzung früh, weil sie über technische Dokumentation und Meldewege entscheidet.

Wie hoch sind die Bußgelder nach dem Cyber Resilience Act?

Die Verordnung sieht für Verstöße gegen die grundlegenden Anforderungen und die Herstellerpflichten Geldbußen von bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Für andere Pflichtverstöße und für falsche Angaben gegenüber Behörden gelten niedrigere Stufen. Die konkrete Bemessung liegt bei den nationalen Marktüberwachungsbehörden.

Brauchen wir eine SBOM für unsere Individualsoftware?

Die Verordnung verlangt von Herstellern eine systematische Schwachstellenbehandlung, dazu gehört eine Software-Stückliste (SBOM) mindestens für die obersten Abhängigkeitsebenen. Für Auftragsentwicklung bedeutet das: Die SBOM ist Teil der Lieferung, nicht eine Beilage danach. Legen Sie im Vertrag fest, in welchem Format sie erzeugt wird, wer sie bei jedem Release aktualisiert und wie lange sie verfügbar bleibt.

Passende Leistung: Software & IT-Systeme →

Mehr dazu

Projektmanagement →Nearshore Softwareentwicklung →DSGVO auf der Unternehmenswebsite — Checkliste →Was kostet Individualsoftware statt Standardsoftware? Die Break-even-Rechnung →