Mit der Verordnung (EU) 2024/2847 macht die Europäische Union Cybersicherheit zu einer verbindlichen Produkteigenschaft. Hersteller müssen künftig nicht nur sichere Produkte entwickeln. Sie müssen über den gesamten Produktlebenszyklus hinweg nachweisen können, dass Cyberrisiken systematisch bewertet, Schwachstellen bearbeitet und Sicherheitsupdates bereitgestellt werden.

Für das C-Level ist der Cyber Resilience Act, kurz CRA, deshalb kein Spezialthema der IT-Sicherheit. Er betrifft Marktzugang, Produktstrategie, Investitionsentscheidungen, Lieferketten, Margen, Haftungsrisiken und Reputation.

Die zentrale Managementfrage lautet nicht mehr nur: Ist unser Produkt technisch sicher?

Sie lautet: Können wir die Sicherheit des Produkts belastbar nachweisen, während seiner gesamten Nutzungsdauer aufrechterhalten und im Krisenfall innerhalb weniger Stunden handlungsfähig sein?

Der CRA reguliert nicht primär Unternehmen, sondern ihre Produkte

Der Cyber Resilience Act schafft erstmals einen horizontalen europäischen Rechtsrahmen für die Cybersicherheit von sogenannten Produkten mit digitalen Elementen. Darunter fallen grundsätzlich Hardware- und Softwareprodukte, deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Verbindung zu einem Gerät oder Netzwerk umfasst.

Der Anwendungsbereich ist entsprechend weit. Er kann beispielsweise Betriebssysteme, Anwendungen, Router, IoT-Geräte, industrielle Steuerungskomponenten, vernetzte Maschinen, Firmware, Security-Produkte und eingebettete Software erfassen.

Entscheidend ist, dass der CRA als Produktregulierung verstanden wird. Während Regelwerke wie NIS2 vor allem das Cyberrisikomanagement von Organisationen adressieren, setzt der CRA unmittelbar am Produkt und an dessen Bereitstellung auf dem europäischen Markt an.

Betroffen sind nicht nur klassische Produkthersteller. Auch Importeure und Händler müssen bestimmte Prüf- und Sorgfaltspflichten erfüllen. Unternehmen können zudem selbst zum Hersteller im regulatorischen Sinne werden, wenn sie ein Produkt unter eigenem Namen oder eigener Marke vertreiben oder ein bereits bereitgestelltes Produkt wesentlich verändern.

Gerade für OEM-Modelle, White-Label-Produkte, Systemintegratoren und Anbieter komplexer digitaler Lösungen ist diese Abgrenzung von erheblicher Bedeutung. Die vertragliche Rollenbezeichnung allein entscheidet nicht darüber, wer regulatorisch verantwortlich ist. Maßgeblich ist, wer das Produkt in welcher Form auf dem Markt bereitstellt und wer wesentliche Entscheidungen über Produktfunktion, Architektur und Veränderung trifft.

Auch Hersteller mit Sitz außerhalb der Europäischen Union sind betroffen, sobald sie ihre Produkte auf dem europäischen Markt anbieten.

Nicht jede digitale Dienstleistung fällt automatisch unter den CRA. Reine Cloud- oder SaaS-Leistungen sind differenziert zu beurteilen. Ist eine Remote-Datenverarbeitungslösung jedoch integraler Bestandteil eines Produkts und für dessen Funktion erforderlich, kann sie in die CRA-Betrachtung einzubeziehen sein. Für bestimmte sektorspezifisch regulierte Produkte, etwa in Teilen der Medizinprodukte-, Fahrzeug- oder Luftfahrtregulierung, gelten Ausnahmen oder besondere Abgrenzungen.

Cybersicherheit wird zur Voraussetzung für Konformität und Marktzugang

Der grundlegende Paradigmenwechsel des CRA besteht darin, dass Cybersicherheit nicht mehr nur als Qualitätsmerkmal oder freiwillige Best Practice behandelt wird. Sie wird zu einer rechtlich überprüfbaren Voraussetzung dafür, ein Produkt auf dem europäischen Markt bereitzustellen.

Hersteller müssen vor dem Inverkehrbringen bewerten, ob ihr Produkt die wesentlichen Cybersicherheitsanforderungen erfüllt. Dazu gehören eine dokumentierte Risikobewertung, technische Nachweise, Informationen über den Umgang mit Schwachstellen, die EU-Konformitätserklärung und die CE-Kennzeichnung.

Die CE-Kennzeichnung ist dabei nicht als Sicherheitssiegel oder Garantie für Unangreifbarkeit zu verstehen. Sie dokumentiert vielmehr, dass der Hersteller die anwendbaren europäischen Anforderungen bewertet hat und die Konformität seines Produkts erklärt.

Für viele Standardprodukte wird grundsätzlich eine interne Konformitätsbewertung möglich sein. Für als wichtig oder kritisch eingestufte Produktkategorien gelten jedoch strengere Verfahren. Je nach Produktklasse, eingesetzten harmonisierten Normen und gewähltem Konformitätsweg kann eine unabhängige Prüfung durch eine notifizierte Stelle erforderlich werden.

Damit erhält Produktsicherheit eine unmittelbare wirtschaftliche Dimension. Kann ein Unternehmen die Konformität nicht nachweisen, geht es nicht lediglich um einen negativen Auditbericht. Im Extremfall kann das Produkt nicht mehr rechtskonform angeboten werden.

Security by Design wird von der Empfehlung zur Verpflichtung

Der CRA verlangt, dass Cybersicherheit von Beginn an in Konzeption, Entwicklung und Herstellung eines Produkts integriert wird. Eine nachträgliche Sicherheitsprüfung kurz vor dem Marktstart reicht nicht aus.

Produkte sollen grundsätzlich ohne bekannte ausnutzbare Schwachstellen bereitgestellt werden. Sie müssen unter anderem sichere Standardeinstellungen unterstützen, ihre Angriffsfläche begrenzen und einen angemessenen Schutz von Vertraulichkeit, Integrität und Verfügbarkeit gewährleisten. Ebenso relevant sind Zugriffskontrollen, Authentisierung, Datenminimierung, Protokollierungsfunktionen, Schutz vor Manipulation sowie sichere Update- und Wiederherstellungsmechanismen.

Für die Produktentwicklung bedeutet das eine tiefgreifende Veränderung. Security-Anforderungen müssen in Produktanforderungen, Architekturentscheidungen, Entwicklungsprozesse, Testverfahren und Freigabekriterien integriert werden. Threat Modeling, sichere Softwareentwicklung, Code- und Komponentenanalyse sowie Security-Tests werden damit zu Bestandteilen der regulären Produktentwicklung und nicht zu nachgelagerten Sondermaßnahmen.

Besonders wichtig ist die Dokumentation der zugrunde liegenden Cybersecurity-Risikobewertung. Hersteller müssen nicht nur technische Schwachstellen betrachten, sondern auch den vorgesehenen Einsatzzweck, die erwartbare Nutzungsumgebung, Abhängigkeiten, mögliche Fehlanwendungen und relevante Bedrohungsszenarien.

Diese Risikobewertung ist kein einmaliges Dokument. Sie muss über den Produktlebenszyklus hinweg fortgeführt und bei relevanten Veränderungen aktualisiert werden.

Der CRA endet nicht mit dem Produktrelease

Eine der größten Fehlannahmen besteht darin, den CRA als Zulassungsprojekt für neue Produkte zu betrachten. Tatsächlich beginnt ein wesentlicher Teil der Verantwortung erst nach dem Markteintritt.

Hersteller müssen während des festgelegten Supportzeitraums neue Schwachstellen beobachten, ihre Relevanz für die eigenen Produkte bewerten, Korrekturen entwickeln und Sicherheitsupdates bereitstellen. Hinzu kommen Prozesse zur koordinierten Offenlegung von Schwachstellen sowie erreichbare Kommunikationskanäle für Kunden und Security Researcher.

Der Supportzeitraum muss sich an der erwartbaren Nutzungsdauer des Produkts orientieren und grundsätzlich mindestens fünf Jahre betragen. Ist die erwartbare Nutzungsdauer kürzer, kann auch der Supportzeitraum entsprechend kürzer ausfallen. Bei langlebigen Industrieprodukten, Maschinen, Steuerungskomponenten oder Infrastruktursystemen kann dagegen ein deutlich längerer Planungshorizont erforderlich sein.

Damit wird die Entscheidung über die Lebensdauer eines Produkts zu einer strategischen und finanziellen Entscheidung. Wer ein vernetztes Produkt verkauft, übernimmt nicht nur eine Lieferverpflichtung, sondern eine mehrjährige Cybersecurity-Verantwortung.

Diese Verantwortung verursacht langfristige Kosten. Dazu gehören Vulnerability Monitoring, technische Analyse, Entwicklung und Test von Sicherheitsupdates, sichere Update-Infrastrukturen, Kundenkommunikation, Incident Response, regulatorische Dokumentation und die Pflege interner Produktkompetenz.

Der CRA verändert deshalb die Produktkalkulation. Die Wirtschaftlichkeit eines digitalen Produkts kann nicht mehr ausschließlich anhand von Entwicklungs-, Produktions- und Vertriebskosten bewertet werden. Auch die erwartbaren Kosten der Sicherheitsunterstützung über den gesamten Produktlebenszyklus müssen berücksichtigt werden.

Nicht jedes bestehende Produktportfolio wird unter diesen Bedingungen wirtschaftlich tragfähig sein. Für ältere oder technisch schwer wartbare Produkte muss das Management gegebenenfalls entscheiden, ob eine Nachrüstung sinnvoll ist, ob die Architektur grundlegend modernisiert werden muss oder ob ein geordnetes End-of-Life die verantwortungsvollere Option darstellt.

Die SBOM wird zur Grundlage operativer Handlungsfähigkeit

Besondere Bedeutung erhält die Software Bill of Materials, kurz SBOM. Sie schafft Transparenz darüber, welche Softwarekomponenten und Abhängigkeiten in einem Produkt eingesetzt werden.

Der CRA verlangt eine maschinenlesbare Aufstellung der verwendeten Softwarekomponenten, mindestens auf der Ebene der direkten beziehungsweise obersten Abhängigkeiten. Die SBOM muss nicht grundsätzlich öffentlich zugänglich sein. Sie muss jedoch so aktuell, strukturiert und nutzbar sein, dass der Hersteller im Falle einer neu bekannt gewordenen Schwachstelle schnell feststellen kann, welche Produkte, Versionen und Kunden betroffen sein könnten.

Eine formal vorhandene SBOM genügt daher nicht. Entscheidend ist ihre operative Qualität.

Unternehmen müssen wissen, wie vollständig die erfassten Informationen sind, wie häufig sie aktualisiert werden, wie Komponenten eindeutig identifiziert werden und wie die SBOM mit Build-Prozessen, Produktversionen, Vulnerability-Datenbanken und Freigabeverfahren verbunden ist.

Die eigentliche Herausforderung liegt häufig nicht im Erzeugen einer Komponentenliste, sondern in der durchgängigen Beherrschung der Softwarelieferkette. Moderne Produkte bestehen aus eigener Software, kommerziellen Komponenten, Open-Source-Bibliotheken, Firmware, Betriebssystembestandteilen und Leistungen externer Entwicklungspartner. Ohne belastbare Transparenz über diese Abhängigkeiten ist ein wirksames Vulnerability Management kaum möglich.

Die Lieferkette wird Teil der eigenen Compliance

Der CRA lässt sich nicht auf die eigene Entwicklungsorganisation begrenzen. Hersteller bleiben auch dann verantwortlich, wenn Schwachstellen aus Komponenten oder Leistungen externer Lieferanten stammen.

Damit verändert sich das Lieferantenmanagement. Preis, Qualität und Lieferfähigkeit bleiben relevant, reichen aber nicht mehr aus. Unternehmen müssen beurteilen, ob Lieferanten über verlässliche Security-Prozesse verfügen, Schwachstellen rechtzeitig melden, Sicherheitsupdates bereitstellen und belastbare Informationen über eingesetzte Komponenten liefern können.

Verträge mit Technologie- und Softwarelieferanten sollten deshalb klare Anforderungen an SBOM-Daten, Vulnerability-Meldungen, Patch-Zeiten, Supportfristen, End-of-Life-Ankündigungen, Incident-Kommunikation und Mitwirkung bei regulatorischen Anfragen enthalten.

Besonders kritisch sind Komponenten, deren Supportzeitraum kürzer ist als die geplante Lebensdauer des eigenen Produkts. Ein Hersteller kann gegenüber seinen Kunden kaum einen langfristigen Security Support gewährleisten, wenn zentrale Abhängigkeiten bereits nach wenigen Jahren nicht mehr gepflegt werden.

Für Einkauf, Produktmanagement und Technik entsteht damit eine gemeinsame Aufgabe: Lieferketten müssen nicht nur wirtschaftlich stabil, sondern auch über den gesamten Produktlebenszyklus hinweg sicherheits- und updatefähig sein.

Ab September 2026 gelten sehr kurze Meldefristen

Die operative Dringlichkeit des CRA beginnt nicht erst mit der vollständigen Anwendung der wesentlichen Produktanforderungen am 11. Dezember 2027.

Bereits ab dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit eines Produkts auswirken.

In beiden Fällen ist grundsätzlich innerhalb von 24 Stunden eine Frühwarnung erforderlich. Innerhalb von 72 Stunden müssen ergänzende Informationen bereitgestellt werden. Anschließend folgt ein Abschlussbericht innerhalb der jeweils vorgesehenen Frist. Bei aktiv ausgenutzten Schwachstellen ist dieser grundsätzlich spätestens 14 Tage nach Bereitstellung einer Korrektur oder Abhilfemaßnahme einzureichen. Bei schwerwiegenden Sicherheitsvorfällen gilt grundsätzlich eine Frist von einem Monat nach der ergänzenden Meldung.

Diese Fristen sind für viele Unternehmen anspruchsvoller, als sie auf den ersten Blick erscheinen.

Innerhalb von 24 Stunden muss nicht zwingend bereits jedes technische Detail bekannt sein. Das Unternehmen muss aber erkennen, dass ein potenziell meldepflichtiger Sachverhalt vorliegt, das betroffene Produkt identifizieren, die Ausnutzung und mögliche Auswirkungen bewerten, die richtigen Entscheider einbinden und die Meldung organisatorisch auslösen.

Das lässt sich nicht durch improvisierte Abstimmungen im Krisenfall bewältigen. Erforderlich sind klare Verantwortlichkeiten, belastbare Produktinformationen, ein etabliertes Product Security Incident Response Team, definierte Eskalationswege sowie eine enge Zusammenarbeit zwischen Entwicklung, Product Security, Legal, Compliance, Kommunikation und Geschäftsleitung.

Ein klassisches IT-Security-Incident-Response-Verfahren reicht hierfür nicht automatisch aus. Ein Angriff auf die interne Unternehmens-IT und eine aktiv ausgenutzte Schwachstelle in einem weltweit vertriebenen Produkt können völlig unterschiedliche Zuständigkeiten, Informationsquellen und Entscheidungsprozesse erfordern.

Sicherheit muss nicht nur vorhanden, sondern nachweisbar sein

Der CRA erhöht die Bedeutung auditierbarer Evidenz.

Ein Unternehmen kann technisch gute Sicherheitsarbeit leisten und dennoch regulatorisch angreifbar sein, wenn Anforderungen, Risikoentscheidungen, Tests, Freigaben und Maßnahmen nicht nachvollziehbar dokumentiert sind.

In vielen Organisationen liegen relevante Informationen heute verteilt vor. Architekturentscheidungen befinden sich in Wikis, Schwachstellenbewertungen in Ticketsystemen, Testergebnisse in einzelnen Projektablagen, Risikoakzeptanzen in E-Mails und Lieferantendaten in Einkaufssystemen. Ein konsistenter Nachweis über die gesamte Produktentstehung ist häufig nur mit erheblichem Aufwand möglich.

CRA-konforme Produktgovernance verlangt eine nachvollziehbare Verbindung zwischen identifiziertem Risiko, abgeleiteter Sicherheitsanforderung, technischer Kontrolle, Testergebnis und formaler Produktfreigabe. Ebenso muss dokumentiert sein, wie Risiken nach dem Marktstart überwacht und neue Erkenntnisse verarbeitet werden.

Axians Secure hebt in seiner fachlichen Einordnung des CRA entsprechend hervor, dass eine wirksame Umsetzung nicht bei einzelnen technischen Maßnahmen beginnt, sondern bei einer strukturierten Readiness- und GAP-Analyse, klaren Verantwortlichkeiten, Security by Design, auditierbaren Prozessen und der organisatorischen Verankerung von Product Security.

Diese Perspektive ist entscheidend: Der CRA verlangt kein isoliertes Dokumentationsprojekt, sondern ein belastbares Product-Security-Betriebsmodell.

Was der CRA für den CEO und den Gesamtvorstand bedeutet

Für CEO und Gesamtvorstand ist der CRA ein Markt-, Produkt- und Reputationsrisiko.

Die Geschäftsleitung muss wissen, welcher Umsatzanteil von betroffenen Produkten abhängt, welche Produktlinien regulatorisch kritisch sind und wo fehlende Security-Fähigkeiten zu Markteintrittsverzögerungen, Rückrufen oder Vertriebsbeschränkungen führen könnten.

CRA-Risiken gehören deshalb in die reguläre Unternehmens- und Produktportfoliosteuerung. Sie sollten nicht ausschließlich über technische Schwachstellenberichte oder Compliance-Ampeln adressiert werden.

Das Management muss insbesondere Entscheidungen ermöglichen, bei denen Sicherheitsfähigkeit und Wirtschaftlichkeit in Konflikt geraten. Dazu zählen die Modernisierung älterer Produktarchitekturen, die Verlängerung von Supportzeiträumen, der Aufbau zusätzlicher Product-Security-Kapazitäten oder die Abkündigung nicht mehr vertretbar wartbarer Produkte.

Eine zentrale Governance-Frage ist, wer im Unternehmen die Gesamtverantwortung für CRA-Readiness trägt. Die operative Umsetzung ist bereichsübergreifend. Die Verantwortung darf deshalb nicht zwischen CISO, CTO, Produktmanagement und Rechtsabteilung diffundieren.

Was der CRA für CTO und Chief Product Officer bedeutet

Für CTO und Chief Product Officer wird Produktsicherheit zu einem verbindlichen Bestandteil von Architektur, Roadmap und Release-Entscheidungen.

Neue Produkte müssen so konzipiert werden, dass sie sicher aktualisiert, überwacht und über den vorgesehenen Zeitraum gewartet werden können. Das betrifft nicht nur Software, sondern auch Hardwarearchitektur, Firmware, kryptografische Verfahren, Schnittstellen, Identitäts- und Berechtigungskonzepte sowie die technische Möglichkeit, Komponenten später auszutauschen.

Produkt-Roadmaps müssen ausreichend Zeit und Budget für Risikobewertungen, Security Engineering, Tests, Dokumentation und Schwachstellenbehebung enthalten. Ein Produktrelease, das nur funktionale Anforderungen, Termine und Kosten berücksichtigt, ist unter dem CRA kein tragfähiges Steuerungsmodell mehr.

Gleichzeitig wird die technische Wartbarkeit zu einem wirtschaftlichen Produktmerkmal. Eine Architektur, die Sicherheitsupdates nur mit hohem Aufwand erlaubt, kann über den Lebenszyklus deutlich höhere Kosten verursachen als eine von Beginn an updatefähige und modular aufgebaute Lösung.

Was der CRA für CISO und Product Security bedeutet

Für den CISO reicht es nicht aus, bestehende Enterprise-Security-Prozesse auf Produktorganisationen auszudehnen. Produktsecurity erfordert eigene Kompetenzen, Informationsflüsse und Verantwortlichkeiten.

Im Mittelpunkt stehen ein funktionsfähiges Product Security Incident Response Team, ein dokumentierter Coordinated-Vulnerability-Disclosure-Prozess, kontinuierliches Monitoring relevanter Schwachstellen und eine belastbare technische Triage.

Dabei muss das Security-Team produktbezogen arbeiten können. Es muss erkennen, welche Komponente in welcher Produktversion eingesetzt wird, ob eine Schwachstelle unter den konkreten Bedingungen ausnutzbar ist, wie viele Kunden betroffen sind und welche Gegenmaßnahmen zur Verfügung stehen.

Der CISO benötigt dafür enge Schnittstellen zu Entwicklung, Produktmanagement, Support, Lieferantenmanagement und Legal. Ohne Zugriff auf aktuelle Produkt- und Komponenteninformationen bleibt Product Security reaktiv und im Ernstfall zu langsam.

Was der CRA für den CFO bedeutet

Für den CFO verändert der CRA die finanzielle Betrachtung digitaler Produkte.

Security-Support, Schwachstellenmanagement und Konformitätsnachweise sind keine einmaligen Projektkosten, sondern wiederkehrende Lebenszykluskosten. Sie müssen in Business Cases, Produktpreise, Rückstellungen, Investitionsplanung und Make-or-Buy-Entscheidungen einfließen.

Zusätzliche Kosten können durch externe Prüfungen, notifizierte Stellen, Security-Tests, SBOM- und Vulnerability-Management-Plattformen, Update-Infrastrukturen und spezialisierte Fachkräfte entstehen.

Gleichzeitig muss der CFO die finanziellen Auswirkungen unzureichender Vorbereitung bewerten. Je nach Art des Verstoßes sieht der CRA Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, wobei grundsätzlich der höhere Betrag maßgeblich sein kann.

Die möglichen wirtschaftlichen Folgen gehen jedoch über Bußgelder hinaus. Ein verspäteter Produktlaunch, ein Vertriebsstopp, eine verpflichtende Nachbesserung oder ein Rückruf kann deutlich schwerer wiegen. Hinzu kommen Vertragsrisiken, mögliche Kundenverluste und Reputationsschäden.

Was der CRA für COO, Einkauf, Legal und Compliance bedeutet

Für COO und Einkauf wird die Sicherheitsfähigkeit von Lieferanten zu einem Bestandteil operativer Resilienz. Kritische Abhängigkeiten müssen transparent sein, Supportfristen müssen zur eigenen Produktplanung passen und bei relevanten Schwachstellen müssen Informationen schnell verfügbar sein.

Legal und Compliance müssen frühzeitig in Produktklassifizierung, Rollenabgrenzung, Vertragsgestaltung und Konformitätsstrategie eingebunden werden. Ihre Aufgabe beginnt nicht erst bei der Prüfung der EU-Konformitätserklärung.

Zu klären ist unter anderem, ob das Unternehmen regulatorisch als Hersteller, Importeur oder Händler handelt, welches Konformitätsbewertungsverfahren erforderlich ist und welche Nachweise langfristig vorgehalten werden müssen. Ebenso wichtig sind klare Regeln für Behördenkommunikation, Meldeentscheidungen und die rechtssichere Beschreibung von Supportzeiträumen und Produktfunktionen.

Welche Steuerungsinformationen das C-Level benötigt

Ein reines Reporting über die Anzahl offener Schwachstellen reicht nicht aus.

Die Geschäftsleitung sollte jederzeit erkennen können, welche Produkte in den Anwendungsbereich fallen, welcher Umsatz und welche strategischen Kundenbeziehungen davon abhängen und für welche Produkte noch keine belastbare Risikobewertung oder Konformitätsstrategie vorliegt.

Ebenso relevant ist, welcher Anteil des Portfolios über eine aktuelle SBOM verfügt, ob Supportzeiträume technisch und finanziell abgesichert sind, wo kritische Lieferantenlücken bestehen und wie schnell neue Schwachstellen hinsichtlich ihrer Produktauswirkung bewertet werden können.

Besondere Aufmerksamkeit sollte der Frage gelten, ob die Organisation die 24- und 72-Stunden-Meldefristen tatsächlich erfüllen kann. Entscheidend ist nicht, ob ein Prozess dokumentiert wurde, sondern ob er unter realistischen Bedingungen funktioniert.

Das C-Level sollte außerdem wissen, welche Produkte nur durch unverhältnismäßige Investitionen CRA-fähig gemacht werden können. Diese Information ist für Portfoliobereinigung, Investitionspriorisierung und strategische Produktentscheidungen unverzichtbar.

Der CRA ist auch eine strategische Chance

Der Cyber Resilience Act erzeugt ohne Zweifel zusätzlichen Aufwand. Er kann jedoch zugleich zum Katalysator für eine professionellere Produktorganisation werden.

Viele strukturelle Schwächen, die der CRA adressiert, sind ohnehin wirtschaftlich relevant: unbekannte Softwareabhängigkeiten, fehlende Updatefähigkeit, nicht definierte Supportzeiträume, unklare Lieferantenverantwortung und schwer wartbare Legacy-Architekturen.

Unternehmen, die diese Themen konsequent bearbeiten, verbessern nicht nur ihre regulatorische Position. Sie reduzieren technische Schulden, beschleunigen die Bewertung von Sicherheitsvorfällen und schaffen mehr Transparenz über ihre Produkt- und Lieferkettenrisiken.

Gerade im B2B-Geschäft kann eine nachweisbare Product-Security-Fähigkeit zum Differenzierungsmerkmal werden. Unternehmenskunden, Betreiber kritischer Infrastrukturen und öffentliche Auftraggeber verlangen zunehmend belastbare Aussagen zu Secure Development, Schwachstellenmanagement, SBOM, Updatefähigkeit und Support.

CRA-Readiness kann damit auch Vertriebsprozesse unterstützen, Sicherheitsprüfungen bei Kunden beschleunigen und das Vertrauen in digitale Produkte stärken.

Fazit: Produktsicherheit wird zur Führungsaufgabe

Der Cyber Resilience Act verändert die Verantwortung für digitale Produkte nachhaltig. Cybersicherheit wird zu einer Voraussetzung für Konformität, CE-Kennzeichnung und europäischen Marktzugang.

Die erste operative Zäsur ist der 11. September 2026, wenn die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle greifen. Ab dem 11. Dezember 2027 sind die wesentlichen Produkt-, Prozess- und Konformitätsanforderungen vollständig anzuwenden.

Unternehmen, die den CRA als abschließende juristische Prüfung behandeln, werden voraussichtlich zu spät reagieren. Die entscheidenden Veränderungen betreffen Architektur, Entwicklung, Lieferantensteuerung, Supportmodelle, Produktkalkulation und Governance.

Für das C-Level geht es deshalb nicht um die Frage, ob Product Security finanziert werden muss. Es geht darum, wie Produktsecurity so in das Geschäftsmodell integriert wird, dass Produkte auch künftig wirtschaftlich, wartbar und rechtskonform angeboten werden können.

Die entscheidende Frage für Vorstand und Geschäftsführung lautet:

Können wir für jedes relevante Produkt nachweisen, dass wir seine Cyberrisiken verstehen, seine Sicherheit über den gesamten Lebenszyklus beherrschen und im Ernstfall innerhalb der regulatorischen Fristen handlungsfähig sind?

Wer diese Frage heute nicht belastbar beantworten kann, hat nicht nur eine Compliance-Lücke. Er hat ein potenzielles Markt- und Geschäftsrisiko.

Quellen und weiterführende Informationen

Verordnung (EU) 2024/2847 – Cyber Resilience Act

Europäische Kommission – Überblick zum Cyber Resilience Act

Europäische Kommission – Meldepflichten nach dem CRA

Axians Secure – Cyber Resilience Act: Einordnung und Umsetzung

Stand: Juli 2026. Der Beitrag dient der fachlichen Einordnung und ersetzt keine rechtliche Bewertung des konkreten Produktportfolios.

Der Beitrag Cyber Resilience Act: Wenn Produktsicherheit über Marktzugang und Marge entscheidet erschien zuerst auf Business Resilience Podcast.