Jedes Gerät mit digitalen Elementen muss zum Zeitpunkt des Inverkehrbringens frei von bekannten ausgenutzten Schwachstellen sein — pro Einzelstück, nicht pro Produktlinie. Für Schweizer Hersteller mit langen Lagerzyklen entkoppelt das Produktionsdatum vom Compliance-Zustand: wer 2026 fertigt und 2028 ausliefert, muss den 2028-Patch-Stand auf jedem einzelnen Gerät garantieren.
Was bedeutet das Einzelstück-Prinzip im EU CRA?
Der Cyber Resilience Act knüpft die zentralen Sicherheitspflichten an das Inverkehrbringen eines Produkts — den Moment, in dem es erstmals auf dem EU-Markt bereitgestellt wird (Art. 3 Abs. 21). Entscheidend ist nicht das Produktionsdatum, sondern der Zustand des einzelnen Geräts zum Übergabezeitpunkt an den nächsten Wirtschaftsakteur oder Endkunden.
Annex I §2(a) verlangt explizit, dass Produkte „ohne bekannte ausnutzbare Schwachstellen" bereitgestellt werden. Art. 13 Abs. 8 verpflichtet den Hersteller, „die in seiner Verantwortung liegenden Risiken" über den Unterstützungszeitraum zu adressieren — der mindestens fünf Jahre ab Bereitstellung läuft, oder die erwartete Nutzungsdauer, falls länger.
Praktisch bedeutet das: Ein 2026 produziertes Gerät, das zwei Jahre im Lager liegt, ist 2028 nicht automatisch konform — selbst wenn es bei Produktion auf dem damals aktuellen Sicherheitsstand war. Zwischen Produktion und Auslieferung können neue Schwachstellen in verwendeten Software-Komponenten bekannt werden. Das Gerät muss dann vor Inverkehrbringen aktualisiert werden.
Warum trifft das Schweizer Maschinenbau und Embedded-Hersteller besonders hart?
Die Schweizer Industrie ist von dieser Regelung überproportional betroffen — aus drei strukturellen Gründen.
Lange Produktentwicklungs- und Lagerzyklen. Maschinensteuerungen, industrielle Sensoren und Embedded-Systeme haben in der Schweiz typische Time-to-Market-Zyklen von 12 bis 24 Monaten, dazu kommen Lagerbestände, die bei Spezialprodukten auch ein bis zwei Jahre alt werden können. Ein Hersteller von SPSen oder CNC-Steuerungen produziert in Losen und hält Konfigurationen vor, die später kundenspezifisch ausgeliefert werden.
Hohe Software-Komplexität pro Produkt. Ein moderner Industriesteller enthält Firmware mit dutzenden Open-Source-Komponenten — Krypto-Bibliotheken, TCP/IP-Stacks, Webserver, Bootloader-Komponenten. In CycloneDX- oder SPDX-SBOMs sehen wir bei typischen Embedded-Geräten zwischen 80 und 400 Komponenten. Jede einzelne kann zwischen Produktion und Verkauf eine CVE-Meldung erhalten.
Drittlandshersteller-Status. Wie im Cyber Resilience Act für die Schweiz detailliert: Schweizer Hersteller müssen einen bevollmächtigten Vertreter in der EU benennen, der für 10 Jahre die technische Dokumentation vorhält. Wenn die Marktüberwachung eines EU-Mitgliedstaats später Stichproben aus älteren Liefer-Chargen prüft, muss pro Seriennummer nachweisbar sein, welcher Patch-Stand zum Inverkehrbringen verbaut war.
Wie funktioniert das im Detail?
Drei CRA-Artikel arbeiten hier zusammen:
| Artikel | Pflicht | Konsequenz pro Einzelstück |
|---|---|---|
| Art. 13 Abs. 8 | Sicherstellung, dass Sicherheitsrisiken über den Unterstützungszeitraum adressiert werden | Patch-Verfügbarkeit für jede ausgelieferte Seriennummer |
| Art. 14 | 24h-Meldepflicht bei aktiv ausgenutzten Schwachstellen | Wissen, welche Seriennummern betroffen sind |
| Annex I §2(a) | Auslieferung ohne bekannte ausgenutzte Schwachstellen | Pre-Shipping-Check pro Einheit |
| Annex VII | Technische Dokumentation 10 Jahre vorhalten | Patch-Status-Historie pro Charge nachweisbar |
Die Verbindung ist klar: Wenn der Hersteller nicht weiß, welche Software-Version auf welcher Seriennummer verbaut wurde, kann er weder Annex I §2(a) zum Auslieferungszeitpunkt garantieren noch eine glaubhafte Art. 14-Meldung an ENISA abgeben.
Was scheitert bei manuellem Excel-Tracking?
In der Praxis sehen wir bei Schweizer KMU drei typische Excel-basierte Workflows — und alle brechen unter dem Einzelstück-Prinzip zusammen.
Variante A: Eine SBOM pro Produktlinie. Der Hersteller pflegt eine zentrale SBOM für „Modell XY", aktualisiert sie bei Major-Updates. Problem: Wenn 60 Geräte Modell XY zwischen Mai und Oktober produziert werden, weicht der Software-Stand bei jedem ab — Bug-Fixes, kleinere Patches, Bibliotheks-Updates. Die zentrale SBOM stimmt für kein einziges ausgeliefertes Stück exakt.
Variante B: Excel-Sheet mit Seriennummer und Patch-Datum. Klassische Lösung: eine Spalte pro Seriennummer, eine pro Komponente, manuelle Eintragung bei Patches. Wir sehen Sheets mit 200 Zeilen × 80 Spalten. Bei jedem CVE-Bekanntwerden muss jemand prüfen, welche Komponenten in welchen Geräten betroffen sind. Bei 50+ Geräten pro Monat und 300+ Komponenten pro Gerät wird das zur Vollzeitstelle — die niemand budgetiert hat.
Variante C: „Wir patchen vor der Auslieferung." Charmant in der Theorie, scheitert in der Praxis am fehlenden Trigger. Ohne automatisiertes Monitoring kommt der Patch-Bedarf erst beim Kunden-Order, also unter Zeitdruck. Bei Spezialmaschinen ist das ein einwöchiges Validierungs- und Test-Verfahren — Lieferzeitenverschiebungen sind dann die Regel.
Sonderfall: Komponenten ohne SBOM des Zulieferers
Ein verwandtes Problem: Viele Zulieferer — insbesondere aus Nicht-EU-Staaten — geben heute keine detaillierten SBOMs heraus. Der Integrator bleibt dann in der Pflicht. Wenn keine Zulieferer-Dokumentation vorliegt, müssen Hersteller die Sicherheit der Komponente eigenständig nachweisen: durch Binär-Analyse, Vulnerability-Scans oder die Auswertung öffentlich bekannter Schwachstellen. Praktisch heißt das, jede opake Drittkomponente verursacht im Pre-Shipping-Check Mehraufwand, der bei manuellen Prozessen schnell explodiert.
Was passiert beim Audit, wenn der Patch-Status nicht stimmt?
Die EU-Marktüberwachungsbehörden (in Deutschland z.B. die Bundesnetzagentur, in Frankreich die ANSSI) können risikobasiert Stichproben aus laufenden Lieferungen oder aus dem Bestand bei EU-Importeuren ziehen. Geprüft wird zweistufig:
- Konformitätsprüfung des Einzelstücks — Software-Version auslesen, gegen die zum Auslieferungszeitpunkt bekannten CVEs prüfen. Treffer = Verstoß gegen Annex I §2(a).
- Konsistenz der technischen Dokumentation — wenn die Patch-Historie nicht zur tatsächlichen Software-Version auf dem Gerät passt, ist das ein dokumentarischer Verstoß gegen Annex VII, der eigenständig sanktionierbar ist.
Die Bußgeldspanne reicht bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes. Praktisch häufiger sind temporäre Verkaufsverbote, Rückrufpflichten und Imageschäden — bei Schweizer Maschinenbauern mit B2B-Kundenstamm wirken diese stärker als das Bußgeld selbst.
Wie sieht ein skalierender Prozess aus?
Ein CRA-konformer Pre-Shipping-Check für jedes Einzelstück basiert auf vier verbundenen Schritten — die alle automatisierbar sind:
1. SBOM-Generierung pro Seriennummer. Jedes Gerät bekommt beim Produktions-Build seine eigene CycloneDX- oder SPDX-Datei mit exakten Komponenten-Versionen. Das ist in CI/CD-Pipelines mit Tools wie kunnus-scanner Standardbau.
2. Kontinuierliches Vulnerability-Matching. Die SBOM wird gegen NVD und OSV-Datenbanken gematcht — täglich, nicht ad-hoc. Bei einer neuen CVE in einer verwendeten Komponente kommt ein Alert pro betroffener Seriennummer.
3. Pre-Shipping-Gate vor Auslieferung. Bei jeder Auslieferung wird die zur Seriennummer gehörige SBOM gegen den aktuellen CVE-Stand geprüft. Findet der Check eine offene Schwachstelle, wird die Auslieferung blockiert, bis entweder der Patch aufgespielt oder eine dokumentierte Risikobewertung vorliegt.
4. Audit-Trail pro Stück. Jede Aktion — SBOM-Generierung, CVE-Match, Patch-Aufspielung, Pre-Shipping-Check — wird mit Zeitstempel und verantwortlicher Person geloggt. Das ist die technische Dokumentation, die Annex VII verlangt.
Wenn Annex I §2 technisch nicht 1:1 erfüllbar ist
Komplexe Industriesysteme — Aufzugsanlagen, Großmaschinen, langlebige Embedded-Plattformen — basieren oft auf Architekturen, die vor Geltung des CRA entworfen wurden. Bestimmte Annex-I-Anforderungen können dort technisch unverhältnismäßig sein. Der CRA erlaubt in diesen Fällen alternative oder kompensatorische Maßnahmen wie Netzwerksegmentierung oder Defense-in-Depth — vorausgesetzt, das Sicherheitsniveau bleibt insgesamt gewahrt und die Begründung wird in der technischen Dokumentation belegt. Was als „angemessene" Kompensation gilt, ist in den aktuellen Leitlinien noch nicht abschließend definiert; eine saubere, nachvollziehbare Dokumentation der getroffenen Annahmen ist daher zentral.
Manuelle Umsetzung der vier Schritte ist für ein einstelliges Produktportfolio noch leistbar. Für ein mittleres Schweizer Produktportfolio mit 50–80 Geräten und 300+ Komponenten pro Gerät steigt der Aufwand erfahrungsgemäß auf 3–6 Vollzeitstellen jährlich — bei einem dokumentierten Ersparnispotenzial von 60–75 % gegenüber automatisierter SBOM- und Vulnerability-Pipeline. Die Fehlerquote im Pre-Shipping-Check steigt zusätzlich mit jeder Variantenstufe.
Welche Schritte sind jetzt sinnvoll?
Für Schweizer Hersteller mit Lagerbeständen und EU-Export sind drei Aktionen zeitkritisch.
Bestandsaufnahme der aktuellen Lagerware. Welche Produkte stehen heute auf dem Hochregal, die nach September 2026 oder nach Dezember 2027 ausgeliefert werden könnten? Welche SBOM-Daten existieren zu diesen Geräten — und auf welcher Granularität (Produktlinie vs. Seriennummer)?
Aufbau einer pro-Seriennummer-fähigen SBOM-Pipeline. Die nächsten Produktions-Loose sollten ab sofort mit individueller SBOM pro Einzelstück gebaut werden. Das ist nicht nur CRA-Compliance, sondern auch Voraussetzung für glaubwürdige Art. 14-Meldungen ab September 2026.
Pre-Shipping-Gate in den Logistikprozess integrieren. Vor jeder EU-Auslieferung muss ein technischer Check stehen, der CVE-Stand gegen Seriennummer abgleicht. In Kunnus läuft dieser Check als automatisierter Workflow vor jeder Versandfreigabe.
Eine kostenlose CRA-Reifegradanalyse zeigt in wenigen Minuten, ob Ihr aktueller Prozess das Einzelstück-Prinzip abdeckt — und wo die Lücken zwischen Produktion und Auslieferung liegen, die sich beim ersten Audit zum Problem entwickeln.
Häufige Fragen
Gilt das Einzelstück-Prinzip auch für bereits ausgelieferte Geräte? Nein. Der CRA wirkt auf das Inverkehrbringen. Bereits ausgelieferte Geräte sind nicht rückwirkend betroffen — solange keine wesentliche Änderung (Art. 3 Abs. 40) erfolgt, die eine erneute Bewertung auslöst.
Was zählt als „bekannte ausgenutzte Schwachstelle" gemäß Annex I §2(a)? Aktiv im Wild ausgenutzte CVEs, wie sie z.B. in der CISA Known Exploited Vulnerabilities Catalog oder vergleichbaren ENISA-Listen geführt werden. Theoretische Schwachstellen ohne nachgewiesene Ausnutzung sind weniger streng — fallen aber in den allgemeinen Vulnerability-Management-Prozess.
Wir liefern an einen EU-Importeur, nicht direkt an Endkunden. Wer trägt das Einzelstück-Risiko? Beide. Der EU-Importeur muss vor Markteinführung prüfen, dass das einzelne Gerät konform ist (Art. 19). In der Praxis verlangen EU-Importeure ab 2027 zunehmend SBOM und Patch-Nachweise pro Lieferung als Voraussetzung für die Annahme.
Gibt es Erleichterungen für Kleinst- oder Kleinunternehmen? Die SME-Erleichterungen nach Art. 33 Abs. 5 betreffen die Dokumentationsform, nicht die Sicherheitsanforderungen selbst. Ein Schweizer KMU darf vereinfachte technische Dokumentation einreichen, muss aber dennoch pro Einzelstück nachweisen, dass keine bekannten ausgenutzten Schwachstellen vorlagen.
Wie hängt das mit der Motion 24.3810 in der Schweiz zusammen? Das Schweizer Cybersicherheitsgesetz, das aus der Motion 24.3810 hervorgeht, wird voraussichtlich ähnliche Prinzipien für den Inlandsmarkt etablieren. Wer den EU CRA heute umsetzt, ist für die Schweizer Regelung zu großen Teilen bereits vorbereitet.