Cyber Resilience Act

Pflichten, Fristen und Methodik für Hersteller

Der Cyber Resilience Act verpflichtet Hersteller, Cybersicherheit von der Produktentwicklung bis zum Support‑Ende nachvollziehbar zu dokumentieren. Wer die Anforderungen früh strukturiert, verwandelt eine komplexe Verordnung in einen beherrschbaren Prozess.

kontaktperson-foto
Ein Whitepaper von Sarah Fluchs

CTO admeritia, Individual Member der CRA Expert Group der EU‑Kommission und Co‑Convenor der ISA/IEC 62443‑3‑2.

In diesem Leitfaden erklären wir, was der Cyber Resilience Act von Herstellern verlangt, welche Fristen greifen und wie eine sechsstufige Methodik den Weg zur Konformität konkretisiert.

Was ist der Cyber Resilience Act?


Der Cyber Resilience Act, kurz CRA, regelt europaweit erstmals die Cybersicherheit von Produkten mit digitalen Elementen. Die Verordnung (EU) 2024/2847 erschien am 20. November 2024 im Amtsblatt der EU und trat am 10. Dezember 2024 in Kraft. Vollständig verbindlich wird sie am 11. Dezember 2027, 36 Monate danach.

Vor dem CRA gab es kaum verbindliche Vorgaben dafür, wie viel Cybersicherheit ein vernetztes Produkt bereits vor dem Marktzugang erfüllen muss. Hersteller entwickelten Router, Industriesteuerungen oder smarte Sensoren häufig ohne einen einheitlichen Cybersecurity‑Sicherheitsmaßstab. Der CRA schreibt Cybersicherheitsanforderungen nun über den gesamten Produktlebenszyklus fest, von der Entwicklung bis zum Ende des Supportzeitraums.

Als EU‑Verordnung gilt der CRA unmittelbar in allen Mitgliedstaaten, ein nationales Umsetzungsgesetz entfällt. Betroffen sind Hersteller, Importeure und Händler von Produkten mit digitalen Elementen, die auf den EU‑Markt gelangen – Hardware ebenso wie eigenständige Software. Medizinprodukte, Fahrzeuge und Luftfahrtprodukte bleiben ausgenommen, für sie gelten eigene Cybersicherheitsregeln.

Der CRA und die NIS2‑Richtlinie adressieren unterschiedliche Ebenen. NIS2 verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zu organisatorischem Risikomanagement im eigenen Unternehmen. Der CRA setzt an der Produktebene an und verpflichtet Hersteller, Sicherheit in ihre Produkte einzubauen, bevor diese in Betrieb gehen. Ein Hersteller von Industriesteuerungen beispielsweise trägt damit häufig beide Pflichten gleichzeitig.

Zeitplan & Fristen – Was gilt ab wann?

Der CRA staffelt seine Pflichten über gut drei Jahre, und genau diese Staffelung unterschätzen viele Hersteller. Seit dem 10. Dezember 2024 gilt die Verordnung formal, ab dem 11. September 2026 greifen die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, ab dem 11. Dezember 2027 gilt der CRA vollständig.

CRA‑Fristen im Überblick

  1. CRA tritt formal in Kraft

    Die Verordnung ist offiziell in Kraft getreten.

  2. Nächster Schritt

    Meldepflichten für aktiv ausgenutzte Schwachstellen aktiv

    (24h/72h/14‑Tage‑Fristen an ENISA)

  3. CRA vollständig verbindlich

    Marktzugang nur mit konformen Produkten

Infografik zum Zeitplan und zu den Fristen des Cyber Resilience Act

Wie der CRA Produkte klassifiziert


Der CRA unterscheidet drei Produktklassen: Standard‑Produkte, wichtige Produkte und kritische Produkte. Die Einstufung richtet sich nach der Zugehörigkeit zu bestimmten Produktkategorien, die im Anhang III und IV beschrieben werden und in dem Durchführungsrechtsakt genauer definiert werden.

Die Zugehörigkeit zu den Produktklassen ändert nichts an den geltenden Anforderungen, sondern nur daran, welche Konformitätsbewertungsverfahren möglich sind.

Frei zugängliche und quelloffene Software bleibt außerhalb einer kommerziellen Tätigkeit vollständig ausgenommen; für kommerziell getragene Open‑Source‑Projekte definiert die EU‑Kommission die Rolle des Open‑Source‑Software‑Stewards mit einem vereinfachten Pflichtenregime nach Artikel 24. Details der EU‑Kommission.

Standard

ca. 90 % aller Produkte

Beispielprodukte

Die meisten vernetzten Consumer- und Industrieprodukte

Konformitätsbewertung

Der Hersteller darf eine interne Selbstbewertung durchführen.

!

Wichtig – Klasse I

Anhang III

Beispielprodukte

Passwortmanager, VPN, Netzwerküberwachung

Konformitätsbewertung

Selbstbewertung, wenn der Hersteller harmonisierte Normen anwendet. Andernfalls ist eine Bewertung durch eine notifizierte Stelle notwendig.

!!

Wichtig – Klasse II

Anhang III

Beispielprodukte

Firewall, Intrusion‑Detection‑Systeme, manipulationssichere Mikroprozessoren

Konformitätsbewertung

Bewertung durch eine notifizierte Stelle oder, sofern verfügbar und anwendbar, Cybersicherheitszertifizierung gemäß Artikel 27 Absatz 9.

Kritisch

Anhang IV

Beispielprodukte

Smartcards, Smart‑Meter‑Gateways, Hardwaregeräte mit Sicherheitsboxen

Konformitätsbewertung

Die Bewertung durch eine notifizierte Stelle ist verpflichtend.

Was verlangt der CRA von Herstellern: Pflichten im Überblick


Sechs Pflichtbereiche bilden das Fundament der CRA‑Konformität.

01 Cybersicherheitsanforderungen an das Produkt (Anhang I)

Anhang I formuliert grundlegende Sicherheitseigenschaften für jedes Produkt mit digitalen Elementen: etwa eine sichere Standardkonfiguration, Schutz vor unbefugtem Zugriff und die Möglichkeit, Sicherheitsupdates einzuspielen. Der Anhang verlangt eine risikobasierte Einzelfallprüfung, welche Anforderungen für das konkrete Produkt zutreffen.

02 Technische Dokumentation & Nutzerinformationen

Hersteller dokumentieren für die Aufsichtsbehörden, wie das Produkt die CRA‑Anforderungen erfüllt. Für die Nutzer wird eine Information beigelegt, wie das Produkt sicher zu benutzen ist. Für beide Dokumente spielt die Zweckbestimmung eine wichtige Rolle: Sie definiert die erlaubte Nutzung des Produkts und damit die Verantwortungsverteilung zwischen Hersteller und Nutzer.

03 Konformitätsbewertung & CE‑Kennzeichnung

Je nach Produktklasse bewerten Hersteller die Konformität selbst oder ziehen eine notifizierte Stelle hinzu. Durch Ausfertigen der EU‑Konformitätserklärung und Anbringen der CE‑Kennzeichnung erklärt der Hersteller schließlich formal die Konformität seines Produkts mit den geltenden EU‑Anforderungen.

04 Schwachstellenmanagement & SBOM

Der CRA verlangt einen strukturierten Umgang mit Schwachstellen während des gesamten Produktlebenszyklus, ergänzt um eine Software Bill of Materials (SBOM) mit allen enthaltenen Softwarekomponenten. Ohne dieses Verzeichnis lässt sich im Ernstfall kaum klären, welche Produkte eine neue Schwachstelle betrifft.

05 Meldepflichten (24h/72h‑Fristen, ENISA‑Plattform)

Hersteller melden aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung und binnen 72 Stunden detailliert an die ENISA und nationale CSIRTs über eine zentrale Meldeplattform. Ein Abschlussbericht folgt spätestens 14 Tage nach Verfügbarkeit eines Sicherheitsupdates. Die Meldepflichten gelten ab 11.09.2026 und für alle Produkte mit digitalen Elementen auf dem EU‑Markt und nicht nur für die ab 11.12.2027 verkauften.

06 Supportzeitraum (mind. 5 Jahre)

Hersteller sichern die Behebung von Schwachstellen für mindestens fünf Jahre oder die erwartete Nutzungsdauer zu. Diese Zusage gilt, wie alle CRA‑Anforderungen, für das gesamte Produkt inklusive Drittkomponenten.

Die admeritia‑Methode: In 6 Schritten CRA‑konform werden


Herausforderungen

Wenn Hersteller den CRA umsetzen, stockt das Projekt häufig an einem von vier Punkten.

Der erste Stolperstein betrifft die fehlende Orientierung: Harmonisierte Normen, die eine Konformitätsvermutung begründen würden, liegen für die meisten Produktkategorien vor der Frist im Dezember 2027 nicht vollständig vor. Viele Hersteller wissen deshalb nicht, wie sie am besten anfangen, und ihnen läuft die Zeit davon.

Der zweite Stolperstein liegt im Interpretationsspielraum von Anhang I. Er beschreibt Ziele, keine konkreten Maßnahmen. Wer sie direkt übersetzt, wählt oft zu pauschale oder zu eng gefasste Lösungen.

Der dritte Stolperstein betrifft die Zusammenarbeit vieler Abteilungen mit jeweils eigener Fachsprache. Ohne gemeinsames Verständnis wächst ein Dokumentenberg, der als Argumentationslinie nicht geeignet ist.

Der vierte Stolperstein resultiert aus dem Umfang des Produktportfolios. Hersteller mit einem umfangreichen Produktportfolio haben meistens mehrere Geschäftsbereiche, die jeweils einen Teil des Portfolios verantworten. Oft fällt es den Bereichen schwer, sich auf ein Vorgehen zu einigen.Mehr zum Thema „Erfolgsfaktoren, um alle EU‑Cybersecurity‑Regularien einzuhalten“ und in unserem Whitepaper

Die 6 Schritte der Methode von admeritia

Die Methode von admeritia bündelt Projekterfahrung aus über 4.000 Kundenworkshops, akademische Forschung und Best Practices aus der ISA/IEC 62443‑3‑2 zu einem wiederholbaren Prozess.

  1. 01

    Business‑Ziel schärfen

    Hersteller legen Schadensszenarien, Risikomatrix und Schutzziele fest, bevor sie sich in technischen Details verlieren.

  2. 02

    Produkt als Cybersystem modellieren

    Funktionen, beteiligte Entitäten und Schnittstellen des Produkts werden auf einer Seite sichtbar.

  3. 03

    Auswirkungen bestimmen

    Für jede Funktion wird geklärt, was im schlimmsten Fall passiert, wenn ein Schutzziel verletzt wird.

  4. 04

    Risikoanalyse durchführen

    Für die kritischsten Funktionen werden Angriffsszenarien bewertet und daraus die schlankstmöglichen Security‑Anforderungen abgeleitet.

  5. 05

    Compliance‑Check durchführen

    Die Essential Requirements aus Anhang I werden systematisch geprüft und, wo zutreffend, umgesetzt und dokumentiert.

  6. 06

    CRA‑Compliance dokumentieren

    Konformitätserklärung, technische Dokumentation und Nutzerinformation entstehen aus den Ergebnissen der vorangegangenen Schritte.

Die vollständig Methodik und Hinweise zum Security Engineering Tool (SET) finden Sie in unserem kostenlosen Whitepaper – (Deutsch und Englisch)

In unserem Whitepaper:
  • Die 3 typischen Stolpersteine bei der CRA‑Umsetzung
  • Schritt‑für‑Schritt‑Methodik zur CRA‑Konformität
  • Wie unser Security Engineering Tool (SET) die Umsetzung beschleunigt
  • Erfahrungen aus der Praxis
Zweckbestimmung (Intended Purpose): unterschätzt, aber entscheidend Die Zweckbestimmung eines Produkts, auf Englisch Intended Purpose genannt, legt fest, wofür ein Hersteller sein Produkt vorsieht und unter welchen Bedingungen es zum Einsatz kommt. Der CRA verknüpft mit dieser Festlegung mehr als eine Formalie: Die Zweckbestimmung entscheidet, welche Essential Requirements aus Anhang I greifen. Sie setzt den Rahmen für die spätere Risikoanalyse, grenzt die Verantwortung zwischen Hersteller und Nutzer ab und ist somit haftungsrelevant. Die Zweckbestimmung bildet die erste Weichenstellung jedes CRA‑Projekts, lange bevor die technische Arbeit beginnt.

Ein Beispiel verdeutlicht das Prinzip. Eine industrielle Pumpensteuerung, ausschließlich für geschlossene Produktionsnetzwerke vorgesehen, unterliegt anderen Risikoannahmen als dieselbe Steuerung mit vorgesehenem Fernzugriff über das Internet.
Weiterlesen Weniger anzeigen

Die Zweckbestimmung eines Produkts, auf Englisch Intended Purpose genannt, legt fest, wofür ein Hersteller sein Produkt vorsieht und unter welchen Bedingungen es zum Einsatz kommt. Der CRA verknüpft mit dieser Festlegung mehr als eine Formalie: Die Zweckbestimmung entscheidet, welche Essential Requirements aus Anhang I greifen. Sie setzt den Rahmen für die spätere Risikoanalyse, grenzt die Verantwortung zwischen Hersteller und Nutzer ab und ist somit haftungsrelevant. Die Zweckbestimmung bildet somit die erste Weichenstellung jedes CRA‑Projekts, lange bevor die technische Arbeit beginnt.

Ein Beispiel verdeutlicht das Prinzip. Eine industrielle Pumpensteuerung, ausschließlich für geschlossene Produktionsnetzwerke vorgesehen, unterliegt anderen Risikoannahmen als dieselbe Steuerung mit vorgesehenem Fernzugriff über das Internet. Bindet ein Betreiber die Steuerung später an ein Wartungsportal an, obwohl der Hersteller das nicht vorsah, wird genau diese Lücke zwischen Zweckbestimmung und vorhersehbarer Verwendung zum Streitpunkt gegenüber der Marktüberwachungsbehörde.

Eine bewusste Formulierung der Zweckbestimmung stellt sicher, dass Hersteller, Nutzer und Marktüberwachungsbehörden mit denselben Annahmen arbeiten. Eine bewusst formulierte Zweckbestimmung kann auch ein Mittel sein, die sichere Nutzung eines Produktes zu gewährleisten, obwohl bestimmte Sicherheitsmaßnahmen technisch nicht umsetzbar sind.

Zwei Fehler treten in der Praxis besonders häufig auf. Zum einen formulieren Hersteller die Zweckbestimmung so allgemein, dass sie für die Risikoanalyse keinen brauchbaren Rahmen mehr liefert und sie hohe Haftungsrisiken eingehen. Fast jedes Szenario erscheint dann plausibel, die Analyse verliert sich in Eventualitäten und die Liste der notwendigen Cybersicherheitsmaßnahmen wird lang.

Zum anderen fassen Hersteller die Zweckbestimmung zu eng und blenden reale Nutzungsszenarien aus, etwa Fernwartung durch externe Dienstleister oder eine Integration in fremde IT‑Umgebungen – ein Streitpunkt mit Kunden und potenziell Marktüberwachungsbehörden.

Eine belastbare Zweckbestimmung entsteht selten am Schreibtisch einer einzelnen Abteilung. Entwicklung, Produktmanagement, Vertrieb und die Rechtsabteilung kennen jeweils unterschiedliche Facetten des realen Einsatzes und der rechtlichen Auswirkungen. Ihr gemeinsamer Blick führt zu einer tragfähigen Formulierung. Ohne diese saubere Grundlage fehlt jeder folgenden Analyse ihr Fundament.

Risikoanalyse im CRA: Der methodische Kern Der CRA schreibt eine Risikoanalyse vor, doch viele Hersteller unterschätzen ihre Bedeutung. Sie bildet das Herzstück der Verordnung, weil sie Herstellern erlaubt, ihre Sicherheitsmaßnahmen selbst zu wählen und gegenüber einer Konformitätsbewertungsstelle zu rechtfertigen. Der CRA verlangt ein risikobasiertes, nachvollziehbares Vorgehen: Wer seine Risiken kennt, entscheidet selbstbewusst, statt vorauseilend zu überdimensionieren.

Eine belastbare Risikoanalyse beginnt bei klar formulierten Schadensszenarien und einer Risikomatrix, die Eintrittswahrscheinlichkeit und Schadenshöhe zueinander in Beziehung setzt. Sie beschreibt Bedrohungsszenarien, zeigt, wie sich ein Angriff auswirken kann, und leitet daraus konkrete Sicherheitsanforderungen ab.
Weiterlesen Weniger anzeigen

Der CRA schreibt eine Risikoanalyse vor, doch viele Hersteller unterschätzen ihre Bedeutung. Sie bildet das Herzstück der Verordnung, weil sie Herstellern erlaubt, ihre Sicherheitsmaßnahmen selbst zu wählen und gegenüber einer Konformitätsbewertungsstelle zu rechtfertigen. Der CRA verlangt ein risikobasiertes, nachvollziehbares Vorgehen: Wer seine Risiken kennt, entscheidet selbstbewusst, statt vorauseilend zu überdimensionieren.

Eine belastbare Risikoanalyse beginnt bei klar formulierten Schadensszenarien und einer Risikomatrix, die Eintrittswahrscheinlichkeit und Schadenshöhe zueinander in Beziehung setzt. Sie beschreibt Bedrohungsszenarien, zeigt, wie sich ein Angriff auswirken kann, und leitet daraus konkrete Sicherheitsanforderungen ab. Jeder Schritt braucht eine Dokumentation, die auch Dritte nachvollziehen können. Ein Leitfaden, um jede Risikoanalyse schnell zu verbessern, zeigt, worauf es dabei im Detail ankommt.

Der Nutzen zeigt sich im Konformitätsbewertungsverfahren. Eine notifizierte Stelle prüft, ob die Entscheidungen für oder gegen bestimmte Sicherheitsmaßnahmen nachvollziehbar aus einer Risikoanalyse hervorgehen. Darin liegt der Unterschied zu einer reinen Checklisten‑Logik: Eine Risikoanalyse liefert eine Begründung für getroffene Entscheidungen. Hersteller, die diesen Zusammenhang früh verinnerlichen, sparen sich sowohl unnötig aufwendige Sicherheitsmaßnahmen als auch unbequeme Nachfragen zur technischen Dokumentation.

„Habt Mut, Euch Eurer eigenen Risikoanalyse zu bedienen!“

— Tagesspiegel Background, IT & Cybersicherheit
Normen und Standards im CRA: Was gilt wirklich? Welche Standards für den CRA tatsächlich zählen, gehört zu den meistgestellten Fragen. Harmonisierte Standards, die eine Konformitätsvermutung begründen, entstehen über einen mehrjährigen Abstimmungsprozess zwischen der EU‑Kommission und den Normungsorganisationen CEN, CENELEC und ETSI. Für die meisten CRA‑Produktkategorien liegen sie vor Dezember 2027 nicht vollständig vor.

Harmonisierte Standards zu nutzen, ist nicht verpflichtend. CRA‑Konformität ist auch ohne harmonisierte Standards möglich, und das Fehlen von harmonisierten Standards entbindet Hersteller nicht von ihrer Pflicht zur CRA‑Konformität. Das Erfüllen eines harmonisierten Standards allein ist ebenfalls nicht ausreichend – die Risikoanalyse bleibt zentral.
Weiterlesen Weniger anzeigen

Welche Standards für den CRA tatsächlich zählen, gehört zu den meistgestellten Fragen. Harmonisierte Standards, die eine Konformitätsvermutung begründen, entstehen über einen mehrjährigen Abstimmungsprozess zwischen der EU‑Kommission und den Normungsorganisationen CEN, CENELEC und ETSI. Für die meisten CRA‑Produktkategorien liegen sie vor Dezember 2027 nicht vollständig vor.

Harmonisierte Standards zu nutzen, ist nicht verpflichtend. CRA‑Konformität ist auch ohne harmonisierte Standards möglich, und das Fehlen von harmonisierten Standards entbindet Hersteller nicht von ihrer Pflicht zur CRA‑Konformität. Auf der anderen Seite ist das Erfüllen eines harmonisierten Standards allein nicht ausreichend für die CRA‑Konformität – die Risikoanalyse bleibt weiter zentral, denn: Die Konformitätsvermutung gilt nur, wenn der harmonisierte Standard alle relevanten Cybersecurity‑Risiken abdeckt, die mit Ihrem Produkt verbunden sind.

Trotzdem gibt es einige Standards, die Herstellern als Orientierung dienen können:

  • EN 18031 entstand als harmonisierte Normenreihe für die Funkanlagenrichtlinie (RED‑DA) und begründet dort seit August 2025 eine Konformitätsvermutung für Netzwerksicherheit, Schutz personenbezogener Daten und Schutz vor finanziellem Betrug. Sie ist kein harmonisierter Standard für den CRA. Die EU‑Kommission beschloss im Februar 2026, die RED‑DA mit zum Stichtag der vollständigen CRA‑Anwendung (11. Dezember 2027) aufzugeben, um eine Doppelregulierung zu vermeiden. EN 18031 liefert allerdings Vorarbeit für die aktuell laufende CRA‑Normungsarbeit.
  • IEC 62443, ursprünglich für industrielle Automatisierungs- und Steuerungssysteme entwickelt, liefert bereits heute erprobte Anforderungen an industrielle Komponenten, Systeme und Risikobetrachtungen. Die Teile -4‑1 und -4‑2 der Normenreihe werden momentan als europäische Normen adaptiert, damit sie als harmonisierte Standards verwendet werden können
  • EN ISO 40000 ist die Standardreihe zu CRA‑Horizontalstandards und befindet sich ebenfalls im Entwurfsstadium. Die Standards konkretisieren keine Anforderungen für spezifische Produkte, sondern produktübergreifende prozessuale Anforderungen – etwas für das Schwachstellenmanagement.
  • EN 50742 ist der harmonisierte Standard für die Security‑Aspekte der EU‑Maschinenverordnung (MVO) und momentan in der Entwurfsphase. Der Standard stellt zwei Ansätze zur Auswahl – einer davon basiert auf den Teilen -4‑1, -4‑2 und -3‑3 der IEC‑62443‑Standardreihe.

Bis harmonisierte CRA‑Normen vollständig vorliegen, bleibt eine transparent dokumentierte, an etablierten Standards orientierte Vorgehensweise der verlässlichste Weg zur Konformität.

CRA & Maschinenverordnung – Safety meets Security Safety und Security wachsen regulatorisch zusammen. Die EU‑Maschinenverordnung (EU) 2023/1230 löst ab dem 20. Januar 2027 die bisherige Maschinenrichtlinie 2006/42/EG ab und verankert erstmals Cybersicherheitsanforderungen in den grundlegenden Sicherheitsanforderungen für Maschinen. Ein manipulierter Sensor oder eine gekaperte Steuerung können einen sicherheitskritischen Vorgang auslösen. Die Grenze zwischen Safety und Security verschwimmt an dieser Stelle.

Für Hersteller von Maschinen mit digitalen Elementen und Safety‑Steuerungen bedeutet das eine doppelte Sorgfaltspflicht: Sie erfüllen die Essential Requirements des CRA und die Cybersicherheitsanforderungen der Maschinenverordnung.
Weiterlesen Weniger anzeigen

Safety und Security wachsen regulatorisch zusammen. Die EU‑Maschinenverordnung (EU) 2023/1230 löst ab dem 20. Januar 2027 die bisherige Maschinenrichtlinie 2006/42/EG ab und verankert erstmals Cybersicherheitsanforderungen in den grundlegenden Sicherheitsanforderungen für Maschinen. Ein manipulierter Sensor oder eine gekaperte Steuerung beispielsweise können einen sicherheitskritischen Vorgang auslösen. Die Grenze zwischen Safety und Security verschwimmt an dieser Stelle.

Für Hersteller von Maschinen mit digitalen Elementen und Safety‑Steuerungen bedeutet das eine doppelte Sorgfaltspflicht: Sie erfüllen die Essential Requirements des CRA und die Cybersicherheitsanforderungen der Maschinenverordnung. Beide Regelwerke greifen ineinander.

Zur Abgrenzung: NIS2 adressiert Betreiber kritischer und wichtiger Einrichtungen, DORA regelt die digitale Resilienz von Finanzunternehmen, KRITIS bezeichnet die national benannten Betreiber kritischer Infrastrukturen in Deutschland. Der CRA ergänzt diese Regelwerke auf der Produktebene, bevor ein Produkt überhaupt in Betrieb geht.
Trotzdem gibt es einige Standards, die Herstellern als Orientierung dienen können:

Mit einem definierten ersten Schritt starten


Ob ein Produkt überhaupt unter den CRA fällt, was Ihre wichtigsten Aufgaben sind oder welche Anforderung zum Showstopper wird: Je nachdem, wo Sie stehen, sieht der erste Schritt anders aus. Unsere Einstiegsformate setzen genau dort an, wo Sie sich gerade befinden – damit Sie die CRA‑Konformität selbst in die Hand nehmen können.

Sie suchen Klarheit, was der CRA für Ihre Produkte bedeutet

Roadmap to CRA‑Compliance Ihr Zeitaufwand: 6 Stunden für einen Teams‑Workshop Für Produktverantwortliche, die ihre Produkte bis Dezember 2027 CRA‑konform und am Markt halten müssen. Das Format liefert Übersicht, Entscheidungsgrundlage und Fahrplan.
1

Inhalt

  • CRA Anforderungen definiert
  • CRA Workstreams erklärt
    • Product‑Design
    • Schwachstellenmanagement
    • Einkaufsprozess
    • Dokumentation
  • Toolgestützte Systemmodellierung und Risikologik in SET
2

Vorgehensweise

  • Ihr Zeitaufwand: 6 Stunden Teams‑Workshop
  • Modellierung eines Produktes
  • Beantwortung spezifischer Fragen zum CRA und strategischen Vorgehensweise
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • „Roadmap_to_Compliance“ steht
  • Systemmodell eines Produktes
  • Klarheit über die Aufgaben der nächsten Monate
  • Grundlage für produktstrategische Entscheidungen hinsichtlich des CRA und Verkaufsfähigkeit der Produkte
CRA‑Betroffenheitsanalyse Ihr Zeitaufwand: 7 Stunden über vier Teams‑Workshops Für Produktverantwortliche, die wissen müssen, ob ihre Produkte unter den CRA fallen. Das Format liefert Feststellung, CRA‑Kategorie und erste Roadmap.
1

Inhalt

  • Erheben der Produktinformationen, technischer Aufbau, Einbauumgebung und Einsatzzweck eines Produkts gemäß CRA
  • Betroffenheitsanalyse nach CRA‑Vorgabe im Security‑Engineering‑Tool
  • Zuordnung der Produktgruppe zu der CRA‑Kategorie
  • CRA‑Roadmap für die Produktgruppe definiert
2

Vorgehensweise

  • Ihr Zeitaufwand: Vier Teams‑Workshops, insgesamt 7 Stunden
  • Modellierung der Produktgruppe
  • Prüfung gegen CRA‑Kriterien
  • Ableitung der CRA‑Roadmap
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • Belastbare Betroffenheitsaussage je Produktgruppe
  • Systemmodell und Funktionen eines Produktes sind dokumentiert
  • CRA‑Roadmap mit priorisiertem Handlungsbedarf
  • Übertragbar auf alle Einzelprodukte der Gruppe

Sie wollen den konkreten Handlungsbedarf für Ihre Produkte identifizieren

CRA‑Showstopper‑Analyse Ihr Zeitaufwand: 10 Stunden über drei Teams‑Workshops Für Produktverantwortliche, die wissen müssen, welche CRA‑Anforderungen zum Showstopper werden. Das Format liefert die Basis für eine wirtschaftlich tragfähige Produktstrategie.
1

Inhalt

  • Regulatorische Anforderungen des CRA
  • Erheben der Produktinformationen, technischer Aufbau, Einbauumgebung und Einsatzzweck eines Produkts gemäß CRA
  • Show‑Stopper identifiziert und Handlungsoptionen definiert
  • Projektmanagement
2

Vorgehensweise

  • Ihr Zeitaufwand: Drei Teams‑Workshops, insgesamt 10 Stunden
  • Modellierung der Produktgruppe im SET
  • Identifikation der Showstopper
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • CRA‑Anforderungen sind verstanden
  • Netzmodell und Funktionen sind dokumentiert
  • CRA‑Showstopper‑Analyse je Produkt durchgeführt
  • Entscheidungsgrundlage je Showstopper für Management erstellt
CRA‑Gap‑Analyse Ihr Zeitaufwand: 11 Stunden über sechs Teams‑Workshops Für Produktverantwortliche, die ihren konkreten Handlungsbedarf zur CRA‑Konformität kennen müssen. Das Format liefert Lücken, Maßnahmen und priorisierte Roadmap.
1

Inhalt

  • Regulatorische Anforderungen des CRA
  • Erheben der Produktinformationen, technischer Aufbau, Einbauumgebung und Einsatzzweck eines Produkts gemäß CRA
  • CRA‑Gap‑Analyse Produktdesign
  • CRA‑Gap‑Analyse der übergeordneten Prozesse
  • CRA‑Roadmap
2

Vorgehensweise

  • Ihr Zeitaufwand: Sechs Teams‑Workshops, insgesamt 11 Stunden
  • Modellierung der Produktgruppe in SET
  • Gap‑Analyse Produktdesign und Prozesse
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • Netzmodell und Funktionen dokumentiert
  • CRA‑Gap‑Analyse für Produktdesign inkl. Maßnahmen steht
  • CRA‑Gap‑Analyse für Schwachstellenmanagement, Einkauf & Dokumentation inkl. Maßnahmen steht
  • CRA‑Roadmap mit priorisierten Handlungsfeldern ist definiert

Sie wollen eine Methode, die der Konformitätsbewertung standhält

CRA‑High‑Level‑Risikoanalyse Ihr Zeitaufwand: 10 Stunden über drei Teams‑Workshops Für Produktverantwortliche, die ihren CRA‑Handlungsbedarf aus den Top‑5‑Risiken ihrer Produkte ableiten müssen. Das Format liefert die kritischsten Risikoszenarien und die passenden Security‑Anforderungen.
1

Inhalt

  • Regulatorische Anforderungen des CRA and die Risikologik
  • Netz- und Systemmodell erstellt Funktionen modelliert & Business Impact Analyse durchgeführt
  • Threat Model mit Top‑5‑Risikoszenarien in SET modelliert
  • Security‑Anforderungen für Top‑3‑kritischten Risiken abgeleitet
2

Vorgehensweise

  • Ihr Zeitaufwand: Drei Teams‑Workshops, insgesamt 10 Stunden
  • Modellierung in SET
  • Bedrohungsanalyse und Risikobewertung
  • Ableitung der Security‑Anforderungen
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • Netz- und Systemmodell dokumentiert
  • Business Impact Analyse steht
  • Top‑5‑Risikoszenarien priorisiert
  • Security‑Anforderungen für Top‑3‑Risiken sind definiert
  • Erklärbare Compliance für jede Security‑Entscheidung steht
  • Verkaufs- und Wettbewerbsfähigkeit gesichert
CRA‑Risikoanalyse Blueprint Ihr Zeitaufwand: 18 Stunden über fünf Teams‑Workshops Für Produktverantwortliche, die den Cybersecurity‑Handlungsbedarf für ihre Produktgruppen ermitteln müssen. Das Format liefert Risikoszenarien, passende Security‑Anforderungen und einen Blueprint für die weitere Bearbeitung in Eigenregie.
1

Inhalt

  • Regulatorische Anforderungen des CRA
  • CRA‑betroffenen Produkte identifiziert und geclustert
  • Netz- und Systemmodell, Funktionen und Business Impact Analyse für 3 Produktgruppen erstellt
  • Threat Model und Risikoszenarien in SET modelliert
  • Security‑Anforderungen inkl. Essential Requirements Annex I CRA abgeleitet
  • Blueprint‑Guided‑Workflow in SET eingerichtet
2

Vorgehensweise

  • Ihr Zeitaufwand: Fünf Teams‑Workshops, insgesamt 18 Stunden
  • Kickoff und Methodik‑Einführung
  • Identifikation und Clustering der CRA‑Produkte
  • Risikoanalyse für 3 Produktgruppen durch admeritia ausgearbeitet
  • Setup des Blueprint‑Guided‑Workflows in SET
  • Vor- und Nachbereitung durch admeritia
3

Ergebnis

  • CRA‑Produktgruppen identifiziert und dokumentiert
  • Netz- und Systemmodelle inkl. Business Impact Analyse für 3 Produktgruppen
  • Risikoszenarien und Security‑Anforderungen für 3 Produktgruppen abgeleitet
  • Blueprint‑Guided‑Workflow für weitere Produktgruppen in Eigenregie
  • Erklärbare Compliance für das gesamte Produktportfolio steht
  • Verkaufs- und Wettbewerbsfähigkeit gesichert

Sie sind unsicher, welches Format zu Ihrer Ausgangslage passt? Schreiben Sie uns, wir finden das gemeinsam heraus.

Fragen Sie Ihr Einstiegsformat an

Wer vertraut admeritia?

Ich habe Sarah und ihr Team schon in Aktion gesehen und kann bestätigen: Diese Prozesse wirken Wunder. Absolute Empfehlung.
Mitchell Impey, ehemals ICS Security Manager bei Norlys, bringt damit auf den Punkt, was viele Kunden von admeritia erleben.
manroland GOSS legt größten Wert darauf, dass unsere Produkte gegen Cyberbedrohungen geschützt sind. Die Anforderungen des CRA und der neuen MVO nehmen wir dabei sehr ernst. admeritia ist dabei als kompetenter und praxisnaher Partner jederzeit ansprechbar und hilft uns, diese Vorgaben verständlich und umsetzbar in unsere Prozesse und Produkte zu integrieren. Diese Zusammenarbeit gibt uns die Sicherheit, unseren Kunden zukunftsfähige und konforme Maschinen anzubieten.
Frank Weyhmüller, Vice President Technology bei manroland GOSS, beschreibt die gemeinsame Umsetzung des CRA und der MVO.

Seit 2004 begleitet admeritia Kunden bei der Cybersicherheit industrieller Produkte, Systeme und kritischer Infrastrukturen. Mehr als 760 Unternehmen vertrauen der Expertise des Teams, das an internationalen Standards wie ISO/IEC 27001 und IEC 62443 mitwirkt.

Firmenlogo Kunde 1 Firmenlogo Kunde 2 Firmenlogo Kunde 3 Firmenlogo Kunde 4 Firmenlogo Kunde 5 Firmenlogo Kunde 6