Cyber Resilience Act: Was der CRA für Ihr Produkt bedeutet

Der Cyber Resilience Act (CRA), die Verordnung (EU) 2024/2847, ist die erste EU-weite Verordnung, die verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen über deren gesamten Lebenszyklus festlegt – von der Konzeption über die Marktbereitstellung bis zum Ende des Supportzeitraums. Sein Ziel ist klar formuliert: Security by Design und Security by Default. Sicherheit soll bereits in Entwicklung und Produktion integriert sein, kritische Schwachstellen frühzeitig erkannt und behoben werden und Hersteller sollen Sicherheitsupdates über einen angemessenen Supportzeitraum bereitstellen. Konkret bedeutet das die Verankerung eines „Secure Development Lifecycle“, systematisches Threat-Modeling, sichere Default-Konfigurationen und dokumentierte Härtungsmaßnahmen. Was in Softwarehäusern als Best Practice bekannt ist, wird durch den CRA zur rechtlich verbindlichen, nachweispflichtigen Anforderung.

Bemerkenswert ist, wie der CRA einen bekannten regulatorischen Ansatz weiterdenkt. Das CE-Kennzeichnungsregime, das viele Unternehmen aus der Produktsicherheitsrichtlinie oder der Maschinenverordnung kennen, wird auf Cybersicherheit übertragen. Damit verlässt Cybersicherheit den Status einer optionalen Qualitätseigenschaft und wird zu einer nachweispflichtigen Grundvoraussetzung für den Marktzugang in der EU.

Welche Produkte fallen unter den Cyber Resilience Act?

Der Anwendungsbereich des Cyber Resilience Acts ist bewusst breit gefasst, aber nicht grenzenlos. Erfasst sind Hardware und Softwareprodukte, die auf dem EU-Markt bereitgestellt werden und deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst. Damit reicht der CRA von klassischer Hardware mit eingebetteter Firmware über mobile Apps und installierbare Programme bis zu komplexen Hardware- und Softwaresystemen. Entscheidend ist nicht bloße Elektronik, sondern die Fähigkeit zum Austausch digitaler Informationen. Ausgenommen sind eng definierte Bereiche wie Medizinprodukte, Kraftfahrzeuge oder zivile Luftfahrt, die eigenen Sektorregimen unterliegen.

Bis wann muss der Cyber Resilience Act umgesetzt werden?

Die Umsetzung des CRA erfolgt in Etappen. Wer jedoch sein Produkt nach dem 11. Dezember 2027 ohne CRA-Konformität in Verkehr bringt, riskiert nicht nur Bußgelder, sondern den Marktzugang selbst.

Die zeitliche Staffelung ist bewusst gewählt, um Unternehmen Vorlaufzeit zu geben. Die folgende Übersicht zeigt die zentralen Etappen von 2024 bis 2027:

Auf den ersten Blick wirkt die Übergangsfrist großzügig. In der Praxis täuscht dieser Eindruck. Produktentwicklungszyklen in kritischen Branchen wie Energieversorgung, industrielle Automatisierung oder Medizintechnik-nahe Systeme dauern häufig drei bis fünf Jahre. Wer heute ein neues Produkt spezifiziert, das 2028 oder 2029 in Verkehr gebracht werden soll, entwickelt es faktisch bereits unter CRA-Regime. Die Frage ist nicht mehr, ob CRA-Anforderungen ins Lastenheft gehören, sondern ob sie dort strukturiert oder nachträglich landen. Nachträgliche CRA-Integration ist erfahrungsgemäß um ein Vielfaches aufwendiger als das Mitdenken im Design. Wer laufende Entwicklungsprojekte hat, sollte seine Design-Reviews jetzt mit einer CRA-Gap-Analyse koppeln und die Ergebnisse in die Roadmap integrieren.

Der CRA verteilt die Verantwortung entlang der gesamten Lieferkette auf vier Wirtschaftsakteure:

• Hersteller: Hauptverantwortung für Sicherheit, Konformität und CE-Kennzeichnung
• Bevollmächtigter: Vertreter für Hersteller außerhalb der EU, zuständig für Dokumentation und Behördenkontakt
• Einführer: Sicherstellung von Konformität und Kennzeichnung bei Importen aus Drittstaaten
• Händler: Kontrolle von CE-Kennzeichnung und Unterlagen, Vertrieb nur konformer Produkte

Jede Rolle hat klar abgegrenzte Pflichten und für jede Rolle gilt, wer sie einnimmt, muss die entsprechenden Nachweise erbringen. Unabhängig von der eigenen Größe, dem Branchenkontext oder der Selbstwahrnehmung als Vertrieb, Integrator oder Reseller. Hier ein Überblick über die vier Rollen:

Hersteller

Der Hersteller nach Art 13 trägt die Hauptverantwortung. Er verantwortet Design, Entwicklung, Sicherheit und Updates, führt die Risikoanalyse durch, erstellt die technische Dokumentation, führt die Konformitätsbewertung durch, stellt die EU-Konformitätserklärung aus und bringt die CE-Kennzeichnung an. Über den gesamten Produktlebenszyklus hinweg bleibt er für Schwachstellenmanagement und Sicherheitsupdates verantwortlich. Der Hersteller ist damit die einzige Rolle, die vollumfänglich für die Sicherheit des Produkts einsteht. Hier ein Überblick, was der Aufgabenbereich konkret umfasst:

Sicherheit über den gesamten Lebenszyklus ist der Kern des CRA; entsprechend sollten Sicherheitsmaßnahmen schon eingangs fest in Entwicklung und Produktion integriert sein. Der Hersteller identifiziert und minimiert Risiken, stellt Sicherheitsupdates über den Supportzeitraum bereit und kommuniziert dessen Umfang und Dauer transparent an den Käufer. Der Supportzeitraum muss dabei zur erwarteten Lebensdauer passen; in der Praxis haben sich fünf Jahre als Default etabliert, bei langlebigen Produkten wie Ladesäulen oder industriellen Steuerungen sind zehn Jahre und mehr üblich.

Informations- und Meldepflichten verlangen aktive Kommunikation nach außen. Aktiv ausgenutzte Schwachstellen und schwere Vorfälle sind gestuft an den zuständigen CSIRT-Koordinator und ENISA zu melden:

• Frühwarnung binnen 24 Stunden
• Meldung binnen 72 Stunden
• Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Korrektur (bei schweren Vorfällen spätestens einen Monat nach der 72-Stunden-Meldung)

Wer diese Fristen operationalisieren will, braucht einen strukturierten Vulnerability-Handling-Prozess nach dem Vorbild von ISO 30111 und ISO 29147, organisatorisch meist gebündelt in einem „Product Security Incident Response Team“ (PSIRT). Hinzu kommen Nutzerinformationen wie Anleitungen und Sicherheitshinweise sowie die Kooperation mit Marktüberwachungsbehörden.

Die Technische Dokumentation ist die Compliance-Grundlage. Sie umfasst Produktbeschreibung, Risikobewertung, Testergebnisse und das Bewertungsverfahren nach Anhang VIII, wird bei Produktänderungen aktualisiert, mindestens zehn Jahre nach Inverkehrbringen aufbewahrt und den Behörden auf Anforderung vorgelegt. Zentrales Artefakt ist die „Software Bill of Materials“ (SBOM): eine vollständige Liste aller Softwarekomponenten inklusive Versionsständen und damit das Rückgrat moderner Supply-Chain-Security. Ohne SBOM lässt sich weder eine belastbare Schwachstellenanalyse durchführen noch die Auswirkung neuer CVEs schnell bewerten. Wer sie früh systematisch aufbaut, spart in Konformitätsbewertungen und bei Behördenanfragen erheblichen Aufwand – und hat zugleich ein starkes Argument in Ausschreibungen bei NIS2-pflichtigen Kunden.

Konformität und CE-Kennzeichnung schließen den Katalog sichtbar ab. Nach der Konformitätsbewertung stellt der Hersteller die EU-Konformitätserklärung aus und bringt die CE-Kennzeichnung an. Bei Software erfolgt sie nicht physisch am Produkt, sondern über die EU-Konformitätserklärung oder eine leicht zugängliche begleitende Website.

Bevollmächtigter

Der Bevollmächtigte nach Art 18 handelt im Auftrag des Herstellers und wird typischerweise dann relevant, wenn der Hersteller außerhalb der EU sitzt. Er hält technische Dokumentation und Konformitätserklärung für Behörden bereit, ist Ansprechpartner für Marktüberwachungsbehörden und übernimmt eine eigene zehnjährige Aufbewahrungspflicht für Kopien der Konformitätserklärung. Für internationale Hersteller ist die sorgfältige Auswahl eines qualifizierten Bevollmächtigten in der EU eine der ersten operativen Weichenstellungen.

Einführer

Der Einführer nach Art 19 stellt sicher, dass Drittland-Produkte CRA-konform sind, bevor sie auf den EU-Markt gelangen. Er prüft die CE-Kennzeichnung und die Verfügbarkeit der Konformitätserklärung, meldet erkannte Risiken an den Hersteller, Bevollmächtigte und Marktüberwachungsbehörden und wirkt bei Marktüberwachungsmaßnahmen mit. Der Einführer wird damit zum Türsteher an der EU-Grenze.

Händler

Der Händler nach Art 20 prüft vor der Bereitstellung, ob CE-Kennzeichnung und Konformitätserklärung vorhanden sind, und darf offensichtlich nicht-konforme Produkte nicht vertreiben. Bei bekannten Risiken muss er unverzüglich Hersteller und Behörden informieren. Er trägt keine eigenen Entwicklungs- oder Sicherheitspflichten, ist aber ein wichtiges Glied in der Melde- und Marktüberwachungskette.

Neben diesen vier Akteuren kennt der CRA außerdem die Figur des „Open Source Software Stewards“, die für Organisationen relevant wird, die kommerziell relevante Open-Source-Komponenten in erheblichem Umfang unterstützen. Für die überwiegende Mehrheit der Unternehmen bleibt jedoch das Vier-Rollen-Modell der wesentliche Bezugsrahmen.

Die folgende Detailmatrix zeigt, wie sich die konkreten und häufig unterschätzten Pflichten für Bevollmächtigte, Einführer und Händler unterscheiden:

Einblick aus der Praxis: Starre Rollen sind nicht die Norm

Ein wesentlicher Punkt in der Praxis ist, dass Rollen nicht statisch sind. Wir sehen in Projekten regelmäßig, dass Unternehmen, die sich selbst als reine Händler oder Integratoren verstehen, unter dem CRA in die Herstellerrolle rutschen. Konkrete Auslöser sind die Bündelung fremder Produkte zu einem Systempaket und Vertrieb unter eigenem Namen, die Modifikation von Firmware oder Konfiguration über Standardparameter hinaus, das Vertreiben von Drittland-Produkten unter eigener Marke (Private Labeling) oder die Integration in eine Managed Lösung mit sicherheitsrelevanten Konfigurationsänderungen. In allen vier Fällen verändert sich die rechtliche Rolle oft, ohne dass es intern bewusst wahrgenommen wird.

Für viele Unternehmen bedeutet das eine grundsätzliche Neubewertung. Wer bin ich unter dem CRA und in welcher Konstellation? Die Antwort ist nicht immer dieselbe. Ein Unternehmen kann für Produkt A Hersteller sein, für Produkt B nur Händler und für Produkt C, ein Bundle, wieder Hersteller. Diese Rollenlandkarte gehört an den Anfang jeder CRA-Umsetzung. In der Praxis lohnt sich ein strukturierter Workshop mit Vertreter:innen aus Produktmanagement, Vertrieb, Einkauf und Recht, dessen Ergebnisse im Laufe der folgenden zwei Jahre regelmäßig aktualisiert werden.

Nicht jedes Produkt durchläuft dieselbe Konformitätsbewertung. Der CRA unterscheidet drei Klassen, die den Prüfaufwand steuern. Die folgende Übersicht zeigt die Entscheidungspfade von der Grundeinstufung bis zur passenden Konformitätsbewertung.

• Standardprodukte bilden die breite Basis. Für sie genügen Selbstbewertung und interne Kontrolle auf Basis der grundlegenden Anforderungen aus Anhang I. Die überwiegende Mehrheit der Produkte mit digitalen Elementen fällt hierunter. Niedrig sind die Anforderungen deshalb nicht: Auch Standardprodukte müssen die grundlegenden Cybersicherheitsanforderungen erfüllen, dokumentieren und über den Lebenszyklus aufrechterhalten.

• Wichtige Produkte (Klasse I und II, Anhang III) haben höheres Sicherheitspotenzial, etwa Passwort-Manager, Firewalls, Netzwerküberwachungssysteme, VPN-Software oder Managementsysteme für Netzwerkkonfigurationen. Klasse I lässt sich bei Anwendung eines harmonisierten Standards noch über interne Kontrolle abdecken, Klasse II erfordert typischerweise eine externe Konformitätsprüfung. Maßgeblich ist, wie tief das Produkt in die Sicherheitsarchitektur des Kunden eingreift.

• Kritische Produkte (Anhang IV) unterliegen der strengsten Prüfung, etwa Hardware-Security-Modules, Smart-Meter-Gateways oder Sicherheitschips für Ausweise. Hier verlangt der CRA eine Konformitätsbewertung durch eine benannte Zertifizierungsstelle, in der Regel über ein europäisches Cybersicherheits-Zertifizierungssystem nach dem Cybersecurity Act. Selbstbewertung reicht nicht mehr aus; unabhängige Dritte prüfen und bestätigen die Konformität.

Der eigentliche Aufwand liegt für viele Unternehmen nicht in der Konformitätsbewertung selbst, sondern im Vorfeld, bei der korrekten Einstufung der eigenen Produktlandschaft. Ein Portfolio mit 40 bis 200 Produktvarianten wird zum ersten Mal systematisch nach CRA-Kriterien inventarisiert. Der Großteil fällt als Standardprodukte in die Selbstbewertung. Ein signifikanter Anteil landet in Klasse I oder II und löst Prozess und Dokumentationsaufwand aus. Eine kleinere, aber kritische Menge erweist sich als Anhang IV – oft überraschend, weil sicherheitsrelevante Komponenten in scheinbar unkritischen Produkten versteckt sind. Und eine nicht unerhebliche Restmenge fällt aus dem CRA-Scope heraus, was ebenfalls belegt und dokumentiert werden muss.

Die eigentliche Kunst liegt in einer belastbaren Produkt-Taxonomie, die dieselbe Sprache spricht wie Produktmanagement, Entwicklung, Vertrieb und Compliance. Wer diese Taxonomie einmal sauber aufsetzt, hat für die kommenden Jahre einen wiederverwendbaren Rahmen, der weit über die reine CRA-Umsetzung hinaus Wert stiftet. Er kann als Grundlage für Investitionsentscheidungen, Portfolio-Rationalisierung, Roadmap-Planung und M&A-Due-Diligence dienen.

Wesentliche Änderung: Wann aus einem Update ein neues Produkt wird

Ein Produkt ist in Verkehr gebracht, CE-gekennzeichnet, dokumentiert – und dann kommt das erste Firmware-Update. Bedeutet das eine neue Konformitätsbewertung? Die Antwort steckt im Begriff der wesentlichen Änderung nach Art 3 Z 30. Drei Kriterien müssen kumulativ erfüllt sein:

• Die Änderung erfolgt nach dem Inverkehrbringen.
• Sie war in der ursprünglichen technischen Dokumentation nicht antizipiert.
• Sie berührt die grundlegenden Cybersicherheitsanforderungen nach Anhang I Teil I oder ändert den Verwendungszweck.

Anhang I Teil I bündelt 13 grundlegende Cybersicherheitsanforderungen. Wer sie kennt, kann Änderungen strukturiert bewerten und nachvollziehbar begründen, warum eine bestimmte Modifikation die Schwelle zur wesentlichen Änderung überschreitet oder nicht. Jede Änderung wird gegen diese 13 Punkte geprüft. Wird keiner der 13 Punkte berührt, liegt keine wesentliche Änderung vor. Wird mindestens einer der 13 Punkte berührt, ist eine weitere Wirkungsprüfung erforderlich. Die 13 essenziellen Cybersicherheitsanforderungen sind:

• Keine ausnutzbaren Schwachstellen: Auslieferung ohne offene CVEs
• Secure by Default: sichere Werkseinstellungen, Reset-Möglichkeit
• Sichere Update-Mechanismen: automatische Sicherheitsupdates, Opt-out-Möglichkeit, Nutzerinformation
• Zugriffskontrolle: Authentifizierung, IAM, Reporting bei unautorisiertem Zugriff
• Vertraulichkeit: Verschlüsselung „at rest“ und „in transit“
• Integrität: Schutz gegen Manipulation von Daten, Code und Konfiguration
• Datenminimierung: nur zweckgebundene, notwendige Daten verarbeiten
• Verfügbarkeit: Resilienz, DoS-Schutz, Kernfunktionen auch nach einem Vorfall
• Minimale Auswirkung auf andere Systeme: keine Beeinträchtigung fremder Dienste oder Geräte
• Minimale Angriffsfläche: Reduzierung externer Schnittstellen
• Exploit-Mitigation: Härtungstechniken, Schutzmechanismen gegen Angriffe
• Logging und Monitoring: Aufzeichnung sicherheitsrelevanter Aktivitäten
• Sichere Datenlöschung: Nutzer:innen können Daten und Einstellungen dauerhaft entfernen.

Nur wenn alle drei Kriterien für eine wesentliche Änderung nach Art 3 Z 30 zutreffen, liegt eine wesentliche Änderung vor. Reine Software-Updates, CVE-Patches oder UI-Fixes bleiben in aller Regel darunter. Wesentlich wird eine Änderung erst, wenn sie einen neuen Angriffsvektor öffnet, etwa durch eine neue Schnittstelle, einen neuen Remote-Zugriffskanal, einen neuen Datenverarbeitungspfad in die Cloud oder den Wegfall einer Krypto- und Härtungskonfiguration, oder wenn sich der Verwendungszweck ändert, etwa vom Consumer- zum Industrieprodukt oder von passivem Monitoring zu aktiver Steuerung.

Die folgende Schwellen-Übersicht bringt Änderungen in drei Kategorien und macht die Bewertung praktisch anwendbar:

CRA: Die zwei Auslöser für eine wesentliche Änderung

Die wesentliche Änderung ist damit weniger eine reine Compliance-Frage als eine Design-Entscheidung. Wer den Kernzweck seines Produkts präzise definiert und in der technischen Dokumentation ein antizipiertes Update-Framework hinterlegt, verschiebt die Wesentlichkeitsgrenze zulässig nach hinten. Ein eng definierter Zweck macht viele Änderungen wesentlich und führt zu hohem Re-Zertifizierungsaufwand. Ein weit definierter Zweck mit dokumentierten Erweiterungspfaden hält mehr Änderungen im Regelbetrieb und führt zu weniger Neubewertungen.

Der CRA ist kein Bremsklotz für Updates. Entscheidend ist, Änderungen frühzeitig zu antizipieren und in der technischen Dokumentation vorzusehen. Gerade bei langlebigen Produkten wie Ladesäulen, SCADA-Komponenten oder industriellen Steuerungen kann sonst nahezu jede größere Firmware-Iteration eine Neubewertung auslösen. Technische Dokumentation, Update-Roadmap und die dokumentierte Bewertung jedes Releases sollten daher eng verzahnt sein.

Kaum ein Thema löst in unseren Projekten mehr Diskussion aus als die Frage, wann Cloud oder SaaS unter den CRA fallen. Die Ausgangslage ist verkürzt klar. Reine SaaS-Dienste liegen nicht unmittelbar im CRA-Scope. Cloud-Computing-Dienste und Cloud-Dienstmodelle wie SaaS, PaaS und IaaS werden in der CRA-Systematik der NIS2-Richtlinie zugeordnet, soweit deren Voraussetzungen erfüllt sind. Genauer betrachtet ist diese Trennung aber nicht binär. Der CRA kann indirekt auf Cloud- und SaaS-Angebote zurückwirken, sobald Integrationen, Update-Prozesse oder gebündelte Produktkomponenten ins Spiel kommen. Und in modernen digitalen Produkten ist genau das der Regelfall, nicht die Ausnahme.

Cloud-Komponenten im CRA-Kontext

Um zu verstehen, wie unterschiedlich Cloud-Komponenten unter dem CRA einzuordnen sind, hilft der Blick auf die sechs typischen Ausprägungen, von reinem Zusatznutzen bis zur zwingenden Produktfunktion:

Fällt nicht unter CRA:

• Eigenständiger Cloud-Dienst: Die Cloud ist selbst die eigentliche Leistung. Es gibt kein physisches oder digitales Produkt, das ohne die Cloud seine Funktion verlieren würde. Beispiele sind browserbasierte Zeiterfassungssysteme oder CRM-Lösungen.
  
  
• Cloud als Zugangsschicht: Die Cloud stellt lediglich den Zugang, ein Portal oder eine Benutzeroberfläche bereit, übernimmt aber keine eigentliche Produktfunktion. Beispiel: Ein Web-Portal zur Anzeige oder Verwaltung von Daten.
  
  
• Cloud als Zusatznutzen: Die Cloud ergänzt Komfortfunktionen wie Synchronisation, Reporting oder Fernzugriff. Das Produkt bleibt jedoch auch ohne Cloud voll nutzbar. Beispiel: Ein Gerät mit optionalem Reporting-Dashboard.

Kann unter CRA fallen:

• Cloud aus Herstellerhand: Die Cloud wird vom Hersteller bereitgestellt oder verantwortet. Dadurch rückt sie näher an das Produkt heran. Beispiele sind Hersteller-Backends für mobile Apps oder vernetzte Geräte.
  
  
• Cloud als Produktfunktion: Die Cloud übernimmt Teile der eigentlichen Leistungserbringung, etwa Steuerung, Backend-Logik oder Authentifizierung. Sie ist nicht mehr bloßer Zusatznutzen, sondern Teil der Lösung.

Fällt unter CRA:

• Cloud als notwendiger Bestandteil: Ohne die Cloud verliert das Produkt eine wesentliche Funktion oder ist gar nicht mehr nutzbar. Beispiel: Ein vernetztes Produkt, das ohne Hersteller-Backend weder gesteuert noch aktualisiert werden kann.

Die Einordnung ist daher selten eine reine Ja-Nein-Entscheidung. Maßgeblich ist, ob die Cloud lediglich unterstützende Funktionen bereitstellt oder ob das Produkt ohne sie seine Kernfunktion verliert. Je stärker die Cloud für Steuerung, Logik oder Authentifizierung benötigt wird, desto eher fällt sie in den Anwendungsbereich des CRA.

Der Grenzfall: Wann wird eine Cloud-Komponente zur Remote Data Processing Solution?

Für den formalen Grenzfall definiert der CRA den Begriff der Datenfernverarbeitungslösung bzw. „Remote Data Processing Solution“ (RDPS). Eine Cloud-Komponente wird nur dann Teil eines CRA-Produkts, wenn sie drei Bedingungen kumulativ erfüllt:

• At a distance: die Verarbeitung erfolgt außerhalb des Nutzergeräts, also in Cloud oder Edge

• Needed for a function: ohne den Service verliert das Produkt eine Kernfunktion

• Built by or for you: die Komponente wurde vom Hersteller oder unter dessen Verantwortung entwickelt

Damit lassen sich Cloud-Komponenten in drei Kategorien einordnen:

• RDPS im CRA-Scope: etwa ein vom Hersteller betriebenes Backend, ohne das ein IoT-Gerät oder -Gateway nicht steuerbar ist – die Komponente wird Teil des Produkts, fließt in Risikobewertung, technische Dokumentation, Konformitätsbewertung und Vulnerability-Management ein und muss über den Supportzeitraum aufrechterhalten werden

• Komponente mit Due-Diligence-Pflicht: etwa integriertes oder lizenziertes Fremd-SaaS (z. B. für Threat Intelligence) – die Komponente ist kein RDPS, verlangt aber eine dokumentierte Lieferanten-Due-Diligence nach Art 13 Z 5

• Out of Scope: etwa reine Konnektivität wie 5G oder WLAN, interne IT wie CRM oder CI/CD oder etwa eine Industriesoftware mit optionalem Cloud-Reporting-Dashboard, die vollständig lokal funktioniert, wobei das Dashboard ein Zusatznutzen und keine Kernfunktion ist – es greift keine unmittelbare CRA-Pflicht, wohl aber möglicherweise NIS2 oder branchenspezifische Anforderungen

Der RDPS-Test zwingt zu einer klaren Architekturentscheidung, die im Produktdesign fällt, nicht in der Compliance-Abteilung: Welche Cloud-Bausteine sind Teil des Produkts und damit über Jahre CRA-pflichtig, welche bleiben abgegrenzte Dienste?

Der eigentliche Wert des Tests liegt darin, dass er saubere Grenzen erzwingt. Zwischen Produktarchitektur und Servicearchitektur, zwischen Hersteller- und Betreiberrolle, zwischen CRA-Verantwortung und Vertragsmanagement. Wer die Grenzen früh setzt, kann sein Angebot präziser gestalten, sauberer bepreisen und rechtssicher vertreiben.

Während der CRA das Produkt vor der Marktbereitstellung adressiert, verpflichtet die NIS2-Richtlinie ((EU) 2022/2555) Unternehmen zu einem systematischen Cybersicherheitsmanagement. Dazu zählen etwa erweiterte Anforderungen an leitende Organe hinsichtlich Compliance und Risk-Management, risikobasierte technische und organisatorische Sicherheitsmaßnahmen sowie klare Prozesse für den Umgang mit Sicherheitsvorfällen und deren fristgerechte Meldung.

In Österreich wurde die Richtlinie mit dem Netz- und Informationssystemsicherheitsgesetz 2026, NISG 2026, BGBl. I Nr. 94/2025, umgesetzt. Das Gesetz wurde am 12. Dezember 2025 mit Zweidrittelmehrheit beschlossen und tritt am 1. Oktober 2026 in Kraft. Rund 4.000 Einrichtungen aus 18 Sektoren fallen in den Anwendungsbereich. Die Registrierung beim neu geschaffenen Bundesamt für Cybersicherheit im BMI ist bis 1. Jänner 2027 abzuschließen.

Der zeitliche Zusammenfall ist bemerkenswert: Zwischen dem Start der CRA-Meldepflichten 11. September 2026 und dem Inkrafttreten des NISG 2026 am 1. Oktober 2026 liegen keine drei Wochen. Für Unternehmen im DACH-Raum bedeutet das, die Rollenklärung entlang des eigenen Stacks ist keine akademische Übung mehr, sondern ein operativer Pflichttermin mit direkten Konsequenzen für Beschaffung, Vertragsgestaltung und Lieferantenmanagement. Wer im Herbst 2026 noch überlegt, welche Rollen sein Unternehmen unter welchem Regime spielt, wird von den Fristen überholt.

CRA & NIS2: Der SAP-Stack als Anschauungsobjekt

Um das Zusammenspiel greifbar zu machen, denken wir uns den SAP-Stack als ein vertikal gestapeltes System:

• Ganz oben: der SAP-Client, eine installierbare Softwareanwendung, die der Hersteller in Verkehr bringt
• Ganz unten: die SAP-Serverlandschaft mit Applikationsserver, Datenbanken, Netzwerk, Berechtigungen und Backup

Zwischen beiden Ebenen liegt ein vertikaler Regler. Oben steht CRA, unten NIS2. Wichtig: Der Regler markiert keine technische Schicht, sondern eine Verantwortungsgrenze, oben Produktkonformität, unten Governance und sicherer Betrieb. In der Grundeinstellung teilen sich beide Regime den Stack sauber auf. Je nach Bereitstellungsmodell wandert der Regler jedoch nach oben oder unten und verschiebt die Verantwortung mit sich. Die drei folgenden Szenarien zeigen jeweils, wohin er wandert; die zugehörigen Abbildungen halten die Verantwortungsverteilung fest.

Szenario 1: Der Regler steht mittig – die Standardaufteilung

Ein installierbarer SAP-Client ist CRA-Terrain, sobald er als Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird, mit Konformitätsbewertung, CE-Kennzeichnung, SBOM-bezogener Dokumentation, Update-Zusage im Supportzeitraum und dem gestuften Meldeverfahren an CSIRT und ENISA. Die SAP-Serverlandschaft dagegen ist Teil der Netz- und Informationssysteme des Betreibers; ihre Sicherheit entscheidet sich nicht am Marktbereitstellungspunkt, sondern über Risikomanagement, Zugriffskontrolle, Business-Continuity, Incident-Handling und Lieferkettensteuerung nach Art 20 und 21 NIS2.

In dieser Standardaufteilung greifen beide Regime an derselben Nahtstelle: Der Hersteller liefert ein sicheres Produkt, der Betreiber betreibt es sicher weiter. Die Schnittstelle heißt Beschaffung, denn die CRA-Erwägungsgründe stellen ausdrücklich einen Bezug zwischen Beschaffung, Produktsicherheit und NIS2-Lieferkettensicherheitsmaßnahmen her.

CRA und NIS2: Wo Produktverantwortung endet

Szenario 2: Der Regler wandert nach unten – Infrastruktur wird zum Produkt

Wird die Serverlandschaft nicht nur betrieben oder integriert, sondern als vorkonfiguriertes Hardware-/Software-Bundle mit eigener Produktverantwortung auf den Markt gebracht, etwa als HANA-Appliance oder paketierte Server-Software, reicht der CRA in die untere Stack-Ebene hinein. Für den Hersteller heißt das: Konformitätsbewertung für das Gesamtsystem, EU-Konformitätserklärung, CE-Kennzeichnung, SBOM-bezogene Dokumentation und Update-Zusage für das eingebettete Betriebssystem; produktnotwendige Remote-Komponenten können als Datenfernverarbeitungslösung in den Scope fallen.

Der Betreiber bleibt in der Verantwortung, aber sein Spielfeld schrumpft. Er konfiguriert und härtet, was ihm geliefert wird, und dokumentiert die Auswahl in seinen NIS2-Lieferkettenprozessen. Der Großteil der Sicherheitsarbeit ist bereits beim Hersteller passiert. Wer als Betreiber „Appliance statt Eigenbau“ wählt, gewinnt Compliance-Effizienz, muss aber die Herstellernachweise aktiv in seine eigenen NIS2-Prozesse übernehmen.

CRA und NIS2: Wenn Infrastruktur Teil des Produkts wird

Szenario 3: Der Regler wandert nach oben – der Schwerpunkt verschiebt sich zum Dienst

Umgekehrt kann der Schwerpunkt nach oben in die Betriebssicht wandern, wenn der Nutzer keinen eigenständigen installierbaren Client mehr erhält, sondern primär Zugang zu einem betriebenen Dienst, etwa über Browser, zentral verteilten Thin Client oder Managed SaaS-Zugriff. Dann steht nicht mehr die Konformität eines lokal bereitgestellten Softwareprodukts im Vordergrund, sondern Zugriffsschutz, Betriebssicherheit, Incident-Handling und Lieferkette des Dienstes.

CRA bleibt dort relevant, wo installierbare, separat bereitgestellte oder produktnotwendige Komponenten bestehen, die selbst die CRA-Voraussetzungen erfüllen, etwa lokale Konnektoren, Endpoint-Agents oder mobile Apps. Diese verbleibenden Komponenten können weiterhin Produkte mit digitalen Elementen im CRA-Sinn sein.

Der Regler kippt also nicht binär, sondern verschiebt den Sicherheitsschwerpunkt: weg von der Produktkonformität und hin zu Verfügbarkeit, Zugriff und Kontinuität des Dienstes.

CRA und NIS2: Die Grenze zwischen Produkt und Betrieb

Was das Zusammenspiel aus CRA & NIS2 für Hersteller und Betreiber bedeutet

Die drei Szenarien zeigen: Es hängt nicht am Objekt, sondern am Bereitstellungs- und Verantwortungsmodell. Für Hersteller lautet die zentrale Frage daher nicht: „Bin ich vom CRA betroffen?“, sondern „In welchen Kundenkonstellationen bin ich Produktlieferant, in welchen Diensterbringer?“ Wer sein Angebot zusätzlich als Managed Service anbietet, muss beide Teile sauber trennen.

Für Betreiber lautet die Frage nicht: „Ist das CRA oder NIS2?“, sondern „Was fordere ich vom Hersteller ein, damit ich meine Pflichten nach Art 20 und 21 NIS2 erfüllen kann?“ Die Antwort steckt in genau den Artefakten, die der CRA ohnehin verlangt. Wer die Beschaffung entsprechend aufstellt, macht CRA-Konformität zum Katalysator für NIS2-Compliance. Folgende fünf CSR-Nachweise sollten NIS2-Betreiber deshalb in der Beschaffung abfragen:

• EU-Konformitätserklärung und CE-Kennzeichnung: fixe Position in Ausschreibungsunterlagen und Lieferantenprüfliste vor Vertragsschluss
• Supportzeitraum mit klarem Enddatum: direkter Input für Lifecycle-Management und Investitionsplanung
• Vulnerability-Handling-Prozess: Meldekanal, Reaktionszeit und Update-Bereitstellung vertraglich fixieren
• SBOM-Zugriff: klären, welche Stücklisten-Informationen der Betreiber wann erhält, insbesondere bei Schwachstellen in Drittkomponenten
• Remote-Komponenten und Drittanbieter-Services: welche davon Teil des Produkts sind und welche Due-Diligence der Hersteller durchgeführt hat

Wer diese fünf Punkte in seine Standard-Beschaffungsunterlagen aufnimmt, deckt einen Großteil der NIS2-Lieferkettensicherheit nach Art 21 ab und zwingt gleichzeitig seine Lieferanten in eine saubere CRA-Umsetzung. Die Beschaffungsabteilung wird damit zum unerwarteten strategischen Hebel in der Cybersicherheit.

FAQ – Häufig gestellte Fragen zum CRA