D

er 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

1. Security by Design & by Default: Sicherheit ist nicht ein Feature, sondern Grundannahme. Voreinstellungen müssen sicher sein.
2. Risikomanagement: Sie müssen Risiken identifizieren, bewerten, mitigieren – und das kontinuierlich.
3. Schwachstellenmanagement: Sie brauchen einen Schwachstellen-Prozess (inkl. Annahme externer Hinweise), Priorisierung, Behebung, Advisories.
4. Updates über den Lebenszyklus: Sicherheitsupdates müssen zeitnah und ohne Zusatzkosten (innerhalb des zugesagten Supportzeitraums) bereitstehen – signiert, rückrollbar, gestaffelt.
5. SBOM (Software Bill of Materials): Sie wissen, was Sie ausliefern (Abhängigkeiten, Versionen), um auf CVEs reagieren zu können.
6. Lieferkette: Sie steuern Ihre Third Parties: Anforderungen an SBOM, Patch-SLAs, Security-Mitteilungen gehören in die Verträge.
7. Konformitätsbewertung & CE: Vor dem Inverkehrbringen: Bewertung, technische Dokumentation, Konformitätserklärung, CE-Kennzeichnung.
8. Post-Market-Surveillance: Nach dem Launch beobachten, Daten sammeln, reagieren (PSIRT, Telemetrie, Feedback-Kanäle).
9. Meldepflichten: Bestimmte Vorfälle/Sicherheitslücken müssen frühzeitig gemeldet werden (an zuständige Stellen und oft an Kunden).
10. 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

1. Security-Kontakt veröffentlichen (/.well-known/security.txt) mit CVD-Hinweisen.
2. SBOM-Generierung in einem Hauptprodukt automatisieren.
3. Signatur der Build-Artefakte einführen (Code-Signing).
4. Update-Staging-Plan skizzieren (Wellen, Stop-Kriterien, Rollback-Pfad).
5. Mini-PSIRT-Team benennen, Triage-SLA definieren, Advisory-Template anlegen.
6. 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.