Cyber Resilience Act (CRA): Vollständiger Compliance-Leitfaden 2026
Alles, was Hersteller zum EU Cyber Resilience Act wissen müssen — Pflichtanforderungen, SBOM-Pflicht, September-2026-Frist, CE-Kennzeichnung und Umsetzungsfahrplan für Produkte mit digitalen Elementen.
Cyber Resilience Act (CRA): Vollständiger Compliance-Leitfaden 2026
Der Cyber Resilience Act (Verordnung 2024/2847) ist die weltweit erste horizontale Verordnung, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen einführt. Er verlangt Security by Design, Sicherheitsupdates über den gesamten Lebenszyklus und transparentes Schwachstellenmanagement für Hardware- und Softwareprodukte auf dem EU-Markt.
Die kritische Frist rückt näher: Ab dem 11. September 2026 gelten Schwachstellenmeldepflichten — auch für Produkte, die sich bereits auf dem Markt befinden.
Wenn Sie vernetzte Produkte oder Software in Europa herstellen, importieren oder vertreiben, betrifft der CRA Sie direkt. Dieser Leitfaden behandelt den vollständigen Anwendungsbereich, die Anforderungen, die September-2026-Sofortmaßnahmen und die wichtigsten Klarstellungen der Kommissions-Leitlinien vom März 2026.
Was ist der Cyber Resilience Act?
Der CRA etabliert horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen über ihren gesamten Lebenszyklus — von Design und Entwicklung über die Markteinführung bis zum Lebensende. Er adressiert das grundlegende Marktversagen, dass die meisten vernetzten Produkte bisher keinerlei regulatorische Cybersicherheitsanforderungen hatten.
Zentrale Grundsätze:
- Security by Design: Sicherheit muss von Anfang an eingebaut sein — nicht nachträglich ergänzt werden
- Security by Default: Produkte müssen mit sicherer Standardkonfiguration ausgeliefert werden
- Lebenszyklus-Verantwortung: Hersteller müssen Sicherheitsupdates für die erwartete Produktlebensdauer bereitstellen (mindestens 5 Jahre)
- Transparenz: Schwachstellen müssen gemeldet und koordiniert behandelt werden
- Marktzugang: Nicht-konforme Produkte dürfen keine CE-Kennzeichnung tragen und nicht auf den EU-Markt gebracht werden
Der CRA wurde am 20. November 2024 im Amtsblatt veröffentlicht und trat am 10. Dezember 2024 in Kraft.
Wer muss den CRA einhalten?
Der CRA gilt für drei Kategorien von Wirtschaftsakteuren:
Hersteller
Jede Einrichtung, die Produkte mit digitalen Elementen entwirft, entwickelt oder herstellt — oder herstellen lässt — und unter eigenem Namen oder einer eigenen Marke vermarktet. Wenn Sie Software unter Ihrem eigenen Markennamen vertreiben (auch auf Basis von Open-Source-Komponenten), sind Sie für CRA-Zwecke der Hersteller.
Importeure
Jede in der EU ansässige Einrichtung, die ein Produkt eines außereuropäischen Herstellers auf den EU-Markt bringt.
Händler
Jede Einrichtung in der Lieferkette (außer Hersteller und Importeur), die ein Produkt auf dem Markt bereitstellt.
Was zählt als „Produkt mit digitalen Elementen"?
Der CRA erfasst:
- Vernetzte Hardware: IoT-Geräte, Router, Smart-Home-Geräte, Industriesteuerungen, Automotive-Komponenten
- Eigenständige Software: Anwendungen, Betriebssysteme, Firmware, Middleware, Bibliotheken
- Cloud-Komponenten: Fernverarbeitungslösungen, die für die Kernfunktion eines Produkts wesentlich sind (keine eigenständigen SaaS-Dienste)
Die Kommissions-Leitlinien vom März 2026 stellen klar: Software gilt als „in Verkehr gebracht", wenn sie erstmals zur Verteilung oder Nutzung auf dem EU-Markt bereitgestellt wird — einschließlich durch Download-Angebote oder Fernzugriff.
Ausnahmen
- Open-Source-Software in nicht-kommerziellem Kontext (siehe Abschnitt Open Source)
- Produkte unter sektorspezifischer EU-Gesetzgebung (Medizinprodukte nach MDR, Automotive nach Typgenehmigungsvorschriften, Luftfahrt nach EASA)
- Produkte ausschließlich für nationale Sicherheit oder Verteidigung
Produktkategorien und Konformitätsbewertung
Der CRA kategorisiert Produkte nach ihrem Kritikalitätsniveau:
Standardkategorie (Mehrheit der Produkte)
- Konformitätsbewertung: Selbstbewertung durch den Hersteller
- Beispiele: Die meisten Consumer-IoT-Geräte, Allzweck-Software
- Verfahren: Interne Kontrolle (Modul A) gemäß Anhang VIII
Wichtige Produkte — Klasse I (Anhang III)
- Identitätsmanagement- und Authentifizierungssoftware
- VPNs, Netzwerkverwaltungssysteme
- SIEM-Systeme
- Boot-Manager, BIOS-Firmware
- Firewalls, IDS/IPS für nicht-industrielle Nutzung
- Router und Modems für Internet-Konnektivität
- Mikroprozessoren und Mikrocontroller mit Sicherheitsfunktionen
- Bewertung: Selbstbewertung mit harmonisierten Normen ODER Drittbewertung
Wichtige Produkte — Klasse II (Anhang III, höheres Risiko)
- Hypervisoren, Container-Laufzeitumgebungen
- Firewalls und IDS/IPS für industrielle Nutzung
- Manipulationsresistente Mikroprozessoren/Mikrocontroller
- Bewertung: Drittbewertung obligatorisch
Kritische Produkte (Anhang IV)
- Hardware-Sicherheitsmodule (HSMs), Smartcards, sichere Elemente
- Smart-Meter-Gateways in Smart-Meter-Systemen
- Bewertung: Europäische Cybersicherheitszertifizierung erforderlich
Aktueller Stand harmonisierter Normen: ETSI, CEN und CENELEC entwickeln auf Mandat der Kommission EU-weite harmonisierte Normen — darunter vertikale Produktnormen für Browser, Passwort-Manager, Antivirensoftware, VPNs, SIEM und Boot-Manager. Der erste gemeinsame Bericht war für Februar 2026 vorgesehen; die meisten harmonisierten Normen werden bis Ende 2026 erwartet.
Wesentliche Cybersicherheitsanforderungen (Anhang I)
Teil I: Produktanforderungen
- Produkte müssen mit angemessenem Cybersicherheitsniveau konzipiert, entwickelt und hergestellt werden
- Produkte müssen ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden
- Sichere Standardkonfiguration mit Reset-Möglichkeit auf Werkseinstellungen
- Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen
- Schutz der Vertraulichkeit gespeicherter, übertragener oder verarbeiteter Daten (Verschlüsselung wo angemessen)
- Schutz der Datenintegrität
- Verarbeitung nur notwendiger Daten (Datenminimierung)
- Verfügbarkeitsschutz, einschließlich Resilienz gegen Denial-of-Service
- Minimierung negativer Auswirkungen auf andere Geräte/Netzwerke
- Minimale Angriffsfläche
- Schadensbegrenzung durch Exploit-Mitigation-Techniken
- Sicherheitsrelevante Protokollierung und Überwachung (Logging)
- Sichere Software-Update-Mechanismen mit Nutzerbenachrichtigung
Teil II: Anforderungen an das Schwachstellenmanagement
- Schwachstellen und Komponenten identifizieren und dokumentieren (inkl. SBOM)
- Schwachstellen unverzüglich durch Sicherheitsupdates beheben
- Regelmäßige und wirksame Tests und Überprüfungen
- Öffentliche Offenlegung behobener Schwachstellen mit CVE-Kennungen
- Koordinierte Schwachstellenoffenlegungsrichtlinie (CVD-Policy)
- Sichere Verteilungsmechanismen für Sicherheitsupdates
- Kostenlose Sicherheitsupdates für die erwartete Produktlebensdauer (mindestens 5 Jahre)
Die September-2026-Frist: Was Unternehmen jetzt tun müssen
Die dringlichste CRA-Pflicht ist Artikel 14 — der ab dem 11. September 2026 gilt. Dies ist kein Vorbereitungsmeilenstein, sondern ein harter Durchsetzungstermin. Ab diesem Datum ist das Unterlassen einer Meldung ein CRA-Verstoß.
Achtung: Auch Bestandsprodukte sind betroffen
Ein entscheidender Punkt, den viele Hersteller übersehen: Die Meldepflichten nach Artikel 14 gelten für alle Produkte mit digitalen Elementen auf dem EU-Markt — auch für Produkte, die vor dem Dezember-2027-Stichtag in Verkehr gebracht wurden. Wenn Ihr IoT-Gerät, Ihr Router oder Ihre Software heute verkauft wird und im September 2026 eine Schwachstelle entdeckt wird, müssen Sie diese melden.
Was gemeldet werden muss
Hersteller müssen über die Single Reporting Platform an ENISA und das zuständige nationale CSIRT melden:
Aktiv ausgenutzte Schwachstellen:
- Innerhalb von 24 Stunden nach Kenntnisnahme: Frühwarnung
- Innerhalb von 72 Stunden: Vollständige Schwachstellenmeldung mit verfügbaren Korrekturmaßnahmen
- Innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme: Abschlussbericht mit Beschreibung, Schweregrad, Auswirkung und Behebung
Schwerwiegende Sicherheitsvorfälle:
- Gleiche 24-Stunden/72-Stunden-Frühwarnstruktur
- Innerhalb von 1 Monat: Abschlussberichterstattung
Die Single Reporting Platform (SRP)
ENISA richtet die Single Reporting Platform (SRP) ein, die bis zum 11. September 2026 betriebsbereit sein soll. Hersteller melden einmalig über die SRP — Meldungen gehen an das CSIRT am Hauptgeschäftssitz des Herstellers, werden gleichzeitig ENISA und relevanten EU-CSIRTs zugänglich gemacht. Vor dem Stichtag steht eine Testphase zur Verfügung.
Sofortmaßnahmen bis September 2026
- Produktinventur: Alle Produkte mit digitalen Elementen auf dem EU-Markt identifizieren
- SBOM erstellen oder aktualisieren: Jedes Produkt braucht eine vollständige Software Bill of Materials
- CSIRT-Kontakt festlegen: Zuständiges nationales CSIRT auf Basis des Hauptgeschäftssitzes identifizieren
- SRP-Zugang registrieren: Zugang zur ENISA Single Reporting Platform einrichten
- CVD-Policy veröffentlichen: Koordinierte Schwachstellenoffenlegungsrichtlinie veröffentlichen (security@ihredomain.de oder HackerOne/Bugcrowd)
- 24/72h-Eskalationsprozess dokumentieren: Internen Meldeprozess für Frühwarnung in 24 Stunden dokumentieren und einüben
- CVE-Monitoring einrichten: CVE-Datenbanken und Security Advisories für Ihre Abhängigkeiten überwachen
Software Bill of Materials (SBOM): Die Grundlage der CRA-Compliance
Eine der praktisch bedeutsamsten CRA-Anforderungen ist die Pflicht zur Software Bill of Materials (SBOM) — eine vollständige, maschinenlesbare Liste aller Softwarekomponenten in einem Produkt: Bibliotheken, Frameworks, Open-Source-Pakete und ihre Versionen.
Warum SBOMs für den CRA entscheidend sind:
- Schwachstellen-Erkennung: Wird eine kritische Schwachstelle in einer Abhängigkeit entdeckt (z.B. ein Log4Shell-ähnliches Ereignis), können Sie sofort identifizieren, welche Ihrer Produkte betroffen sind
- 24-Stunden-Meldepflicht: Ohne eine aktuelle SBOM ist die Einhaltung der 24-Stunden-Frühwarnfrist für Produkte mit umfangreichem Abhängigkeitsbaum praktisch unmöglich
- Konformitätsnachweis: Marktüberwachungsbehörden (in Deutschland: das BSI als zuständige Behörde) können SBOMs im Rahmen der Konformitätsbewertung anfordern
SBOM-Mindestinhalt nach CRA:
- Name und Version jeder Komponente
- Hersteller/Autor der Komponente
- Eindeutige Kennung (z.B. Package URL/PURL)
- Abhängigkeitsbeziehungen
- Lizenzinformationen
Gängige Formate: SPDX (ISO/IEC 5962) und CycloneDX — CycloneDX wird für Sicherheitsanwendungen zunehmend bevorzugt, da es Schwachstellen-Tracking integriert.
Secure Development Lifecycle (SDL) nach CRA-Anforderungen
Der CRA schreibt kein spezifisches SDL-Framework vor, aber die wesentlichen Anforderungen aus Anhang I beschreiben im Kern, was ein CRA-konformer Entwicklungsprozess erzeugen muss. Security in jeder Phase zu verankern, ist der einzige skalierbare Ansatz:
Anforderungsphase
- Sicherheitsanforderungen von Beginn an in der Produktspezifikation festlegen
- Threat Modelling als Teil der Produktplanung durchführen
- Erwartete Produktlebensdauer deklarieren (mindestens 5 Jahre für den Support-Zeitraum)
Entwicklungsphase
- Sichere Coding-Standards und systematische Code-Reviews anwenden
- Dependency-Management-Tools zur Verfolgung und Aktualisierung von Drittbibliotheken einsetzen
- Automatisiertes Static Application Security Testing (SAST) implementieren
Testphase
- Penetrationstests vor jedem Major Release
- Dynamic Application Security Testing (DAST)
- Schwachstellen-Scanning aller Komponenten
Veröffentlichungsphase
- SBOM für jeden Release erstellen und veröffentlichen
- Sichere Standardkonfiguration vor Auslieferung verifizieren
- Sicherheitseinstellungen für Nutzer dokumentieren
Betriebsphase
- CVE-Datenbanken und Security Advisories für den Abhängigkeitsgraphen überwachen
- Patch-Management-Prozess mit definierten Reaktionsfristen betreiben
- Formales Coordinated Vulnerability Disclosure (CVD)-Programm betreiben
Open Source und der CRA
Die CRA-Regelungen zu Open Source sind differenziert. Die Ausnahme für nicht-kommerziellen Open Source deckt individuelle Beiträge und Projekte ab, die außerhalb eines kommerziellen Kontexts entwickelt werden. Es gibt jedoch zwei Szenarien, die Open-Source-Akteure in den Anwendungsbereich bringen:
Open-Source-Stewards
Eine juristische Person (typischerweise eine Stiftung), die nachhaltige Unterstützung für die Entwicklung von Open-Source-Software mit kommerziellem Verwendungszweck leistet, unterliegt dem CRA als Open-Source-Steward. Dieses vereinfachte Regime sieht vor:
- Pflege einer Cybersicherheitsrichtlinie für sichere Entwicklung und Schwachstellenbehandlung
- Kooperation mit Marktüberwachungsbehörden
- Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle ab September 2026
- Wichtig: Open-Source-Stewards unterliegen keinen Bußgeldern im Rahmen des CRA
Kommerzielle Produkte mit Open-Source-Komponenten
Wenn Sie ein kommerzielles Produkt vertreiben, das Open-Source-Komponenten enthält, sind Sie für CRA-Zwecke der Hersteller — verantwortlich für das gesamte Produkt inklusive seiner Open-Source-Abhängigkeiten. Die Kommissions-Leitlinien vom März 2026 stellen klar: Hersteller müssen nicht sicherstellen, dass ein Bugfix vom Upstream-Projekt akzeptiert wird (lokale Patches sind zulässig) — aber sie müssen Schwachstellen in allen Komponenten verfolgen und melden.
Kommissions-Leitlinien März 2026: Wichtige Klarstellungen
Die Europäische Kommission veröffentlichte ihr Entwurfsdokument (Ares(2026)2319816) am 3. März 2026 — rund 70 Seiten praktische Klarstellungen, offen für Stakeholder-Rückmeldungen bis zum 31. März 2026.
Für Hersteller relevante Klarstellungen:
- „Inverkehrbringen" schließt das Angebot von Software zum Download oder Fernzugriff ein — nicht nur physische Distribution
- Fernverarbeitungskomponenten, die für die Kernfunktion eines Produkts wesentlich sind, fallen in den Anwendungsbereich
- Support-Zeitraum: Definition und Zusammenspiel mit der Mindestpflicht von 5 Jahren Sicherheitsupdates
- Upstream-Reporting: Hersteller müssen nicht garantieren, dass ihr Fix vom Open-Source-Projekt akzeptiert wird
- Zusammenspiel mit anderen EU-Gesetzen: Leitlinien zum Verhältnis von CRA zu DSGVO, NIS2 und KI-Verordnung
Das endgültige Leitliniendokument wird nach Ende der Konsultationsfrist erwartet und wird vor dem September-2026-Stichtag die maßgebliche Auslegung liefern.
CRA-Zeitplan
| Datum | Meilenstein |
|---|---|
| 20. Nov. 2024 | Im Amtsblatt veröffentlicht |
| 10. Dez. 2024 | In Kraft getreten |
| 3. Mär. 2026 | Kommission veröffentlicht Leitlinien-Entwurf (Feedback bis 31. März 2026) |
| 11. Jun. 2026 | Bestimmungen für Konformitätsbewertungsstellen gelten; Mitgliedstaaten müssen Notifizierungsbehörden benannt haben |
| 11. Sep. 2026 | Schwachstellenmeldepflichten (Artikel 14) — auch für Bestandsprodukte auf dem Markt |
| 11. Dez. 2027 | Vollständige Anwendung — CE-Kennzeichnung, Konformitätsbewertung, technische Dokumentation |
Bußgelder und Sanktionen
| Verstoß | Höchststrafe |
|---|---|
| Wesentliche Cybersicherheitsanforderungen (Anhang I) | 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes |
| Sonstige CRA-Pflichten | 10 Mio. € oder 2 % des Umsatzes |
| Irreführende Angaben gegenüber Behörden | 5 Mio. € oder 1 % des Umsatzes |
Marktüberwachungsbehörden können zusätzlich:
- Produkte vom Markt nehmen lassen
- Korrekturmaßnahmen anordnen
- Marktverfügbarkeit einschränken oder verbieten
- Rückrufe anordnen
In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) als zuständige Behörde für die Marktüberwachung im Rahmen des CRA vorgesehen. Das BSI hat bereits umfangreiche Leitlinien zur CRA-Vorbereitung veröffentlicht und kann auf bestehende Expertise aus dem IT-Sicherheitsgesetz 2.0 zurückgreifen.
Vollständiger Compliance-Fahrplan bis Dezember 2027
Über die September-2026-Frist für Schwachstellenmeldungen hinaus benötigen Hersteller ein umfassendes Programm für die vollständige CRA-Compliance bis Dezember 2027:
Schritt 1: Betroffenheitsanalyse
Klären Sie, welche Ihrer Produkte unter den CRA fallen und in welche Kategorie (Standard, Klasse I wichtig, Klasse II wichtig oder kritisch). Bestimmen Sie die passende Konformitätsbewertungsroute.
Schritt 2: Gap-Analyse gegen Anhang I
Gleichen Sie Ihre aktuellen Produktsicherheitspraktiken mit allen 20 wesentlichen Anforderungen ab. Typische Lücken in CRA-Readiness-Assessments:
- Kein formales SBOM-Management-Prozess
- Schwachstellenbehandlungsfristen nicht mit CRA-Zeitvorgaben (24/72h/14 Tage) abgestimmt
- Kein sicherer Update-Mechanismus für ausgelieferte Produkte
- Keine veröffentlichte koordinierte Schwachstellenoffenlegungsrichtlinie
- Sicherheitstests ad-hoc statt systematisch
Schritt 3: Security-by-Design-Integration
Verankern Sie Sicherheitsanforderungen in Ihrem Produktentwicklungsprozess über alle Phasen (vgl. SDL-Abschnitt). Dies ist ein kultureller und prozessualer Wandel, nicht nur eine technische Maßnahme.
Schritt 4: Schwachstellenmanagement-Programm aufbauen
- Koordinierte Schwachstellenoffenlegungsrichtlinie auf der Website veröffentlichen
- SBOM-Generierung und -Pflege für jeden Produkt-Release
- CVE-Monitoring für den Abhängigkeitsgraphen
- 24/72h/14-Tage-Meldeprozess dokumentieren und einüben
Schritt 5: Technische Dokumentation
Erstellen Sie das vollständige technische Dossier für die CRA-Konformität:
- Produkt- und Designbeschreibung
- Sicherheitsanforderungen und deren Umsetzung
- Risikoanalyse
- Testergebnisse
- SBOM
- EU-Konformitätserklärung
Schritt 6: Konformitätsbewertung und CE-Kennzeichnung
Durchlaufen Sie das für Ihre Produktkategorie passende Konformitätsbewertungsverfahren und bringen Sie die CE-Kennzeichnung an.
Schritt 7: Kontinuierliche Lifecycle-Compliance
Der CRA schafft fortlaufende Pflichten — kein einmaliges Projekt:
- SBOM bei jedem Release aktualisieren
- Abhängigkeiten während des gesamten deklarierten Support-Zeitraums überwachen und patchen
- Technische Dokumentation aktuell halten
- Meldepflichten nach Artikel 14 fortlaufend erfüllen
Häufige Fragen zur CRA-Umsetzung
Gilt der CRA für SaaS-Produkte?
Reine SaaS-Dienste, die nicht als Komponente in ein Produkt integriert sind, fallen grundsätzlich nicht unter den CRA — dafür gibt es andere Regulierungen wie NIS2. Aber: Cloud-Dienste, die für die Kernfunktion eines physischen Produkts wesentlich sind (z.B. Cloud-Backend für ein IoT-Gerät), gelten als Teil des Produkts und müssen die CRA-Anforderungen für diesen Anteil erfüllen.
Faustregel: Wird Ihre Software als eigenständiges Produkt verkauft oder ist sie wesentlicher Bestandteil eines vernetzten Produkts, gilt der CRA. Wird sie rein als Dienst ohne Produkteinbindung betrieben, eher nicht.
Wie lange müssen Sicherheitsupdates bereitgestellt werden?
Der CRA fordert Sicherheitsupdates für die erwartete Produktlebensdauer, mindestens jedoch 5 Jahre ab dem letzten Inverkehrbringen des Produkts. Hersteller müssen:
- Den offiziellen Support-Zeitraum für jedes Produkt definieren
- Diesen klar an Kunden kommunizieren
- Ressourcen für Patch-Management über die gesamte Lebensdauer einplanen
Was passiert, wenn eine Schwachstelle in einer Open-Source-Abhängigkeit entdeckt wird?
Als Hersteller tragen Sie die Verantwortung — nicht der Open-Source-Autor. Sie müssen:
- Die betroffenen Produkte anhand Ihrer SBOM identifizieren
- Eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden an ENISA melden
- Innerhalb von 72 Stunden ein Update oder einen Workaround bereitstellen
- Nutzer informieren
CRA und andere EU-Regulierungen
| Regulierung | Verhältnis zum CRA |
|---|---|
| NIS2 | CRA betrifft Produktsicherheit; NIS2 betrifft organisatorische Sicherheit. CRA-konforme Produkte helfen NIS2-regulierten Betreibern bei der Erfüllung ihrer Lieferkettensicherheitspflichten. |
| DSGVO | CRA-Datenschutzanforderungen (Datenminimierung, Verschlüsselung, Zugangskontrolle) ergänzen die DSGVO auf Produktebene. |
| DORA | Im Finanzsektor tätige Unternehmen müssen sichere IKT-Produkte einsetzen — CRA-konforme Produkte reduzieren das DORA-IKT-Risiko. |
| KI-Verordnung (AI Act) | Hochrisiko-KI-Systeme als Produkte mit digitalen Elementen müssen sowohl CRA als auch KI-Verordnung einhalten. |
| MDR/IVDR | Medizinprodukte sind vom CRA ausgenommen (eigene Regulierung gilt). |
| Funkanlagen-Richtlinie (RED) | Der CRA wird die Cybersicherheits-Delegierten-Rechtsakte der RED für betroffene Produkte langfristig ablösen. |
Wie Orbiq bei der CRA-Compliance unterstützt
Die CRA-Compliance erzeugt umfangreiche Dokumentations- und Nachweispflichten über den gesamten Produktlebenszyklus. Orbiq unterstützt Hersteller bei der kontinuierlichen Verwaltung:
- Lieferketten-Dokumentation: Komponenten und Abhängigkeiten über Ihr gesamtes Produktportfolio verfolgen — die Grundlage für SBOM-Management
- Compliance-Nachweise: Sicherheitstests, Schwachstellenbewertungen und Konformitätsdokumentation zentral verwalten
- Trust Center: Produktsicherheitsstatus, CVD-Policy und Compliance-Status gegenüber Kunden und Marktüberwachungsbehörden darstellen
- Lieferantenmanagement: Sicherheitsstatus von Komponenten und Drittanbieter-Abhängigkeiten überwachen
- Kontinuierliches Monitoring: CRA-Pflichten mit automatisiertem Compliance-Tracking über das gesamte Produktportfolio erfüllen
Wenn Sie noch Plattformen vergleichen, erklärt unser Leitfaden zu Compliance-Automatisierungs-Software, welche Anbieter bei kontinuierlicher Nachweiserhebung, EU-Datenhaltung und operativen Compliance-Workflows am stärksten sind.
Weiterführende Artikel
- Cyber Resilience Act: Artikel 13 & 14 im Detail
- EU KI-Verordnung: Vollständiger Compliance-Leitfaden 2026 — KI-Anforderungen, die sich mit dem CRA für KI-gestützte Produkte überschneiden
- NIS2 Compliance Leitfaden — Organisatorische Sicherheitsanforderungen
- DORA Compliance Leitfaden — Anforderungen für den Finanzsektor
- NIS2-Richtlinie: Vollständiger Überblick — Gesetzgebungsrahmen und nationale Umsetzung
Quellen und Nachweise
- EU Cyber Resilience Act — Offizieller Text (Verordnung 2024/2847) — Amtsblatt der EU, 20. November 2024
- Kommissions-Leitlinien-Entwurf zum CRA — Ares(2026)2319816 — Europäische Kommission, 3. März 2026
- CRA-Meldepflichten — Offizielle Seite — Artikel 14, Single Reporting Platform
- CRA-Umsetzung — EC-Factsheet — Meilensteine und Zeitplan
- EU CRA: Key 2026 Milestones — Hogan Lovells
- CRA's Phased Entry into Application — Bird & Bird, 2026
- One Year Countdown to EU CRA Compliance — Keysight Technologies
- CRA Harmonized Standards — Keysight, Februar 2026
- CRA Open Source — Europäische Kommission
- DLA Piper CRA-Leitfaden — DLA Piper, Februar 2026
Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letzte Aktualisierung: März 2026.