CRA: Guidance hilft, entscheiden musst du trotzdem selbst

6 MinutenLars Roith
Zwei aktuelle VDMA-Stellungnahmen zeigen, warum Hersteller offene CRA-Auslegungsfragen begründet entscheiden und später überprüfen müssen.

Der Cyber Resilience Act, kurz CRA, gibt Herstellern verbindliche Anforderungen vor. Für die Einordnung jedes Produkts, jeder Komponente und jeder Modernisierung liefert er jedoch nicht sofort eine fertige Ja-Nein-Antwort.

Um die Anwendung der Verordnung in der Praxis zu erleichtern, veröffentlicht die Europäische Kommission ergänzende Guidance-Dokumente. Diese Erläuterungen sollen Herstellern helfen, unbestimmte Rechtsbegriffe einheitlicher auszulegen, typische Anwendungsfälle zu verstehen und regulatorische Anforderungen auf konkrete Produkte und Entwicklungsprozesse zu übertragen. Die Guidance erklärt also, wie bestimmte Vorschriften verstanden werden können. Sie ersetzt jedoch nicht den Gesetzestext und trifft keine verbindlichen Entscheidungen für einzelne Produkte.

Zwei aktuelle VDMA-Stellungnahmen zeigen, dass selbst zentrale Fragen zur wesentlichen Änderung und zur Interoperabilität öffentlich umstritten bleiben. Dieser Beitrag zeigt, wie Hersteller bei solchen Fragen entscheidungsfähig werden, ohne eine strittige Rechtsauslegung als abschließend auszugeben.

Guidance schafft Orientierung, keine Rechtssicherheit

Die Verordnung (EU) 2024/2847 ist für diesen Beitrag der verbindliche rechtliche Ausgangspunkt. Ihre allgemeinen Anwendungspflichten gelten grundsätzlich ab dem 11. Dezember 2027, während die Meldepflichten aus Artikel 14 bereits ab dem 11. September 2026 gelten.

Die Guidance der Europäischen Kommission zum CRA vom 27. Juli 2026 hilft bei der Anwendung des CRA. Die Kommission bezeichnet sie ausdrücklich als nicht bindend und kündigt weitere Guidance an, falls sie erforderlich wird. Sie ändert deshalb weder den Verordnungstext noch seine Fristen und kann eine produktbezogene Entscheidung nicht vorwegnehmen.

Der Verband Deutscher Maschinen- und Anlagenbau, kurz VDMA, veröffentlichte am 24. August 2026 eine Position zu wesentlichen Änderungen und eine Position zu Erwägungsgrund 55 sowie Interoperabilität. Beide Beiträge kritisieren Teile der Kommissionsauslegung aus Sicht des Maschinenbaus. Sie sind keine verbindliche Rechtsauslegung und keine Ausnahme von CRA-Pflichten, machen aber sichtbar, dass die Guidance zentrale Fragen nicht endgültig beendet.

Zwei Streitfragen zeigen die Lücke

Wesentliche Änderung bei Modernisierungen

Artikel 3 Nummer 30 definiert, wann eine Änderung nach dem Inverkehrbringen als wesentlich gilt. Artikel 22 regelt, wann eine Person, die nicht Hersteller, Einführer oder Händler ist und ein wesentlich geändertes Produkt auf dem Markt bereitstellt, als Hersteller gilt. Die VDMA-Stellungnahme zu wesentlichen Änderungen kritisiert die Auslegung der Guidance der Kommission und fordert, den Wortlaut von Artikel 22 bei Modernisierungen durch Originalhersteller stärker zu berücksichtigen.

Damit ist nicht entschieden, welche Auslegung im Einzelfall rechtlich trägt. Die öffentliche Kritik zeigt aber: Auch nach der Guidance muss ein Hersteller Produktgrenze, Zweckbestimmung, Risikokontext und die Art der Marktbereitstellung selbst nachvollziehbar einordnen. Eine einzelne Passage aus einer Guidance als abschließende Antwort zu behandeln, wäre bei einer solchen Streitfrage zu kurz gegriffen.

Interoperabilität und Erwägungsgrund 55

Der CRA enthält 124 Erwägungsgründe, in denen der EU-Gesetzgeber Hintergrund, Zielsetzung und Auslegung der Regelungen näher erläutert. Erwägungsgrund 55 greift dabei ausdrücklich einen möglichen Zielkonflikt auf: Die Zweckbestimmung eines Produkts kann die Anwendung einer anerkannten Interoperabilitätsnorm erfordern, obwohl deren Sicherheitsmerkmale nicht mehr dem Stand der Technik entsprechen.

Der CRA verlangt in einem solchen Fall nicht, diesen Widerspruch zu ignorieren. Ist eine grundlegende Cybersicherheitsanforderung deshalb auf das konkrete Produkt nicht anwendbar, muss der Hersteller dies in seiner Cybersicherheitsrisikobewertung nachvollziehbar begründen und die damit verbundenen Risiken gegebenenfalls mit anderen Maßnahmen adressieren.

Der VDMA argumentiert, die Guidance der Kommission lege diesen Spielraum bei Komponenten und Interoperabilität zu eng aus. Er warnt vor Over-Engineering, also einer übermäßigen technischen Aufrüstung, bei etablierten Technologien wie PROFINET, EtherCAT oder IO-Link. Auch diese Verbandsposition beantwortet die Rechtsfrage nicht abschließend. Sie zeigt jedoch, dass die Guidance die produktbezogene Risikobewertung nicht ersetzt und eine Entscheidung die verwendeten Quellen, Annahmen und offenen Punkte sichtbar machen muss.

Quellen mit unterschiedlichem Gewicht nutzen

Nicht jede Quelle beantwortet dieselbe Frage und nicht jede Quelle hat dieselbe rechtliche Wirkung. Die Verordnung setzt die verbindlichen Pflichten. Harmonisierte Normen, gemeinsame Spezifikationen und europäische Cybersicherheitszertifizierungen können je nach Produkt und Anforderung einen Weg zum Konformitätsnachweis eröffnen.

Halte bei offenen Fragen deshalb fest, auf welche Quellen sich die Entscheidung stützt.

  1. Die Verordnung und weitere einschlägige Rechtsakte bestimmen die verbindlichen Anforderungen.
  2. Harmonisierte Normen, gemeinsame Spezifikationen und Zertifizierungen können für abgedeckte Anforderungen eine Konformitätsvermutung schaffen, wenn ihre Voraussetzungen erfüllt sind.
  3. Guidance der Kommission und häufige Fragen und Antworten, FAQs, helfen bei der Auslegung und Anwendung, bleiben aber unverbindlich.
  4. Veröffentlichungen von Behörden, Verbänden und Herstellern zeigen Praxispositionen oder Vollzugshinweise, ersetzen jedoch keine eigene Bewertung.

Diese Reihenfolge ist kein Schema, das eine Rechtsfrage automatisch löst. Sie verhindert aber, dass eine nützliche Orientierungshilfe unbemerkt wie verbindliches Recht behandelt wird. Wenn du tiefer in die Risikobewertung einsteigen willst, schau in unseren Artikel zur Cybersecurity-Risikobewertung in der Praxis.

Aus Unklarheit eine überprüfbare Entscheidung machen

Entscheidungsfähig zu werden heißt nicht, dass jeder Hersteller den CRA selbst auslegen kann. Es heißt, für ein konkretes Produkt, seine Zweckbestimmung und seinen Risikokontext auf Basis der verfügbaren Quellen eine begründete Entscheidung zu treffen. Die Entscheidung muss so dokumentiert sein, dass sie bei neuen Erkenntnissen nachvollzogen und überprüft werden kann.

  1. Grenze die Frage ab. Beschreibe Produkt, Komponente, Version, Zweckbestimmung und konkreten Entscheidungsanlass, statt eine abstrakte CRA-Frage beantworten zu wollen.
  2. Mache Quellen und Widersprüche sichtbar. Halte fest, welche Fassung der Verordnung, welche Normen, Guidance, FAQs oder Praxisposition berücksichtigt wurden und wo sie unterschiedliche Schlüsse nahelegen.
  3. Begründe die Bewertung im Produktkontext. Verbinde die relevante CRA-Stelle mit Risikobewertung, vorhersehbarer Nutzung, Einsatzbedingungen und vorhandenen Nachweisen.
  4. Dokumentiere Annahmen und offene Punkte. Formuliere klar, was entschieden wurde, worauf die Entscheidung beruht und welche Fragen ungeklärt bleiben.
  5. Lege Review-Auslöser fest. Eine neue Guidance, eine harmonisierte Norm, eine geänderte Produktversion, ein Sicherheitsvorfall oder neue Behördenpraxis können eine Neubewertung auslösen.

Bei Grenzfällen zu Marktbereitstellung, Produktabgrenzung oder Auswirkungen auf die funktionale Sicherheit der Maschine gehört die zuständige Compliance- und Rechtskompetenz früh in die Entscheidung. Ein sauberer Prozess macht eine strittige Auslegung nicht automatisch richtig. Er verhindert aber, dass sie unbegründet, unsichtbar oder dauerhaft unverändert bleibt.

Entscheidungen überprüfbar festhalten

Ein kurzes, versioniertes Entscheidungsprotokoll ist kein zusätzlicher Papierprozess neben der Entwicklung. Es verknüpft Risikobewertung, technische Dokumentation und vorhandene Nachweise mit dem aktuellen Stand der Quellenlage. So ist später nachvollziehbar, was entschieden wurde, welche Annahmen damals galten und wann die Bewertung erneut auf den Tisch muss.

decision-id: CRA-2026-042
product-scope: machine-controller, firmware 4.2
decision-question: substantial modification after controller replacement
sources:
  regulation: Regulation (EU) 2024/2847
  commission-guidance: C(2026) 5252, version of 2026-07-27
  industry-position: VDMA position of 2026-08-24
assessment: documented in risk assessment and technical documentation
assumptions:
  - original manufacturer performs the modernization
  - intended purpose remains unchanged
open-points:
  - effect of future Commission guidance
review-triggers:
  - new Commission guidance or FAQ
  - relevant harmonised standard
  - change to product or intended purpose

Das Entscheidungsprotokoll ersetzt keine Risikobewertung und keine rechtliche Prüfung. Es verhindert jedoch, dass eine Begründung nur in einem Ticket oder im Wissen einzelner Beteiligter bleibt.

Entscheiden können ist Teil der CRA-Compliance

Guidance, FAQs, harmonisierte Normen und die Vollzugspraxis werden den CRA in den kommenden Monaten weiter konkretisieren. Sie werden jedoch nicht jede Konfiguration, jede Bestandsmaschine und jeden Komponentenfall vorentscheiden.

Die beiden VDMA-Stellungnahmen zeigen das exemplarisch. Auch eine umfangreiche Guidance der Europäischen Kommission beendet eine fachliche und rechtliche Diskussion nicht automatisch. Das ist kein Grund, Entscheidungen zu verschieben, bis jede Unsicherheit verschwunden ist, oder nur die günstigste Quelle auszuwählen.

Hersteller sollten offene Auslegungsfragen erkennen, Quellen nach ihrem Gewicht bewerten, Entscheidungen im Produktkontext begründen und ihre Annahmen überprüfbar festhalten. CRA-Compliance bedeutet damit nicht nur, Anforderungen umzusetzen. Sie bedeutet auch, unter Unsicherheit begründet entscheiden und bei neuen Erkenntnissen neu bewerten zu können.

Wie entscheidungsfähig ist deine CRA-Umsetzung? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.

Autoren

Lars Roith

Lars Roith

Lars ist Solution Consultant und berät Unternehmen und Entwicklungsteams ganzheitlich bei der Umsetzung ihrer Softwareentwicklungsprojekte, von den Prozessen über die Anforderungen und Architekturen bis hin zu Umsetzung und Betrieb.