Welche Anforderungen stellt der Cyber Resilience Act an Hersteller? Die Antwort entscheidet künftig darüber, ob Produkte mit digitalen Elementen auf dem EU-Markt bereitgestellt werden dürfen. Erfahren Sie, welche 21 Anforderungen gelten, welche Fristen Sie beachten müssen und wie Sie die Umsetzung vorbereiten.
Der Cyber Resilience Act (CRA) führt erstmals einheitliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen in der EU ein. Hersteller müssen nachweisen, dass ihre Produkte über den gesamten Lebenszyklus ein angemessenes Sicherheitsniveau erfüllen.
Neben Hardwareherstellern fallen auch Anbieter von Software und Firmware in den Anwendungsbereich. Erste Pflichten gelten bereits, weitere werden bis Ende 2027 verbindlich. Die konkreten Anforderungen stehen vor allem in Anhang I der Verordnung.
Der Gesetzgeber unterscheidet dabei zwei Bereiche:
Der CRA definiert Produkte mit digitalen Elementen als Software- oder Hardwareprodukte einschließlich ihrer Lösungen zur Datenfernverarbeitung, die direkt oder indirekt mit einem anderen Gerät oder einem Netzwerk verbunden werden können. Auch separat in Verkehr gebrachte Komponenten können darunter fallen.
Typische Beispiele sind:
Ein häufiger Grenzfall sind Cloud-Dienste. Reine SaaS-Angebote fallen nicht automatisch unter den CRA. Benötigt ein Produkt jedoch Datenfernverarbeitung, um seine Funktionen bereitzustellen, kann auch dieser Bestandteil erfasst sein.
Ausdrücklich ausgenommen sind unter anderem Medizinprodukte und Kraftfahrzeuge. Das gilt auch für Produkte der zivilen Luftfahrt sowie bestimmte Schiffsausrüstungen. Für sie gelten eigene sektorspezifische Vorschriften.
Die zentralen Anforderungen verteilen sich auf mehrere Abschnitte des CRA:
Betrachten Sie diese Vorschriften gemeinsam. Die Pflichten greifen ineinander und bilden die Grundlage der Konformitätsbewertung.
Ob Unternehmen bereits handeln müssen, hängt auch von der Rechtsform ab. Der Cyber Resilience Act ist eine EU-Verordnung und gilt unmittelbar in allen Mitgliedstaaten. Sie müssen daher nicht auf ein deutsches Umsetzungsgesetz warten.
Anders verhält es sich bei NIS2. Als Richtlinie musste sie zunächst in nationales Recht umgesetzt werden, bevor Unternehmen die konkreten nationalen Vorgaben erfüllen müssen.
Der Anwendungsbereich reicht weiter, als viele erwarten. Pflichten können auch Softwareanbieter und Markeninhaber treffen. Einführer und Händler unterliegen ebenfalls bestimmten Vorgaben.
Prüfen Sie deshalb frühzeitig, welche Rolle Ihr Unternehmen in der Lieferkette einnimmt. Davon hängt ab, welche Pflichten Sie erfüllen müssen.
Hersteller tragen die umfassendsten Pflichten. Sie müssen die anwendbaren Anforderungen aus Anhang I erfüllen und Risikobewertungen durchführen.
Außerdem stellen sie Sicherheitsupdates bereit und managen Schwachstellen. Hinzu kommt die erforderliche technische Dokumentation.
Als Hersteller gilt auch, wer ein Produkt unter eigenem Namen oder eigener Marke auf den Markt bringt. Viele Unternehmen unterschätzen diesen Punkt und ordnen sich fälschlicherweise nur als Händler ein.
Einführer und Händler unterliegen ebenfalls Pflichten nach dem CRA, ihr Verantwortungsbereich ist jedoch deutlich enger als der von Herstellern. Sie müssen unter anderem prüfen, ob Produkte die erforderlichen Kennzeichnungen tragen und die vorgeschriebenen Informationen sowie Dokumentationen enthalten. Die Anforderungen aus Anhang I richten sich dagegen grundsätzlich an den Hersteller. Deshalb müssen Händler beispielsweise keine Software Bill of Materials (SBOM) erstellen, also keine Übersicht der Softwarekomponenten eines Produkts.
Der Gesetzgeber führt die Anforderungen schrittweise mit unterschiedlichen Übergangsfristen ein. Einzelne Vorgaben sind bereits anwendbar.
Für Hersteller sind vor allem zwei Termine relevant. Seit September 2026 gelten die Meldepflichten. Die übrigen Vorgaben werden im Dezember 2027 umfassend anwendbar.
Seit dem 11. September 2026 müssen Hersteller die Meldepflichten aus Artikel 14 erfüllen. Dazu gehört vor allem, aktiv ausgenutzte Schwachstellen fristgerecht zu melden.
Dafür benötigen Sie einen operativen Prozess mit klaren Zuständigkeiten und dokumentierten Abläufen. Haben Sie diesen Prozess noch nicht eingerichtet, sollten Sie das Thema jetzt priorisieren.
Ab dem 11. Dezember 2027 gelten die übrigen Anforderungen umfassend. Hersteller müssen dann unter anderem:
Die Umsetzung fällt häufig in laufende Produktentwicklungs- und Releasezyklen. Wer die Anforderungen früh einplant, reduziert den Anpassungsaufwand vor der Markteinführung.
Viele Produkte, die Ende 2027 oder 2028 auf den Markt kommen, sind heute bereits in Planung oder Entwicklung.
Berücksichtigen Sie den CRA deshalb frühzeitig. Sicherheitsanforderungen beeinflussen bereits die Designphase. Wer sie jetzt einplant, kann kostspielige Nacharbeiten vermeiden.
Anhang I Teil I bildet das Fundament des CRA. Die Anforderungen betreffen den gesamten Lebenszyklus eines Produkts, von der Entwicklung bis zum Betrieb beim Kunden.
Der CRA verlangt dabei eine risikobasierte Betrachtung. Umfang und Tiefe der Maßnahmen richten sich nach den Risiken, die von einem Produkt ausgehen.
| Anforderung | Praktische Bedeutung | Erwarteter Nachweis |
| Keine bekannten ausnutzbaren Schwachstellen bei Markteinführung | Bekannte Sicherheitslücken vor Veröffentlichung beheben | Schwachstellenberichte und Testergebnisse |
| Sichere Standardkonfiguration | Produkt ist ohne zusätzliche Einstellungen sicher nutzbar | Dokumentierte Baseline-Konfiguration |
| Begrenzung der Angriffsfläche | Unnötige Dienste und Schnittstellen deaktivieren | Sicherheitsarchitektur |
| Schutz vor Exploits | Sicherheitsmechanismen gegen bekannte Angriffstechniken einsetzen | Designdokumentation und Tests |
| Vertraulichkeit von Daten | Daten im Ruhezustand und bei Übertragung schützen | Verschlüsselungskonzept |
| Integrität von Daten und Konfigurationen | Manipulationen erkennen und verhindern | Integritätsprüfungen und Monitoring |
| Datenminimierung | Nur erforderliche Daten erfassen und verarbeiten | Datenflussanalyse |
| Sichere Löschung und Übertragbarkeit | Daten kontrolliert löschen und exportieren können | Betriebsdokumentation |
| Schutz vor unbefugtem Zugriff | Authentifizierung und Zugriffssteuerung integrieren | IAM-Konzept |
| Protokollierung relevanter Ereignisse | Sicherheitsrelevante Aktivitäten nachvollziehbar machen | Protokollierungskonzept |
| Verfügbarkeit wesentlicher Funktionen | Produkt bleibt trotz Vorfällen nutzbar | Resilienz- und Wiederherstellungspläne |
| Vermeidung negativer Auswirkungen auf andere Systeme | Auswirkungen auf andere Geräte und Netze begrenzen | Architektur- und Integrationstests |
| Sicherheitsupdates bereitstellen | Sicherheitslücken während des Supportzeitraums beheben | Update-Prozess und Release-Nachweise |
Der CRA verlangt Security by Design, also Sicherheit von Beginn der Produktentwicklung an. Planen Sie Sicherheitsmaßnahmen deshalb von Anfang an ein, statt sie nachträglich zu ergänzen.
Besondere Aufmerksamkeit gilt der Standardkonfiguration. Ein Produkt muss bei Auslieferung bereits ein angemessenes Sicherheitsniveau bieten. Nutzer sollen dafür keine komplizierten Anpassungen vornehmen müssen.
Begrenzen Sie außerdem die Angriffsfläche. Offene Schnittstellen und nicht benötigte Funktionen schaffen potenzielle Einfallstore.
Der CRA verlangt Maßnahmen zum Schutz der Vertraulichkeit und Integrität von Daten. Verschlüsseln Sie insbesondere sensible Informationen bei der Speicherung und Übertragung.
Beschränken Sie Daten zudem auf das notwendige Maß. Prüfen Sie, welche Daten Ihr Produkt für den vorgesehenen Zweck tatsächlich benötigt.
Viele dieser Anforderungen überschneiden sich mit datenschutzrechtlichen Vorgaben. Weitere Informationen finden Sie im DataGuard-Leitfaden zur DSGVO.
Schützen Sie Produkte vor unbefugtem Zugriff. Der CRA nennt ausdrücklich Authentifizierungsmechanismen sowie Identitäts- und Zugriffsmanagement.
Zudem müssen Hersteller relevante Sicherheitsereignisse protokollieren. So erkennen Sie Vorfälle und können Angriffe nachvollziehen.
Ein häufig übersehener Punkt: Nutzer müssen bestimmte Protokollierungsfunktionen ablehnen können. Planen Sie dieses Opt-out bereits in der Entwicklung ein.
Produkte sollen ihre wesentlichen Funktionen auch unter schwierigen Bedingungen aufrechterhalten. Der CRA fordert deshalb Maßnahmen zur Resilienz gegenüber Störungen und Angriffen.
Dazu zählen etwa Schutzmechanismen gegen Denial-of-Service-Angriffe und Verfahren, um wichtige Funktionen wiederherzustellen.
Auch Sicherheitsupdates spielen eine zentrale Rolle. Wo technisch sinnvoll, stellen Sie Updates automatisch bereit und aktivieren sie standardmäßig. Nutzer müssen Updates jedoch aufschieben oder ablehnen können.
Die 13 Anforderungen gelten nicht pauschal in identischer Form für jedes Produkt. Eine Risikobewertung legt fest, welche Anforderungen in welchem Umfang greifen.
Die Risikobewertung erlaubt jedoch nicht, Sicherheitsmaßnahmen ohne Begründung auszuschließen. Sie bestimmt den Umfang der Umsetzung.
Dokumentieren Sie Ihre Risikobewertung und nehmen Sie sie in die technische Dokumentation nach Anhang VII auf.
Ihre Pflichten enden nicht mit der Markteinführung. Hersteller müssen ihre Produkte während des gesamten Supportzeitraums überwachen und Schwachstellen beheben.
Zudem informieren sie Nutzer über Sicherheitsrisiken und verfügbare Lösungen. Anhang I Teil II definiert dafür acht Anforderungen:
Überwachen Sie Ihre Produkte kontinuierlich auf Schwachstellen. Der CRA verlangt ausdrücklich, dass Sie sicherheitsrelevante Komponenten und Abhängigkeiten erfassen.
In der Praxis geschieht das über eine SBOM. Ohne Transparenz über eingesetzte Bibliotheken und Open-Source-Komponenten lassen sich viele Schwachstellen nur schwer erkennen.
Stellen Sie eine Schwachstelle fest, müssen Sie diese unverzüglich beheben. Veröffentlichen Sie Sicherheitsupdates nach Möglichkeit getrennt von Funktionsupdates.
So müssen Nutzer keine neuen Funktionen installieren, um eine kritische Sicherheitslücke zu schließen. Sicherheitsupdates stellen Sie kostenlos zur Verfügung.
Testen Sie Ihre Produkte regelmäßig. Automatisierte Schwachstellenscans und geeignete Sicherheitsprüfungen helfen Ihnen, Risiken frühzeitig zu erkennen.
Sobald ein Sicherheitsupdate verfügbar ist, informieren Sie Nutzer über die behobene Schwachstelle.
Typischerweise umfasst diese Information:
Unter bestimmten Voraussetzungen erlaubt der CRA, die Veröffentlichung aufzuschieben. Dadurch lässt sich verhindern, dass Angreifer die Informationen nutzen, bevor ausreichend Nutzer das Update installiert haben.
Sie benötigen einen formalen Prozess, um Schwachstellenmeldungen entgegenzunehmen und zu bearbeiten. Eine Coordinated Vulnerability Disclosure Policy, kurz CVD Policy, regelt den geordneten Umgang mit gemeldeten Schwachstellen.
Es reicht nicht, diese Policy zu veröffentlichen. Sie müssen den Prozess auch umsetzen und nachweisen können.
Stellen Sie außerdem eine klar erkennbare Kontaktmöglichkeit für Sicherheitsforschende bereit. Typische Lösungen sind:
Schützen Sie auch den Update-Prozess vor Manipulation. Setzen Sie dafür geeignete Mechanismen wie digitale Signaturen und geschützte Übertragungskanäle ein.
Auch ein technisch korrektes Update birgt Risiken, wenn Angreifer den Update-Kanal kompromittieren. Der CRA betrachtet deshalb den gesamten Prozess von der Entwicklung bis zur Auslieferung.
Die Software Bill of Materials gehört zu den meistdiskutierten Anforderungen des CRA. Gleichzeitig kursieren viele Missverständnisse über Format und Veröffentlichungspflichten.
Eine SBOM schafft Transparenz über die Bestandteile eines Produkts. So erkennen und bewerten Sie Sicherheitsrisiken schneller.
Der CRA schreibt kein konkretes Format vor. Er verlangt lediglich ein gängiges maschinenlesbares Format.
In der Praxis kommen häufig SPDX und CycloneDX zum Einsatz. Beide Formate haben sich am Markt etabliert, sind jedoch keine ausdrücklich vorgeschriebenen Standards.
Der CRA verlangt mindestens die Dokumentation von Top-Level-Abhängigkeiten. Das Wort „mindestens“ ist dabei relevant. Sie können Ihre SBOM detaillierter gestalten.
Kritische Schwachstellen befinden sich häufig in indirekten oder transitiven Abhängigkeiten, die einfache Übersichten nicht zeigen. Eine tiefere Erfassung kann deshalb die Bewertung neuer Schwachstellen erleichtern.
Nein. Der CRA verpflichtet Hersteller weder zur Veröffentlichung noch zur automatischen Weitergabe an Kunden oder Geschäftspartner.
Die SBOM ist in erster Linie Bestandteil der technischen Dokumentation. Marktüberwachungsbehörden können sie im Rahmen ihrer Prüfungen anfordern.
Die SBOM gehört in die technische Dokumentation nach Anhang VII. Dokumentieren Sie sie für jede ausgelieferte Produktversion und halten Sie sie aktuell.
Eine statische Datei für eine ganze Produktfamilie reicht in der Regel nicht aus. Da sich Abhängigkeiten mit jeder Version ändern können, sollten Sie die SBOM zum festen Bestandteil Ihres Release-Prozesses machen.
Der CRA versteht Cybersicherheit als dauerhafte Herstellerpflicht. Hersteller müssen Sicherheitsupdates über einen definierten Zeitraum bereitstellen.
Diese Vorgabe wirkt sich direkt auf Produktplanung und Kosten aus. Legen Sie deshalb früh fest, wie lange Sie ein Produkt unterstützen.
Grundsätzlich müssen Hersteller Sicherheitsupdates für mindestens fünf Jahre bereitstellen. Ist die erwartete Nutzungsdauer eines Produkts kürzer, kann sich der Supportzeitraum daran orientieren.
Die Europäische Kommission kann für einzelne Produktkategorien längere Mindestzeiträume festlegen. Prüfen Sie Ihre Planung deshalb regelmäßig.
Der Supportzeitraum betrifft auch Produktmanagement und Budgetplanung. Ein Produkt, das 2028 auf den Markt kommt, kann auch 2033 noch Sicherheitsupdates erfordern.
Das gilt selbst dann, wenn Sie bereits Nachfolgeprodukte vertreiben. Planen Sie Sicherheit deshalb als langfristige Verpflichtung ein.
Seit September 2026 ist die Meldung bestimmter Schwachstellen und Sicherheitsvorfälle verbindlich. Die Fristen sind knapp bemessen.
Sie müssen Schwachstellen daher schnell erkennen und intern bewerten können. Bereiten Sie außerdem die erforderlichen Informationen und Freigabewege vor.
Aktiv ausgenutzte Schwachstellen müssen Hersteller unverzüglich melden. Spätestens 24 Stunden nach Kenntnisnahme ist eine Frühwarnung fällig.
Soweit bekannt, geben Sie dabei auch die betroffenen Mitgliedstaaten an.
Für viele Unternehmen stellt diese Frist eine operative Herausforderung dar. Wer Zuständigkeiten erst nach einer Entdeckung klärt, kann die Frist kaum einhalten.
Für Kleinst- und Kleinunternehmen gilt eine Ausnahme: Versäumen sie die 24-Stunden-Frist, drohen dafür keine Bußgelder.
Innerhalb von 72 Stunden stellen Hersteller zusätzliche Informationen bereit, insbesondere:
Spätestens 14 Tage nach Bereitstellung einer Abhilfemaßnahme übermitteln Sie den Abschlussbericht.
Typische Inhalte sind:
Sie melden über die zentrale Meldeplattform nach Artikel 16. Die Informationen gehen an das zuständige nationale Computer Security Incident Response Team, kurz CSIRT, sowie an ENISA, die EU-Agentur für Cybersicherheit.
Verwechseln Sie diese Pflicht nicht mit einer NIS2-Meldung. Beide Regelwerke haben unterschiedliche Auslöser und getrennte Meldeprozesse.
Ein CRA-konformer Meldeprozess umfasst mindestens folgende Schritte:
Schon eine einzige aktiv ausgenutzte Schwachstelle kann die 24-Stunden-Frist starten. Prüfen Sie deshalb frühzeitig, ob Ihr Meldeprozess operativ funktioniert.
Hersteller müssen nachweisen können, dass sie ihre Pflichten erfüllen. Eine vollständige und aktuelle Dokumentation bildet deshalb die Grundlage jeder Konformitätsbewertung.
Die Unterlagen müssen vor dem Inverkehrbringen vorliegen. Halten Sie sie anschließend über den erforderlichen Zeitraum aktuell.
Typische Bestandteile der technischen Dokumentation sind:
Die Dokumentation sollte nachvollziehbar zeigen, wie Ihr Produkt die anwendbaren CRA-Anforderungen erfüllt.
Mit der EU-Konformitätserklärung bestätigen Sie offiziell, dass Ihr Produkt den Anforderungen des CRA entspricht.
Sie enthält unter anderem Angaben zum Hersteller und zum Produkt. Außerdem nennt sie die angewandten Rechtsvorschriften.
Unter bestimmten Voraussetzungen können Sie die vereinfachte Konformitätserklärung nach Anhang VI nutzen.
Nutzer müssen ausreichend Informationen erhalten, um ein Produkt sicher zu verwenden.
Dazu gehören beispielsweise:
Dokumentieren Sie den Supportzeitraum nicht nur intern. Informieren Sie Nutzer auch über dessen Ende.
Bewahren Sie die Dokumentation mindestens zehn Jahre nach dem Inverkehrbringen eines Produkts auf. Ist der Supportzeitraum länger, verlängert sich die Aufbewahrungspflicht entsprechend.
Je nach Risikopotenzial und Funktion eines Produkts gelten unterschiedliche Konformitätsanforderungen. Die korrekte Einstufung ist deshalb einer der ersten Schritte zur CRA-Compliance.
Die meisten Produkte sind Standardprodukte. Strengere Anforderungen gelten für Produkte, deren Kompromittierung erhebliche Auswirkungen auf andere Systeme haben kann.
| Produktklasse | Beispiele | Typischer Nachweis |
| Standardprodukte | Die meisten Software- und Hardwareprodukte | Interne Konformitätsbewertung |
| Wichtige Produkte Klasse I | Browser, Passwortmanager, VPN-Lösungen, Betriebssysteme | Erweiterte Nachweispflichten |
| Wichtige Produkte Klasse II | Firewalls, Angriffserkennungs- und Angriffsverhinderungssysteme, Hypervisoren | Höheres Prüfungsniveau |
| Kritische Produkte | Smartcards, Secure Elements, Smart-Meter-Gateways | Zusätzliche Anforderungen und mögliche Zertifizierung |
Nehmen Sie die Einstufung frühzeitig vor. Sie beeinflusst Ihre Ressourcenplanung und den Aufwand für die Konformitätsbewertung.
Der CRA enthält einzelne Erleichterungen für Kleinst- und Kleinunternehmen.
Dazu gehören:
Die grundlegenden Sicherheitsanforderungen gelten unabhängig von der Unternehmensgröße. Auch kleine Hersteller müssen sichere Produkte entwickeln und Schwachstellen beheben. Sie müssen außerdem die erforderliche Dokumentation vorhalten.
CRA und NIS2 stärken beide die Cybersicherheit in Europa. Sie verfolgen jedoch unterschiedliche Ziele.
Der CRA regelt die Sicherheit von Produkten mit digitalen Elementen. NIS2 richtet sich an Organisationen und deren Sicherheitsmanagement.
| Cyber Resilience Act | NIS2 |
| Reguliert Produkte | Reguliert Organisationen |
| Adressiert Hersteller, Einführer und Händler | Adressiert besonders wichtige und wichtige Einrichtungen |
| Fokus auf Produktentwicklung und Schwachstellenmanagement | Fokus auf Governance, Risikomanagement und Betrieb |
| Meldung aktiv ausgenutzter Schwachstellen | Meldung erheblicher Sicherheitsvorfälle |
| CE-Kennzeichnung und Konformitätsbewertung | Organisatorische Sicherheitsmaßnahmen |
Der CRA gilt als EU-Verordnung unmittelbar in allen Mitgliedstaaten. NIS2 ist eine Richtlinie, die nationale Gesetze umsetzen.
Deshalb können sich einzelne Details der NIS2-Umsetzung zwischen den EU-Staaten unterscheiden.
Viele Unternehmen müssen beide Regelwerke erfüllen. Ein Hersteller kann zugleich als wichtige oder besonders wichtige Einrichtung unter NIS2 gelten.
Dann bestehen separate Compliance-Pflichten mit eigenen Nachweisen und Meldewegen. Stimmen Sie Ihre Prozesse für beide Regelwerke möglichst aufeinander ab.
Marktüberwachungsbehörden können Verstöße gegen den CRA mit erheblichen Sanktionen ahnden. Neben Bußgeldern kommen weitere behördliche Maßnahmen infrage.
Eine mögliche Marktrücknahme kann für Hersteller besonders weitreichende wirtschaftliche Folgen haben.
Bußgelder bei Verstößen gegen Anhang I sowie Artikel 13 und 14
Verstöße gegen die zentralen Sicherheitsanforderungen können bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres kosten.
Maßgeblich ist jeweils der höhere Betrag.
Bußgelder bei sonstigen Pflichtverstößen
Für weitere Pflichtverstöße können Behörden Bußgelder von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes verhängen.
Bußgelder bei falschen Auskünften
Wer Marktüberwachungsbehörden oder benannten Stellen unrichtige, unvollständige oder irreführende Angaben macht, riskiert Bußgelder von bis zu 5 Millionen Euro oder 1 Prozent des weltweiten Jahresumsatzes.
Das größere Risiko: Marktrücknahme
Marktüberwachungsbehörden können anordnen, Produkte vom Markt zu nehmen oder zurückzurufen.
Dadurch können Umsatzeinbußen und zusätzliche Entwicklungskosten entstehen. Auch Lieferverzögerungen und Reputationsschäden sind möglich.
Bewerten Sie mit dieser Checkliste den aktuellen Umsetzungsstand Ihrer Organisation:
Je früher Sie diese Punkte angehen, desto besser integrieren Sie die Anforderungen in Ihre bestehenden Entwicklungs- und Produktprozesse.
Nein. Der Cyber Resilience Act ist eine EU-Verordnung und gilt unmittelbar in allen Mitgliedstaaten.
Sie müssen deshalb nicht auf ein deutsches Umsetzungsgesetz warten.
Ja. Die Verordnung ist bereits in Kraft. Für einzelne Pflichten gelten jedoch unterschiedliche Übergangsfristen.
Die Meldepflichten nach Artikel 14 gelten bereits. Die übrigen Anforderungen werden ab dem 11. Dezember 2027 umfassend anwendbar.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und bestimmte Sicherheitsvorfälle nach Artikel 14 melden.
Dafür benötigen Sie einen operativen Meldeprozess.
Anhang I umfasst insgesamt 21 Anforderungen.
Davon betreffen 13 die Entwicklung und Sicherheit des Produkts. Weitere 8 Anforderungen beziehen sich auf das Schwachstellenmanagement während des Produktlebenszyklus.
Nicht jede Open-Source-Software fällt automatisch unter den CRA.
Einzelne Entwickler, die freie und quelloffene Software außerhalb einer kommerziellen Verantwortung bereitstellen, behandelt die Verordnung grundsätzlich anders als Hersteller. Prüfen Sie deshalb, welche Rolle Ihr Unternehmen bei der Bereitstellung übernimmt.
Der CRA regelt die Cybersicherheit von Produkten mit digitalen Elementen. NIS2 regelt die organisatorischen Sicherheitsmaßnahmen bestimmter Unternehmen und Einrichtungen.
Viele Hersteller müssen künftig beide Regelwerke erfüllen. Beide sehen getrennte Meldewege vor.
Nicht zwingend. Für viele Standardprodukte reicht die interne Konformitätsbewertung aus.
Je nach Produktkategorie und Einstufung können zusätzliche Prüfungen erforderlich sein. Klassifizieren Sie Ihre Produkte deshalb frühzeitig.
Der CRA enthält Übergangsregelungen. Prüfen Sie Ihr bestehendes Produktportfolio trotzdem frühzeitig.
Berücksichtigen Sie dabei insbesondere geplante Änderungen an bereits in Verkehr gebrachten Produkten.
_HighPerformer_HighPerformer.svg)
TISAX® ist eine eingetragene Marke der ENX Association. DataGuard steht in keiner geschäftlichen Verbindung zu ENX. Wir bieten lediglich Software-as-a-Service und Unterstützung zur Vorbereitung auf das Assessment nach TISAX® an. Die ENX Association übernimmt keine Verantwortung für die auf der DataGuard-Website dargestellten Inhalte.
Alle Angaben dienen lediglich der Information und beruhen auf internen Schätzungen. Diese Informationen sind kein Indikator für KPIs und werden ohne ausdrückliche oder stillschweigende Zusicherungen oder Garantien in Bezug auf Genauigkeit und Zuverlässigkeit gegeben.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "www.dataguard.de#organization",
"name": "DataGuard",
"legalName": "DataCo GmbH",
"description": "DataGuard ist der führende europäische Anbieter von Security- und Compliance-Software und wird von über 4.000 Organisationen in mehr als 50 Ländern weltweit geschätzt. Wir helfen Ihnen, Sicherheits- und Compliance-Risiken zu identifizieren und zu managen, Compliance-Anforderungen zu erfüllen und Zertifizierungen schneller zu erreichen. Dabei kombinieren wir maßgeschneiderte Expertenberatung mit KI-gestützter Automatisierung. Unsere speziell entwickelte All-in-One-Plattform basiert auf mehr als 1,5 Millionen Stunden Erfahrung eines Teams zertifizierter Security- und Compliance-Experten.",
"foundingDate": "2018",
"taxID": "DE315880213",
"logo": "https://7759810.fs1.hubspotusercontent-na1.net/hubfs/7759810/DataGuardLogo.svg",
"url": "www.dataguard.de",
"email": "info@dataguard.de",
"telephone": "+49 89 452459 900",
"address": {
"@type": "PostalAddress",
"streetAddress": "Sandstrasse 33",
"addressLocality": "München",
"addressRegion": "Bayern",
"postalCode": "80335",
"addressCountry": "Deutschland"
},
"sameAs": [
"https://www.linkedin.com/company/dataguard1/",
"https://www.youtube.com/channel/UCEQzPZ6sCBCj9cAoBvaLL6w",
"https://x.com/i/flow/login?redirect_after_login=%2FDataGuard_dg"
]
}
]
}✅ Organization schema markup for "DataGuard" has been injected into the document head.