Wenn Ihr Unternehmen Hard- oder Software auf dem EU-Markt bereitstellt, die sich direkt oder indirekt mit einem Gerät oder einem Netz verbindet, sollten Sie sich jetzt mit dem Cyber Resilience Act befassen. Nicht erst in eineinhalb Jahren.

Die meisten Unternehmen haben ein einziges Datum im Kopf: den 11. Dezember 2027. Die erste durchsetzbare Pflicht gilt jedoch bereits ab dem 11. September 2026 - und sie betrifft auch Produkte, die heute schon auf dem Markt sind.

Dieser Artikel gibt einen Überblick über die gesamte Verordnung: was der CRA ist, wen er betrifft, welche Pflichten er bringt und in welcher Reihenfolge man sie angeht. Die Meldepflicht nach Artikel 14 behandeln wir ausführlich in einem eigenen Beitrag.

Was der CRA ist und warum es ihn gibt

Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Sie ist am 10. Dezember 2024 in Kraft getreten.

Die Verordnung benennt die Probleme, die sie adressiert, selbst: ein niedriges Cybersicherheitsniveau bei Produkten mit digitalen Elementen, erkennbar an weit verbreiteten Schwachstellen und an der unzureichenden und uneinheitlichen Bereitstellung von Sicherheitsupdates - und ein Informationsdefizit, das Nutzer daran hindert, sichere Produkte auszuwählen und sicher zu verwenden.

Ein formaler Punkt ist wichtiger, als er klingt. Der CRA ist eine Verordnung, keine Richtlinie. Er muss nicht in nationales Recht umgesetzt werden, wie es bei NIS2 der Fall war. Er gilt unmittelbar und wortgleich in allen Mitgliedstaaten. Sie warten also auf kein nationales Gesetz.

Für Hersteller in der Schweiz gilt der CRA nicht unmittelbar - die Schweiz ist weder EU- noch EWR-Mitglied. Sobald ein Schweizer Hersteller ein Produkt auf dem EU-Markt bereitstellt, greifen die Anforderungen jedoch vollständig. Maßgeblich ist nicht der Sitz des Herstellers, sondern die Bereitstellung auf dem Unionsmarkt. Die Verordnung ist zudem als EWR-relevant gekennzeichnet.

CRA versus NIS2: ein Satz, der genügt

Der CRA reguliert das Produkt. NIS2 reguliert die Organisation.

In Deutschland wurde NIS2 durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) umgesetzt, das am 6. Dezember 2025 in Kraft getreten ist und das BSI-Gesetz umfassend ändert. Betroffen sind nach Schätzungen rund 29.500 Einrichtungen, zuständige Aufsichts- und Meldebehörde ist das BSI.

In Österreich erfolgte die Umsetzung durch das Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026), das am 23. Dezember 2025 kundgemacht wurde und am 1. Oktober 2026 in Kraft tritt. Es löst das NISG 2018 ab und betrifft rund 5.000 Einrichtungen.

Beide Gesetze sagen Betreibern in regulierten Sektoren, wie sie die Risiken ihrer Netz- und Informationssysteme steuern müssen. Der CRA sagt Herstellern, welche Eigenschaften ein Produkt haben muss, das sie auf dem EU-Markt bereitstellen. Zwei verschiedene Regime mit unterschiedlichen Adressaten und unterschiedlichen Behörden.

Sie treffen sich in der Lieferkette. Eine nach NIS2 regulierte Einrichtung muss Lieferantenrisiken steuern - und zunehmend heißt das, genau jene Fragen zu stellen, die der CRA an Hersteller richtet. Selbst wenn Ihr Unternehmen nicht unter NIS2 fällt, kommt der Druck zur CRA-Konformität wahrscheinlich früher vom Kunden als von der Behörde.

Was ein „Produkt mit digitalen Elementen“ ist

Die Verordnung gilt für Produkte, die auf dem Markt bereitgestellt werden und deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz umfasst. Hardware und Software gleichermaßen.

In der Praxis sind das vernetzte Maschinen und Industrieanlagen, Steuerungssysteme, IoT-Geräte, Router und Netzkomponenten, mobile und Desktop-Anwendungen, Betriebssysteme, eingebettete Software - und Komponenten, die ein anderer Hersteller in sein eigenes Produkt einbaut.

Das Wort indirekt wiegt schwerer, als es aussieht. Wenn Ihre Komponente sich nicht selbst mit einem Netz verbindet, aber Teil einer Baugruppe ist, die es tut, fällt sie ebenfalls in den Anwendungsbereich.

Gilt der CRA für Cloud und SaaS?

In der Regel nicht - mit einer wesentlichen Ausnahme. Der CRA erfasst Lösungen zur Datenfernverarbeitung: Software, die vom Hersteller eines Produkts oder in seinem Auftrag entwickelt wurde und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte.

Ein Cloud-Dienst, über den Nutzer Ihr Gerät fernsteuern, fällt damit in den Anwendungsbereich. Eine eigenständige SaaS-Plattform, die für kein Produkt funktionsnotwendig ist, fällt nicht unter den CRA - andere EU-Vorschriften können auf sie jedoch anwendbar sein, etwa NIS2, sofern der Anbieter die sektoralen und Größenkriterien erfüllt. Eine Website, die keine Produktfunktion unterstützt, fällt ebenfalls nicht unter den CRA.

Rollen: Hersteller, Einführer, Händler

Die Pflichten unterscheiden sich nach Rolle, und die meisten treffen den Hersteller. Achten Sie auf zwei Konstellationen, in denen ein Einführer oder Händler zum Hersteller wird - mit allen Pflichten nach Artikel 13 und 14:

• Das Produkt wird unter eigenem Namen oder eigener Handelsmarke in Verkehr gebracht - typischerweise White-Label- und Eigenmarkenkonstellationen.
• Es wird eine wesentliche Veränderung an einem bereits auf dem Markt befindlichen Produkt vorgenommen.

Dasselbe gilt für jeden anderen Beteiligten - etwa einen Systemintegrator -, der ein Produkt wesentlich verändert und bereitstellt. Er wird damit selbst zum Hersteller im Sinne der Verordnung.

Was nicht unter den CRA fällt

Die Verordnung gilt nicht für Produkte, die bereits sektorspezifisches EU-Recht erfasst, und nicht für einige weitere Kategorien:

• Medizinprodukte nach den Verordnungen (EU) 2017/745 und 2017/746.
• Kraftfahrzeuge sowie deren Systeme und Bauteile nach der Verordnung (EU) 2019/2144 - also der Bereich, den Typgenehmigung und UN R155 abdecken.
• Luftfahrtprodukte, die nach der Verordnung (EU) 2018/1139 zertifiziert sind.
• Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder der Verteidigung entwickelt oder verändert wurden, sowie Produkte zur Verarbeitung von Verschlusssachen.
• Ersatzteile zur Reparatur, einschließlich Teilen für Altprodukte, die vor Geltungsbeginn der Verordnung in Verkehr gebracht wurden.
• Nichtkommerzielle freie und quelloffene Software. Entscheidend ist nicht, ob der Quellcode offen ist, sondern ob die Software im Rahmen einer Geschäftstätigkeit bereitgestellt wird. Software, die ihr Entwickler nicht monetarisiert, gilt nicht als Geschäftstätigkeit; die bloße Annahme von Spenden oder regelmäßige Releases ändern daran nichts.

Die sektoralen Ausnahmen sind enger, als sie zunächst wirken - Automotive ist das deutlichste Beispiel und für den deutschen und österreichischen Markt zugleich das heikelste. Ausgenommen ist, was die Verordnung (EU) 2019/2144 abdeckt, nicht automatisch alles, was ein Unternehmen an die Automobilindustrie liefert. Diagnosegeräte, Ladestationen, Produktions- und Prüfsysteme oder Telematikmodule außerhalb der Typgenehmigung können sehr wohl unter den CRA fallen. Das ist Produkt für Produkt zu beurteilen, nicht pauschal für das ganze Unternehmen.

Produktklassen und was daraus folgt

Der CRA teilt Produkte nach Risiko in vier Stufen ein. Die Einstufung bestimmt, ob Sie die Konformität selbst bewerten dürfen oder eine benannte Stelle einbinden müssen. Maßgeblich ist die Kernfunktionalität des Produkts, nicht die Frage, ob es beiläufig eine Sicherheitsfunktion als Nebenmerkmal enthält.

Die technischen Beschreibungen der einzelnen Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392. Wenn die Einstufung Ihres Produkts strittig ist, ist das das erste Dokument, das Sie öffnen sollten.

Welche Unternehmen es am härtesten trifft

Anders als NIS2, das auf Betreiber in definierten Sektoren zielt, trifft der CRA eine völlig andere Gruppe. Im deutschsprachigen Raum typischerweise:

• Automobilzulieferer, die vernetzte Komponenten außerhalb der Typgenehmigung liefern,
• Maschinen- und Anlagenbau sowie Hersteller von Industrieautomatisierung, Steuerungs- und Messtechnik,
• Hersteller von IoT- und Smart-Home-Geräten,
• Softwarehäuser mit On-Premise-Produkten und mobilen Anwendungen,
• Unternehmen, die fremde Produkte unter eigener Marke vertreiben.

Gemeinsam ist ihnen, dass die meisten bislang keine Berührung mit Cybersicherheitsregulierung hatten. Der Problemeigner ist nicht die IT-Abteilung und nicht der CISO - es sind Entwicklung, Produktmanagement und Qualitätssicherung.

Welche Pflichten der CRA bringt

1. Sicherheitsanforderungen an das Produkt selbst

Anhang I Teil I legt die grundlegenden Anforderungen fest, die ein Produkt beim Inverkehrbringen erfüllen muss. Dazu zählen insbesondere:

• das Produkt wird ohne bekannte ausnutzbare Schwachstellen ausgeliefert,
• eine sichere Standardkonfiguration und die Möglichkeit, es in einen sicheren Zustand zurückzusetzen,
• Schutz vor unbefugtem Zugriff einschließlich Authentifizierungs- und Identitätsmanagement,
• Schutz der Vertraulichkeit und Integrität gespeicherter, übertragener und verarbeiteter Daten,
• Verarbeitung nur der Daten, die für die Funktion des Produkts erforderlich sind,
• Minimierung der Angriffsfläche, Begrenzung der Auswirkungen von Vorfällen und Protokollierung sicherheitsrelevanter Ereignisse,
• die Möglichkeit, Schwachstellen durch Updates zu beheben, bei Verbraucherprodukten grundsätzlich automatisch.

Die Anforderungen sind ergebnisorientiert formuliert, nicht als technische Anleitung. Welche davon für Ihr Produkt relevant sind, ergibt sich aus der Risikobewertung - und wo eine Anforderung nicht einschlägig ist, müssen Sie das in der technischen Dokumentation begründen.

2. Cybersicherheitsrisikobewertung

Die Risikobewertung des Produkts ist der Kern der gesamten technischen Dokumentation. Sie ist kein einmaliges Dokument: Sie muss während des gesamten Unterstützungszeitraums fortgeschrieben werden und sowohl die bestimmungsgemäße als auch die vernünftigerweise vorhersehbare Verwendung berücksichtigen.

3. Sorgfaltspflicht bei Komponenten Dritter

Wenn Sie fremde Komponenten einschließlich quelloffener Software integrieren, müssen Sie dabei Sorgfalt walten lassen. Die Verordnung nennt Beispiele: prüfen, ob die Komponente bereits eine CE-Kennzeichnung trägt, ob sie regelmäßig Sicherheitsupdates erhält, ob sie in der europäischen Schwachstellendatenbank oder in anderen öffentlich zugänglichen Datenbanken mit einer Schwachstelle geführt wird - oder zusätzliche Sicherheitstests durchführen.

Finden Sie dabei eine Schwachstelle in einer Komponente, sollen Sie denjenigen informieren, der sie herstellt oder pflegt, die Schwachstelle beheben und den Fix nach Möglichkeit weitergeben.

4. SBOM

Hersteller müssen die im Produkt enthaltenen Komponenten identifizieren und dokumentieren und eine Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format erstellen, die zumindest die Abhängigkeiten der obersten Ebene abdeckt.

Gute Nachricht, falls Vertraulichkeit ein Thema ist: Sie müssen die SBOM Nutzern nicht regelmäßig offenlegen. Die Marktüberwachungsbehörde kann sie in bestimmten Fällen anfordern; im Rahmen einer unionsweiten Bewertung von Softwareabhängigkeiten werden die relevanten Informationen anonymisiert und aggregiert weitergegeben.

5. Unterstützungszeitraum und Sicherheitsupdates

Der Unterstützungszeitraum soll den Zeitraum abbilden, in dem das Produkt voraussichtlich genutzt wird, und darf nicht kürzer als fünf Jahre sein - die einzige Ausnahme ist ein Produkt mit kürzerer Lebensdauer. Wird ein Produkt üblicherweise länger genutzt, wie bei Netzkomponenten, Betriebssystemen oder industriellen Steuerungssystemen, ist der Unterstützungszeitraum entsprechend länger anzusetzen.

Sicherheitsupdates müssen kostenlos und, soweit technisch möglich, getrennt von Funktionsupdates bereitgestellt werden. Nutzer sind auch darüber zu informieren, wann der Unterstützungszeitraum endet.

Der Bestimmung des Unterstützungszeitraums widmen sich die Leitlinien der Europäischen Kommission vom Juli 2026 gesondert. Wer langlebige Produkte herstellt, sollte diese Passage genau lesen - fünf Jahre sind eine Untergrenze, kein Richtwert.

6. Schwachstellenbehandlung und koordinierte Offenlegung

Während des gesamten Unterstützungszeitraums muss der Hersteller Schwachstellen behandeln: die Sicherheit des Produkts wirksam und regelmäßig testen und überprüfen, Schwachstellen unverzüglich durch Updates beheben und Informationen über behobene Schwachstellen einschließlich Beschreibung und Handlungshinweisen für Nutzer veröffentlichen.

Dazu kommen zwei organisatorische Pflichten, die die meisten Hersteller heute nicht erfüllen: eine Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD) und eine zentrale Anlaufstelle, über die Ihnen jeder eine Schwachstelle melden kann. Diese Anlaufstelle darf sich nicht ausschließlich auf automatisierte Werkzeuge stützen.

7. Meldepflicht

Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, die die Sicherheit ihres Produkts betreffen. Gemeldet wird einmal, über die von der ENISA betriebene zentrale Meldeplattform, an das als Koordinator benannte CSIRT am Ort der Hauptniederlassung und gleichzeitig an die ENISA. Die Fristen beginnen in beiden Fällen unterschiedlich:

• Aktiv ausgenutzte Schwachstelle: Frühwarnung binnen 24 Stunden ab Kenntniserlangung, Meldung binnen 72 Stunden und Abschlussbericht spätestens 14 Tage, nachdem eine Abhilfemaßnahme verfügbar ist.
• Schwerwiegender Sicherheitsvorfall: Frühwarnung binnen 24 Stunden, Vorfallsmeldung binnen 72 Stunden und Abschlussbericht binnen eines Monats nach dieser Meldung.

Das ist die einzige Pflicht, die bereits jetzt greift, und wir behandeln sie ausführlich in einem eigenen Beitrag.

8. Konformitätsbewertung, CE-Kennzeichnung und Dokumentation

Die Konformität wird durch eine Konformitätsbewertung, eine EU-Konformitätserklärung und die CE-Kennzeichnung nachgewiesen. Ohne sie darf ein Produkt auf dem EU-Markt nicht bereitgestellt werden. Technische Dokumentation und Konformitätserklärung sind den Marktüberwachungsbehörden mindestens 10 Jahre nach dem Inverkehrbringen oder für die Dauer des Unterstützungszeitraums bereitzuhalten - je nachdem, welcher Zeitraum länger ist.

Eine wesentliche Veränderung bedeutet, dass die Konformität erneut zu prüfen und gegebenenfalls eine neue Konformitätsbewertung durchzuführen ist. Ein Sicherheitsupdate, das den Verwendungszweck des Produkts nicht ändert, ist keine wesentliche Veränderung.

Wie reale Produkte heute aussehen

Die Anforderungen aus Anhang I klingen auf dem Papier abstrakt. In der Praxis beschreiben sie exakt jene Fehler, die wir bei Produkttests seit Jahren finden.

Bei Citadelo führen wir seit Langem Penetrationstests an IoT-Geräten durch, und nahezu jedes getestete Gerät enthält mindestens eine als high oder critical eingestufte Schwachstelle. Am häufigsten wiederholen sich dieselben fünf Probleme:

Der Unterschied zu früher: Ab Dezember 2027 sind solche Befunde keine technischen Altlasten mehr. Sie bedeuten, dass das Produkt die grundlegenden Anforderungen der Verordnung nicht erfüllt. Und wenn jemand einen davon ausnutzt, entsteht daraus ab September 2026 ein meldepflichtiges Ereignis mit einer 24-Stunden-Frist.

Die geltenden Fristen

Parallel entsteht auf Grundlage des Normungsauftrags M/606, den CEN, CENELEC und ETSI angenommen haben, ein Satz harmonisierter Normen. Ihre vollständige Anwendung begründet die Konformitätsvermutung - bei Produkten der Klasse I ist das der Unterschied zwischen Selbstbewertung und der Pflicht, eine benannte Stelle einzubinden.

Sanktionen - und was wirklich weh tut

Die Verordnung sieht drei Bußgeldstufen vor:

• bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die grundlegenden Anforderungen des Anhangs I sowie gegen die Pflichten nach Artikel 13 und 14,
• bis zu 10 Millionen Euro oder 2 % des Umsatzes bei Verstößen gegen sonstige Pflichten,
• bis zu 5 Millionen Euro oder 1 % des Umsatzes für unrichtige oder irreführende Angaben gegenüber benannten Stellen und Marktüberwachungsbehörden.

Für die meisten Hersteller wiegt allerdings eine andere Folge schwerer. Die Marktüberwachungsbehörde kann Abhilfemaßnahmen anordnen, die Bereitstellung einschränken oder das Produkt vom Markt nehmen. Für ein exportierendes Unternehmen ist das kein bilanzielles Risiko, sondern ein Vertriebsstopp.

Was zu tun ist - in dieser Reihenfolge

1. Inventarisieren Sie Ihre Produkte. Welche Produkte stellen Sie auf dem EU-Markt bereit, welche verbinden sich direkt oder indirekt, und welche Rolle nehmen Sie bei jedem einzelnen ein? Denken Sie an Produkte unter eigener Marke und an solche, die Sie nicht mehr aktiv entwickeln, aber weiterhin verkaufen.
2. Stufen Sie die Produkte ein. Standard, wichtig Klasse I oder II, kritisch. Diese Entscheidung bestimmt, ob Selbstbewertung genügt oder eine benannte Stelle erforderlich ist - und damit auch, wie viel Zeit und Budget Sie einplanen müssen.
3. Erstellen Sie die SBOM. Ohne Überblick über die Komponenten erfüllen Sie weder die Sorgfaltspflicht noch die 24-Stunden-Frist für Meldungen. Der praktikabelste Einstieg ist die Erzeugung der SBOM direkt in der Build-Pipeline.
4. Erstellen Sie Risikobewertung und technische Dokumentation. Dokumentieren Sie zu jeder Anforderung aus Anhang I, wie Sie sie erfüllen - oder warum sie auf Ihr Produkt nicht anwendbar ist.
5. Etablieren Sie einen Schwachstellenprozess. CVD-Richtlinie, zentrale Anlaufstelle, Überwachung von Schwachstellen in Komponenten und ein Plan für die Bereitstellung von Fixes über den gesamten Unterstützungszeitraum.
6. Lassen Sie es unabhängig prüfen. Der CRA schreibt keinen Penetrationstest vor. Anhang I verlangt jedoch, dass der Hersteller die Sicherheit des Produkts wirksam und regelmäßig testet und überprüft, und die Sorgfaltspflicht bei Komponenten sieht zusätzliche Sicherheitstests ausdrücklich vor. Eine unabhängige Prüfung ist der direkteste Weg, die Erfüllung nachzuweisen - nicht weil das Gesetz sie vorschreibt, sondern weil eine Selbstbewertung ohne technische Verifikation nur eine Behauptung ist.
7. Üben Sie den Ernstfall. Eine einzige Tabletop-Übung zum Szenario „eine Schwachstelle in unserem Produkt wird aktiv ausgenutzt“ sagt mehr über die Reife aus als ein Dokumentenaudit. Kann das Produktteam binnen 24 Stunden entscheiden, ob ein meldepflichtiges Ereignis vorliegt - und weiß jemand, wer diese Entscheidung am Freitagabend trifft?

Häufige Fragen

Schreibt der CRA Penetrationstests vor?

Nicht ausdrücklich. Anhang I verlangt, dass der Hersteller die Sicherheit des Produkts wirksam und regelmäßig testet und überprüft; die Form der Prüfung ist nicht vorgegeben. Für die meisten Produkte ist eine unabhängige Prüfung der praktikabelste Weg, diese Anforderung zu erfüllen und nachzuweisen - eine gesetzliche Pflicht ist sie als solche jedoch nicht.

Wir sind nach ISO 27001 zertifiziert. Reicht das?

Nein. ISO 27001 bewertet ein Informationssicherheits-Managementsystem in der Organisation. Der CRA bewertet die Eigenschaften eines Produkts, das Sie auf dem Markt bereitstellen. Ein etabliertes Managementsystem erleichtert die Arbeit, ersetzt aber weder die Risikobewertung des Produkts noch SBOM, technische Dokumentation oder Konformitätsbewertung.

Wir sind Komponentenlieferant. Betrifft uns der CRA?

Wenn Sie die Komponente im Rahmen einer Geschäftstätigkeit auf dem Markt bereitstellen: ja - dann sind Sie deren Hersteller. Zusätzlich trifft den Hersteller des Endprodukts eine Sorgfaltspflicht gegenüber Ihrer Komponente, sodass die Fragen auch aus dieser Richtung kommen werden.

Wir entwickeln ein Produkt nicht mehr weiter, es ist aber noch im Verkauf. Was nun?

Die Meldepflicht ab dem 11. September 2026 gilt auch für Produkte, die bereits auf dem EU-Markt sind. Für Produkte, die nach dem 11. Dezember 2027 weiter verkauft werden, kommt die vollständige Konformität hinzu. Das ist typischerweise der Punkt, an dem zu entscheiden ist, ob das Produkt in die Konformität überführt oder der Vertrieb in der EU eingestellt wird.

Gilt der CRA für unser Cloud-Backend?

Wenn das Produkt ohne dieses Backend eine seiner Funktionen nicht erfüllen kann und Sie oder jemand in Ihrem Auftrag es entwickelt haben, handelt es sich um eine Lösung zur Datenfernverarbeitung und fällt in den Anwendungsbereich. Ist es ein eigenständiger, vom Produkt unabhängiger Dienst, gilt der CRA nicht.

Wir sind ein Schweizer Unternehmen. Gilt der CRA für uns?

Nicht unmittelbar - die Schweiz gehört weder zur EU noch zum EWR. Sobald Sie Produkte auf dem EU-Markt bereitstellen, gelten die Anforderungen jedoch in vollem Umfang. Der CRA knüpft an das Produkt und dessen Bereitstellung auf dem Unionsmarkt an, nicht an den Sitz des Herstellers. Zu prüfen ist zusätzlich, ob ein bevollmächtigter Vertreter in der Union zu benennen ist.

Wo Sie anfangen sollten

Der Unterschied zwischen den beiden Fristen ist einfach: Dezember 2027 geht um die Nachweisfähigkeit, September 2026 um die Reaktionsfähigkeit. Unternehmen, die mit der Vorbereitung auf die Meldepflicht beginnen, bauen dabei Produktinventar, SBOM und Schwachstellenprozess auf - also den größten Teil dessen, was sie ein Jahr später für die Konformitätsbewertung brauchen.

Wenn Sie unabhängig prüfen lassen wollen, ob Ihr Produkt den Anforderungen aus Anhang I standhält: Bei Citadelo testen wir

• Firmware und Hardwareschnittstellen einschließlich Debug-Ports,
• mobile, Web- und API-Schnittstellen des Produkts,
• Cloud-Backends und Lösungen zur Datenfernverarbeitung,
• Authentifizierungs- und Zugriffskontrollmechanismen,
• Update-Mechanismen und Signaturprüfung,
• Schwachstellen in Komponenten und Abhängigkeiten Dritter.

Es geht nicht darum, ein Dokument zu haben, das bescheinigt, dass das Produkt sicher ist. Es geht darum, seine Sicherheit technisch verifizieren zu können.

Rechtlicher Hinweis: Der Beitrag ist ein informativer Überblick, keine Rechtsberatung.

Sind Sie auf die Anforderungen des CRA vorbereitet?

Der Cyber Resilience Act betrifft nicht nur neue Produkte. In bestimmten Fällen gelten die Anforderungen auch für Produkte, die sich bereits auf dem Markt befinden. Prüfen Sie, ob Ihr Produkt auf die neuen Anforderungen vorbereitet ist.