CRA umsetzen, ohne Entwicklung auszubremsen

Der Cyber Resilience Act, kurz CRA, verändert die Spielregeln für Hersteller digitaler Produkte. Was bisher oft als Best Practice galt, wird künftig zur Marktvoraussetzung: sichere Produkte, nachvollziehbare Software-Komponenten, geregeltes Schwachstellenmanagement, verlässliche Updates und belastbare technische Dokumentation.

Für Unternehmen besteht die eigentliche Herausforderung jedoch nicht darin, den Gesetzestext zu verstehen. Entscheidend ist, den CRA so in Produktentwicklung, Betrieb und Lieferkette zu integrieren, dass Sicherheit und Compliance nicht zum Bremsklotz für Innovation werden.

Warum ist der Cyber Resilience Act relevant?

Der Cyber Resilience Act richtet sich an Produkte mit digitalen Elementen – also an Hardware, Software und vernetzte Systeme, die auf dem EU-Markt bereitgestellt werden. Die EU-Kommission beschreibt den CRA als Rahmenwerk mit verpflichtenden Cybersecurity-Anforderungen für Hersteller über Planung, Design, Entwicklung und Wartung hinweg. Zudem müssen Hersteller Schwachstellen über den Produktlebenszyklus hinweg behandeln.

Wichtig ist der Zeitplan: Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten gelten ab 11. September 2026, die wesentlichen Verpflichtungen ab 11. Dezember 2027.

Das klingt nach ausreichend Zeit. In der Praxis ist es das oft nicht. Denn CRA-Readiness betrifft nicht nur Security-Teams. Sie greift tief in Produktmanagement, Architektur, Softwareentwicklung, Embedded Engineering, Testing, DevOps, Dokumentation, Einkauf und Governance ein.

Ist mein Unternehmen vom CRA betroffen?

Viele Unternehmen starten mit der Frage: Sind wir überhaupt vom CRA betroffen?

Diese Frage ist wichtig – aber sie greift zu kurz.

Für Hersteller digitaler Produkte ist meist entscheidender:

• Welche Produkte, Komponenten und Varianten sind betroffen?
• Welche Software-Komponenten sind tatsächlich im Einsatz?
• Wo fehlen Nachweise, Prozesse oder technische Dokumentation?
• Wie werden Schwachstellen erkannt, bewertet, gemeldet und behoben?
• Wie werden Updates bereitgestellt und über den Lebenszyklus abgesichert?
• Welche Risiken entstehen durch Drittkomponenten, Open Source oder Lieferanten?

Genau hier entstehen die grössten Lücken. Der CRA fordert nicht nur sichere Produkte zum Zeitpunkt des Inverkehrbringens. Er verlangt Sicherheitsprozesse, die über den gesamten Produktlebenszyklus funktionieren.

Was sind die grössten Herausforderungen beim CRA?

In der Praxis scheitert CRA-Readiness selten an einem einzelnen Security-Problem. Häufiger fehlt der durchgängige Überblick.

Typische Hürden sind:

• kein vollständiges Inventar der Software-Komponenten,
• unklare Zuständigkeiten zwischen Produktmanagement, Engineering und Security,
• fehlende oder uneinheitliche Security Reviews,
• nicht ausreichend dokumentierte Tests,
• unklare Prozesse für Vulnerability Disclosure,
• fehlende Nachweise für Updates, Korrekturen und Risikobewertungen,
• zu wenig Transparenz in der Software Supply Chain.

Besonders die Lieferkette wird zur Herausforderung. Das World Economic Forum berichtet, dass mehr als 69 Prozent der befragten Organisationen Cyber-Regulierungen als zu komplex oder zu zahlreich empfinden beziehungsweise Schwierigkeiten haben zu prüfen, ob Drittanbieter die Anforderungen erfüllen.

Für Hersteller digitaler Produkte bedeutet das: CRA-Compliance ist nicht nur eine regulatorische Aufgabe. Sie ist auch eine Frage der technischen Transparenz, der operativen Resilienz und der Steuerbarkeit komplexer Lieferketten.

Was passiert, wenn Unternehmen zögern?

Wer den CRA zu spät angeht, gerät schnell unter Druck. Dann müssen Sicherheitsanforderungen nachträglich in bestehende Roadmaps, Architekturen und Entwicklungsprozesse eingebaut werden. Das führt häufig zu zusätzlichem Abstimmungsaufwand, Verzögerungen im Marktzugang und höheren Kosten.

Gleichzeitig steigen die wirtschaftlichen Folgen realer Sicherheitsvorfälle. IBM beziffert die durchschnittlichen globalen Kosten einer Datenpanne im Cost of a Data Breach Report 2025 auf rund 4,4 Mio. US-Dollar. Für Deutschland nennt IBM laut veröffentlichter Länderauswertung durchschnittlich 3,87 Mio. Euro pro Datenpanne.

Diese Zahlen zeigen: Cybersecurity ist längst kein rein technisches Thema mehr. Sie betrifft Produktstrategie, Haftungsrisiken, Marktzugang, Kundenvertrauen und Wettbewerbsfähigkeit.

Wie können Unternehmen den Cyber Resilience Act konkret umsetzen?

CRA-Readiness beginnt nicht mit Aktionismus, sondern mit Struktur. Unternehmen sollten zunächst verstehen, wo sie stehen und welche Lücken wirklich relevant sind.

Ein pragmatischer Einstieg umfasst fünf Schritte:

1. Betroffene Produkte und Komponenten identifizieren

Zuerst braucht es Klarheit darüber, welche Produkte unter den CRA fallen und welche digitalen Komponenten, Software-Module, Bibliotheken und Drittbestandteile darin enthalten sind.

Eine Software Bill of Materials, kurz SBOM, schafft hier die notwendige Transparenz. Sie bildet die Grundlage, um Risiken zu bewerten, Schwachstellen schneller zu erkennen und Nachweise belastbar zu führen.

2. Risiken bewerten und priorisieren

Nicht jede Lücke hat dieselbe Kritikalität. Entscheidend ist eine risikobasierte Bewertung: Welche Produkte sind besonders exponiert? Welche Komponenten sind sicherheitskritisch? Wo bestehen Abhängigkeiten von Dritten? Welche Schwachstellen können den Betrieb, Nutzer oder Kundenprozesse gefährden?

So entsteht ein priorisierter Massnahmenplan statt einer überladenen To-do-Liste.

3. Security by Design im Entwicklungsprozess verankern

CRA-konforme Entwicklung darf kein nachgelagerter Prüfpunkt am Ende eines Projekts sein. Security muss in Architektur, Requirements Engineering, Entwicklung, Code Reviews, Testing und Release-Prozesse integriert werden.

Dazu gehören unter anderem Threat Modeling, sichere Coding Guidelines, automatisierte Security Tests, Dependency Scans und klare Kriterien für Releases.

4. Schwachstellenmanagement operationalisieren

Der CRA verlangt belastbare Abläufe für den Umgang mit Schwachstellen. Unternehmen müssen definieren, wie Schwachstellen gemeldet, bewertet, priorisiert, behoben, dokumentiert und – wo erforderlich – gemeldet werden.

Das betrifft nicht nur interne Prozesse. Auch externe Meldungen, Koordination mit Lieferanten und Kommunikation gegenüber Nutzern müssen geregelt sein.

5. Dokumentation und Nachweise laufend pflegen

Technische Dokumentation wird unter dem CRA zu einem zentralen Compliance-Baustein. Sie sollte nicht erst kurz vor einer Prüfung entstehen, sondern kontinuierlich aus dem Entwicklungsprozess heraus gepflegt werden.

Das reduziert Aufwand, verbessert Nachvollziehbarkeit und sorgt dafür, dass Sicherheit nicht als Parallelprojekt neben der Produktentwicklung läuft.

CRA-Readiness darf kein Parallelprojekt werden

Viele Unternehmen befürchten, dass CRA-Umsetzung ihre Entwicklung verlangsamt. Das muss nicht passieren.

Der Schlüssel liegt darin, Security und Compliance dort zu integrieren, wo Produktentscheidungen ohnehin getroffen werden: in Architekturboards, Entwicklungsprozessen, CI/CD-Pipelines, Teststrategien, Release-Management und Produkt-Governance.

Richtig umgesetzt, entstehen daraus nicht nur regulatorische Nachweise. Unternehmen gewinnen auch mehr Transparenz über ihre Produkte, bessere Entscheidungsgrundlagen für Risiken und robustere Abläufe im Umgang mit Schwachstellen.

Vom regulatorischen Druck zum klaren Fahrplan

Noser Engineering verbindet CRA-Verständnis mit technischer Umsetzungskompetenz. Nicht nur konzeptionell, sondern in allen relevanten Disziplinen der praktischen Umsetzung – von Architektur über Embedded- und Softwareentwicklung bis hin zu Testing, DevSecOps, Schwachstellenmanagement und Dokumentation.

Für Unternehmen ist das entscheidend: Ein Partner muss nicht nur erklären, was gefordert ist. Er muss helfen, Prioritäten zu setzen, Lücken sauber zu schliessen und CRA-konforme Prozesse in den realen Entwicklungsalltag zu integrieren.

So wird aus regulatorischem Druck eine belastbare Entscheidungsgrundlage. Und aus Unsicherheit ein konkreter Fahrplan.

Wann sollen Unternehmen mit der CRA-Umsetzung beginnen?

Die wichtigsten CRA-Pflichten greifen zwar erst im September 2026 beziehungsweise im Dezember 2027. Doch Unternehmen, die digitale Produkte entwickeln, sollten jetzt handeln. Denn Transparenz über Komponenten, Lieferketten, Schwachstellen und Sicherheitsprozesse entsteht nicht über Nacht.

Wer früh startet, kann CRA-Readiness schrittweise aufbauen – ohne Roadmaps zu blockieren, ohne hektische Nachrüstung und ohne unnötige Reibung zwischen Compliance, Security und Engineering.

Noser Engineering unterstützt Unternehmen dabei, den Cyber Resilience Act pragmatisch umzusetzen – mit technischem Tiefgang, klarer Priorisierung und einem Fahrplan, der zur Produktentwicklung passt.

Holen Sie sich jetzt unser kostenloses CRA-Whitepaper für noch mehr Informationen zum Cyber Resilience Act.

Autor

Thomas Stadelmann ist CRA-Experte bei Noser Engineering. Die Noser Engineering AG ist ein Schweizer ICT-Dienstleister für massgeschneiderte Software- und Hardwarelösungen und begleitet Unternehmen bei der Umsetzung komplexer digitaler Vorhaben.

Unsere Angebote im Bereich Security & CRA

Hier eine Übersicht mit unseren Angebot.

Veröffentlichung

Dieser Artikel wurde veröffentlicht im Swiss IT Magazine.

Quellen

• EU-Kommission: Cyber Resilience Act – Fristen, Ziele und Pflichten.
• World Economic Forum: Global Cybersecurity Outlook 2025.
• ENISA: Threat Landscape 2025.
• IBM: Cost of a Data Breach Report 2025.
• IBM-Länderauswertung Deutschland, veröffentlicht bei Silicon Saxony.