Cyber Resilience Act: Was jetzt auf Hersteller zukommt – 7 harte Pflichten, 3 Chancen, 1 Deadline

Cyber Resilience Act: Was jetzt auf Hersteller zukommt – 7 harte Pflichten, 3 Chancen, 1 Deadline

Es gibt Regulierungstexte, die man einmal liest, abnickt und dann in den Schrank stellt. Und es gibt Gesetze wie den Cyber Resilience Act (CRA): Er verändert, wie Produkte mit digitalen Funktionen in Europa entwickelt, gebaut, ausgeliefert, gepflegt und aus dem Verkehr gezogen werden. Der CRA ist kein weiteres „nice to have“ in Sachen IT-Security, sondern die neue Grundlinie, an der sich künftig jedes „Produkt mit digitalen Elementen“ messen lassen muss – vom smarten Heizkörperthermostat über Routers, Türschlösser, Kameras, Medizingeräte-Software bis hin zu industriellen Steuerungen, Entwicklungswerkzeugen, Passwortmanagern oder Betriebssystemen.

Der CRA ist seit Ende 2024 im EU-Amtsblatt veröffentlicht und in Kraft; die Pflichten greifen gestaffelt: Die Melde- und Vulnerability-Management-Pflichten gelten 21 Monate nach Inkrafttreten, die übrigen Pflichten nach 36 Monaten – also spätestens Ende 2027 muss das Regelwerk in der Breite erfüllt sein. Wer ab dann Produkte in der EU „in Verkehr bringt“ (Hersteller), importiert (Importeure) oder weiterverkauft (Händler), bewegt sich nur noch innerhalb dieses neuen Spielraums. Das gilt auch für Unternehmen außerhalb der EU, die ihre Soft- oder Hardware hier vermarkten: Sie benötigen einen in der EU ansässigen Bevollmächtigten und unterliegen denselben Regeln.

Warum das wichtig ist? Weil der CRA etwas tut, was Sicherheitsprofis seit Jahren fordern: Sicherheit wird vom Projektziel zum Produkterfordernis. So wie elektrische Sicherheit oder EMV-Verträglichkeit schon lange Teil der CE-Kennzeichnung sind, wird auch die Cyber-Sicherheit künftig konformitätsrelevant. Und das bedeutet: ohne Security keine CE-Kennzeichnung, ohne CE keine Marktteilnahme.

Worum es im Kern geht

Der CRA spricht von „Produkten mit digitalen Elementen“. Das umfasst physische Geräte (Hardware) und Software (auch als standalone Software – also ohne eigenes Gerät), sofern sie als Produkt auf den Markt gebracht werden. Reine Dienstleistungen – etwa klassische SaaS-Angebote – stehen grundsätzlich nicht im Fokus des CRA, fallen aber ggf. unter andere EU-Rahmen (z. B. NIS2 oder das künftige EUCS-Cloud-Zertifikat). Bei Produkten, die für ihre Funktionen auf Cloud-Dienste angewiesen sind, ist der Hersteller trotzdem in der Pflicht: Er muss sicherstellen, dass das gesamte Produktverhalten – inkl. Kommunikationsschnittstellen – die CRA-Anforderungen erfüllt.

Der CRA unterscheidet zudem kritische Klassen: Für bestimmte Produktarten – z. B. Identitäts-/Zugangs-Management, Passwortmanager, Firewalls, VPN-Lösungen, SIEM/IDS, Betriebssysteme, Hypervisoren, Netzwerk-Switches, Router, Industriesteuerungen u. a. – verschärfen sich die Anforderungen. Ein wesentlicher Unterschied: Für nicht-kritische Produkte genügt häufig eine interne Konformitätsbewertung (Selbstbewertung auf Basis harmonisierter Normen). Kritische Produkte benötigen dagegen in vielen Fällen eine Dritt-Konformitätsbewertung (Notified Body), sofern nicht vollständig nach harmonisierten Normen entwickelt wurde. Das sorgt dafür, dass dort, wo am meisten Schaden entstehen kann, genauer hingeschaut wird.

Die Offen-Software-Welt ist in der finalen Fassung geschützt: Open-Source-Software, die ohne Gewinnerzielungsabsicht entwickelt und bereitgestellt wird, fällt nicht unter den CRA. Wer OSS jedoch kommerziell bündelt, integriert oder inklusive Support als Produkt vertreibt, wird zum Hersteller im Sinne des CRA – und trägt dann die Pflichten.

Die 7 harten Pflichten – was Hersteller jetzt sauber aufsetzen müssen

Im Marketing lässt sich vieles schönreden, beim CRA zählen Prozesse, Nachweise und gelebte Praxis. Die folgenden sieben Punkte sind die „Schrauben“, an denen Aufsicht, Marktüberwachung und Kunden in Zukunft drehen werden. Wer hier sauber arbeitet, besteht Audits, gewinnt Ausschreibungen – und hat deutlich weniger Feuerwehreinsätze im Feld.

1) „Security by Design & by Default“ – vom ersten Commit bis zur letzten Schraube

Entwicklung wird vom Sicherheitsende her gedacht. Der CRA verlangt einen systematischen Secure-Development-Lifecycle (SDL): Threat Modeling, sichere Architekturentscheidungen, Härtung von Schnittstellen, abgesicherte Update-Mechanismen, Schutz der gespeicherten und übertragenen Daten, robuste Authentifizierung, Logging, Monitoring, Schutz vor Manipulation (z. B. Secure Boot, Anti-Rollback), Fail-Safe-Design u. v. m.

Die Anforderungen sind in zwei Annexen gebündelt: „Essential Cybersecurity Requirements“ (Was muss das Produkt im Betrieb können, um sicher zu sein?) und „Vulnerability-Handling-Requirements“ (Wie gehen Hersteller mit Schwachstellen um?). Harmonisierte Normen (CEN/CENELEC/ETSI) werden diese Grundsätze in prüfbare technische Spezifikationen übersetzen – wer normkonform umsetzt, kann sich für die CE-Erklärung auf die „Vermutungswirkung“ stützen.

2) Sichere Lieferketten und Komponenten – SBOM nicht nur als PDF

Moderne Produkte bestehen aus hunderten bis tausenden Komponenten: eigene Module, Drittanbieter-Libraries, Open-Source-Bausteine, Firmware-Blobs. Der CRA verlangt, dass Hersteller eine Stückliste digitaler Komponenten (SBOM) führen, Risiken dieser Bauteile bewerten und Updates/Patches zeitnah einspielen. Das „Einmal bauen, nie wieder anfassen“ endet.

Eine gute SBOM ist maschinell auswertbar, pflegt Metadaten (Version, Quelle, Lizenz, bekannte CVEs, Fix-Versionen), ist über den gesamten Produktlebenszyklus aktuell und – wo sinnvoll – für Kunden zugänglich. In Ausschreibungen wird die SBOM zum Standardanhang werden.

3) Vulnerability-Handling & CVD – die organisierte Schwachstelle

Sicherheitslücken gehören zum Leben. Entscheidend ist, wie man damit umgeht. Der CRA fordert ein CVD-Programm (Coordinated Vulnerability Disclosure): klare Kontaktwege, ein definiertes Intake-Verfahren, Priorisierung, Risikobewertung, Reproduzierbarkeit, SLAs zur Behebung, Kommunikation an Kunden, CVE-Prozesse – und Telemetrie, um die Wirksamkeit zu prüfen.

Wichtig: Aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle müssen gemeldet werden. Die Timeline ist eng: Erstmeldung binnen 24 Stunden, technischer Bericht binnen 72 Stunden, Abschlussbericht innerhalb von 14 Tagen nach Abhilfe. Diese Meldepflicht – an ENISA und nationale CSIRTs – gilt früher als der Rest: 21 Monate nach Inkrafttreten. Wer heute noch kein Incident-Team und keine Meldekette hat, startet spät. cumulocity.com+1

4) Updates, Patches, Supportdauer – Sicherheit ist ein Versprechen

Hersteller müssen über den erwarteten Produktlebenszyklus Sicherheit erhalten. Der CRA verlangt Sicherheitsupdates „für die voraussichtliche Nutzungsdauer“ oder einen fixen Minimalzeitraum (verkürzt formuliert: typischerweise bis zu fünf Jahren, sofern die erwartete Lebensdauer nicht kürzer ist). Updates müssen sicher verteilt, integriert und – wo möglich – nutzerfreundlich („secure by default“) eingespielt werden; sie dürfen keine neue Angriffsfläche schaffen.

Transparenz ist Pflicht: Welche Versionen sind unterstützt? Wie werden Kunden benachrichtigt? Was passiert, wenn ein Gerät EOL ist? Ohne diese Antworten kein sauberer Marktauftritt – und künftig kein CE.

5) Dokumentation, technische Unterlagen & CE-Erklärung – was nicht belegt ist, existiert nicht

Die Konformität ist kein Bauchgefühl, sondern ein Dokumentensatz: Risikobeurteilung, Sicherheitszielen, Designentscheidungen, implementierte Kontrollen, Ergebnisse von Tests (statisch, dynamisch, Pen-Tests), SBOM, CVD-Prozess, Update-Konzept, Nutzerinformationen (z. B. sichere Grundeinstellungen), Betriebs-/Wartungsanleitungen, Verarbeitungsverzeichnis relevanter Datenflüsse, u. v. m.

Darauf bauen Konformitätsbewertung und CE-Kennzeichnung auf. Je nach Produktklasse: interne Kontrolle oder Prüfstelle. Fehlt die Doku, fehlt die CE – und damit der Marktzugang.

6) Haftung & Marktüberwachung – Security wird zur ökonomischen Größe

Mit dem CRA wird mangelnde IT-Sicherheit rechtlich fassbar. Marktüberwachungsbehörden können Produkte zurückrufen, Verkäufe untersagen, Bußgelder verhängen. Hersteller müssen Sicherheitsmängel unverzüglich adressieren, Kunden informieren und ggf. Korrekturmaßnahmen (Fix, Rückruf, Tausch) durchführen.

Wirtschaftlich heißt das: Wer Security-Risiko nicht in sein Produkt-P&L einpreist, erlebt ein böses Erwachen. Gleichzeitig bietet der CRA Planungssicherheit: Security wird kalkulierbar, Budgets lassen sich über Lebenszyklus-Kosten rechtfertigen.

7) Rollen und Pflichten entlang der Lieferkette – nicht nur der Hersteller ist dran

Der CRA kennt Ökonomenrollen: Hersteller, Bevollmächtigte, Importeure, Händler. Importeur und Händler müssen u. a. prüfen, ob die CE-Kennzeichnung vorhanden ist, ob das Produkt Anweisungen/Sicherheitsinformationen in der Landessprache enthält und ob erkennbar nicht konforme Ware nicht weiterverkauft wird. Wer als Integrator Software bündelt und unter eigenem Namen vertreibt, wird zum Hersteller – inklusive Pflichten.

Drei echte Chancen – warum der CRA mehr ist als Bürokratie

Viele lesen den CRA als „noch eine Compliance-Welle“. Man kann es auch anders sehen: Er ist ein Wettbewerbsvorteil in Gesetzesform. Drei Gründe:

1. Vertrauen wird messbar
   Bisher war „sichere Software“ ein Marketing-Versprechen. Künftig gibt es harte Nachweise: Prozesse, Normenkonformität, CE-Erklärung, SBOM, Update-Historie, Offenlegung von Schwachstellen mit Reaktionszeiten. Das schafft Vergleichbarkeit – und damit Vertrauen. Wer sauber arbeitet, kann es zeigen.
2. Weniger Firefighting, mehr Produktivität
   Ein gelebter SDL, ein funktionierendes CVD-Programm, eine gepflegte SBOM und automatisierte Update-Pipelines reduzieren Support-Kosten, verkürzen Time-to-Fix, verringern Folgeschäden. Security wird Planungsbaustein, nicht Störfaktor.
3. Besserer Zugang zu regulierten Märkten
   Wer CRA-konform ist, steht in Ausschreibungen vorn – besonders in kritischen Infrastrukturen, im öffentlichen Sektor oder in Branchen, die NIS2-Pflichten managen müssen. Der CRA wird zur Eintrittskarte für wertige Marktsegmente.

Eine Deadline – und was das praktisch bedeutet

Der CRA ist seit Ende 2024 in Kraft. Es gibt Übergangsfristen:

• Melde- und Vulnerability-Handling-Pflichten gelten 21 Monate nach Inkrafttreten (also 2026).
• Alle übrigen Pflichten – und damit die CE-Konformität nach CRA – greifen 36 Monate nach Inkrafttreten (spätestens Ende 2027). finitestate.io+1

Das wirkt weit weg – ist es aber nicht. Wer heute ein Produkt mit Entwicklungszeit von 12–24 Monaten startet, muss jetzt die Weichen stellen: Architektur, Toolchain, Security-Funktionen, Lieferketten-Governance, Meldeprozesse, Vertragsgestaltung mit Zulieferern, Konformitätsstrategie.

Was sich „unter der Haube“ ändert – tiefere Einblicke für Produkt- und Technikverantwortliche

Secure Development Lifecycle (SDL) als Rückgrat

Die typischen Bausteine eines CRA-fähigen SDL:

• Governance & Policies: Security-Ziele, Rollen, Verantwortlichkeiten, Training.
• Requirements: Sicherheitsanforderungen aus Risikobeurteilung und Standards ableiten (z. B. IEC 62443, ISO/IEC 27034, ETSI EN 303 645).
• Threat Modeling & Architecture Risk Analysis: STRIDE/LINDDUN, Angriffsgraphen, Missuse-Cases, Sicherheitszonen und -kanäle, Zero-Trust-Prinzipien.
• Secure Coding & Reviews: Coding-Standards, SAST/DAST/IAST, Code-Reviews/Pairing, Memory-Safety-Sprachen dort, wo sinnvoll.
• Dependency Hygiene: SBOM-Generierung, Vulnerability-Scans (SCA), Lizenz-Compliance, Upstream-Monitoring.
• Build & Release: Trusted Builds, Reproducible Builds, Signierung (Code/Firmware), Supply-Chain-Absicherung (SLSA, in-toto).
• Testing: Unit/Integration, Fuzzing, Pen-Tests, Red-Team-Übungen, Security-Regression-Suiten.
• Field Security: Secure Boot, Anti-Rollback, Hardening, sichere Defaults, Logging, Telemetrie, Remote-Wipe, Key-Rotation, Secrets-Handling.
• Ops & Updates: Update-Server absichern, Staged Roll-outs, Rollback-Mechanismen, Customer Notice, CVE-Publikation.
• Vulnerability Response: CVD-Prozess, SLAs, Notfall-Playbooks, 24/72/14-Meldekaskade, Beweissicherung.
• EoL/EoS: Planbares Ende, Migrationsempfehlungen, Kommunikationsstrategie.

Das ist kein „Papier-SDLC“; es lebt in Tickets, Pipelines, Repos und Dashboards. Der CRA belohnt Automatisierung – und er bestraft Excel-Orchester.

SBOM als Organisations-Artefakt

Viele Hersteller beginnen mit einem SBOM-Export aus dem Build: CycloneDX oder SPDX. Das ist ein guter Start, aber nicht genug. Entscheidend ist der Prozess: Komponenten schon bei der Auswahl prüfen, Policies für Zulässigkeit (z. B. Lizenztypen, Mindestreife), Abnahmen dokumentieren, Automatik für CVE-Monitoring, Rückverfolgbarkeit bis zum Gerät.

Wer es richtig macht, koppelt SBOM und Asset-Intelligence: Welcher Kunde betreibt welche Version mit welchen Komponenten? Welche CVE trifft welche Flotte? So werden Fixes gezielt verteilt und Meldungen valide.

CVD & Incident-Meldekette – kein PR-Text, sondern Betrieb

Die 24/72/14-Meldezeitleiste zwingt zu klaren Abläufen:

• Erstmeldung (24 h): Was ist bekannt? Welche Produkte/Versionen sind betroffen? Erste Maßnahmen/Workarounds.
• Technischer Bericht (72 h): Ursache, Exploitability, CVSS-Einschätzung, geplante Patches, erwarteter Zeitplan.
• Finaler Status (spätestens 14 Tage nach Abhilfe): Was wurde gefixt, wie verteilt, welche Residualrisiken?

Das gelingt nur mit vorbereiteten Playbooks, Rechte-/Rollen-Modellen, Reaktions-Teams (Engineering, Legal, Support, Comms) und Übungen. Der CRA verlangt keine Perfektion – er verlangt Professionalität.

Was bedeutet das für verschiedene Hersteller-Profile?

Start-ups & Scale-ups

Oft ist das Produktteam klein, die Entwicklung schnell, die Security „später“. Das wird schwierig. Der Gewinn: Viele moderne Toolchains (Cloud-CI, IaC, moderne Sprachen) bieten Security-Automatisierung out of the box. Wer früh Security-Stories in die Backlogs nimmt und Build-in-Security im Pitch verankert, überzeugt Kunden – und spart teure Nachrüstungen.

Mittelstand & „Embedded Champions“

Hier sind Lebenszyklen lang, Lieferketten tief, Feldgeräte laufen zehn Jahre und mehr. Ohne Langzeit-Update-Strategie, Key-Management und Lifecycle-Funding wird das teuer. Gelingt der Umbau, kann man mit robusten Service-Verträgen (Security-Maintenance) kalkulierbare Erlöse schaffen.

Global Player & Plattformanbieter

Sie müssen Konformität weltweit harmonisieren: CRA, UK PSTI, US Cyber Trust Mark, SBOM-Pflichten (US-Federal), chinesische CY-Standards. Vorteil: Wer CRA-Level als globalen Standard setzt, spart Fragmentierung und erhöht die Baseline insgesamt.

Vermeintliche Stolperfallen – und wie man sie entschärft

„Wir benutzen nur OSS – also sind wir raus.“
Falsch. Sobald Sie OSS als Produkt bündeln, vertreiben oder mit Support anbieten, sind Sie Hersteller. Gute Nachricht: Die OSS-Community liefert oft Security-Reife mit (CVE-Prozesse, Fix-Zyklen). Schlechte Nachricht: Sie tragen die Verantwortung, das sauber zu integrieren.

„Unsere Geräte sind offline – Security ist nicht relevant.“
Auch Offline-Produkte sind angreifbar (physischer Zugriff, Seiteneffekte, Supply-Chain). Außerdem verlangen Kunden Nachweise – und die CE basiert auf den Essential Requirements, unabhängig vom Online-Status.

„SBOM leaken wir nicht, das ist ein Sicherheitsrisiko.“
SBOMs sind Sicherheitswerkzeuge. Sie müssen nicht jede interne Details öffentlich machen. Aber ohne strukturierte Komponentenverwaltung ist ein Patch-Management in der Breite unmöglich. Und: Kunden fordern SBOMs zunehmend in Verträgen.

„Dritt-Prüfstelle? Dafür haben wir keine Zeit.“
Für kritische Produkte kann sie Pflicht sein – oder die einzige realistische Verteidigung, wenn Marktzugang auf dem Spiel steht. Eine frühe Vorab-Konsultation mit dem künftigen Notified Body spart Monate.

Verzahnung mit anderen EU-Rahmen

Der CRA ist Teil eines Regulierungsmosaiks:

• NIS2 regelt Security-Pflichten für betroffene Unternehmen/Branchen (Betreiber). Der CRA adressiert Produkte.
• AI Act (für KI-Systeme) und Machinery Regulation (für Maschinen) können parallel gelten.
• Data Act/DSA betreffen Datenzugang und Plattformverantwortung.
• Produkt-spezifische Regeln (z. B. Medizinprodukte, Kfz-Cybersecurity UN ECE R155/R156) haben Vorrang, wenn gleichwertige Anforderungen bestehen.

Hersteller brauchen eine Regulatory Map: Welcher Produkt-/Markt-Mix, welche Pflichten, welche Konformitätswege? Synergien nutzen (z. B. gemeinsame Risikoanalyse, wiederverwendbare Controls).

Verträge, Einkauf, Vertrieb – der oft vergessene Hebel

Technik löst vieles – aber Vertragsgestaltung entscheidet oft über Risiken:

• Zulieferer-Verträge: SBOM-Pflicht, Patch-SLAs, Security-Garantien, Auditrechte, Benachrichtigungspflichten bei Vulnerabilities.
• Kunden-Verträge: Update-Versprechen, Support-Zeiträume, Informationskanäle, Verantwortlichkeiten bei gemanagten Installationen.
• Import/Handel: CE-Prüfung, Sprachunterlagen, Rückverfolgbarkeit, Reklamationsprozesse.

Der CRA verlangt Rückverfolgbarkeit. Ohne saubere Vertrags- und Beschaffungsprozesse bleibt Security ein technischer Wunsch.

Praktische Roadmap-Ideen (ohne die x-te „Projektliste“)

Statt langer Bullet-Roadmaps hier drei Bilder, die sich in vielen Organisationen bewährt haben:

Bild 1 – Das „doppelte Betriebssystem“ der Organisation
Neben dem Produkt-Betriebssystem (Entwicklung, Release, Vertrieb) läuft ein Security-Betriebssystem: Policies, SDL-Artefakte, SBOM-Pipeline, Incident-Playbooks, Meldekette. Beide Systeme sind gekoppelt über Metriken, Gate-Kriterien und gemeinsame Dashboards. Jeder Release durchläuft Security-Gates; jede Sicherheitsmeldung triggert produktive Reaktionen.

Bild 2 – Der „digitale Zwilling“ des Produkts
Für jedes Produkt existiert ein digitaler Zwilling der Sicherheitslage: Versionen, Komponenten, bekannte CVEs, offene Findings, Kompatibilitäten, Kundenflotten, Update-Status, End-of-Support-Daten. Dieser Zwilling steht Vertrieb, Support und Compliance zur Verfügung – nicht nur der Entwicklung. So werden Sicherheits- und Geschäftsentscheidungen verknüpft.

Bild 3 – Die „Kette der Reaktionsfähigkeit“
Vom Hinweis (Forscher, Kunde, CERT) über Intake, Bewertung, Fix-Planung, Build, Test, Rollout, Kommunikation bis zur Meldung an ENISA/CSIRT: jede Schnittstelle ist klar. Keine E-Mail-Lotterie, keine Excel-Ablagen. Stattdessen: Tickets, Runbooks, Zeitstempel, Owner. Das nimmt das Drama aus dem Vorfall.

Was kostet das – und was bringt es?

Die Kosten entstehen v. a. durch: Prozessaufbau, Tooling (SBOM, Scans, Signierung, Update-Infrastruktur), Drittprüfungen, Ressourcen für CVD/Incident Response und langfristigen Support.

Die Erlöse kommen subtil, aber nachhaltig: höhere Abschlusschancen in RFPs; geringere Feldkosten; weniger Krisen; bessere Bewertungen bei Versicherern; stärkeres Markenvertrauen. In Summe entsteht ein stabileres Produktgeschäft. Und wer früh startet, hat First-Mover-Vorteile bei Normen, Best Practices, Auditerfahrung.

Was passiert, wenn man nichts tut?

Kurzfristig: oft wenig. Mittelbar: verpasste Deals, Marktüberwachung setzt den Rotstift an, Rückrufe werden teuer, Bußgelder schmerzen, und die Reputationskurve knickt ab. Vor allem aber: Die technische Schuld wächst schneller als die Marge. Der CRA gibt den Takt vor – der Markt folgt.

Fazit: Der CRA ist ein Sicherheits-Reset – und eine Einladung

Der Cyber Resilience Act zwingt Hersteller, Sicherheit als Produkteigenschaft zu denken – nicht als Add-on, nicht als Projekt „nach Version 1.0“, sondern als Qualitätsmerkmal von Anfang an. Er ist streng, aber fair: Wer zeigen kann, dass er Risiken beherrscht, Prozesse etabliert, offen kommuniziert und seine Kunden nicht im Regen stehen lässt, erhält das wichtigste Gütesiegel überhaupt: Vertrauen.

Die Formel lässt sich so schreiben:

7 Pflichten konsequent umsetzen → 3 Chancen realisieren → 1 Deadline einhalten.

Bis Ende 2027 wird sich entscheiden, wer in Europa digitale Produkte mit oder ohne Zukunft baut. Der CRA ist kein Papiermonster. Er ist die Betriebsanleitung für verlässliche digitale Produkte. Wer sie liest – und anwendet –, baut nicht nur sicherer, sondern auch besseres Geschäft.