Der Teil I des Anhang I im Cyber Resilience Act ist das technische Herzstück der Verordnung: die Liste der Produkteigenschaften, die ein Produkt mit digitalen Elementen (PwDE) erfüllen muss, bevor es auf dem EU-Markt bereitgestellt werden darf. Auf den Punkt gebracht: Produkte müssen so konzipiert, entwickelt und hergestellt sein, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten. Im Anhang I Teil I sind dafür 13 konkrete Anforderungen definiert, was „angemessen” heißt. Was diese für die Praxis und das jeweilige Produkt bedeuten, soll dieser Artikel erklären.
Manuel Sandler
Der Gesetzestext des CRA ist bewusst technologieneutral und abstrakt gehalten. Schließlich muss er von der Smartwatch bis zur industriellen Steuerungsanlage alles abdecken.
Ohne Interpretation und Kontextualisierung bleibt daher offen, was eine einzelne Anforderung aus dem CRA-Dokument für ein konkretes Produkt bedeutet und welche Maßnahmen sie möglicherweise verlangt.
Gleichzeitig gilt ins Auge zu fassen, was Hersteller vielleicht vielfach längst umgesetzt haben, ohne es dabei dediziert als CRA-relevant zu bezeichnen.
Im Nachfolgenden soll versucht werden, alle 13 CRA-Cybersicherheitsanforderungen (in Bezug auf die Eigenschaften von Produkten mit digitalen Elementen) in handhabbare, produktbezogene Aussagen zu übersetzen. Dabei ziehen wir auch die entstehende EN-40000-Reihe als kommendes Konkretisierungswerkzeug heran (bereits im vorherigen Artikel zur CRA-Risikobewertung vorgestellt). Der CRA-Gesetzestext benennt die Anforderungen nur abstrakt; die EN-40000-Reihe übersetzt sie in konkrete technische Vorgaben. Damit man beides zusammenbringt, enthalten die Teile der 40000er-Reihe eine Zuordnungstabelle im Anhang — in der DIN EN 40000-1-3:2026-02 etwa findet sie sich in Anhang ZA.
Zugleich soll die Brücke zwischen Regulierung und Praxis geschlagen werden: eine ehrliche Bestandsaufnahme, was die meisten Hersteller bereits haben und wo die tatsächlichen Lücken liegen.
Das Grundprinzip des CRA: „konzipiert, entwickelt und hergestellt“ gemäß den Anforderungen der Cybersicherheit
Vor den 13 Anforderungen steht das übergeordnete Prinzip aus Anhang I Teil I Nr. 1: PwDE werden so konzipiert, entwickelt und hergestellt, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten.
Die drei Verben sind in keinem Fall synonym. Sie beschreiben drei unterscheidbare Phasen des Produktentstehungsprozesses, in denen Cybersicherheit jeweils aktiv zu berücksichtigen ist. Wir reden letztendlich über den Produktlebenszyklus:
- Konzipiert (designed): In der Konzeptionsphase fallen die Architekturentscheidungen, die die gesamten späteren Cybersicherheitsnotwendigkeiten definieren. Hier setzt auch die Bedrohungsmodellierung (Threat Modelling) im Rahmen der Risikobewertung an, die festlegt, welche Komponenten und Schnittstellen überhaupt schützenswert sind und gegen welche Bedrohungen. Auf dieser Grundlage werden die konkreten Architekturfragen beantwortet: Welche Schnittstellen gibt es? Welche Hardware-Basis ist vorgesehen? Werden Sicherheitsfunktionen wie Secure Boot oder kryptografische Beschleunigung benötigt — und ist die Hardware darauf ausgelegt? Diese Entscheidungen lassen sich nachträglich nur mit erheblichem Aufwand oder gar nicht korrigieren.
- Entwickelt (developed): Im Entwicklungsprozess werden die konzeptuellen Entscheidungen implementiert. Dazu gehören Secure Coding Practices, Code Reviews unter Security-Gesichtspunkten, statische und dynamische Analysen sowie ein angemessenes Management von kryptografischen Schlüsseln und Zertifikaten. Auch die für den Nutzer bestimmte technische Dokumentation entsteht hier — Sicherheitshinweise, Konfigurationsanleitungen und Angaben zum sicheren Betrieb sind für viele Hersteller neue Pflichtinhalte und sollten deshalb bereits in der Entwicklung mitgedacht werden. Cybersicherheit gehört hier tief in den Prozess verzahnt, nicht als abschließende Prüfung.
- Hergestellt (produced): In der Herstellungsphase geht es um sichere Produktion und Lieferkette: Sind die verwendeten Komponenten frei von bekannten Schwachstellen? Ist die Herstellung selbst — vom Einspielen der Software bis zur Endkontrolle — gegen Manipulation abgesichert? Sind die Ausgangskonfigurationen der ausgelieferten Produkte tatsächlich sicher? Und bestehen in der Produktion ausreichende Schutzmaßnahmen gegen unbefugte Eingriffe? Vieles davon deckt sich mit Maßnahmen, die Hersteller aus einem bestehenden Informationssicherheits-Managementsystem (ISMS, etwa nach ISO 27001) bereits kennen und hier wiederverwenden können. Dieser Aspekt wird in der Security-Diskussion oft übersehen, ist aber regulatorisch explizit adressiert.
Den Startpunkt für alle drei Phasen bildet das CRA-Risiko-Assessment (aus dem vorigen Artikel unserer CRA-Serie) — und zwar samt einer klaren Produktdefinition (Item Definition): Erst wenn feststeht, was genau zum Produkt gehört, welche Komponenten und Schnittstellen es umfasst und wo seine Grenzen liegen, lässt sich bestimmen, welche Assets zu schützen sind. Auf dieser Grundlage gibt das Risikoassessment vor, welche Anforderung in welcher Phase konkret umzusetzen ist.
Wer diesen Startpunkt überspringt und direkt bei den 13 Anforderungen beginnt, riskiert Maßnahmen, die am tatsächlichen Risikoprofil vorbeigehen. Oder, betriebswirtschaftlicher ausgedrückt: es entstehen vermeidbare Kosten.
Der detaillierte Blick auf die Liste der CRA-Cybersicherheitsanforderungen: Warum sieht diese Liste so aus?
Bevor wir die 13 Anforderungen des CRA-Anhang-I einzeln durchgehen, lohnen sich drei Vorbemerkungen, die das Verständnis aller folgenden Punkte erleichtern: Sie zeigen, wie Teil I mit den Herstellerprozessen aus Teil II zusammenhängt, dass nicht jede Anforderung für jedes Produkt gilt, und mit welchem Werkzeug sich die Umsetzung künftig strukturieren lässt.
Wer diese drei Punkte verstanden hat, liest die 13 Anforderungen nicht mehr als starre Checkliste, sondern als das, was sie sind — ein risikobasiertes, miteinander verzahntes System.
Also:
- Teil I und Teil II in Anhang I des CRA greifen ineinander. Die 13 Anforderungen aus Teil I beschreiben, wie das Produkt beschaffen sein muss — beim Verkauf und über den gesamten Unterstützungszeitraum. Teil II (mehr dazu auch im vierten Artikel dieser Serie) beschreibt die laufenden Prozesse, mit denen der Hersteller diesen Zustand über den gesamten Produktlebenszyklus hinweg hält. Beide hängen zusammen, und die BSI TR-03183 benennt die Verzahnung am deutlichsten an Anforderung (a): kein Produkt mit bekannten, ausnutzbaren Schwachstellen ausliefern. Das lässt sich nur einhalten, wenn man überhaupt weiß, was im Produkt steckt und wo Schwachstellen bekannt werden. Dafür braucht es ein funktionierendes Schwachstellen-Management. Konkret: Wer keine Software-Stückliste (SBOM, die Liste aller im Produkt enthaltenen Komponenten) führt und diese nicht laufend gegen Schwachstellen-Datenbanken (z. B. den CVE-Katalog öffentlich bekannter Schwachstellen) abgleicht, kann Anforderung (a) faktisch nicht erfüllen — auch wenn er es formal behauptet. Diese Kopplung von Produkteigenschaft und Herstellerprozess ist eine der zentralen Ideen des CRA.
- Nicht jede Anforderung gilt für jedes Produkt. Die 13 Anforderungen sind „soweit zutreffend” umzusetzen. Was zutrifft, ergibt sich zum einen aus dem Produktumfang selbst — der Produktdefinition (Item Definition): Manche Anforderungen sind schlicht nicht anwendbar, wenn ein Produkt bestimmte Funktionen oder Daten gar nicht hat. Zum anderen bestimmt die Risikobewertung, mit welcher Tiefe die anwendbaren Anforderungen umzusetzen sind (s. Anhang I Teil I Nr. 2). Fällt eine Anforderung für ein Produkt weg, muss der Hersteller das in der technischen Dokumentation begründen (s. Art. 13 Abs. 4). Beispiel: Die Anforderung (m) — sichere Datenlöschung durch den Nutzer — kann bei einem Embedded-System ohne Nutzerdaten schlicht nicht anwendbar sein. Wichtig ist nur: Das muss explizit begründet, nicht stillschweigend übergangen werden. Marktüberwachungsbehörden erwarten hier klare Aussagen.
- Die EN 40000-Reihe als kommende Umsetzungshilfe. Der Gesetzestext sagt, was ein Produkt leisten muss, aber nicht wie. Genau diese Lücke schließt die (bereits im letzten Artikel erwähnte) entstehende EN-40000-Normenfamilie. Besonders relevant wird die entstehende EN 40000-1-4: ein konkreter Katalog von Sicherheitsanforderungen, direkt auf die CRA-Anforderungen gemappt. Wer ihn auf sein Produkt anwendet, hat ein strukturiertes Werkzeug, um für jede Anforderung die Anwendbarkeit zu begründen — und erfüllt damit gleich die Dokumentationspflicht aus Art. 13 Abs. 4. Entscheidend ist dabei, den Katalog nie blind abzuarbeiten: Er entfaltet seinen Wert erst in Verbindung mit den Ergebnissen der Risikobewertung, die vorgibt, welche Anforderungen für das konkrete Produkt anwendbar sind und mit welcher Tiefe. Noch sind die Normen nicht im EU-Amtsblatt referenziert und begründen daher keine Konformitätsvermutung; als Arbeitsgrundlage taugen sie aber schon heute und werden voraussichtlich die erste verlässliche Referenz für die Konformitätsbewertung.
Die 13 Cybersicherheits-Anforderungen des Cyber Resilience Act im Detail
Jetzt zu den Anforderungen selbst. Im Nachfolgenden sollen sie einzeln vorgestellt werden — von (a) bis (m) —, jeweils nach demselben Muster:
- Was verlangt die Anforderung?
- Was heißt das konkret in der Praxis?
- Und was haben viele Hersteller davon oft längst umgesetzt, ohne es als CRA-Thema zu kennen?
Man muss nicht alle dreizehn auswendig können; entscheidend ist, das Prinzip hinter jeder zu erfassen. Wer parallel sein eigenes Produkt mitdenkt, hat am Ende dieses Abschnitts bereits eine erste, grobe Standortbestimmung.
(a) Keine bekannten ausnutzbaren Schwachstellen bei Markteinführung
Das Produkt muss beim Inverkehrbringen frei von Schwachstellen sein, für die bekannte Exploits existieren. Selbstverständlich klingt das nur, bis man die Implikationen durchdenkt.
In der Praxis stützt sich die Erfüllung von Anforderung (a) auf zwei sich ergänzende Stränge. Der erste ist der risikobasierte Weg:
- Die Risikobewertung identifiziert die relevanten Schwachstellen, daraus wird ein Maßnahmenkonzept abgeleitet und umgesetzt — und vor dem Release wird verifiziert und validiert, dass alle vorgesehenen Sicherheitsmaßnahmen tatsächlich korrekt implementiert und aktiv sind.
- Der zweite Strang läuft parallel dazu: ein systematischer Abgleich aller enthaltenen Komponenten — von zugekauften Bausteinen über Open-Source-Bibliotheken bis zu selbst entwickelten Teilen — gegen Datenbanken bekannter Schwachstellen. Technische Grundlage dafür ist die Software Bill of Materials (kurz SBOM), die alle Komponenten und Versionen erfasst; ohne sie ist dieser Abgleich nicht möglich.
Relevante Quellen für die CVE-Prüfung sind die National Vulnerability Database (NVD), die europäische Schwachstellendatenbank (EUVD, eingerichtet nach Art. 12 Abs. 2 NIS2-Richtlinie) und herstellerspezifische Security Advisories der Komponenten-Hersteller.
Produkte, die bekannte CVEs mit verfügbaren Patches in ausgelieferten Komponenten enthalten, verstoßen gegen Anforderung (a) — unabhängig davon, ob die Schwachstelle im spezifischen Produktkontext ausnutzbar ist.
Status Quo: (a) Keine bekannten ausnutzbaren Schwachstellen bei Markteinführung
Was in der Praxis oft bereits gegeben ist
Viele Unternehmen haben bereits erste Sicherheitsmaßnahmen umgesetzt — meist nach bestem Wissen, seltener nach einem durchgängig methodischen Ansatz. Und es existieren in aller Regel etablierte Abläufe für das Produkttesting, in die sich das Testen der Sicherheitsmaßnahmen gut integrieren lässt, statt einen völlig neuen Prozess aufzubauen.
Was zur CRA-Compliance noch fehlt
Eine saubere Definition der Sicherheitsmaßnahmen und der Nachweis ihrer korrekten Umsetzung — konkret der formale Bezug auf Schwachstellen-Datenbanken, die SBOM-Grundlage und die Dokumentation, dass der Abgleich stattgefunden hat und zu welchem Ergebnis.
(b) Secure by Default
Die Werkseinstellung muss sicher sein, ohne dass der Nutzer aktiv Sicherheitsmaßnahmen aktivieren oder konfigurieren muss. Das klassische Beispiel ist das Gerät, das beim ersten Start zur Vergabe eines individuellen Passworts zwingt, statt mit einem für alle Geräte identischen Standard-Passwort ausgeliefert zu werden. Dies ist eine direkte Absage an das Modell „maximale Funktionalität by default, Sicherheit optional”.
Konkret: keine unnötig geöffneten Ports oder aktivierten Dienste jenseits der Kernfunktion; keine deaktivierten Sicherheitsfunktionen in der Auslieferungskonfiguration. Zudem muss sich das Produkt in den sicheren Ausgangszustand zurücksetzen lassen — eine vollständige Werksrücksetzung, die alle nutzerspezifischen Daten und Konfigurationen entfernt.
Ein oft übersehener Aspekt betrifft Produkte, die in mehreren Konfigurationsvarianten ausgeliefert werden — etwa für verschiedene Zielmärkte, Regionen oder Anwendungsfälle. Hier gilt die Anforderung für jede einzelne Variante: Welche Konfiguration auch immer als Standard eingestellt ist, sie muss sicher sein. Es genügt nicht, dass eine der möglichen Konfigurationen die Anforderung erfüllt, während eine andere mit unsicheren Voreinstellungen ausgeliefert wird.
Eine Ausnahme sieht der CRA für maßgeschneiderte Produkte vor: Vereinbaren Hersteller und gewerblicher Nutzer ausdrücklich andere Bedingungen, kann von der sicheren Standardkonfiguration abgewichen werden (s. Anhang I Teil I lit. b). Dies wäre relevant für industrielle Fälle, in denen die Standardkonfiguration eines allgemeinen Produkts nicht zur spezifischen OT-Umgebung passt.
Status Quo: (b) Secure by Default
Was in der Praxis oft bereits gegeben ist
Ersteinrichtungsassistenten, die beim ersten Start ein Passwort verlangen, oder Passwortpflichten bei der Erstkonfiguration.
Was zur CRA-Compliance noch fehlt
Die systematische Prüfung, ob alle Dienste und Schnittstellen tatsächlich auf das Notwendige reduziert sind, und die Dokumentation, was zur Werkseinstellung gehört.
(c) Updatefähigkeit und automatische Sicherheitsupdates
Schwachstellen müssen durch Sicherheitsupdates behebbar sein. Dies ist die technische Voraussetzung dafür, dass Anforderung (a) nicht nur bei Markteinführung, sondern über den gesamten Unterstützungszeitraum erfüllbar bleibt.
Der CRA präzisiert zwei Punkte:
- Automatische Sicherheitsupdates sollen als Standard aktiviert sein — mit einem klaren, einfach bedienbaren Opt-out (also der Möglichkeit für den Nutzer, die automatische Installation bewusst abzuschalten) und der Option, Updates vorübergehend aufzuschieben; zudem sollen Nutzer über verfügbare Updates informiert werden.
- Sicherheitsupdates sollen, soweit technisch machbar, getrennt von Funktionsupdates bereitgestellt werden (s. Anhang I, Teil II, 2) — niemand soll neue Funktionen installieren müssen, nur um eine Schwachstelle zu schließen.
Für den industriellen und B2B-Bereich ist das besonders relevant: Automatische Updates sind in produktionskritischen Umgebungen oft deaktiviert, weil jede Softwareänderung validiert und freigegeben werden muss. Der CRA adressiert das — automatische Updates gelten nicht für Produkte, bei denen Nutzer dies vernünftigerweise nicht erwarten, insbesondere in professionellen IKT-Netzen und industriellen Umgebungen, in denen sie Betriebsstörungen auslösen könnten (s. Erwägungsgrund 56).
Stattdessen wird dort ein nachvollziehbarer, dokumentierter Prozess für die zeitnahe manuelle Einspielung verfügbarer Sicherheitsupdates erwartet.
Status Quo: (c) Updatefähigkeit und automatische Sicherheitsupdates
Was in der Praxis oft bereits gegeben ist
Bei vernetzten Consumer-Produkten mit regelmäßiger Internetverbindung ist Auto-Update weitgehend etabliert; auch viele B2B-Produkte bringen Update-Mechanismen mit, oft aber mit deaktivierten Auto-Updates und ohne klare Trennung von Security- und Feature-Updates.
Was zur CRA-Compliance noch fehlt
Die Opt-out-Dokumentation, die Trennung von Sicherheits- und Funktionsupdates und die Notification-Mechanismen. Hinzu kommt ein Aspekt, der über die reine Update-Technik hinausgeht: Die EN 40000-1-3 (Vulnerability Handling) verlangt, dass Cybersicherheitsprobleme unverzüglich und auf angemessene Weise behandelt werden. Das setzt voraus, dass ein Hersteller vorab definiert hat, wie er auf gemeldete Schwachstellen reagiert — mit welchen Fristen, in welcher Priorisierung, durch wen. Diese vorausschauende Reaktionsplanung ist für viele Unternehmen neu. (Siehe dazu auch unser erster Artikel zu CRA-Meldepflichten.)
(d) Schutz vor unbefugtem Zugriff
Das Produkt muss durch geeignete Kontrollmechanismen vor unbefugtem Zugriff geschützt sein, mindestens durch Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme; unbefugte Zugriffsversuche müssen erkannt und gemeldet werden.
Die kommende EN 40000-Reihe konkretisiert das in prüfbare Unteranforderungen:
- eindeutige Nutzeridentifikation (keine geteilten Accounts, die die nachträgliche Zuordnung von Aktionen unmöglich machen),
- starke Passwortanforderungen oder gleichwertige Mechanismen,
- Multi-Faktor-Authentifizierung für privilegierte Zugänge
- und Administratorfunktionen sowie automatische Sperrung nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche.
Die Anforderung umfasst alle Zugangswege: nicht nur die primäre Benutzeroberfläche, sondern auch Wartungsschnittstellen, Debug-Ports, Management-APIs und Fernzugriffe. Gerade Wartungsschnittstellen, die während der Entwicklung angelegt und in Produktionsgeräten aktiv geblieben sind, sind ein häufiger Schwachpunkt.
Status Quo: (d) Schutz vor unbefugtem Zugriff
Was in der Praxis oft bereits gegeben ist
Authentifizierungsmechanismen in nahezu jedem Produkt.
Was zur CRA-Compliance noch fehlt
Die systematische Abdeckung aller Zugangswege (im Idealfall bereits im Risikoassessment erfasst), die Dokumentation der Authentifizierungsanforderungen und die Erkennung und Meldung von Zugriffsversuchen.
(e) Vertraulichkeit von Daten
Gespeicherte, übertragene und anderweitig verarbeitete Daten müssen in ihrer Vertraulichkeit geschützt werden. Das heißt aber nicht, dass pauschal alles zu verschlüsseln ist: Die Anforderung gilt „auf Basis der Risikobewertung und soweit zutreffend”. Also nur für die Daten, bei denen das Risiko es rechtfertigt, und in dem Umfang, der zum jeweiligen Produkt passt. Verschlüsselung nach dem Stand der Technik nennt der CRA dabei ausdrücklich als Mittel („etwa durch Verschlüsselung relevanter Daten at rest oder in transit”), aber nicht als einziges — der Verordnungstext lässt daneben ausdrücklich „andere technische Mittel” zu, etwa ein belastbares Zugriffskonzept (s. Anhang I Teil I lit. e).
In der Praxis kommt für die Datenübertragung über Netzwerke meist TLS (Transport Layer Security, das Standardprotokoll, das eine Verbindung verschlüsselt, etwa das „https” im Browser) in aktueller Version zum Einsatz, mindestens TLS 1.2, empfohlen TLS 1.3.
Hinzu kommt, wo das Risiko es erfordert, die Verschlüsselung sensitiver Daten „at rest” — also im gespeicherten Zustand auf dem Gerät, im Unterschied zu Daten „in transit” während der Übertragung. Das betrifft typischerweise Credentials, kryptografische Schlüssel und personenbezogene Daten. Und in keinem Fall dürfen Zugangsdaten im Klartext übertragen werden.
Was „Stand der Technik” heißt, orientiert sich an anerkannten kryptografischen Empfehlungen — für Deutschland die BSI TR-02102 (der jährlich aktualisierte BSI-Katalog, welche Verschlüsselungsverfahren und Schlüssellängen als sicher gelten), auf europäischer Ebene die SOG-IS Agreed Cryptographic Mechanisms.
Häufig wird übersehen: Diese Anforderung gilt nicht nur für die externe Kommunikation, sondern auch für die Kommunikation zwischen internen Komponenten. Microservice-Architekturen, deren interne Services unverschlüsselt kommunizieren, „weil das ja im eigenen Netz ist”, sind das klassische Beispiel für eine Lücke unter (e).
Status Quo: (e) Vertraulichkeit von Daten
Was in der Praxis oft bereits gegeben ist
Für die klassische Netzwerk- und Internetkommunikation ist TLS heute weitgehend Standard. Bei eingebetteten Systemen gilt das aber keineswegs durchgängig — und der Blick verengt sich leicht auf IP-basierte Verbindungen. Vertraulichkeit betrifft jedoch jede Schnittstelle, über die Daten fließen: auch Bluetooth, andere Funkprotokolle, lokale Bus- oder Debug-Schnittstellen. Genau diese nicht-netzwerkbasierten Übertragungswege werden bei der Verschlüsselung am häufigsten übersehen.
Was zur CRA-Compliance noch fehlt
Der Schritt beginnt eigentlich früher, als viele denken, nämlich mit der Klassifizierung der Daten bereits in Konzept- und Architekturphase. Welche Daten verarbeitet das Produkt überhaupt, und welche davon sind tatsächlich schützenswert (personenbezogen oder anderweitig sensitiv)? Diese Einordnung entscheidet, ob und wo die Anforderung greift. Verarbeitet ein Produkt gar keine solchen Daten, kann sie im Einzelfall auch nicht anwendbar sein. Erst auf dieser Grundlage werden die konkreten Lücken sichtbar: die Verschlüsselung interner Kommunikation, die systematische Prüfung der verwendeten kryptografischen Algorithmen auf Aktualität und die Verschlüsselung sensitiver Daten „at rest”.
(f) Integrität von Daten, Befehlen und Konfigurationen
Unautorisierte Manipulation von Daten, Programmen, Befehlen und Konfigurationen muss verhindert und erkannt werden. Diese Anforderung adressiert gezielt die Integrität (Integrity), also eine der drei Schutzdimensionen der CIA-Trias (s. vorherige Artikel), angewendet auf alle relevanten Datentypen. (Vertraulichkeit und Verfügbarkeit, die beiden anderen Dimensionen, sind an dieser Stelle nicht Gegenstand der Anforderung; sie werden in den Anforderungen (e) und (h) gesondert behandelt.)
Konkret bedeutet das:
- kryptografische Signaturen für Software-Updates: Sie stellen sicher, dass ein Update unverändert ist (Integrität) und tatsächlich vom Hersteller stammt (Authentizität), sodass nur echte, unmanipulierte Updates eingespielt werden. Integritätsprüfung von Konfigurationsdaten (unbefugte Änderungen werden erkannt)
- sowie Erkennung und Meldung von Manipulationen an sicherheitsrelevanten Dateien, Datenbanken oder Systemzuständen.
Wichtig ist dabei, dass Integritätsschutz den gesamten Produktlebenszyklus betrifft und nicht nur einen einzelnen Moment. Er beginnt in der Architektur (wo etwa festgelegt wird, welche Daten überhaupt manipulationsgeschützt sein müssen und mit welchen Mechanismen), setzt sich in der Implementierung fort (Signaturprüfung, Zugriffsschutz, sichere Speicherung) und reicht bis in den laufenden Betrieb (fortlaufende Überwachung auf Manipulationen samt Meldung). Je nach Phase kommen dabei unterschiedliche Maßnahmen zum Tragen.
Oft übersehen wird dabei die Befehlsintegrität. In vernetzten Systemen, die Steuerbefehle von externen Quellen empfangen, muss sichergestellt sein, dass diese Befehle unverändert ankommen (Integrität) und wirklich von der legitimen Quelle stammen (Authentizität). Beides ist eng verwandt, aber nicht dasselbe: Ein Befehl kann technisch unverändert sein und trotzdem von einem Angreifer stammen. Das klassische Beispiel dafür ist der Replay-Angriff, bei dem ein legitimer, korrekt signierter Befehl aufgezeichnet und später unverändert erneut eingespeist wird. Gerade weil der Befehl dabei inhaltlich unangetastet bleibt, greift reiner Integritätsschutz hier nicht; verhindern lässt sich das durch kryptografische Mechanismen wie Nonces, Zeitstempel oder Challenge-Response.
Status Quo: (f) Integrität von Daten, Befehlen und Konfigurationen
Was in der Praxis oft bereits gegeben ist
Ein erstes Bewusstsein dafür, dass Updates vor Veränderung geschützt werden müssen. Häufig geschieht das aber nur über einfache Prüfsummen (Checksummen), die lediglich unabsichtliche Übertragungsfehler erkennen. Sie bieten keinen Schutz gegen gezielte Manipulation, weil ein Angreifer die Prüfsumme einfach mitverändern kann. Echte kryptografische Signaturen, die Integrität und Herkunft absichern, sind seltener implementiert, als man erwarten würde.
Was zur CRA-Compliance noch fehlt
Der Umstieg von einfachen Prüfsummen auf echte kryptografische Signaturen bei Software-Updates, der Integritätsschutz für Konfigurationsdaten sowie die Erkennung von Manipulationen an sicherheitsrelevanten Dateien und Systemzuständen samt Meldung.
(g) Datenminimierung
Das Produkt darf nur Daten verarbeiten, die für den jeweiligen Zweck angemessen, relevant und auf das Notwendige beschränkt sind. Hier handelt es sich letztlich um das aus der DSGVO bekannte Datenminimierungsprinzip, im CRA nun als Produktanforderung.
In der Praxis gilt:
- Telemetrie darf nur umfassen, was für den angegebenen Zweck tatsächlich nötig ist;
- Diagnostik-Daten für die Fehleranalyse sind zulässig, darüber hinausgehende Nutzungsdaten ohne Funktionsbezug nicht;
- personenbezogene Daten dürfen nicht länger gespeichert werden als für den Zweck erforderlich.
Der Schnittpunkt mit der DSGVO ist relevant, aber nicht deckungsgleich: Die DSGVO regelt die Verarbeitung personenbezogener Daten durch den Verantwortlichen, der CRA die Datenverarbeitung durch das Produkt selbst.
Ein Produkt, das mehr Daten sammelt als für seine Funktion notwendig, verstößt somit gegen den CRA (unabhängig davon, ob der Hersteller die DSGVO an anderer Stelle erfüllt).
Status Quo: (g) Datenminimierung
Was in der Praxis oft bereits gegeben ist
Datenminimierung ist keine Funktion, die man implementiert, sondern eine bewusste Design-Entscheidung, nur die wirklich benötigten Daten zu erheben. Vorhandene Telemetrie- oder Analysefunktionen zählen hier gerade nicht als Erfüllung, im Gegenteil: Sie sind häufig der Grund, warum mehr Daten anfallen als nötig. Ein sinnvoller Anknüpfungspunkt findet sich aber branchenübergreifend dort, wo im Rahmen der DSGVO bereits Datenkataloge oder Verarbeitungsverzeichnisse geführt werden. Auf dieser Grundlage lässt sich aufsetzen, denn sie beantwortet bereits die entscheidende Vorfrage: Welche Daten werden überhaupt erhoben und wofür?
Was zur CRA-Compliance noch fehlt
Der Ansatz beginnt sinnvollerweise schon im Risikoassessment, indem die verarbeiteten Daten von Anfang an kategorisiert werden. Personenbezogene und andere sensitive Daten werden dabei als eigenes schützenswertes Asset erfasst, was zugleich die Grundlage für die Anforderungen (e) und (g) bildet. Darauf aufbauend folgt die eigentliche Arbeit der Datenminimierung: die systematische Prüfung, ob die gesammelten Daten für den jeweiligen Zweck wirklich notwendig sind, und die nachvollziehbare Dokumentation dieser Entscheidung.
(h) Verfügbarkeit und Resilienz
Wesentliche Funktionen müssen auch nach einem Sicherheitsvorfall aufrechterhalten werden, einschließlich Abwehr- und Eindämmungsmaßnahmen gegen Denial-of-Service-Angriffe (s. Anhang I Teil I lit. h).
Damit wird die Availability-Dimension der CIA-Trias eine explizite Produktanforderung.
In der Praxis erfordert das ein Rate Limiting auf allen für DoS missbrauchbaren Schnittstellen; eine Graceful Degradation, bei der das Produkt unter Überlast oder Angriff seine Kernfunktionen hält, auch wenn Zusatzfunktionen wegfallen, und darüber hinaus Watchdog-Mechanismen, die das System bei Absturz oder Fehlfunktion in einen sicheren Zustand zurückführen.
Für sicherheitskritische Anwendungen — industrielle Steuerungssysteme, Netzwerkinfrastruktur — hat das besonderes Gewicht. Ein Router, der unter DDoS zusammenbricht und damit das gesamte Netzwerk lahmlegt, verstößt gegen (h).
Status Quo: (h) Verfügbarkeit und Resilienz
Was in der Praxis oft bereits gegeben ist
Watchdog-Mechanismen und automatische Neustarts sind in Embedded-Systemen weitgehend Standard.
Was zur CRA-Compliance noch fehlt
Zunächst überhaupt die Berücksichtigung von DoS-Szenarien im Risikoassessment, damit die Verfügbarkeit als schützenswertes Ziel bewusst bewertet wird und nicht unbeachtet bleibt. Darauf aufbauend folgen explizite DoS-Schutzmaßnahmen auf Anwendungsebene und die Bewertung, ob Rate Limiting (die Begrenzung, wie viele Anfragen ein System pro Zeitspanne von einer Quelle annimmt, um Überlastung zu verhindern) auf allen angreifbaren Schnittstellen vorhanden und ausreichend dimensioniert ist.
(i) Minimierung negativer Auswirkungen auf andere Systeme
Das Produkt darf im Fall einer Kompromittierung nicht zum Angriffswerkzeug gegen andere Geräte oder Netzwerke werden. Dabei soll es die negativen Auswirkungen der Produkte selbst oder vernetzter Geräte auf die Verfügbarkeit der von anderen Geräten oder Netzen bereitgestellten Dienste minimieren (s. Anhang I Teil I lit. i).
Die historische Motivation ist klar: Mirai (das IoT-Botnetz von 2016, das über gekaperte Geräte großflächige DDoS-Angriffe fuhr) und vergleichbare Botnet-Angriffe haben gezeigt, dass schlecht gesicherte IoT-Geräte massenhaft als Angriffswerkzeuge gegen Dritte missbraucht werden. Der CRA macht die Vermeidung dieser externen Schadenswirkung zur Produktanforderung.
Typischerweise bedeutet das, es braucht:
- Mechanismen, die verhindern, dass ein kompromittiertes Gerät unbegrenzt Netzwerkverkehr gegen Dritte erzeugt,
- Bandbreitenbeschränkungen auf ausgehenden Verbindungen,
- Überwachung anomaler Kommunikationsmuster,
- und automatische Isolation bei erkannten Anomalien.
Für Produkte mit Internetzugang ist die Beschränkung auf notwendige Ausgangsverbindungen (Egress Filtering) eine grundlegende Maßnahme.
Status Quo: (i) Minimierung negativer Auswirkungen auf andere Systeme
Was in der Praxis oft bereits gegeben ist
Bandbreitenbeschränkungen und Rate Limiting existieren häufig aus Performance-Gründen und erfüllen die Anforderung mit.
Was zur CRA-Compliance noch fehlt
Die explizite Verankerung im Risikoassessment. Bei der Bewertung der Schadensszenarien (Damage Scenarios) sollten die Auswirkungen auf Dritte von vornherein mitbetrachtet werden, also die Frage, welchen Schaden ein kompromittiertes Produkt bei anderen Geräten, Netzen oder Nutzern anrichten kann. Darauf aufbauend folgen die Bewertung unter dem Gesichtspunkt „was passiert bei Kompromittierung” und die Dokumentation der entsprechenden Schutzmaßnahmen.
(j) Minimierung der Angriffsfläche
Das Produkt ist so zu konzipieren, entwickeln und herzustellen, dass es — auch bei externen Schnittstellen — möglichst geringe Angriffsflächen bietet (s. Anhang I Teil I lit. j).
Jede externe Schnittstelle, jeder Dienst, jede aktivierte Funktion jenseits der Kernfunktion ist potenzielle Angriffsfläche.
Das Prinzip heißt „Principle of Least Functionality”: Das Produkt soll nur können, was es für seinen Zweck können muss, nichts darüber hinaus.
Das bedeutet:
- unnötige Protokolle deaktivieren,
- unnötige Dienste entfernen oder deaktivieren,
- unnötige Schnittstellen sperren;
- was unvermeidlich ist, muss so restriktiv wie möglich konfiguriert und gegen Angriffe abgesichert werden.
Dasselbe Prinzip gilt ausdrücklich auch für die Schnittstellen zugekaufter COTS-Komponenten. Diese bringen oft Schnittstellen mit, die für die eigentliche Produktfunktion gar nicht gebraucht werden. Werden sie nicht aktiv deaktiviert, fallen sie in späteren Analysen leicht durchs Raster, obwohl von ihnen weiterhin eine Gefahr ausgeht.
Besonders relevant für Produkte auf allgemeinen Betriebssystemen: Ein Linux-basiertes IoT-Gerät bringt von Haus aus zahlreiche Dienste und Protokolle mit, die die Produktfunktion nicht benötigt. Das Hardening — das systematische Deaktivieren aller nicht benötigten Komponenten — ist hier kein optionaler Schritt, sondern direkte Anforderung aus (j).
Status Quo: (j) Minimierung der Angriffsfläche
Was in der Praxis oft bereits gegeben ist
Firewall-Regeln und Port-Konfigurationen.
Was zur CRA-Compliance noch fehlt
Die systematische Prüfung aller aktivierten Dienste, Protokolle und Schnittstellen unter der Frage „was brauchen wir wirklich?”, einschließlich der oft übersehenen Schnittstellen zugekaufter COTS-Komponenten, sowie deren Dokumentation. Auch hier zeigt sich, warum eine saubere Item Definition am Anfang so wichtig ist: Nur was zu Beginn vollständig erfasst wurde, kann später überhaupt auf seine Notwendigkeit geprüft werden. Was sich nicht abschalten lässt, muss anschließend gehärtet werden, also gezielt gegen Angriffe abgesichert, etwa durch restriktive Konfiguration, das Entfernen von Standardzugängen und die Beschränkung von Rechten.
(k) Schadensbegrenzung durch Exploitation-Mitigation
Das Produkt ist so zu konzipieren, entwickeln und herzustellen, dass die Auswirkungen eines Sicherheitsvorfalls durch geeignete Mechanismen und Techniken zur Minderung der möglichen Ausnutzung verringert werden (s. Anhang I Teil I lit. k).
Hier ist der CRA realitätsnah und adressiert eine fundamentale Realität: Kein Produkt lässt sich vollständig immunisieren. Ziel ist daher nicht nur, Angriffe zu verhindern, sondern ihre Auswirkungen zu begrenzen, wenn ein Angriff doch gelingt.
Die Anforderung (k) folgt dem Prinzip der mehrschichtigen Verteidigung (Defense in Depth): Statt sich auf eine einzige Schutzlinie zu verlassen, werden mehrere unabhängige Schutzebenen kombiniert. Wird eine Ebene überwunden, verhindern die darunterliegenden weiterhin, dass ein Angreifer das gesamte Produkt übernimmt. Das ist der Kern dieser Anforderung: nicht jeden Angriff zu verhindern, sondern seine Auswirkungen zu begrenzen, wenn er doch gelingt.
Typische Schutzebenen dafür sind:
- Isolation von Komponenten (Sandboxing): Einzelne Funktionsblöcke werden voneinander abgeschottet, sodass ein kompromittierter Bestandteil nicht auf andere Komponenten oder Systemressourcen zugreifen kann. Wie das umgesetzt wird, hängt von der Produktplattform ab. Auf betriebssystembasierten Geräten geschieht es etwa über getrennte, rechtebeschränkte Dienste oder Zugriffskontrollmechanismen wie SELinux oder AppArmor, auf Mikrocontrollern über Speicherpartitionierung (MPU) oder eine hardwaregestützte, vertrauenswürdige Ausführungsumgebung (TEE).
- Speicherschutz wie ASLR (Address Space Layout Randomization) und Stack Canaries, die die Ausnutzung von Speicherfehlern erschweren.
- Least Privilege: Jede Komponente und jeder Dienst läuft nur mit den minimal notwendigen Rechten, sodass eine Kompromittierung möglichst wenig Handlungsspielraum eröffnet.
- Virtualisierung oder Containerisierung als weitergehende Form der Isolation, die eine Kompromittierung auf abgeschlossene Bereiche beschränkt, sofern die Produktplattform dies unterstützt.
Status Quo: (k) Schadensbegrenzung durch Exploitation-Mitigation
Was in der Praxis oft bereits gegeben ist
In der klassischen IT-Welt sind Speicherschutzmechanismen wie ASLR in modernen Betriebssystemen und Compilern meist schon standardmäßig aktiv. Für Embedded-Systeme gilt das aber nicht automatisch. Auf vielen kleinen Mikrocontrollern, wie sie im Embedded- oder Automotive-Umfeld verbreitet sind, stehen solche Schutzmechanismen nicht von Haus aus bereit, sondern müssen bewusst aktiviert werden und werden teils erst durch die passende Hardware ermöglicht. Der Schutz vor Speicherfehlern ist hier also eine aktive Design-Entscheidung, kein Automatismus.
Was zur CRA-Compliance noch fehlt
Die bewusste Verifikation, dass diese Mechanismen tatsächlich aktiviert und korrekt konfiguriert sind, und die Prüfung, ob darüber hinausgehende Isolation für das spezifische Risikoprofil erforderlich ist.
(l) Sicherheitsrelevantes Logging und Monitoring
Das Produkt muss sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge bereitstellen, etwa Zugang zu Daten, Diensten oder Funktionen und Änderungen daran (s. Anhang I Teil I lit. l).
Wichtig dabei: Nutzer müssen dieses Logging deaktivieren können (Opt-out).
Sicherheitsrelevantes Logging umfasst mindestens:
- Authentifizierungs- und Autorisierungsereignisse (erfolgreiche und fehlgeschlagene Anmeldungen, Zugriffsversuche auf geschützte Ressourcen),
- Konfigurationsänderungen,
- Systemereignisse mit möglichem Kompromittierungsbezug
- sowie Netzwerkkommunikationsereignisse bei Produkten, die aktiv Netzwerkverbindungen verwalten.
Wichtige Einschränkung dabei: Die Logs selbst dürfen keine sensitiven Daten im Klartext enthalten. Passwörter, Schlüssel oder vollständige personenbezogene Daten haben in Logs nichts zu suchen. Logisch, denn Logs mit sensitiven Daten schaffen neue Datenschutz- und Sicherheitsrisiken, statt zur Sicherheit beizutragen.
Status Quo: (l) Sicherheitsrelevantes Logging und Monitoring
Was in der Praxis oft bereits gegeben ist
Logging ist in den meisten Produkten vorhanden, oft für Debugging und Support.
Was zur CRA-Compliance noch fehlt
Die Ausrichtung des Loggings auf sicherheitsrelevante Ereignisse, die Prüfung auf sensitive Daten in Logs und die Implementierung des Opt-out. Häufig fehlt zudem überhaupt ein praktikabler Weg, an die Logging-Daten heranzukommen. Bei Produkten ohne Internetverbindung und ohne Wartungsschnittstelle, wie sie bei vielen Elektronikgeräten im Alltag der Fall sind, werden Ereignisse zwar unter Umständen lokal aufgezeichnet, lassen sich aber im Bedarfsfall gar nicht auslesen. Ein Logging, das im Ernstfall niemand einsehen kann, erfüllt seinen Zweck nicht. Der Zugang zu den Aufzeichnungen muss daher von Anfang an mitgedacht werden.
(m) Sichere und vollständige Datenlöschung
Nutzer müssen alle Daten und Einstellungen dauerhaft, sicher und einfach löschen können; ein Datentransfer auf andere Produkte oder Systeme muss sicher erfolgen (s. Anhang I Teil I lit. m).
Dies wird relevant bei Gerätetausch, Weiterverkauf und Entsorgung — und in der Praxis erschreckend häufig unzureichend umgesetzt.
Ein „Factory Reset”, der nur die Konfiguration zurücksetzt, gespeicherte Daten aber nicht sicher überschreibt, erfüllt die Anforderung nicht. Wer ein gebrauchtes Gerät kauft und mit einfachen Mitteln die Daten des Vorbesitzers auslesen kann, belegt eine Verletzung von (m).
Für Produkte mit Flash-Speicher ist „sicheres Löschen” technisch nicht trivial: Einfaches Überschreiben funktioniert wegen Wear Leveling (Daten wandern automatisch an wechselnde Speicherstellen) und Bad Block Management (unbrauchbare Bereiche werden stillgelegt, bleiben aber lesbar) nicht zuverlässig. Kryptografisches Löschen, bei dem die Verschlüsselungsschlüssel sicher vernichtet und die verschlüsselten Daten damit unzugänglich werden, ist für Flash-basierte Produkte die praxistaugliche Alternative.
Status Quo: (m) Sichere und vollständige Datenlöschung
Was in der Praxis oft bereits gegeben ist
Factory-Reset-Funktionen sind fast überall implementiert.
Was zur CRA-Compliance noch fehlt
Das Thema sichere Datenlöschung, und ebenso das kontrollierte Auslesen von Daten, gehört bereits in der Konzeptphase in die Architektur. Wird es dort nicht von Anfang an mitgedacht, lässt es sich später oft nur schwer nachrüsten, weil es davon abhängt, wie Daten gespeichert und verschlüsselt werden. Darauf aufbauend folgen die Verifikation, dass der Reset alle sensitiven Daten unwiederbringlich entfernt, und die Dokumentation des verwendeten Löschverfahrens.
Was die CRA-Cybersecurity-Anforderungen in Summe ergeben und was daraus folgt
Eine ehrliche Bestandsaufnahme zeigt: Für Produkthersteller, die bereits Security-Maßnahmen implementiert haben, klingen die meisten der 13 Anforderungen nicht grundlegend neu.
Das ist kein Zufall. Der CRA destilliert letztendlich auch nur die heute etablierten Security-Best-Practices in EU-weite Rechtsverbindlichkeit.
Was sich ändert, ist somit nicht primär das Was, sondern das Wie der Dokumentation und Nachweisführung.
Der pragmatische Ansatz für die CRA-Vorbereitung heißt nicht „bei null anfangen”, sondern „inventarisieren, mappen, Lücken schließen”.
Für die meisten Hersteller ist das weniger eine technische Neuentwicklung als eine Dokumentations- und Lückenanalyse-Aufgabe.
Grundlage für alles Weitere ist dabei das CRA-Risikoassessment: Es bestimmt zusammen mit dem Produktumfang, welche der 13 Anforderungen für das konkrete Produkt überhaupt anwendbar sind und mit welcher Tiefe. Nicht jede Anforderung gilt für jedes Produkt, und gerade das blinde Erfüllen aller 13 verursacht unnötigen Aufwand und vermeidbare Kosten. Auf dieser Basis lässt sich die Analyse in vier Schritten angehen:
- Inventarisieren: Alle bereits vorhandenen Sicherheitsmaßnahmen erfassen, technische wie organisatorische, auch solche, die heute nicht als „CRA-relevant” gelten (etwa TLS, Update-Signaturen, Zugriffskonzepte oder Awareness-Trainings).
- Mappen: Jede vorhandene Maßnahme den relevanten Anforderungen aus Anhang I Teil I zuordnen. So wird sichtbar, welche Anforderungen bereits abgedeckt sind und mit welchen Belegen.
- Lücken identifizieren: Pro Anforderung festhalten, was fehlt. Meist ist das nicht die Maßnahme selbst, sondern ihr dokumentierter, nachweisbarer Bezug zur Anforderung.
- Priorisieren und schließen: Die Lücken nach Risiko und Aufwand ordnen und abarbeiten, dokumentieren, wo Maßnahmen bereits greifen, nachrüsten, wo sie fehlen, und für jede nicht anwendbare Anforderung eine Begründung festhalten.
So strukturiert, wird aus einer scheinbar überwältigenden Liste von 13 Anforderungen eine überschaubare Abgleichsaufgabe. Die Lücken, die dabei zutage treten, sind erfahrungsgemäß weniger fehlende Technik als fehlende Nachweise, und sie wiederholen sich über Produktwelten hinweg in ähnlicher Form.
Weil solche Lücken strukturell wiederkehren und intern oft übersehen werden, empfiehlt sich der frühzeitige Austausch mit security-versierten Dritten: Er löst die Betriebsblindheit auf und bringt Produkt, die vorgestellten Anforderungen aus Anhang I und die regulatorische Zielsetzung des CRA in eine konsistente Linie.
- Nicht jede der 13 Anforderungen gilt für jedes Produkt. Was zutrifft, entscheiden Produktumfang und Risikobewertung. Fällt eine weg, muss das begründet und dokumentiert sein.
- Der CRA sagt was, nicht wie. Der Gesetzestext bleibt abstrakt. Die konkrete Umsetzungstiefe steuert die Risikobewertung, die kommende EN 40000 liefert später die technischen Details.
- Meist fehlt nicht die Technik, sondern der Nachweis. Die meisten Hersteller haben vieles längst umgesetzt (TLS, Update-Signaturen, Zugriffskonzepte). Neu ist die dokumentierte, begründete Verknüpfung mit den Anforderungen.
- Kein Start ohne Risikobewertung und Item Definition. Wer direkt bei den 13 Anforderungen loslegt, produziert Maßnahmen am tatsächlichen Risiko vorbei, und damit vermeidbare Kosten.
- Der Weg ist: inventarisieren, mappen, Lücken schließen. Keine Neuentwicklung, sondern eine strukturierte Abgleichsaufgabe. Die Lücke ist meist kleiner als befürchtet.
- Eine Anforderung braucht mehr als einen Nachweis: „keine bekannten Schwachstellen" (a) funktioniert dauerhaft nur mit einem laufenden Vulnerability-Handling-Prozess, Thema des vierten Artikels unserer CRA-Artikelreihe.
- Als Grundlage für die Risikobewertung eignet sich heute die BSI TR-03183, später die EN 40000-1-2. Beide liegen inhaltlich nah beieinander, ein späterer Wechsel bedeutet also keinen Neuanfang.
- Key Learnings
Damit schließt sich der Bogen: Die 13 Essential Requirements aus Anhang I Teil I sind kein Checklisten-Bürokratie-Akt, sondern die direkte technische Konsequenz der Risikobewertung aus dem zweiten Artikel unserer Serie.
Wer in der Cyberrisikobewertung saubere Arbeit geleistet hat, findet hier die logische Fortsetzung, keine von außen aufgesetzte Pflichtenliste.
Und wer bestehende Maßnahmen systematisch gegen die Anforderungen mappt, stellt meist fest: Der Abstand zwischen dem, was schon vorhanden ist, und dem, was der CRA verlangt, ist kleiner als befürchtet.
Was fehlt, ist selten die technische Substanz, sondern ihre dokumentierte, begründete und nachweisbare Verknüpfung mit den Anforderungen.
Aber: An einer Anforderung zeigt sich allerdings, dass Nachweis allein nicht genügt.
Die Anforderung (a) — kein Produkt mit bekannten ausnutzbaren Schwachstellen in Verkehr zu bringen — lässt sich strukturell nur durch einen funktionierenden Vulnerability-Handling-Prozess dauerhaft erfüllen.
Wie dieser Prozess aufgebaut wird — von der SBOM über das CVE-Monitoring bis zur Coordinated Vulnerability Disclosure Policy und den sicheren Update-Verteilungsmechanismen — erörtern wir im vierten Artikel.
