Der Cyber Resilience Act, kurz CRA, ist die Verordnung (EU) 2024/2847. Er gilt unmittelbar in Deutschland und allen anderen EU-Staaten. Er verpflichtet Hersteller von Produkten mit digitalen Elementen, also auch von Software, zu Sicherheit über den gesamten Lebenszyklus.
Hersteller ist, wer ein solches Produkt unter eigenem Namen oder eigener Marke vermarktet, entgeltlich oder kostenlos (Art. 3 Nr. 13 CRA). Für deine Agentur heißt das:
- Baust du im Auftrag und der Kunde vertreibt das Produkt unter seinem Namen, ist meist der Kunde Hersteller.
- Verkaufst oder lizenzierst du eigene Produkte, Plugins oder Bibliotheken, bist du es selbst.
Die Meldepflichten gelten seit dem 11. September 2026, alle anderen Pflichten ab dem 11. Dezember 2027 (Art. 71 Abs. 2 CRA).
Wann ist meine Agentur Hersteller?
Drei typische Konstellationen:
| Konstellation | Wer ist Hersteller? | Was das für dich heißt |
|---|---|---|
| Auftragsentwicklung, Kunde vertreibt unter seinem Namen | Der Kunde | Er reicht Anforderungen an dich weiter: SBOM, Schwachstellenprozess, Updates |
| Eigenes Produkt, Plugin oder eigene Bibliothek, verkauft oder lizenziert | Deine Agentur | Alle Herstellerpflichten treffen dich |
| White-Label-Produkt, ein anderer vertreibt es unter seiner Marke | Wer es unter seinem Namen vermarktet | Vertraglich klären, wer was liefert |
Der CRA erfasst nur Produkte, die als Teil einer Geschäftstätigkeit auf dem Markt bereitgestellt werden (Erwägungsgrund 15 CRA). Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt wird, ist ausgenommen (Erwägungsgrund 18 CRA).
Reine Cloud-Dienste wie SaaS fallen nach Erwägungsgrund 12 CRA grundsätzlich unter NIS2. Der CRA greift bei Cloud-Funktionen nur, wenn sie als Datenfernverarbeitung zu einem Produkt gehören, etwa die Fernsteuerung einer App für ein Gerät.
Welche Pflichten hat ein Hersteller nach dem CRA?
Die wichtigsten Pflichten aus Art. 13, Art. 14 und Anhang I CRA:
- Sicherheit von Anfang an. Das Produkt muss nach den grundlegenden Cybersicherheitsanforderungen in Anhang I Teil I konzipiert und entwickelt sein (Art. 13 Abs. 1).
- Risikobewertung. Du bewertest die Cybersicherheitsrisiken des Produkts, dokumentierst sie und berücksichtigst sie in Planung, Entwicklung, Lieferung und Wartung (Art. 13 Abs. 2 und 3). Die Bewertung gehört in die technische Dokumentation.
- Sorgfalt bei Fremdkomponenten. Wer Komponenten Dritter einbaut, auch Open Source, muss die gebotene Sorgfalt walten lassen, damit sie die Sicherheit des Produkts nicht beeinträchtigen (Art. 13 Abs. 5). Findest du eine Schwachstelle in einer Komponente, meldest du sie dem, der sie pflegt (Art. 13 Abs. 6).
- Software-Stückliste. Du ermittelst und dokumentierst Komponenten und Schwachstellen, unter anderem mit einer SBOM in einem gängigen maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten zeigt (Anhang I Teil II Nr. 1).
- Sicherheitsupdates. Schwachstellen werden unverzüglich behoben, Sicherheitsupdates nach Möglichkeit getrennt von Funktionsupdates ausgeliefert (Anhang I Teil II Nr. 2).
- Unterstützungszeitraum. Du legst fest, wie lange du Schwachstellen behandelst. Er beträgt mindestens 5 Jahre, außer das Produkt wird voraussichtlich kürzer genutzt (Art. 13 Abs. 8). Das Ende muss klar angegeben sein.
Was muss ich melden, und wie schnell?
Seit dem 11. September 2026 gelten die Meldepflichten nach Art. 14 CRA. Für eine aktiv ausgenutzte Schwachstelle:
- Frühwarnung innerhalb von 24 Stunden, nachdem du davon erfahren hast (Art. 14 Abs. 2 Buchst. a).
- Meldung mit allgemeinen Informationen zum Produkt, zur Ausnutzung und zu Gegenmaßnahmen innerhalb von 72 Stunden (Art. 14 Abs. 2 Buchst. b).
- Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur verfügbar ist (Art. 14 Abs. 2 Buchst. c).
Für schwerwiegende Sicherheitsvorfälle gelten ähnliche Stufen (Art. 14 Abs. 3 CRA). Gemeldet wird über die einheitliche Meldeplattform der ENISA.
Für Hersteller mit Hauptniederlassung in Deutschland ist das koordinierende CSIRT in der Regel CERT-Bund beim BSI. Eine vorherige Registrierung ist laut BSI nicht nötig.
Was droht bei Verstößen?
Bei Verstößen gegen die grundlegenden Anforderungen aus Anhang I oder die Pflichten aus Art. 13 und 14 drohen nach Art. 64 Abs. 2 CRA Geldbußen bis zu 15 Mio. Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Was verlangen Kunden, die Hersteller sind, von deiner Agentur?
Wenn du im Auftrag Produkte für Hersteller baust, wandern deren Pflichten in deine Verträge. Rechne mit:
- einer SBOM bei jeder Lieferung,
- einem dokumentierten Prozess für den Umgang mit Schwachstellen,
- Reaktionszeiten für Sicherheitsfixes, die zu den Meldefristen des Kunden passen,
- Wartungsverträgen über den gesamten Unterstützungszeitraum,
- Nachweisen zu sicherer Entwicklung, etwa Code-Reviews und Abhängigkeits-Scans.
Das ist Arbeit, die du verkaufen kannst. Viele mittelständische Hersteller haben keine eigene Sicherheitsabteilung und suchen genau diese Unterstützung. Nach Aufwand, als Retainer, über die gesamte Supportdauer.
Was der CRA für Code bedeutet, der deiner Agentur gehört
Wer eigenen Code lizenzieren will, muss den CRA einpreisen.
| Du gibst die Komponente heraus | Wer ist Hersteller? | Was auf dich zukommt |
|---|---|---|
| Gegen Lizenzgebühr, der Lizenznehmer baut sie in sein Produkt ein | Der Lizenznehmer, für sein Produkt. Er muss bei deiner Komponente die gebotene Sorgfalt walten lassen | Er wird von dir eine SBOM, einen Schwachstellenprozess und Zusagen zu Sicherheitsupdates verlangen |
| Selbst als Produkt unter deinem Namen | Du | Unterstützungszeitraum und Meldepflichten |
Daraus folgen drei Dinge:
- Code mit SBOM, Tests und aktuellem Abhängigkeitsstand ist mehr wert. Käufer und Lizenznehmer zahlen für Code, der sich ohne Risiko einsetzen lässt. Welche Faktoren den Wert bestimmen, steht in Was ist Code wert?.
- Die Lizenz muss regeln, wer welche Pflicht trägt. Wer liefert Sicherheitsupdates, wie lange, zu welchem Preis? Wie Lizenzen aufgebaut sind, steht in Softwarelizenz.
- Ein Verkauf verschiebt die Herstellerrolle. Hersteller ist, wer das Produkt unter eigenem Namen vermarktet (Art. 3 Nr. 13). Verkaufst du Code mit allen Rechten und vermarktet der Käufer ihn danach unter seinem Namen, ist für dieses Produkt der Käufer Hersteller. Wie ein Verkauf abläuft, steht in Quellcode verkaufen.