Cyber Resilience Act Leitlinien: worum es jetzt praktisch geht
Die EU-Kommission hat einen Entwurf von Leitlinien zur Anwendung des Cyber Resilience Act vorgelegt und damit zentrale Auslegungsfragen für die Praxis konkretisiert. Der Cyber Resilience Act ist eine europäische Verordnung, die verbindliche Anforderungen an die Cybersicherheit bestimmter digitaler Produkte und Software über den gesamten Lebenszyklus setzt. Für Unternehmen, die Software entwickeln, vertreiben, in eigene Produkte integrieren oder als Betreiber in kritischen Prozessen einsetzen, ist vor allem relevant, wie die Kommission die Begriffe „Inverkehrbringen“, „fortgesetzte Bereitstellung“, „wesentliche Änderung“ und die Anforderungen an eine Cybersecurity Risk Assessment einordnet. Diese Leitlinien sind zwar als Auslegungshilfe konzipiert, haben aber erhebliche Bedeutung für die Risikosteuerung, die technische Roadmap und die vertragliche Gestaltung in Lieferketten, etwa bei Standardsoftware, Branchenlösungen für Pflegeeinrichtungen oder Krankenhäuser, ERP-Systemen im Mittelstand oder Shop- und Payment-Komponenten im Onlinehandel.
Im Kern wird deutlich, dass der Zeitpunkt der erstmaligen kommerziellen Bereitstellung einer konkreten Softwareversion im EU-Markt entscheidend ist, um zu bestimmen, ob und wann die jeweilige Version als in Verkehr gebracht gilt. Gleichzeitig adressieren die Leitlinien die häufige Praxis, Softwareversionen über längere Zeit unverändert zum Download anzubieten, und grenzen diese Konstellation von einem erneuten Inverkehrbringen ab. Für Hersteller und Anbieter ist das besonders wichtig, weil sich daran anknüpfen kann, ob die Anforderungen des Cyber Resilience Act für eine Version neu zu erfüllen sind. Für Nutzerunternehmen, die Software beschaffen und betreiben, ergeben sich daraus klare Fragen an Release-Management, Dokumentation und die Bewertung von Updates, insbesondere wenn Sicherheitsanforderungen und Compliance-Vorgaben im Unternehmen eng verzahnt sind.
Inverkehrbringen und fortgesetzte Bereitstellung von On-Premise-Software
Ein zentraler Punkt der Leitlinien betrifft Standalone Software, die über digitale Mittel bereitgestellt wird. Für immaterielle Produkte stellt die Kommission darauf ab, dass die erstmalige kommerzielle Bereitstellung einer konkreten Softwareversion auf dem EU-Markt maßgeblich ist. Mit diesem Zeitpunkt gilt die Version als in Verkehr gebracht. Das ist für die Praxis deshalb bedeutsam, weil die fortgesetzte Bereitstellung derselben unveränderten Version, etwa wenn ein Kunde die Software später erneut herunterlädt oder ein weiterer Kunde dieselbe Version bezieht, nicht als erneutes Inverkehrbringen verstanden wird. Die Kommission ordnet diese Konstellation vielmehr als fortgesetztes „Making available“ ein, also als fortgesetzte Bereitstellung derselben Version.
Damit wird eine häufige Unsicherheit im Markt adressiert: Wenn eine Softwareversion vor dem Anwendungsbeginn des Cyber Resilience Act erstmals in Verkehr gebracht wurde, fällt sie nach der Leitlinienlogik nicht allein deshalb unter die neuen Anforderungen, weil sie nach dem Anwendungsbeginn weiterhin unverändert verfügbar bleibt. Für Hersteller von On-Premise-Lösungen, etwa im Bereich Kanzleisoftware, ERP-Systeme oder branchenspezifische Anwendungen für das Gesundheits- und Pflegewesen, ist das eine wichtige Abgrenzung für Bestandsprodukte und deren Weitervertrieb. Gleichzeitig gilt: Sobald Änderungen vorgenommen werden, stellt sich die Frage, ob dadurch ein neues Inverkehrbringen ausgelöst wird. Die Leitlinien verknüpfen dies ausdrücklich mit der Einordnung als wesentliche Änderung, also als „substantial modification“.
Für mittelständische Anbieter und kleine Softwarehäuser ist diese Differenzierung operativ relevant, weil sie Release-Zyklen, Produktpflege und Patch-Strategien beeinflusst. Wer eine unveränderte Version weiter bereitstellt, sollte dennoch die internen Nachweise so organisieren, dass klar ist, welche Version wann erstmals kommerziell bereitgestellt wurde und ob spätere Bereitstellungen tatsächlich unverändert erfolgten. Für Nutzerunternehmen, insbesondere wenn mehrere Standorte oder Mandantenstrukturen existieren, wird damit auch die Lizenz- und Deployment-Dokumentation wichtiger, weil sie im Zweifel zeigt, ob es sich um dieselbe Version handelt oder ob faktisch neue Versionen ausgerollt wurden.
Wesentliche Änderung und Update-Praxis: wann CRA-Konformität auslöst
Die Leitlinien definieren, wann nachträgliche Änderungen als wesentlich gelten. Wesentlich sind demnach nur Änderungen, die entweder Auswirkungen auf die Erfüllung der wesentlichen Cybersicherheitsanforderungen haben oder den ursprünglich bewerteten Verwendungszweck der Software verändern. Entscheidend ist also nicht, wie groß ein Update wirkt, wie häufig es kommt oder wie es im Marketing bezeichnet wird, sondern ob dadurch neue oder erhöhte Cybersicherheitsrisiken entstehen, die in der ursprünglichen Risikoanalyse nicht berücksichtigt waren. Damit wird ein klarer risikobasierter Maßstab gesetzt: Die Frage lautet, ob sich das Risiko- und Sicherheitsprofil gegenüber der ursprünglichen Bewertung so verändert, dass eine neue Bewertung erforderlich wird.
Besonders praxisrelevant ist die Aussage, dass reine Sicherheitsupdates oder Änderungen, die sich innerhalb der Annahmen der ursprünglichen Risikoanalyse bewegen und keine neuen Risiken einführen, grundsätzlich nicht als neues Inverkehrbringen gelten. Das ist für Unternehmen mit hohen Update-Frequenzen, etwa bei Onlinehändlern mit Shop-Systemen und Integrationen in Payment oder Logistik, ebenso wichtig wie für Betreiber von IT-Systemen in Pflegeeinrichtungen und Krankenhäusern, bei denen Sicherheitsupdates zum Standardbetrieb gehören. Gleichzeitig bleibt die Pflicht, Updates nachvollziehbar zu steuern. In der Praxis empfiehlt sich ein Release-Prozess, der schon vor der Auslieferung bewertet, ob eine Änderung sicherheitsrelevant ist, ob sie den Verwendungszweck verschiebt und ob Abhängigkeiten betroffen sind, die neue Angriffspunkte eröffnen könnten. Gerade bei Funktionsupdates, die Authentifizierung, Synchronisation, Konfiguration oder Update-Mechanismen selbst betreffen, kann die Schwelle zur wesentlichen Änderung schneller erreicht werden, weil solche Bausteine regelmäßig sicherheitskritisch sind.
Für Steuerberatende und Finanzinstitutionen, die in Vendor-Management und Auslagerungssteuerung eingebunden sind, ergeben sich daraus klare Prüfpunkte in der Lieferantenkommunikation: Es reicht nicht, auf Versionsnummern oder Changelogs zu schauen. Relevant ist, ob das Update neue Risiken erzeugt, ob der Hersteller dies in der Risikoanalyse abgebildet hat und ob die wesentlichen Anforderungen weiterhin erfüllt werden. Wer Software beschafft, sollte außerdem vertraglich sicherstellen, dass der Hersteller die Kriterien für wesentliche Änderungen transparent anwendet und bei entsprechenden Änderungen die erforderlichen Compliance-Nachweise bereitstellt, ohne dass operative Prozesse durch unklare Zuständigkeiten verzögert werden.
Cybersecurity Risk Assessment und Remote Data Processing Solutions
Die Leitlinien konkretisieren zudem die Cybersecurity Risk Assessment, also die Cybersicherheits-Risikoanalyse. Diese Risikoanalyse bezieht sich auf das Produkt selbst und ist danach zu beurteilen, ob identifizierte Cyberrisiken hinreichend adressiert wurden. Maßgeblich sind dabei insbesondere Zweck und vorhersehbare Nutzung des Produkts, die Einsatzbedingungen, die zu schützenden Werte und Daten sowie die erwartete Nutzungsdauer. Für die Praxis bedeutet das: Die Risikoanalyse darf nicht abstrakt bleiben, sondern muss das reale Nutzungsszenario abbilden. Bei einer Branchenlösung im Gesundheitswesen wird man andere schützenswerte Werte und andere Einsatzbedingungen annehmen als bei einer internen Zeiterfassung oder bei einem Webshop-Plugin. Ebenso kann die erwartete Nutzungsdauer bei On-Premise-Lösungen länger sein, was die Bedeutung eines belastbaren Patch- und Update-Konzepts erhöht.
Wesentlich ist auch die Klarstellung, dass identifizierte Cyberrisiken durch Maßnahmen auf Produktebene behandelt werden müssen. Der Cyber Resilience Act sieht nach der Leitlinienlogik keine Möglichkeit vor, Risiken oder Verantwortung auf Nutzer oder Dritte zu verlagern. Hinweise, Dokumentationen und Anleitungen können die sichere Nutzung unterstützen, ersetzen aber keine technischen oder organisatorischen Maßnahmen im Produkt selbst. Für Anbieter bedeutet das, dass „Security by Documentation“ nicht genügt. Für Nutzerunternehmen heißt es, dass man sich nicht darauf verlassen sollte, durch interne Richtlinien allein Produktdefizite zu kompensieren, sondern bereits in der Auswahl und Abnahme auf belastbare Sicherheitsmechanismen achten muss.
Wenn Risiken nicht ausreichend gemindert werden können, können Anpassungen von Design, Funktionalität oder vorgesehenem Verwendungszweck erforderlich werden. In der Umsetzung betrifft das häufig die Entscheidung, bestimmte Funktionen nur unter restriktiven Standardkonfigurationen auszuliefern oder Abhängigkeiten zu ändern, die schwer kontrollierbare Risiken einführen. Die Leitlinien betonen außerdem, dass Risiken aus externen Abhängigkeiten, etwa aus Cloud-Diensten oder integrierten Drittkomponenten, in der Risikoanalyse zu berücksichtigen sind und die Erfüllung der wesentlichen Anforderungen nicht beeinträchtigen dürfen. Das ist besonders relevant, weil moderne Software typischerweise aus einer Kette von Komponenten besteht. Wer etwa Standardbibliotheken einbindet, Authentifizierungsdienste nutzt oder Update-Server betreibt, muss diese Abhängigkeiten sauber erfassen und bewerten.
In diesem Kontext wird auch der Begriff der Remote Data Processing Solutions aufgegriffen. Gemeint sind Lösungen, bei denen Datenverarbeitung außerhalb der Nutzerumgebung stattfindet, diese Verarbeitung funktional notwendig ist und die betreffende Software vom Hersteller selbst entwickelt oder maßgeschneidert unter seiner Verantwortung erstellt wurde. Die Leitlinien stellen klar, dass solche Remote Data Processing Solutions Teil des Produkts im Sinne des Cyber Resilience Act sein können, wenn sie für die Ausführung von Produktfunktionen erforderlich sind. Der Funktionsbegriff wird weit verstanden und erfasst auch unterstützende Funktionen wie Authentifizierung, Konfiguration, Synchronisation oder Updates. Damit wird für hybride Architekturen relevant, ob ein Hersteller bestimmte Remote-Komponenten als Teil des Produkts verantwortet und entsprechend in Risikoanalyse und Lifecycle-Pflichten einbeziehen muss.
Gleichzeitig grenzen die Leitlinien ab, dass interne Unternehmenssysteme des Herstellers sowie generische Software-as-a-Service-Dienste oder lizenzierte Standardsoftware nicht vom Produktbegriff erfasst sind. Solche externen Dienste gelten als Drittkomponenten und müssen im Rahmen der Risikoanalyse und einer angemessenen Sorgfalt berücksichtigt werden, ohne selbst Teil des Produkts zu werden. Für die Praxis ist diese Unterscheidung wichtig, weil sie bestimmt, wie Verantwortlichkeiten in der Lieferkette verteilt sind und welche Nachweise ein Hersteller aus eigener Sphäre liefern muss. Für Nutzerunternehmen bleibt dennoch die Aufgabe, Drittkomponentenrisiken im Beschaffungsprozess zu adressieren, etwa über Mindestanforderungen an Sicherheitsstandards, Update- und Supportzusagen sowie klare Eskalationswege bei Sicherheitsvorfällen.
Fazit: Die Leitlinien der EU-Kommission liefern eine praxistaugliche Auslegung, wann Softwareversionen als in Verkehr gebracht gelten, wann Updates als wesentliche Änderungen eine neue Konformitätsbetrachtung auslösen und wie Risikoanalysen produktbezogen und ohne Verantwortungsverlagerung auf Nutzer zu gestalten sind. Wir unterstützen kleine und mittelständische Unternehmen dabei, diese Anforderungen in effiziente, digitalisierte Buchhaltungs- und IT-nahe Prozesse zu übersetzen und durch klare Workflows und Dokumentation messbare Kostenersparnisse in der Organisation zu realisieren.
Gerichtsentscheidung lesen
