Für einen Hersteller mit einem einzigen Produkt ist die CRA-Konformität ein klar umrissenes Projekt mit einem eindeutigen Endpunkt. Für einen Hersteller mit einem Produktportfolio, mehreren gleichzeitig unterstützten Produktversionen und einer Entwicklungspipeline, die neue Releases hervorbringt, ist Compliance eine kontinuierliche operative Funktion. Die erforderlichen Werkzeuge, Prozesse und Disziplinen unterscheiden sich sowohl im Umfang als auch im Charakter.
Dieser Beitrag behandelt die strukturellen und operativen Fragen, die entstehen, wenn die CRA-Konformität kein einmal abzuschließendes Projekt ist, sondern ein Programm, das über ein gesamtes Produktportfolio hinweg betrieben werden muss.
Warum Portfolio-Compliance anders ist
Die Anforderungen des CRA gelten pro Produkt, nicht pro Organisation. Jedes Produkt mit digitalen Elementen erfordert seine eigene Risikobewertung, seine eigene technische Dokumentation, seine eigene Konformitätserklärung und seine eigenen Aufzeichnungen zur Schwachstellenbehandlung. Ein Hersteller mit zwanzig Produkten hat zwanzig Sätze dieser Pflichten, jeden in einer anderen Phase des Produktlebenszyklus, jeden mit unterschiedlichen Risikoprofilen und jeden mit unterschiedlicher Anwendbarkeit der grundlegenden Anforderungen je nach Produktklasse.
Die Herausforderung besteht nicht darin, dass ein einzelnes Produkt schwer zu verwalten wäre. Die Herausforderung besteht darin, dass dieselbe Sorgfalt konsistent auf alle anzuwenden ist, mit denselben Beweisstandards, durch Teams, die typischerweise konkurrierende Prioritäten haben.
Compliance über Produktlinien hinweg strukturieren
Der verlässlichste Ansatz für Portfolio-Compliance ist es, die grundlegenden Anforderungen als strukturiertes Bewertungsrahmenwerk zu behandeln und sie konsistent auf jedes Produkt anzuwenden, angepasst an die spezifischen Eigenschaften jeder Produktklasse.
Anhang I des CRA listet 21 grundlegende Anforderungen in zwei Kategorien auf: Sicherheitseigenschaften des Produkts selbst und Pflichten zur Schwachstellenbehandlung. Nicht alle Anforderungen gelten mit demselben Gewicht für jedes Produkt, aber alle müssen für jedes in den Geltungsbereich fallende Produkt behandelt und dokumentiert werden. Die praktische Umsetzung ist eine Bewertung auf Produktebene gegen jede Anforderung, mit angehängten Nachweisen.
Dies nach Produktlinie statt nach Anforderung zu strukturieren, hat zwei Vorteile. Erstens wird es dadurch möglich, die Bewertungsarbeit an die Teams zu delegieren, die jedes Produkt am besten kennen. Zweitens entsteht ein Compliance-Status, der auf Produktebene sichtbar ist, also auf der Ebene, auf der Marktüberwachungsbehörden und notifizierte Stellen ihn prüfen werden.
Das Versionsmanagement ist eine weitere Komplikation. Wird ein Produkt aktualisiert, lautet die Frage, ob das Update das Risikoprofil so weit verändert, dass eine überarbeitete Bewertung erforderlich ist. Die Verordnung zieht keine klare Grenze, aber aktualisierte Firmware, die neue Netzwerkschnittstellen einführt, das Authentifizierungsverhalten ändert oder neue Datenverarbeitung hinzufügt, erfordert fast immer eine Überprüfung. Ein Portfolio-Compliance-Prozess muss einen definierten Auslöser für die Neubewertung haben, wenn sich Produkte ändern.
Grundlegende Anforderungen in geführte Bewertungen übersetzen
Die grundlegenden Anforderungen in Anhang I sind auf einer Abstraktionsebene formuliert, die für eine Verordnung notwendig, für einen Ingenieur aber unzureichend ist. „Produkte sind so zu gestalten, dass die Angriffsflächen begrenzt werden“ ist ein Prinzip. Die bewertbare Frage lautet: Welche konkreten Designentscheidungen hat dieses Produktteam getroffen, um die Angriffsflächen zu begrenzen, und welcher Nachweis belegt, dass diese Entscheidungen umgesetzt wurden?
Abstrakte Anforderungen in fachspezifische Bewertungsfragen zu übersetzen, ist die Arbeit, die Compliance umsetzbar macht. Bei einem vernetzten Verbrauchergerät bedeutet die Verringerung der Angriffsflächen, ungenutzte Netzwerkdienste zu deaktivieren, unnötige Ports zu schließen und auf allen Verwaltungsschnittstellen eine Authentifizierung zu verlangen. Bei einer Industriesteuerung bedeutet es, Prozesssteuerungsschnittstellen vom Zugriff aus dem Firmennetz zu isolieren und bei Firmware-Updates eine kryptografische Authentifizierung zu erzwingen.
Ein gut strukturierter Bewertungsprozess baut diese fachspezifischen Fragen in die Bewertungsvorlage jeder Produktklasse ein, sodass die Ingenieure, die die Bewertung ausfüllen, konkrete Fragen zu ihrem spezifischen Produkt beantworten statt regulatorischen Text auszulegen.
Mit Reifegradbewertung Fortschritt verstehen und verfolgen
Eine binäre Bestanden/Nicht-bestanden-Bewertung gegen die grundlegenden Anforderungen sagt Ihnen, ob ein Produkt konform ist oder nicht. Sie sagt Ihnen nicht, wie weit es von der Konformität entfernt ist, welche Lücken am bedeutendsten sind oder ob sich das Programm als Ganzes in die richtige Richtung bewegt.
Die Reifegradbewertung begegnet dem, indem sie jeder grundlegenden Anforderung einen abgestuften Wert zuweist, der auf der Qualität und Vollständigkeit der vorhandenen Kontrollen beruht. Ein Produkt ohne formale Risikobewertung erhält einen anderen Wert als eines mit einem informellen Prozess, das wiederum einen anderen Wert erhält als eines mit einem strukturierten, dokumentierten und regelmäßig überprüften Prozess, der auf eine anerkannte Norm ausgerichtet ist.
Für das Portfoliomanagement liefert die Reifegradbewertung mehrere nützliche Ergebnisse. Sie erlaubt es Compliance-Managern, Behebungsarbeiten zu priorisieren, indem sie identifiziert, welche Produkte und welche Anforderungen die größten Lücken aufweisen. Sie liefert eine Fortschrittskennzahl, die sich über die Zeit verfolgen und an das Management berichten lässt. Und sie schafft eine Grundlage für die Ressourcenzuweisung im Portfolio: Produkte, die der Konformität näher sind, erfordern weniger Investitionen als solche in frühen Reifephasen.
Die Reifegradbewertung ersetzt nicht die binäre Compliance-Bewertung, die für die Konformitätserklärung erforderlich ist. Sie ergänzt sie, indem sie die Sichtbarkeit liefert, die nötig ist, um Compliance als Programm statt als Checkliste zu steuern.
Nachweise konsistent sammeln und verwalten
Die nach CRA-Anhang VII erforderliche technische Dokumentation muss für jedes Produkt erstellt und gepflegt werden. Die Dokumentation ist kein einzelnes Dokument, sondern eine strukturierte Sammlung von Nachweisen: Risikobewertungen, Bedrohungsmodelle, Testergebnisse, Schwachstellenaufzeichnungen, Patch-Historien und Konformitätserklärungen.
Über ein Portfolio hinweg bedeutet eine konsistente Beweissammlung, dass für jedes Produkt dieselben Arten von Nachweisen existieren, dass die Nachweise an einem kontrollierten Ort mit Versionshistorie gespeichert sind und dass die Verbindung zwischen einem bestimmten Nachweis und der grundlegenden Anforderung, die er adressiert, ausdrücklich und nachvollziehbar ist.
Der zu vermeidende Fehlermodus sind verstreute Dateien. Risikobewertungen auf einem geteilten Laufwerk, Testergebnisse in CI/CD-Pipeline-Logs, Schwachstellenaufzeichnungen in E-Mail-Verläufen und Konformitätserklärungen in einem Ordner, den niemand seit der ersten Zertifizierung überprüft hat. Wenn eine Marktüberwachungsbehörde die technische Dokumentation für ein Produkt anfordert oder wenn eine schwerwiegende Schwachstelle entdeckt wird und der Hersteller das vollständige Risikoprofil des Produkts verstehen muss, sind verstreute Nachweise der Unterschied zwischen einer kontrollierten Reaktion und einer Krise.
Der Wert von Prüfpfaden und rollenbasierter Zusammenarbeit
Compliance-Programme erfordern, dass mehrere Personen zu Bewertungen beitragen, Nachweise prüfen und Entscheidungen über die Konformität treffen. Prüfpfade halten fest, wer was bewertet hat, wann er es bewertet hat und welche Entscheidung getroffen wurde. Das ist aus zwei Gründen wichtig.
Erstens zeigt es Marktüberwachungsbehörden, dass der Compliance-Prozess keine Dokumentenübung ist, sondern ein organisatorischer Prozess mit echter Verantwortlichkeit. Zweitens unterstützt es die interne Governance, die nötig ist, um Compliance über die Zeit aufrechtzuerhalten. Verlässt ein Ingenieur das Unternehmen, geht die Bewertungshistorie nicht mit ihm. Wird ein Produkt zwei Jahre nach seiner ersten Konformitätserklärung geprüft, ist der Nachweis dessen, was getan wurde und warum, abrufbar.
Rollenbasierter Zugriff in einem Portfolio-Compliance-Werkzeug stellt sicher, dass Produktingenieure zu Bewertungen beitragen können, ohne Zugriff zu haben, um Compliance-Aufzeichnungen anderer Produkte zu ändern, und dass Compliance-Manager das gesamte Portfolio überwachen können, ohne zum Flaschenhals für jede einzelne Bewertung werden zu müssen.
Wie KMU die Compliance-Kosten senken und zugleich prüfbereit bleiben
Der oben beschriebene Compliance-Aufwand ist real, aber er ist nicht proportional zur Zahl der Produkte im Portfolio. Ein gut strukturiertes Bewertungsrahmenwerk, wiederverwendbare Beweisvorlagen und ein zentralisiertes Compliance-Werkzeug senken die Grenzkosten für die Aufnahme jedes neuen Produkts in das Programm erheblich. Die fixe Investition steckt in der Struktur; die variablen Kosten pro Produkt sinken, je reifer der Prozess wird.
Für KMU ist die wichtigste Disziplin, mit Struktur zu beginnen, statt sie später hinzuzufügen. Ein in einer geteilten Tabelle aufgebautes Compliance-Programm muss irgendwann auf ein kontrolliertes System migriert werden, und diese Migration geschieht unter Zeitdruck. Mit kontrollierten, prüffähigen, rollenbasierten Werkzeugen zu beginnen, kostet am Anfang fast nichts zusätzlich und vermeidet später erhebliche Nacharbeitskosten.
Die Frist im Dezember 2027 ist das harte Compliance-Datum für das gesamte Portfolio. Doch die Frist im September 2026 für die Melde- und Vorfallpflichten kommt zuerst. Organisationen, die jetzt ein strukturiertes Portfolio-Compliance-Programm aufbauen, haben Zeit, sowohl die Pflichten vom September 2026 zu erfüllen als auch das breitere Programm für die Konformitätsanforderungen vom Dezember 2027 zu positionieren.