Was kostet CRA-Compliance wirklich?
Von Redaktion codAIx | 17. August 2026
„Was kostet uns der CRA?“ ist die häufigste Frage — und die mit den meisten unseriösen Antworten. Eine nackte Gesamtzahl wie „90–180 Personentage“ klingt präzise, ist aber angreifbar, weil sie verschweigt, woraus sie sich zusammensetzt. Die ehrliche Antwort beginnt woanders: CRA-Compliance ist keine Aufgabe für eine einzelne Rolle. Sie verteilt sich über mehrere Funktionen — Entwicklung, Security, Produkt/Compliance, Recht —, die ein KMU oft gar nicht alle besetzt hat. Genau das macht den Aufwand hoch. Dieser Beitrag schlüsselt ihn pro Aufgabe und Rolle auf, nennt ein nachvollziehbares Referenzszenario und trennt sauber, was belegte Studienlage ist und was Erfahrungswert.
Eine bewusste Abgrenzung: Security by Design klammern wir aus
Bevor wir rechnen, eine Klarstellung: Dieser Beitrag beziffert nicht den Aufwand für Security by Design — also für die sichere Entwicklung des Produkts selbst nach den grundlegenden Anforderungen aus Anhang I Teil I CRA. Das ist kein Versäumnis, sondern Absicht. Wie sichere Entwicklung konkret aussieht und was sie kostet, hängt so stark von Architektur, Technologie-Stack, Codebasis und Reifegrad des einzelnen Produkts ab, dass jede pauschale Personentage-Angabe mehr verschleiern als erklären würde. Es gibt nicht die eine Art, sicher zu entwickeln — und damit auch nicht den einen Aufwand. Eine belastbare Zahl liesse sich hier nur produktspezifisch ermitteln, nicht seriös über alle Hersteller hinweg mitteln.
Dieser Artikel konzentriert sich deshalb auf die übertragbaren Compliance-Aufgaben — Klassifizierung, SBOM, Schwachstellen- und Meldeprozesse, technische Dokumentation und Konformitätsnachweis —, deren Aufwand sich sinnvoll in Bandbreiten fassen lässt. Die sichere Entwicklung verdient eine eigene, produktspezifische Betrachtung; sie pauschal in eine Tabelle zu pressen, wäre genau die Art unseriöser Vereinfachung, die wir hier vermeiden wollen.
Dem Thema widmen wir uns gesondert: Ab dem vierten Quartal 2026 sollen die in unserem Leistungsumfang enthaltenen Schulungsvideos Security by Design aufgreifen und dazu praktische Unterstützung bieten.
Eine kostenlose Praxishilfe für genau diese Lücke: das ENISA-Playbook
Wer sich in der Zwischenzeit orientieren möchte, findet seit Juli 2026 eine kostenlose Praxishilfe der EU-Agentur für Cybersicherheit: das ENISA „Secure by Design and Default Playbook“ (Version 1.0), das sich ausdrücklich an kleine und mittlere Unternehmen richtet, die Produkte mit digitalen Elementen herstellen. Als Zielgruppe nennt ENISA Entwicklerinnen und Entwickler, technische Produktverantwortliche, Sicherheitsverantwortliche in KMU und Systemarchitekten[5]. Sprachlich trennt ENISA dabei sauber zwischen secure by design — wie entwickelt wird — und secure by default — wie das Produkt beim Nutzer ankommt. Diese Zweiteilung ist präziser als der Sammelbegriff „Security by Design“ und liegt näher am Verordnungswortlaut: Der CRA verwendet den Begriff „Security by Design“ gar nicht, sondern spricht in Anhang I Teil I Nr. 2 lit. b von der „sicheren Standardkonfiguration“[1].
Inhaltlich enthält das Playbook 22 Prinzipien in vier Kategorien: architektonische Grundlagen (6), operative Integrität (8), Härtung der Standardkonfiguration (4) und geführter Schutz (4). Jedes Prinzip ist auf einer Seite mit einheitlichem Aufbau dargestellt — Zielsetzung, Checkliste, Mindestnachweise und Freigabekriterien. Letztere sind ausdrücklich als übernehmbare Bestanden/Nicht-bestanden-Kriterien für ein Release-Review oder eine CI/CD-Pipeline gedacht. Als Einstiegs-Baseline empfiehlt ENISA die Playbooks zu sicherer Programmierung, Protokollierung und Überwachung, Schwachstellen- und Patch-Management sowie Lieferkettenkontrollen, ergänzt um die produktabhängig einschlägigen weiteren Prinzipien. In einem Anhang ordnet ENISA die Prinzipien den grundlegenden Anforderungen des Anhang I CRA zu, bezeichnet dieses Mapping aber an mehreren Stellen selbst als „indicative“, also lediglich als Orientierung[5].
Ebenso wichtig ist, was das Playbook nicht leistet. Es ist unverbindlich. ENISA stellt selbst klar, dass es keine Rechtsberatung darstellt, dass es eine einführende Orientierung und kein umfassendes Compliance-Handbuch ist und dass die Befolgung der Prinzipien weder eine Zertifizierung nach bestimmten internationalen Normen noch die Einhaltung regulatorischer Vorgaben sicherstellt. Zu harmonisierten Normen oder zur Konformitätsvermutung nach Art. 27 CRA äussert es sich an keiner Stelle. Und es enthält keine Aufwands- oder Kostenzahlen — im Gegenteil: Es bestätigt die Begründung dieses Abschnitts, denn es bietet selbst nur eine risikobasierte, produktabhängige Priorisierung statt einer pauschalen Aufwandsangabe.
Warum „eine Zahl“ in die Irre führt
Wer CRA-Compliance auf eine einzige Kennzahl verdichtet, unterschlägt das Eigentliche: Die Pflichten greifen an verschiedenen Stellen des Unternehmens und verlangen unterschiedliche Kompetenzen. Eine Software-Bill-of-Materials (SBOM) wird nicht zwingend von derselben Person aufgebaut, die den Meldeprozess gegenüber der Behörde aufsetzt; auch die technische Dokumentation nach Anhang VII wird nicht zwingend von der Person erstellt, die die rechtliche Haftungsfrage abschliessend bewertet. In einem Grosskonzern sind diese Rollen vorhanden und eingespielt. In einem KMU mit zehn oder dreissig Mitarbeitenden liegen sie häufig bei ein, zwei Personen — oder sind gar nicht besetzt und müssen extern zugekauft werden. Genau hier entsteht der reale Aufwand. Die eierlegende Wollmilchsau (hier in Form einer einzigen Kennzahl) gibt es nicht und genau deshalb ist in unseren Augen die ehrlichste Darstellung eine, die pro Verantwortlichkeit die zuständige Rolle ausweist und deren Kennzahlen aufschlüsselt.
Die Rollen, über die sich CRA-Compliance verteilt
Vier Funktionen tragen den Kern der CRA-Pflichten — bei höheren Risikoklassen kommen zwei weitere hinzu:
Entwicklung / Engineering verantwortet die technische Substanz: Aufbau und Pflege der SBOM, sichere Update-Mechanismen und das Beheben von Schwachstellen im Code (Anhang I CRA).
Security / AppSec verantwortet den laufenden Schutz: Schwachstellen-Monitoring, einen Prozess zur koordinierten Offenlegung (Coordinated Vulnerability Disclosure, CVD), Incident Response und die Meldungen an die Behörden nach Art. 14 CRA.
Produkt / Compliance verantwortet den regulatorischen Nachweis: Klassifizierung und Scoping des Produkts, die technische Dokumentation nach Anhang VII, die Konformitätsbewertung sowie CE-Kennzeichnung und EU-Konformitätserklärung (DoC).
Recht verantwortet die finale rechtliche Bewertung und die Haftungsfragen — eine Funktion, die KMU häufig extern einkaufen.
Bei Produkten höherer Risikoklassen (wichtige Produkte der Klasse II, kritische Produkte) treten hinzu: Qualitätsmanagement / Management für ein Qualitätsmanagementsystem nach dem einschlägigen Konformitätsbewertungsmodul und eine notifizierte Stelle als externe Prüfinstanz. Diese Konstellation treibt Aufwand und Kosten deutlich nach oben — sie betrifft aber nur eine Minderheit der Produkte (siehe unten). Welche Module wann greifen, haben wir in der CRA-Konformitätsbewertung dargestellt.
Methodik: Wie wir Aufwand seriös schätzen
Damit eine Aufwandsdarstellung belastbar ist, folgen wir fünf Prinzipien:
1. Pro Aufgabe statt pro Gesamtzahl. Jede Aufgabe wird einzeln ausgewiesen — mit der typischerweise zuständigen Rolle. Eine konkrete und nachvollziehbare Aufschlüsselung ist einer pauschalen Summe vorzuziehen.
2. Mit Referenzszenario. Ohne Bezugspunkt ist jede Zahl angreifbar. Wir rechnen durchgehend für ein definiertes Szenario (siehe nächster Abschnitt). Wer mehr Produkte, höhere Risikoklassen oder einen geringeren Reifegrad hat, muss nach oben skalieren.
3. Einmaligen und laufenden Aufwand trennen. Klassifizierung und Erst-Dokumentation sind einmalig; SBOM-Pflege, Schwachstellen-Monitoring und Meldebereitschaft sind dauerhaft. Beides in einen Topf zu werfen, verzerrt das Bild.
4. Bandbreiten statt Punktwerte, immer mit Caveat. Jede Zahl ist eine unverbindliche Orientierung, kein garantiertes Ergebnis. Der tatsächliche Aufwand hängt vom Einzelfall ab.
5. Quellen sauber getrennt. Unabhängige Studien belegen, dass der CRA-Aufwand erheblich ist — sie belegen nicht unsere konkreten Personentage. Unsere Tageswerte sind ausdrücklich eigene Projekterfahrung und als solche gekennzeichnet.
Das Referenzszenario
Alle nachfolgenden Werte beziehen sich auf: ein Produkt, mittlerer Reifegrad, KMU, Erstimplementierung, Standard-Selbstbewertung (Modul A nach Anhang VIII CRA — interne Kontrolle ohne notifizierte Stelle). Dieses Szenario ist nicht beliebig gewählt: Nach einer Schätzung der EU-Kommission aus dem Gesetzgebungsverfahren fallen rund 90 % der Produkte mit digitalen Elementen in die Standardkategorie, für die der Hersteller selbst bewertet, die EU-Konformitätserklärung ausstellt und die technische Dokumentation erstellt[2]. Das Referenzszenario bildet also den häufigsten Fall ab; höhere Risikoklassen mit notifizierter Stelle liegen darüber.
Einmaliger Aufwand pro Aufgabe und Rolle
Die folgenden Bandbreiten sind eigene Projekterfahrung für das genannte Referenzszenario — eine illustrative Orientierung, kein garantiertes Ergebnis. Die Spalte „mit crAIready“ beschreibt das Aufwandspotenzial, wenn wiederkehrende Arbeit plattformgestützt gebündelt wird; sie ist ebenfalls ein Erfahrungswert, keine Zusage.
Angaben in Personentagen (PT) — illustrative Erfahrungswerte für das Referenzszenario, keine garantierten Werte.
| Aufgabe | Typische Rolle | Selbst | Mit crAIready | |:---|:---|---:|---:| | Klassifizierung & Scoping | Produkt/Compliance (+ Recht) | 5–15 | 1–2 | | SBOM aufbauen | Engineering | 10–25 | 1–3 | | Schwachstellen-/CVD-Prozess aufsetzen | Security | 15–35 | 2–5 | | Technische Dokumentation (Anhang VII) | Produkt/Compliance | 20–40 | 3–6 | | Konformitätsbewertung, DoC, CE | Compliance/QMS | 10–25 | 2–5 | | Meldeprozess (24 h / 72 h / 14 Tage) aufsetzen | Security/Recht | 10–20 | 2–4 | | Summe | | 70–160 | 11–25 |
In Summe ergibt das für die Erstimplementierung grob rund 70–160 Personentage in Eigenleistung gegenüber rund 11–25 Personentagen plattformgestützt — eine Grössenordnung, die zu den in der Praxis kursierenden Gesamtschätzungen passt, hier aber nachvollziehbar aus den Einzelaufgaben hergeleitet ist. Der Meldeprozess folgt den gestuften Fristen des Art. 14 CRA — 24 h / 72 h / 14 Tage (bei schwerwiegenden Sicherheitsvorfällen: Abschlussbericht nach einem Monat; Art. 14 Abs. 2 lit. c bzw. Abs. 4 lit. c CRA) — Details dazu in Artikel 8 dieser Serie.
Laufender Aufwand
Mit dem Inverkehrbringen ist es nicht getan: Der CRA verlangt Pflege über den gesamten Unterstützungszeitraum (mindestens fünf Jahre, Art. 13 Abs. 8 CRA). SBOM-Aktualisierung, Schwachstellen-Monitoring, Bereitstellung sicherer Updates und Meldebereitschaft laufen dauerhaft weiter.
| Laufender Betrieb (pro Jahr) | Typische Rolle | Selbst | Mit crAIready | |:---|:---|---:|---:| | Monitoring, SBOM-Pflege, Update- & Meldebereitschaft | Security/Engineering | 20–40 / Jahr | 3–8 / Jahr |
Auch diese Werte sind eigene Projekterfahrung für das Referenzszenario und skalieren mit Produktanzahl und Risikoklasse.
Was die Studien belegen — und was nicht
Die Grössenordnung „erheblich“ ist unabhängig belegt; die konkreten Personentage oben sind es nicht. Diese Trennung ist uns wichtig.
Die EU-Kommission beziffert in ihrer Folgenabschätzung die Compliance-Kosten für Hersteller EU-weit auf rund 29 Mrd. Euro — nach Einschätzung der Kommission gering im Vergleich zu den volkswirtschaftlichen Kosten von Cybervorfällen, die der CRA senken soll[2]. Das ist eine Makro-Zahl über den gesamten Binnenmarkt, kein Wert pro Unternehmen — sie belegt nur, dass der Gesamtaufwand substanziell ist.
Die Studie des Instituts der deutschen Wirtschaft (IW Köln) von Engels, Lang und Scheufen (November 2025) kommt für KMU zu einem klaren Befund: Die neuen Rechtsakte — AI Act, NIS-2 und CRA — sind mit „erheblichen Compliance-Kosten“ verbunden, die Wettbewerbs- und Innovationsfähigkeit kleinerer Unternehmen kurzfristig belasten können; die grössten Hürden sind komplexe Anforderungen, Rechtsunsicherheit, Fachkräftemangel bei Security- und Compliance-Expertise sowie begrenzte Ressourcen. Eine vollständige CRA-Umsetzung veranschlagt die Studie je nach Reifegrad auf mindestens 12 bis 18 Monate[3]. Das deckt sich mit dem Kern unserer Darstellung: Der Aufwand ist weniger eine Frage einzelner Tage als der fehlenden Rollen, die ein KMU erst aufbauen oder zukaufen muss.
Beide Quellen stützen also die Aussage „CRA-Aufwand ist erheblich“. Keine von ihnen belegt eine konkrete Personentage-Angabe — solche Werte stammen aus Projekterfahrung und sind hier ausdrücklich so gekennzeichnet.
Was den Aufwand nach oben oder unten treibt
Drei Faktoren bestimmen, wo ein Unternehmen innerhalb (oder oberhalb) der Bandbreiten landet:
Produktanzahl. Die Werte gelten für ein Produkt. Mehrere Produkte vervielfachen vor allem die Dokumentations- und Bewertungsarbeit — wobei wiederverwendbare Bausteine (gemeinsame Komponenten, Vorlagen) den Grenzaufwand senken.
Risikoklasse. Das Referenzszenario nutzt die Selbstbewertung (Modul A). Wichtige Produkte der Klasse II und kritische Produkte erfordern die Einbindung einer notifizierten Stelle und in der Regel ein Qualitätsmanagementsystem — das hebt Aufwand, Dauer und externe Kosten deutlich an. Wie dauerhaft dieser Aufwand ist, macht die Technische Richtlinie BSI TR-03183-H zu Modul H deutlich: Für Qualitätssysteme ist im Regelfall alle drei Jahre eine Rezertifizierung mit vollem mehrstufigem Audit vorgesehen, dazu jährliche Überwachungsaudits. Änderungen am Qualitätssystem sind der notifizierten Stelle vorab anzuzeigen und können eine Neubewertung auslösen — insbesondere dann, wenn der Geltungsbereich auf zusätzliche Produktkategorien erweitert wird[6]. Modul-H-Kosten sind also keine Einmalgrösse, sondern ein Mehrjahresbudget.
Reifegrad. Wer bereits ein gelebtes Schwachstellenmanagement, eine gepflegte SBOM und dokumentierte Prozesse hat, startet weit oben auf der Lernkurve. Ein niedriger Ausgangsreifegrad ist der grösste einzelne Kostentreiber.
Öffentliche Unterstützung existiert: Das EU-Projekt SECURE etwa fördert KMU bei der CRA-Umsetzung[4] — ein Hinweis darauf, dass der Gesetzgeber den Aufwand für kleinere Unternehmen selbst als hoch einschätzt. Kostenfreie fachliche Orientierung liefert daneben das oben genannte ENISA-Playbook[5]; es senkt den Einarbeitungsaufwand, ersetzt aber keine Konformitätsbewertung.
Der eigentliche Hebel: Arbeit bündeln, die sonst über vier Funktionen läuft
Der teure Teil der CRA-Compliance ist nicht eine einzelne schwierige Aufgabe — es ist die Koordination über vier bis sechs Rollen hinweg, die in vielen KMU nicht vollständig vorhanden sind. Genau hier setzt der Nutzen einer Plattform an: Wenn Klassifizierung, SBOM, Schwachstellen-Monitoring, technische Dokumentation, Konformitätsnachweis und Meldebereitschaft in einem System zusammenlaufen, sinkt nicht nur der Aufwand pro Aufgabe, sondern vor allem der Koordinationsaufwand zwischen den Funktionen — der in der Praxis oft den grössten Teil ausmacht. Insbesondere wenn Kompetenzen extern zugekauft werden müssen, entsteht unserer Erfahrung nach häufig ein grosses Problem: Bei der gemeinsamen Lösungserarbeitung mit Externen ist Fingerspitzengefühl gefragt, weil sowohl das Verständnis für die jeweils andere Rolle als auch die Kenntnis der konkreten Abläufe im Unternehmen fehlen können. Das kann schnell zu mehr Aufwand und im schlimmsten Fall zu Missverständnissen und Fehlern führen. IT und Recht arbeiten häufig voneinander abgeschottet — in zwei Räumen oder sogar in zwei verschiedenen Unternehmen —, haben unterschiedliche Sicht- und Herangehensweisen und verfügen nicht über dieselben Einblicke. Hier muss sorgfältig darauf geachtet werden, dass keine Lücken entstehen. Aus dieser Erfahrung heraus arbeiten bei uns Entwicklung, Recht, Produkt und Security als Legal-Tech-Team besonders eng zusammen, um ein auf allen Seiten abgestimmtes Produkt anbieten zu können.
crAIready bündelt, was sonst über vier Funktionen läuft
crAIready ist die KI-gestützte SaaS-Plattform, die CRA-Arbeit zusammenführt, die sonst über Engineering, Security, Produkt/Compliance und Recht verteilt ist:
- Klassifizierung & Scoping → CRA-Navigator (Modul 1): KI-gestützte Klassifizierung und Empfehlung des Konformitätsverfahrens — die verbindliche Einordnung bleibt beim Hersteller.
- SBOM & Schwachstellen-/CVD-Prozess → Module 2 und 3: automatische Stückliste, laufendes Monitoring der einschlägigen Schwachstellendatenbanken und einbettbare CVD-Annahmestelle.
- Technische Dokumentation & Konformitätsnachweis → Modul 4: Anhang VII, EU-Konformitätserklärung als Entwurf und Behörden-Dossier — auditfest und versioniert.
- Meldeprozess → Modul 5: geführter 24-h-/72-h-/14-Tage-Workflow mit CSAF-konformem Export.
Der Einstieg ist unser kostenloser CRA Quick-Check: eine erste, belastbare Orientierung zu Umfang und Aufwand Ihrer CRA-Pflichten — ohne Beratungsabhängigkeit. Die genannten Aufwände sind unverbindliche Erfahrungswerte; die verbindliche Beurteilung Ihres Einzelfalls bleibt Ihnen vorbehalten.
Methodik dieser Recherche
Versionshinweis (v15, 12.08.2026): Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 17.08.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.
Die rechtlichen Bezüge sind gegen die Verordnung (EU) 2024/2847 (Cyber Resilience Act) geprüft (Art. 13, Art. 14, Anhang I Teil I, Anhang VII, Anhang VIII). Die Makro-Kostenaussagen stammen aus der Folgenabschätzung der EU-Kommission und aus der Studie des IW Köln (Engels/Lang/Scheufen, November 2025); sie belegen die Grössenordnung „erheblich“, nicht die in diesem Beitrag genannten Personentage. Die Angaben zum ENISA „Secure by Design and Default Playbook“ (Juli 2026, Version 1.0) und zur Technischen Richtlinie BSI TR-03183-H (Version 1.1.0 vom 30.05.2026) sind unmittelbar am jeweiligen Dokument geprüft; beide sind unverbindliche technische Praxishilfen ohne rechtsverbindliche Wirkung. Die Aufwands-Bandbreiten in Personentagen sind eigene Projekterfahrung von codAIx für das definierte Referenzszenario, ausdrücklich unverbindlich und kein garantiertes Ergebnis. Stand: 06.08.2026 (v14 — Wording-Korrektur im Plattform-Abschnitt: Das Schwachstellen-Monitoring wird nicht mehr als „tägliches Monitoring“ beschrieben, sondern als laufendes Monitoring ohne Angabe eines konkreten Intervalls. Der übrige Beitrag wurde auf weitere Intervallangaben durchgesehen; die genannten Zyklen im Abschnitt „Risikoklasse“ beziehen sich auf die Audit- und Rezertifizierungsvorgaben der BSI TR-03183-H und bleiben unverändert. v13 — neuer Unterabschnitt zum ENISA „Secure by Design and Default Playbook“ in der bewussten Abgrenzung: Zielgruppe KMU, Trennung von secure by design und secure by default, 22 Prinzipien in vier Kategorien (6/8/4/4), einheitlicher Seitenaufbau mit Zielsetzung, Checkliste, Mindestnachweisen und Freigabekriterien für Release-Review bzw. CI/CD, empfohlene Einstiegs-Baseline sowie die von ENISA selbst als „indicative“ bezeichnete Zuordnung zu Anhang I CRA; ausdrücklicher Hinweis auf die Unverbindlichkeit — keine Rechtsberatung, kein Compliance-Handbuch, keine Zertifizierungs- oder Konformitätswirkung, keine Aussage zu harmonisierten Normen oder zur Konformitätsvermutung nach Art. 27 CRA; keine Aufwands- oder Kostenzahlen übernommen, da das Playbook keine enthält. Abschnitt „Risikoklasse“ um die Modul-H-Zyklen aus BSI TR-03183-H Anhang B.2 ergänzt (Rezertifizierung mit vollem mehrstufigem Audit alle drei Jahre, jährliche Überwachungsaudits, Anzeigepflicht bei Änderungen am Qualitätssystem mit möglicher Neubewertung, insbesondere bei Erweiterung des Geltungsbereichs). Quellenverzeichnis um [5] ENISA und [6] BSI TR-03183-H erweitert; Stand- und Prüfdatum aktualisiert). Vorherige Fassung (v12, Stand 29.06.2026): Aufwandsdarstellung pro Aufgabe und Rolle, Referenzszenario, Trennung von Studienlage und Projekterfahrung.
Quellen
[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 13 Abs. 8, Art. 14, Anhang I Teil I Nr. 2 lit. b (sichere Standardkonfiguration), Anhang VII (technische Dokumentation), Anhang VIII (Konformitätsbewertungsverfahren).
[2] Europäische Kommission — Cyber Resilience Act, Impact Assessment / Folgenabschätzung (2022) und Summary of the legislative text — Compliance-Kosten der Hersteller EU-weit rund 29 Mrd. Euro. Die Schätzung, dass rund 90 % der Produkte in die Standardkategorie mit Selbstbewertung fallen, stammt aus dem Gesetzgebungsverfahren: Europäische Kommission, Fragen und Antworten zum Cyber Resilience Act (QANDA/22/5375, September 2022) zum Vorschlag COM(2022) 454 final. Ergänzend: The Cyber Resilience Act – Summary of the legislative text.
[3] Engels, B. / Lang, T. / Scheufen, M. — KI-Verordnung, NIS-2-Richtlinie und Cyber Resilience Act: Auswirkungen auf KMU, Institut der deutschen Wirtschaft (IW Köln), November 2025 — erhebliche Compliance-Kosten für KMU; vollständige CRA-Umsetzung je nach Reifegrad mindestens 12–18 Monate.
[5] ENISA, „Secure by Design and Default Playbook — A Practical Guide to Secure by Design and Default Principles for SMEs“, Juli 2026, Version 1.0. Unverbindliche technische Praxishilfe; nach eigener Angabe keine Rechtsberatung, sondern einführende Orientierung und kein umfassendes Compliance-Handbuch; die Befolgung der Prinzipien stellt weder eine Zertifizierung nach bestimmten internationalen Normen noch die Einhaltung regulatorischer Vorgaben sicher. Das Dokument nennt als Datum lediglich „Juli 2026“; ein genaues Veröffentlichungsdatum ist daraus nicht belegbar. Verfügbar über enisa.europa.eu.
[6] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie BSI TR-03183-H: „Cyber Resilience Requirements for Manufacturers and Products: Conformity based on full quality assurance (Module H)“, Version 1.1.0 vom 30.05.2026, hier Anhang B.2 (Rezertifizierungs- und Überwachungszyklen, Anzeigepflicht bei Änderungen am Qualitätssystem). Verfügbar unter: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-H_v1_1_0.html?nn=1106058
Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Die genannten Aufwände in Personentagen sind unverbindliche Erfahrungswerte für ein definiertes Referenzszenario und kein garantiertes Ergebnis; der tatsächliche Aufwand hängt vom Einzelfall ab (Produktanzahl, Risikoklasse, Reifegrad). Die zitierten Studien belegen die Grössenordnung des CRA-Aufwands, nicht die hier genannten Tageswerte. Die genannten Praxishilfen von ENISA und BSI sind unverbindlich und ersetzen keine Konformitätsbewertung. Stand: 06.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).
Damit endet diese Serie vorerst. Den Einstieg in alle Themen finden Sie in Teil 0: Zweck und Anwendungsbereich des CRA.
Veröffentlicht am: 17.08.2026 | Zuletzt geprüft am: 13.08.2026
Stand: 13.08.2026 (v16 — freigegebene Schlusskorrektur: zwei unvollständige Absätze neu gefasst; Grammatik, Vergleichssatz, Aufwandstabelle und Meldefrist sprachlich korrigiert; „KI-gestützt“ vereinheitlicht. Vorherige Fassung: v15; zeitabhängige Formulierungen unverändert.)