Cyber Resilience Act für OEMs: Vom Compliance-Nachweis zum Lifecycle-Service

Hi und herzlich willkommen, liebe Freunde von IoT. Das ist euer Podcast über die reale Umsetzung von IoT. Ich bin eure Gastgeberin Madeleine Mickeleit, gelernte Maschinenbauingenieurin. Und heute sprechen wir über ein Thema, das für viele von euch und viele Hersteller gerade zu einem echten Problem wird. Es geht um den europäischen Cyber Resilience Act, kurz CRA. Viele von euch haben davon vielleicht schon etwas gehört. Deshalb starten wir heute mit Fakten und Definitionen anhand eines echten Beispiels: Danfoss, ein dänisches Familienunternehmen, das Antriebstechnik, Kühlsysteme und weitere Industriemaschinen herstellt.

Und wir wollen heute Fragen beantworten wie: Welche Use Cases sind für den CRA relevant? Wie wird er in eure Architektur integriert? Wir versuchen, das Ganze nicht zu technisch zu erklären, also keine Sorge. Und was kostet das eigentlich, welche Business Cases stecken dahinter, und wie arbeitet man dabei mit Partnern zusammen, zum Beispiel mit seinen Cloud-Partnern und Ähnlichem.

Und heute nehmen wir mit einem Unternehmen auf, das ich, glaube ich, seit über einem Jahr nicht mehr im Podcast hatte: unserem Partner Cumulocity, früher bekannt als Software AG. Und heute mit Miguel Morales, er ist Vice President Cloud Alliances bei Cumulocity. Und wie immer findet ihr alle Informationen zur Umsetzung dieses und anderer Projekte auf iotusecase.com. Auch Kontakte und Quellen findet ihr in den Shownotes. Hi Miguel, schön, dass du da bist.

Miguel

Ich freue mich, hier zu sein. Danke.

Schön, dass du heute dabei bist. Lass uns direkt mit dir starten, Miguel, und deiner Rolle. Du bist Vice President Cloud Alliances bei Cumulocity. Was bedeutet das, und wie bist du in diese Rolle gekommen? Du hast ja auch schon bei anderen großen Unternehmen gearbeitet. Das würde mich wirklich interessieren.

Miguel

Die Rolle als Vice President of Strategic Cloud Alliances konzentriert sich auf die globalen Allianzen mit den Hyperscalern. Also konkret Microsoft, AWS und Google. Wir setzen gemeinsam auf deren Infrastruktur auf, integrieren uns mit ihren Lösungen und arbeiten kommerziell mit ihnen zusammen, um genau solche schwierigen Themen wie CRA-Compliance zu lösen, über die wir heute sprechen.

Und dahin gekommen bin ich, würde ich sagen, durch eine Reihe unglücklicher Ereignisse. Oder glücklicher, oder unglücklicher, je nachdem. Ich bin bei Texas Instruments groß geworden, acht Jahre lang im Bereich Embedded Systems. Ich war also immer irgendwo zwischen Mikrocontrollern und eingebetteten Mikroprozessorsystemen unterwegs. In letzter Zeit werde ich wieder mehr zum Ingenieur. Offiziell bin ich 2015 ins IoT gewechselt und bin einem Startup namens Exosite aus Minneapolis beigetreten.

Cool.

Miguel

Für ein Industrieunternehmen namens Parker Hannifin. Dort bin ich als Vice President of IoT auf Konzernebene eingestiegen und habe mit den Geschäftsbereichen zusammengearbeitet, um IoT-Lösungen zu kommerzialisieren. Dabei hatte ich Berührung mit der Umsetzung auf Azure IoT, mit Lizenzierung, Elevate Licensing, Litmus Automation – Unternehmen, die aus meiner Sicht wirklich gute Arbeit in dieser Branche leisten. Danach bin ich vier Jahre zu Microsoft und Azure IoT gewechselt und habe dort mit OEMs und Betreibern an Deployment-Systemen gearbeitet.

Passt perfekt zu unserem heutigen Thema. Miguel, bevor wir einsteigen, lass mich dich kurz vorstellen. Du leitest also die globalen Allianzen von Cumulocity mit den Hyperscalern. Mit welchen genau, übrigens? Das beantwortest du uns vielleicht gleich noch. Deine Karriere hast du bei Texas Instruments begonnen, rund acht Jahre im Bereich Embedded Systems. 2015 bist du mit dem Startup Exosite ins IoT gewechselt, wo du den Parker-Hannifin-Account so stark ausgebaut hast, dass man dich als Vice President of IoT auf Konzernebene geholt hat. Von dort aus warst du vier Jahre bei Microsoft Azure IoT und hast direkt mit OEMs und Betreibern gearbeitet. Wie lange bist du jetzt schon bei Cumulocity, und was bedeutet der CRA für dich heute?

Miguel

Ich bin jetzt seit drei Jahren bei Cumulocity. Das war großartig. Ich habe im Vertrieb angefangen und im Laufe der Zeit wirklich zu schätzen gelernt, welche Kraft ein Partnerkanal für unsere Wachstumsstrategie hat. Und ehrlich gesagt habe ich durch den CRA auch eines der aus meiner Sicht wichtigsten Themen unserer Branche entdeckt.

Der Grund für all diese Wechsel ist mir eigentlich erst letztes Jahr klar geworden: Wir steuern auf eine Art schöne neue Welt unbegrenzter Fähigkeiten zu. Und der CRA war für mich so etwas wie der erste Lehrmeister dabei. Beim Beschäftigen mit dem CRA wurde mir klar, dass Autonomie sich erst Vertrauen verdienen muss, bevor sie sich Befugnisse verdient. Und was anfangs wie „Mensch, schau dir diese CRA-Anforderungen an" wirklich herausfordernd oder sogar lästig wirkte, hat sich meiner Meinung nach als ziemlich zeitgemäß und passend für die Richtung erwiesen, in die sich die Branche bewegt. Diese Leidenschaft spiegelt sich auch in unseren Partnerschaften mit den Hyperscalern wider, mit einem starken Fokus darauf, OT-Security zu verankern und diese Gelegenheit zu nutzen, um für die kommende Zeit zu modernisieren.

Alles klar. Zunächst würde mich interessieren, wie ihr mit AWS, Google und Microsoft integriert und ausrollt, denn manche Zuhörer denken vielleicht, dass Cumulocity mit den Hyperscalern konkurriert. Es wäre also gut zu verstehen, wie ihr tatsächlich mit ihnen zusammenarbeitet, wie du gerade schon die Partnerschaft angesprochen hast. Und das könnte auch für Leute interessant sein, die mit Microsoft oder anderen Hyperscalern arbeiten und wissen wollen, wie sie Assets und Features von Cumulocity nutzen können. Ich denke, dazu kommen wir gleich noch im Zusammenhang mit dem CRA.

Und übrigens, dein Bild vom Lehrmeister hat mir richtig gut gefallen, das war ein wirklich wichtiger Punkt. Aber bevor wir weitermachen, lass mich das Thema kurz einordnen, oder lass uns das Thema gemeinsam einordnen, damit alle beim CRA auf dem gleichen Stand sind. Tatsächlich hat mich jemand aus unserer Community gefragt, ob wir nicht eine Top-10-Liste mit Maßnahmen oder Überlegungen dazu zusammenstellen könnten, weil Hersteller je nach Wissensstand und Unternehmensgröße gerade an sehr unterschiedlichen Punkten stehen. Meinst du, das könnten wir heute schaffen?

Miguel

Auf jeden Fall, auf jeden Fall. Wir sagen zum CRA immer wieder: Der EU Cyber Resilience Act ist eine Regulierung mit zwei wichtigen Terminen. September dieses Jahres, also September 2026, und dann die vollständige Durchsetzung ab Dezember 2027. Er verpflichtet Hersteller vernetzter Produkte, die Cybersicherheit ihrer Assets zu managen, und verlangt einen Nachweis darüber. Ab September müsst ihr aktiv ausgenutzte oder ausnutzbare Schwachstellen innerhalb von 24 Stunden nach Entdeckung an die zuständigen Behörden in Europa melden und den weiteren Umgang mit dem Vorfall dann fristgerecht nachverfolgen.

Er reguliert also sozusagen die Produkte der Hersteller, wobei Produkt hier ein Software- oder Hardwareprodukt inklusive der zugehörigen Fernverarbeitungslösungen für Daten meint, richtig? Wenn ich also Hersteller bin und ein Produkt oder ein digitales Produkt verkaufe, ist das für mich relevant.

Miguel

Genau. Und er ist so etwas wie eine Schwesterregulierung zu einigen anderen, von denen ihr vielleicht schon gehört habt, über die wir heute aber nicht sprechen, die aber auch relevant sind – zum Beispiel der Data Act. Worüber wir heute sprechen, ist die Beziehung zwischen dem Hersteller des Produkts und der NIS2-Compliance-Anforderung auf Kundenseite.

Der EU-CRA verlangt vom Hersteller also, Nachweise über Schwachstellen zu liefern und Patches zum Download oder Rollout bereitzustellen. NIS2 ist die Betreiberseite der Gleichung. Dort heißt es: Ihr kauft Produkte, und ihr müsst nachweisen, dass ihr diese Produkte betreibt und eure Cybersicherheitslage als Betreiber aufrechterhaltet.

Genau. Und beide sind zwei zentrale Säulen der europäischen Cybersicherheitsstrategie. Wie du sagst, reguliert NIS2 eher die Betreiber, also die Endnutzer, die zum Beispiel ein digitales Projekt oder Produkt nutzen, etwa eine Hersteller-Cloud oder ein vernetztes Produkt eines Herstellers. Und der CRA reguliert das, was wir gerade besprochen haben, also das Herstellerprodukt selbst, richtig?

Miguel

Genau. Und ich hoffe, ihr nehmt mehr als nur eine Sache aus diesem Podcast mit, aber ich würde sagen ...

Das ist das Erste, was ihr euch merken müsst.

Miguel

Das Erste ist: Ihr müsst CRA-Compliance nicht nur als Compliance-Initiative behandeln. Es steckt eine kommerzielle Chance darin, die den ROI eures Compliance-Projekts wirklich beschleunigen kann. Und sie liegt genau an der Schnittstelle dieser beiden Welten, der CRA-Anforderungen und der NIS2-Anforderungen. Das ist es, was ich vermitteln möchte.

Dazu kommen wir gleich, und du hast gerade das Compliance-Projekt angesprochen. Viele, die den Podcast hören, wissen ja, dass ich immer neugierig bin, aus der Praxis zu lernen. Bevor wir weitermachen: Kannst du uns ein Kundenbeispiel aus eurem Ökosystem nennen? Ich weiß, ihr habt jede Menge Kunden und Partner. Übrigens, schaut euch auch die Website an, dort gibt es viele Partner im Cumulocity-Umfeld. Aber vielleicht können wir ein konkretes Projekt eines Herstellers herausgreifen, das hier passt, damit wir das etwas praxisnäher besprechen können, wenn du weißt, was ich meine.

Miguel

Klar. Du hast es ja eingangs schon erwähnt: Danfoss hat ein Cybersecurity-Paper zu den DrivePro-Produkten veröffentlicht, letztes Jahr.

Zunächst einmal: Danfoss ist zum Beispiel Hersteller von Antrieben oder Kühlsystemen. Ihre Produkte sind also im Feld bei ihren Kunden im Einsatz. Was sind da die Use Cases?

Miguel

Genau. Danfoss ist ein sehr diversifiziertes Unternehmen, sie haben – ich glaube, sie nennen es die Climate Solutions Group, das ist im Prinzip der HLK-Bereich – und der Antriebsbereich macht einen erheblichen Teil ihres Produktportfolios aus. Wir sprechen hier von einer industriellen Automatisierungs- beziehungsweise Aktorkomponente, die Motoren antreibt.

Diese Produkte unterlagen eine Zeit lang dem Standard IEC 62443, einem Engineering-Standard, der sicherstellt, dass der Entwicklungsprozess sicher ist und dass die Produkte selbst je nach Design und Verifizierung bestimmte Sicherheitsstufen nachweisen können. Was der CRA obendrauf hinzufügt, ist die Anforderung, das an den Markt zu koppeln: Um es künftig in Europa verkaufen zu dürfen, müsst ihr über euer SBOM nachweisen, welche Software ausgeliefert wird, und die Meldepflichten erfüllen – damit es keine Sicherheit durch Verschleierung mehr gibt, Schwachstellen geteilt werden und alle davon profitieren.

Verstehe. Das, was du hier beschreibst, sind also eher die technischen Use Cases, würde ich sagen – Dinge wie das Ausrollen der neuesten Firmware oder das lückenlose Festhalten, was wann aktualisiert wurde. Das ist dann, würde ich sagen, der Audit-Log-Teil. Das sind im Grunde auch Produktfeatures, die verschiedene IoT-Lösungen dafür anbieten, und Unternehmen wie ihr verkaufen sie als Teil ihrer Plattform. Ich finde, das sollte man hier klar benennen, denn wenn ihr gerade zuhört und euer Unternehmen etwas Ähnliches macht oder braucht, könnt ihr euch schon jetzt denken: Ah okay, das betrifft uns auch.

Wenn ihr sehen wollt, wie Cumulocity das technisch konkret unterstützt: Es gibt eine eigene Seite zu CRA- und NIS2-Compliance auf der Website, die verlinken wir euch in den Shownotes, wenn ihr mehr erfahren wollt. Auf einige dieser konkreten Features kommen wir später in der Episode noch zu sprechen, bleibt also dran. Aber schauen wir uns jetzt den eigentlichen Business Use Case dahinter an. Was ist bei Danfoss konkret der geschäftliche Grund, all das ihren Endkunden anzubieten?

Miguel

Ja, also stellt euch vor: Danfoss verkauft als Hersteller an Endkunden, für die NIS2-Compliance verpflichtend ist. Das heißt, deren Endkunden müssen nachweisen, dass sie Cybersicherheit managen. Danfoss sagt dann: Hey, lass es mich dir leicht machen. Hier ist das Cybersecurity-Paper zu den Standards, die unser Design bestimmen. Und es gibt drei Ebenen: die Antriebe, das Gateway und die IoT-Plattform. Als IoT-Plattform nennen sie im Whitepaper Cumulocity.

Das packe ich übrigens auch in die Shownotes, falls ihr euch das Whitepaper anschauen wollt.

Miguel

Ja, gerne, danke. Im Grunde können ihre Kunden, wenn sie ein Danfoss-Produkt mit DrivePro kaufen, sich darauf verlassen, dass sie von einem einfachen Rollout der jeweils neuesten Firmware-Version profitieren. Sie sehen, ob sie Updates vornehmen müssen, um compliant zu bleiben. Und sie haben den Nachweis dafür, die Audit-Logs, die zeigen, wann etwas installiert wurde. Für einen NIS2-Betreiber ist das extrem wertvoll, weil NIS2 mit persönlicher Haftung verbunden ist.

Und wenn ich mir das überlege: Wenn ich ein Unternehmen besäße und persönlich rechtlich haftbar für die Einhaltung dieser Regulierung wäre, würde ich mehr wollen als nur das Wort meines Teams, dass wir uns an Cybersicherheit halten. Genau da liegt aus meiner Sicht die Chance für ein Unternehmen wie Danfoss zu sagen: Wir geben euch den Nachweis, wir geben euch das Tooling, das sicherstellt, dass wir die jeweils neuesten Software-Sicherheitspatches ausrollen und diese Disziplin einhalten, die wir im Whitepaper veröffentlichen. Für mich ist das ein echter Wert. Das ist ein Stück Sicherheit.

Ich glaube, wir werden künftig deutlich mehr solcher Whitepapers sehen, deutlich mehr solcher Services von Unternehmen, die die Chance erkennen, zusätzlich zu ihrer Hardware einen Service zu verkaufen – um genau diese Sicherheit und den Nachweis zu liefern, wie ihre Geräte in der Betreiberumgebung gepflegt werden.

Okay, lass mich das für mich noch mal ordnen und zusammenfassen. Was du gerade beschrieben hast, sind, würde ich sagen, die technischen Use Cases. Also auf den drei Ebenen – Antriebe, Gateway und IoT-Plattform – habt ihr einfache Firmware-Updates und Audit-Logs als Nachweis.

Ich denke da zum Beispiel an einen Kunden von Danfoss, etwa ein Wasserwerk. Ich habe gerade auf deren Website nachgesehen, und Wasser und Abwasser wird dort tatsächlich als eine der Branchen genannt. Sie setzen viele dieser Motorantriebe ein, um Pumpen und Förderbänder im Feld bei ihren Kunden anzutreiben. Und sie könnten sagen: Okay, lieber Kunde, wir machen dir das Leben leicht. Wir zeigen dir automatisch, ob deine Pumpe sicher ist, und stellen sicher – wir schicken dir Updates, sobald etwas behoben werden muss.

Und der Anlagenbetreiber ist derjenige, der unter NIS2 persönlich haftet. Wenn Danfoss ihm also diesen Nachweis und einfache Firmware-Updates liefert, ist das eine wirklich nützliche Hilfe für jemanden, der das sonst für jeden einzelnen Antrieb selbst nachweisen müsste. Wo verläuft da die Grenze zwischen dem, was ein Hersteller wie Danfoss laut CRA tun muss, und dem, was für diese Kunden zusätzlich zur Chance wird?

Miguel

Ja, es lohnt sich, eine Grenze zu ziehen zwischen dem, was notwendig ist, und dem, was die Chance ist. Notwendig für die Compliance ist, dass ihr eure SBOMs veröffentlicht, eure Software Bill of Materials – im Grunde alles, woraus eure Firmware besteht –, dass ihr aktive Exploits veröffentlicht und ausnutzbare Schwachstellen offenlegt, sie dann patcht und den Patch bereitstellt.

Aber ehrlich gesagt, da hört der CRA auf. Ihr könnt die Firmware auf einer Website veröffentlichen und sagen: Schaut regelmäßig auf diese Website nach Firmware-Updates und rollt sie dann aus. Die NIS2-Betreiber dagegen müssen nachweisen, wie sie die Cybersicherheit ihrer gesamten Flotte über alle unterschiedlichen Produkte hinweg, die sie einkaufen, aufrechterhalten. Und die meisten Betreiber haben eine große Vielfalt an OEM-Produkten im Einsatz.

Genau das ist die Lücke. Wenn ihr diese Lücke schließen wollt und sagt: Ich stelle das nicht nur auf einer Website bereit, sondern gebe euch ein Tooling, das zeigt, wie ihr das in eurer bei mir gekauften Flotte ausrollt, und liefere auditierbare Nachweise, die ihr für den eigenen Compliance-Nachweis nutzen könnt – das ist die Chance, die sich am Markt kommerzialisieren lässt. Wenn ihr das besser und einfacher hinbekommt, ist das ein Differenzierungsmerkmal, eine Umsatzquelle. Und ich glaube, genau das übersehen viele, wenn sie beim CRA nur an die gesetzliche Pflicht denken.

Ja, absolut. Wenn wir jetzt an die kommerzielle Seite denken: Hast du in eurem Ökosystem schon Unternehmen gesehen, die aus dieser Compliance-Arbeit tatsächlich einen bezahlten Service gemacht haben? Also etwas, wofür der Kunde extra zahlt? Viele Unternehmen testen das ja gerade erst und lernen dazu, besonders mit den anstehenden CRA-Fristen. Hat schon jemand damit tatsächlich Geld verdient?

Miguel

Grob gesagt sehe ich die Wertströme von IoT-Programmen entweder als internen Nutzen, also die Optimierung interner Abläufe, oder als externe Umsätze. Und im Wertstrom der externen Use Cases, also wenn ihr anfangt, das Produkt zu verkaufen – die Grundlage für beides, intern wie extern, ist eigentlich, dass ihr Fernzugriff braucht, Telemetriedaten sammeln müsst, die Geräte aktualisieren können müsst und ein gewisses Sicherheitsniveau wollt. Und jetzt koppeln die Regulierungen den kommerziellen Verkauf an Compliance.

Die erste Stufe, die wir bei unseren Kunden sehen, ist, dass sie die Software einfach lizenzieren, aber nicht kostenpflichtig. Sie liefern die Software aus, aber mit einer Lizenz, die besagt: Ihr erlaubt uns, Daten zu sammeln, damit wir euch besser bedienen können, wenn ihr uns kontaktiert. Um dann den nächsten Schritt zu gehen und die Software zu bepreisen, müsst ihr verstehen, welches Risiko ihr für den Kunden reduziert, und das dann bepreisen. In diesem Fall ist das das Compliance-Risiko des NIS2-Betreibers.

Und einer der Top-10-Punkte, die im Dokument stehen, das am Ende des Podcasts auch zum Download bereitsteht, ist: Stellt drei euren Betreibern eine Frage. Welchen Nachweis braucht ihr für euer nächstes Audit? Und was würdet ihr dafür zahlen, diesen Nachweis nicht selbst zusammenstellen zu müssen? Das ist nicht meine Recherche, das ist eure Möglichkeit zu prüfen, ob meine These für euch als OEM zutrifft. Fragt eure Kunden, die eure Geräte betreiben: Welchen Nachweis braucht ihr, und wie viel würdet ihr zahlen, um diesen Nachweis nicht selbst zusammenstellen zu müssen? Was, wenn ich euch das einfach für all meine Produkte mitliefere?

Das ist die Chance. Klärt mit euren Kunden, wie der Austausch aussehen soll und wie das funktionieren wird. Ich glaube, ihr lernt dabei viel über diese Risikolücke, die den Weg von der kostenlosen Lizenzierung vernetzter Produkte als Mehrwert hin zu einer bepreisten Softwarelizenz aufzeigt. Und darüber hinaus könnt ihr anfangen, Ergebnisse zu verkaufen. Sobald ihr genug Nachweise darüber gesammelt habt, wie eure Geräte bei euren Kunden performen, könnt ihr anfangen, Ergebnisse oder Security as a Service zu verkaufen. Zum Beispiel: Ich kann garantieren, dass meine Produkte immer zu 90 % auf der neuesten Firmware laufen. So könnt ihr bei den Service Level Agreements kreativer werden und mehr von diesem Wert abschöpfen.

Das ist so etwas wie die Reifekurve. Der erste Schritt erfordert einfach nur Compliance. Der nächste Schritt erfordert die Lizenz. Der nächste Schritt erfordert die Bepreisung des Risikos. Und dafür braucht ihr wiederum ausreichend Nachweise, um die Chance zu haben, Ergebnisse zu kommerzialisieren.

Oh, das ist wirklich ein spannender Punkt. Du sagst also: Findet heraus, welches reale Risiko ihr dem Kunden abnehmt, und bepreist auf Basis dieses Werts. Das nehme ich tatsächlich mit in unsere nächste Community-Session, das ist wirklich interessant, und ich frage mal die Leute, wie sie das sehen. Aber wenn du hier von Risiko sprichst, meinst du dann so etwas wie eine Security-Versicherung, oder ist das breiter gefasst?

Miguel

Ja, es gibt Risiko im Versicherungssinn. Aber ich glaube, in den meisten Fällen verkauft man nicht unbedingt einen Security-Service, einen Security-Lifecycle-Service – das halte ich zwar durchaus für auf den CRA anwendbar –, wenn man Risiko als Betriebsrisiko interpretiert. Wie hoch ist die Wahrscheinlichkeit, dass derjenige, der die Fritteusen im Schnellrestaurant bedient, sie so pflegt, wie sie es bräuchten? Dass er den Filter wechselt, das Öl sauber hält? Ich greife hier auf ein anderes Kundenbeispiel zurück, aber das Risiko ist ziemlich hoch.

Wenn der Hersteller dem Anlageneigentümer und dem P&L des Betreibers nachweisen kann, dass sich dieser Betrieb verbessern lässt, reduziert er reales monetäres Risiko, oder? Denn das Projekt wurde mit bestimmten Annahmen aufgesetzt, und das Risiko, dass diese Annahmen im Feld nicht eintreten, ist bis zu einem gewissen Grad genau das, was man bepreisen kann. Und in unserem Fall sprechen wir dabei einfach nur über Cybersicherheitsrisiko.

Aber wenn ich von der Bepreisung von Risiko spreche, ist der häufigere Fall meiner Meinung nach: Statt eines Freemium-Modells, bei dem es hier coole Features und dort weniger coole Features für die Basisversion gibt, müsst ihr die Plattform mit eurer eigenen Definition von Risiko ausstatten, das ihr für den Endkunden zu mindern glaubt. Dann müsst ihr euch selbst davon überzeugen, dass ihr dieses Risiko tatsächlich mindert, und habt dann die Chance, es zu bepreisen. Ich glaube, das ist ein wachsender Trend bei Hardware-Herstellern: die Bepreisung von Softwareservices. Ich sehe das bei einem Großteil unserer Kunden mit vernetzten Produkten, die schon länger als drei Jahre bei uns sind. Sie erreichen den Punkt, an dem sie genug Nachweise gesammelt haben und die Risikolücke verstehen, die sie schließen können, und fangen dann an, ihre Lifecycle-Services zu kommerzialisieren.

Bin ich als Hersteller übrigens im Rahmen des CRA nur für die Kernfunktion des Geräts verantwortlich? Oder geht es auch um alles, was ich mit meiner Cloud verbinde? In welchem Raum bewege ich mich da als Hersteller, denn um mein vernetztes Produkt herum gibt es ja einen Vorher- und einen Nachher-Prozess?

Miguel

Das Produkt selbst trägt die CE-Kennzeichnung, richtig? Die Hardware trägt diese CE-Kennzeichnung. Und es gibt unterschiedliche Risikostufen. Die meisten Produkte sind eigentlich selbstzertifiziert. Je nach Risikoklasse könnt ihr dann auf der ENISA-Website nachsehen, dort werden sie als wichtige Geräte, Klasse eins, Klasse zwei, oder kritische Geräte eingestuft. Und es geht letztlich darum, wie nah man an das ist, was man Infrastruktur nennen könnte, also was passiert, wenn bei bestimmten Geräten etwas Schlimmes passiert. Das solltet ihr auf jeden Fall wissen, denn sobald ihr in Klasse zwei oder kritisch landet, braucht ihr eine Zertifizierung durch Dritte.

Und der Umfang dessen, was zertifiziert wird, umfasst die Hardware und die dazugehörige Lösung. Dazu gehört auch euer Device-Management-Produkt. Ihr müsst den gesamten Prozess beschreiben können, mit dem ihr Schwachstellen überwacht, eure SBOMs generiert, die VEX-Dateien erstellt, sie einreicht und dann in eure Flotte ausrollt, um zu verstehen, welche Updates nötig sind und wie ihr diese bereitstellt. Das kann überwältigend wirken, wenn das nicht schon Kernbestandteil eures Geschäfts ist. Wenn ihr heute kein Medizintechnikunternehmen seid, fühlt sich das für manche industriellen OEMs oder andere OEMs vielleicht neu an.

Deshalb veröffentlichen wir ein Referenzdesign. Es gibt ein Whitepaper, das wir gemeinsam mit EY Legal in Deutschland geschrieben haben, Cumulocity und EY Legal Deutschland, das auf unserer Website verfügbar ist. Und im Rahmen meiner Arbeit habe ich das Vergnügen, dieses Referenzdesign in die verschiedenen Hyperscaler-Ökosysteme einzubinden. Genau dort arbeiten wir zusammen. Microsoft ist eines der weltweit größten Unternehmen für Enterprise-IT-Sicherheit. Sie bieten Firmware-Scanning, rollenbasierte Zugriffskontrolle, Audit-Signaturtechnologie und so weiter. Genau dort arbeiten wir mit den Hyperscalern zusammen, an diesem Referenzdesign, das ihr schon heute nutzen könnt.

Wir haben außerdem ein Professional-Services-Paket, das wie eine einmonatige Bestandsaufnahme funktioniert. Wir befragen euer Team, ermitteln, wo ihr über eure gesamte Flotte hinweg heute steht, und geben Empfehlungen. Das ist im Grunde eine ausführlichere Version meiner Top-10-Liste, die ihr nutzen könnt, um CRA-compliant zu werden, und die dann verfügbar sein wird.

Okay, das eben erwähnte Whitepaper packe ich in die Shownotes, schaut es euch gerne an, wenn ihr mehr erfahren wollt. Bevor wir zur Top-10-Liste kommen, lass uns das Ganze noch mal Schritt für Schritt durchgehen, damit wir verstehen, wie das konkret funktioniert. Nehmen wir an, in eurer Produktsoftware wird eine Schwachstelle entdeckt. Was passiert dann? Was tun Kunden, und wie helft ihr ihnen dabei, eher aus technischer Sicht?

Miguel

ENISA selbst hat, würde ich sagen, seit der Veröffentlichung des ursprünglichen CRA-Texts deutlich bessere Arbeit geleistet. Sie haben kürzlich ein Dokument veröffentlicht – ich glaube, es ist noch im Entwurf, geht aber Richtung finaler Fassung –, das sich mit den Prinzipien Secure by Design und Secure by Default beschäftigt. Das sind die beiden übergeordneten Konzepte, die sie darlegen wollen. Und in diesem Dokument werden sie relativ konkret dabei, was das eine vom anderen unterscheidet. Auf meiner Liste steht deshalb definitiv: Verbindet euch mit dieser Website, beobachtet sie und interpretiert sie für euch selbst.

Dazu gehört: Ihr müsst eure gesamte Firmware scannen lassen. Und ich glaube, ihr braucht dafür fast schon ein kontinuierliches Scanning, weil heute laufend neue Schwachstellen auftauchen und ausgenutzt werden – etwa 30 % davon schon innerhalb des ersten Tages. Die durchschnittliche Zeitspanne zwischen Ausnutzung einer Schwachstelle und dem Patch liegt bei minus sieben Tagen. Im Schnitt werden Schwachstellen also sieben Tage ausgenutzt, bevor sie gepatcht sind. Die Branche muss hier also aufholen: kontinuierliches Scanning.

Zum Beispiel meine Antriebe oder meine Gateways oder was auch immer ich als Hardware im Feld bei den Kunden habe.

Miguel

Oh ja. Stellt euch ein Gateway in eurem Antrieb vor – dann hat das Gateway Software, euer Gateway und euer Antrieb haben Software. Ihr seid dafür verantwortlich, nachzuweisen, dass die Software, so wie ihr sie ausliefert, beim Kunden installiert oder per Firmware-Update aktualisiert, keine bekannten ausnutzbaren Schwachstellen aufweist.

Das ist ziemlich interessant. Es gibt nämlich einen Unterschied – ich nutze Linux, Linux hat Schwachstellen, und ausnutzbare Schwachstellen, denn diese Lücke ist eure Design-Entscheidung. Die Zahl der tatsächlich ausnutzbaren Schwachstellen muss abgeglichen werden. Dafür gibt es Tools. Es gibt interne Prozesse, mit denen ihr festlegt, was eine ausnutzbare Schwachstelle ist, und eine sehr lange Liste bekannter Schwachstellen darauf abbildet, was auf eurem Gerät tatsächlich ausnutzbar ist. Ihr seid nur dafür verantwortlich, das zu kommunizieren, was aktuell ausgenutzt wird oder ausnutzbar ist. Genau da sehe ich Kunden gerade daran arbeiten: wie sie Ausnutzbarkeit definieren und was sie der Regulierungsbehörde tatsächlich in dem, glaube ich, VEX-Datei genannten Dokument veröffentlichen müssen.

Okay. Übrigens, wenn ihr mehr über Security by Design erfahren wollt: Dazu gibt es bereits eine Episode von mir, und wir haben auch viele Partner, die sich darauf spezialisiert haben. Darauf gehen wir in diesem Podcast nicht weiter ein, aber wenn ihr interessiert seid, verlinke ich euch in den Shownotes auch die entsprechende Podcast-Episode dazu.

Miguel

Die höre ich mir auch an. Diese Schwachstellen gelten dann für die Software Bill of Materials einer bestimmten Firmware-Distribution. Und die wird auf eine bestimmte Gerätemenge ausgerollt. Also OEM, Marke, Modell, Version hat compliant-konforme Firmware-Versionen – und veraltete Firmware-Versionen, die diese Schwachstellen weiterhin enthalten.

Der OEM muss also nachweisen können, dass er für jede verkaufte Marke-Modell-Version innerhalb einer bestimmten Frist eine Firmware bereitstellt, die die Schwachstelle behebt. Das ist eine Anforderung. Und wenn ihr das ausrollen könnt, wie einfach lässt sich das gestalten? Genau da kommt eine IoT-Plattform ins Spiel.

Ja, genau das wollte ich gerade fragen. Wie mache ich das auf der IoT-Plattform? Zum Beispiel: Dieser Kunde hat Cumulocity als Datenbank genannt, aber ich habe vielleicht auch andere IoT-Plattformen im Einsatz. Wie stelle ich sicher, dass das CRA-konform ist? Zum Beispiel, dass ich Multi-Faktor-Authentifizierung habe oder meine Datenspeicherung passt? Hast du Beispiele, wie ich diese Ebene managen kann?

Miguel

Ja. Im Grunde hat der CRA, glaube ich, so um die 50 verpflichtende Klauseln. Wenn ihr euch den Text durchlest, stehen da rund 50 Zeilen mit „das müsst ihr tun, das müsst ihr tun". Ich unterteile die in prozedurale Anforderungen – also Dinge, für die ihr einen Bericht einreichen müsst – und in plattformseitig umsetzbare Anforderungen.

Cumulocity zielt auf die plattformseitig umsetzbaren Anforderungen ab, also Dinge wie: Ihr braucht eine sichere Identität auf dem Gerät, um es zu authentifizieren, bevor es auf eure Plattform zugreift. Cumulocity unterstützt dafür PKI-Zertifikate, die regelmäßig rotiert werden müssen. Ihr müsst die Firmware zum Download bereitstellen – wir können die Firmware nicht nur bereitstellen und sagen: Okay, hier ist sie, verfügbar, sondern Cumulocity sorgt auf Wunsch auch dafür, dass sie einfach über alle passenden Marke-Modell-Versionen ausgerollt wird, und wir liefern die Audit-Logs, die zeigen: Diese Firmware wurde an diesem Datum an diese Geräte ausgeliefert. Die Geräte melden dann zurück, ob das Firmware-Update erfolgreich war oder nicht. Und wir müssen die Geräte, bei denen es nicht geklappt hat, nachbessern, damit sie auf den passenden Stand kommen. Das ist der Teil, der bei großem Umfang wirklich anspruchsvoll werden kann.

Das ist der Wert einer IoT-Plattform wie Cumulocity, wenn man einen solchen Service verfügbar machen will, besonders für OEMs, denn die verkaufen global. Es geht hier nicht um ein einzelnes Werksgelände, in dem ihr das Netzwerk kontrolliert, sondern um weltweit verteilte Geräte. Diesen Service global verfügbar zu machen, die Verfügbarkeit sicherzustellen, die Services so zu gestalten, dass sie auch Randfälle abfangen – das ist alles fest in die Cumulocity-IoT-Plattform eingebaut, und davon profitieren OEMs, weil sie das nicht selbst entwickeln müssen. Sie können sich auf die differenzierenden Aspekte konzentrieren: welche Nachweise sie für ihre Kunden brauchen, oder die Wertversprechen, die sich aus sicheren, verifizierten Gerätedaten für Insights und Prozessverbesserungen ergeben.

Letztlich ist jedes Gerät dafür verantwortlich, seine sichere Identität, seinen Build-Zustand, seinen Laufzeitzustand und sein Umfeld zu melden. Ich nenne das das BRE-Modell. Also: Sag mir deine Identität, und ist sie aktuell – meist ein PKI-Zertifikat. Welche Firmware solltest du eigentlich fahren? Läufst du wirklich diese Firmware, wenn man einen Hash über die Laufzeitumgebung bildet, oder hat jemand etwas eingeschleust? In welchem Netzwerk befindest du dich? Welche Konfiguration hast du? Das sind die Daten, die eine Plattform abgleichen muss, um Compliance kontinuierlich zu berechnen. Ich belasse es dabei, aber ich glaube, das ist die große Verschiebung: weg von der jährlichen Compliance-Prüfung hin zu der Fähigkeit, kontinuierlich nachzuweisen, welche Geräte compliant sind und welche nicht, und automatisch die dafür nötigen Nachweise zu erzeugen.

Okay, um das zusammenzufassen: Die große Verschiebung ist der Wechsel weg von einer jährlichen Compliance-Prüfung hin zu einer kontinuierlichen, automatischen Nachweisführung, Gerät für Gerät. Und noch eine Frage, bevor wir endlich zur Top-10-Liste kommen: Wie funktioniert das eigentlich konkret zwischen euch und dem Hyperscaler? Wer macht was, und wie greift das ineinander?

Miguel

Ich glaube, das ist bei jedem Hyperscaler unterschiedlich. Ich kann darüber sprechen, worin Cumulocity wirklich stark ist. Letztlich verwalten wir die Sicherheitslage des Geräts. Alle Firmware-Updates, alle Identitäts-Updates – wir orchestrieren diese Updates über eine vielfältige, weltweit verteilte Flotte aus großen, kleinen und mittleren Geräten. Das ist die Rollout-Seite der Gleichung.

Mit den Hyperscalern arbeiten wir auf zwei Arten zusammen. Sie haben gehostete Infrastruktur bei vielen dieser OEMs und Betreiber. Diese haben oft schon eine erhebliche Investition oder Verpflichtung gegenüber diesen Hyperscalern, ein bestimmtes Volumen an Azure, AWS oder Google abzunehmen. Wir machen Cumulocity daher im jeweiligen Marketplace käuflich verfügbar. Wenn ihr also eine Azure-Verpflichtung habt und Cumulocity kauft, zählt die gesamte Lizenz auf diesen Verbrauch an. Es gibt also einen Anreiz, mit den Hyperscalern zusammenzuarbeiten und sicherzustellen, dass wir uns mit deren Produkten integrieren.

Microsoft hat Entra für rollenbasierte Zugriffskontrolle, um zu steuern, wer welche Änderungen an der Plattform vornehmen darf. Microsoft hat das Firmware-Scanning-Tool, mit dem sich Schwachstellen identifizieren und den entsprechenden Geräten in der Flotte zuordnen lassen. Sie haben die Audit-Logs. Microsoft kann die Zertifizierungsstelle sein, die die Identitäten generiert oder signiert, die ihr auf eure Geräte ausrollt. Das hängt also vom Fall ab. Bei Google geht es eher um Datenintegration und Sicherheitsinfrastruktur. Es kommt also auf den Hyperscaler an, aber im Kern verbinden wir uns mit den bestehenden Diensten unserer Kunden und liefern die Orchestrierungsebene, mit der wir nachweisen, dass die Geräte konform aktualisiert werden.

Okay, lass uns das zusammenführen. Bisher haben wir über Dinge gesprochen wie: euer SBOM veröffentlichen – also eure Software Bill of Materials, im Grunde die vollständige Liste aller Softwarekomponenten in eurem Produkt. Sicherheit von Anfang an in euer Produkt einzubauen. Kontinuierlich nach Problemen zu scannen und herauszufinden, welche Schwachstellen tatsächlich gefährlich sind.

Du hast außerdem etwas gesagt, das bei mir hängen geblieben ist: Fragt euren eigenen Kunden, welchen Nachweis er für das nächste Audit braucht. Das ist wirklich ein guter Punkt. Und was er dafür zahlen würde, das nicht selbst zusammenstellen zu müssen. Und das ist ein zentraler Punkt: den Patch selbst kostenlos zu lassen, aber den Nachweis und das Tracking drumherum als Service zu verkaufen. Vieles davon klingt schon nach unserer Top-10-Liste, also können wir vielleicht endlich dazu kommen. Wie sieht die vollständige Top-10-Liste aus, und was sind aus deiner Sicht die zehn wichtigsten Maßnahmen?

Miguel

Der erste Punkt, den ich noch nicht erwähnt habe: Holt es sofort aus der Rechtsabteilung raus.

Alles klar. Warum das?

Miguel

Das war einfach ein Muster im letzten Jahr. Ich rede mit einem Kunden und sage: Erzähl mir von eurer CRA-Initiative. Und die Antwort ist dann: Ach, das liegt noch bei der Rechtsabteilung. Und ich sage: Okay, das muss in die Produkt-P&Ls überführt werden, denn es ist ein Business-Continuity-Risiko für die P&Ls. Wir müssen also Verantwortlichkeit schaffen, die von der Rechtsabteilung unterstützt und informiert wird, was ihr sagen dürft. Aber die P&Ls müssen die Compliance verantworten.

Und nicht nur ein P&L, sondern strategisch übergreifend – Punkt zwei: Schaut über eure gesamte Produktflotte, denn vielleicht gibt es Best Practices, die ein Produktteam bereits umgesetzt hat und die sich auf andere Teile eures Portfolios übertragen lassen. Ihr müsst sicherstellen, dass ihr eine Monitoring-Infrastruktur für das Scanning und die SBOM-Generierung habt, fest integriert als Kernfunktion eurer Software- und Firmware-Entwicklung. Denn ihr müsst nicht nur schnell reagieren, um Schwachstellen zu patchen, sondern auch, um compliant zu bleiben und sie innerhalb von 24 Stunden melden zu können.

Also die Automatisierung dieser Nachweise. Kunden arbeiten gerade daran, herauszufinden, wie sie Schwachstellen in ausnutzbare Schwachstellen übersetzen, denn diese Lücke ist entscheidend, damit ihr nicht Schwachstellen veröffentlicht, die für euer Produkt gar nicht relevant sind. Da der September-Termin bald ansteht, solltet ihr sicherstellen, dass eure Meldewege feststehen.

Ja, kurz zur Klarstellung: Der September-Termin ist die frühere Frist, ab der Hersteller bereits melden müssen, wenn eine Sicherheitslücke oder Ähnliches auftritt.

Miguel

Genau. Sie müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden. ENISA baut dafür eine zentrale Meldeplattform auf. Was müsst ihr innerhalb von 24 Stunden tun, was innerhalb von 72 Stunden, was innerhalb von 15 Tagen? Es braucht eine Offenlegungsrichtlinie, eine Kontaktstelle. Ihr müsst wissen, an wen in eurem Land ihr das melden müsst. Ihr müsst also genau verstehen, wohin die Dokumentation ab dem 11. September 2026 fließen wird.

Und ihr braucht jemanden, der die Entwicklungen bei ENISA im Blick behält, denn die veröffentlichen ihre eigene Interpretation der Regulierung fortlaufend, um zu zeigen, worauf sie achten werden. Bisher wurde noch niemand auditiert. Auch wenn sich ihre Interpretation noch etwas verschieben mag, bleiben die Grundlagen immer gleich: Ihr müsst wissen, was in eurem Produkt steckt, ihr müsst es beobachten, ihr müsst es beheben, ihr müsst es nachweisen. Aber ihr solltet beobachten, wann ENISA ihr Secure-by-Design- und Secure-by-Default-Playbook fertigstellt. Und sobald die Website der zentralen Meldeplattform verfügbar ist, müsst ihr das noch am selben Tag wissen.

Legt eure Support-Zusagen schriftlich fest. Und auch das gehört wieder in die P&Ls. Denn übrigens: Die Bereitstellung der Patches muss kostenlos sein. Der kommerzielle Teil ist die Bereitstellung des Nachweises für euren Kunden. Aber das alles muss laut Regulierung kostenlos angeboten werden, und ihr müsst es fünf Jahre lang dokumentieren. Das müsst ihr in eure ROI- und Programmrechnung einbauen.

Sorgt dafür, dass ihr die Updates auch tatsächlich ausliefern könnt – dabei kann Cumulocity helfen. Und stellt sicher, dass allen klar ist, wo eure Compliance-Pflichten enden und wo die kommerzielle Chance beginnt. Also noch mal: Fragt eure Kunden, welchen Nachweis sie für die Compliance brauchen und wie viel sie zahlen würden, wenn ihr ihnen das liefert, statt dass sie es selbst zusammenstellen müssen. So könnt ihr meine These zur ROI-Rechnung selbst überprüfen. Ich stelle euch dafür eine Art grob gehaltenen ROI-Rechner bereit.

Das wäre schön.

Miguel

Was kostet mich das alles heute, und was passiert, wenn ich das durch eine großartige IoT-Plattform ersetze und damit sogar Umsatz erzielen kann? Ich sehe ROI-Rechnungen mit dem Vier- bis Achtfachen an Rendite, je nachdem, wie viel ihr aus diesen heute noch sehr manuellen, personalintensiven Prozessen herausoptimieren könnt.

Okay, das ist cool. Ich habe nicht jeden Punkt mitgezählt – haben wir schon zehn?

Miguel

Es sind zehn. Ja, ihr seht sie im herunterladbaren PDF auf der Website.

Okay, schaut euch das unbedingt an. Die Community hatte ja auch danach gefragt – bitte sehr, da ist es. Zum Abschluss noch eine Frage mit Blick nach vorn: Glaubst du, dass CRA-Compliance in fünf Jahren einfach ein Standardfeature bei jedem IoT-Plattformanbieter wie euch, Cumulocity, sein wird, oder auch OEMs das out of the box verkaufen können? Oder braucht jedes Unternehmen dafür weiterhin ein eigenes, maßgeschneidertes Projekt? Was ist deine Einschätzung?

Miguel

Ich glaube, Cybersicherheit ist so etwas wie der Fingerabdruck eines Geräts. Wenn ihr ein Gerät entwickelt, hat es einen Fingerabdruck, und diese Form bestimmt, auf welchen unterschiedlichen Ebenen es ausgenutzt werden könnte – ob auf Anwendungs-, Netzwerk-, Zugriffs- oder Rollout-Ebene. Deshalb glaube ich, dass Cybersicherheit ein maßgeschneidertes, produktspezifisches Thema bleiben wird. Aber die Prinzipien, die Abläufe des, sagen wir, Software-Entwicklungs- und Rollout-Lebenszyklus im großen Maßstab ...

Zum Beispiel, ob ein Update erfolgreich war oder nicht – das könnte so ein Punkt sein.

Miguel

Oh ja, wie ein fehlgeschlagenes A/B-Update, oder jemand zieht während eines Updates den Stecker. Diese Szenarien sind so branchenspezifisch, dass ich glaube, die Cybersicherheit auf niedriger Ebene, also auf Geräteebene, wird spezifisch bleiben. Aber die Fähigkeit eines Unternehmens, Cybersicherheit zu managen und der eigenen Führungsebene sowie der des Kunden Nachweise über das Cybersecurity-Programm zu liefern, wird meiner Meinung nach zum Standard werden. Ja, das wird erwartet werden. Und aus dem Markt gedrängt wird das meiner Meinung nach nicht von den Regulierungsbehörden, sondern von den Angreifern, die alles ausnutzen können, was das nicht bietet.

Cybersicherheit war früher so etwas wie ein Differenzierungsmerkmal, ein Nerd-Thema. Aber in einer Welt, in der KI die US-Regierung oder Regierungen weltweit hacken kann und man das zurückhält, weil es zu mächtig ist – wenn man fünf Jahre vorausdenkt, sind IoT-Geräte das ideale Ziel. Vielleicht haben sie heute noch nicht die Transparenz und Disziplin, um sicherzustellen, dass jeder weiß, welches IoT-Asset im Netzwerk vorhanden ist. Deshalb sind sie ein perfektes, ein bevorzugtes Angriffsziel für diese Angreifer. Und ich glaube, KI wird uns ziemlich schnell zeigen, wer eine vollständig automatisierte, modernisierte, agile Cybersicherheitsinfrastruktur hat und wer nicht – und genau das werden die Unternehmen sein, die überleben. Die anderen Produkte, glaube ich, wird man einfach nicht mehr nutzen können.

Alles klar. Danke dir. Das war jetzt einfach eine kleine Frage zur Zukunft. Ich hoffe, du bleibst mit unserem Netzwerk verbunden. Vielleicht sehen wir uns in einem weiteren Podcast wieder, oder bei einem unserer User-Group-Meetups, denn die Leute sprechen viel über dieses, aber auch über andere Themen. Also, ich würde mich freuen, wenn du mit dem Netzwerk verbunden bleibst und wieder von dir zu hören.

Miguel

Das würde ich sehr gerne. Ich habe unser Gespräch heute wirklich genossen. Und ich hätte als junger Mensch nie gedacht, dass ich mal so leidenschaftlich für Regulierung und Compliance brennen würde, aber hier bin ich, und ich finde, das ist ein entscheidendes Thema, das die Branche richtig angehen muss. Ich würde mich sehr freuen, weiter Teil des Austauschs zu sein.

Perfekt. Und vielen Dank für all deine Einblicke heute, auch für das konkrete Kundenbeispiel, das macht es gleich viel praxisnäher. Danke für deine Zeit und dieses Gespräch heute. Ich gebe dir gerne das letzte Wort zum Abschluss, aber von meiner Seite: vielen Dank für deine Zeit und unser heutiges Gespräch.

Miguel

Vielen herzlichen Dank. Mein letztes Wort: Der CRA ist ein Schritt auf dem Weg hin zu autonomeren Systemen. Es ist ein notwendiger Schritt. Und der Grund, warum ich im IoT bleibe, ist, dass wir vernetzte Lösungen entwickeln müssen, die sich Vertrauen verdienen, bevor sie sich die Befugnis zum Handeln verdienen. Ich bleibe in dieser Branche, bei Cumulocity und in der Zusammenarbeit mit den Hyperscalern, weil ich an diese Mission glaube, und ich hoffe, eure Zuhörer schließen sich mir auf diesem Weg an und sorgen dafür, dass vernetzte Lösungen sich Vertrauen verdienen, bevor sie sich die Befugnis verdienen, autonom zu handeln.

Perfekt, das gefällt mir. Euch allen einen schönen Rest der Woche. Bye bye.

Miguel

Danke dir. Bye.