Cyber Resilience Act ab 2027: Was Software- und IoT-Anbieter in Österreich schon 2026 vorbereiten müssen

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist seit 10. Dezember 2024 in Kraft. Die Hauptpflichten greifen am 11. Dezember 2027, die Meldepflichten für aktiv ausgenutzte Schwachstellen schon ab 11. September 2026. Betroffen sind nicht nur Hardware-Hersteller, sondern alle Wirtschaftsakteure, die „Produkte mit digitalen Elementen“ in Verkehr bringen – das umfasst Software, Apps, Plug-ins, IoT-Geräte, Router und sogar Open-Source-Komponenten, wenn sie kommerziell vertrieben werden. Für österreichische KMU im SaaS- oder IoT-Bereich beginnt die Vorbereitung jetzt, weil CE-Konformität, technische Dokumentation und Schwachstellen-Management nicht in wenigen Wochen aufgebaut werden können.

Was der CRA regelt

Der Cyber Resilience Act ist die erste horizontale EU-Verordnung, die Cybersicherheits-Anforderungen an Produkte mit digitalen Elementen direkt vorschreibt. Bisherige sektorale Regelungen – NIS2 für Betreiber wesentlicher Dienste, RED-Delegierte für Funkanlagen, DSGVO für personenbezogene Datenverarbeitung – greifen je nach Anwendungsbereich. Der CRA schliesst die Lücke bei klassischen Produkten: vom smarten Türschloss über die Cloud-Backup-Software bis zum E-Bike-Akku-Management.

Die Kernidee: Wer ein Produkt mit digitalen Elementen in der EU verkauft, übernimmt Verantwortung für seine Cybersicherheit über die gesamte vorhersehbare Lebensdauer. Das umfasst Produkt-Design, Vulnerability-Management, Update-Bereitstellung und Endbenutzer-Information.

Anders als manche Diskussion suggeriert ist der CRA kein reines Hardware-Gesetz. Standalone-Software, also auch Plug-ins, Mobile-Apps und SaaS-Software, fällt vollständig unter den Anwendungsbereich, sofern sie kommerziell vertrieben oder bereitgestellt wird. Auch Embedded Software, Firmware und IoT-Stacks sind erfasst.

Drei Risikokategorien mit unterschiedlichen Anforderungen

Der CRA arbeitet mit einer dreistufigen Risikoklassifizierung:

Standardprodukte (rund 90 Prozent aller erfassten Produkte). Wirtschaftsakteure führen eine Selbstbewertung durch (interne Konformitätsbewertung nach Anhang VIII Modul A) und bringen das CE-Zeichen nach erfolgreichem Selbst-Test an. Beispiele: einfache Mobile-Apps, Standard-Web-Plug-ins, viele Consumer-IoT-Geräte ohne sicherheitskritische Funktion.

Wichtige Produkte Klasse I (Anhang III). Zusätzlich zur Selbstbewertung muss eine harmonisierte Norm angewendet oder eine Drittzertifizierung durchgeführt werden. Beispiele: Identitätsmanagement-Systeme, Standalone-Browser, Passwortmanager, VPN-Software, Smart-Home-Hubs, vernetzte Spielzeuge.

Wichtige Produkte Klasse II (Anhang III). Drittzertifizierung durch eine notifizierte Stelle verpflichtend. Beispiele: Firewalls für industrielle Anwendungen, Hardware-Tunnel-Komponenten, manipulationssichere Smartcard-Reader, Routers mit Sicherheitsfunktion.

Kritische Produkte (Anhang IV). Zusätzlich zur Drittzertifizierung sind europäische Cybersicherheitszertifizierungsschemata (EUCC) verpflichtend, sofern verfügbar. Beispiele: Hardware-Sicherheitsmodule (HSM), Smartcards mit kritischer Sicherheitsfunktion, sichere Krypto-Komponenten.

Für die typische österreichische SaaS-EPU oder den IoT-Startup ist die Klassifizierung in der Regel Standard oder maximal Klasse I. Wer aber etwa einen Open-Source-Passwortmanager kommerziell anbietet oder ein vernetztes Spielzeug entwickelt, fällt unter Klasse I – das bedeutet bereits den deutlich höheren Aufwand der harmonisierten Normanwendung.

Wesentliche Cybersicherheits-Anforderungen

Anhang I des CRA enthält die essenziellen Anforderungen, die alle Produkte mit digitalen Elementen erfüllen müssen. Ein Auszug der praxisrelevanten Punkte:

• Produkte werden ohne bekannte ausnutzbare Schwachstellen ausgeliefert
• Standardkonfiguration ist sicher (Secure-by-Default, etwa keine vorinstallierten Standard-Passwörter)
• Authentifizierung und Zugangskontrolle für Konfigurations- und Funktionsänderungen
• Verschlüsselung von gespeicherten und übertragenen Daten dort, wo angemessen
• Integritätsschutz der Software und Daten gegen Manipulation
• Minimierung der angreifbaren Oberfläche (Reduktion ungenutzter Schnittstellen)
• Begrenzung der negativen Auswirkungen erfolgreicher Angriffe (Containment)
• Logging sicherheitsrelevanter Vorgänge mit nachvollziehbarem Audit-Trail
• Sicheres Update-Verfahren, Updates müssen automatisch oder einfach aktivierbar sein
• Möglichkeit für Nutzer, Daten löschen und Werkseinstellungen wiederherzustellen

Anhang I enthält darüber hinaus Pflichten zum Schwachstellen-Management während der Produktlebensdauer: koordiniertes Vulnerability Disclosure, Test- und Verifizierungsprozesse, Bereitstellung von Sicherheitsupdates ohne unzumutbare Verzögerung, klare Information der Anwender über Schwachstellen und Behebungen.

Meldepflichten ab September 2026

Wesentlich früher als die Hauptpflichten greifen die Meldepflichten in Artikel 14. Ab 11. September 2026 müssen Hersteller dem zuständigen CSIRT (Computer Security Incident Response Team) und der ENISA (European Union Agency for Cybersecurity) zwei Arten von Vorfällen melden:

1. Aktiv ausgenutzte Schwachstellen. Sobald der Hersteller weiss oder mit hinreichender Sorgfalt wissen müsste, dass eine in seinem Produkt enthaltene Schwachstelle ausgenutzt wird, sind drei Fristen einzuhalten: 24 Stunden für eine erste Frühwarnung, 72 Stunden für eine Schwachstellen-Meldung mit Erstmassnahmen und 14 Tage für einen Abschlussbericht.

2. Sicherheitsvorfälle mit Auswirkung auf das Produkt. Bei sicherheitsrelevanten Zwischenfällen, die Sicherheits- oder Funktionseigenschaften des Produkts betreffen, gelten die gleichen Fristen.

Die Meldepflicht greift unabhängig von der Risikoklasse – auch reine Standardprodukte sind erfasst. Für österreichische Selbstständige ist das praktisch der erste konkrete CRA-Compliance-Punkt, der in den nächsten Monaten umgesetzt werden muss: ein Vulnerability-Tracking-Prozess, eine Eskalationskette, klare Verantwortlichkeit für die 24-Stunden-Frühwarnung.

Konformitätsbewertung und CE-Kennzeichnung

Ab 11. Dezember 2027 dürfen Produkte mit digitalen Elementen nur noch mit CE-Kennzeichnung in den EU-Markt gebracht werden. Voraussetzung sind:

• Technische Dokumentation nach Anhang VII (Produktbeschreibung, Risikoanalyse, angewandte Standards, Test-Ergebnisse, Software-Bill-of-Materials)
• EU-Konformitätserklärung nach Anhang V
• Konformitätsbewertung im jeweiligen Modus (Selbstbewertung, Modulanwendung, Drittzertifizierung)
• CE-Kennzeichnung auf Produkt oder Verpackung sichtbar
• Aufbewahrung der Dokumentation für mindestens 10 Jahre nach Inverkehrbringen

Für Standardprodukte ist die Selbstbewertung in der Regel ausreichend. Das Verfahren ist anspruchsvoll, aber ohne externe Auditkosten machbar. Für Klasse-I-Produkte werden bis 2027 harmonisierte Normen erwartet, deren Anwendung die Konformität präsumiert. Die ETSI EN 303 645 für IoT-Verbrauchergeräte und die ISO/IEC 27034 für Anwendungssicherheit sind aktuelle Kandidaten.

Wer in Klasse II oder darüber liegt, muss eine notifizierte Stelle einbinden. In Österreich sind das die akkreditierten Konformitätsbewertungsstellen, die über die Akkreditierung Austria gelistet sind. Die Kosten liegen schnell im fünf- bis sechsstelligen Bereich, der Vorlauf für die Auditierung bei mehreren Monaten.

Open-Source-Software und Bereitsteller-Pflichten

Eine der intensivsten Diskussionen während des CRA-Gesetzgebungsverfahrens drehte sich um Open-Source-Software. Die finale Verordnung unterscheidet zwischen:

• Reinen Hobby- und Community-Projekten ohne kommerziellen Vertrieb: nicht erfasst
• Open-Source-Software, die als Bestandteil eines kommerziellen Produkts verteilt wird: Erfassung über den kommerziellen Inverkehrbringer
• Open-Source-Software-Stewards (etwa Foundations, die OSS-Komponenten pflegen): vereinfachte Pflichten mit Fokus auf koordiniertes Vulnerability Disclosure, kein vollständiger CE-Prozess

Für österreichische Selbstständige relevant: Wer ein SaaS-Produkt aus Open-Source-Komponenten zusammenbaut und kommerziell anbietet, ist Hersteller im Sinne des CRA. Die SBOM-Pflicht (Software-Bill-of-Materials) wird zur Routine – jedes Library-Update, jeder neue Dependency-Tree muss dokumentiert und auf Schwachstellen geprüft sein.

Sanktionen und Marktüberwachung

Artikel 64 staffelt die Sanktionen nach Schwere des Verstosses:

• Verstösse gegen Grundpflichten (Anhang I, Anhang II, Schwachstellen-Management, Konformitätsbewertung): bis 15 Mio. Euro oder 2,5 Prozent des weltweiten Vorjahresumsatzes, je höher
• Verstösse gegen sonstige Pflichten: bis 10 Mio. Euro oder 2 Prozent
• Falsche oder irreführende Angaben gegenüber Marktüberwachung oder notifizierten Stellen: bis 5 Mio. Euro oder 1 Prozent

Die Marktüberwachung erfolgt in Österreich voraussichtlich durch das Bundesministerium für Klimaschutz, Innovation und Technologie (BMK) in Zusammenarbeit mit der Telekom-Control-Kommission und dem Computer Emergency Response Team Austria (CERT.at). Stichprobenkontrollen sind ab Dezember 2027 zu erwarten.

Was Selbstständige jetzt vorbereiten sollten

Sieben konkrete Schritte für Software- und IoT-Anbieter, geordnet nach Dringlichkeit:

1. Produktportfolio gegen Anhang III/IV abgleichen. Welche eigenen Produkte fallen in welche Risikoklasse? Diese Einstufung bestimmt den gesamten Compliance-Aufwand und die Vorlaufzeit.

2. Vulnerability-Disclosure-Prozess aufsetzen. Bis September 2026 muss eine Eskalationskette stehen: wer empfängt Schwachstellen-Meldungen, wie wird klassifiziert, wer hat die 24h-Meldepflicht-Verantwortung, wo erfolgt der Eintrag bei ENISA und CSIRT.

3. SBOM-Prozess etablieren. Eine Software-Bill-of-Materials ist Pflicht und Praxiserfordernis. Tools wie Syft, CycloneDX und SPDX-fähige Build-Pipelines automatisieren den Prozess. Ohne SBOM keine Konformität.

4. Sicherheits-Update-Lebenszyklus definieren. Wie lange werden Sicherheitsupdates für jedes Produkt bereitgestellt? Das Mindestmass ist die vorhersehbare Lebensdauer, in der Regel 5 Jahre. Lebenszyklus-Politik schriftlich fixieren, in AGB aufnehmen, intern kommunizieren.

5. Secure-by-Design in den Entwicklungsprozess integrieren. Threat Modeling, Code Review mit Security-Fokus, automatisiertes SAST/DAST in der CI/CD-Pipeline. Was heute optional ist, wird ab 2027 Pflichtnachweis im Konformitätsverfahren.

6. Technische Dokumentation strukturieren. Anhang VII listet 11 Dokumentationspunkte auf. Wer jetzt anfängt, kann sie organisch aufbauen. Wer 2027 startet, hat keinen Vorlauf für Audits und Iteration.

7. Bei Klasse II Lieferanten von Konformitätsbewertungsstellen sondieren. Die Notified Bodies sind kapazitätsbeschränkt. Wer 2027 erst Anfragen stellt, riskiert Wartezeiten von 6 bis 12 Monaten. Frühzeitige Vorgespräche und Vorab-Audits sichern Slots.

Kosten realistisch eingeordnet

Anhaltspunkte aus aktueller Beratungspraxis, Stand Mai 2026:

• CRA-Gap-Analyse für ein Standardprodukt: 5.000 bis 15.000 Euro Beratung
• Erstmalige technische Dokumentation und Konformitätserklärung für Standardprodukt: 10.000 bis 30.000 Euro
• SBOM-Tooling-Integration in bestehende CI/CD: 5.000 bis 20.000 Euro Entwicklungsaufwand
• Drittzertifizierung Klasse I oder II: 20.000 bis 150.000 Euro je nach Komplexität und Notified Body
• Vulnerability-Management-Aufbau für KMU: 8.000 bis 30.000 Euro Initialkosten plus 1.500 bis 5.000 Euro pro Monat laufender Aufwand
• Inhouse-Aufbau ohne externe Hilfe: 200 bis 500 Stunden Erstaufwand, plus 50 bis 150 Stunden pro Quartal Pflege

Wer kein eigenes Produkt mit digitalen Elementen vertreibt, ist nicht direkt betroffen. Wer aber etwa eine Marketing-App, ein Trading-Tool oder eine White-Label-SaaS-Lösung anbietet, fällt unter die volle CRA-Pflicht.

Häufige Fragen zum Cyber Resilience Act

Sind reine Web-Anwendungen ohne herunterladbaren Client betroffen?

Ja, Software-as-a-Service ist als „Software“ im Sinne von Art. 3 erfasst, sobald sie kommerziell bereitgestellt wird. Die Anforderungen treffen den Bereitsteller des Dienstes.

Was passiert mit bereits am Markt befindlichen Produkten?

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, bleiben grundsätzlich konform, müssen aber bei wesentlichen Updates die CRA-Anforderungen erfüllen. Eine substantielle Funktionsänderung gilt als neues Inverkehrbringen und löst die volle CE-Pflicht aus.

Brauche ich für jede WordPress-Plug-in-Version eine eigene Konformitätserklärung?

Massgeblich ist das Produkt, nicht jede Patch-Version. Kleinere Sicherheits- und Bug-Fixes bleiben in der Produktidentität. Funktionserweiterungen, die die Risikoeinstufung verändern, lösen einen neuen Konformitätsbewertungs-Zyklus aus.

Sind Solopreneur-Apps von der Schwelle ausgenommen?

Es gibt keine generelle KMU- oder EPU-Ausnahme im CRA. Der Gesetzgeber sieht Cybersicherheit als produktbezogen, nicht unternehmensgrössenbezogen. Vereinfachte Konformitätsbewertungsverfahren für KMU sind aber in mehreren Stellen vorgesehen (Art. 33 Abs. 5).

Was bedeutet das für Reseller und Importeure?

Importeure und Distributoren haben eigene Pflichten nach Art. 19 und 20: Sicherstellung der CE-Kennzeichnung, Vorhandensein der Konformitätserklärung, Kontaktinformationen des Herstellers, Sprachgerechte Begleitdokumentation. Bei Verdacht auf Nichtkonformität dürfen Produkte nicht in den Verkehr gebracht werden.

Wie verhält sich der CRA zum NIS2?

NIS2 reguliert Betreiber wesentlicher und wichtiger Dienste in ihrer Cybersecurity-Governance. Der CRA reguliert die Produkte, die diese und alle anderen Akteure einsetzen. Die beiden Regelwerke ergänzen sich: NIS2-Pflichtige werden bei der Beschaffung künftig CE-konforme Produkte verlangen.

Wer haftet bei Schwachstellen in Open-Source-Komponenten meiner Software?

Der kommerzielle Inverkehrbringer ist verantwortlich. Wer Open-Source-Komponenten in sein Produkt integriert, übernimmt deren Sicherheits-Verantwortung. Die OSS-Steward-Vereinfachung gilt nur für die Steward-Organisation selbst, nicht für deren kommerzielle Nutzer.