BLOG
BLOG
6 Minuten Lesezeit
(1175 Worte)
CRA in 7 Minuten: Der Survival-Guide für Produktteams – ohne Juristendeutsch, mit konkreten To-dos
Der Cyber Resilience Act (CRA) ist die EU-Regel, die aus „nice to have Security“ eine Marktzulassungsbedingung macht. Er betrifft praktisch alle Produkte mit digitalen Elementen – vom smarten Thermostat über Industriesteuerungen bis zur Desktop-App. Und er ändert, wie Sie planen, bauen, ausliefern und pflegen. Hier ist der verständliche, praxisnahe Überblick: Was verlangt der CRA? Wen trifft er? Was müssen Sie jetzt umstellen, damit Features morgen nicht zu Haftung werden?
1) Der CRA in einem Satz
Der CRA verpflichtet Hersteller, Importeure und Händler, cybersichere Produkte zu entwickeln, Sicherheitsrisiken über den gesamten Lebenszyklus zu managen, Schwachstellen zügig zu beheben, Updates bereitzustellen und das alles nachweisbar zu dokumentieren – sonst drohen Bußgelder, Vertriebsstopps und Rückrufe.
2) Wen betrifft das?
- Hersteller (auch Software-Publisher), die Produkte mit digitalen Elementen in der EU in Verkehr bringen.
- Importeure/Vertreiber, die Produkte in die EU holen oder unter eigenem Namen verkaufen (Mitverantwortung!).
- OEM/White-Labeler, die fremde Produkte rebranden (gelten als Hersteller).
- Komponenten- und SDK-Lieferanten indirekt: Ihre Kunden werden CRA-Pflichten in Verträge gießen (SBOM, Patch-SLAs, Disclosure-Regeln).
Faustregel: Wenn Ihr Produkt ohne Software nicht sinnvoll funktioniert oder sich mit einem Netzwerk verbinden kann, denken Sie CRA.
3) Die 10 Kernaussagen – verständlich
- Security by Design & by Default: Sicherheit ist nicht ein Feature, sondern Grundannahme. Voreinstellungen müssen sicher sein.
- Risikomanagement: Sie müssen Risiken identifizieren, bewerten, mitigieren – und das kontinuierlich.
- Schwachstellenmanagement: Sie brauchen einen Schwachstellen-Prozess (inkl. Annahme externer Hinweise), Priorisierung, Behebung, Advisories.
- Updates über den Lebenszyklus: Sicherheitsupdates müssen zeitnah und ohne Zusatzkosten (innerhalb des zugesagten Supportzeitraums) bereitstehen – signiert, rückrollbar, gestaffelt.
- SBOM (Software Bill of Materials): Sie wissen, was Sie ausliefern (Abhängigkeiten, Versionen), um auf CVEs reagieren zu können.
- Lieferkette: Sie steuern Ihre Third Parties: Anforderungen an SBOM, Patch-SLAs, Security-Mitteilungen gehören in die Verträge.
- Konformitätsbewertung & CE: Vor dem Inverkehrbringen: Bewertung, technische Dokumentation, Konformitätserklärung, CE-Kennzeichnung.
- Post-Market-Surveillance: Nach dem Launch beobachten, Daten sammeln, reagieren (PSIRT, Telemetrie, Feedback-Kanäle).
- Meldepflichten: Bestimmte Vorfälle/Sicherheitslücken müssen frühzeitig gemeldet werden (an zuständige Stellen und oft an Kunden).
- Haftung & Sanktionen: Bei Verstößen drohen Bußgelder, Rückruf und Vertriebsverbot. „Wir wussten es nicht“ zählt nicht.
4) Was ändert sich konkret im Alltag?
Produktplanung
„Done“ bedeutet nicht nur „Feature fertig“, sondern: Threat Model aktualisiert, SBOM erzeugt, Artefakte signiert, Updatepfad getestet, Rollback vorhanden, Telemetrie-Hooks aktiv, Dokumentation fortgeschrieben. Roadmaps priorisieren Versorgbarkeit vor „glänzendem Feature“.
Entwicklung & CI/CD
- Automatisierte Security-Checks (SCA, SAST, Secrets-Scanning, Container-Scans) gehören in jede Pipeline.
- Reproduzierbare Builds und signierte Artefakte sind Pflicht.
- SBOM wird automatisch pro Release erzeugt und abgelegt (mit Version/Hash).
Betrieb & Support
- Update-Backbone mit Wellen, Stop-Kriterien, Rollback, stichprobenartiger Validierung in Staging.
- PSIRT (Product Security Incident Response Team) als Orchestrator: Intake, Triage, Fix-Koordination, Advisory, Kundenkommunikation, Meldewege.
Einkauf & Verträge
- Security-Anhänge: SBOM je Release, CVE-Mitteilungen, Patch-SLA, Disclosure-Prozess, Schlüsselmanagement, Mindest-Supportdauer, Audit-Rechte.
Marketing & Vertrieb
- Versprechen nur, was Sie belegen können: Supportzeiträume, Update-Mechanik, Reaktionszeiten. Sicherheit wird Leistungsmerkmal – kein Slogan.
5) SBOM ohne Mythos
Warum? Ohne SBOM wissen Sie nicht, ob eine neue CVE Ihre Kunden betrifft.
Wie? SBOMs automatisiert im Build erzeugen (z. B. CycloneDX, SPDX), versionieren, VEX (Exploitability-Infos) ergänzen.
Wofür? Impact-Analysen in Stunden statt Wochen; fundierte Advisories; belastbare Konformitätsdokumentation.
6) Updates, die nicht weh tun
Ein Update ist kein ZIP-Anhang, sondern ein kontrollierter Prozess:
- Signatur der Pakete, sichere Verteilung, integritätsgeprüfte Installation.
- Staged Rollouts (z. B. 5 % → 20 % → 100 %), Stop-Regeln bei Anomalien, Rollback.
- Telemetrie (Crash-Rate, Boot-Time, Fehlercodes) zur Live-Bewertung.
- Kundenseitig: klare UI/UX, stille Sicherheitsupdates, Wartungsfenster für kritische Umgebungen.
7) PSIRT – die Einsatzleitung
Auftrag: Hinweise annehmen, bewerten, beheben, informieren.
Bausteine: eindeutiger Security-Kontakt (security.txt), SLA für Triage/Fixes, Advisory-Vorlagen, Eskalationspfade (Engineering, Legal, PR, Customer Success), Lessons Learned.
Erfolgsmesser: Mean Time to Acknowledge/Remediate, Fix-Rate, Update-Adoption, SLA-Einhaltung.
8) Dokumentation ohne Papierfriedhof
Der CRA will Nachweise, keine Prosa. Halten Sie schlank fest:
- Produkt-Risikobewertung (aktualisiert je Major-Change).
- Sicherheitsziele & Kontrollen (Design-Entscheidungen mit Begründung).
- Update-Konzept (Lebenszyklus, Supportdauer, Mechanik, Schlüssel).
- Schwachstellenprozess (CVD, PSIRT-Ablauf, Kommunikation).
- Lieferkette (Verträge, Audits, SBOM-Pflichten).
- Post-Market-Surveillance (welche Signale, wie ausgewertet, Trigger).
- Konformitätsbewertung & CE (Erklärung, technische Unterlagen).
Legen Sie das in der Pipeline ab – dann wächst es automatisch mit.
9) „Wie lange“ muss ich updaten?
Das hängt vom Produkt, Risiko und Ihren Zusagen ab. Wichtig ist:
- Vorab klar kommunizieren, wie lange Sicherheitsupdates garantiert sind.
- Kein Kostenhebel für Sicherheitsfixes innerhalb dieser Zeit.
- EOL-Planung früh: Migration, Alternativen, Zeitfenster, Kundeninfo.
10) Häufige Mythen – und was stimmt
- „Wir sind nur Software, kein Gerät – also raus.“
Falsch. Der CRA adressiert Produkte mit digitalen Elementen – Software inklusive. - „Open Source entbindet uns von Pflichten.“
Falsch. Open-Source-Nutzung ist okay, Verantwortung bleibt bei Ihnen. SBOM & Fix-Prozess trotzdem nötig. - „Unser Reseller kümmert sich.“
Mitverantwortung, ja. Aber Herstellerpflichten bleiben bei Ihnen – besonders bei Rebranding/OEM. - „Wir patchen schnell, reicht.“
Nicht ohne Nachweis, Prozess, Dokumentation und kundenfähige Verteilung.
11) Quick-Wins, die Sie in 2–3 Wochen schaffen
- Security-Kontakt veröffentlichen (/.well-known/security.txt) mit CVD-Hinweisen.
- SBOM-Generierung in einem Hauptprodukt automatisieren.
- Signatur der Build-Artefakte einführen (Code-Signing).
- Update-Staging-Plan skizzieren (Wellen, Stop-Kriterien, Rollback-Pfad).
- Mini-PSIRT-Team benennen, Triage-SLA definieren, Advisory-Template anlegen.
- Einkaufs-Klauseln zu SBOM, Patch-SLA, Disclosure in neue Verträge aufnehmen.
Diese Schritte ändern Ihre Roadmap-Gespräche sofort – ohne Mammutprojekt.
12) So passt der CRA in die Regulierungs-Landschaft
- NIS2: Pflichten für Betreiber „wesentlicher Dienste“. Der CRA ergänzt auf Produktebene.
- Funkanlagenrecht (RED): Spezifisch für Funk/IoT; mit CRA mehr Konsistenz.
- AI Act: Für KI-Systeme – Sicherheitsprozesse aus dem CRA helfen, die AI-Governance zu stützen.
Tipp: Bauen Sie Baustein-Prozesse (SBOM/VEX, PSIRT/CVD, Update-Backbone, Lieferkette). Mappen Sie alle Regime darauf – ein System, mehrere Häkchen.
13) Was heißt das für Budget & Roadmap?
Die unsichtbaren Arbeiten werden priorisiert: Update-Infrastruktur, Automatisierung, Lieferketten-Kontrollen, Dokumentation. Das senkt mittelfristig Kosten (weniger Firefighting, weniger Eskalationen) und erhöht Planbarkeit. Machen Sie Sicherheit zum Produktmerkmal: Supportzeiträume, Reaktionsgeschwindigkeit, Transparenz – das verkauft.
14) Ein Mini-Leitfaden für Führungskräfte
- Zielbild setzen: „Wir liefern versorgbare Produkte.“
- Verantwortliche benennen: Produkt-Security (PSO), PSIRT-Lead, Supplier-Security.
- Metriken definieren: MTTR, Fix-Rate, Update-Adoption, SBOM-Abdeckung.
- Stop-Authority geben: Releases dürfen bei Sicherheitsrisiken gestoppt werden.
- Budget verlagern: Weniger Projekt-Feuerwehr, mehr Pipeline & Automatisierung.
15) Checkliste „Sind wir CRA-ready?“
- Haben wir pro Produkt eine Risikobewertung und definierte Sicherheitsziele?
- Erzeugt jedes Release eine SBOM (mit Version/Hash) – automatisiert?
- Sind Builds reproduzierbar und Artefakte signiert?
- Gibt es einen Update-Backbone (Staging, Wellen, Stop/Rollback, Telemetrie)?
- Existiert ein PSIRT mit klaren SLAs, Templates und Eskalationspfaden?
- Haben wir Lieferantenklauseln (SBOM, Patch-SLA, Disclosure)?
- Können wir Konformität mit Dokumenten belegen (CE-Erklärung, technische Unterlagen)?
- Wissen Vertrieb/Marketing, was wir zu Security zusagen (und was nicht)?
- Ist EOL pro Produkt geplant und kommuniziert?
Wenn Sie 7+ Häkchen haben, sind Sie auf Kurs. Darunter? Jetzt priorisieren.
16) Kurz-Glossar
- SBOM: Stückliste Ihrer Softwarekomponenten und Abhängigkeiten.
- VEX: Hinweis, ob eine Schwachstelle in Ihrem Kontext ausnutzbar ist.
- PSIRT: Team zur Behandlung von Produkt-Sicherheitsvorfällen.
- CVD: Coordinated Vulnerability Disclosure – geregelter Umgang mit Meldungen.
- Post-Market-Surveillance: Systematisches Beobachten des Produkts nach dem Launch.
- Konformitätsbewertung: Verfahren, das zur CE-Kennzeichnung führt.
17) Fazit: Weniger Glamour, mehr Substanz – und genau das macht Sie schneller
Der CRA ist kein Kreativitätskiller, sondern ein Katalysator für reife Entwicklung: Er zwingt dazu, die „unsichtbare“ Basis zu bauen, auf der Innovation steht, statt ständig umzufallen. Wer jetzt SBOM, Updates, PSIRT, Lieferketten-Kontrollen und schlanke Nachweise aufsetzt, gewinnt doppelt: rechtssicherer Marktzugang und robustere Produkte, die Kunden lieben, weil sie im Ernstfall gut versorgt werden.
Der schnellste Weg ist nicht die Abkürzung, sondern das gerade Rückgrat. Bauen Sie es – die Features laufen dann von selbst.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Blog-Beitrag abonnieren
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Über den Autor
Kommentare 42
Ich würde gern einen Punkt vertiefen: wie sich die Anforderung in einen belastbaren Arbeitsablauf übersetzen lässt. Wie lässt sich das mit überschaubarem Aufwand überprüfen?
Ein kleiner Pilot erscheint mir sinnvoll. Wichtig wäre nur, vorher festzulegen, welches Ergebnis als Verbesserung gilt und wer es beurteilt.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Das wirft eine praktische Frage auf. Wie würdest du die im Beitrag angesprochenen Anforderungen in überschaubare erste Schritte übersetzen?
Ich würde mit klaren Verantwortlichkeiten und einem begrenzten Anwendungsfall beginnen. So lässt sich prüfen, ob die Vorgehensweise im Alltag tatsächlich hilft.
Wo hilft Automatisierung, und wo verschiebt sie nur unklare Verantwortlichkeiten in einen Workflow? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Daran würde ich anknüpfen. Ich würde zuerst den Entscheidungsweg klären. Ein automatisierter unklarer Ablauf wird dadurch nicht automatisch zu einem besseren Ablauf. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Meine Ausgangsfrage bleibt: Wo hilft Automatisierung, und wo verschiebt sie nur unklare Verantwortlichkeiten in einen Workflow?
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren. Für mich steht dabei die Umsetzbarkeit im Vordergrund.
Das wäre für mich ein sinnvoller Einstieg. Wichtig wäre dann, den ersten Fall auch wirklich auszuwerten und nicht nur abzuschließen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wo würdet ihr bei Nachweis sicherheitsrelevanter Produktentscheidungen anfangen, wenn ein kleines Team mehrere Rollen gleichzeitig übernimmt?
Ich würde zunächst die Rollen dennoch getrennt dokumentieren und für die kritische Entscheidung einen zweiten Blick vorsehen. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Nachweis sicherheitsrelevanter Produktentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Wie plant man den Umgang mit Schwachstellen über die Veröffentlichung hinaus?
Daran würde ich anknüpfen. Für mich gehören Bearbeitung, Kommunikation und die Bereitstellung von Verbesserungen zusammen. Ein sicherer Ausgangszustand ersetzt keine Planung für spätere Probleme.
Dazu eine Rückfrage: Was bringt eine Komponentenliste, wenn sie nach dem ersten Release nicht mehr gepflegt wird?
Dann wäre sie für laufende Entscheidungen nur eingeschränkt hilfreich. Ich würde Aktualisierung und tatsächliche Verwendung als eigene Aufgaben behandeln.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren? Meine Ausgangsfrage bleibt: Was bringt eine Komponentenliste, wenn sie nach dem ersten Release nicht mehr gepflegt wird?
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Auf die Ausgangsfrage bezogen: Dann wäre sie für laufende Entscheidungen nur eingeschränkt hilfreich. Ich würde Aktualisierung und tatsächliche Verwendung als eigene Aufgaben behandeln.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wie würdet ihr Verantwortung entlang des Produktlebenszyklus konkret prüfen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Für diesen Fall wäre mein Ansatz: die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Verantwortung entlang des Produktlebenszyklus sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie verhindert man, dass Sicherheit erst kurz vor der Produktfreigabe zum Thema wird?
Daran würde ich anknüpfen. Ich würde Sicherheitsanforderungen in die Entwicklung und in die Änderungsentscheidungen aufnehmen. Eine späte Prüfung kann grundlegende Produktentscheidungen kaum noch wirtschaftlich korrigieren.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Wie werden zugekaufte Komponenten in die eigene Sicherheitsplanung eingebunden? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Für mich liegt der Schwerpunkt hier: Ich würde Informationen und Zuständigkeiten entlang der Lieferkette prüfen. Eine externe Herkunft nimmt dem eigenen Produktteam die Integrationsaufgabe nicht ab.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen? Meine Ausgangsfrage bleibt: Wie werden zugekaufte Komponenten in die eigene Sicherheitsplanung eingebunden?
Wie verhindert ihr bei Verantwortung entlang des Produktlebenszyklus, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Verantwortung entlang des Produktlebenszyklus würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Ein weiterer Punkt: Wie verhindert man, dass eine Übung nur den gut vorbereiteten Idealfall testet? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Für mich liegt der Schwerpunkt hier: Ich würde auch fehlende Informationen und nicht erreichbare Beteiligte einbeziehen. Gerade dann zeigt sich, ob die vorgesehenen Abläufe belastbar sind. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Mir wäre die laufende Pflege wichtiger als die perfekte erste Fassung. Wie könnte man das mit überschaubarem Aufwand organisieren?
Das würde ich an einem konkreten Szenario prüfen. Eine Beschreibung zeigt die Absicht; die gemeinsame Durchführung zeigt, wo Informationen oder Übergaben fehlen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Danke für die Präzisierung. Für mich wäre die Wirkung im Betrieb die interessantere Rückmeldung als die reine Vollständigkeit der Unterlagen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Dazu eine Rückfrage: Wer entscheidet, wenn ein Sicherheitsproblem mit Liefertermin oder Produktumfang kollidiert? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Das ist ein wichtiger Punkt. Das würde ich vor dem Konflikt klären. Die Entwicklung sollte mit einer solchen Abwägung nicht ohne klare Entscheidungswege allein bleiben.
Das klingt nachvollziehbar, aber der Aufwand ist damit noch nicht geklärt. Welchen Teil würdest du zuerst angehen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Mich überzeugt besonders der Bezug zu nachvollziehbare Produktsicherheit über den Lebenszyklus. Ein konkreter Anwendungsfall könnte zeigen, wo der Ansatz noch zu abstrakt bleibt.