Bei 5 Produktlinien ist die EU-CRA-Compliance herausfordernd, aber noch mit einer Excel-Tabelle handhabbar. Bei 50 Varianten beginnt die Tabelle zu reißen. Bei 500 Varianten — typisch für Industrie-OEMs, IoT-Hersteller und Anbieter vernetzter Konsumgüter — ist Compliance ohne Plattform mathematisch unmöglich. Dieser Artikel erklärt, warum Multi-Produkt-Compliance unter dem CRA eine Plattformstrategie braucht, was die Plattform leisten muss und wie der Umstieg von manuellen Werkzeugen ohne Audit-Trail-Verlust gelingt.
Warum CRA-Aufwand pro Produkt nicht linear skaliert
Konformitätsbewertung unter dem CRA gilt pro Produkt, nicht pro Unternehmen. Oberflächlich gedacht: Wenn ein Produkt 100 Stunden Compliance-Aufwand braucht, kosten zehn Produkte 1.000 Stunden. In der Praxis ist die Beziehung super-linear — und der Grund dafür bestimmt die Plattformstrategie.
Software-Komposition über Varianten hinweg geteilt. Die meisten Multi-Produkt-Portfolios teilen 60–80 % ihrer Software-Komponenten über Varianten. Dieselbe Linux-Distribution, derselbe Schwachstellen-Scanner, dieselbe TLS-Bibliothek. Wenn jede Variante ihre eigene SBOM unabhängig pflegt, löst dasselbe Komponenten-Upgrade dasselbe SBOM-Update 500 Mal aus. Mit gemeinsamer Komponentenverfolgung fließt ein Upgrade automatisch in alle betroffenen Varianten.
Schwachstellen-Monitoring produktübergreifend. Eine CVE in OpenSSL 3.0.x betrifft jede Produktvariante, die diese Version nutzt. Ohne Plattform vervielfacht sich der Schwachstellen-Monitoring-Aufwand pro Variante. Mit Plattform geschieht das CVE-zu-Produkt-Matching einmal und produziert einen Fan-out-Alert.
Dokumentationsmuster wiederholen sich. Die Technische Dokumentation nach Anhang VII folgt für jedes Produkt derselben Struktur, mit produktspezifischen Nachweisen eingefügt. Manuelle Dokumentation baut das gleiche Gerüst 500 Mal neu. Eine Plattform speichert das Gerüst einmal und rendert variantenspezifische Nachweise hinein.
Wesentliche Änderungen kaskadieren. Wenn eine wesentliche Änderung an einer gemeinsam genutzten Komponente vorgenommen wird (Firmware-Basis, Kommunikations-Stack), muss jede Produktvariante mit dieser Komponente die Konformität neu bewerten. Ohne Plattform ist das Identifizieren der Kaskade eine manuelle Querreferenz-Übung. Mit Plattform ist die Kaskade automatisch aus dem Dependency-Graph ableitbar.
Was eine Multi-Produkt-CRA-Plattform leisten muss
Das Mindest-Funktionsset für Multi-Produkt-Compliance, abgeleitet aus der operativen Realität von 100+ Varianten-Portfolios:
Produktkatalog mit Varianten-Vererbung. Eine Plattform, die jedes Produkt als vollständig eigenständig behandelt, vervielfacht den Aufwand. Der Katalog sollte Produktfamilien mit gemeinsamen Attributen und Varianten-Overrides unterstützen. Eine neue Variante einer bestehenden Familie hinzuzufügen, erbt die Familien-Nachweise (SBOM-Basis, Schwachstellenbehandlungsprozess, Unterstützungszeitraum-Policy) und ergänzt nur das Varianten-Spezifische.
Variantenübergreifende SBOM-Aggregation. SBOMs pro Build-Artefakt erzeugen (CycloneDX oder SPDX). Komponenten über Varianten hinweg aggregieren, um geteilte Abhängigkeiten, Versions-Drift und End-of-Life-Risiken zu identifizieren. Die Frage „Welche Produkte enthalten log4j 2.14.x?" muss in Sekunden beantwortbar sein, nicht in Tagen.
Produktbezogene Risikoklassifizierung. CRA Anhang III-Klassen variieren je Produkt. Eine vernetzte Industrie-Steuerung kann Klasse II sein, während ihr Hand-Konfigurations-Zubehör in die Standardkategorie fällt. Die Plattform muss varianten-spezifische Risikoklassen und Konformitätsbewertungs-Modul-Zuordnung unterstützen.
Zentrale Schwachstellen-Triage mit produktbewusstem Routing. Wenn eine neue CVE eintrifft, identifiziert das System jede betroffene Variante, berechnet die Severity im Produktkontext (CVSS angepasst an das Bedrohungsmodell des Produkts) und routet die entstehenden Tickets an den verantwortlichen Produkt-Owner. Schwachstellenbehandlung ist eine Pflicht pro Produkt — die Plattform muss die Per-Produkt-Nachvollziehbarkeit erzwingen.
Wesentliche-Änderungs-Impact-Analyse. Wenn ein Entwickler eine wesentliche Änderung an einer geteilten Komponente vorschlägt, zeigt die Plattform, welche Produktvarianten betroffen sind, welche Konformitätsbewertungen neu validiert werden müssen und wie der kumulative Re-Assessment-Aufwand aussieht.
Audit-fertige Nachweis-Erstellung. Auf Knopfdruck die vollständige Technische Dokumentation jeder Produktvariante erzeugen — inklusive EU-Konformitätserklärung, SBOM, Testberichten, Beschreibung des Schwachstellenbehandlungsprozesses und Änderungshistorie. Ohne Plattform ist diese Zusammenstellung der mehrtägige Aufwand, der zum Deal-Breaker wird, wenn eine Marktüberwachungs-Anfrage eintrifft.
Migration: Vom Tabellenblatt zur Plattform ohne Audit-Trail-Verlust
Der häufigste Einwand gegen eine Plattform-Migration ist, dass das bestehende Excel- und Shared-Drive-Setup Jahre an Compliance-Arbeit enthält, die nicht verloren gehen darf. Eine strukturierte Migration schützt diese Historie.
Phase A — Aktuellen Zustand snapshotten. Vor jedem Eingriff die aktuellen Tabellen und Shared-Drive-Ordner in ein versioniertes Archiv exportieren. Das ist die Pre-Migrations-Nachweis-Baseline. Sie muss laut CRA-Dokumentations-Aufbewahrungs-Regeln zehn Jahre zugänglich bleiben.
Phase B — Datenmodell abbilden. Entitäten im bestehenden Setup identifizieren: Produkte, Varianten, Software-Komponenten, Zulieferer, Schwachstellen, Konformitätsbewertungen. Jede auf das Datenmodell der Plattform abbilden. Die meisten Excel-Setups haben eine große „Produkte"-Tabelle mit gemischten Spalten; die Plattform trennt Produkte, Varianten und Komponenten in separate Entitäten mit expliziten Beziehungen.
Phase C — Aktives Portfolio zuerst migrieren. Die aktuell ausgelieferten Produktvarianten zuerst übernehmen. Historische End-of-Life-Varianten können später als Read-only-Archiv migriert werden. Diese Phasierung begrenzt das Migrationsrisiko auf die Produkte, die für laufende Compliance-Pflichten am wichtigsten sind.
Phase D — Parallelbetrieb für 30 Tage. Plattform und Bestands-Setup 30 Tage parallel laufen lassen. Neue Compliance-Arbeit geht in die Plattform; bestehende Referenzdaten bleiben im Archiv zugänglich. Nach Tag 30 die Excel-Workflows abschalten.
Phase E — Audit-Trail festschreiben. Plattform-Audit-Logs ab Tag eins erzeugen. Jede Änderung an Produkt, SBOM, Schwachstellenbewertung oder Konformitätserklärung ist zeitgestempelt, attributiert und unveränderlich. Das ist das Audit-Trail-Substrat, das die Excel-Welt nie hatte — und der konkreteste Compliance-Gewinn der Migration.
Das 80/20 der Multi-Produkt-Compliance
Für Hersteller mit 50+ Varianten liefern vier Praktiken 80 % des Multi-Produkt-Compliance-Nutzens:
Früh komponentisieren. Geteilte Software-Komponenten über Varianten identifizieren und auf Komponentenebene managen, nicht auf Produktebene. SBOM-Updates, Schwachstellenbewertungen und Sicherheitspatches fließen von der Komponente zum Produkt, nicht umgekehrt.
Varianten-Vererbung. Produktfamilien mit gemeinsamen Baselines definieren und Varianten erben lassen. Die 51. Variante zu einer Familie hinzuzufügen, dauert Stunden, nicht Wochen.
Dokumentations-Rendering automatisieren. Technische Dokumentation aus strukturierten Daten erzeugen, nicht von Hand pflegen. Wenn Daten sich ändern, regeneriert die Dokumentation. Wenn die Dokumentation regeneriert werden muss, haben sich Daten geändert — und der Audit-Trail spiegelt das wider.
Ein Source-of-Truth pro Datenart. SBOMs in einem System, Schwachstellen in einem System, Konformitätsbewertungen in einem System. Die Kosten doppelter Quellen werden in jedem Audit, jeder Marktüberwachungs-Anfrage und jedem Produkt-Launch bezahlt.
Wie Kunnus Multi-Produkt-Compliance skaliert
Kunnus ist für diese Realität gebaut. Der Produktkatalog unterstützt Varianten-Vererbung mit gemeinsamem Komponenten-Management. SBOM-Aggregation läuft über das gesamte Portfolio mit Ein-Klick-Identifikation gemeinsamer Abhängigkeiten und Versions-Drift. Die Vulnerability-Engine bildet CVEs automatisch auf Produktvarianten ab und routet Tickets an die verantwortlichen Owner. Die Wesentliche-Änderungs-Impact-Analyse zeigt den Kaskaden-Umfang vor dem Commit. Audit-fertige Nachweis-Erstellung ist ein Klick pro Produkt, und der plattformweite Audit-Trail erfasst jede Änderung mit Attribution.
Für Enterprise-Hersteller mit Hunderten von Varianten ergänzt die Kunnus Enterprise-Plattform rollenbasierte Zugriffsebenen, Multi-Team-Workflows und Integration in bestehende PLM- und CI/CD-Systeme.
Starten Sie mit unserer CRA-Reifegradanalyse — oder sprechen Sie mit unserem Team über einen Portfolio-Walkthrough, der auf Ihre Variantenzahl zugeschnitten ist.