Cyber Resilience Act 2027 für KVM-Systeme in Leitstellen

KVM-Systeme bilden in vielen Leitstellen den zentralen Bedienpfad zwischen Mensch und kritischer Anwendung. Der Cyber Resilience Act macht deshalb nicht an Servern, Firewalls oder klassischen IoT-Geräten halt. Auch KVM-Matrizen, Extender, Encoder, Decoder, Managementserver und ihre Firmware können als Produkte mit digitalen Elementen erfasst sein. Für Betreiber wird damit die Herkunfts-, Update- und Nachweiskette zum Beschaffungskriterium.

Das Wichtigste in Kürze

• Die Hauptpflichten des europäischen Cyber Resilience Act gelten ab 11. Dezember 2027. Die Meldepflichten für Hersteller nach Artikel 14 beginnen bereits am 11. September 2026.
• Erfasst werden nicht nur Produkte mit Internetzugang. Eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz kann genügen. Damit können auch klassische KVM-Technologien in den Anwendungsbereich fallen.
• Die Hauptverantwortung liegt beim Hersteller. Bei Produkten aus Drittstaaten erhält der EU-Einführer eigene Prüf- und Nachweispflichten.
• Wer OEM-Technik unter dem eigenen Namen oder der eigenen Marke verkauft, wird nach Artikel 21 selbst zum Hersteller – einschließlich der Pflicht, aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden.
• Der Hersteller des gesamten KVM-Produkts bleibt auch für integrierte Hardware- und Softwarekomponenten verantwortlich. Dazu gehören beispielsweise Embedded-Betriebssysteme, Webserver, Bibliotheken, Netzwerkcontroller und Updatekomponenten.
• Eine CE-Kennzeichnung ist kein unabhängiges EU-Cybersicherheitsgütesiegel. Entscheidend sind die produktbezogene Risikobewertung, technische Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung.
• Der Verordnungsgeber benennt in Erwägungsgrund 58 ausdrücklich nichttechnische Risikofaktoren: Gerichtsbarkeit des Herstellers, Eigentümerstruktur und Staatsnähe im Herkunftsland.
• Barco CTRL bringt als Plattform eines europäischen Herstellers eine ungewöhnlich weit dokumentierte Ausgangslage mit: Security by Design, Zero Trust, TLS 1.2/1.3 und mTLS, Identitätsmanagement, MFA, ABAC, Audit Logging, Secure Development, Penetrationstests, ein eigenes PSIRT sowie ein ISO/IEC 27001:2022-zertifiziertes Managementsystem mit jährlichen externen Audits.
• Betreiber sollten CRA-Nachweise nicht erst 2027 anfordern. KVM-Systeme werden langfristig geplant und häufig weit über fünf Jahre genutzt.

Hinweis: Dieser Beitrag bietet eine technische und redaktionelle Einordnung mit Rechtsstand 4. August 2026. Er ist keine Rechtsberatung und ersetzt weder die Prüfung des konkreten Produkts noch die rechtliche Bewertung eines Liefer- oder Integrationsmodells.

Warum der CRA gerade bei KVM-Systemen relevant ist

Eine KVM-Infrastruktur überträgt Keyboard-, Video- und Mouse-Signale zwischen Bedienplatz und Quellsystem. In einer Leitstelle ist sie damit wesentlich mehr als Zubehör: Sie entscheidet, welcher Operator welche Anwendung sehen und bedienen kann.

Je nach Architektur kann die KVM-Lösung unter anderem Folgendes umfassen:

• KVM-Matrix oder Switching-Core,
• KVM-Extender, Encoder und Decoder,
• Netzwerk- und IP-Gateways,
• zentrale Managementserver und Datenbanken,
• Weboberflächen und administrative Clients,
• Embedded-Betriebssysteme und Firmware,
• Schnittstellen zu Active Directory oder anderen Identity Providern,
• Monitoring-, Logging- und Fernwartungsfunktionen,
• Update-Server oder cloudbasierte Dienste.

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt nach Artikel 2 Absatz 1 für Produkte mit digitalen Elementen, deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Eine Internetverbindung ist dafür nicht erforderlich.

Das ist für die KVM-Technik entscheidend: Auch eine proprietäre Matrix mit optischen oder elektrischen Verbindungen kann ein Produkt mit digitalen Elementen sein. „Nicht IP-basiert“ bedeutet daher nicht automatisch „außerhalb des CRA“.

Die entscheidenden Termine

Termin	Bedeutung für die KVM-Lieferkette
10. Dezember 2024	Der CRA ist in Kraft getreten.
11. Juni 2026	Kapitel IV (Artikel 35 bis 51) gilt: Benennung und Notifizierung von Konformitätsbewertungsstellen.
11. September 2026	Die Meldepflichten nach Artikel 14 gelten. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden.
11. Dezember 2027	Die wesentlichen Produkt-, Dokumentations-, Konformitäts- und Lieferkettenpflichten werden anwendbar.

Die EU-Kommission hat am 27. Juli 2026 zusätzliche Leitlinien veröffentlicht. Sie präzisieren unter anderem den Anwendungsbereich, wesentliche Änderungen, Unterstützungszeiträume, Risikobewertungen und Meldepflichten.

KVM ist nicht gleich KVM: Architektur entscheidet

Klassische KVM-Matrix

Eine klassische, proprietäre KVM-Matrix kann Quellsysteme und Bedienplätze physisch oder logisch voneinander trennen. Werden keine allgemeinen IP-Netze genutzt, verringert dies bestimmte netzwerkbasierte Angriffswege. Trotzdem bleiben CRA-relevante Fragen:

• Besitzt die Matrix administrierbare Firmware?
• Welche Schnittstellen sind für Konfiguration und Service vorhanden?
• Wie werden Benutzer und Berechtigungen verwaltet?
• Sind Updates signiert und offline einspielbar?
• Wie werden Schwachstellen erkannt, bewertet und behoben?
• Wie lange liefert der Hersteller Sicherheitsupdates?
• Welche Komponenten und Bibliotheken sind in der Firmware enthalten?

Eine physische Trennung kann ein wirkungsvolles Sicherheitsmerkmal sein. Sie ersetzt aber kein dokumentiertes Schwachstellen- und Produktlebenszyklusmanagement.

KVM over IP und KVM over IT

Bei KVM over IP werden Video- und Bediensignale über IP-Netze transportiert. KVM over IT geht darüber hinaus und integriert die KVM-Plattform nativ in vorhandene IT-Dienste wie Identitätsmanagement, DNS, DHCP, NTP, Monitoring, Syslog, VDI oder APIs.

Diese Integration erweitert den Funktionsumfang, vergrößert jedoch auch die Zahl der Abhängigkeiten und Schnittstellen. Gleichzeitig ermöglicht sie zentrale Sicherheitsfunktionen, die in isolierten KVM-Inseln oft nur eingeschränkt verfügbar sind:

• Multi-Faktor-Authentifizierung,
• zentraler Entzug von Benutzerrechten,
• rollen- oder attributbasierte Zugriffssteuerung,
• Zertifikatsmanagement,
• verschlüsselte und gegenseitig authentifizierte Kommunikation,
• zentrale Audit-Protokollierung,
• geregeltes Patch- und Versionsmanagement,
• Integration in SIEM und Netzwerkmonitoring.

Die richtige Frage lautet daher nicht „IP oder nicht IP?“, sondern:

Ist die konkrete KVM-Architektur über ihren gesamten Lebenszyklus sicher beherrschbar, transparent dokumentiert und organisatorisch eindeutig verantwortet?

Mehr zu den technischen Grundlagen finden Sie bei controlrooms unter KVM-Switches und KVM-Matrizen, KVM-Extender und Barco CTRL – KVM over IT für Leitstellen.

Das eigentliche Risiko: die OEM- und Firmware-Lieferkette

Viele KVM-Produkte entstehen nicht vollständig bei dem Unternehmen, dessen Logo auf dem Gehäuse steht. Hardwareplattform, FPGA-Design, Netzwerkcontroller, Embedded Linux, Webserver oder Updatekomponenten können von unterschiedlichen Lieferanten stammen. Bei Private-Label-Produkten wird ein System eines OEM unter einer anderen Marke vertrieben.

Eine typische Lieferkette kann so aussehen:

OEM und Komponentenlieferanten in Drittstaaten
                         ↓
       europäischer Markeninhaber / Private Label
                         ↓
               EU-Einführer / Distributor
                         ↓
                  KVM-Systemintegrator
                         ↓
            Leitstellen- oder Kontrollraumbetreiber

Rechtlich gilt der CRA herkunftsneutral: Die Regeln greifen für alle Produkte, die auf dem EU-Markt bereitgestellt werden. Der Verordnungsgeber hat allerdings gesehen, dass Herkunft und Eigentümerstruktur sehr wohl ein Risiko begründen können – und das ausdrücklich in den Verordnungstext geschrieben.

Was der CRA selbst zu Anbietern mit hohem Risiko sagt

Erwägungsgrund 58 des CRA hält fest, dass Abhängigkeiten von risikoreichen Anbietern ein strategisches Risiko darstellen können, „insbesondere wenn die Produkte mit digitalen Elementen für die Verwendung durch die […] wesentlichen Einrichtungen bestimmt sind“ – also genau für jene Betreiber kritischer Infrastruktur, die Leitstellen betreiben.

Als Kriterien nennt der Verordnungsgeber wörtlich:

• die für den Hersteller geltende Gerichtsbarkeit,
• die Merkmale seines Unternehmenseigentums,
• von Kontrolle bestimmte Beziehungen zur Regierung eines Drittlands, in dem er niedergelassen ist,

und dies „insbesondere wenn das Drittland Wirtschaftsspionage betreibt oder unverantwortliches staatliches Verhalten im Cyberspace an den Tag legt und seine Gesetze einen willkürlichen Zugang zu Geschäftsvorgängen oder Unternehmensdaten jeglicher Art […] ermöglichen und unter Umständen nachrichtendienstliche Verpflichtungen auferlegen, ohne dass es demokratische Schutzmechanismen, Kontrollmechanismen, ordnungsgemäße Verfahren oder das Recht auf Anrufung eines unabhängigen Gerichts gibt“.

Diese nichttechnischen Risikofaktoren sind bei der Bestimmung eines erheblichen Cybersicherheitsrisikos ausdrücklich zu berücksichtigen. Nach Artikel 19 Absatz 3 muss ein Einführer die Marktüberwachungsbehörden sogar dann unterrichten, wenn er allein aufgrund nichttechnischer Risikofaktoren Grund zu der Annahme hat, dass ein Produkt ein erhebliches Cybersicherheitsrisiko darstellen könnte. Zusätzlich dürfen Mitgliedstaaten nach Erwägungsgrund 13 nationale Beschränkungen für Produkte oder Anbieter festlegen, die nichttechnischen Faktoren Rechnung tragen.

Für die Beschaffung heißt das: Wer eine Leitstelle ausstattet, darf die Eigentums- und Rechtsverhältnisse hinter einem Produkt abfragen. Das ist keine Überregulierung, sondern die vom Gesetzgeber vorgesehene Prüfrichtung.

Die praktischen Nachweisfragen

• Ist der tatsächliche Entwickler der Firmware bekannt und vertraglich erreichbar?
• Wer besitzt und schützt die Signierschlüssel für Firmwareupdates?
• Kann der EU-Vertragspartner Sicherheitsupdates selbst bereitstellen oder ist er vollständig vom OEM abhängig?
• Gibt es eine koordinierte Schwachstellenoffenlegung und einen erreichbaren Product-Security-Kontakt?
• Sind verwendete Open-Source- und Drittkomponenten nachvollziehbar?
• Werden neue Schwachstellen auch nach dem Verkaufsende überwacht?
• Können Updates ohne Verbindung zu einem ausländischen Cloud- oder Telemetriedienst installiert werden?
• Was passiert bei Herstellerwechsel, Insolvenz, Exportbeschränkung oder Einstellung einer Produktlinie?

Der letzte Punkt ist im CRA sogar eigens geregelt: Nach Artikel 19 Absatz 8 muss ein Einführer die Marktüberwachungsbehörden und die Nutzer informieren, sobald ihm bekannt wird, dass der Hersteller seine Betriebstätigkeit eingestellt hat und seine Pflichten nicht mehr erfüllen kann. Das Ausfallrisiko einer weit entfernten Lieferkette ist damit kein theoretisches Szenario, sondern ein im Gesetz vorgesehener Fall.

Entscheidend ist nicht der Aufdruck auf dem Gerät, sondern die belastbare Antwortkette hinter dem Produkt.

Wer trägt welche CRA-Verantwortung?

1. Der Hersteller

Hersteller ist nicht nur, wer ein Produkt physisch fertigt. Nach Artikel 3 Nummer 13 ist auch jenes Unternehmen Hersteller, das Produkte konzipieren, entwickeln oder herstellen lässt und sie unter seinem Namen oder seiner Marke vermarktet.

Bei einem KVM-System unter der Marke eines Drittstaatenherstellers bleibt dieses Unternehmen Hersteller. Verkauft dagegen ein europäisches Unternehmen dieselbe Technik unter der eigenen Marke, übernimmt dieses Unternehmen die Herstellerrolle. Damit übernimmt es unter anderem Verantwortung für:

• Cybersicherheits-Risikobewertung,
• Erfüllung der grundlegenden Anforderungen,
• technische Dokumentation,
• Konformitätsbewertung und EU-Konformitätserklärung,
• CE-Kennzeichnung,
• sichere Produktkonfiguration,
• Schwachstellenbehandlung und Sicherheitsupdates,
• CRA-Meldungen nach Artikel 14,
• Festlegung und Kommunikation des Unterstützungszeitraums.

Ein weitergereichtes PDF des ursprünglichen OEM ist dafür allein kein belastbarer Ersatz.

Der unterschätzte Punkt dabei ist die Meldefrist. Nach Artikel 21 gilt ein Einführer oder Händler als Hersteller, sobald er ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt – und unterliegt damit den Pflichten der Artikel 13 und 14. Dazu gehört die Frühwarnung über eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntniserlangung. Wer den Quellcode und die Firmware nicht kontrolliert, sondern erst beim OEM in einer anderen Zeitzone nachfragen muss, kann diese Frist strukturell kaum einhalten. Private Label ist damit ab September 2026 keine reine Marketingentscheidung mehr, sondern eine operative Haftungsfrage.

2. Der EU-Einführer

Der Einführer ist das in der EU niedergelassene Unternehmen, das ein Produkt mit der Marke eines außerhalb der EU ansässigen Herstellers erstmals auf dem Unionsmarkt in Verkehr bringt. Nach Artikel 19 Absatz 1 darf es nur konforme Produkte in Verkehr bringen.

Vorher muss der Einführer nach Artikel 19 Absatz 2 sicherstellen, dass:

• das erforderliche Konformitätsbewertungsverfahren nach Artikel 32 durchgeführt wurde,
• die technische Dokumentation erstellt wurde,
• die CE-Kennzeichnung vorhanden ist,
• die EU-Konformitätserklärung und Nutzerinformationen beigefügt sind,
• Hersteller- und Supportinformationen vollständig sind,
• die erforderlichen Unterlagen gegenüber Behörden vorgelegt werden können.

Hat der Einführer Grund zur Annahme, dass das Produkt nicht konform ist, darf er es nicht in Verkehr bringen. Wird ihm später eine Schwachstelle bekannt, muss er den Hersteller unverzüglich informieren; bei erheblichem Cybersicherheitsrisiko kommen weitere Informations- und Korrekturpflichten hinzu.

3. Der Händler

Der Händler muss mit der gebotenen Sorgfalt prüfen, ob Kennzeichnung, Hersteller- und Einführerinformationen, Unterlagen und Unterstützungszeitraum vorhanden sind. Erkennt er eine mögliche Nichtkonformität, darf er das Produkt nicht einfach weiterverkaufen.

4. Der Systemintegrator

Die Rolle des Integrators hängt vom Projekt ab. Installation, Konfiguration und Verbindung konformer Komponenten machen ihn nicht automatisch zum Hersteller. Anders kann es aussehen, wenn er:

• aus Einzelkomponenten ein neues Gesamtprodukt bildet und dieses als eigenes Produkt auf dem Markt bereitstellt,
• das System unter dem eigenen Namen oder der eigenen Marke vertreibt,
• die Zweckbestimmung verändert,
• neue, sicherheitsrelevante Schnittstellen oder Datenflüsse hinzufügt,
• eine wesentliche Änderung an einem bereits in Verkehr gebrachten Produkt vornimmt.

Nach Artikel 22 gilt auch eine Person, die weder Hersteller, Einführer noch Händler ist, als Hersteller, wenn sie eine wesentliche Änderung vornimmt und das Produkt auf dem Markt bereitstellt. Bei komplexen KVM-Gesamtsystemen muss diese Rollenfrage vor Auftragserteilung geklärt werden – nicht erst nach einer Schwachstelle oder einem Vorfall.

5. Der Betreiber

Der CRA richtet seine Hauptpflichten an die Wirtschaftsakteure, nicht an den Betreiber einer Leitstelle. Für den Betreiber bleiben die Nachweise dennoch zentral:

• als Grundlage einer sicheren Beschaffung,
• für das Lieferkettenmanagement nach NIS2 beziehungsweise NISG 2026,
• für Risikoanalysen und technische Freigaben,
• für Patch-, Change- und Incident-Management,
• als Nachweis gegenüber interner Revision, Kunden und Behörden.

Der CRA ersetzt daher nicht die organisatorischen Betreiberpflichten. Er verbessert im Idealfall die Informations- und Sicherheitsbasis der eingesetzten Produkte. Zur österreichischen Betreiberperspektive siehe unsere NIS2-Checkliste für Leitstelle und Kontrollraum.

Was der CRA technisch für ein KVM-System verlangt

Die Anforderungen des CRA sind risikobasiert und technologieneutral. Auf ein KVM-System übertragen, ergeben sich insbesondere folgende Prüffelder.

Sichere Grundeinstellung

Nach Anhang I Teil I muss das Produkt mit einer sicheren Standardkonfiguration bereitgestellt werden, sofern zwischen Hersteller und gewerblichem Nutzer für ein maßgeschneidertes Produkt nichts anderes vereinbart wurde. Für KVM bedeutet das beispielsweise:

• keine universellen oder unveränderten Standardpasswörter,
• nicht benötigte Dienste und Schnittstellen deaktiviert,
• minimale Rechte für Benutzer und Administratoren,
• sichere Erstinbetriebnahme und dokumentiertes Hardening.

Zugriffsschutz und Identitätsmanagement

KVM ist ein privilegierter Zugriffsweg. Die Rechtevergabe sollte deshalb nicht allein auf gemeinsam verwendeten Accounts beruhen. Relevant sind:

• persönliche Benutzeridentitäten,
• rollen- oder attributbasierte Berechtigungen,
• Multi-Faktor-Authentifizierung,
• Trennung von Operator-, Service- und Administrationsrollen,
• geregelte Notfall- und Break-Glass-Zugänge,
• zeitnaher Entzug von Rechten bei Rollenwechsel oder Austritt.

Vertraulichkeit und Integrität

Nicht nur Videodaten, sondern auch Tastatur- und Mausbefehle sowie administrative Kommandos müssen gegen Manipulation und unberechtigten Zugriff geschützt werden. Bei netzwerkbasierten Systemen sind daher authentifizierte und verschlüsselte Kommunikationskanäle, ein belastbares Zertifikatsmanagement und die Trennung von Nutz-, Management- und Servicepfaden zu prüfen.

Verfügbarkeit und Wiederherstellung

In einer Leitstelle kann eine KVM-Störung die Bedienbarkeit kritischer Anwendungen beeinträchtigen. Die Risikobewertung muss daher auch folgende Punkte abdecken:

• Redundanz kritischer Server- und Netzwerkkomponenten,
• definiertes Verhalten bei Verbindungs- oder Authentifizierungsfehlern,
• gesicherte Konfigurationsbackups,
• Wiederanlauf- und Wiederherstellungsverfahren,
• getestete Failover-Szenarien,
• lokale Bedienmöglichkeiten für definierte Notfälle.

Protokollierung

Nachvollziehbar sein sollten mindestens Anmeldungen, fehlgeschlagene Zugriffe, Änderungen von Rollen und Berechtigungen, administrative Änderungen, sicherheitsrelevante Systemereignisse sowie Update- und Wartungsvorgänge. Die Protokolle müssen vor Manipulation geschützt und sinnvoll in das zentrale Monitoring oder SIEM integriert werden können.

Schwachstellen und sichere Updates

Der Hersteller muss Schwachstellen während des Unterstützungszeitraums wirksam behandeln. Für Betreiber sind dabei insbesondere relevant:

• eindeutiger Meldekanal für Sicherheitslücken,
• definierte Triage- und Eskalationsprozesse,
• signierte und auf Integrität geprüfte Updates,
• dokumentierte Release Notes und Security Advisories,
• Offline-Updatefähigkeit für abgeschottete Leitstellen,
• Rollback- oder Wiederherstellungsverfahren,
• Prüfung von Schwachstellen in integrierten Komponenten.

Der Verordnungsgeber erkennt dabei ausdrücklich an, dass automatische Aktualisierungen nicht für alle Umgebungen taugen: Nach Erwägungsgrund 56 gelten die entsprechenden Erwartungen nicht für Produkte, die für den Einsatz in professionellen IKT-Netzen und insbesondere in kritischen und industriellen Umgebungen bestimmt sind, in denen eine automatische Aktualisierung zu Betriebsstörungen führen könnte. Für Leitstellen ist damit ein kontrolliertes, offline einspielbares Updateverfahren regelkonform – die Informations- und Bereitstellungspflicht des Herstellers bleibt davon unberührt.

SBOM: notwendig, aber nicht automatisch für den Kunden sichtbar

Der Hersteller muss Komponenten und Schwachstellen beherrschen. Nach Anhang I Teil II Nummer 1 müssen Hersteller Schwachstellen und Komponenten ermitteln und dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten des Produkts hervorgehen.

Das bedeutet jedoch nicht, dass jeder Käufer automatisch die vollständige SBOM oder die gesamte technische Dokumentation erhält. Diese Unterlagen sind vor allem für die Konformitätsbewertung und Marktüberwachung bestimmt. Leitstellenbetreiber sollten deshalb vertraglich festlegen, welche Informationen sie für das eigene Risikomanagement benötigen, beispielsweise:

• Komponenten- oder Firmwareinventar,
• Liste der unterstützten Versionen,
• Zuordnung veröffentlichter CVEs,
• Security Advisories,
• Nachweis über Drittkomponentenmanagement,
• SBOM-Bereitstellung unter Vertraulichkeitsvereinbarung,
• Reaktionsfristen bei kritischen Schwachstellen.

Für Betreiber ist die SBOM-Pflicht zugleich ein wirksamer Prüfstein: Wer die Firmware seines Produkts nicht selbst entwickelt, sondern als Private Label zukauft, kann eine belastbare Software-Stückliste nur liefern, wenn der OEM sie herausgibt. Die Frage „Zeigen Sie mir Ihre SBOM“ trennt in der Praxis sehr schnell echte Herstellerverantwortung von weitergereichter Dokumentation.

Supportdauer: Fünf Jahre sind nicht automatisch genug

Nach Artikel 13 Absatz 8 beträgt der Unterstützungszeitraum mindestens fünf Jahre. Wird das Produkt voraussichtlich kürzer genutzt, entspricht der Zeitraum der voraussichtlichen Nutzungsdauer. Entscheidend ist aber, dass die Supportdauer die erwartete Nutzungsdauer widerspiegelt.

Die Kommissionsleitlinien vom 27. Juli 2026 stellen dazu klar, dass fünf Jahre nicht als Standardwert zu verstehen sind: Das Minimum wirke lediglich als Absicherung, während der Hersteller den angemessenen Zeitraum anhand der Kriterien des Artikels 13 Absatz 8 selbst bestimmen müsse.

Noch deutlicher wird der Verordnungsgeber in Erwägungsgrund 60. Dort heißt es, dass bei einer vernünftigerweise zu erwartenden Nutzung von mehr als fünf Jahren entsprechend längere Unterstützungszeiträume sicherzustellen sind – „wie dies häufig bei Hardwarekomponenten wie Hauptplatinen oder Mikroprozessoren, bei Netzwerkgeräten wie Routern, Modems oder Switches sowie bei Software wie Betriebssystemen […] der Fall ist“. Und weiter: „Insbesondere Produkte mit digitalen Elementen, die für die Verwendung in industriellen Umgebungen bestimmt sind, wie etwa industrielle Steuerungssysteme, werden häufig über deutlich längere Zeiträume hinweg verwendet.“

Damit ist die Sache für Leitstellen klar. KVM-Systeme, Videowall-Infrastrukturen und Kontrollräume werden häufig zehn Jahre oder länger betrieben. Ein Hersteller kann sich bei einem solchen Produkt nicht auf eine pauschale Fünfjahreszusage zurückziehen.

Für ein KVM-Projekt sollten deshalb die Supportzeiträume aller kritischen Bestandteile aufeinander abgestimmt werden:

• KVM-Software und Managementserver,
• Encoder, Decoder und Extender,
• Embedded-Betriebssysteme,
• Netzwerkkomponenten,
• Datenbank und Hypervisor,
• Zertifikats- und Schlüsselmanagement,
• externe Dienste und APIs.

Sicherheitsupdates, die während des Unterstützungszeitraums bereitgestellt wurden, müssen nach Artikel 13 Absatz 9 nach ihrer Bereitstellung mindestens zehn Jahre oder für die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben – je nachdem, welcher Zeitraum länger ist.

Meldepflichten ab 11. September 2026

Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Artikel 14 Absatz 1 gleichzeitig dem als Koordinator benannten CSIRT und der ENISA melden, und zwar über die einheitliche Meldeplattform der ENISA.

Für aktiv ausgenutzte Schwachstellen gilt:

1. Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung,
2. ergänzende Meldung innerhalb von 72 Stunden,
3. Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht.

Bei schwerwiegenden Sicherheitsvorfällen gelten ebenfalls 24- und 72-Stunden-Stufen; der Abschlussbericht ist innerhalb eines Monats nach Übermittlung der 72-Stunden-Meldung fällig.

Nach Artikel 69 Absatz 3 gelten diese Meldepflichten auch für Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Für Betreiber bedeutet das: Der Vertragspartner muss schon 2026 wissen, wer innerhalb der KVM-Lieferkette eine Schwachstelle bewertet, meldet, behebt und die betroffenen Kunden informiert.

Ist ein KVM-Switch ein „Switch“ im Sinne des CRA?

Diese Frage stellt sich sofort, wenn man Anhang III des CRA liest: Unter den wichtigen Produkten der Klasse I stehen dort „Router, Modems für die Internetanbindung und Switches„. Bedeutet das, dass jeder KVM-Switch automatisch strengeren Verfahren unterliegt?

Nein. Die Durchführungsverordnung (EU) 2025/2392 vom 28. November 2025 liefert die technische Beschreibung der Kategorien und definiert Switches als Produkte, „die die Konnektivität zwischen vernetzten Geräten durch Paketweiterleitungsmechanismen ermöglichen, über eine Managementebene verfügen und die üblicherweise Teil der Sicherungsschicht oder der Vermittlungsschicht sind“. Genannt werden Managed Switches, Smart Switches, Multilayer Switches, Virtual Security Switches, programmierbare SDN-Switches und Bridges.

Ein KVM-Switch leitet keine Netzwerkpakete auf Schicht 2 oder 3 weiter, sondern schaltet Bedien- und Videosignale zwischen Arbeitsplatz und Quellsystem. Die Namensgleichheit ist historisch, nicht funktional. Entscheidend ist ohnehin ein anderer Grundsatz derselben Verordnung: Ein Produkt, das die Funktionen einer gelisteten Kategorie zwar ausüben kann, dessen Kernfunktionen sich davon aber unterscheiden, gilt nicht als Produkt dieser Kategorie.

Ist ein KVM-System ein wichtiges Produkt der Klasse I oder II?

Nicht automatisch. Die Einstufung richtet sich nach der Kernfunktion des Produkts. Ein KVM-System wird nicht allein deshalb zu einem wichtigen Produkt, weil es ein Betriebssystem, einen Netzwerkanschluss oder eine sicherheitsrelevante Bibliothek enthält.

Eine genauere Prüfung ist erforderlich, wenn die Kernfunktion einer der in Anhang III gelisteten Kategorien entspricht:

Klasse I (unter anderem): Identitätsmanagementsysteme sowie Software und Hardware für die Verwaltung privilegierter Zugänge · Netzmanagementsysteme · Produkte mit VPN-Funktion · physische und virtuelle Netzschnittstellen · Betriebssysteme · Router, Modems und Switches · Mikroprozessoren, Mikrocontroller, ASIC und FPGA mit sicherheitsrelevanten Funktionen.

Klasse II: Hypervisoren und Container-Runtime-Systeme · Firewalls, Intrusion-Detection- und Intrusion-Prevention-Systeme · manipulationssichere Mikroprozessoren und Mikrocontroller.

Für die typische KVM-Signalverteilung spricht vieles für die allgemeine Produktkategorie. Übernimmt die Plattform im Kern jedoch Funktionen der Verwaltung privilegierter Zugänge oder eines Netzmanagementsystems, kann Klasse I relevant werden. Die Durchführungsverordnung beschreibt Software für die Verwaltung privilegierter Zugänge als Zugangsverwaltungssystem, „das die Zugangsrechte zu IT- oder OT-Systemen und sensiblen Informationen innerhalb einer Organisation kontrolliert und überwacht“. Die Einstufung muss der Hersteller begründen und dokumentieren.

Die Klassifizierung beeinflusst das Konformitätsverfahren nach Artikel 32:

• Allgemeine Produkte: interne Kontrolle (Modul A) möglich.
• Klasse I: interne Kontrolle nur, wenn harmonisierte Normen, gemeinsame Spezifikationen oder ein europäisches Zertifizierungsschema vollständig angewandt wurden. Andernfalls EU-Baumusterprüfung (Modul B + C) oder umfassende Qualitätssicherung (Modul H) – also mit notifizierter Stelle.
• Klasse II: stets Modul B + C, Modul H oder ein europäisches Zertifizierungsschema mindestens der Vertrauenswürdigkeitsstufe „mittel“.

Barco CTRL: europäischer Hersteller mit belegter CRA-Vorbereitung

Barco CTRL wird als KVM-over-IT-Plattform für die gemeinsame Informationsverteilung an Bedienplätzen und Videowänden entwickelt. Für die CRA-Bewertung zählt zunächst ein struktureller Vorteil, der sich nicht nachrüsten lässt: Barco NV ist ein europäischer Hersteller. Hersteller, Produktverantwortung und behördlicher Ansprechpartner fallen damit zusammen. Es gibt keine Einführerkette, keinen Drittstaaten-OEM hinter der Marke und keine Unklarheit darüber, wer im Sinne der Artikel 13 und 14 verpflichtet ist. Genau jene nichttechnischen Risikofaktoren, die Erwägungsgrund 58 des CRA benennt – fremde Gerichtsbarkeit, undurchsichtige Eigentümerstruktur, staatliche Einflussnahme –, stellen sich hier nicht.

Öffentlich dokumentierte Sicherheitsmerkmale

Laut den offiziellen Barco-CTRL-Produktinformationen basiert die Plattform auf Security-by-Design- und Zero-Trust-Prinzipien, wobei jede Verbindung authentifiziert und jeder Kommunikationskanal mit TLS 1.2 beziehungsweise 1.3 verschlüsselt wird. Die Sicherheitsarchitektur ruht auf fünf Säulen: Identitätsmanagement, Kommunikationsschutz, Systemschutz, Audit Logging und Medienschutz.

Bemerkenswert für dieses Thema: Barco benennt den Cyber Resilience Act selbst als Bestandteil der langfristigen Sicherheitsroadmap – gemeinsam mit ISO 27001 und NIS2. Der CRA ist dort also kein nachträglich aufgesetztes Compliance-Thema, sondern eine eingeplante Entwicklungslinie.

Hinzu kommen nach den veröffentlichten Barco-Unterlagen:

• gegenseitige Zertifikatsauthentifizierung über mTLS,
• Integration in zentrale Identitätsdienste und MFA,
• rollenbasierte und attributbasierte Zugriffskontrolle,
• Audit-Ereignisse für Operator- und IAM-Aktionen sowie Weitergabe an externe Syslog-Systeme,
• Secure Software Development Lifecycle mit Threat Modeling, SAST, SCA, DAST und Schwachstellenscans,
• Einbindung unabhängiger Sicherheitsexperten und Penetrationstests durch Ethical Hacker,
• Responsible-Disclosure-Verfahren und ein eigenes Product Security Incident Response Team,
• Redundanzoptionen für kritische Komponenten.

Die Barco Security Organization beschreibt eine mehrstufige Sicherheitsorganisation mit Security Office, Produktsicherheit und PSIRT. Das Informationssicherheits-Managementsystem ist nach ISO/IEC 27001:2022 zertifiziert; als dritte Verteidigungslinie beschreibt Barco jährliche externe ISO-9001- und ISO-27001-Audits. Damit existiert genau jene unabhängige Kontrollinstanz, die der CRA für die Konformitätsbewertung und die Schwachstellenbehandlung voraussetzt.

Was daraus folgt – und was noch aussteht

Diese Merkmale bilden eine starke Ausgangslage für die CRA-Vorbereitung und gehen deutlich über eine reine KVM-Signalübertragung hinaus. Sie adressieren die zentralen Anforderungen an Zugriffsschutz, Kommunikationssicherheit, Protokollierung, Schwachstellenbehandlung und sichere Entwicklung – und sie sind öffentlich nachlesbar statt nur zugesichert.

Fairerweise gehört dazu die Einordnung, dass eine formale CRA-Konformität vor dem 11. Dezember 2027 noch von niemandem erklärt werden kann: Die entsprechenden Pflichten sind bis dahin schlicht nicht anwendbar. Die formale Konformität ist für das konkrete Produkt, die konkrete Version, den festgelegten Unterstützungszeitraum und den Zeitpunkt des Inverkehrbringens nachzuweisen, maßgeblich anhand der dann gültigen Risikobewertung, technischen Dokumentation, Konformitätsbewertung und EU-Konformitätserklärung.

Die belastbare Aussage lautet daher:

Barco CTRL erfüllt heute schon einen Großteil dessen, was der CRA ab 2027 verlangt, und dokumentiert es öffentlich und extern auditiert. Für Projekte, die über 2027 hinaus betrieben werden, ist das die derzeit nachweisstärkste Ausgangsposition im KVM-Markt.

Barco CTRL und OEM-/White-Label-KVM im Nachweisvergleich

Die folgende Tabelle bewertet keine namentlich genannten Mitbewerber. Sie zeigt, welche Nachweise bei Barco öffentlich dokumentiert sind und welche Punkte bei OEM- oder Private-Label-Systemen gesondert geprüft werden müssen.

CRA-relevantes Prüffeld	Bei Barco CTRL öffentlich dokumentiert	Bei OEM-/Private-Label-Produkten zu klären
Verantwortlicher Hersteller	Barco NV als europäischer Hersteller und Produktverantwortlicher	Wer ist Hersteller: OEM, Markeninhaber oder Importeur?
Gerichtsbarkeit und Eigentümerstruktur	EU-Recht, börsennotiert, keine Drittstaatenabhängigkeit	Welche Gerichtsbarkeit gilt, wer kontrolliert das Unternehmen?
Sicherheitsarchitektur	Security by Design, Zero Trust und fünf definierte Sicherheitsbereiche	Gibt es eine dokumentierte Architektur und Risikobewertung?
Kommunikationsschutz	TLS 1.2/1.3 und mTLS	Welche Protokolle, Zertifikate und Schlüssel werden verwendet?
Identitätsmanagement	zentrale Identitätsintegration, MFA, RBAC/ABAC	Gibt es persönliche Accounts, MFA und zentralen Rechteentzug?
Auditierbarkeit	Audit Logging und externe Syslog-Anbindung	Welche Aktionen werden protokolliert und manipulationssicher exportiert?
Sichere Entwicklung	Secure SDLC, Threat Modeling, Penetrationstests	Wer entwickelt die Firmware und wie wird sie geprüft?
Unabhängige Prüfung	ISO/IEC 27001:2022 zertifiziert, jährliche externe Audits	Existiert eine externe Zertifizierung mit passendem Geltungsbereich?
Schwachstellenorganisation	Responsible Disclosure und eigenes PSIRT	Wer nimmt Meldungen an, bewertet CVEs und liefert Patches binnen 24 h?
Herstellerkontinuität	dokumentierte Hersteller- und Supportorganisation	Ist der EU-Vertragspartner vom Drittstaaten-OEM abhängig?
CRA-Vorbereitung	CRA ausdrücklich Teil der veröffentlichten Sicherheitsroadmap	Existiert eine schriftliche CRA-Roadmap mit Verantwortlichen und Terminen?
Formale CRA-Nachweise	für die ab 2027 relevante Produktversion anzufordern	EU-Konformitätserklärung, Klassifizierung und Supportende anfordern

Bestandsanlagen und Erweiterungen nach 2027

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den neuen Hauptanforderungen nach Artikel 69 Absatz 2 erst dann, wenn sie ab diesem Datum wesentlich geändert werden. Die Meldepflichten nach Artikel 14 bilden die Ausnahme und gelten bereits ab September 2026 auch für früher bereitgestellte Produkte.

Nicht jedes Firmwareupdate oder jeder Komponententausch ist eine wesentliche Änderung. Sicherheitsupdates, die ausschließlich Risiken reduzieren und keine neuen Schnittstellen oder Abhängigkeiten schaffen, sind typischerweise anders zu bewerten als funktionale Erweiterungen.

Bei KVM-Bestandsanlagen sollte genauer geprüft werden, wenn beispielsweise:

• ein IP-Gateway oder eine Cloud-Anbindung nachgerüstet wird,
• neue Remote-Servicepfade entstehen,
• aus reinem Monitoring eine aktive Bedienmöglichkeit wird,
• die Zweckbestimmung erweitert wird,
• ein anderer Managementserver oder ein neues Betriebssystem eingesetzt wird,
• proprietäre Komponenten durch funktional abweichende Drittprodukte ersetzt werden,
• mehrere Systeme zu einem neuen, gemeinsam vermarkteten Gesamtprodukt verbunden werden.

Die Kommissionsleitlinien enthalten dazu ein Beispiel, das für Kontrollräume kaum treffender sein könnte: Ein Dashboard, das Maschinendaten sammelt sowie Trends und Alarme anzeigt, wird um Funktionen erweitert, mit denen sich die Maschinen steuern lassen. Damit verschiebt sich die Zweckbestimmung von einem Werkzeug zur Lagedarstellung hin zu einem Produkt, das operative Kontrolle über andere Geräte ausübt – eine wesentliche Änderung. Der Übergang vom „Sehen“ zum „Bedienen“ ist für KVM- und Kontrollraumprojekte also nicht nur eine Funktions-, sondern eine Regulierungsfrage.

CRA und NIS2: Produktpflicht trifft Betreiberpflicht

CRA und NIS2 verfolgen unterschiedliche Ansatzpunkte:

CRA	NIS2 / NISG 2026
reguliert Produkte mit digitalen Elementen	reguliert betroffene Organisationen und ihre Netz- und Informationssysteme
Hauptpflichten für Hersteller, Importeure und Händler	Risikomanagement- und Meldepflichten für wesentliche und wichtige Einrichtungen
Produktentwicklung, Konformität, Schwachstellen und Support	Organisation, Betrieb, Lieferkette, Kontinuität und Vorfallsmanagement
CE- und Marktüberwachungslogik	Aufsicht über die betroffene Einrichtung

Für den Betreiber laufen beide Ebenen bei der Beschaffung zusammen. NIS2 verlangt Lieferkettensicherheit und eine risikobasierte Auswahl von Produkten und Dienstleistern. Der CRA liefert künftig zusätzliche Mindestanforderungen und Herstellerinformationen. Eine CRA-Konformität ersetzt jedoch weder die NIS2-Risikoanalyse noch projektspezifische Sicherheitsanforderungen. Ein Betreiber darf daher vertraglich strengere Anforderungen stellen als das gesetzliche Produktminimum – und sollte das bei kritischen Bedienpfaden auch tun.

Beschaffungscheckliste: 15 Nachweise für ein CRA-fähiges KVM-System

Die folgende Liste eignet sich für Ausschreibungen, Herstelleranfragen und technische Abnahmen. Sie ist keine vollständige juristische CRA-Konformitätsprüfung.

1. Produkt eindeutig identifizieren

Artikelnummer, Hardwarestand, Firmwareversion, Softwarestand, Lizenzmodell und Systemtopologie müssen eindeutig festgelegt sein. Allgemeine Herstellerpräsentationen reichen nicht.

2. Wirtschaftsakteure und Rollen benennen

Hersteller, OEM, Markeninhaber, EU-Einführer, Distributor, Integrator und Supportpartner schriftlich zuordnen. Für jede Rolle eine ladungsfähige Anschrift und einen erreichbaren Sicherheitskontakt verlangen.

3. OEM- und Fertigungskette offenlegen

Klären, welche Hardware, Firmware und zentralen Komponenten von Drittunternehmen stammen. Bei Private Label muss eindeutig sein, wer die Herstellerpflichten übernimmt – und ob dieser Akteur die 24-Stunden-Meldefrist technisch überhaupt einhalten kann.

4. Gerichtsbarkeit und Eigentümerstruktur prüfen

Nach Erwägungsgrund 58 des CRA sind Gerichtsbarkeit, Unternehmenseigentum und Beziehungen zu einer Drittstaatenregierung legitime Prüfkriterien. Bei Systemen für wesentliche Einrichtungen gehören sie in die Bewertung.

5. CRA-Anwendungsbereich und Klassifizierung dokumentieren

Der Hersteller soll schriftlich begründen, warum das Produkt unter den CRA fällt und ob es als allgemeines, wichtiges oder kritisches Produkt eingestuft wird.

6. Konformitätsweg festlegen

Anwendbares Bewertungsverfahren, verwendete harmonisierte Standards oder technische Spezifikationen und gegebenenfalls die notifizierte Stelle benennen. Ab 2027 die produktbezogene EU-Konformitätserklärung verlangen.

7. Unterstützungszeitraum je Komponente nennen

Das Supportende muss nach Artikel 13 Absatz 19 mit Monat und Jahr angegeben werden. Für langlebige Leitstellen ist die gesamte erwartete Nutzungsdauer zu berücksichtigen – nicht nur ein pauschales Fünfjahresminimum.

8. Firmware- und Komponenteninventar vereinbaren

Mindestens Firmwarestände, zentrale Drittkomponenten, Embedded-Betriebssysteme und relevante Bibliotheken nachvollziehbar dokumentieren. SBOM-Zugang und Vertraulichkeitsregeln vertraglich festlegen.

9. Schwachstellenprozess prüfen

Responsible-Disclosure-Kanal, PSIRT oder zuständige Stelle, CVE-Verarbeitung, Security Advisories, Kundeninformation und Reaktionszeiten dokumentieren.

10. Updateverfahren absichern

Signaturprüfung, Integrität, Offline-Installation, Wartungsfenster, Abhängigkeiten, Rollback und Wiederherstellung praktisch nachweisen lassen.

11. Signierschlüssel und Update-Infrastruktur klären

Festhalten, wer Signierschlüssel kontrolliert, wo Updates gehostet werden und was bei Ausfall des OEM oder Herstellers geschieht. Direkte Abhängigkeiten von Drittstaaten-Clouds transparent machen.

12. Identitäts- und Berechtigungskonzept abnehmen

MFA, zentrale Identitätsintegration, Rollen, Attribute, privilegierte Administration, Notfallzugänge und Rechteentzug testen und dokumentieren.

13. Schnittstellen und Datenflüsse erfassen

Alle physischen und logischen Schnittstellen, Ports, Protokolle, APIs, Telemetrie-, Fernwartungs- und Cloud-Verbindungen in einem freigegebenen Datenflussplan abbilden.

14. Protokollierung, Monitoring und Wiederherstellung testen

Nachweisen, welche Ereignisse aufgezeichnet werden, wie die Zeit synchronisiert wird und ob sich Logs geschützt an ein zentrales Syslog- oder SIEM-System übertragen lassen. Failover, Redundanz, Konfigurationsbackup und Restore als Abnahmetest durchführen.

15. Change- und Verantwortungsmatrix vereinbaren

Definieren, wer Firmware freigibt, Updates testet, Schwachstellen bewertet, CRA-Meldungen durchführt und bei Erweiterungen prüft, ob eine wesentliche Änderung oder eine neue Herstellerrolle entsteht.

Was Betreiber jetzt tun sollten

Bis 11. September 2026

• Hersteller und EU-Vertragspartner für vorhandene KVM-Produkte erfassen.
• Sicherheits- und Schwachstellenkontakte validieren.
• Eskalationsweg für Herstellerinformationen und betroffene Systeme definieren.
• Kritische Firmwarestände und Produktversionen inventarisieren.

2026 bis Mitte 2027

• CRA-Nachweise in Ausschreibungs- und Vertragsvorlagen integrieren.
• Supportende und Updatefähigkeit bestehender Systeme prüfen.
• OEM-, Importeur- und Integratorrollen schriftlich klären.
• KVM-Management-, Service- und Datenpfade dokumentieren.
• Abnahmeverfahren für Hardening, MFA, Logging, Updates und Failover definieren.

Vor 11. Dezember 2027

• Für neu zu beschaffende Produkte die relevante EU-Konformitätserklärung prüfen.
• Produktklassifizierung und Konformitätsverfahren plausibilisieren.
• Unterstützungszeitraum mit der geplanten Leitstellenlebensdauer abgleichen.
• Verträge für Schwachstellenkommunikation, Updates, EOL und Ersatzteile abschließen.

Fazit: KVM-Beschaffung wird zur Lebenszyklusentscheidung

Der Cyber Resilience Act verändert die Bewertung von KVM-Technik grundlegend. Leistung, Bildqualität und Ergonomie bleiben wichtig. Für kritische Leitstellen reichen sie aber nicht mehr aus.

Ein zukunftsfähiges KVM-System muss auch folgende Fragen beantworten können:

• Wer trägt in der EU die Hersteller- und Produktverantwortung?
• Wer beherrscht Firmware, Signierschlüssel und Schwachstellen?
• Wie werden Benutzer, Berechtigungen und Kommunikationswege geschützt?
• Wie lange werden Updates bereitgestellt?
• Welche Nachweise bleiben über die gesamte Nutzungsdauer verfügbar?

Wer diese Fragen erst 2027 stellt, stellt sie zu spät. Systeme, die heute beschafft werden, laufen mitten in den Geltungsbeginn hinein – und Verträge, die Supportdauer, Meldewege und Nachweispflichten nicht regeln, lassen sich später nur schwer nachbessern.

Kontrollraumlösungen aus einer Hand

controlrooms plant, liefert und betreut Leitstellen und Kontrollräume als Gesamtanbieter – von der KVM-Architektur über Videowall und Bedienplätze bis zum laufenden Service. Für CRA-Fragen heißt das konkret: Wir bewerten bestehende KVM-Landschaften herstellerübergreifend, prüfen Lieferketten und Supportzeiträume, formulieren belastbare Nachweisanforderungen für Ausschreibungen und integrieren Barco CTRL sicher in bestehende Leitstellen- und IT-Umgebungen.

Sprechen Sie mit uns über Ihre KVM- und CRA-Projektbewertung.

Besuchen Sie unseren Showroom in Wien Prater oder Wieselburg

Technik für Leitstellen, Kontrollräume und KVM-Arbeitsplätze lässt sich am besten live beurteilen. Im controlrooms Showroom zeigen wir Videowall, KVM, Bedienplätze und typische 24/7-Szenarien im realen Zusammenspiel.

Termine nach Vereinbarung. controlrooms GmbH unterstützt bei Analyse, Planung, Integration und laufendem Service.

Showroom-Termin anfragen

---

Offizielle Quellen und weiterführende Informationen

• Verordnung (EU) 2024/2847 – Cyber Resilience Act
• Durchführungsverordnung (EU) 2025/2392 – wichtige und kritische Produktkategorien
• EU-Kommission: CRA-Leitlinien vom 27. Juli 2026
• EU-Kommission: Zusammenfassung des Cyber Resilience Act
• EU-Kommission: FAQ zur Umsetzung des CRA
• EU-Kommission: Standardisierung zum CRA
• ENISA: Single Reporting Platform
• Barco CTRL – Produkt- und Sicherheitsübersicht
• Barco CTRL Security Insights
• Barco CTRL Security Whitepaper
• Barco Security Organization und PSIRT
• Barco Trust Center