Cyber Resilience Act: Security by Design für Produkte mit digitalen Elementen

TL;DR

• Der Cyber Resilience Act (CRA) verpflichtet Hersteller von „Products with Digital Elements“ (PDE) ab seinem Inkrafttreten am 20. August 2024 zu nachweisbarer Cybersecurity über den gesamten Produktlebenszyklus – von Design über Betrieb bis End-of-Support.
• Produkte werden risikobasiert in nicht klassifiziert, „Important“ (Class I/II) und „Critical“ eingestuft; die Klasse bestimmt, ob eine Selbstbewertung ausreicht oder ein Third-Party-Assessment bzw. eine EU-Zertifizierung nötig wird.
• Kernanforderungen sind Security by Design, vollständige und gepflegte SBOMs, systematisches CVE-Management, strukturierte Update-Strategien mit klar definierten Support-Zeiträumen sowie koordinierte Vulnerability-Disclosure-Prozesse inklusive Meldefristen.
• Der CRA schafft Transparenz in der Supply Chain – auch über nicht-technische Risiken wie Jurisdiktionsabhängigkeiten – und eröffnet europäischen Anbietern die Chance, Sicherheit und Souveränität als Wettbewerbsvorteil zu nutzen.
• ayedo unterstützt Sie praxisnah bei der CRA-Readiness: automatisierte SBOM-Generierung, signierte Build-Pipelines, kontinuierliches Vulnerability Management und ein abgestimmtes Incident- und Support-Modell – bis hin zum strukturierten CRA-Readiness-Check.

Cyber Resilience Act: Einordnung und Zeitplan

Mit dem Cyber Resilience Act etabliert die EU erstmals einen horizontalen Rechtsrahmen für Cybersecurity von Produkten mit digitalen Elementen. Der CRA tritt am 20. August 2024 in Kraft, die meisten Pflichten gelten nach einer Übergangsphase von 36 Monaten – also voraussichtlich ab Spätsommer 2027. Einzelne Teile, insbesondere zu Vulnerability-Disclosure und Meldungen, greifen bereits früher.

Wichtig ist: Der CRA ergänzt bestehende Regelwerke wie NIS2, ersetzt sie aber nicht. Während NIS2 vor allem Betreiber kritischer Dienste adressiert, richtet sich der CRA an Hersteller, Importeure und Händler von Hardware und Software. Wer heute Produkte in Europa platziert, muss künftig nachweisen können, dass Cybersecurity über den gesamten Lebenszyklus strukturiert berücksichtigt wird.

Für technisch verantwortliche Führungskräfte bedeutet das: Cybersecurity wird von einer „guten Praxis“ zu einer rechtlich verbindlichen Produkteigenschaft – mit klaren Anforderungen an Architektur, Prozesse und Dokumentation.

Products with Digital Elements: Anwendungsbereich und Klassifizierung

Was gilt als „Product with Digital Elements“?

Der CRA spricht von „Products with Digital Elements“ (PDE). Gemeint sind:

• klassische Softwareprodukte (on-premise, embedded, teilweise auch SaaS-ähnliche Modelle, sofern sie Teil eines Produkts sind),
• Hardware mit Software-Komponenten (Router, Gateways, Industrie-Controller, vernetzte Geräte),
• Remote-Processing-Komponenten, die für die Funktion des Produkts erforderlich sind (z.B. Cloud-Backends).

Sobald ein Produkt mit anderen Geräten oder Netzwerken verbunden ist, fällt es typischerweise in den CRA-Anwendungsbereich. Rein interne Unternehmenssoftware ohne „Bereitstellung auf dem Markt“ kann ausgenommen sein, aber hybride Szenarien (z.B. OEM-Software, die bei Kunden ausgerollt wird) sind klar in Scope.

Risikobasierte Kategorisierung

Kern des CRA ist eine risikobasierte Einstufung:

• Nicht klassifizierte PDE
  Standardprodukte ohne sicherheitskritische Kernfunktion. Sie unterliegen den allgemeinen CRA-Pflichten, können die Konformität aber in der Regel über eine interne Selbstbewertung nachweisen.

• Important Class I
  Produkte, deren Kernfunktion sicherheitsrelevante Aufgaben erfüllt (z.B. Authentifizierungslösungen, bestimmte Endpoint-Security oder Netzwerkkomponenten). Hier steigen die Anforderungen an Risikoanalyse, Testing und Dokumentation. Selbstbewertung bleibt möglich, sofern harmonisierte Standards konsequent angewendet werden.

• Important Class II
  Produkte mit besonders hoher potentieller Schadenswirkung (z.B. Intrusion-Detection-/Prevention-Systeme, zentrale Sicherheits-Gateways). Für sie sind Third-Party-Assessments durch „Notified Bodies“ verpflichtend, inklusive Prüfung von Produktdesign und Entwicklungsprozessen.

• Critical Products
  Produktkategorien, die per delegiertem Rechtsakt als „Critical“ eingestuft werden, können einer verpflichtenden EU-Zertifizierung (z.B. EUCC auf „substantial“ oder höher) unterliegen. Hier ist eine umfassende Security-Evaluation obligatorisch.

Die Klassifizierung bestimmt also nicht, ob Sie Sicherheit ernst nehmen müssen – das ist immer der Fall –, sondern wie tief Ihr Konformitätsnachweis gehen muss. Strategisch sinnvoll ist es, die eigene Produktpalette frühzeitig zu mappen: Welche PDE haben wir? In welche Kategorien fallen sie voraussichtlich? Welche Konformitätspfade ergeben sich daraus?

Lifecycle-Anforderungen: Security by Design wird Standard

Der vielleicht wichtigste Paradigmenwechsel im CRA ist die konsequente Lifecycle-Perspektive. Cybersecurity ist nicht mehr nur eine Eigenschaft der ausgelieferten Version, sondern des gesamten Produktlebenszyklus.

Secure by Design und Secure by Default

Security by Design wird vom Leitbild zur Pflicht. Der CRA erwartet unter anderem:

• dokumentierte Risikoanalysen und Threat-Modeling bereits in der Konzeption,
• klare Security-Requirements, bevor Implementierung startet,
• Architekturentscheidungen, die Prinzipien wie Least Privilege, Defense in Depth und Zero Trust berücksichtigen,
• sinnvolle Secure-by-Default-Voreinstellungen (z.B. sichere Standard-Konfigurationen, deaktivierte unnötige Schnittstellen).

Für Führungskräfte heißt das: Security muss explizit Teil des Produktentwicklungsprozesses werden – mit klaren Verantwortlichkeiten, Quality-Gates und der nötigen Governance. Informelle „wir machen das schon sicher“-Versprechen sind künftig nicht mehr ausreichend.

SBOM als Fundament der Transparenz

Eine vollständige und gepflegte Software Bill of Materials (SBOM) ist zentrale Voraussetzung, um CRA-Pflichten erfüllen zu können. Ohne SBOM können Sie:

• Sicherheitslücken in Dependencies nicht zielgerichtet bewerten,
• nicht nachweisen, welche Komponenten Sie tatsächlich ausliefern,
• keine belastbare Aussage zu Lizenz- und Supply-Chain-Risiken treffen.

Der CRA verlangt, dass Hersteller wissen, welche Komponenten sie verwenden, wie diese gepflegt werden und wie sie mit Schwachstellen umgehen. Praktisch bedeutet das:

• automatisierte SBOM-Generierung im Build-Prozess,
• Aktualisierung der SBOM bei jeder relevanten Änderung,
• Verknüpfung mit Vulnerability-Scannern und CVE-Datenbanken.

CVE-Management als kontinuierlicher Prozess

Eine SBOM ist nur so wertvoll wie das darauf aufbauende Vulnerability Management. Der CRA fordert:

• systematisches Monitoring relevanter Quellen für neue Schwachstellen,
• Bewertung der Relevanz für das eigene Produkt (Kontext, Exposure, Ausnutzbarkeit),
• priorisierte Planung von Remediation-Maßnahmen (Patches, Konfigurationsänderungen, Workarounds),
• lückenlose Dokumentation der Entscheidungen.

Das ist mehr als „gelegentliches Scannen“. Gefragt ist ein strukturierter CVE-Management-Prozess, der Engineering, Product Management, Legal und Support verbindet – und der im Zweifel gegenüber Behörden und Kunden nachvollziehbar belegt werden kann.

Update-Strategie und Support-Zeiträume

Der CRA schreibt vor, dass Sicherheitsupdates über die erwartete Nutzungsdauer bereitgestellt werden – mit Mindestzeiträumen von mehreren Jahren. In der Praxis bedeutet das:

• definierte Support-Strategien für alle Produktlinien,
• Trennung von Security-Fixes und Feature-Releases, soweit technisch möglich,
• sichere, signierte Update-Mechanismen mit Rollback-Fähigkeiten,
• klare Kommunikation, wie Kunden Updates erhalten und wie lange.

Hier verbinden sich technische und organisatorische Fragen mit Geschäftsmodellen. Wer bisher kurze oder unklare Support-Zyklen hatte, muss diese nun strukturiert definieren und dokumentieren. Das betrifft auch Managed-Angebote und Services; ein sauber definiertes Support-Modell wird zum Compliance-Baustein.

Koordinierte Vulnerability Disclosure: Von „Ad-hoc“ zu Prozess

Der CRA macht koordinierte Vulnerability Disclosure (CVD) zur Pflicht. Hersteller müssen:

• eine öffentlich zugängliche CVD-Policy bereitstellen,
• einen funktionierenden Kontaktpunkt für Vulnerability-Meldungen etablieren,
• eingehende Meldungen strukturiert triagieren und priorisieren,
• Forscherinnen und Forscher bzw. meldende Dritte angemessen einbinden.

Hinzu kommen Meldepflichten gegenüber den Behörden: Schwere Sicherheitsvorfälle und aktiv ausgenutzte Schwachstellen müssen über ein zentrales ENISA-Portal gemeldet werden – in engen Fristen:

• erste Frühwarnung innerhalb von 24 Stunden nach Kenntnis,
• ein strukturierter Incident-Report innerhalb von 72 Stunden,
• ein Abschlussbericht mit Root-Cause-Analyse innerhalb von 30 Tagen,
• bei aktiv ausgenutzten Schwachstellen regelmäßige Status-Updates, insbesondere nach Bereitstellung von Patches oder Workarounds.

Für Organisationen bedeutet das: Incident Response und Vulnerability Management dürfen kein rein technisches Thema des Ops-Teams bleiben. Es braucht klar definierte Rollen, Eskalationspfade und vorbereitete Kommunikationslinien – nach innen wie nach außen.

Supply-Chain-Transparenz: Technische und nicht-technische Risiken

Der CRA greift eine Realität auf, die viele Engineering-Teams längst spüren: Die eigentlichen Risiken liegen oft nicht im eigenen Code, sondern in der Supply Chain.

Technische Supply-Chain-Risiken

Technisch adressiert der CRA insbesondere:

• Transparenz über alle eingesetzten Komponenten (SBOM),
• Nachvollziehbarkeit der Herkunft (Repositories, Hersteller, Maintainer),
• Anforderungen an sichere Update-Quellen und Signaturketten,
• Verantwortlichkeiten bei Sicherheitslücken in Dritthersteller- oder Open-Source-Komponenten.

Wird eine kritische Schwachstelle in einer Komponente bekannt, müssen Sie als Hersteller:

• die Relevanz für Ihre Produkte bewerten,
• Maintainer und Zulieferer informieren, falls nötig,
• Ihre Kunden über Risiko und Maßnahmen auf dem Laufenden halten.

Nicht-technische Risikofaktoren und digitale Souveränität

Besonders interessant ist die explizite Öffnung für nicht-technische Risikofaktoren: Jurisdiktion, staatliche Einflussmöglichkeiten, wirtschaftliche Abhängigkeiten. Daraus ergibt sich:

• Abhängigkeiten von Anbietern in „High-Risk“-Jurisdiktionen können regulatorisch relevant werden,
• EU-basierte Alternativen gewinnen an Gewicht, insbesondere in sicherheitskritischen Bereichen,
• Multi-Sourcing-Strategien und Transparenz über Sub-Supplier werden gestärkt.

Damit verbindet der CRA Cybersecurity mit digitaler Souveränität. Für europäische Technologieanbieter ist das eine strukturelle Chance: Wer transparente, nachvollziehbare Lieferketten mit hoher Resilienz anbieten kann, punktet nicht nur bei Compliance, sondern auch bei der Vertrauensbildung.

Organisatorische Weichenstellungen für CRA-Compliance

Die technischen Anforderungen sind nur die eine Seite. Ebenso entscheidend ist, wie Sie sich organisatorisch aufstellen. Drei Hebel sind erfahrungsgemäß besonders wirkungsvoll:

1. Produkt-Mapping und Klassifizierung
   Erstellen Sie eine Übersicht aller Produkte und Komponenten, die in den EU-Markt gelangen. Ordnen Sie sie vorläufig den CRA-Kategorien zu und leiten Sie daraus ab, wo voraussichtlich Third-Party-Assessment oder Zertifizierung nötig wird.

2. Lifecycle-Governance etablieren
   Ergänzen Sie Ihren Produktentwicklungsprozess um explizite Security-Gates: Anforderungen, Architekturreviews, SBOM- und CVE-Checks, Freigabekriterien für Releases. Wichtig ist, dass diese Schritte dokumentiert und auditierbar sind.

3. Incident- und Vulnerability-Organisation definieren
   Legen Sie fest, wer bei Sicherheitsmeldungen entscheidet, wer kommuniziert, wer mit Behörden interagiert. Stimmen Sie diese Strukturen mit bestehenden NIS2-, Datenschutz- und internen Krisenprozessen ab. Ziel ist ein integrierter, aber schlanker Governance-Rahmen.

Wer früh beginnt, diese Strukturen aufzubauen, kann den CRA nutzen, um bestehende Security-Initiativen zu konsolidieren – statt kurzfristig auf regulatorische „Fire Drills“ reagieren zu müssen.

Häufige Fragen

Betrifft der CRA auch reine SaaS-Produkte?

Der CRA adressiert in erster Linie Produkte, die auf dem EU-Markt bereitgestellt werden – also Hardware und Software, die Kunden erwerben, mieten oder anderweitig nutzen. Reine SaaS-Angebote ohne Produktcharakter können je nach Ausgestaltung außerhalb des unmittelbaren Fokus liegen, insbesondere wenn sie eher als Dienstleistung im Sinne von NIS2 gelten.

In der Praxis ist die Trennlinie jedoch oft nicht scharf: Viele SaaS-Angebote enthalten Komponenten, die als Product with Digital Elements gelten (z.B. Agenten, Appliances, Client-Software). Zudem erwarten Kunden zunehmend CRA-konforme Praktiken auch von Dienstleistern. Strategisch sinnvoll ist es daher, zentrale CRA-Prinzipien – SBOM, CVE-Management, CVD – auch für SaaS konsequent umzusetzen.

Wie unterscheidet sich der CRA von NIS2 in der Verantwortung?

NIS2 richtet sich primär an Betreiber wesentlicher und wichtiger Dienste (z.B. Energie, Gesundheit, Cloud-Provider), der CRA an Hersteller, Importeure und Händler von Produkten mit digitalen Elementen. Beide Regelwerke ergänzen sich:

• CRA: Fokus auf sichere Produkte über den Lebenszyklus, Lieferketten-Transparenz, Konformität vor Markteintritt.
• NIS2: Fokus auf sichere Dienstleistungen und Betriebsprozesse, Risikomanagement und Incident-Reporting im Betrieb.

Für viele Unternehmen gelten beide Regime parallel: Sie betreiben kritische Dienste (NIS2) und entwickeln gleichzeitig Produkte (CRA). In diesem Fall lohnt es sich, Governance, Prozesse und Tooling so zu gestalten, dass sie beide Regulierungen integrieren – statt zwei getrennte Welten aufzubauen.

Wie unterstützt ayedo konkret bei der CRA-Readiness?

ayedo fokussiert sich auf die praktische Umsetzung der regulatorischen Anforderungen in modernen, oft containerisierten und cloud-nativen Umgebungen. Typische Bausteine sind:

• Integration von SBOM-Generierung in bestehende Build- und Release-Pipelines,
• signierte Builds und Artefaktketten, die Supply-Chain-Integrität nachweisbar machen,
• kontinuierliches Vulnerability Management mit Priorisierung, Tracking und Nachweisführung,
• Unterstützung beim Design von CVD-Prozessen, Incident-Workflows und der technischen Umsetzung (z.B. Log- und Telemetrie-Strategien),
• abgestimmte Support-Modelle, die CRA-konforme Support-Zeiträume, SLAs und Prozesse berücksichtigen.

Ziel ist nicht, zusätzliche Bürokratie zu erzeugen, sondern bestehende Engineering-Workflows so zu erweitern, dass CRA-Compliance ein natürlicher Teil des Tagesgeschäfts wird.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Der CRA bringt viel von dem, was verantwortungsvolle Engineering-Teams seit Jahren anstreben, nun in einen verbindlichen Rahmen: Security by Design, Transparenz in der Supply Chain, nachvollziehbare Prozesse für Schwachstellen und Incidents. Für europäische Anbieter ist das eine Möglichkeit, Qualität und Vertrauenswürdigkeit strukturiert nach außen zu belegen.

ayedo versteht Compliance in diesem Kontext als Architektur- und Prozessaufgabe, nicht als reines Dokumentationsthema. In gemeinsamen Projekten konzentrieren wir uns darauf,

• Security-Anforderungen in Ihre bestehenden Produkt- und Plattform-Architekturen zu integrieren,
• Build- und Delivery-Pipelines so zu gestalten, dass SBOMs, Signaturen und CVE-Checks automatisch entstehen,
• Incident-Response- und Vulnerability-Prozesse mit Ihren Teams, Tools und regulatorischen Pflichten zu verzahnen,
• Support- und Betriebsmodelle so zu definieren, dass sie CRA-konforme Support-Zeiträume und Update-Strategien abbilden – auch in komplexen, verteilten Infrastrukturen.

Ob Sie eine bestehende Produktlinie schrittweise anpassen oder eine neue Plattform mit Blick auf CRA und NIS2 planen: Entscheidend ist, früh klar zu strukturieren, was Sie wo nachweisen müssen – und wie Sie diesen Nachweis technisch elegant in Ihren Alltag integrieren.

Wenn Sie den nächsten Schritt gehen wollen, ist ein strukturierter Blick von außen oft hilfreich. Gemeinsam identifizieren wir, welche Ihrer Produkte unter den CRA fallen, welche Prozesse verstärkt werden müssen und welche technischen Maßnahmen am meisten Wirkung entfalten. Der Einstiegspunkt dafür ist unser CRA-Readiness-Check.