Von Redaktion codAIx | 17. August 2026

„Was kostet uns der CRA?“ gehört zu den häufigsten Fragen — und zu denen mit den meisten vorschnellen Antworten. Eine pauschale Gesamtzahl klingt präzise, lässt aber nicht erkennen, woraus sie sich zusammensetzt. CRA-Compliance verteilt sich über mehrere Funktionen — Entwicklung, Security, Produkt/Compliance und 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 Referenzszenario und trennt, was Studienlage, was Erfahrungswert und was Planwert ist.

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, Software-Stückliste (englisch software bill of materials, SBOM; dazu Teil 7), 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.

Ergänzende Inhalte zu Secure by Design und Secure by Default können diese produktspezifische Betrachtung unterstützen, ersetzen sie aber nicht. Wie KI-gestützte Angriffe Risikobewertung, Tests und Schwachstellenbehandlung verändern, behandelt Teil 15 dieser Serie.

Eine kostenlose Praxishilfe für genau diese Lücke: das ENISA-Playbook

Wer sich 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“ nicht. Der Sache nach verlangt er in Anhang I Teil I Nr. 1, Produkte so zu konzipieren, zu entwickeln und herzustellen, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten (secure by design), und in Nr. 2 lit. b eine „sichere Standardkonfiguration“ (secure by default)[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 Einstieg empfiehlt ENISA die Prinzipien 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; es priorisiert risikobasiert und produktabhängig — und stützt damit den Ansatz dieses Abschnitts.

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 SBOM wird nicht zwingend von derselben Person aufgebaut, die den Meldeprozess zum koordinierenden CSIRT und zur ENISA über die einheitliche Meldeplattform 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. Eine einzige Kennzahl, die all das abbildet, gibt es nicht. Ehrlicher ist eine Darstellung, die je Aufgabe die zuständige Rolle und den Aufwand ausweist.

Die Rollen, über die sich CRA-Compliance verteilt

Vier Funktionen tragen den Kern der CRA-Pflichten — bei wichtigen und kritischen Produkten 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 nach Art. 14 CRA an das als Koordinator benannte CSIRT und die ENISA über die einheitliche Meldeplattform.

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.

Wichtige Produkte der Klasse I brauchen eine Bewertung nach Modul B+C oder Modul H, wenn der Hersteller harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema (mindestens Vertrauenswürdigkeitsstufe „mittel“) nicht oder nur teilweise anwendet oder solche nicht vorhanden sind (Art. 32 Abs. 2 CRA); für Klasse II gilt das stets, sofern kein europäisches Zertifizierungsschema genutzt wird (Art. 32 Abs. 3 CRA). Weil am 11. Oktober 2026 keine CRA-harmonisierten Normen im Amtsblatt veröffentlicht und die delegierten Rechtsakte nach Art. 27 Abs. 9 CRA nicht erlassen waren, betrifft das derzeit praktisch alle wichtigen Produkte; ausgenommen ist quelloffene Software mit öffentlich zugänglicher technischer Dokumentation (Art. 32 Abs. 5 CRA). In beiden Modulen ist eine notifizierte Stelle beteiligt: bei B+C für die EU-Baumusterprüfung, bei H für Bewertung und Überwachung des Qualitätssicherungssystems, das der Hersteller dafür zusätzlich aufbauen muss. Kritische Produkte unterliegen Art. 8 und Art. 32 Abs. 4 CRA. 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, wichtige oder kritische Produkte 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. Die Folgenabschätzung der Kommission und eine Kurzstudie des IW belegen, dass der CRA-Aufwand erheblich sein kann; sie belegen nicht unsere konkreten Personentage. Unsere Tageswerte für die Eigenleistung beruhen auf eigener Projekterfahrung; die Werte mit crAIready, der CRA-Compliance-Plattform der Herausgeberin codAIx GmbH, sind Planwerte. Beides ist ausdrücklich so 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). Im Vorschlagsstadium 2022 wurde geschätzt, dass etwa 90 % der Produkte mit digitalen Elementen in die damalige Standardkategorie fallen würden; so gibt es die BSI TR-03183-1 (Kap. 3.8.1) unter Verweis auf ein Briefing des Wissenschaftlichen Dienstes des Europäischen Parlaments von 2022 wieder[7]. Diese historische Schätzung ist keine aktuelle Marktverteilung unter der endgültigen Verordnung. Das Referenzszenario dient deshalb nur als nachvollziehbarer Rechenfall; die tatsächliche Modulwahl ist für jedes Produkt nach Art. 32 CRA zu prüfen.

Der Koordinationsaufwand zwischen den Funktionen ist in der folgenden Kalkulation innerhalb der ausgewiesenen Arbeitspakete berücksichtigt.

Einmaliger Aufwand pro Aufgabe und Rolle

Die folgenden Bandbreiten für die Eigenleistung sind eigene Projekterfahrung für das genannte Referenzszenario — eine illustrative Orientierung, kein garantiertes Ergebnis. Der Wert „mit crAIready“ ist ein Planwert: die Zielgrösse für den verbleibenden Eigenaufwand bei der Erstimplementierung, auf die wir die Plattform auslegen. Er beruht auf einer internen Ablaufanalyse und ist keine Zusage. crAIready erstellt die SBOM auf Wunsch automatisch aus dem Code (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs; Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, werden manuell erfasst. Der Planwert gilt für den Fall, dass crAIready die SBOM aus Ihrem Code erstellt.

Angaben in Personentagen (PT) für die Eigenleistung je Aufgabe im Referenzszenario. Der Gesamtwert mit crAIready ist ein Planwert.

| Aufgabe | Typische Rolle | Selbst | |:---|:---|---:| | Klassifizierung & Scoping | Produkt/Compliance (+ Recht) | 5–15 | | SBOM erstellen und für Verwaltung, Abgleich und Due Diligence aufbereiten | Engineering | 10–25 | | Schwachstellen-/CVD-Prozess aufsetzen | Security | 15–35 | | Technische Dokumentation (Anhang VII) | Produkt/Compliance | 20–40 | | Konformitätsbewertung, DoC, CE | Compliance/QMS | 10–25 | | Meldeprozess (24 h / 72 h sowie Abschlussberichte) aufsetzen | Security/Recht | 10–20 | | Summe in Eigenleistung | | 70–160 |

Mit crAIready (Planwert, Erstimplementierung bei SBOM-Erstellung durch crAIready aus dem Code): 5–15 PT

In Summe ergibt das für die Erstimplementierung grob rund 70–160 Personentage in Eigenleistung. Für dieselben Arbeitspakete liegt unser Planwert bei plattformgestützter Arbeit bei rund 5–15 Personentagen, sofern crAIready die SBOM aus dem Code erstellt; wird die SBOM ohne Anbindung des Codes selbst erstellt, kommt der Eigenaufwand der SBOM-Zeile (10–25 PT) hinzu. Die Personentage beziffern ausschliesslich den internen Personalaufwand. Der Meldeprozess folgt den gestuften Fristen des Art. 14 CRA: Bei aktiv ausgenutzten Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmassnahme fällig (Art. 14 Abs. 2 lit. c); bei schwerwiegenden Sicherheitsvorfällen ist der Abschlussbericht innerhalb eines Monats nach Übermittlung der 72-Stunden-Meldung nach Art. 14 Abs. 4 lit. b fällig (Art. 14 Abs. 4 lit. c). Details behandelt Teil 8 dieser Serie.

Laufender Aufwand

Mit dem Inverkehrbringen ist es nicht getan: Der CRA verlangt Pflege über den gesamten Unterstützungszeitraum. Dieser beträgt grundsätzlich mindestens fünf Jahre; ist die voraussichtliche Nutzungsdauer kürzer, muss der Unterstützungszeitraum entsprechend kürzer festgelegt werden (Art. 13 Abs. 8 CRA). Ein Regelwert für alle Produkte sind fünf Jahre nach der Kommissionsleitlinie nicht (Rn. 126)[8]. SBOM-Aktualisierung, Schwachstellen-Monitoring, Bereitstellung sicherer Updates und Meldebereitschaft laufen während dieses Zeitraums weiter.

| Laufender Betrieb (pro Jahr) | Typische Rolle | Selbst | Mit crAIready (Planwert) | |:---|:---|---:|---:| | Monitoring, SBOM-Pflege, Update- und Meldebereitschaft | Security/Engineering | 20–40 / Jahr | 3–8 / Jahr |

Auch hier beruhen die Werte für die Eigenleistung auf eigener Projekterfahrung, die Werte mit crAIready sind Planwerte auf Grundlage derselben internen Ablaufanalyse; beide gelten für das Referenzszenario und skalieren mit Produktanzahl und Produktklasse. Der Planwert mit crAIready umfasst nicht die Entwicklung und Auslieferung von Sicherheitsupdates; diese bleiben vollständig beim Hersteller.

Was die Studien belegen — und was nicht

Dass der Aufwand erheblich sein kann, ist belegt; die konkreten Personentage oben sind es nicht. Diese Trennung ist uns wichtig.

Die EU-Kommission schätzte im Gesetzgebungsverfahren die aggregierten Befolgungskosten für Software- und Hardwarehersteller auf bis zu rund 29 Mrd. Euro bei einem geschätzten Marktvolumen von 1.485 Mrd. Euro. Sie stellte dem eine mögliche Senkung vorfallsbedingter Kosten der Unternehmen um rund 180 bis 290 Mrd. Euro jährlich gegenüber[2]. Das sind Makro-Zahlen über den Binnenmarkt, keine Werte pro Unternehmen.

Die Kurzstudie des Instituts der deutschen Wirtschaft (IW Köln/IW Consult) von Engels, Lang und Scheufen vom 13. November 2025 hält für KMU fest, dass den Vorteilen von AI Act, NIS-2 und CRA „teils erhebliche Compliance-Kosten“ gegenüberstehen, die kurzfristig die Wettbewerbs- und Innovationsfähigkeit kleinerer Unternehmen belasten können; langfristig dürften die Vorteile nach Einschätzung der Autoren überwiegen[3]. Als Hürden nennt die Studie komplexe Anforderungen, Rechtsunsicherheit, Fachkräftemangel bei Security- und Compliance-Expertise sowie begrenzte Ressourcen.

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.

Produktklasse. Das Referenzszenario nutzt die Selbstbewertung (Modul A). Für wichtige und kritische Produkte gilt das oben im Abschnitt zu den Rollen Gesagte. Wie dauerhaft der Aufwand unter Modul H ist, macht die Technische Richtlinie BSI TR-03183-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-finanzierte Projekt SECURE fördert KMU bei der CRA-Umsetzung mit rund 16 Mio. Euro direkter Unterstützung[4]; der Unionsgesetzgeber selbst hat in Art. 33 CRA Unterstützungsmassnahmen für Kleinst- und Kleinunternehmen vorgesehen. Kostenfreie fachliche Orientierung liefert daneben das oben genannte ENISA-Playbook[5]; es senkt den Einarbeitungsaufwand, ersetzt aber keine Konformitätsbewertung.

Schnittstellen: Wo zwischen Technik und Recht Aufwand entsteht

Eine Plattform kann wiederkehrende Arbeitsschritte strukturieren und bündeln; wie stark sich der Aufwand im Einzelfall reduziert, hängt von Ausgangslage, Produkt und Produktklasse ab.

Besonders aufwendig wird es, wenn Kompetenzen extern zugekauft werden. Bei der gemeinsamen Lösungserarbeitung mit Externen ist Fingerspitzengefühl gefragt: Externe kennen die Abläufe im Unternehmen nicht, und IT und Recht arbeiten oft getrennt — in verschiedenen Abteilungen oder sogar in verschiedenen Unternehmen, mit unterschiedlicher Sprache und Perspektive. Missverständnisse an dieser Schnittstelle kosten Zeit und können zu Lücken in der Dokumentation führen. Bei codAIx arbeiten Entwicklung, Recht, Produkt und Security deshalb als gemeinsames Legal-Tech-Team.

Das Wichtigste für Hersteller

  • Für ein Produkt mittleren Reifegrads im Referenzszenario (Modul A) rechnen wir mit rund 70–160 Personentagen Eigenleistung für die Erstimplementierung und rund 20–40 Personentagen pro Jahr im laufenden Betrieb – eigene Projekterfahrung, kein garantiertes Ergebnis.
  • Über einen Unterstützungszeitraum von fünf Jahren übersteigt der laufende Aufwand damit in der Regel den einmaligen; CRA-Compliance lässt sich nicht als Einmalprojekt planen.
  • Kosten sind kein Massstab für die Risikobehandlung: Nach der Kommissionsleitlinie sind interne Risikotoleranz, Geschäftsstrategie oder blosse Kostenüberlegungen für die Frage, ob Risiken ausreichend behandelt sind, nicht massgeblich (Rn. 158)[8].
  • Nicht enthalten sind die sichere Entwicklung selbst (Security by Design) und die Kosten einer notifizierten Stelle, die im Referenzszenario (Modul A) nicht beteiligt ist.
  • Solange keine CRA-harmonisierten Normen veröffentlicht sind, brauchen wichtige Produkte praktisch durchweg eine Bewertung nach Modul B+C oder H (Ausnahme: Art. 32 Abs. 5 CRA); Modul H ist ein Mehrjahresbudget.
  • Wer die Personentage mit dem internen Tagessatz multipliziert, erhält eine erste Budgetgrösse – als Orientierung, nicht als Angebot.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • SBOM & Lieferkette: erstellt die Software-Stückliste auf Wunsch automatisch aus Ihrem Code (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs per Upload; Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, werden manuell erfasst. Für eingebundene Drittkomponenten unterstützt die Plattform die Sorgfaltspflicht nach Art. 13 Abs. 5 CRA.
  • Schwachstellen & CVD: gleicht die SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet sie für die Triage auf. Ob eine Meldepflicht nach Art. 14 besteht, wird gesondert geprüft.
  • Meldepflicht & Incident Response: unterstützt die Prüfung der Meldepflicht nach Art. 14 CRA und bereitet die Angaben für Frühwarnung, Meldung und Abschlussbericht mit Fristenübersicht vor. Prüfung, Freigabe und Einreichung über die einheitliche Meldeplattform bleiben beim verantwortlichen Unternehmen.
  • Dokumentation & Konformität: erstellt Entwürfe der technischen Dokumentation nach Anhang VII und der EU-Konformitätserklärung zur fachlichen Prüfung und Freigabe.

Der Einstieg in die Plattform ist unser kostenloser CRA-Quick-Check. Er unterstützt mit wenigen Fragen eine unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte. Die im Artikel genannten Aufwände sind unverbindliche Erfahrungs- und Planwerte; die konkrete Beurteilung hängt von Produkt, Produktklasse und Ausgangslage des Unternehmens ab.

Methodik dieser Recherche

Die rechtlichen Bezüge sind gegen die Verordnung (EU) 2024/2847 (Cyber Resilience Act) geprüft (Art. 8, Art. 13, Art. 14, Art. 27, Art. 32, Art. 33, Anhang I Teil I, Anhang VII, Anhang VIII). Die Aussage zur Rolle von Kostenüberlegungen bei der Risikobehandlung beruht auf der unverbindlichen Guidance der Kommission C(2026) 5252 final vom 27.07.2026 (Rn. 158). 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 historische 90-%-Schätzung ist der BSI TR-03183-1 (Version 1.0.0, Kap. 3.8.1) entnommen, die sie auf ein Briefing des Wissenschaftlichen Dienstes des Europäischen Parlaments von 2022 stützt. Die Aufwands-Bandbreiten in Personentagen sind für die Eigenleistung eigene Projekterfahrung von codAIx, für die Arbeit mit crAIready Planwerte auf Grundlage einer internen Ablaufanalyse (für die Erstimplementierung bei SBOM-Erstellung durch crAIready aus dem Code), jeweils für das definierte Referenzszenario, ausdrücklich unverbindlich und kein garantiertes Ergebnis.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act) – EUR-Lex — insbesondere Art. 8, Art. 13 Abs. 8, Art. 14, Art. 27, Art. 32, Art. 33, Anhang I Teil I Nr. 2 lit. b (sichere Standardkonfiguration), Anhang VII (technische Dokumentation), Anhang VIII (Konformitätsbewertungsverfahren).

[2] Europäische Kommission, Vorschlag COM(2022) 454 final, Begründung, Abschnitt Folgenabschätzung — aggregierte Befolgungskosten von bis zu rund 29 Mrd. Euro, Marktvolumen von 1.485 Mrd. Euro und mögliche Senkung vorfallsbedingter Unternehmenskosten um rund 180 bis 290 Mrd. Euro jährlich.

[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/IW Consult), 13.11.2025 — Zusammenfassung („teils erhebliche Compliance-Kosten“, langfristig erwartete Vorteile); S. 35 (CRA-Kosten).

[4] EU-Projekt SECURE — Unterstützung von KMU bei der Umsetzung des Cyber Resilience Act (Plattform Industrie 4.0) — Gesamtbudget rund 22 Mio. Euro, davon rund 16 Mio. Euro direkte finanzielle Unterstützung.

[5] ENISA, „Secure by Design and Default Playbook — A Practical Guide to Secure by Design and Default Principles for SMEs“, Version 1.0, Juli 2026. 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.

[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).

[7] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technische Richtlinie BSI TR-03183-1: „Cyber Resilience Requirements for Manufacturers and Products – Part 1: General requirements“, Version 1.0.0 — Kap. 3.8.1, mit Verweis auf European Parliamentary Research Service, „EU Cyber Resilience Act“, Briefing EPRS_BRI(2022)739259.

[8] Europäische Kommission, Communication C(2026) 5252 final mit Annex, „Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)“. Veröffentlicht am 27.07.2026. Die Guidance ist nicht verbindlich und schafft keine zusätzlichen Pflichten; massgeblich bleiben der CRA und andere verbindliche Rechtsakte. Herangezogen wurden Rn. 126 (fünf Jahre kein Regelwert) und Kapitel 7.1 (Rn. 158: interne Risikotoleranz, Geschäftsstrategie und blosse Kostenüberlegungen sind für die Frage, ob Risiken behandelt sind, nicht massgeblich).

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Die genannten Aufwände in Personentagen sind unverbindliche Erfahrungswerte (Eigenleistung) beziehungsweise Planwerte (mit crAIready) für ein definiertes Referenzszenario und kein garantiertes Ergebnis; der tatsächliche Aufwand hängt vom Einzelfall ab (Produktanzahl, Produktklasse, 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. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 17.08.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: KI-Cyberangriffe: Was der CRA von Herstellern verlangt — warum KI-gestützte Angriffe keine KI-Abwehrpflicht begründen, aber Risikobewertung, Tests, Schwachstellenbehandlung und Updates verändern.