Der Cyber-Resilience-Act (CRA), amtlich Cyber Resilience Act, verpflichtet Hersteller von Produkten mit digitalen Elementen erstmals europaweit dazu, Cybersicherheit über den gesamten Produktlebenszyklus nachweisbar zu machen. Für Hersteller industrieller Embedded-Systeme ist das weniger eine Frage einzelner Sicherheitsfunktionen als eine Frage der Skalierung: Die Pflichten gelten je Produkt, je Variante und über den gesamten Unterstützungszeitraum.
Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab dem 11. September 2026, die Verordnung insgesamt ab dem 11. Dezember 2027 (Quelle: Verordnung (EU) 2024/2847, Erwägungsgrund 126, eur-lex.europa.eu/eli/reg/2024/2847/oj).
awinia entwickelt Embedded-Software für Hersteller intelligenter, softwareintensiver Industriesysteme und richtet Architektur, Test, Wartung und Modernisierung so aus, dass CRA-Nachweise im Entwicklungsprozess entstehen — statt nachträglich rekonstruiert werden zu müssen. Diese Seite ordnet die technischen Pflichten ein; sie ist keine Rechtsberatung.
Ab wann der CRA gilt — die vier relevanten Daten
| Datum | Was ab diesem Datum gilt |
|---|---|
| 10. Dezember 2024 | Inkrafttreten der Verordnung (EU) 2024/2847. |
| 11. Juni 2026 | Die Vorschriften über die Notifizierung von Konformitätsbewertungsstellen gelten. Notifizierte Stellen können ab diesem Zeitpunkt benannt werden. |
| 11. September 2026 | Die Meldepflichten greifen: aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit sind zu melden (Artikel 14 und 15). |
| 11. Dezember 2027 | Vollständige Anwendung: grundlegende Cybersicherheitsanforderungen nach Anhang I, technische Dokumentation nach Anhang VII, Konformitätsbewertung und CE-Kennzeichnung. |
Alle vier Daten ergeben sich unmittelbar aus der Verordnung (EU) 2024/2847, Erwägungsgrund 126 (eur-lex.europa.eu). Für Produkte, die sich heute in der Entwicklung befinden, ist der 11. Dezember 2027 die planungsrelevante Marke — und damit die Frage, welche Architektur- und Nachweisentscheidungen jetzt getroffen werden müssen, um sie später nicht rückwirkend nachziehen zu müssen.
Was der CRA konkret verlangt
Grundlegende Cybersicherheitsanforderungen (Anhang I Teil I)
Produkte mit digitalen Elementen müssen so entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau bieten. In der Praxis heißt das für Embedded-Systeme:
- sichere Standardkonfiguration ohne bekannte ausnutzbare Schwachstellen im Auslieferungszustand
- Schutz vor unbefugtem Zugriff über Authentisierung, Identitäts- und Zugriffsverwaltung
- Schutz von Vertraulichkeit und Integrität gespeicherter und übertragener Daten
- Minimierung der Angriffsfläche einschließlich externer Schnittstellen
- Bereitstellung von Sicherheitsupdates, wo technisch möglich automatisch und getrennt von Funktionsupdates
- Protokollierung und Überwachung sicherheitsrelevanter Ereignisse
Schwachstellenbehandlung (Anhang I Teil II)
Der zweite Pflichtenblock betrifft nicht das Produkt, sondern den Prozess dahinter — und er läuft über die gesamte Lebensdauer:
- die im Produkt enthaltenen Komponenten feststellen und dokumentieren und dazu eine Software-Stückliste (SBOM) aufstellen
- Schwachstellen unverzüglich behandeln und durch Sicherheitsupdates beheben
- eine Politik zur koordinierten Offenlegung von Schwachstellen vorhalten
- eine Kontaktstelle für Schwachstellenmeldungen benennen und öffentlich zugänglich machen
- einen Mechanismus zur sicheren Verteilung von Updates bereitstellen
Unterstützungszeitraum: mindestens fünf Jahre
Der Unterstützungszeitraum beträgt mindestens fünf Jahre. Kürzer darf er nur sein, wenn das Produkt voraussichtlich weniger als fünf Jahre in Verwendung ist; dann entspricht er der erwarteten Nutzungsdauer (Artikel 13 Absatz 8, eur-lex.europa.eu). Für Produkte, die für industrielle Umgebungen bestimmt sind — die Verordnung nennt ausdrücklich industrielle Steuerungssysteme —, hält sie fest, dass diese häufig über deutlich längere Zeiträume verwendet werden.
Ein Unterstützungszeitraum von fünf Jahren und mehr ist keine Dokumentationsfrage, sondern eine Architekturfrage: Wer über acht oder zehn Jahre Sicherheitsupdates für ein variantenreiches Portfolio ausliefern will, braucht eine Software-Basis, die Varianten und Produktgenerationen trägt — sonst wächst der Wartungsaufwand mit jeder Variante linear mit.
Die Meldekette: 24 Stunden, 72 Stunden, 14 Tage
Der Hersteller meldet unverzüglich, in jedem Fall aber innerhalb von 24 Stunden nach Kenntniserlangung, eine Frühwarnung über die aktiv ausgenutzte Schwachstelle und gibt an, in welchen Mitgliedstaaten das Produkt seiner Kenntnis nach bereitgestellt wurde (Artikel 14 Absatz 2 Buchstabe a).
Innerhalb von 72 Stunden folgt die eigentliche Meldung: allgemeine Informationen zum Produkt, zur Art der Ausnutzung und zur Schwachstelle, zu bereits ergriffenen Korrektur- oder Risikominderungsmaßnahmen sowie zu Maßnahmen, die Nutzer selbst ergreifen können (Artikel 14 Absatz 2 Buchstabe b).
Spätestens 14 Tage nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht, folgt der Abschlussbericht mit Beschreibung der Schwachstelle einschließlich Schweregrad und Auswirkungen (Artikel 14 Absatz 2 Buchstabe c).
Gemeldet wird gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA, über die einheitliche Meldeplattform nach Artikel 16 (Quelle: Verordnung (EU) 2024/2847, Artikel 14 und 16, eur-lex.europa.eu; Plattformbetrieb bei der ENISA, enisa.europa.eu). Für schwerwiegende Sicherheitsvorfälle gilt nach Artikel 15 eine entsprechende Meldekette.
Welche Embedded-Produkte betroffen sind
Der CRA gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden — also für nahezu jedes vernetzbare Industriegerät mit eigener Software. Die Verordnung unterscheidet Standardprodukte von „wichtigen“ Produkten (Anhang III, Klassen I und II) und „kritischen“ Produkten (Anhang IV). Die Einordnung entscheidet über das Verfahren der Konformitätsbewertung.
Wichtige Produkte der Klasse II — für Embedded-Hersteller besonders relevant
- manipulationssichere Mikrocontroller
- manipulationssichere Mikroprozessoren
- Hypervisoren und Container-Runtime-Systeme, die eine virtualisierte Ausführung von Betriebssystemen unterstützen
- Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme
Wichtige Produkte der Klasse I — Auszug
- Betriebssysteme
- Mikroprozessoren mit sicherheitsrelevanten Funktionen
- Netzmanagementsysteme sowie Router, Modems für die Internetanbindung und Switches
- physische und virtuelle Netzschnittstellen
- Bootmanager
- Identitätsmanagementsysteme und Software für die Verwaltung privilegierter Zugriffe
Die vollständigen Listen stehen in Anhang III der Verordnung (EU) 2024/2847 (eur-lex.europa.eu). Für Standardprodukte ist die Selbstbewertung der Regelfall; für wichtige und kritische Produkte sieht die Verordnung strengere Verfahren bis zur Einbeziehung einer notifizierten Stelle vor.
Der wirtschaftliche Kern: CRA über viele Produktvarianten
Warum der CRA ein Skalierungsthema ist
Die CRA-Pflichten gelten nicht je Unternehmen, sondern je Produkt. Bei Portfolios, die über Variantenmerkmale wie Leistungsklassen, Kommunikationsschnittstellen oder Messprinzipien aufgespannt werden, entstehen schnell dutzende bis hunderte Varianten. Das bedeutet nicht eine Software-Stückliste, sondern eine je Variante und Produktgeneration — jede über einen Unterstützungszeitraum von mindestens fünf Jahren gepflegt, überwacht und im Ereignisfall innerhalb von 24 Stunden meldefähig.
Diese Dynamik ist nicht neu, der CRA macht sie nur verbindlich. Wie ein Hersteller in die Wartungsfalle läuft — divergierende Firmwarestände, steigende Integrations- und Testaufwände, Entwickler, die zunehmend nur noch warten — ist auf der Seite Plattformstrategie – Roadmap zur Embedded Plattform im Detail beschrieben.
Wer diese Last variantenweise organisiert, skaliert sie mit. Wer sie plattformweise organisiert, bricht die Kopplung zwischen Variantenzahl und Nachweisaufwand.
Der Hebel: Plattform statt Einzelprodukt
awinia arbeitet mit einem etablierten Methoden-Bestand, der genau auf langlebige, variantenreiche Produkte ausgelegt ist. Diese Methoden sind kein CRA-Programm — sie waren schon vorher die Grundlage wirtschaftlicher Embedded-Entwicklung und tragen die CRA-Nachweise nun mit:
- Plattformstrategie und Produktlinien Software Engineering (PLSE) für variantenreiche Portfolios — ausführlich auf den Seiten Produktlinien Software Engineering und Plattformstrategie – Roadmap zur Embedded Plattform
- modellgetriebene Entwicklung zur Reduktion wiederkehrender Implementierungsaufwände
- Domain-Driven Design für Embedded — fachlich geschnittene, wartbare Architekturen
- Embedded Platform Engineering als Basis für generationentragende Systeme
- Package Principles für saubere Modul- und Abhängigkeitsstrukturen
Der integrierte KI-Einsatz übernimmt dabei die repetitiven Anteile — Testfallableitung, Auswertung, Erkennen wiederkehrender Änderungen. Architektur-, Sicherheits- und Freigabeentscheidungen bleiben beim Menschen (Human in the Loop). Gerade im CRA-Kontext ist das kein Detail: Nachweise sind nur belastbar, wenn nachvollziehbar bleibt, wer was entschieden hat.
Von der CRA-Anforderung zur Leistung
Embedded Software Engineering
Grundlegende Anforderungen (Anhang I Teil I)
Sichere Architektur, minimierte Angriffsfläche und Update-Fähigkeit von Beginn an mitentwickeln
Assisted Embedded System Testing
Reproduzierbare, auditfähige Nachweise
Testableitung, Ausführung, Auswertung und Wartung automatisieren und über Varianten hinweg wiederholbar halten
Autonomous Maintenance & Quality Automation
Schwachstellenbehandlung, SBOM, Updates über den Unterstützungszeitraum
Komponenten und Abhängigkeiten überwachen, Patches über Varianten und Generationen ausrollen
Intelligent Software Migration & Modernization
Update-Fähigkeit von Altsystemen
Bestand rekonstruieren, testbar machen, dann auf eine wart- und skalierbare Basis modernisieren
Industrial Web-Frontends
Zugriffsschutz in Bedien- und Serviceoberflächen
Rollen, Authentisierung und sichere Voreinstellungen im Frontend verankern
Industrial Internet-of-Things
Sichere Anbindung vernetzter Geräte
Transportverschlüsselung, Geräteidentitäten und Datenpfade im Produktkontext absichern
Embedded Product Viability Assessment
Ist-Bewertung des Portfolios als Einstieg
Architektur, Entwicklungsprozesse, Teststrategie, Wartbarkeit und Compliance-Fähigkeit bewerten, Risiken und Handlungsfelder priorisieren — siehe Embedded Product Viability Assessment
Die sechs erstgenannten Leistungen sind gleichwertige Bestandteile des awinia-Leistungsangebots und greifen entlang des Produktlebenszyklus ineinander; jede ist auf einer eigenen Seite ausführlich beschrieben. Das Embedded Product Viability Assessment ist keine Umsetzungsleistung, sondern die vorgeschaltete Bewertung — der übliche Einstieg, wenn zuerst geklärt werden soll, wo ein Portfolio regulatorisch und technisch steht.
CRA intern stemmen oder mit awinia skalieren?
| CRA-Aufgabe | Intern allein | Mit awinia als Skalierungspartner |
|---|---|---|
| Ersteinordnung des Portfolios | Norm- und Verordnungswissen muss aufgebaut werden | Vorhandenes Norm- und Domänenwissen (CRA, IEC 62443, IEC 61508) |
| SBOM über Varianten und Generationen | Pflege je Variante, Aufwand wächst mit dem Portfolio | Varianten- und Patch-Handling als Teil der Wartungsleistung |
| Auditfähige Testnachweise | Testlast steigt mit jeder Variante und jedem Release | KI-gestützte Automatisierung des Systemtest-Lebenszyklus |
| Meldefähigkeit 24 h / 72 h / 14 Tage | Bereitschaft und Zuständigkeiten müssen organisiert werden | Wartungsprozess mit Schwachstellen-Monitoring, Human in the Loop |
| Unterstützungszeitraum ab fünf Jahren | Bindet das Kernteam über die gesamte Laufzeit | Ergebnisverantwortung für definierte Komponenten |
| Altsysteme im Portfolio | Rekonstruktion vor jeder Modernisierung nötig | Migration und Modernisierung als eigene Leistung |
Beide Wege sind gangbar. awinia positioniert sich nicht als Alternative zum internen Team, sondern als Weg, kritische Architektur- und Nachweisthemen zu verantworten und dem Kernteam Freiraum für das eigene Produkt zu schaffen — mit bedarfsgerechten Teams statt einzeln gesteuerter Ressourcen.
Der konkrete Einstieg: Zukunftscheck CRA Readiness
Wer nicht bei der Frage „was verlangt der CRA“ stehen bleiben will, sondern wissen möchte, wo das eigene Portfolio steht, hat bei awinia einen definierten Einstieg: den Zukunftscheck CRA Readiness im Rahmen des Embedded Product Viability Assessments.
Der Zukunftscheck bewertet, wie die Software die Anforderungen des Cyber-Resilience-Act dauerhaft und wirtschaftlich erfüllen kann, wie sich die Umsetzung in bestehende Entwicklungs-, Test- und Wartungsprozesse einfügt und wo KI-gestützte Verfahren bei Analyse und Nachverfolgung von Security- und Compliance-Anforderungen tragen. Er ist einer von fünf Zukunftschecks; die übrigen betreffen Skalierbarkeit, Testautomatisierung, Legacy-Modernisierung und Wartungs-Automatisierbarkeit.
| Rahmen | Angabe |
|---|---|
| Aufwand intern | 1 bis 2 Workshops plus Interviews |
| Ergebnis | Product Viability Report mit Management-Präsentation: Executive Summary, Bewertung der Zukunftsdimensionen, Risiko- und Potenzialanalyse, priorisierte Maßnahmen, Roadmap |
Angaben nach der Seite Embedded Product Viability Assessment, Stand September 2026. Dauer und Preisrahmen des Zukunftschecks sind dort beschrieben.
Der 11. Dezember 2027 ist keine Frist, die sich in einem Sprint erledigen lässt: Architekturentscheidungen, eine belastbare Nachweiskette und ein tragfähiges Varianten-Handling brauchen Vorlauf. Eine Ist-Bewertung des Portfolios trennt früh, was ohnehin ansteht, von dem, was der CRA zusätzlich verlangt — und macht den Aufwand planbar statt schätzbar.
Normen-Anschluss und Nachweisrahmen
| Rahmenwerk | Bedeutung im CRA-Kontext |
|---|---|
| ISO 9001 | awinia ist seit 2024 ISO-9001-zertifiziert, mit jährlichem Überwachungsaudit. Das zertifizierte Qualitätsmanagement ist der Prozessrahmen für reproduzierbare Entwicklungs- und Nachweisprozesse. |
| IEC 62443 | Industrielle Cybersecurity über den Lebenszyklus — inhaltlich die engste Brücke zu den grundlegenden CRA-Anforderungen. |
| IEC 61508 | Funktionale Sicherheit sicherheitsgerichteter Systeme; bei entsprechenden Produkten parallel zum CRA nachzuweisen. |
| BSI-Vorgaben | Ergänzende Sicherheitsanforderungen im deutschen Kontext (bsi.bund.de). |
awinia ist zudem in fachliche Netzwerke eingebunden — unter anderem den Spitzencluster microTEC Südwest und die DHBW Lörrach. Mitarbeiter-Patente belegen die technologische Tiefe.
Domänenkompetenz in regulierten Industriefeldern
Regulatorische Anforderungen wirken immer im konkreten Industriefeld. awinia bringt gewachsene Domänenkompetenz in sechs Feldern ein:
Domänenkompetenz heißt hier: Vertrautheit mit den regulatorischen Rahmenbedingungen, den typischen Produktarchitekturen, den Entwicklungs- und Freigabeprozessen sowie den realen Betriebs-Randbedingungen dieser Felder.
Diese Seite ordnet die technischen Anforderungen des Cyber-Resilience-Act für industrielle Embedded-Produkte ein. Sie ist keine Rechtsberatung. Die verbindliche Einordnung eines Produkts — insbesondere die Frage, ob es als Standardprodukt oder als wichtiges bzw. kritisches Produkt gilt — liegt beim Hersteller und dessen rechtlicher Beratung. awinia verantwortet die technische Umsetzung und die Nachweisfähigkeit der Software.
Ansprechpartner und nächster Schritt
Erste Ansprechperson für Anfragen ist Marc Gossweiler (Mitgründer, Geschäftsführung). Für tiefergehende technische und architektonische Themen — unter anderem Rust und Systemarchitektur — steht CTO Philipp Bormuth zur Verfügung.
awinia GmbH · Hanferstraße 28 · 79108 Freiburg im Breisgau · +49 761 52074490
Häufige Fragen zum Cyber-Resilience-Act
Ab wann gilt der Cyber-Resilience-Act?
Die Verordnung (EU) 2024/2847 ist am 10. Dezember 2024 in Kraft getreten. Die Vorschriften über die Notifizierung von Konformitätsbewertungsstellen gelten seit dem 11. Juni 2026. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten ab dem 11. September 2026. Die Verordnung insgesamt gilt ab dem 11. Dezember 2027.
Welche Fristen gelten für die Meldung einer aktiv ausgenutzten Schwachstelle?
Drei Fristen greifen nacheinander: eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Schwachstellenmeldung innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht. Gemeldet wird gleichzeitig an das als Koordinator benannte CSIRT und an die ENISA über die einheitliche Meldeplattform.
Wie lange müssen Sicherheitsupdates bereitgestellt werden?
Der Unterstützungszeitraum beträgt mindestens fünf Jahre. Kürzer darf er nur sein, wenn das Produkt voraussichtlich weniger als fünf Jahre in Verwendung ist; dann entspricht er der erwarteten Nutzungsdauer. Bei Produkten für industrielle Umgebungen ist die tatsächliche Nutzungsdauer regelmäßig deutlich länger — der Unterstützungszeitraum ist entsprechend länger anzusetzen.
Braucht jedes Produkt eine Software-Stückliste (SBOM)?
Der CRA verlangt, dass Hersteller die in ihren Produkten enthaltenen Komponenten feststellen und dokumentieren und dazu eine Software-Stückliste aufstellen. Marktüberwachungsbehörden können die Vorlage der Software-Stücklisten verlangen. Für variantenreiche Portfolios heißt das: nicht eine Stückliste, sondern eine je Variante und Produktgeneration.
Welche Embedded-Produkte fallen unter die strengeren Verfahren?
Anhang III der Verordnung listet die „wichtigen“ Produkte. Klasse II umfasst unter anderem manipulationssichere Mikrocontroller und Mikroprozessoren, Hypervisoren und Container-Runtime-Systeme sowie Firewalls und Intrusion-Detection-Systeme. Klasse I umfasst unter anderem Betriebssysteme, Netzmanagementsysteme, Router und Switches, physische und virtuelle Netzschnittstellen und Bootmanager. Die verbindliche Einordnung eines konkreten Produkts liegt beim Hersteller.
Welche Sanktionen sieht der CRA vor?
Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen aus Anhang I oder gegen die Pflichten aus Artikel 13 und 14 sieht die Verordnung Geldbußen von bis zu 15.000.000 Euro oder — bei Unternehmen — bis zu 2,5 Prozent des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, je nachdem, welcher Betrag höher ist.
Wie fängt man mit der CRA-Umsetzung konkret an?
Ein sinnvoller Einstieg ist eine Ist-Bewertung des Portfolios. awinia bietet dafür den Zukunftscheck CRA Readiness im Rahmen des Embedded Product Viability Assessments an: 1 bis 2 Workshops plus Interviews. Ergebnis ist ein Product Viability Report mit priorisierten Maßnahmen und einer Roadmap. Dauer und Preisrahmen sind auf der Seite Embedded Product Viability Assessment beschrieben.
Übernimmt awinia die rechtliche Bewertung?
Nein. awinia verantwortet die technische Umsetzung: Architektur, Testnachweise, Schwachstellenbehandlung und Modernisierung. Die rechtliche Bewertung — insbesondere die Produktklassifizierung und das anzuwendende Konformitätsbewertungsverfahren — liegt beim Hersteller und dessen rechtlicher Beratung.