Cyber Resilience Act: Warum Dev-Teams vor September 2026 ihre Sicherheitsprozesse sortieren sollten

Der Cyber Resilience Act klingt nach einem Thema für Gerätehersteller, IoT-Konzerne und Menschen mit sehr vielen Excel-Tabellen. Das ist nur halb richtig. Die Verordnung betrifft Produkte mit digitalen Elementen — also Hardware und Software, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden können. Damit rückt auch klassische Softwareentwicklung stärker in Richtung Produktsicherheit.

Für kleine Dev-Teams, Agenturen und SaaS-nahe Anbieter ist der wichtigste Punkt nicht Panik. Der wichtigste Punkt ist: Sicherheitsprozesse müssen sichtbar und wiederholbar werden, bevor jemand fragt, warum ein kritischer Bug drei Wochen in einem Slack-Thread verschimmelt ist.

Was jetzt zeitlich wichtig wird

Die EU-Kommission beschreibt den Cyber Resilience Act als Regelwerk, das digitale Produkte sicherer machen soll. Er führt verpflichtende Cybersicherheitsanforderungen für Hersteller ein, die Planung, Design, Entwicklung und Wartung betreffen. Außerdem müssen Hersteller Schwachstellen über den Lebenszyklus ihrer Produkte behandeln.

Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die meisten Hauptpflichten gelten ab dem 11. Dezember 2027. Vorher kommt aber ein wichtiger Zwischenpunkt: Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab dem 11. September 2026.

Das ist für Produktteams praktisch nah. Wer heute Plugins, Desktop-Apps, mobile Apps, On-Premise-Software, Geräte-Software oder kommerzielle Softwarekomponenten baut, sollte nicht bis Sommer 2026 warten, um herauszufinden, wer intern überhaupt für Sicherheitsmeldungen zuständig ist.

Betrifft das jede Website?

Nein. Eine normale Unternehmenswebsite ist nicht automatisch ein Produkt mit digitalen Elementen im Sinne des CRA. Das wäre zu grob und ehrlich gesagt auch regulatorischer Drachennebel.

Relevant wird es eher, wenn ein Unternehmen Software als Produkt bereitstellt oder vertreibt, zum Beispiel:

• ein WordPress-Plugin oder Theme,
• eine mobile oder Desktop-App,
• eine self-hosted SaaS-Version,
• eine Softwarebibliothek oder ein SDK,
• ein verbundenes Gerät oder dessen Firmware,
• ein kommerzielles Tool, das Kund:innen installieren oder integrieren.

Für reine Website-Betreiber bleibt der CRA trotzdem indirekt wichtig. Viele Websites hängen an Plugins, Tracking-Tools, Consent-Lösungen, Payment-Integrationen, Formularsystemen, Hosting-Panels oder KI-Diensten. Wenn diese Komponenten unsicher sind, landet das Problem trotzdem im Betrieb.

Was Dev-Teams jetzt dokumentieren sollten

Der praktische Start ist keine riesige Policy. Der Start ist eine kleine Sicherheitsakte im Projekt, zum Beispiel docs/security-process.md. Darin sollte stehen:

1. Produktgrenzen: Was ist das Produkt, welche Komponenten gehören dazu und was ist nur externe Infrastruktur?
2. Komponentenliste: Welche eigenen Module, Open-Source-Abhängigkeiten, APIs und Drittanbieter sind sicherheitsrelevant?
3. Update-Strategie: Wie schnell werden kritische Patches bewertet, getestet und veröffentlicht?
4. Schwachstellenannahme: Gibt es eine E-Mail-Adresse oder Security-Policy, über die externe Meldungen ankommen?
5. Incident-Weg: Wer entscheidet, ob ein Vorfall meldepflichtig, kund:innenrelevant oder nur intern zu behandeln ist?
6. Release-Nachweise: Wo werden Sicherheitsfixes, Versionen, Changelogs und betroffene Kund:innen dokumentiert?
7. Abhängigkeiten: Welche Tools prüfen Dependencies, Container, Secrets und bekannte CVEs?

Das klingt banal. Aber banal ist gut. Banal lässt sich im Ernstfall finden. Banal rettet Nerven.

Der Unterschied zwischen Bugfix und Sicherheitsprozess

Viele kleine Teams behandeln Security noch wie normale Bugs: Ticket rein, irgendwann fixen, deployen, fertig. Das reicht bei sicherheitsrelevanten Produkten nicht mehr.

Ein Sicherheitsprozess braucht mindestens drei zusätzliche Fragen:

• Auswirkung: Können Daten offengelegt, verändert, gelöscht oder Systeme übernommen werden?
• Ausnutzung: Wird die Schwachstelle bereits aktiv ausgenutzt oder gibt es öffentliche Exploits?
• Kommunikation: Müssen Kund:innen, Behörden, Hostingpartner oder andere Anbieter informiert werden?

Gerade bei AI-generiertem Code und schnell zusammengebauten Prototypen ist diese Trennung wichtig. Ein Feature kann funktional wirken und trotzdem unsichere Defaults, fehlende Validierung, zu offene CORS-Regeln, geleakte Secrets oder gefährliche Datei-Uploads enthalten. Der Build ist grün, aber der Drache im Keller hat WLAN.

Open Source: Nicht automatisch raus aus der Nummer

Der CRA berücksichtigt Open Source besonders. Nicht-kommerzielle freie und Open-Source-Software wird anders behandelt als kommerziell bereitgestellte Produkte. Aber sobald Open-Source-Komponenten in einem kommerziellen Produkt landen, verschwindet Verantwortung nicht magisch.

Für Teams heißt das: Eine Dependency-Liste ist keine Kür. Sie ist Grundlage für Updates, Risikoentscheidungen und Kommunikation. Wer nicht weiß, welche Bibliotheken im Produkt stecken, kann auch nicht sauber bewerten, ob eine neue CVE relevant ist.

Praktische To-do-Liste für diese Woche

Wer sich jetzt vorbereiten will, kann klein anfangen:

• Eine SECURITY.md oder Kontaktadresse für Schwachstellenmeldungen anlegen.
• Kritische Dependencies mit einem Tool wie Dependabot, Renovate oder einem SCA-Scanner überwachen.
• Einen festen Ablauf für kritische Sicherheitsupdates definieren.
• Release Notes so schreiben, dass Sicherheitsfixes später nachvollziehbar sind.
• Secrets, Uploads, Auth, Rollenrechte und Adminfunktionen gezielt reviewen.
• Für kommerzielle Softwareprodukte eine einfache Komponentenliste pflegen.

Das Ziel ist nicht, morgen wie ein Konzern zu wirken. Das Ziel ist, im Ernstfall nicht wie ein panischer Kobold mit Produktionszugriff zu handeln.

Fazit

Der Cyber Resilience Act macht Produktsicherheit verbindlicher. Die meisten Pflichten greifen erst 2027, aber die Reporting-Schiene startet 2026. Für Softwareteams ist jetzt der richtige Zeitpunkt, Sicherheitsprozesse zu sortieren: Was bauen wir, welche Komponenten nutzen wir, wie behandeln wir Schwachstellen, wer entscheidet im Incident und wie dokumentieren wir Updates?

Wer diese Grundlagen früh sauber hält, gewinnt nicht nur regulatorisch. Er baut bessere Software, reduziert Betriebsrisiken und kann Kund:innen deutlich souveräner erklären, wie Sicherheit im Projekt wirklich funktioniert.

Quellen

• European Commission: Cyber Resilience Act
• Regulation (EU) 2024/2847, Cyber Resilience Act

Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.