EU Cyber Resilience Act: Was er für digitale Produkte bedeutet

Der EU Cyber Resilience Act klingt nach einem weiteren Compliance-Thema, das irgendwo zwischen Legal, Security und Produktmanagement herumgereicht wird. In Wahrheit ist er etwas anderes: ein Signal, dass Cybersicherheit nicht mehr als Add-on behandelt werden kann.

Wenn ein Produkt digitale Elemente hat, soll Sicherheit Teil des Produkts sein. Nicht erst nach dem Launch. Nicht erst nach dem ersten Vorfall. Und nicht nur als PDF im Audit-Ordner.

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act ist eine EU-Verordnung für Produkte mit digitalen Elementen. Dazu können Software, Hardware, vernetzte Geräte, IoT-Produkte und viele digitale Komponenten gehören.

Die offizielle Rechtsgrundlage ist die Verordnung (EU) 2024/2847. Sie wurde 2024 veröffentlicht und gilt schrittweise: Meldepflichten für bestimmte Schwachstellen und Sicherheitsvorfälle greifen früher, die meisten Anforderungen werden ab dem 11. Dezember 2027 relevant.

Das Ziel ist simpel: Produkte sollen sicherer entwickelt, ausgeliefert, gewartet und dokumentiert werden.

Warum das für Produktteams relevant ist

Viele Teams denken bei Regulierung zuerst an Checklisten. Der CRA ist aber eher ein Produkt- und Prozessproblem.

Denn die Fragen dahinter sind praktisch:

• Wie gehen wir mit Sicherheitsupdates um?
• Wer bewertet Schwachstellen?
• Welche Komponenten stecken in unserem Produkt?
• Wie lange supporten wir ein Produkt nach Release?
• Wie dokumentieren wir Sicherheitsentscheidungen?
• Wie schnell können wir reagieren, wenn eine Lücke aktiv ausgenutzt wird?

Das sind keine reinen Legal-Fragen. Das sind Architektur-, DevOps-, Produkt- und Ownership-Fragen.

Was sich konkret ändert

Der CRA verschiebt die Verantwortung stärker in Richtung Hersteller und Anbieter. Wer Produkte mit digitalen Elementen in der EU bereitstellt, muss je nach Produktklasse nachweisen können, dass Cybersicherheit systematisch berücksichtigt wurde.

Praktisch bedeutet das:

1. Security by Design wird Pflichtprogramm

Sicherheit soll nicht nachträglich angeklebt werden. Produktteams müssen Risiken bereits in Konzeption, Architektur und Entwicklung mitdenken.

Das betrifft zum Beispiel:

• sichere Standardkonfigurationen
• Zugriffsschutz und Authentifizierung
• Schutz vor unbefugtem Zugriff
• sichere Update-Mechanismen
• Minimierung bekannter Angriffsvektoren

Kurz: "Wir patchen das später" wird als Produktstrategie immer schlechter.

2. Vulnerability Management wird Teil des Produkts

Ein Produkt ist nicht fertig, wenn es released ist. Es braucht einen Prozess für Schwachstellen.

Teams sollten klären:

• Wo melden Nutzer oder Forschende Sicherheitslücken?
• Wer triagiert diese Meldungen?
• Wie werden Fixes priorisiert?
• Wie werden Security Updates ausgeliefert?
• Wie dokumentieren wir bekannte Risiken?

Das klingt trocken, aber es ist genau der Unterschied zwischen "Wir hoffen, dass nichts passiert" und "Wir können reagieren".

3. Dokumentation wird wichtiger

Der CRA wird Dokumentation nicht beliebter machen. Aber er macht sie relevanter.

Produktteams sollten nachvollziehbar festhalten:

• welche Komponenten verwendet werden
• welche Sicherheitsannahmen getroffen wurden
• welche Risiken bewertet wurden
• welche Updates und Support-Zeiträume vorgesehen sind
• welche Konformitätsbewertung nötig ist

Das ist nicht nur für Auditoren hilfreich. Es hilft auch dem eigenen Team, sechs Monate später noch zu verstehen, warum eine Entscheidung getroffen wurde.

4. Lieferketten werden sichtbarer

Kaum ein digitales Produkt entsteht heute komplett selbst. Frameworks, Libraries, APIs, Cloud-Services, Container Images, SaaS-Komponenten: alles Teil der Lieferkette.

Der CRA passt zu einer Entwicklung, die ohnehin längst nötig ist: Teams brauchen mehr Transparenz über ihre Software Supply Chain.

Mindestens sollte klar sein:

• Welche externen Komponenten verwenden wir?
• Welche davon sind kritisch?
• Wie erfahren wir von Schwachstellen?
• Wie schnell können wir aktualisieren?
• Wer ist verantwortlich, wenn ein Bestandteil ausfällt oder unsicher wird?

Was jetzt nicht passieren sollte

Der schlechteste Reflex wäre, den CRA bis 2027 zu ignorieren und dann hektisch "Compliance" über ein bestehendes Produkt zu kippen.

Das wird teuer, langsam und unangenehm.

Besser ist ein pragmatischer Start:

1. Bestehende Produkte grob klassifizieren
2. Security-Verantwortlichkeiten klären
3. Update- und Vulnerability-Prozess definieren
4. Abhängigkeiten inventarisieren
5. Security-Anforderungen in neue Produktarbeit integrieren
6. Dokumentation dort starten, wo Risiken wirklich entstehen

Nicht alles muss sofort perfekt sein. Aber die Richtung muss stimmen.

Was das für SaaS und digitale Plattformen heißt

Bei reinen SaaS-Produkten ist die Einordnung nicht immer trivial. Der CRA spricht von Produkten mit digitalen Elementen und erfasst bestimmte Software- und Hardware-Konstellationen. Gleichzeitig gibt es Überschneidungen mit anderen Regelwerken wie NIS2, DORA, DSGVO oder dem AI Act.

Die praktische Frage lautet deshalb nicht: "Betrifft uns das ganz sicher?"

Die bessere Frage lautet: "Welche CRA-Prinzipien sollten wir ohnehin umsetzen, weil sie gutes Produktengineering sind?"

Unsere Antwort:

• Security by Design
• klare Update-Prozesse
• Abhängigkeitsmanagement
• nachvollziehbare technische Dokumentation
• Incident- und Vulnerability-Prozesse
• Produktentscheidungen mit Sicherheitsfolgen sichtbar machen

Selbst wenn ein Produkt am Ende nicht voll unter den CRA fällt, sind diese Punkte keine verschwendete Arbeit.

Unser Take

Der Cyber Resilience Act ist kein reines Compliance-Projekt. Er ist ein Reifegrad-Test für digitale Produktentwicklung.

Teams, die heute schon sauber entwickeln, dokumentieren, patchen und Verantwortung übernehmen, werden weniger Schmerzen haben. Teams, die Security als späteres Ticket behandeln, werden aufholen müssen.

Der beste Zeitpunkt, um sich vorzubereiten, ist nicht Dezember 2027. Es ist jetzt.

Nicht panisch. Nicht mit 80-seitigen Policies zum Start. Sondern mit einem klaren Blick auf Produktarchitektur, Prozesse und Verantwortlichkeiten.

Oder kurz gesagt: Sicherheit wird vom Nebensatz zur Produkteigenschaft.