„Wir können keine Beta-Versionen mehr rausgeben, die erfüllen noch nicht alle CRA-Anforderungen." Diesen Satz höre ich in Gesprächen mit Herstellern inzwischen regelmäßig. Die Sorge ist verständlich. Die Schlussfolgerung ist falsch. Sie kostet Innovationsgeschwindigkeit.
Was sagt der CRA zu unfertiger Software?
Der Cyber Resilience Act reguliert „Produkte mit digitalen Elementen", also Hardware und Software, die auf dem EU-Markt bereitgestellt werden. Entscheidend ist dabei das Konzept des „In-Verkehr-Bringens", also die erstmalige tatsächliche Bereitstellung auf dem EU-Markt.
Was viele nicht wissen: Der CRA schließt unfertige Software aus diesem Regulierungsrahmen ausdrücklich aus, unter bestimmten Voraussetzungen. Erwägungsgrund 24 der Verordnung hält fest, dass Software, die noch nicht fertiggestellt ist und nur zu Testzwecken bereitgestellt wird, nicht als In-Verkehr-Bringen gilt. Artikel 19 CRA konkretisiert dies und benennt zwei Bedingungen, unter denen Test-Software (Alpha, Beta, Release Candidate) nicht den vollständigen Konformitätspflichten unterliegt.
Das ist keine Grauzone und kein Schlupfloch. Es ist eine bewusste gesetzgeberische Entscheidung, um Softwareentwicklungsprozesse nicht zu blockieren. Wer diese Ausnahme kennt und richtig anwendet, kann seine Testprogramme weiterbetreiben, rechtssicher und ohne Konformitätsaufwand für jede Zwischenversion.
Zur Einordnung: Eine umfassende Übersicht über den CRA und seine Kernanforderungen bietet unser CRA-Leitfaden.
Warum der Irrtum Innovationsprozesse bremst
Der Fehler entsteht durch eine zu weite Auslegung des CRA. Hersteller lesen, dass Produkte mit digitalen Elementen umfangreiche Sicherheitsanforderungen erfüllen müssen, und schlussfolgern, dass jede veröffentlichte Software-Version diese Anforderungen sofort erfüllen muss.
Das stimmt für Produkte, die tatsächlich in Verkehr gebracht werden. Aber für Software, die explizit zum Testen bereitgestellt wird, gilt das nicht pauschal. Der Unterschied liegt nicht im technischen Zustand der Software, sondern in ihrer Zweckbestimmung und der Art ihrer Bereitstellung.
Ein Beispiel aus der Praxis: Ein Hersteller von Industriesteuerungen entwickelt eine neue Firmware-Generation für seine Maschinensteuerungen. Drei Bestandskunden aus dem Maschinenbau sollen die Beta in kontrollierten Produktionsumgebungen testen, echter Betrieb, echter Stresstest, echtes Feedback. Das ist für die Produktentwicklung unersetzlich. Wenn dieser Hersteller jetzt davon ausgeht, dass er die Beta erst nach vollständiger CRA-Konformitätsbewertung freigeben darf, verliert er Monate. Und der Kunde wartet.
Das ist nicht die Absicht des Gesetzgebers. Wohl aber ist es die Konsequenz eines verbreiteten Irrtums.
Mythos vs. Fakt
Mythos: Der CRA verbietet die Veröffentlichung von Beta-Versionen und unfertiger Software, weil diese noch nicht alle Sicherheitsanforderungen erfüllen.
Fakt: Artikel 19 CRA erlaubt die Bereitstellung von Test-Software ausdrücklich. Voraussetzung ist, dass die Software nur für die zum Testen notwendige Zeit verfügbar ist und mit einem deutlichen Hinweis versehen wird, dass sie nicht den CRA-Anforderungen entspricht und ausschließlich für Testzwecke bestimmt ist.
Die zwei Bedingungen für CRA-konforme Beta-Veröffentlichungen
Artikel 19 CRA nennt zwei kumulativ zu erfüllende Bedingungen. Beide müssen zutreffen. Eine allein reicht nicht.
1. Zeitliche Begrenzung auf das Notwendige. Die Test-Software darf nur so lange verfügbar sein, wie es der Testzweck tatsächlich erfordert. Das klingt selbstverständlich, ist in der Praxis aber oft das schwächste Glied. Wer einen Beta-Kanal aufmacht und ihn dann über Monate oder Jahre laufen lässt, verlässt den Schutzbereich dieser Ausnahme. In der Praxis bedeutet das: Definieren Sie vorab eine Laufzeit für das Beta-Programm. Dokumentieren Sie sie. Stellen Sie sicher, dass die Software nach Ablauf oder nach Abschluss des Testprogramms nicht mehr abrufbar ist. Eine Beta-Version, die nach dem offiziellen Produktlaunch noch ein halbes Jahr im Download-Portal liegt, ist kein Test mehr. Sie ist ein nicht konformes Produkt. Eine klare zeitliche Abgrenzung ist auch deshalb wichtig, weil sie im Zweifel dokumentiert werden muss. Aufsichtsbehörden werden nicht nur auf das Label schauen, sondern auf den tatsächlichen Verlauf des Testprogramms. Was Nicht-Konformität beim CRA bedeutet, haben wir in unserem Artikel zu CRA-Strafen und Bußgeldern zusammengefasst.
2. Deutlicher Hinweis auf Testcharakter und fehlende Konformität. Die Test-Software muss mit einem klaren Hinweis versehen sein, dass sie nicht den Anforderungen des CRA entspricht und ausschließlich zu Testzwecken bereitgestellt wird. Dieser Hinweis muss sichtbar und unmissverständlich sein. Was nicht ausreicht: ein Satz in den Release Notes, ein Fußnoten-Disclaimer in einem PDF-Anhang oder eine allgemeine Beta-Kennzeichnung ohne konkreten CRA-Bezug. Was ausreicht: ein expliziter Hinweis, der beim Download, bei der Installation oder im Interface selbst erscheint, formuliert so, dass ein informierter Nutzer den regulatorischen Status der Software eindeutig einordnen kann. In der Praxis empfiehlt sich eine Formulierung wie: „Diese Software ist eine Vorabversion zu Testzwecken. Sie entspricht nicht den Anforderungen des EU Cyber Resilience Act (Verordnung (EU) 2024/2847) und darf nur im Rahmen dieses Testprogramms bis [Datum] eingesetzt werden." Ergänzend sollten Sie für Beta-Teilnehmer einen schriftlichen Test-Agreement einholen, der den Testcharakter und die Nutzungsbeschränkungen dokumentiert.
Was bedeutet das für Ihre CRA-Roadmap?
Die Ausnahme für Test-Software ist heute schon relevant und wird es in den kommenden Monaten noch stärker. Zwei Stichtage sind dabei entscheidend.
Ab dem 11. September 2026 treten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in Kraft. Das betrifft auch Software, die sich bereits im Markt befindet. Wer bis dahin klare Grenzen zwischen Test-Software und Produktions-Software gezogen hat, ist in einer deutlich besseren Position, sowohl operativ als auch dokumentatorisch.
Ab dem 11. Dezember 2027 gilt der CRA vollständig. Wer bis dahin Konformitätsprozesse für alle echten Produkte etabliert hat, kann sich die Ausnahme für Test-Software als echten Vorteil erhalten: schnellere Feedback-Zyklen, mehr Kundeneinbindung in die Entwicklung, ohne jeden Zwischenschritt als regulatorisches Ereignis behandeln zu müssen.
Wie Sie Ihre Compliance-Roadmap bis zu diesen Stichtagen strukturieren, zeigt unser Artikel zur CRA Compliance-Roadmap 2026–2027.
Wichtig: Die Ausnahme für Test-Software entbindet nicht von den späteren Konformitätspflichten für das fertige Produkt. Eine CE-Kennzeichnung und eine vollständige Konformitätsbewertung sind für das finale Produkt weiterhin erforderlich. Und wer schon in der Beta-Phase sauber mit Schwachstellen umgeht (Stichwort Vulnerability Management), wird feststellen, dass der Weg zur Konformität des finalen Produkts erheblich kürzer ist.
Häufig gestellte Fragen
Gilt die Ausnahme auch für Open-Source-Beta-Versionen? Grundsätzlich ja, sofern die beiden Bedingungen erfüllt sind: zeitliche Begrenzung und deutlicher Hinweis. Bei Open-Source-Software gelten im CRA teilweise eigene Regelungen. Wichtig ist, dass die Bereitstellung der Test-Version klar als solche gekennzeichnet ist und die Verfügbarkeit tatsächlich zeitlich begrenzt wird.
Muss ich für eine Beta-Version trotzdem eine SBOM erstellen? Eine vollständige SBOM im Sinne der CRA-Anforderungen ist für Test-Software, die unter die Ausnahme nach Artikel 19 fällt, nicht verpflichtend. Für die interne Entwicklungsdokumentation und die spätere Konformitätsbewertung des finalen Produkts ist eine früh erstellte SBOM aber sinnvoll. Unser SBOM-Guide für IoT-Hersteller gibt dazu einen praxisnahen Einstieg.
Was ist, wenn ein Kunde die Beta produktiv einsetzt, obwohl das nicht vorgesehen war? Das ist ein reales Risiko. Deshalb ist ein Test-Agreement mit klaren Nutzungsbeschränkungen wichtig, nicht nur als rechtliche Absicherung, sondern als aktives Steuerungsinstrument. Wenn ein Hersteller weiß oder wissen müsste, dass Beta-Software de facto produktiv genutzt wird, verlässt er den Schutzbereich der Ausnahme.
Wie lange darf eine Beta-Phase maximal dauern? Der CRA nennt keine konkrete Frist. Maßstab ist der tatsächliche Testzweck. Eine Beta-Phase von drei bis sechs Monaten für ein konkretes Testprogramm ist in der Regel unproblematisch. Ein offener Beta-Kanal ohne Enddatum ist problematisch.
Brauche ich eine formelle Genehmigung, um Test-Software bereitzustellen? Nein. Artikel 19 CRA ist eine direkt anwendbare Ausnahme, keine Genehmigungspflicht. Es liegt in der Verantwortung des Herstellers, die Bedingungen zu erfüllen und zu dokumentieren.
Fazit
Die Ausnahme für Test-Software im CRA ist ein durchdachtes Instrument, das Innovationsprozesse schützt, wenn man sie kennt und richtig anwendet. Wer Beta-Versionen aus falsch verstandener Vorsicht einstellt, schadet nicht nur seinem eigenen Entwicklungsprozess, sondern verzichtet auf Kundenfeedback in einer Phase, in der Änderungen noch günstig sind.
Zwei Bedingungen, richtig umgesetzt, sind kein bürokratischer Aufwand. Sie sind gute Produktentwicklungspraxis.
Eine strukturierte CRA-Compliance-Plattform hilft dabei, den Status jeder Software-Version (Test oder Produkt) eindeutig zu dokumentieren und die Übergänge zwischen Entwicklungsphase und regulatorischer Konformität systematisch zu steuern, bevor der Stichtag aus der Theorie in die Praxis kippt. Mehr dazu unter /cra-compliance-assessment.
Jeden Freitag räume ich hier mit einem CRA-Mythos auf.