EU Cyber Resilience Act: Überblick und Praxis

Am 25. November 2025 zeigten Martin Grossen und Michael Roeder von Avnet Silica detailliert auf, was es technisch bedeutet, Software und Systeme auf die Anforderungen des EU‑Cyber‑Resilience‑Acts vorzubereiten und innerhalb dieser Regulierung zu betreiben. Das grosse Interesse am Seminar verdeutlichte, wie zentral technische Aufklärung für Entwicklerinnen und Entwickler in diesem Umfeld ist.

Was ist der CRA?  

Der Cyber Resilience Act ist ein Baustein der EU‑Digitalstrategie und verfolgt das Ziel, die Sicherheit von Hard‑ und Software über ihre gesamte Lebensdauer nachweisbar zu erhöhen. Hintergrund ist die weltweit stark ansteigende Schadenssumme durch Cyberangriffe. Der CRA erweitert bestehende Anforderungen um verbindliche Sicherheitsanforderungen, Dokumentationspflichten und die kontinuierliche Meldung von Schwachstellen.

Mehr zum Cyber Resilience Act unter:  cyberresilienceact.eu

Products with Digital Elements (PDE)  

Der CRA gilt für alle Produkte mit digitalen Elementen. Damit sind praktisch sämtliche Hard- und Software erfasst, die direkt oder indirekt kommuniziert – unabhängig davon, ob dies über ein Netzwerk, Bluetooth oder andere Schnittstellen geschieht.
Diese Produkte müssen mindestens die grundlegenden Cybersicherheitsanforderungen gemäss Anhang I, Teil II CRA erfüllen. Zudem sind die Hersteller verpflichtet, eine entsprechende Cybersicherheits-Selbstbewertung durchzuführen.

Was kommuniziert, fällt unter den CRA – und zukünftig wird fast alles kommunizieren.

Technische Verantwortung des Herstellers

Hersteller ist im Sinne des CRA jede Instanz, die ein Produkt bereitstellt oder in Verkehr bringt, auch wenn das Produkt aus Drittkomponenten oder Open‑Source‑Bausteinen besteht. Auch Komponenten, die in eigene Produkte integriert werden, fallen unter den CRA. Im Zusammenhang mit der neuen EU Produkthaftungsrichtlinie ergeben sich sogar Fälle, in denen auch Endkunden durch Rollentausch als Hersteller betrachtet werden und in die Gesamthaftung mit eintreten, etwa durch Vornahme wesentlicher Veränderungen oder einer Zweckänderung des Produktes.

Der Hersteller trägt die technische und sicherheitsrelevante Verantwortung. Dazu gehören unter anderem:  
•    Risikoanalyse und Definition der Lebensdaueranforderungen  
•    Erstellung und Pflege einer SBOM (Software Bill of Materials)
•    Härtung, Sicherheitsmassnahmen und technische Nachweise  
•    Dokumentation und interne Prozesse zur Meldung von Schwachstellen
•    Sicherstellung, dass das Produkt während seiner gesamten Nutzungsdauer sicher betrieben werden kann

Der CRA als Prozess, nicht als Checkliste

Michael Roeder betonte, dass absolute Compliance zum CRA nicht einfach nur erreicht und abgehakt werden kann. Sicherheit sei ein dynamisches Ziel. Deshalb fördere CRA-Konformität strukturierte, wiederholbare Prozesse. 

Regulatorischer Rahmen

Der CRA ist eine EU‑Verordnung, gilt also in allen EU‑Mitgliedstaaten identisch. Unentgeltlich bereitgestellte Open Source Software ist ausgenommen. Sobald Software jedoch im Rahmen eines kommerziellen Angebots bereitgestellt oder in ein kommerzielles Produkt integriert wird, unterliegt sie dem CRA. Und das unabhängig davon, ob sie Open Source oder proprietär ist.

Der Umgang mit Free and Open Source Software (FOSS) 

Wer FOSS kommerziell in ein Produkt integriert, wird zum Hersteller im CRA‑Sinne und trägt dadurch die volle Verantwortung für alle Abhängigkeiten. Das umfasst Sicherheitswartung, das Monitoring der jeweiligen Open‑Source‑Communities, die Pflege der Lieferkette und alle Meldepflichten. Sicherheit bleibt ein fortlaufender Prozess.

Aktuelle Entwicklungen bei Microsoft

Martin zeigte im Anschluss auf, wie Microsoft sein Embedded‑ und IoT‑Portfolio weiterentwickelt. Ein Schwerpunkt liegt verstärkt auf ARM‑Plattformen, unter anderem aus Energieeffizienz‑ und Sicherheitsgründen. 

Ein dringendes technisches Thema betrifft Secure Boot: Die aktuellen UEFI‑Zertifikate laufen ab Juli 2026 aus. Ohne rechtzeitige Aktualisierung können Geräte schlicht nicht mehr booten. UEFI‑Zertifikate stellen sicher, dass nur vertrauenswürdige Software beim Start geladen wird – laufen sie ab, verweigern Geräte den Boot‑Vorgang. Dies betrifft Windows‑ und Linux‑Systeme gleichermassen. 

Wichtig sind daher frühzeitige Planung, Koordination mit Board‑ und UEFI‑Herstellern und die Einführung regelmässiger Zertifikats‑Rotationsprozesse.