Die CRA verpflichtet alle Hersteller von Produkten mit digitalen Elementen zu Security-by-Design, dokumentiertem Vulnerability Handling und einer 5-jährigen Update-Garantie. Dieser Leitfaden erklärt Geltungsbereich, technische Anforderungen, Meldepflichten und den Weg zur CE-Konformität.
Volle Anwendbarkeit ab 11.12.2027 — der Umsetzungsaufwand ist heute schon realistisch einschätzbar.
Die Verordnung (EU) 2024/2847 — die Cyber Resilience Act (CRA) — wurde am 20. November 2024 im Amtsblatt der EU veröffentlicht und trat am 10. Dezember 2024 in Kraft. Sie verpflichtet Hersteller, Importeure und Händler von „Produkten mit digitalen Elementen", die auf dem EU-Markt in Verkehr gebracht werden, zu einem grundlegenden Mindestniveau an Cybersicherheit.
Die CRA schliesst eine erhebliche regulatorische Lücke: Bislang gab es keine EU-weite Regelung, die Sicherheitsanforderungen für vernetzte Produkte über deren gesamten Lebenszyklus vorschreibt. Unternehmen konnten unsichere Software auf den Markt bringen, ohne haftbar zu sein. Mit der CRA ändert sich das grundlegend.
Wer ist betroffen? Primär Hersteller — das sind Unternehmen, die Produkte mit digitalen Elementen entwickeln, herstellen oder entwerfen lassen und unter eigenem Namen oder Warenzeichen in Verkehr bringen. Sekundär betroffen sind Importeure (die Produkte aus Drittländern in die EU bringen) und Händler (die bestehende Produkte auf dem EU-Markt bereitstellen). Für österreichische SaaS-Startups, die eigene Software entwickeln und EU-weit vermarkten, ist die Hersteller-Rolle die relevante.
„Die CRA ist die erste Verordnung, die Sicherheit nicht als optionales Feature behandelt, sondern als gesetzliche Mindestanforderung für jedes vernetzte Produkt. Das ist eine fundamentale Änderung des Produkthaftungsrahmens." Ing. Mag. Günter Omer, tablegray services gmbh
Für mehr Kontext zur CRA-Landing-Page und unsere Beratungsleistungen: CRA-Überblick für Hersteller. Ergänzend zum CRA ist auch das NISG 2024 (NIS-2) für Betreiber wesentlicher und wichtiger Einrichtungen relevant — beide Regelwerke ergänzen sich im Bereich Vulnerability Management und Incident Response.
Der Begriff „Produkt mit digitalen Elementen" (PDE) ist der Schlüsselbegriff der CRA und bewusst weit gefasst. Art. 3 Nr. 1 definiert ihn als jedes Software- oder Hardwareprodukt und seine Remote-Datenverarbeitungslösungen, das eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netzwerk herstellt.
Konkret bedeutet das: Apps (mobil und Desktop), SaaS-Produkte, IoT-Geräte (Sensoren, Smart-Home-Geräte, Industrie-Steuerungen), vernetzte Hardware (Router, Drucker, Kameras), Betriebssysteme und Firmware. Ausgenommen sind Produkte, die ausschliesslich für nationale Sicherheit oder militärische Zwecke entwickelt wurden, sowie Medizinprodukte (die unter die MDR fallen), Fahrzeuge und Luftfahrzeuge.
Für SaaS-Anbieter ist die Einordnung nicht immer trivial: Cloud-Dienste, die als eigenständiges Produkt vermarktet werden und eine Netzwerkverbindung herstellen, gelten als PDE. Pure Service-Erbringung ohne Produkt-Charakter kann ausserhalb des Geltungsbereichs liegen — die Abgrenzung ist aber einzelfallabhängig und sollte rechtlich geprüft werden.
Die CRA kennt drei Produktklassen: Standard-PDEs (Selbstkontrolle reicht), wichtige PDEs (Anhang II Teil 1 — erhöhte Pflichten, aber ggf. Selbstkontrolle), und kritische PDEs (Anhang II Teil 2 — zwingende Drittbewertung durch notifizierte Stelle). Industrielle Kontrollsysteme, Firewalls und bestimmte Netzwerkgeräte sind in den höheren Klassen eingestuft.
Anhang I der CRA definiert die wesentlichen Cybersicherheitsanforderungen in zwei Teilen: technische Sicherheitseigenschaften des Produkts (Teil 1) und Anforderungen an den Vulnerability-Handling-Prozess (Teil 2). Teil 1 ist das, was Entwicklungsteams direkt betrifft.
Security-by-Design (Anhang I Teil 1 Nr. 1): Produkte müssen ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden. Das klingt trivial, ist aber in der Praxis eine erhebliche Anforderung: Es bedeutet, dass Sicherheit nicht als Nachbearbeitung verstanden werden darf, sondern als inhärenter Teil des Entwicklungsprozesses. Threat Modeling, Secure Coding Guidelines und Security-Code-Reviews sind keine Best Practices mehr — sie werden zur gesetzlichen Pflicht.
Software-Bill-of-Materials (SBOM): Hersteller müssen in der Lage sein, alle Softwarekomponenten ihres Produkts zu identifizieren und zu dokumentieren — einschliesslich Open-Source-Komponenten, deren Versionen und Lizenzen. Die CRA schreibt SBOM nicht als Pflichtdokument vor, aber die Anforderungen an Vulnerability Handling und Lieferketten-Transparenz machen eine SBOM praktisch unumgänglich. Gängige Formate sind CycloneDX und SPDX.
Risikoanalyse (Anhang I Teil 1 Nr. 1): Hersteller müssen eine Cybersicherheits-Risikoanalyse für ihr Produkt durchführen und dokumentieren. Geeignete Methoden sind STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) oder OWASP-basierte Ansätze. Die Risikoanalyse muss im Rahmen der technischen Dokumentation verfügbar sein.
Security-Anforderungen müssen in der Design-Phase, nicht erst in der Test-Phase berücksichtigt werden. OWASP SAMM oder Microsoft SDL sind geeignete Rahmenwerke.
Abhängigkeiten vollständig erfassen, Versionen tracken, Lizenzen prüfen. Tools wie Syft, Grype oder Dependency-Track helfen bei der Automatisierung. Format: CycloneDX oder SPDX.
Für jede wesentliche Produktfunktion: Welche Angriffsvektoren existieren? Welche Gegenmassnahmen sind implementiert? Das ist die Grundlage der Risikoanalyse nach Anhang I.
CRA Anhang I Nr. 2: Produkte müssen mit sicheren Standardkonfigurationen ausgeliefert werden. Keine Standard-Passwörter, unnötige Dienste standardmässig deaktiviert, Least-Privilege-Prinzip.
Anhang I Teil 2 der CRA enthält die Anforderungen an den Vulnerability-Handling-Prozess. Diese Anforderungen gelten für Hersteller über den gesamten Support-Zeitraum des Produkts — mindestens fünf Jahre oder die Produktlebensdauer, je nachdem was länger ist. Die Meldepflicht für aktiv ausgenutzte Schwachstellen wird ab dem 11. September 2026 wirksam.
Was bedeutet „aktiv ausgenutzt"? Eine Schwachstelle gilt als aktiv ausgenutzt, wenn konkrete Hinweise vorliegen, dass sie von einem Angreifer in einem realen Angriff verwendet wird — nicht nur als theoretisches Proof-of-Concept. Sobald ein Hersteller von einer solchen Schwachstelle in seinem Produkt Kenntnis erlangt, beginnt die Meldefrist.
Die Meldepflicht nach Art. 14 CRA ist zweistufig: Innerhalb von 24 Stunden ab Kenntniserlangung muss eine Frühwarnung an die ENISA (Europäische Agentur für Cybersicherheit) erstattet werden. Innerhalb von 72 Stunden ist eine vollständigere Meldung zu übermitteln. Dieser Zeitrahmen ist identisch mit dem Meldezeitraum unter NIS-2 (NISG 2024 § 23) — was die Koordination beider Compliance-Regime erleichtert.
Ein funktionierender Vulnerability-Handling-Prozess umfasst: regelmässige Schwachstellen-Scans (statische und dynamische Code-Analyse), ein Bug-Bounty-Programm oder koordiniertes Meldeverfahren für externe Finder (Coordinated Vulnerability Disclosure, CVD), eine interne Eskalationskette, die innerhalb von Stunden reagieren kann, und eine dokumentierte Patch-Pipeline.
„Vulnerability Handling ist kein einmaliges Projekt — es ist ein kontinuierlicher Prozess, der in den normalen Development-Workflow integriert sein muss. Wer das erst 2026 beginnt aufzubauen, wird den September-Stichtag nicht entspannt erleben." Ing. Mag. Günter Omer, tablegray services gmbh
Ab dem 11. Dezember 2027 müssen alle PDEs, die neu auf den EU-Markt gebracht werden, eine CE-Kennzeichnung tragen und von einer Konformitätserklärung begleitet sein. Die CE-Kennzeichnung signalisiert, dass das Produkt die wesentlichen Cybersicherheitsanforderungen der CRA erfüllt.
Die technische Dokumentation nach Art. 31 und Anhang VII muss mindestens enthalten: allgemeine Beschreibung des Produkts und seine beabsichtigte Verwendung; Sicherheitsarchitektur und Sicherheitsmassnahmen; Risikoanalyse; Informationen über Schwachstellen-Behandlungsprozesse; SBOM für kritische Abhängigkeiten; Test- und Prüfnachweise; Konformitätserklärung. Diese Dokumentation muss für Marktüberwachungsbehörden auf Anfrage innerhalb kurzer Zeit verfügbar sein.
Die Konformitätsbewertung erfolgt für Standard-PDEs in der Regel durch Selbstkontrolle (interne Prüfung nach Anhang VI). Für wichtige und kritische Produkte (Anhang II) ist je nach Kategorie eine externe Prüfung durch eine notifizierte Stelle erforderlich. In Österreich werden die Marktüberwachungsaufgaben voraussichtlich der RTR und dem Fernmeldebüro obliegen.
Art. 13 Abs. 8 CRA verpflichtet Hersteller, für Sicherheitsupdates zu sorgen. Der Supportzeitraum beträgt mindestens fünf Jahre ab dem Zeitpunkt des Inverkehrbringens oder die erwartete Produktlebensdauer, je nachdem was länger ist. Diese Pflicht trifft SaaS-Anbieter und Software-Hersteller besonders hart: Sie müssen klare End-of-Life-Richtlinien definieren und einhalten.
Praktisch bedeutet das: Wer ein Produkt 2028 auf den Markt bringt, muss bis mindestens 2033 Sicherheits-Updates liefern. Das ist für viele SaaS-Unternehmen, die ohnehin kontinuierlich deployen, keine wesentliche Änderung. Für traditionelle Softwarehersteller mit langen Release-Zyklen oder für IoT-Hersteller, die Hardware-Updates nur schwer ausliefern können, ist das ein erheblicher Aufwand.
Die Updates müssen dem Nutzer kostenfrei zur Verfügung gestellt werden (Art. 13 Abs. 9). Sie müssen separat von funktionalen Updates angeboten werden, es sei denn, eine Ablehnung des Sicherheits-Updates durch den Nutzer würde zu nicht behebbaren Sicherheitsproblemen führen. Hersteller müssen Nutzer klar über bevorstehende End-of-Life-Daten informieren.
Für Unternehmen, die bereits NIS-2-konform arbeiten (siehe NIS-2-Leitfaden) und ein Patch-Management-System etabliert haben, ist die Erweiterung auf CRA-Anforderungen verhältnismässig schlank. Wer heute noch keinen definierten Patch-Zyklus hat, sollte das als Priorität behandeln.
Die CRA adressiert explizit die Sicherheit von Lieferketten. Hersteller sind verpflichtet, die Sicherheit ihrer Softwarekomponenten zu kennen und zu verwalten — einschliesslich zugekaufter Komponenten, Open-Source-Bibliotheken und Third-Party-SDKs. Eine bekannte Schwachstelle in einer Abhängigkeit, die im SBOM dokumentiert ist, muss rechtzeitig behoben werden.
Für Open-Source-Software gilt ein differenzierter Ansatz: Open-Source-Softwarekomponenten, die kommerziell entwickelt und in einem Unternehmenskontext vermarktet werden, fallen grundsätzlich unter die CRA. Rein freie Open-Source-Software, die ohne kommerzielle Absicht entwickelt wird, ist ausgenommen. Die Grauzone ist erheblich — wer Open-Source-Projekte maintained und dabei auch kommerzielle Interessen verfolgt, sollte die Einordnung prüfen.
Praktisch relevant ist, dass viele Schwachstellen nicht im selbst geschriebenen Code entstehen, sondern in Abhängigkeiten. Log4Shell (2021) hat exemplarisch gezeigt, wie eine Schwachstelle in einer weit verbreiteten Java-Bibliothek tausende Produkte betreffen kann. Die CRA macht Hersteller für solche Abhängigkeiten verantwortlich — was bedeutet: regelmässige SBOM-Aktualisierungen, automatisierte Vulnerability-Scans und ein definierter Prozess für das Handeln bei neuen CVEs.
Ähnliche Lieferketten-Transparenzanforderungen entstehen durch die EU AI Act, wenn KI-Komponenten in Produkten eingesetzt werden. Die Synergie beider Regelwerke zu nutzen — gemeinsame SBOM-Prozesse, gemeinsame Risikoanalyse-Frameworks — ist der effizienteste Ansatz für Unternehmen, die unter beide Regelwerke fallen.
Die gute Nachricht: Die CRA gibt ausreichend Vorlaufzeit. Wer heute beginnt, kann die Anforderungen bis 2027 geordnet umsetzen — ohne Hektik, ohne teure Nacharbeit. Die schlechte Nachricht: Viele Unternehmen unterschätzen den Aufwand, insbesondere für den Aufbau des Vulnerability-Handling-Prozesses und die SBOM-Erstellung.
Tablegray empfiehlt einen vierstufigen Ansatz für die CRA-Vorbereitung:
Stufe 1 — Bestandsaufnahme (sofort): Welche Produkte Ihres Unternehmens fallen unter die CRA? Sind Sie Hersteller, Importeur oder Händler? Welche Produktklasse (Standard, wichtig, kritisch)? Diese Einordnung bestimmt den gesamten Compliance-Pfad.
Stufe 2 — Gap-Assessment (Q3 2026): Vergleich des Ist-Stands mit den Anforderungen aus Anhang I. Wo fehlt eine Risikoanalyse? Ist der Vulnerability-Handling-Prozess dokumentiert? Gibt es eine SBOM? Ergebnis: priorisierter Massnahmenplan.
Stufe 3 — Technische Umsetzung (bis Q2 2027): SBOM aufbauen, Vulnerability-Handling-Prozess etablieren, Meldewege für ENISA definieren, technische Dokumentation erstellen, Sicherheits-Tests dokumentieren.
Stufe 4 — CE-Vorbereitung (bis Q4 2027): Konformitätserklärung erstellen, CE-Kennzeichnung vorbereiten, Dokumentation prüfen, ggf. externe Konformitätsbewertung einleiten.
Jedes Produkt mit Netzwerkverbindung, das Sie auf dem EU-Markt in Verkehr bringen, ist ein PDE. Die Einordnung braucht eine juristische und technische Einschätzung.
Die Meldepflicht startet 11.09.2026. Bis dahin muss der interne Prozess stehen — Eskalationskette, ENISA-Meldung, 24-h-Frist einhalten.
Ohne SBOM kann kein Vulnerability-Handling funktionieren. Beginnen Sie mit dem kritischsten Produkt und arbeiten Sie sich vor.
Technische Dokumentation nach Anhang VII erfordert Vorlaufzeit. Starten Sie nicht erst 2027 damit.
SBOM-Readiness, Vulnerability-Handling-Status, technische Dokumentation, CE-Vorbereitung — der Quick-Check zeigt Ihnen, wo die kritischen Lücken liegen, bevor wir sie gemeinsam im Erstgespräch besprechen.
Kostenlos. Kein Verkauf. Die PDF ist die Grundlage für jedes CRA-Erstgespräch bei tablegray.
Nein. Die CRA gilt für Produkte, die auf dem EU-Markt „in Verkehr gebracht" werden — d.h. die an Dritte weitergegeben oder zum Kauf angeboten werden. Rein interne Software, die ausschliesslich intern genutzt wird und nicht an Dritte weitergegeben wird, ist ausserhalb des Geltungsbereichs. Sobald jedoch auch nur ein externer Nutzer Zugang erhält, kann das PDE-Kriterium erfüllt sein.
Die CRA schreibt kein spezifisches SBOM-Format vor, aber die Dokumentationspflichten legen nahe: vollständige Liste aller enthaltenen Softwarekomponenten inklusive Open-Source-Bibliotheken, jeweils mit Version und Lizenzinformation. Gängige Formate sind CycloneDX (JSON/XML) und SPDX. Für die Praxis empfiehlt tablegray, die SBOM in den CI/CD-Prozess zu integrieren, damit sie automatisch aktuell gehalten wird.
Die Meldepflicht nach Art. 14 bezieht sich auf aktiv ausgenutzte Schwachstellen. Eine neu entdeckte, noch nicht ausgenutzte Schwachstelle löst keine sofortige Meldepflicht aus. Sie müssen aber den internen Vulnerability-Handling-Prozess aktivieren und den Patch mit Priorität entwickeln. Wenn die Schwachstelle öffentlich bekannt wird (CVE), müssen Sie proaktiv kommunizieren, auch wenn noch kein Patch verfügbar ist.
Für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden und danach wesentlich verändert werden, gelten die neuen Anforderungen für die veränderte Version. Produkte ohne wesentliche Änderungen, die bereits auf dem Markt sind, müssen grundsätzlich nicht nachzertifiziert werden — aber Sicherheitsupdates müssen weiterhin bereitgestellt werden. Bestandsprodukte im Support fallen unter die Update-Pflicht.
Ja, erheblich. NIS-2 (NISG 2024) reguliert die Cybersicherheit von Organisationen, CRA reguliert die Sicherheit von Produkten. Ein Unternehmen, das unter beide Regelwerke fällt (z.B. ein Hersteller kritischer Infrastruktur-Produkte), muss beide erfüllen. Vorteil: Vulnerability-Handling-Prozesse, Incident-Response-Pläne und Dokumentationsstrukturen sind teilweise übertragbar. Mehr dazu im NIS-2-Leitfaden.
Teilweise. Die Hersteller-Pflichten (Konformitätserklärung, CE-Kennzeichnung, Registrierung) bleiben beim Unternehmen, das das Produkt in Verkehr bringt — auch wenn die Entwicklung extern erfolgt. Sie können technische Umsetzungsarbeit delegieren, aber die juristische Verantwortung bleibt. Stellen Sie sicher, dass Ihre Entwicklungsverträge Security-Anforderungen explizit beinhalten.
Ein CRA-Gap-Assessment dauert 3–5 Wochen und gibt Ihnen einen konkreten Umsetzungsplan: Was fehlt, was kostet es, was ist der kritische Pfad bis September 2026? tablegray kombiniert Recht und Technik — das ist genau die Kombination, die CRA-Compliance erfordert.