Cyber Resilience Act 2027 for KVM Systems in Control Rooms

In many control rooms, KVM systems form the central operating path between people and critical applications. The Cyber Resilience Act therefore does not stop at servers, firewalls or classic IoT devices. KVM matrices, extenders, encoders, decoders, management servers and their firmware can all be covered as products with digital elements. For operators, that turns the chain of origin, updates and evidence into a procurement criterion.

The essentials at a glance

• The main obligations of the European Cyber Resilience Act apply from 11 December 2027. The manufacturer reporting obligations under Article 14 start earlier, on 11 September 2026.
• It is not only products with internet access that are covered. A direct or indirect logical or physical data connection to a device or network can be enough. Classic KVM technologies can therefore fall within scope as well.
• The main responsibility sits with the manufacturer. For products from third countries, the EU importer takes on its own verification and evidence obligations.
• Anyone selling OEM technology under their own name or brand becomes the manufacturer under Article 21 — including the obligation to report actively exploited vulnerabilities within 24 hours.
• The manufacturer of the complete KVM product remains responsible for integrated hardware and software components too. That includes embedded operating systems, web servers, libraries, network controllers and update components.
• A CE marking is not an independent EU cybersecurity seal of approval. What counts is the product-specific risk assessment, technical documentation, conformity assessment and EU declaration of conformity.
• In recital 58, the legislator explicitly names non-technical risk factors: the jurisdiction of the manufacturer, its corporate ownership structure and its ties to the government of the country of origin.
• As the platform of a European manufacturer, Barco CTRL comes with an unusually well documented starting position: security by design, zero trust, TLS 1.2/1.3 and mTLS, identity management, MFA, ABAC, audit logging, secure development, penetration testing, its own PSIRT and an ISO/IEC 27001:2022-certified management system with annual external audits.
• Operators should not wait until 2027 to request CRA evidence. KVM systems are planned for the long term and frequently used for well over five years.

Note: this article provides a technical and editorial assessment, legal status 8 August 2026. It is not legal advice and replaces neither the assessment of a specific product nor the legal evaluation of a supply or integration model.

Why the CRA is particularly relevant for KVM systems

A KVM infrastructure transmits keyboard, video and mouse signals between the operator workspace and the source system. In a control room that makes it far more than an accessory: it determines which operator can see and operate which application.

Depending on the architecture, the KVM solution can include:

• KVM matrix or switching core,
• KVM extenders, encoders and decoders,
• network and IP gateways,
• central management servers and databases,
• web interfaces and administrative clients,
• embedded operating systems and firmware,
• interfaces to Active Directory or other identity providers,
• monitoring, logging and remote maintenance functions,
• update servers or cloud-based services.

Under Article 2(1), the Cyber Resilience Act — Regulation (EU) 2024/2847 — applies to products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. An internet connection is not required for that.

This is decisive for KVM technology: a proprietary matrix with optical or electrical connections can be a product with digital elements too. “Not IP-based” therefore does not automatically mean “outside the CRA”.

The dates that matter

On 27 July 2026 the European Commission published additional guidance. Among other things, it clarifies the scope, substantial modifications, support periods, risk assessments and reporting obligations.

Not all KVM is alike: architecture decides

Classic KVM matrix

A classic proprietary KVM matrix can separate source systems and operator workspaces physically or logically. Where no general IP networks are used, this reduces certain network-based attack paths. CRA-relevant questions nevertheless remain:

• Does the matrix have administrable firmware?
• Which interfaces exist for configuration and service?
• How are users and permissions managed?
• Are updates signed and installable offline?
• How are vulnerabilities detected, assessed and remediated?
• For how long does the manufacturer deliver security updates?
• Which components and libraries are contained in the firmware?

Physical separation can be an effective security feature. It does not replace documented vulnerability and product lifecycle management.

KVM over IP and KVM over IT

With KVM over IP, video and control signals are transported over IP networks. KVM over IT goes further and integrates the KVM platform natively into existing IT services such as identity management, DNS, DHCP, NTP, monitoring, syslog, VDI or APIs.

This integration extends the feature set, but it also increases the number of dependencies and interfaces. At the same time it enables central security functions that are often only available to a limited extent on isolated KVM islands:

• multi-factor authentication,
• central revocation of user rights,
• role-based or attribute-based access control,
• certificate management,
• encrypted and mutually authenticated communication,
• central audit logging,
• governed patch and version management,
• integration into SIEM and network monitoring.

The right question is therefore not “IP or not IP?”, but:

Is this specific KVM architecture securely manageable across its entire lifecycle, transparently documented and unambiguously owned in organisational terms?

For more on the technical foundations, see how KVM improves your control room, KVM extenders with JPEG XS technology and why KVM-over-IT is the paradigm shift your control room needs.

The real risk: the OEM and firmware supply chain

Many KVM products are not built entirely by the company whose logo is on the enclosure. The hardware platform, FPGA design, network controller, embedded Linux, web server or update components can come from different suppliers. With private-label products, an OEM system is sold under a different brand.

A typical supply chain can look like this:

OEM and component suppliers in third countries
                    ↓
      European brand owner / private label
                    ↓
          EU importer / distributor
                    ↓
             KVM system integrator
                    ↓
        control room or command centre operator

Legally the CRA is origin-neutral: the rules apply to every product made available on the EU market. The legislator did, however, recognise that origin and ownership structure can indeed constitute a risk — and wrote that into the text explicitly.

What the CRA itself says about high-risk suppliers

Recital 58 of the CRA records that dependencies on high-risk suppliers can pose a strategic risk, “in particular when the products with digital elements are intended for use by […] essential entities” — that is, precisely those critical infrastructure operators that run control rooms.

The criteria the legislator names are:

• the jurisdiction that applies to the manufacturer,
• the characteristics of its corporate ownership,
• links of control to the government of a third country in which it is established,

and this applies “in particular where the third country engages in economic espionage or irresponsible State behaviour in cyberspace, and where its laws enable arbitrary access to any kind of business activity or company data […] and possibly impose intelligence obligations without democratic checks and balances, due process or the right to appeal to an independent court”.

These non-technical risk factors have to be taken into account explicitly when determining a significant cybersecurity risk. Under Article 19(3), an importer even has to inform the market surveillance authorities where, solely on the basis of non-technical risk factors, it has reason to believe that a product may present a significant cybersecurity risk. In addition, recital 13 allows Member States to lay down national restrictions on products or suppliers that take account of non-technical factors.

For procurement that means: anyone equipping a control room is entitled to ask about the ownership and legal position behind a product. That is not over-regulation, it is the direction of scrutiny the legislator intended.

The practical evidence questions

• Is the actual developer of the firmware known and contractually reachable?
• Who owns and protects the signing keys for firmware updates?
• Can the EU contracting partner supply security updates itself, or is it entirely dependent on the OEM?
• Is there a coordinated vulnerability disclosure process and a reachable product security contact?
• Are the open source and third-party components used traceable?
• Are new vulnerabilities monitored after end of sale as well?
• Can updates be installed without a connection to a foreign cloud or telemetry service?
• What happens if the manufacturer changes hands, becomes insolvent, faces export restrictions or discontinues a product line?

The last point is expressly regulated in the CRA. Under Article 19(8), an importer has to inform the market surveillance authorities and the users as soon as it becomes aware that the manufacturer has ceased its operations and can no longer comply with its obligations. The failure risk of a distant supply chain is therefore not a theoretical scenario but a case the law anticipates.

What matters is not the label on the device, but the robust chain of answers behind the product.

Who carries which CRA responsibility?

1. The manufacturer

A manufacturer is not only whoever physically builds a product. Under Article 3(13), a company that has products designed, developed or manufactured and markets them under its own name or trademark is a manufacturer as well.

For a KVM system carrying the brand of a third-country manufacturer, that company remains the manufacturer. If, on the other hand, a European company sells the same technology under its own brand, that company takes on the manufacturer role. With it comes responsibility for, among other things:

• the cybersecurity risk assessment,
• meeting the essential requirements,
• technical documentation,
• conformity assessment and EU declaration of conformity,
• CE marking,
• secure product configuration,
• vulnerability handling and security updates,
• CRA reporting under Article 14,
• defining and communicating the support period.

A forwarded PDF from the original OEM is not a robust substitute for this on its own.

The underestimated point here is the reporting deadline. Under Article 21, an importer or distributor is considered a manufacturer as soon as it places a product on the market under its own name or trademark — and is therefore subject to the obligations of Articles 13 and 14. Those include an early warning about an actively exploited vulnerability within 24 hours of becoming aware of it. Anyone who does not control the source code and firmware, but first has to ask the OEM in another time zone, can hardly meet that deadline structurally. From September 2026, private label is therefore no longer a purely marketing decision but an operational liability question.

2. The EU importer

The importer is the company established in the EU that first places a product bearing the brand of a manufacturer established outside the EU on the Union market. Under Article 19(1), it may only place compliant products on the market.

Before doing so, Article 19(2) requires the importer to ensure that:

• the required conformity assessment procedure under Article 32 has been carried out,
• the technical documentation has been drawn up,
• the CE marking is present,
• the EU declaration of conformity and user information are supplied,
• manufacturer and support information are complete,
• the necessary documents can be presented to the authorities.

If the importer has reason to believe that the product is not compliant, it may not place it on the market. If a vulnerability comes to its attention later, it has to inform the manufacturer without undue delay; where there is a significant cybersecurity risk, further information and corrective obligations follow.

3. The distributor

The distributor has to check with due care whether the marking, the manufacturer and importer information, the documents and the support period are present. If it identifies a possible non-conformity, it may not simply pass the product on.

4. The system integrator

The integrator’s role depends on the project. Installing, configuring and connecting compliant components does not automatically make it a manufacturer. The picture can change if it:

• assembles individual components into a new overall product and makes that available on the market as its own product,
• sells the system under its own name or trademark,
• changes the intended purpose,
• adds new, security-relevant interfaces or data flows,
• makes a substantial modification to a product already placed on the market.

Under Article 22, a person who is neither manufacturer, importer nor distributor is also considered a manufacturer if they carry out a substantial modification and make the product available on the market. For complex overall KVM systems, this question of roles has to be settled before the contract is awarded — not after a vulnerability or an incident.

5. The operator

The CRA directs its main obligations at the economic operators, not at the operator of a control room. The evidence nevertheless remains central for the operator:

• as the basis for secure procurement,
• for supply chain management under NIS2 and its national transposition,
• for risk analyses and technical approvals,
• for patch, change and incident management,
• as evidence towards internal audit, customers and authorities.

The CRA therefore does not replace the organisational obligations of the operator. At best it improves the information and security basis of the products used. For the operator perspective, see our NIS2 checklist for control rooms.

What the CRA requires technically for a KVM system

The CRA requirements are risk-based and technology-neutral. Applied to a KVM system, the following test areas emerge in particular.

Secure default configuration

Under Annex I Part I, the product has to be made available with a secure default configuration, unless otherwise agreed between manufacturer and business user for a tailor-made product. For KVM that means, for example:

• no universal or unchanged default passwords,
• unnecessary services and interfaces disabled,
• minimal privileges for users and administrators,
• secure initial commissioning and documented hardening.

Access protection and identity management

KVM is a privileged access path. Permissions should therefore not rest on shared accounts alone. What matters:

• personal user identities,
• role-based or attribute-based permissions,
• multi-factor authentication,
• separation of operator, service and administration roles,
• governed emergency and break-glass access,
• prompt revocation of rights when roles change or staff leave.

Confidentiality and integrity

Not only video data but also keyboard and mouse input and administrative commands have to be protected against manipulation and unauthorised access. For network-based systems that means examining authenticated and encrypted communication channels, robust certificate management and the separation of user, management and service paths.

Availability and recovery

In a control room, a KVM fault can impair the operability of critical applications. The risk assessment therefore also has to cover:

• redundancy of critical server and network components,
• defined behaviour on connection or authentication failures,
• secured configuration backups,
• restart and recovery procedures,
• tested failover scenarios,
• local operating options for defined emergencies.

Logging

At a minimum, logins, failed access attempts, changes to roles and permissions, administrative changes, security-relevant system events and update and maintenance activities should be traceable. The logs have to be protected against manipulation and be capable of meaningful integration into central monitoring or a SIEM.

Vulnerabilities and secure updates

The manufacturer has to handle vulnerabilities effectively throughout the support period. For operators, the following are particularly relevant:

• an unambiguous reporting channel for security flaws,
• defined triage and escalation processes,
• signed and integrity-checked updates,
• documented release notes and security advisories,
• offline update capability for isolated control rooms,
• rollback or recovery procedures,
• assessment of vulnerabilities in integrated components.

The legislator explicitly acknowledges that automatic updates are not suitable for every environment. Under recital 56, the corresponding expectations do not apply to products intended for use in professional ICT networks and in particular in critical and industrial environments, where an automatic update could cause operational disruption. For control rooms, a controlled update procedure that can be applied offline is therefore compliant — without affecting the manufacturer’s obligation to provide and inform.

SBOM: necessary, but not automatically visible to the customer

The manufacturer has to have command of its components and vulnerabilities. Under Annex I Part II point 1, manufacturers have to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies of the product.

That does not mean that every buyer automatically receives the complete SBOM or the entire technical documentation. Those documents are primarily intended for conformity assessment and market surveillance. Control room operators should therefore define contractually which information they need for their own risk management, for example:

• a component or firmware inventory,
• a list of supported versions,
• the mapping of published CVEs,
• security advisories,
• evidence of third-party component management,
• SBOM provision under a confidentiality agreement,
• response times for critical vulnerabilities.

For operators, the SBOM obligation is also an effective touchstone. A company that does not develop the firmware of its product itself but buys it in as private label can only supply a robust software bill of materials if the OEM releases it. In practice, the question “show me your SBOM” separates genuine manufacturer responsibility from forwarded documentation very quickly.

Support period: five years is not automatically enough

Under Article 13(8), the support period is at least five years. If the product is expected to be in use for a shorter time, the period corresponds to the expected time of use. What is decisive, though, is that the support period reflects the expected service life.

The Commission guidance of 27 July 2026 clarifies that five years is not to be understood as a default value: the minimum acts merely as a backstop, while the manufacturer has to determine the appropriate period itself against the criteria of Article 13(8).

The legislator is even clearer in recital 60. It states that where the reasonably expected use exceeds five years, correspondingly longer support periods are to be ensured — “as is often the case for hardware components such as motherboards or microprocessors, network equipment such as routers, modems or switches and software such as operating systems”. And further: “In particular, products with digital elements intended for use in industrial settings, such as industrial control systems, are often used for significantly longer periods of time.”

For control rooms that settles the matter. KVM systems, video wall infrastructures and control rooms are frequently operated for ten years or more. For such a product, a manufacturer cannot fall back on a blanket five-year commitment.

For a KVM project, the support periods of all critical elements should therefore be aligned:

• KVM software and management servers,
• encoders, decoders and extenders,
• embedded operating systems,
• network components,
• database and hypervisor,
• certificate and key management,
• external services and APIs.

Under Article 13(9), security updates provided during the support period have to remain available after their provision for at least ten years or for the remainder of the support period, whichever is longer.

Reporting obligations from 11 September 2026

Under Article 14(1), manufacturers have to report actively exploited vulnerabilities and severe incidents simultaneously to the CSIRT designated as coordinator and to ENISA, via the ENISA single reporting platform.

For actively exploited vulnerabilities:

• early warning within 24 hours of becoming aware,
• a supplementary notification within 72 hours,
• a final report no later than 14 days after a corrective or mitigating measure is available.

For severe incidents, the 24- and 72-hour stages apply as well; the final report is due within one month of submitting the 72-hour notification.

Under Article 69(3), these reporting obligations also apply to products placed on the market before 11 December 2027. For operators that means the contracting partner has to know as early as 2026 who within the KVM supply chain assesses, reports and remediates a vulnerability, and informs the affected customers.

Is a KVM switch a “switch” within the meaning of the CRA?

This question arises immediately when reading Annex III of the CRA: among the important products of class I it lists “routers, modems intended for the connection to the internet, and switches”. Does that mean every KVM switch is automatically subject to stricter procedures?

No. Implementing Regulation (EU) 2025/2392 of 28 November 2025 supplies the technical description of the categories and defines switches as products “that enable connectivity between networked devices through packet forwarding mechanisms, have a management plane and are typically part of the data link layer or the network layer”. Managed switches, smart switches, multilayer switches, virtual security switches, programmable SDN switches and bridges are named.

A KVM switch does not forward network packets at layer 2 or 3; it switches control and video signals between the workspace and the source system. The shared name is historical, not functional. In any case, another principle of the same regulation is decisive: a product that is capable of performing the functions of a listed category, but whose core functions differ from it, is not considered a product of that category.

Is a KVM system an important product of class I or II?

Not automatically. Classification follows the core function of the product. A KVM system does not become an important product merely because it contains an operating system, a network port or a security-relevant library.

A closer assessment is needed where the core function corresponds to one of the categories listed in Annex III:

Class I (among others): identity management systems and privileged access management software and hardware · network management systems · products with VPN functionality · physical and virtual network interfaces · operating systems · routers, modems and switches · microprocessors, microcontrollers, ASICs and FPGAs with security-related functions.

Class II: hypervisors and container runtime systems · firewalls, intrusion detection and prevention systems · tamper-resistant microprocessors and microcontrollers.

For typical KVM signal distribution, much speaks for the general product category. If the platform at its core takes on the functions of privileged access management or of a network management system, however, class I can become relevant. The Implementing Regulation describes privileged access management software as an access management system “that controls and monitors access rights to IT or OT systems and sensitive information within an organisation”. The manufacturer has to justify and document the classification.

Classification influences the conformity procedure under Article 32:

• General products: internal control (module A) is possible.
• Class I: internal control only where harmonised standards, common specifications or a European certification scheme have been applied in full. Otherwise EU type-examination (module B + C) or full quality assurance (module H) — that is, involving a notified body.
• Class II: always module B + C, module H or a European certification scheme at assurance level “substantial” as a minimum.

Barco CTRL: a European manufacturer with documented CRA preparation

Barco CTRL is developed as a KVM-over-IT platform for shared information distribution to operator workspaces and video walls. For a CRA assessment, one structural advantage counts first, and it cannot be retrofitted: Barco NV is a European manufacturer. Manufacturer, product responsibility and the point of contact for authorities therefore coincide. There is no importer chain, no third-country OEM behind the brand and no ambiguity about who is obliged under Articles 13 and 14. Precisely those non-technical risk factors named in recital 58 of the CRA — foreign jurisdiction, opaque ownership structure, state influence — do not arise here.

Publicly documented security features

According to the official Barco CTRL product information, the platform is based on security-by-design and zero-trust principles, with every connection authenticated and every communication channel encrypted using TLS 1.2 or 1.3. The security architecture rests on five pillars: identity management, communication protection, system protection, audit logging and media protection.

Notable for this topic: Barco names the Cyber Resilience Act itself as part of its long-term security roadmap, together with ISO 27001 and NIS2. The CRA is therefore not a compliance topic bolted on afterwards, but a planned development line.

According to the published Barco documents, there is also:

• mutual certificate authentication via mTLS,
• integration into central identity services and MFA,
• role-based and attribute-based access control,
• audit events for operator and IAM actions, and forwarding to external syslog systems,
• a secure software development lifecycle with threat modelling, SAST, SCA, DAST and vulnerability scanning,
• involvement of independent security experts and penetration testing by ethical hackers,
• a responsible disclosure procedure and a dedicated Product Security Incident Response Team,
• redundancy options for critical components.

The Barco security organization describes a multi-level structure with a security office, product security and a PSIRT. The information security management system is certified to ISO/IEC 27001:2022; as a third line of defence, Barco describes annual external ISO 9001 and ISO 27001 audits. That provides exactly the independent control instance the CRA presupposes for conformity assessment and vulnerability handling.

What follows from that — and what is still outstanding

These features form a strong starting position for CRA preparation and go well beyond pure KVM signal transmission. They address the central requirements for access protection, communication security, logging, vulnerability handling and secure development — and they are publicly verifiable rather than merely asserted.

In fairness, that includes the observation that formal CRA conformity cannot be declared by anyone before 11 December 2027: until then the corresponding obligations simply do not apply. Formal conformity has to be demonstrated for the specific product, the specific version, the defined support period and the moment of placing on the market, on the basis of the risk assessment, technical documentation, conformity assessment and EU declaration of conformity valid at that time.

The robust statement is therefore:

Barco CTRL already meets a large part of what the CRA will require from 2027, and documents it publicly and under external audit. For projects operated beyond 2027, that is currently the strongest evidence position in the KVM market.

Barco CTRL and OEM/white-label KVM: an evidence comparison

The following table does not assess any named competitor. It shows which evidence is publicly documented at Barco and which points have to be examined separately for OEM or private-label systems.

Existing installations and extensions after 2027

Products placed on the market before 11 December 2027 become subject to the new substantive requirements under Article 69(2) only once they are substantially modified from that date onwards. The reporting obligations under Article 14 are the exception and already apply from September 2026 to products made available earlier.

Not every firmware update or component replacement is a substantial modification. Security updates that only reduce risks and do not create new interfaces or dependencies are typically assessed differently from functional extensions.

For existing KVM installations, a closer look is warranted where, for example:

• an IP gateway or a cloud connection is retrofitted,
• new remote service paths are created,
• pure monitoring becomes an active operating capability,
• the intended purpose is extended,
• a different management server or a new operating system is deployed,
• proprietary components are replaced by functionally different third-party products,
• several systems are combined into a new, jointly marketed overall product.

The Commission guidance contains an example that could hardly fit control rooms better: a dashboard that collects machine data and displays trends and alarms is extended with functions that allow the machines to be controlled. That shifts the intended purpose from a situational awareness tool to a product exercising operational control over other devices — a substantial modification. For KVM and control room projects, the move from “seeing” to “operating” is therefore not only a functional question but a regulatory one.

CRA and NIS2: product obligation meets operator obligation

For the operator, both levels converge at procurement. NIS2 requires supply chain security and a risk-based selection of products and service providers. In future the CRA will supply additional minimum requirements and manufacturer information. CRA conformity does not, however, replace the NIS2 risk analysis or project-specific security requirements. An operator is therefore free to impose stricter contractual requirements than the statutory product minimum — and for critical operating paths it should.

Procurement checklist: 15 pieces of evidence for a CRA-capable KVM system

The following list is suitable for tenders, manufacturer enquiries and technical acceptance. It is not a complete legal CRA conformity assessment.

1. Identify the product unambiguously

Article number, hardware revision, firmware version, software level, licensing model and system topology have to be defined unambiguously. General manufacturer presentations are not enough.

2. Name the economic operators and roles

Assign manufacturer, OEM, brand owner, EU importer, distributor, integrator and support partner in writing. For each role, require a registered address and a reachable security contact.

3. Disclose the OEM and manufacturing chain

Clarify which hardware, firmware and central components come from third-party companies. With private label it has to be unambiguous who takes on the manufacturer obligations — and whether that actor can technically meet the 24-hour reporting deadline at all.

4. Check jurisdiction and ownership structure

Under recital 58 of the CRA, jurisdiction, corporate ownership and links to a third-country government are legitimate assessment criteria. For systems intended for essential entities, they belong in the evaluation.

5. Document CRA scope and classification

The manufacturer should state in writing why the product falls under the CRA and whether it is classified as a general, important or critical product.

6. Define the conformity route

Name the applicable assessment procedure, the harmonised standards or technical specifications used and, where relevant, the notified body. From 2027, require the product-specific EU declaration of conformity.

7. State the support period per component

Under Article 13(19), the end of support has to be given with month and year. For long-lived control rooms, the entire expected service life has to be taken into account — not just a blanket five-year minimum.

8. Agree a firmware and component inventory

Document at minimum firmware levels, central third-party components, embedded operating systems and relevant libraries in a traceable way. Settle SBOM access and confidentiality rules contractually.

9. Examine the vulnerability process

Document the responsible disclosure channel, the PSIRT or responsible unit, CVE processing, security advisories, customer notification and response times.

10. Secure the update procedure

Have signature verification, integrity, offline installation, maintenance windows, dependencies, rollback and recovery demonstrated in practice.

11. Clarify signing keys and update infrastructure

Record who controls the signing keys, where updates are hosted and what happens if the OEM or manufacturer fails. Make direct dependencies on third-country clouds transparent.

12. Accept the identity and permission concept

Test and document MFA, central identity integration, roles, attributes, privileged administration, emergency access and revocation of rights.

13. Record interfaces and data flows

Map all physical and logical interfaces, ports, protocols, APIs, telemetry, remote maintenance and cloud connections in an approved data flow diagram.

14. Test logging, monitoring and recovery

Demonstrate which events are recorded, how time is synchronised and whether logs can be transferred securely to a central syslog or SIEM system. Carry out failover, redundancy, configuration backup and restore as acceptance tests.

15. Agree a change and responsibility matrix

Define who approves firmware, tests updates, assesses vulnerabilities, submits CRA reports and, for extensions, checks whether a substantial modification or a new manufacturer role arises.

What operators should do now

By 11 September 2026

• Record the manufacturers and EU contracting partners for existing KVM products.
• Validate security and vulnerability contacts.
• Define the escalation path for manufacturer notifications and affected systems.
• Inventory critical firmware levels and product versions.

2026 to mid-2027

• Integrate CRA evidence into tender and contract templates.
• Check end of support and update capability of existing systems.
• Clarify OEM, importer and integrator roles in writing.
• Document KVM management, service and data paths.
• Define acceptance procedures for hardening, MFA, logging, updates and failover.

Before 11 December 2027

• For newly procured products, check the relevant EU declaration of conformity.
• Sanity-check the product classification and conformity procedure.
• Align the support period with the planned control room service life.
• Conclude contracts covering vulnerability communication, updates, end of life and spare parts.

Conclusion: KVM procurement becomes a lifecycle decision

The Cyber Resilience Act fundamentally changes how KVM technology has to be assessed. Performance, image quality and ergonomics remain important. For critical control rooms, they are no longer sufficient.

A future-proof KVM system also has to be able to answer the following questions:

• Who carries manufacturer and product responsibility in the EU?
• Who commands the firmware, the signing keys and the vulnerabilities?
• How are users, permissions and communication paths protected?
• For how long will updates be provided?
• Which evidence remains available across the entire service life?

Anyone asking these questions for the first time in 2027 is asking them too late. Systems procured today run straight into the start of application — and contracts that fail to settle support duration, reporting paths and evidence obligations are hard to fix afterwards.

Control room solutions from a single source

controlrooms plans, delivers and supports control rooms and command centres as a single-source provider — from the KVM architecture through video wall and operator workspaces to ongoing service. For CRA questions that means in concrete terms: we assess existing KVM landscapes across manufacturers, examine supply chains and support periods, formulate robust evidence requirements for tenders, and integrate Barco CTRL securely into existing control room and IT environments.

Talk to us about your KVM and CRA project assessment

Erich Strasser
controlrooms GmbH
Phone: +43 664 8866 7817
Email: erich.strasser@controlrooms.at

Official sources and further information

• Regulation (EU) 2024/2847 — Cyber Resilience Act
• Implementing Regulation (EU) 2025/2392 — important and critical product categories
• European Commission: CRA guidance of 27 July 2026
• European Commission: Cyber Resilience Act summary
• European Commission: FAQ on CRA implementation
• European Commission: CRA standardisation
• ENISA: Single Reporting Platform
• Barco CTRL — product and security overview
• Barco CTRL Security Insights
• Barco CTRL security whitepaper
• Barco security organization and PSIRT
• Barco Trust Center