CRA in Embedded-Projekten: Was Hersteller jetzt technisch vorbereiten müssen

Der CRA ist eine EU-Verordnung für „Produkte mit digitalen Elementen“. Gemeint sind Hardware- und Softwareprodukte, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind oder verbunden werden können. Dazu zählen auch Remote-Data-Processing-Lösungen, wenn diese vom Hersteller verantwortet werden und ohne sie eine Funktion des Produkts nicht mehr möglich wäre. Für viele Embedded-Produkte ist das besonders relevant, weil heute nicht mehr nur das Gerät selbst betrachtet wird, sondern auch seine App, sein Backend oder seine Cloud-nahe Zusatzfunktion.

Wichtig ist dabei: Der CRA ist grundsätzlich marktorientiert. Er greift für Produkte, die auf dem EU-Markt im Rahmen einer kommerziellen Tätigkeit bereitgestellt werden. Bestimmte Produktgruppen sind ausgenommen, wenn sie bereits durch andere EU-Regelwerke mit eigenen Cybersecurity-Anforderungen abgedeckt werden, etwa in Teilen der Medizin-, Luftfahrt- oder Automobilregulierung. Für Hersteller heißt das: Nicht jedes digitale Produkt fällt automatisch in denselben CRA-Pfad, aber sehr viele Embedded-Produkte werden davon unmittelbar erfasst.

Im Embedded-Umfeld treffen lange Produktlebenszyklen, spezielle Hardware, Altplattformen, proprietäre Schnittstellen und Komponenten von Drittanbietern aufeinander. Genau dort setzt der CRA an: Hersteller müssen künftig nachweisen können, dass sie Cyberrisiken systematisch bewerten, Sicherheitsanforderungen technisch umsetzen und Schwachstellen über den Lebenszyklus des Produkts behandeln. Der CRA ergänzt damit andere Regelwerke wie NIS2: Während NIS2 vor allem Organisationen und deren Betriebsprozesse adressiert, richtet sich der CRA an das Produkt selbst.

Für Embedded-Projekte bedeutet das in der Praxis eine klare Verschiebung: Security wird von einer Zusatzanforderung zum festen Bestandteil der Produktentwicklung. Wer Sicherheitsmechanismen erst kurz vor der Markteinführung ergänzt, wird künftig meist zu spät sein. Denn der CRA verlangt eine Cybersecurity-Risikobewertung, die Planung, Design, Entwicklung, Produktion, Auslieferung und Wartung des Produkts einbezieht. Das ist kein reiner Compliance-Anhang, sondern betrifft Architektur, Komponentenwahl, Update-Strategie, Logging, Hardening und die spätere Betriebsfähigkeit gleichermaßen.

Im Kern verlangt der CRA, dass Produkte mit digitalen Elementen mit angemessenen Cybersecurity-Eigenschaften entwickelt und betrieben werden. Die Europäische Kommission nennt dabei unter anderem folgende Leitplanken:

• Security by Default
• Zugriffskontrolle
• Einsatz von Kryptographie
• Update-Fähigkeit

Vor dem Inverkehrbringen müssen Hersteller außerdem mehrere Schritte nachvollziehbar durchlaufen:

1. Risikobewertung des Produkts

2. Erstellung technischer Unterlagen

3. Durchführung des Konformitätsbewertungsverfahrens

4. EU-Konformitätserklärung

5. CE-Kennzeichnung

Hinzu kommt die Pflicht, einen Supportzeitraum anzugeben und Schwachstellen während dieses Zeitraums wirksam zu behandeln. Dieser Zeitraum orientiert sich an der zu erwartenden Nutzungsdauer des Produkts. Gerade bei langlebigen Embedded-Geräten kann sich daraus ein mehrjähriger Supportbedarf ergeben — häufig über einen Zeitraum von mindestens fünf Jahren.

Ebenso müssen Hersteller Informationen und Anleitungen bereitstellen, die eine sichere Installation, Konfiguration, Nutzung und Wartung des Produkts ermöglichen. Gerade bei Embedded-Geräten mit langer Laufzeit ist das ein zentraler Punkt, weil Security nicht mit dem Ausliefern endet.

Besonders häufig unterschätzt werden die Meldepflichten, die bereits ab dem 11. September 2026 greifen. Für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gelten dann enge Fristen:

• Frühwarnung innerhalb von 24 Stunden nach Kenntnis
• Meldung innerhalb von 72 Stunden
• Abschlussbericht im weiteren definierten Verfahren

Wichtig ist dabei: Diese Meldepflichten gelten auch für Produkte mit digitalen Elementen, die bereits vor dem 11. Dezember 2027 auf dem EU-Markt bereitgestellt wurden. Wer also glaubt, sich erst kurz vor Ende 2027 mit dem Thema befassen zu müssen, setzt sich unnötig unter Zeitdruck.

Der CRA unterscheidet zwischen Standardprodukten sowie wichtigen und kritischen Produktkategorien. Für viele Produkte bleibt grundsätzlich eine Hersteller-Selbsterklärung möglich. Für bestimmte Produktklassen mit höherer Cybersecurity-Relevanz gelten jedoch strengere Anforderungen an die Konformitätsbewertung. Die Kommission nennt als Beispiele für wichtige Produkte unter anderem Betriebssysteme, Router oder Firewalls; für kritische Produkte etwa Secure Elements oder Smart-Meter-Gateways. Für Embedded-Hersteller ist deshalb eine frühe Einordnung wichtig, weil sie direkten Einfluss auf Aufwand, Nachweisführung und mögliche Einbindung einer benannten Stelle hat.

Auch Open Source ist beim CRA kein pauschaler Sonderfall. Die Kommission stellt klar: Freie und Open-Source-Software fällt dann in den Anwendungsbereich, wenn sie im Rahmen einer kommerziellen Tätigkeit auf den Markt gebracht wird. Für Embedded-Produkte mit Linux-, Yocto-, Buildroot- oder sonstigen Open-Source-Bausteinen heißt das: Nicht der Open-Source-Charakter allein ist entscheidend, sondern die konkrete Rolle im kommerziellen Produkt.

Der CRA ist nicht nur ein Dokumentations- oder Konformitätsthema. Für Embedded-Projekte bedeutet er vor allem, sicherheitsrelevante technische Fragen frühzeitig und nachvollziehbar beantworten zu können: Welche Angriffsflächen bestehen? Welche Schnittstellen und Dienste sind aktiv? Wie werden Berechtigungen geschützt? Und wie gelangen Sicherheitsupdates zuverlässig ins Feld?

Besonders anspruchsvoll ist das bei komplexeren Software-Stacks, etwa mit Embedded Linux, Android, Treibern, Middleware, Open-Source-Paketen und eigener Applikationslogik. Hier müssen Schwachstellen künftig strukturierter bewertet und betroffene Produktvarianten schneller eingegrenzt werden.

Dafür braucht es vor allem eines: Transparenz über Komponenten, Versionen, Abhängigkeiten und Konfigurationen. Ohne diese Grundlage lassen sich Betroffenheit, Maßnahmen und Updates kaum belastbar steuern.

In der praktischen Umsetzung zeigen sich typischerweise drei Schwachstellen:

• Unklare Produktabgrenzung
  Gerät, Firmware, App, Weboberfläche und Cloud werden organisatorisch oft getrennt entwickelt, regulatorisch aber nicht zwingend getrennt betrachtet. Dadurch entstehen Lücken bei Zuständigkeiten, Bewertung und Dokumentation.

• Nicht ausreichend belastbare Update-Pfade
  Ein Produkt kann nur dann über Jahre sicher betrieben werden, wenn Updates technisch vorgesehen, getestet, dokumentiert und organisatorisch beherrscht sind. Fehlt diese Grundlage, wird die wirksame Schwachstellenbehandlung schnell zum Problem.

• Zu langsame Incident- und Vulnerability-Reaktion
  Zwischen der Kenntnis einer Schwachstelle und der Fähigkeit, Betroffenheit, Risiko, Gegenmaßnahmen und Kommunikation strukturiert zu steuern, liegen in vielen Unternehmen noch zu viele manuelle Schritte. Die kurzen Meldefristen des CRA verschärfen diese Lücke zusätzlich.

Wer den CRA sauber vorbereiten will, sollte nicht mit der CE-Dokumentation beginnen, sondern mit einer Produktaufnahme. Im ersten Schritt sollte geklärt werden, welche Produkte überhaupt in den CRA fallen, welche Funktionen ohne Remote-Verarbeitung nicht lauffähig wären und welche Varianten oder Baugruppen separat betrachtet werden müssen. Danach folgt die technische Einordnung: Produktkategorie, Angriffsflächen, Schnittstellen, Benutzerrollen, Updatewege, Drittkomponenten und Supportmodell. Erst auf dieser Basis wird eine belastbare Risikobewertung sinnvoll.

Im nächsten Schritt sollten Entwicklungs- und Betriebsprozesse überprüft werden: sichere Voreinstellungen, Hardening, Kryptographie, Authentifizierung, Rollen- und Rechtemodelle, Logging, Update-Mechanismen, Schwachstellenmanagement und technische Dokumentation. Parallel lohnt sich der Aufbau eines klaren Meldeprozesses für aktiv ausgenutzte Schwachstellen und schwere Vorfälle, denn dieser Teil greift bereits 2026. Der Punkt ist wichtig: Auch wenn harmonisierte Standards noch weiter ausgearbeitet werden, steht die regulatorische Richtung längst fest. Die Kommission hat 2025 einen Standardisierungsauftrag mit 41 Normungsarbeiten angestoßen und 2026 zusätzliche Leitlinien unter anderem zu Supportzeiträumen und dem Zusammenspiel mit anderen EU-Regelwerken zur Konsultation veröffentlicht. Auf fertige Standards zu warten, ist daher keine sinnvolle Strategie.

Der CRA ist für Embedded-Hersteller vor allem eines: ein Architektur-, Lifecycle- und Prozess-Thema. Wer heute nur auf die spätere Konformitätserklärung schaut, greift zu kurz. Entscheidend ist, ob Produkte technisch so aufgebaut sind, dass Risiken früh bewertet, Komponenten transparent verwaltet, Updates sicher ausgerollt und Schwachstellen über Jahre zuverlässig behandelt werden können. Genau dort trennt sich in der Praxis Compliance auf dem Papier von echter Produktreife. Wir unterstützen Sie gern bei der technischen Umsetzung von CRA-konformen Embedded Projekten.

Für viele Unternehmen ist jetzt der richtige Zeitpunkt, bestehende Plattformen, Redesigns und laufende Embedded-Projekte unter CRA-Gesichtspunkten neu zu bewerten. Denn die Fristen wirken auf den ersten Blick weit entfernt, treffen Entwicklung, Wartung, Dokumentation und Meldeprozesse aber deutlich früher als viele Roadmaps heute abbilden. Eine juristische Einzelfallprüfung ersetzt dieser Beitrag nicht, technisch ist die Richtung jedoch klar: Security-by-Design, belastbare Updatefähigkeit und saubere Schwachstellenprozesse werden zum Marktzugangsthema.