Der Cyber Resilience Act verändert, wie Hardware- und Softwareprodukte geplant, entwickelt, dokumentiert und über ihren gesamten Lebenszyklus betrieben werden. Hersteller müssen nicht nur ein sicheres Produkt in Verkehr bringen. Sie müssen Schwachstellen während des Supportzeitraums behandeln, Sicherheitsupdates organisieren, technische Nachweise aktuell halten und ab dem 11. September 2026 meldefähig sein.
Der entscheidende Punkt: Der CRA ist kein einzelnes CE-Arbeitspaket am Ende der Entwicklung. Er macht Product Security zu einer nachweisbaren Unternehmensfähigkeit.
Die Verordnung (EU) 2024/2847 ist seit Dezember 2024 in Kraft. Die Meldepflichten gelten ab dem 11. September 2026, die wesentlichen übrigen Anforderungen ab dem 11. Dezember 2027. Die Europäische Kommission hat am 27. Juli 2026 zusätzliche praktische Leitlinien veröffentlicht. Sie konkretisieren unter anderem den Anwendungsbereich, wesentliche Änderungen, Supportzeiträume, Risikobewertungen und Meldepflichten.
Für Unternehmen ist damit klar: Wer digitale Produkte in der EU bereitstellt, muss die Umsetzung jetzt in Produktmanagement, Entwicklung, Security, Qualitätsmanagement, Einkauf und Service verankern.
CRA-Readiness ist erreicht, wenn jederzeit nachvollziehbar ist: Welches Produkt? Welches Risiko? Welche Kontrolle? Welche Evidenz? Welche Verantwortung?
Was der CRA in der Praxis verändert
Der CRA gilt grundsätzlich für Hardware- und Softwareprodukte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Verbindung zu einem Gerät oder Netzwerk umfasst. Er erfasst nicht nur Endprodukte, sondern auch separat vermarktete Komponenten und notwendige Remote-Datenverarbeitungsfunktionen.
Damit reicht der Anwendungsbereich von Maschinensteuerungen, Gateways, IoT-Geräten und Embedded Software über Betriebssysteme und Anwendungen bis zu Security-Produkten und digitalen Komponenten. Bestimmte Produktgruppen sind ausgenommen, wenn bereits sektorspezifische EU-Regelungen vergleichbare Cybersicherheitsanforderungen vorgeben. Die Abgrenzung muss deshalb produktspezifisch erfolgen.
Die Herstellerpflichten beginnen vor dem Marktzugang und enden nicht mit der Auslieferung:
- Vor dem Inverkehrbringen müssen Scope, Risikobewertung, Security-Anforderungen, technische Dokumentation und Konformitätsweg belastbar sein.
- Beim Inverkehrbringen müssen Nutzerinformationen, Supportzeitraum, EU-Konformitätserklärung und CE-Kennzeichnung stimmen.
- Nach dem Inverkehrbringen müssen Schwachstellen, Updates, Advisories, Vorfälle, Produktänderungen und die Installed Base gesteuert werden.
Der CRA unterscheidet außerdem zwischen der Standardkategorie, wichtigen Produkten und kritischen Produkten. Für die Standardkategorie ist grundsätzlich eine interne Konformitätsbewertung möglich. Für wichtige Produkte der Klasse I gelten abhängig von den angewendeten technischen Spezifikationen strengere Bedingungen. Wichtige Produkte der Klasse II und kritische Produkte benötigen grundsätzlich eine unabhängige Bewertung oder ein anwendbares europäisches Cybersicherheitszertifizierungsschema.
Die Klassifizierung ist daher keine Formalität. Sie beeinflusst Projektplan, Evidenzumfang, Prüfstrategie, Budget und Markteinführung.
Rollen zuerst klären
Ein häufiger Fehler ist, sofort mit einer Anforderungsliste zu beginnen. Zuerst muss geklärt werden, welche wirtschaftliche Rolle das eigene Unternehmen für jedes Produkt tatsächlich einnimmt.
Hersteller
Hersteller ist, wer ein Produkt entwickelt oder herstellen lässt und es unter eigenem Namen oder eigener Marke vermarktet. Der Hersteller trägt die zentrale Verantwortung für Risikobewertung, Security by Design, technische Dokumentation, Konformitätsbewertung, Schwachstellenmanagement, Support und Meldungen.
Importeur
Ein in der EU ansässiger Importeur, der Produkte eines Herstellers außerhalb der EU erstmals auf den EU-Markt bringt, muss vorab prüfen, ob der Hersteller die Anforderungen erfüllt. Dazu gehören insbesondere Konformitätsbewertung, technische Dokumentation, CE-Kennzeichnung und Prozesse für das Schwachstellenmanagement.
Händler beziehungsweise Distributor
Händler müssen unter anderem prüfen, ob CE-Kennzeichnung, Hersteller- und Importeurangaben, Nutzerinformationen und Supportzeitraum vorhanden sind. Bei erkennbarer Nichtkonformität darf das Produkt nicht weiter bereitgestellt werden.
Bevollmächtigter
Ein Hersteller kann einen in der EU ansässigen Bevollmächtigten mit klar definierten Aufgaben mandatieren, etwa für die Zusammenarbeit mit Marktüberwachungsbehörden. Die grundlegende Herstellerverantwortung bleibt bestehen.
Open-Source-Software-Steward
Der CRA führt eine eigene Rolle für juristische Personen ein, die bestimmte freie und quelloffene Software nachhaltig unterstützen, ohne sie selbst als Hersteller auf dem Markt bereitzustellen. Für diese Stewards gelten angepasste Pflichten, insbesondere zu sicherer Entwicklung, Schwachstellenbehandlung, Behördenkooperation und Meldungen.
Integrator oder Modifizierer
Ein Integrator kann selbst zum Hersteller werden, wenn er ein Produkt unter eigenem Namen bereitstellt oder wesentlich verändert. Das ist insbesondere bei Maschinenumbauten, Retrofits, White-Label-Produkten und tiefen Softwareanpassungen relevant. Jede wesentliche Änderung muss deshalb als Product- und Compliance-Entscheidung behandelt werden.
Klare Arbeitsteilung: Der Hersteller entwickelt, IT Kombinat steuert den CRA-Prozess
Externe Unterstützung kann den CRA-Prozess erheblich beschleunigen. Sie verlagert jedoch nicht die Herstellerverantwortung.
Beim Kunden verbleiben insbesondere:
- Produkt- und Architekturentscheidungen
- Entwicklung und Implementierung der Produktfunktionen
- Entwicklung, Test und Freigabe von Patches und Produktupdates
- technische Freigabe von Releases
- Akzeptanz von Restrisiken
- Konformitätsentscheidung, EU-Konformitätserklärung und CE-Kennzeichnung
IT Kombinat kann parallel die methodische, technische und organisatorische Steuerung übernehmen:
- CRA-Programm, Rollen, Termine und Entscheidungswege aufsetzen
- Risk Assessments und Threat Modeling methodisch durchführen und dokumentieren
- Security-Anforderungen, Architektur und Teststrategie überprüfen
- Findings, Maßnahmen, Lieferantennachweise und Fristen nachhalten
- Technical File, Evidenzregister, Release Gates und Audit-Readiness strukturieren
- PSIRT-, Melde-, SBOM/VEX- und Lifecycle-Prozesse etablieren oder operativ führen
- Managementberichte, KPI, CAPA und regelmäßige Reviews erstellen
Auf Wunsch kann IT Kombinat auch die externe Kommunikation mit zuständigen Behörden und CSIRTs operativ vorbereiten und durchführen. Voraussetzung sind eine klare Beauftragung, abgestimmte Freigabewege und die Freigabe der Inhalte durch Hersteller, Legal beziehungsweise die zuständigen Entscheider. Die rechtliche Verantwortung verbleibt beim Hersteller.
Diese Arbeitsteilung hält die Entwicklung handlungsfähig: Der Kunde konzentriert sich auf Produktentwicklung und Patching. IT Kombinat führt den CRA-Prozess, dokumentiert Entscheidungen und sorgt dafür, dass offene Punkte nicht verloren gehen.
Ein praxistaugliches Vorgehen: PLAN – BUILD – SECURE – OPERATE
Eine belastbare CRA-Umsetzung verbindet regulatorische Anforderungen mit dem tatsächlichen Produktlebenszyklus. Das IT Kombinat strukturiert dieses Vorgehen in vier Phasen.
PLAN: Scope, Rollen, Governance und Zielbild festlegen
In der PLAN-Phase werden die Grundlagen geschaffen. Ohne einen belastbaren Scope entstehen später Lücken in Risikobewertung, SBOM, Technical File und Support.
Zentrale Arbeitsschritte sind:
- Produkt- und Variantenregister aufbauen
- Hardware, Software, Firmware, Komponenten und Remote Services erfassen
- Systemgrenzen, Intended Use und vorhersehbare Fehlanwendung definieren
- Rolle des Unternehmens und der Lieferanten bestimmen
- Produktkategorie und Konformitätsweg vorläufig festlegen
- Supportzeitraum und End-of-Support-Modell entwerfen
- Verantwortlichkeiten zwischen Management, Product, Entwicklung, Security, QM/CE, Einkauf und Service definieren
- CRA-Fit-Gap, Evidenzmodell, Meilensteine und Entscheidungsregister aufsetzen
IT Kombinat kann diese Phase als Initial Assessment oder als Aufbau eines vollständigen CRA-Programms übernehmen. Der Kunde liefert Produktwissen, benennt Entscheider und gibt Scope, Rollen und Zielbild frei.
BUILD: Risk Assessment, Threat Modeling und Security Engineering verbinden
Risk Assessments und Threat Modeling sind keine ergänzenden Compliance-Dokumente. Sie sind das fachliche Steuerungssystem der CRA-Umsetzung.
Dazu gehören:
- Schutzgüter, Bedrohungen, Angriffspfade und Auswirkungen analysieren
- Security-, Safety- und Verfügbarkeitsrisiken gemeinsam betrachten
- Intended Use, vorhersehbare Fehlanwendung und Betriebsumgebung einbeziehen
- prüfbare Security-Anforderungen aus den Risiken ableiten
- Zonen, Kommunikationspfade, Administrationswege und Vertrauensgrenzen gestalten
- IAM, Rollenmodelle, MFA, PKI, Kryptografie und Secret Management festlegen
- Logging, Monitoring, Update, Recovery und sichere Außerbetriebnahme konzipieren
- Secure Coding, Code Reviews, SCA, Security Tests und Release-Kriterien in den Entwicklungsprozess integrieren
- Lieferantenanforderungen, Supportzusagen und technische Nachweise steuern
IT Kombinat unterstützt hier mit Risk Assessments, Threat Modeling, Security Architecture, IEC-62443-Mapping, Architekturreviews, Anforderungsmanagement und Testkonzepten. Die Entwicklung und Umsetzung im Produkt sowie die Erstellung der Patches bleiben beim Hersteller beziehungsweise dessen Entwicklungspartnern.
Gerade im industriellen Umfeld müssen IT, OT und Safety zusammen gedacht werden. Eine rein organisatorische CRA-Matrix reicht nicht, wenn Netzwerkpfade, Fernwartung, Legacy-Komponenten oder Updateverfahren technisch ungeklärt bleiben.
SECURE: Schwachstellen beherrschen, Wirksamkeit prüfen und Evidenz erzeugen
Die SECURE-Phase verbindet technische Prüfung, Schwachstellenmanagement und Nachweisführung.
Eine SBOM ist dabei wichtig, aber sie ist nur das Inventar. Der wirksame Prozess beginnt danach:
- Produkt und Release eindeutig identifizieren
- Komponenten und Abhängigkeiten über eine SBOM erfassen
- bekannte Schwachstellen mit dem Produkt korrelieren
- Ausnutzbarkeit mit VEX oder einer gleichwertigen Bewertung dokumentieren
- Risiko und Handlungsbedarf entscheiden
- Patch, Mitigation, Advisory oder Release-Blocker umsetzen
- Entscheidung und Wirksamkeit als Evidenz sichern
Dabei ist die Begriffsabgrenzung wichtig: CVE bezeichnet eine öffentlich bekannte Schwachstelle. CVD steht für Coordinated Vulnerability Disclosure und beschreibt den geregelten Prozess zur Entgegennahme, Bearbeitung und koordinierten Offenlegung. VEX dokumentiert, ob und warum eine Schwachstelle ein konkretes Produkt tatsächlich betrifft oder nicht ausnutzbar ist.
IT Kombinat kann den Prozess für SBOM-Annahme, Vulnerability Triage, VEX, Findings, Advisories, technische Nachweise und Release Gates führen. Der Hersteller stellt die technischen Produktinformationen bereit, bewertet Findings gemeinsam mit seinen Fachverantwortlichen und entwickelt die erforderlichen Patches oder Mitigations.
Parallel entsteht das Technical File. Es muss unter anderem Produktbeschreibung, Systemgrenzen, Risikobewertung, Architektur, Security Controls, Entwicklungs- und Testnachweise, Schwachstellenprozesse, Komponenteninformationen, Nutzerinformationen und Konformitätsweg nachvollziehbar zusammenführen.
Ein belastbares Release Gate verhindert, dass ein Produkt trotz offener kritischer Findings, fehlender Evidenz oder ungeklärter Restrisiken freigegeben wird.
OPERATE: Meldefähigkeit, Nachhaltung und Lifecycle sicherstellen
Der CRA verlangt Product Security auch nach der Markteinführung. Dafür braucht es funktionierende Betriebsprozesse und aktuelle Produktdaten.
Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden. Vorgesehen sind eine Frühwarnung innerhalb von 24 Stunden und eine vollständige Meldung innerhalb von 72 Stunden. Für aktiv ausgenutzte Schwachstellen folgt ein Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme; für schwerwiegende Vorfälle innerhalb eines Monats nach der vollständigen Meldung.
Ein PDF-Prozess reicht dafür nicht. Meldefähigkeit setzt voraus, dass folgende Informationen und Entscheidungswege unter Zeitdruck funktionieren:
- Zeitpunkt und Quelle der Kenntniserlangung
- betroffene Produkte, Versionen und Installed Base
- technische Triage und Bewertung der aktiven Ausnutzung
- zuständige PSIRT-, Engineering-, Product-, Legal- und Managementrollen
- Sofortmaßnahmen, Kundenkommunikation und Advisory
- Zugang zur CRA Single Reporting Platform
- Evidenzsicherung und dokumentierte Freigaben
IT Kombinat kann diesen Prozess als Managed CRA Process Office operativ begleiten: Eingang und Triage koordinieren, Fristen überwachen, Informationen konsolidieren, Freigaben nachhalten, Meldungen vorbereiten, Evidenz sichern und Management sowie Kundenkommunikation unterstützen. Auf Wunsch und bei entsprechender Bevollmächtigung kann auch die externe Behördenkommunikation übernommen werden.
Der Hersteller bleibt technischer Owner. Er liefert die produktspezifische Bewertung, entwickelt Patches, entscheidet über Releases und gibt Meldungen sowie externe Aussagen frei.
Zum OPERATE-Modell gehören außerdem Lieferantenmonitoring, Support- und End-of-Support-Kommunikation, Änderungsbewertungen, interne Audits, CAPA, KPI und regelmäßige Managementreviews. Tabletop Exercises prüfen, ob Rollen, Daten und Entscheidungen innerhalb der gesetzlichen Fristen tatsächlich funktionieren.
Beispiele für unterstützende Werkzeuge und technische Bausteine
CRA-Readiness hängt nicht von einem bestimmten Tool oder Produkt ab. Werkzeuge und Security-Bausteine können die Umsetzung jedoch beschleunigen, wenn ihre Rolle sauber abgegrenzt und ihre Wirksamkeit nachgewiesen wird.
Beispiel 1: CRANE für Governance und Evidenz
Wir haben uns unter anderem CRANE – die CRA Norm Engine angesehen. CRANE ist eine selbst gehostete Open-Source-Plattform, die Product Registry, SBOM-Analyse, Vulnerability Management, VEX, Risikobewertungen, Release Gates, Annex-I-Matrix, technische Dokumentation und Audit Trail zusammenführt. Das Projekt befindet sich in aktiver Entwicklung und empfiehlt für den produktiven Einsatz weiterhin technische Aufsicht.
CRANE ist damit ein Beispiel für Tooling, das Produkte, Releases, Risiken, Findings und Nachweise strukturiert verknüpfen kann. Es ersetzt weder die fachliche Bewertung noch die Herstellerentscheidung.
Beispiel 2: edge.PSL von TRIOVEGA als technischer Security-Baustein
Im Maschinenbau haben wir uns außerdem edge.PSL von TRIOVEGA angesehen. TRIOVEGA positioniert edge.PSL als Protective Security Layer, der als untrennbarer Softwarebestandteil in Maschinen integriert werden kann und unter anderem Zugriffsschutz, Segmentierung, Logging sowie SBOM-, Vulnerability- und Patch-Prozesse unterstützen soll.
Ein solcher Baustein kann den Security-Lifecycle technisch entlasten. Er ersetzt jedoch nicht die Bewertung des Gesamtprodukts. Der konkrete Beitrag muss für jede Maschine und Produktvariante durch Architektur, Konfiguration, Integrationstests, Update- und Recovery-Verfahren sowie belastbare Lieferantennachweise verifiziert werden.
CRANE und edge.PSL sind damit Beispiele für zwei unterschiedliche Ebenen: Governance und Evidenz auf der einen, technische Produktkontrollen auf der anderen. Je nach Produkt, Architektur und bestehender Tool-Landschaft können andere Lösungen geeigneter sein.
Das CRA-Service-Modell des IT Kombinats
IT Kombinat verbindet Governance, Security Engineering und operativen Lifecycle-Betrieb. Die Leistungen können modular, als gemeinsames Projektteam oder als Managed CRA Process Office erbracht werden.
PLAN
- Initialer CRA-Workshop
- Product Scope, Rollen- und Klassifizierungsbewertung
- CRA-Fit-Gap und priorisierte Roadmap
- Governance, RACI, Entscheidungs- und Evidenzmodell
- Support- und Lieferantenmodell
BUILD
- Cybersecurity Risk Assessments
- Threat Modeling und Angriffspfadanalyse
- Security Architecture und Architekturreviews
- Ableitung prüfbarer Security-Anforderungen
- IEC-62443-Mapping und OT-/IT-Security-Konzeption
- Secure-Development- und Security-Testkonzept
SECURE
- SBOM-/VEX- und Vulnerability-Management-Prozess
- Findings-, Maßnahmen- und Fristensteuerung
- Security-Test- und Nachweiskoordination
- Technical File und Evidenzregister
- Release Gates, Pre-Audit und Remediation-Steuerung
OPERATE
- PSIRT- und 24-/72-Stunden-Meldeprozess
- Lifecycle-, Support- und Installed-Base-Steuerung
- Lieferantenmonitoring, Advisories und Change Impact
- Audits, KPI, CAPA und Managementberichte
- Behördenkommunikation auf Wunsch und nach Freigabe
Der Kunde bleibt Hersteller und technischer Owner. Er entwickelt das Produkt, implementiert Security-Anforderungen, erstellt Patches und trifft die abschließenden Produkt-, Risiko- und Konformitätsentscheidungen. IT Kombinat kann den dazugehörigen Prozess führen, dokumentieren und kontinuierlich nachhalten.
IT Kombinat erbringt technische und organisatorische Unterstützung. Rechtliche Einzelfallbewertungen, die Tätigkeit einer notifizierten Stelle, die EU-Konformitätserklärung und die abschließende Herstellerentscheidung werden dadurch nicht ersetzt.
Initialer CRA-Workshop: Der strukturierte Einstieg
Der sinnvollste Start ist kein großflächiges Transformationsprogramm, sondern ein fokussierter Workshop mit den relevanten Product-, Engineering-, Security-, QM/CE-, Service- und Managementrollen.
Im initialen CRA-Workshop klären wir gemeinsam:
- welche Produkte, Varianten und Remote Services betroffen sind
- welche CRA-Rollen und vorläufigen Produktkategorien vorliegen
- wo die größten Risiken und Nachweislücken bestehen
- welche Risk Assessments, Threat Models und technischen Reviews benötigt werden
- wie die Arbeit zwischen Hersteller und IT Kombinat aufgeteilt wird
- ob einzelne Arbeitspakete oder ein Managed CRA Process Office sinnvoll sind
- welche Entscheidungen, Daten und Maßnahmen als Nächstes erforderlich sind
Das Ergebnis ist ein abgestimmtes Zielbild mit Scope, Verantwortlichkeiten, priorisierten Arbeitspaketen und einem belastbaren nächsten Schritt.
Fazit
Der Cyber Resilience Act verschiebt Cybersicherheit von einer optionalen Produkteigenschaft zu einer verbindlichen Herstellerpflicht. Die zentrale Herausforderung ist nicht das Lesen der Verordnung. Sie liegt im Aufbau eines durchgängigen Product-Security-Lifecycles, der Risiken, Architektur, Entwicklung, Lieferkette, Nachweise und Betrieb zusammenführt.
Risk Assessments, Threat Modeling und Security Engineering bilden dabei den fachlichen Kern. Prozessführung, Dokumentation und Nachhaltung sorgen dafür, dass die technischen Entscheidungen auditierbar bleiben und über den Lifecycle nicht verloren gehen.
CRA-Readiness entsteht nicht durch ein einzelnes Tool, eine SBOM oder einen technischen Security-Baustein. Sie entsteht durch das Zusammenspiel von Governance, Engineering, Evidenz und operativer Verantwortung.
Die fünf Kontrollfragen bleiben einfach:
- Welches Produkt ist betroffen?
- Welches Risiko wurde bewertet?
- Welche Kontrolle wurde umgesetzt?
- Welche Evidenz belegt die Wirksamkeit?
- Wer trägt die Verantwortung für die Entscheidung?
IT Kombinat unterstützt Hersteller vom initialen Workshop über Risk Assessment, Threat Modeling und Security Architecture bis zur operativen Führung von Dokumentation, Findings, Meldeprozessen und Lifecycle-Nachweisen.
Weiterführende Quellen
- EU-Kommission: Cyber Resilience Act – Überblick
- EU-Kommission: Praktische CRA-Leitlinien vom 27. Juli 2026
- EU-Kommission: Pflichten der Hersteller
- EU-Kommission: CRA-Meldepflichten
- EU-Kommission: Konformitätsbewertung
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products
- CRANE – CRA Norm Engine
- TRIOVEGA edge.PSL
