Der Cyber Resilience Act (CRA) legt verbindliche Cybersicherheitsanforderungen für Produkte fest, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind. Die Verordnung betrifft Hersteller, Importeure und Händler entlang der gesamten Lieferkette. Die Meldepflichten gelten bereits seit dem 11. September 2026, die vollständige Anwendung beginnt am 11. Dezember 2027.
Der Cyber Resilience Act (CRA) ist eine EU-Verordnung, die erstmals verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt. Darunter versteht die EU Hard- und Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind, beispielsweise Apps, IoT-Geräte, Router oder Smart-Home-Produkte.
Ziel des CRA ist es, die Cybersicherheit vernetzter Produkte über ihren gesamten Lebenszyklus hinweg zu verbessern. Gleichzeitig schafft die Verordnung einheitliche Anforderungen für Unternehmen und mehr Transparenz für Kunden bei der Bewertung der Sicherheit digitaler Produkte.
Der CRA verfolgt einen produktbezogenen Ansatz. Im Mittelpunkt steht nicht die Sicherheitsorganisation eines Unternehmens, sondern die Sicherheit des Produkts selbst. Hersteller müssen Cybersicherheit bereits bei der Entwicklung berücksichtigen und auch nach der Markteinführung durch Sicherheitsupdates, Schwachstellenmanagement und Dokumentation nachweisen.
Weitere Informationen stellt die Europäische Kommission auf ihrer offiziellen Informationsseite bereit: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Der Begriff „Produkte mit digitalen Elementen“ bildet die Grundlage des gesamten Cyber Resilience Act.
Darunter fallen Hard- und Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden werden können. Die Definition umfasst sowohl eigenständige digitale Produkte als auch Softwarekomponenten, die Teil eines anderen Produkts sind.
Beispiele für Produkte mit digitalen Elementen:
Die Reichweite des Gesetzes ist damit sehr groß. Viele Unternehmen, die bislang keine spezifischen Cybersecurity-Vorgaben für ihre Produkte erfüllen mussten, fallen künftig in den Anwendungsbereich des CRA.
Cybersicherheit und Cyber-Resilienz werden häufig gleichgesetzt. Der Cyber Resilience Act unterscheidet jedoch indirekt zwischen beiden Konzepten.
Cybersicherheit beschreibt Maßnahmen, die Angriffe verhindern oder deren Erfolg erschweren sollen. Dazu gehören beispielsweise Zugangskontrollen, Verschlüsselung oder Schwachstellenmanagement.
Cyber-Resilienz geht einen Schritt weiter. Sie beschreibt die Fähigkeit eines Produkts oder einer Organisation, auch nach einem erfolgreichen Angriff funktionsfähig zu bleiben, Auswirkungen zu begrenzen und den Normalbetrieb wiederherzustellen.
Für Hersteller bedeutet das: Sicherheitsmaßnahmen allein reichen künftig nicht aus. Produkte müssen so entwickelt werden, dass sie auch bei Sicherheitsvorfällen kontrollierbar, aktualisierbar und widerstandsfähig bleiben.
Der CRA richtet sich an Unternehmen entlang der gesamten Lieferkette von Produkten mit digitalen Elementen.
Betroffen sind insbesondere:
Die Anforderungen unterscheiden sich je nach Rolle innerhalb der Lieferkette. Hersteller tragen den größten Teil der Verantwortung, da sie Produktentwicklung, Konformitätsbewertung und Dokumentation steuern.
Importeure und Händler müssen hingegen prüfen, ob Produkte die regulatorischen Anforderungen erfüllen, bevor sie diese auf dem europäischen Markt bereitstellen.
Der Cyber Resilience Act besitzt einen breiten Anwendungsbereich. Dennoch existieren Ausnahmen.
Vom CRA ausgenommen sind unter anderem:
Die Europäische Union möchte damit Doppelregulierung vermeiden. Für viele dieser Bereiche bestehen bereits eigenständige Sicherheitsanforderungen.
Unternehmen sollten den genauen Anwendungsbereich ihres Produktportfolios frühzeitig prüfen. Gerade bei komplexen Softwarelösungen und eingebetteten Systemen kann die Einordnung anspruchsvoll sein.
Der Cyber Resilience Act baut auf der EU-Cybersicherheitsstrategie von 2020 auf und ergänzt bestehende Regelwerke wie die NIS2-Richtlinie.
Die Europäische Union reagiert damit auf mehrere strukturelle Probleme des Marktes.
Zu den zentralen Herausforderungen gehören:
In der Praxis zeigten viele Angriffe, dass Schwachstellen bereits bei der Entwicklung entstanden. Sicherheitsaspekte wurden häufig erst nachträglich berücksichtigt. Der CRA verlagert den Fokus deshalb auf Security by Design und Security by Default.
Hersteller müssen künftig nachweisen, dass sie Sicherheitsrisiken systematisch bewertet und reduziert haben, bevor ein Produkt auf den Markt kommt.
Der CRA kombiniert technische Produktanforderungen mit organisatorischen Herstellerpflichten.
| Produktanforderungen | Herstellerpflichten |
| Security by Design | Risikobewertung vor der Markteinführung |
| Security by Default | Erstellung technischer Dokumentation |
| Schutz vor bekannten Schwachstellen | Durchführung von Konformitätsbewertungen |
| Möglichkeit zur Installation von Sicherheitsupdates | Überwachung von Schwachstellen nach Markteinführung |
| Sichere Standardkonfiguration | Dokumentationsaufbewahrung für zehn Jahre oder die Dauer des Supportzeitraums, je nachdem welcher Zeitraum länger ist |
| Minimierung von Angriffsflächen | Meldung relevanter Vorfälle und Schwachstellen |
Unternehmen müssen Sicherheitsanforderungen über den gesamten Produktlebenszyklus hinweg berücksichtigen. Dazu gehören Entwicklung, Betrieb, Wartung und Support.
Der CRA schafft damit einen einheitlichen Rahmen, der Cybersicherheit als dauerhafte Herstellerverantwortung verankert.
Ein zentrales Konzept des Cyber Resilience Act ist die Software Bill of Materials, kurz SBOM.
Eine SBOM ist ein strukturiertes Verzeichnis aller Softwarekomponenten, aus denen ein Produkt besteht. Sie dokumentiert beispielsweise:
Die SBOM wird Teil der technischen Dokumentation und unterstützt Unternehmen dabei, Schwachstellen schneller zu identifizieren und Risiken über den gesamten Lebenszyklus zu überwachen.
Gerade bei modernen Softwareprodukten mit zahlreichen externen Komponenten schafft eine aktuelle SBOM Transparenz und verbessert das Vulnerability Management.
Viele Unternehmen in Deutschland beschäftigen sich bereits mit der Frage, wie sich die Anforderungen des Cyber Resilience Act praktisch umsetzen lassen. Eine wichtige Orientierungshilfe bietet dabei die technische Richtlinie BSI TR-03183 des Bundesamts für Sicherheit in der Informationstechnik (BSI).
Die Richtlinie unterstützt Hersteller dabei, zentrale Sicherheitsanforderungen des CRA besser zu verstehen und in Entwicklungs- und Produktprozesse zu integrieren. Das gilt insbesondere in einer Übergangsphase, in der noch nicht alle harmonisierten europäischen Normen vorliegen.
Die BSI TR-03183 ist eine technische Richtlinie, die konkrete Empfehlungen für die sichere Entwicklung, Bereitstellung und Wartung von Produkten mit digitalen Elementen enthält.
Sie unterstützt Unternehmen unter anderem bei folgenden Themen:
Wichtig ist dabei die rechtliche Einordnung: Die BSI TR-03183 ist keine verbindliche Vorgabe des Cyber Resilience Act.
Nein. Die BSI TR-03183 begründet keine Konformitätsvermutung im Sinne des CRA. Unternehmen können sich daher nicht allein durch die Umsetzung der Richtlinie auf eine automatische Konformität mit der Verordnung berufen.
Dennoch bietet die Richtlinie wertvolle Orientierung, um Sicherheitsanforderungen frühzeitig in Produktentwicklungsprozesse zu integrieren und bestehende Lücken zu identifizieren.
Zusätzlich können Hersteller das IT-Sicherheitskennzeichen des BSI nutzen, um Sicherheitsmaßnahmen transparenter zu machen und sich auf zukünftige Anforderungen vorzubereiten.
Weitere Informationen stellt das BSI auf seiner offiziellen Informationsseite zum Cyber Resilience Act bereit.
Der CRA unterscheidet mehrere Risikokategorien. Die Einstufung beeinflusst die Anforderungen an die Konformitätsbewertung.
| Kategorie | Beschreibung |
| Standardkategorie | Umfasst den Großteil aller Produkte mit digitalen Elementen |
| Wichtige Produkte Klasse I | Produkte mit erhöhtem Cybersicherheitsrisiko |
| Wichtige Produkte Klasse II | Produkte mit höherem Risikopotenzial und erweiterten Anforderungen |
| Kritische Produkte | Produkte mit besonderer Bedeutung für Sicherheit und kritische Funktionen |
Schätzungen zufolge fallen die meisten Produkte in die Standardkategorie. Für risikoreichere Produkte steigen die Anforderungen an Nachweise, Prüfverfahren und Konformitätsbewertungen.
Der Cyber Resilience Act wird schrittweise eingeführt. Unternehmen sollten die einzelnen Meilensteine genau kennen, da bestimmte Pflichten bereits vor dem Start der vollständigen Anwendung gelten.
| Datum | Meilenstein |
| 10. Dezember 2024 | Der Cyber Resilience Act tritt in Kraft |
| 11. Juni 2026 | Regelungen für die Benennung von Konformitätsbewertungsstellen gelten |
| 11. September 2026 | Melde- und Berichtspflichten nach Art. 14 gelten |
| 11. Dezember 2027 | Vollständige Anwendung der Verordnung inklusive Konformitätsbewertung und CE-Kennzeichnung |
Ein häufiger Irrtum besteht darin, den CRA ausschließlich mit der Frist im Dezember 2027 zu verbinden. Tatsächlich gelten bestimmte Verpflichtungen bereits deutlich früher.
Der CRA ist keine einzelne Frist im Jahr 2027. Die Meldepflichten sind bereits aktiv.
Unternehmen sollten daher nicht darauf warten, bis die vollständige Anwendung beginnt. Wer Prozesse erst kurz vor Ende 2027 aufbaut, riskiert erhebliche Umsetzungsprobleme.
Mit dem Inkrafttreten der Meldepflichten verfolgt die Europäische Union das Ziel, Sicherheitsrisiken schneller zu erkennen und koordinierte Gegenmaßnahmen zu ermöglichen.
Hersteller müssen künftig bestimmte Vorfälle aktiv melden.
Dazu gehören:
Die Meldungen erfolgen an die Europäische Agentur für Cybersicherheit (ENISA) sowie an die zuständige nationale Computer Security Incident Response Team (CSIRT)-Stelle.
Der CRA definiert mehrere aufeinanderfolgende Meldephasen.
| Meldephase | Frist |
| Frühwarnung | Innerhalb von 24 Stunden nach Bekanntwerden |
| Detaillierte Meldung | Innerhalb von 72 Stunden |
| Zwischenbericht | Falls erforderlich |
| Abschlussbericht | Nach 14 Tagen oder innerhalb eines Monats, abhängig vom Vorfall |
Diese Fristen machen deutlich, dass Unternehmen ein funktionierendes Schwachstellenmanagement benötigen. Sicherheitsverantwortliche, Produktteams und Compliance-Abteilungen müssen eng zusammenarbeiten, um relevante Ereignisse rechtzeitig zu identifizieren und zu melden.
Der Cyber Resilience Act wird Teil des europäischen Produktsicherheitsrahmens. Deshalb spielt die CE-Kennzeichnung eine zentrale Rolle.
Mit der CE-Kennzeichnung erklärt ein Hersteller, dass sein Produkt die geltenden Anforderungen der Verordnung erfüllt.
Voraussetzung dafür ist eine erfolgreiche Konformitätsbewertung.
Der CRA orientiert sich am bewährten europäischen Normungsansatz. Die Europäische Kommission hat dazu den Normungsauftrag M/606 veröffentlicht.
Ziel ist die Entwicklung von rund 41 harmonisierten Normen, die Unternehmen bei der Umsetzung der regulatorischen Anforderungen unterstützen sollen.
Wer diese harmonisierten Normen korrekt anwendet, profitiert von einer sogenannten Konformitätsvermutung. Das vereinfacht den Nachweis, dass die relevanten Anforderungen des CRA erfüllt wurden.
Das erforderliche Konformitätsbewertungsverfahren hängt von der Risikoklasse des jeweiligen Produkts ab.
Produkte mit geringerem Risiko können häufig interne Bewertungsverfahren nutzen. Für höher klassifizierte Produkte kann die Einbindung unabhängiger Konformitätsbewertungsstellen erforderlich werden.
Je höher das Risiko eines Produkts, desto umfangreicher fallen in der Regel Nachweise, Prüfungen und Dokumentationsanforderungen aus.
Der europäische Gesetzgeber hat die Einhaltung der Vorgaben mit erheblichen Sanktionen verknüpft.
Unternehmen, die wesentliche Anforderungen oder Herstellerpflichten verletzen, müssen mit Bußgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes rechnen. Maßgeblich ist jeweils der höhere Betrag.
Für andere Verstöße gelten niedrigere Obergrenzen.
Die Höhe möglicher Sanktionen zeigt, welchen Stellenwert die Europäische Union der Cybersicherheit digitaler Produkte beimisst. Für Hersteller kann die Nichteinhaltung daher nicht nur regulatorische Folgen haben, sondern auch erhebliche finanzielle und reputative Risiken mit sich bringen.
Ja. Der CRA berücksichtigt die besonderen Herausforderungen von Kleinstunternehmen und kleinen Unternehmen.
Insbesondere bei der Einhaltung der 24-Stunden-Meldefrist können unter bestimmten Voraussetzungen Erleichterungen vorgesehen sein. Dennoch bleiben die grundlegenden Anforderungen der Verordnung bestehen.
Auch kleinere Anbieter sollten deshalb frühzeitig Prozesse für Schwachstellenmanagement, Incident Response und regulatorische Meldungen aufbauen.
Ein strukturierter Vorbereitungsprozess reduziert den Umsetzungsaufwand und schafft Planungssicherheit, bevor die vollständige Anwendung des Cyber Resilience Act im Dezember 2027 beginnt.
Auch wenn die vollständige Anwendung des Cyber Resilience Act erst am 11. Dezember 2027 beginnt, sollten Unternehmen bereits heute aktiv werden. Die Einführung neuer Prozesse, die Anpassung bestehender Entwicklungsabläufe und die Erstellung der erforderlichen Dokumentation benötigen Zeit.
Ein strukturierter Ansatz hilft dabei, regulatorische Anforderungen frühzeitig zu erfüllen und spätere Umsetzungsprobleme zu vermeiden.
Der erste Schritt besteht darin, festzustellen, welche Produkte unter den Cyber Resilience Act fallen. Dabei sollten Unternehmen ihr gesamtes Produktportfolio prüfen und dokumentieren, welche Hard- und Softwarelösungen als Produkte mit digitalen Elementen gelten.
Besondere Aufmerksamkeit verdienen Produkte mit eingebetteter Software, Cloud-Anbindungen oder Netzwerkfunktionen.
Anschließend sollten Unternehmen die passende Produktrisikoklasse ermitteln. Die Einstufung beeinflusst unter anderem die Anforderungen an die Konformitätsbewertung und die Nachweisführung.
Je früher diese Einordnung erfolgt, desto einfacher lassen sich spätere Compliance-Maßnahmen planen.
Anhang I des CRA enthält die wesentlichen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
Eine Gap-Analyse zeigt auf, welche Anforderungen bereits erfüllt werden und an welchen Stellen Handlungsbedarf besteht. Typische Prüffelder sind sichere Voreinstellungen, Update-Mechanismen, Authentifizierung und Schwachstellenmanagement.
Für viele Unternehmen wird die Pflege einer Software Bill of Materials zu einem zentralen Compliance-Baustein.
Deshalb sollten Prozesse geschaffen werden, die Softwarekomponenten automatisch erfassen, dokumentieren und aktualisieren. Dadurch lassen sich Sicherheitsrisiken schneller bewerten und betroffene Komponenten leichter identifizieren.
Da die Meldepflichten bereits gelten, sollten Hersteller über klare Prozesse zur Identifikation und Meldung von Schwachstellen verfügen.
Dazu zählen:
Ziel ist es, die vorgegebenen Meldefristen zuverlässig einzuhalten.
Der CRA verlangt umfangreiche technische Unterlagen. Unternehmen sollten deshalb frühzeitig festlegen, welche Informationen dokumentiert werden müssen und wie diese langfristig gepflegt werden.
Dazu gehören unter anderem Sicherheitsmaßnahmen, Risikobewertungen, Prüfberichte und die SBOM.
Vor der Markteinführung müssen Hersteller nachweisen, dass ihr Produkt die regulatorischen Anforderungen erfüllt.
Je nach Risikoklasse kann hierfür ein internes Verfahren ausreichen oder die Einbindung einer benannten Stelle erforderlich sein.
Nach erfolgreicher Konformitätsbewertung kann die CE-Kennzeichnung erfolgen. Sie bestätigt, dass das Produkt die geltenden europäischen Anforderungen erfüllt und auf dem EU-Markt bereitgestellt werden darf.
Der Cyber Resilience Act und die NIS2-Richtlinie verfolgen das gleiche übergeordnete Ziel: ein höheres Cybersicherheitsniveau in Europa. Dennoch adressieren beide Regelwerke unterschiedliche Bereiche.
| Cyber Resilience Act (CRA) | NIS2-Richtlinie |
| Regelt Produkte | Regelt Organisationen |
| Fokus auf Security by Design | Fokus auf Sicherheitsmanagement |
| Gilt für Hersteller, Importeure und Händler | Gilt für wichtige und besonders wichtige Einrichtungen |
| Betrifft Produkte mit digitalen Elementen | Betrifft den Betrieb kritischer und relevanter Organisationen |
| Schwerpunkt auf Produktsicherheit | Schwerpunkt auf organisatorischer Resilienz |
Unternehmen sollten beide Regelwerke nicht isoliert betrachten. Viele Hersteller fallen gleichzeitig in den Anwendungsbereich des CRA und der NIS2-Richtlinie.
Ein Softwareanbieter kann beispielsweise seine Produkte nach den Anforderungen des Cyber Resilience Act entwickeln müssen und gleichzeitig als wichtige Einrichtung unter NIS2 zusätzliche organisatorische Sicherheitsmaßnahmen umsetzen.
Die beiden Regelwerke ergänzen sich daher in vielen Fällen.
Die Rolle von Open-Source-Software war während der Ausarbeitung des CRA ein besonders intensiv diskutiertes Thema.
Die Europäische Union verfolgt hier einen differenzierten Ansatz. Nicht-kommerzielle Open-Source-Projekte unterliegen grundsätzlich nicht denselben Anforderungen wie kommerzielle Anbieter.
Wer Open-Source-Software ohne kommerzielle Absicht entwickelt und bereitstellt, profitiert in vielen Fällen von Ausnahmen innerhalb des Regelwerks.
Anders sieht es bei kommerziellen Produkten aus, die Open-Source-Komponenten enthalten. In diesem Fall gelten die regulären Herstellerpflichten des Cyber Resilience Act.
Da moderne Softwareprodukte häufig auf Open-Source-Bibliotheken aufbauen, gewinnt die Transparenz über verwendete Komponenten an Bedeutung. Genau hier spielt die Software Bill of Materials eine wichtige Rolle.
Unternehmen sollten deshalb klare Prozesse etablieren, um Open-Source-Abhängigkeiten zu dokumentieren, zu überwachen und regelmäßig auf bekannte Schwachstellen zu prüfen.
Der Cyber Resilience Act gilt für Hersteller, Importeure und Händler von vernetzten Hard- und Softwareprodukten, die auf dem EU-Markt bereitgestellt werden. Dazu gehören beispielsweise Apps, IoT-Geräte, Smartwatches, Router oder industrielle Steuerungssysteme. Die Verpflichtungen gelten auch für Unternehmen außerhalb der EU, sofern ihre Produkte im europäischen Markt angeboten werden.
Eine SBOM ist ein strukturiertes Verzeichnis aller Softwarekomponenten eines Produkts. Sie dokumentiert beispielsweise verwendete Bibliotheken, Frameworks und Open-Source-Komponenten und unterstützt das Schwachstellenmanagement.
Bei Verstößen gegen wesentliche Anforderungen oder Herstellerpflichten können Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes verhängt werden. Maßgeblich ist jeweils der höhere Betrag.
Nicht-kommerzielle Open-Source-Projekte profitieren grundsätzlich von Ausnahmen. Für kommerzielle Produkte, die Open-Source-Komponenten enthalten, gelten die regulären Anforderungen des CRA.
Zu den wichtigsten Ausnahmen zählen bestimmte Medizinprodukte, Luftfahrtprodukte, Fahrzeuge sowie weitere Produkte, die bereits durch sektorspezifische europäische Regelwerke reguliert werden.
Die Melde- und Berichtspflichten nach Artikel 14 gelten seit dem 11. September 2026. Hersteller müssen bestimmte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb definierter Fristen melden.
Die BSI TR-03183 ist eine technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik. Sie unterstützt Hersteller bei der Interpretation und Umsetzung der CRA-Anforderungen, ersetzt jedoch keine harmonisierten europäischen Normen.
_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.