EU Cyber Resilience Act [German Version]

Security soll Teil des CE-Kennzeichens werden

Photo by Sara Kurfeß on Unsplash

Schon vor einem Jahr, am 15. September 2021, hat EU-Kommissionspräsidentin Ursula von der Leyen in ihrer Rede zur Lage der EU den Cyber Resilience Act (CRA) angekündigt. Genau ein Jahr später, am 15. September 2022, hat die europäische Kommission nun Nägel mit Köpfen gemacht und einen Entwurf für den CRA veröffentlicht.

Wenn die EU-Richtlinie so beschlossen wird, ist das ein Meilenstein: Es gibt dann ein CE-Kennzeichen für digitale Produkte, das Security-Anforderungen verpflichtend macht — denn ohne dürfen die Produkte im EU-Binnenmarkt dann nicht mehr verkauft werden. Dieser Beitrag ordnet den Cyber Resilience Act in die übrige EU-Gesetzgebung zum Thema Security und kritische Infrastrukturen ein und erklärt die Details des Entwurfs.

Bevor wir in die Details einsteigen, können wir festhalten: Mit der Namensgebung ihres neuen Gesetzes liegt die EU voll im Trend.

Cyber und Resilienz sind ja in aller Munde. Das eigentlich eher ungeliebte Wort “Cyber(security)” sickert immer mehr in akzeptierten Sprachgebrauch der IT-Security-Bubble und meint meist doch nicht viel mehr als “irgendwas mit Computern”; zum Verdruss derer, die die Ursprünge des Wortes in der Kybernetik hoch halten.
“Resilienz” ist spätestens seit der Pandemie erklärtes Ziel in vielen Bereichen: Wo wir mit Prävention nicht weiterkommen, wo wir akzeptieren müssen, dass Krisen eintreten, müssen wir eben resilient sein — also auch im Krisenfall funktionieren. Cyberresilienz klingt also irgendwie abgeklärter, aber gleichzeitig auch irgendwie resginierter als Cybersecurity, nach “die Zeiten sind hart, wir müssen unsere Methoden daran anpassen”.

…noch eine EU-Regulierung für Security?!

Methoden anpassen, das passt zum Inhalt des Cyber Resilience Act. Denn der Cyber Resilience Act betrifft erstmals Produkthersteller. Bislang zielte die europäische Regulierung im Bereich Cybersecurity eher auf Betreiber ab: Die ECI-Direktive (Directive on European Critical Infrastructure, 2008) sowie die NIS-Direktive (Directive on Security of Network and Information Systems, 2016) sind der europäische Rechtsrahmen für das deutsche IT-Sicherheitsgesetz, das Security-Pflichten für die Betreiber kritischer Infrastrukturen (KRITIS) regelt. Für beide Direktiven sind gerade Aktualisierungen unterwegs: Die ECI-Direktive soll durch die RCE-Direktive (Directive on the Resilience of Critical Entities; da ist sie wieder, sie Resilienz…) ersetzt werden, die NIS-Direktive durch die NIS-2-Direktive (Directive on Measures for a High Common Level of Cybersecurity across the Union). Aber darum soll es hier nicht gehen.

Welches Problem löst der Cyber Resilience Act?

Bauchschmerzen aus Betreibersicht: Das Kuckucksei-Problem

KRITIS-Betreiber kennen das Problem: Sie sind Risikoeigentümer für ihre eigenen Anlagen und ihre sogenannten “kritischen Dienstleistungen”, das heißt, sie müssen die Cybersecurity selbst verantworten. Die Security selbst veranworten kann man eigentlich nur, wenn man die technischen Systeme versteht, die man betreibt. Und da stoßen Betreiber, vor allem kleinere, an Grenzen.

Sie sind auf die Hersteller ihrer Leitsysteme, ihrer Steuerungen, aber auch ihrer Netzwerktechnik angewiesen: Wie konfiguriert man die Systeme so, dass sie sicher sind? Haben sie überhaupt Security-Funktionalitäten? Darf ich auf meinen Leitsystem ein Virenschutzprogramm installieren, ohne dass die Herstellergarantie erlischt? Und wer informiert mich, wenn in den verbauten Systemen eine neue Schwachstelle bekannt wird?

Die einzige Antwort, die ihnen die bisherige KRITIS-Regulierung bot, war die Ausweitung der eigenen Maßnahmen auf die eigenen Lieferanten: Wenn man selbst ein Security-Managementsystem hat, kann man seine Lieferanten als Schnittstelle auditieren. Das gewährt Einblick in die Arbeitsweise der Lieferanten, aber macht nicht zwangsläufig ihre Produkte sicherer.

In den letzten Jahren gab es eine Reihe von Security-Vorfällen, die als Supply-Chain-Attacks klassifiziert werden können, also sich über die Lieferkette von Software verbreiteten und / oder deswegen hohe Auswirkungen hatten, weil sie in vielen anderen Produkten verbaut waren. Drei Beispiele: Im Falle des Ripple 20-Vorfalls führte eine Schwachstelle tief im TCP/IP-Protokollstack zu einer immensen Zahl betroffener Produkte. Beim Solarwinds-Vorfall wurde Schadcode über die Update-Funktion einer häufig genutzten Monitoring-Software verbreitet, der Kaseya-Vorfall war ähnlich gelagert, aber diesmal war eine Netzwerkadministrationssoftware die Virenschleuder. Kaseya zieht auch die EU-Kommission zur Begründung der Notwendigkeit des Cyber Resilience Act heran.

Diese Vorfälle haben das Problem überdeutlich gemacht: Betreiber haben kaum eine Chance, die vielen verschiedenen Hardware- und Software-Komponenten in ihrer Obhut überhaupt zu überblicken, geschweige denn deren Security-Schwachstellen. In den Supply-Chain-Security-Vorfällen war die erste große Herausforderung meist schon, überhaupt herauszufinden, ob man die betreffenden Komponenten selbst überhaupt einsetzt, also ob man betroffen ist, so tief in den Eingeweiden der verbauten Komponenten versteckten sie sich. Und wenn man betroffen ist: Was tut man gegen die Schwachstellen? Wer sagt einem das?

Die Lage lässt viele Betreiber, egal ob KRITIS oder nicht, mit einer schulterzuckenden Resignation zurück. Wie soll man als Betreiber in dieser Problemlage noch seiner Risikoeigentümer-Verantwortung gerecht werden?! Selbst wenn man alle Security-Maßnahmen gewissenhaft erledigt und ein blitzsauberes, gelebtes Security-Managementsystem hat: Die Herstellerkomponenten liegen wie Kuckuckseier im eigenen Security-Nest. Sie sind nun mal da, aber man weiß nicht so recht, was man da ausbrütet.

Security-Probleme bei Herstellern: Drei Antwortstränge

Das Kuckucksei-Problem ist komplex, und wie für jedes komplexe Problem gibt es nicht die eine einfache Antwort, sondern mehrere Antwortstränge.

Einer ist die verbesserte Dokumentation der Hardware und vor allem Software bis auf tiefe technologische Ebenen wie verwendete Bibliotheken oder Protokoll-Stacks. Eine Lösung dazu ist die Software Bill of Materials (SBOM). Das Versprechen: Endlich weiß man genau, welche Softwarekomponenten man verbaut hat, und kann im Falle eines Security-Vorfalls schnell herausfinden, welche Software man selbst einsetzt — auch in zugekauften Komponenten.

Ein weitere Antwortstrang ist ein verbesserter Informationsaustausch über Schwachstellen und Reaktionsmöglichkeiten.
Das kann man organisatorisch lösen durch die Etablierung von CERTs (Computer Emergency Response Teams), die Informationen über Schwachstellen sammeln, bewerten und veröffentlichen. Eine Lösung dazu ist in Deutschland zum Beispiel das CERT@VDE, oder auf EU-Ebene das CERT-EU — dazu kommen wir gleich noch.
Man kann den Informationsaustausch mit technologischen Ansätzen verbessern, durch standardisierte, maschinenlesbare Schwachstellenmeldungen. Eine Lösung dazu ist das Cybersecurity Advisory Format CSAF. Das Versprechen: Man muss die Fülle an Schwachstellenmeldungen nicht mehr händisch auswerten, sondern kann schnell und automatisiert herausfinden, ob man von einer Schwachstelle betroffen ist.

Sie sehen: Auch bei diesen beiden Antwortsträngen liegt der Ball am Ende wieder bei den Betreibern. Sicher, die Hersteller müssen SBOM- und CSAF-Dateien zur Verfügung stellen. Aber dass sie etwas damit anfangen können, dafür müssen Betreiber sorgen.

Und dann gibt es den dritten Antwortstrang: Eine Zertifizierung der Security von Komponenten. Hier liegt der Ball bei Hersteller, denn dieser muss die Zertifizierung erwerben. Das ist aufwendig, vergleichbar mit dem Nachweis über die Erfüllung der KRITIS-Pflichten für Betreiber.

Security-Zertifizierungen von digitalen Produkten

Was bisher geschah

Schon 2019 hat das EU-Parlament dazu den EU Cybersecurity Act (CSA) verabschiedet. Der CSA kann als Wegbereiter verstanden werden. Man ebnete schon einmal den weiteren Weg für eine EU-weite Security-Produktzertifizierung.

Mit dem CSA wurde die ENISA mit neuem Namen und erweitertem Mandat aus der Taufe gehoben. Die ENISA gibt es seit 2004 als “European Network and Information Security Agency”. Seit 2019 heißt sie nun offiziell “European Union Agency for Cybersecurity” (Sie sehen: Cyber!), auch wenn das Akronym gleich geblieben ist. Wichtiger ist die Aufgabenerweiterung der Behörde. Sie spielt nämlich eine wichtige Rolle bei der Umsetzung des European Cybersecurity Certification Frameworks, das EU-weite Security-Zertifizierungsschemata für Produkte bereitstellen soll. Zertifizierungsschemata regeln alles, was für eine Zertifizierung wichtig ist: die abgedeckten Produkte, die zu erfüllenden Anforderungen, wie die Anforderungen geprüft werden und in welcher Metrik der Erfüllungsgrad der Anforderungen (“assurance level”) auf dem Zertifikat festgelegt und kommuniziert wird.

Solche EU-weiten Zertifizierungsschemata sind ein wichtiger Meilenstein. Denn eine verpflichtende Security-Zertifizierung für Hersteller ist rechtlich nicht ganz einfach umzusetzen, weil sie eine Markteintrittshürde darstellt. So etwas muss EU-weit geregelt sein, damit Hersteller aus allen EU-Ländern gleiche Chancen zur Erlangung eines Zertifikats haben.

So tastet sich also auch der “Wegebner” Cybersecurity Act nur langsam an das Thema heran: Es werden zunächst freiwillige EU-Zertifizierungsschemata in Aussicht gestellt, die die Hersteller unter bestimmten Bedingungen sogar durch eine Selbstbeurteilung erreichen können. Das alles klingt etwas zahnlos und erinnert an das IT-Sicherheitskennzeichen, das auf deutscher Ebene das BSI gerade stufenweise einführt. Auch das ist freiwillig, was ihm viel Kritik eingebracht hat. Aber — siehe oben — verpflichtende Zertifizierungen kann eben nur die EU vorschreiben.

Verpflichtende Security-Zertifikate: Hersteller in der Pflicht

So, Trommelwirbel, wir sind beim Thema. Denn genau dies — verpflichtende Security-Zertifizierungen vorschreiben — hat die EU-Kommission nun mit dem Entwurf zum Cyber Resilience Act vor. Die Kommission selbst beschreibt den Entwurf als “first ever EU wide legislation of its kind”, und das ist nicht übertrieben: Denn wenn das Gesetz so beschlossen wird, ist Schluss mit freiwilligen Selbsterklärungen, zumindest für bestimmte Produkte.
Hersteller haben nun plötzlich Pflichten hinsichtlich Cybersecurity. Das kannte man bislang nur von Betreibern. Genauer: Security wird so richtig offiziell eine Produkteigenschaft, und zwar als Teil des CE-Kennzeichens. Software bill of materials (SBOM) und Bekanntgabe von ausgenutzten Schwachstellen innerhalb von 24h inklusive. Aber der Reihe nach.

Das CE-Kennzeichen für Security

Wie funktioniert das CE-Kennzeichen?

Stellen wir uns vor, ein Hersteller möchte ein Produkt in der EU verkaufen, zum Beispiel eine Sonnenbrille.

Das darf er nicht einfach so. Die EU stellt Anforderungen, die der Hersteller erfüllen muss, damit er seine Sonnenbrille im EU-Binnenmarkt verkaufen darf. Damit Käufer nachvollziehen können, ob das Produkt den EU-Anforderungen genügt, bekommen solche Produkte ein CE-Kennzeichen.

Das CE-Kennzeichen (CE steht für Conformité Européenne) regelt die Kennzeichnung von Produkten, die über alle EU-Mitgliedsstaaten hinweg einheitlichen Anforderungen genügen müssen. Diese Anforderungen werden in “EU-Harmonisierungsrichtlinien” beschrieben. Es gibt sie für alles mögliche: Druckbehälter, Spielzeug, persönliche Schutzausrüstung, Medizinprodukte… eben für alles, was irgendwie “sicher” sein muss.

Vielleicht hat Ihnen auch schon einmal jemand gesagt, dass Sie nur bei Sonnenbrillen mit CE-Kennzeichen sicher sein können, dass sie die Augen wirklich vor UV-Strahlen schützen. Damit Verbraucher darauf vertrauen können, dass das Produkt mit CE-Kennzeichen auch wirklich auf die EU-Anforderungen überprüft wurdre, muss die Vergabe des CE-Kennzeichens genau geregelt sein — und das ist sie natürlich auch:

Eine CE-Kennzeichnung besteht aus einer “EU declaration of conformity”, in der die Konformität mit den relevanten Anforderungen erklärt wird und einer “technical documentation”, die alle technischen Details zur Untermauerung der Anforderungserfüllung enthält. Beide Dokumente müssen vom Hersteller kontinuierlich aktuell gehalten werden.

A propos Hersteller: Genauer sprechen wir von “economic operators”, denn verantwortlich für die Erlangung eines CE-Kennzeichens ist, wer das Produkt in den Verkehr bringt. Das sind nicht immer die Hersteller, sondern manchmal auch Importeure oder Händler.

Zur besseren Übersicht ist in der obenstehenden Grafik markiert, aus welchen EU-Richtlinien welche Anforderungen kommen: Alle Vokabeln, die wir bisher gelernt haben, sind in der EU-Richtlinie 765/2008 (dunkelgrau) definiert.

Wie kommt man jetzt an so ein CE-Kennzeichen? Dafür muss die Konformität mit den EU-weit spezifizierten Anforderungen in einem “Conformity Assessment” nachgewiesen werden. Wie so ein Assessment ablaufen kann, ist in der Richtlinie 768/2008/EC (hellgrau in unserer Grafik) beschrieben. Es gibt verschiedene Arten von Conformity Assessments. Hier beschränken wir uns der Einfachheit halber auf zwei:
Wenn der Hersteller (oder Importeur, oder Händler) seine Konformität selbst nachweist, nennt man das “internal production control”, in der Richtlinie 768/2008/EC als “Module A” bekannt.
Bei bestimmten Produkten und Anforderungen sind die Regeln aber strikter, und dann muss die Konformität durch eine unabhängigen Stelle nachgewiesen werden — das heißt dann “EC type examination” oder “Module B”. Diese unabhängige Stelle nennt man in der CE-Welt “notified body”, weil sie von einem “notifying body” gegenüber der EU benannt (“notified”) wurde.

Weniger verklausuliert: Die unabhängigen Prüfstellen, also die “notified bodies” sind zum Beispiel Unternehmen der TÜV-Gruppe.
“Notifying bodies” sind in Deutschland die zuständigen Ministerien.
Und dann gibt es noch “accreditation bodies” die dafür sorgen, dass die unabhängigen Prüfstellen nach bestimmten Kriterien akkreditiert werden, in Deutschland ist das die Deutsche Akkreditierungsstelle (DAkkS). Für alle EU-Mitgliedsstaaten kann man in der NANDO-Datenbank nachsehen, wer “notifying bodies”, “notified bodies” und “accreditation bodies” sind.

Für welche Produkte gilt der Cyber Resilience Act?

Das mit dem CE-Kennzeichen haben wir nun verstanden, jetzt zur Security und dem Proposal für den Cyber Resilience Act (2022/0272/COD). Der CRA-Entwurf nutzt den ganzen bestehenden Rechtsrahmen zum CE-Kennzeichen (grau in der untenstehenden Grafik) und ergänzt ihn um eine CE-Kennzeichnung für Security-Eigenschaften (blau in den folgendenden Grafiken).

Zunächst muss dafür die Produktklasse definiert werden, auf die die Security-Anforderungen zutreffen. Das sind die “products with digital elements”, grob übersetzt “alles mit Datenverbindung”:

“This regulation applies to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.” — CRA, Article 2

Darunter fällt vom gewöhnlichen Smartphone über den smarten Toaster bis hin zur Industrie-Firewall so ziemlich alles. Deswegen gibt es auch noch zwei weitere Unterklassen, die “critical products with digital elements” oder “Class I” sowie die “highly critical products with digital elements” oder “Class II”. In Annex III des CRA ist definiert, was genau in welche Klasse fällt, aber für uns ist erst mal relevant zu wissen: Die “(highly) critical products with digital elements” ist die Kategorie, wo wir unsere OT wiederfinden: Microcontroller und -prozessoren, IACS (Industrial Automation and Control Systems) nach IEC-62443-Definition, IIoT (Industrial Internet of Things), Roboter und Smart Meter.

Außerdem wird der Cyber Resilience Act hier verzahnt mit der ebenfalls noch im Entwurf befindlichen NIS-2-Richtlinie, denn auch digitale Geräte, die in “essential entities” gemäß NIS-2 zum Einsatz kommen — zu Deutsch: in kritischen Infrastrukturen — zählen im CRA als “(highly) critical”.

Damit ist der CRA ein Gesetzesentwurf, der explizit OT-Komponenten und kritische Infrastrukturen adressiert.

Welche Anforderungen stellt der CRA an digitale Produkte?

Jetzt geht’s ans Eingemachte: Wir werfen ein Blick darauf, was so ein CE-gekennzeichnetes “product with digital elements” können muss. Und das liest sich tatsächlich wie frisch vom Wunschzettel der Supply-Chain-Risiken-geplagten Security-Community.

In Annex I des CRA sind sogenannte “essential requirements” definiert. Sie sind unterteilt in Anforderungen zu Security-Produkteigenschaften und zum Schwachstellenmanagement.

Fangen wir an mit den Produkteigenschaften, die teils eher Eigenschaften der Produktentwicklung sind: Die digitalen Produkte müssen während der Entwicklung einer Risikoanalyse unterzogen werden, sie dürfen keine ausnutzbaren Schwachstellen beinhalten, und dann kommt eine recht übliche, aber deshalb nicht weniger sinnvolle, Litanei an Forderungen: Unter anderem secure by default-Konfigurationen, Zugriffsschutz, CIA, Datensparsamkeit, Härtung, Logging und Monitoring — und die Forderung danach, dass Schwachstellen durch Security-Updates behebbar sein müssen.

Interessant wird es bei den Schwachstellenmanagementanforderungen. Ein SBOM in maschinenlesbarem Format, Schwachstellen müssen “ohne Verzögerung” behoben und öffentlich kommuniziert werden, ein “Responsible-Disclosure-Verfahren” für Schwachstellen muss eingeführt werden, es muss regelmäßige Schwachstellen-Tests geben, und Security-Updates müssen unverzüglich, über einen sicheren Kanal, kostenlos und inklusive Security-Advisory geliefert werden. Schwachstellen müssen übrigens an die ENISA gemeldet werden —Sie erinnern sich? Die betreibt ja das CERT-EU. Der Cybersecurity Act lässt grüßen.

Halten wir fest: Wenn das alle Hersteller so leben, haben wir schon viel erreicht.

Auch an die “technical documentation”, die beim CE-Kennzeichen ja sowieso Pflicht ist, stellt der CRA in Annex V detaillierte Anforderungen: Neben Architekturzeichnungen, dem bereits erwähnten SBOM und der technischen Details zum Update-Mechanismus ist auch eine Risikoanalyse beizulegen.

Wohlklingend, aber vage? Darum gibt es die Vermutungswirkung

Es stimmt natürlich: Besonders die “essential requirements”, die wir gerade kurz gelistet haben, klingen wunderbar, sind aber viel zu generisch, um sie wirklich zu prüfen.

Deswegen kommen wir zur letzten wichtigen Vokabel für heute und läuten damit auch gleich den Ausblick ein.

Achtung, Juristensprech: Es gibt die “Presumption of conformity” oder die “Vermutungswirkung”. Weil die “essential requirements” zu viel Interpretationsspielraum für die Prüfung beinhalten, behilft sich die EU mit Querverweisen. Man verweist auf konkretere Anforderungen aus anderen Dokumenten, bei deren Erfüllung angenommen (“vermutet”) wird, dass man dann auch die “essential requirements” des CRA erfüllt.

Diese Querverweise sind vor allem Standards — aber nicht irgendwelche, sondern solche, die von der EU explizit als “harmonisierte Standards” veröffentlicht wurden. Solche Standards müssen von CEN/CENELEC herausgegebene europäische Normen (EN) sein. Es gibt solche harmonisierten Standards schon für andere Bereiche des CE-Kennzeichens, aber noch nicht für Security. Eine Liste kann man hier einsehen.

Wenn es keine geeigneten Standards gibt, kann die EU selbst Ersatz definieren, das sind dann “common specifications”.

Und — auch hier sehen wir wieder, warum der Cybersecurity Act als Wegbereiter so wichtig ist — wenn man ein Zertifikat gemäß “Cybersecurity certification scheme” (definiert im Cybersecurity Act) durchlaufen hat, hat auch diese Zertifizierung Vermutungswirkung für die CE-Konformitätserklärung.

Ausblick: Welche Standards machen das Rennen?

An der Stelle wird’s also zukünftig noch mal richtig spannend. Schon länger schauen Hersteller etwas ratlos auf die verschiedenen Security-Standards, die wiederum teils mehrere Zertifizierungsschemata haben, und fragen sich, auf welches Pferd sie setzen sollen.

Wer die Antwort darauf sucht, weiß also nun immerhin, wohin er schauen muss: Welche europäischen Normen werden von der EU als “harmonisierte Standards” veröffentlicht? Und welche Zertifizierungsschemata werden unte dem Cybersecurity Act erarbeitet?

Es gibt einige potenzielle Anwärter für Standards und Zertifizierungsschemata mit Vermutungswirkung, zum Beispiel:

• die EN ISO/IEC 15408 (Common Criteria),
• die prEN 17640 (Fixed time cybersecurity evaluation methodology for ICT products), die maßgeblich vom BSI vorangetrieben wird,
• die EN IEC 62443–4–1, EN IEC 62443–4–2 und möglicherweise zukünftige darauf aufbauende Profile für bestimmte Produktgruppen,
• die Evaluierungsmethoden in IEC 62443–6-x (noch keine EN),
• EN 303645 (Cyber Security for Consumer Internet of Things: Baseline Requirements).

Zahnloser Tiger oder echter Fortschritt?

Ich höre ihn schon, den Chor der Nörglerstimmen, der jedes Gesetz zur Cybersecurity begleitet: Zu wenig, zu lasch, zu spät, und überhaupt ein zahnloser Tiger.

Und klar, das kann man alles bemängeln. Seit 2018 gibt es gesetzliche Pflichten für Betreiber kritischer Infrastrukturen, und die Pflichten für Hersteller sind 2022 immer noch nicht da — auf EU-Ebene. Wenn der Cyber Resilience Act beschlossen wird, wird er 24 Monate später für die EU-Mitgliedsstaaten bindend, muss also nationales Recht umgesetzt werden und dann gibt es für die Hersteller auch wieder Übergangsfristen. Das dauuuuuert.

Andererseits: Das Timing ist nicht schlecht. Die Supply-Chain-Vorfälle der letzten Jahre und auch die nun schon eine Weile geltende Regulierung für KRITIS-Betreiber haben dafür sensibilisiert, dass Cybersecurity-Regeln für Hersteller notwendig sind. Eine verpflichtende CE-Kennzeichnung ist kein Pappenstiel. Hat man keine, darf man sein Produkt nicht mehr verkaufen, und hat man eine, aber erfüllt die Anforderungen nicht, drohen laut aktuellem Entwurf Strafen bis zu 15 Mio € bzw. 2,5% des weltweiten jährlichen Umsatzes. Damit so ein Unterfangen eine Chance hat, braucht es ein breites Bewusstsein dafür, dass es ohne nicht geht.

Außerdem braucht es die notwendigen Technologien. Ein Beispiel: Die Idee des SBOM (Software Bill of Materials) ist noch nicht so alt, und die Lösungen entstehen gerade erst. Es jetzt verpflichtend in den Cyber Resilience Act aufzunehmen, ist sportlich — vor ein paar Jahren wäre es nicht möglich gewesen.

Was unterm Strich bleibt: Es geht los und es geht in die richtige Richtung. Security als Teil des CE-Kennzeichens wäre nicht länger eine Produkteigenschaft, die Hersteller ja “wirklich gern einbauen würden, wenn die Kunden bereit wären, dafür zu zahlen”, sondern einfach ein Muss.

Und für das Erwachsenwerden der Disziplin Security wäre der Cyber Resilience Act ein echtes Meilensteinchen. Schaut her, sagt er nämlich, digitale Produkte sind so sicherheitsrelevant wie Medizinprodukte, Sonnenbrillen, Spielzeug und Druckbehälter. Und damit sie “sicher” sind, müssen sie “secure” sein. Zugriffsschutz und Security by Design direkt neben UV-Schutz, Schutz vor elektromagnetischer Strahlung und Explosionsschutz. Klingt gut, hm?

Dieser Beitrag ist als Teil des monatlichen “Security-Briefing für Hard Hats” erschienen.