Der CRA macht Security zur Lifecycle-Aufgabe
Der EU Cyber Resilience Act ist keine ferne Policy-Diskussion mehr. Laut Europaeischer Kommission ist der CRA am 10. Dezember 2024 in Kraft getreten, Reporting-Pflichten gelten seit dem 11. September 2026, und die Hauptpflichten gelten ab dem 11. Dezember 2027. Fuer Produktteams wird Security damit von einer spaeten Audit-Frage zu einem Thema fuer Design, Entwicklung und Wartung.
Der CRA richtet sich an Produkte mit digitalen Elementen, darunter Software und Remote Data Processing, wenn ein Produkt diese Verarbeitung fuer seine Funktion benoetigt. Nicht jede Webplattform ist automatisch auf dieselbe Weise betroffen, und die rechtliche Einordnung braucht Spezialpruefung. Die technische Richtung ist trotzdem wertvoll: Produkte sollten sicher aktualisiert, dokumentiert, beobachtet und ueber ihren Lebenszyklus betreut werden koennen.
Mit Scope und Ownership beginnen
Eine sinnvolle CRA-Vorbereitung beginnt beim konkreten Produkt, nicht bei generischen Policy-Dokumenten. Teams sollten die kundennahe Anwendung, Admin-Dashboards, Mobile Apps, APIs, gehostete Verarbeitung, Firmware oder Desktop-Clients, Drittkomponenten und Open-Source-Abhaengigkeiten erfassen, die das Produkt funktionsfaehig machen.
Die Kommissionsleitlinien von 2026 nennen genau solche Klaerungspunkte: Remote Data Processing, freie und Open-Source-Software, wesentliche Aenderungen, Support-Zeitraeume, Meldepflichten und Risikobewertung. Das ist ein klares Signal, dass Produktarchitektur, Dependency Ownership und Release Governance zusammen gehoeren.
- Alle Produktflaechen auflisten, die Nutzer installieren, aufrufen oder brauchen.
- Gehostete Service-Logik von Softwarekomponenten trennen, die auf den Markt gebracht werden.
- Fuer jede API, jedes Paket, jede Integration und jeden Release-Kanal einen Owner festlegen.
- Security-relevante Features und geschuetzte Datenfluesse sichtbar markieren.
- Unklare Scope-Fragen fuer rechtliche Spezialpruefung festhalten statt sie im Engineering zu erraten.
Secure by Design in Backlog-Arbeit uebersetzen
Secure by Design klingt abstrakt, bis daraus konkrete Backlog-Arbeit wird. Fuer eine Webplattform oder ein SaaS-Dashboard kann das bedeuten: Threat Modeling fuer kritische Workflows, reduzierte Default-Berechtigungen, klare Tenant-Grenzen, Input-Validierung an API-Kanten, Dependency Scanning, gehaertete Authentifizierung und dokumentierte Recovery-Schritte.
Das ENISA Secure by Design and Default Playbook von 2026 richtet sich an KMU und zeigt dieselbe praktische Richtung: Security-Erwartungen gehoeren ins Design und in Default-Verhalten, nicht nur in Patches nach einem Schwachstellenbericht. Fuer Product Engineering ist die Leitfrage einfach: Was waere ein sicherer Default, wenn der Nutzer nie eine Einstellung aendert?
Schwachstellenprozesse vor dem ersten Incident bauen
Die CRA-Reporting-Regeln machen Vulnerability Handling operativ. Die Kommission beschreibt, dass Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfaelle fuer Produkte mit digitalen Elementen melden muessen, mit einer Fruehwarnung innerhalb von 24 Stunden und einer vollstaendigen Meldung innerhalb von 72 Stunden. Danach folgen finale Berichte je nach Schwachstelle oder Incident.
Auch Teams, die ihren Scope noch nicht final geklaert haben, sollten diesen Prozess nicht erst im echten Incident improvisieren. Ein Produkt braucht Security-Kontakt, Intake-Prozess, Severity-Triage, Tracking betroffener Versionen, Owner-Eskalation, Patch-Plan, Kundenkommunikation und ein belastbares Evidence Log. Ohne diese Bausteine verschwinden die ersten Stunden in Koordination statt Eindaemmung.
- Eine zentrale Security-Intake-Adresse einrichten und an verantwortliche Personen routen.
- Severity Labels fuer ausgenutzte Schwachstellen, schwere Incidents und niedrigere Findings definieren.
- Release-, Dependency- und Konfigurationsdaten nach betroffener Version durchsuchbar halten.
- Kundennahe Update Notes vorbereiten, die Auswirkung erklaeren ohne Exploit-Details offenzulegen.
- Die ersten 24 Stunden in einer Tabletop-Uebung proben, bevor der Prozess gebraucht wird.
SBOMs und Support-Zeitraeume reviewbar machen
Die CRA-Zusammenfassung betont Dokumentation, Sorgfalt bei Drittkomponenten, Konformitaetsbewertung, Vulnerability Handling und verstaendliche Support-Zeitraum-Informationen. Fuer Softwareteams deutet das auf eine reviewbare Product-Security-Akte: Dependency-Inventar, SBOM, Architekturhinweise, Risikobewertung, Testnachweise, Update Policy und End-of-Support-Datum.
Das sollte nicht nur in einem Compliance-Ordner liegen. Produktverantwortliche muessen sehen, ob ein Feature eine neue kritische Abhaengigkeit einfuehrt. Entwickler muessen wissen, welche Library-Versionen produktiv sind. Support-Teams muessen wissen, welche Kundenversion noch unterstuetzt wird. Security-Dokumentation ist dann gut, wenn sie Entscheidungen schneller und klarer macht.
Dashboards fuer Security Operations gestalten
Admin-Dashboards werden oft zu dem Ort, an dem Product Security wirklich betrieben wird: Rollen, Audit Logs, Integrationsstatus, Deployment-Zustand, Datenexporte, Incident Flags und Support-Aktionen. Wenn diese Dashboards schwer durchsuchbar sind oder verlaessliche Zeitstempel fehlen, wird Security-Arbeit langsamer und schlechter nachvollziehbar.
Ein CRA-reifes Produkt braucht kein theatralisches Compliance-Cockpit. Es braucht eine ruhige operative Oberflaeche, die zeigt, welche Versionen aktiv sind, welche Abhaengigkeiten betroffen sein koennten, welche Kunden informiert werden muessen, welche Mitigations ausgerollt sind und wer eine riskante Aktion freigegeben hat. Der Audit Trail sollte fuer Engineering Review und Kundenvertrauen ausreichen.
Ein praktischer Vorbereitungsplan
Fuer EDS-Labs-Product-Engineering-Projekte beginnt ein pragmatischer CRA-Plan mit Discovery: Produktflaechen einordnen, Abhaengigkeiten erfassen, Support-Zusagen sichtbar machen und security-kritische Workflows benennen. Danach werden daraus konkrete Backlog-Punkte: sichere Defaults, Vulnerability Intake, SBOM-Erzeugung, Release Notes, Audit Logging, Incident Runbooks und bessere Dashboards.
Entscheidend ist, CRA-Readiness als Produktqualitaet zu behandeln statt als Papierarbeit. Teams, die erklaeren koennen, was sie ausliefern, wie es abgesichert ist, wie lange es unterstuetzt wird, wie Schwachstellen bearbeitet werden und wie Kunden informiert werden, stehen besser da: regulatorisch, in Procurement-Gespraechen und im Alltag des Produktvertrauens.