Control room cybersecurity in 2026: Security is becoming a shared responsibility

Product security is moving from a best-effort discipline towards a demonstrable legal and operational responsibility. Barco Product Security Officer Timo Kosig explains how NIS2 and the Cyber Resilience Act are changing customer expectations, why Zero Trust should remain nearly invisible to operators, and what organizations should ask before trusting a technology vendor.

Timo, are cybersecurity legislations like NIS2 genuinely raising the cybersecurity bar?

Yes. One of the most important changes is that cybersecurity accountability now reaches management level.

NIS2 also gives supply-chain security greater importance. Organizations need to consider not only their own security measures but also the vulnerabilities, products and security practices of their direct suppliers and service providers.

As an essential entity, Barco experiences this from both directions. We need to examine our own suppliers while customers examine us.

The nature of customer conversations is changing as a result. Organizations no longer simply ask whether a product is secure. They ask for evidence. They want documentation about development processes, vulnerability handling, product architecture, certifications and the measures that remain their responsibility.

That is a positive development. Security claims should be verifiable.

How does the Cyber Resilience Act change the relationship between vendors and customers?

The Cyber Resilience Act moves product security from a best-effort approach towards a legal obligation.

Since 11 September 2026, manufacturers of covered products with digital elements have been required to report certain actively exploited vulnerabilities and severe security incidents. An early warning must be submitted within 24 hours after the manufacturer becomes aware of the issue, followed by a more detailed notification within 72 hours.

A final report is also required. The exact deadline depends on whether the report concerns an actively exploited vulnerability or a severe incident.

These reporting obligations can also apply to products already placed on the market. Most of the CRA’s wider product-security requirements will apply from 11 December 2027. 

Are the different cybersecurity rules converging or moving further apart?

They are converging around the fundamental principles.

Most frameworks and regulations expect risk management, secure development, effective vulnerability handling, logging and incident reporting. The underlying direction is relatively consistent.

The differences are mainly found in the evidence organizations need to provide and the timelines they need to follow. NERC CIP, NIS2 and the Cyber Resilience Act do not ask for exactly the same documentation or use the same reporting schedules.

IEC 62443 provides a widely recognized technical language for industrial automation and control-system security. That is why we build on it and on independent certification.

A shared technical baseline helps vendors, integrators and customers understand what has actually been implemented, even when their regulatory obligations differ.

What do people misunderstand about Zero Trust in operational technology?

The first misunderstanding is that Zero Trust is a product. It is not. It is a security principle.

The second is that it automatically creates more friction for operators.

Zero Trust means that trust is earned and verified rather than assumed simply because a user or device is located on the “inside” of a network.

In practice, that means authenticating devices, encrypting traffic and limiting permissions to the sources, displays and workstations that genuinely need them.

When Zero Trust is implemented well, operators should hardly notice it. When it is implemented badly, people start looking for workarounds, and the environment may become less secure rather than more secure.

Secure controls also need to be enabled by default. Weaker options for legacy environments may sometimes be necessary, but enabling them should require an explicit and documented decision. Organizations should understand the risk they are accepting.

How can operators determine whether a technology vendor deserves their trust?

Ask for evidence, not marketing.

Start with the security process behind the product. Does the vendor follow a certified information-security process such as ISO 27001? Does it conduct independent penetration testing regularly? Has the product or its development process received recognized external certification?

Examine the available security documentation as well. It should explain the architecture, threat model and division of responsibilities between the vendor, integrator and operator.

What is post-quantum cryptography and should organizations already be planning for it?

Post-quantum cryptography refers to cryptographic algorithms designed to remain secure against attacks from both today’s conventional computers and future quantum computers. This matters because sufficiently powerful quantum computers could eventually break some of the cryptographic methods currently used to protect sensitive data and communications.

Organizations should therefore already be planning for the transition, but without panic.

The European Union has developed a coordinated roadmap for the transition to post-quantum cryptography. It calls on Member States to begin that transition by the end of 2026 and identifies 2030 as an important target for protecting high-risk systems, including critical infrastructure.

The reason for starting now is not that a cryptographically relevant quantum computer will necessarily arrive tomorrow. There is a more immediate concern known as “store now, decrypt later.”

An attacker can intercept and store encrypted information today in the hope of decrypting it once the necessary quantum capability becomes available. Information that must remain confidential for many years can therefore already be at risk. The European Commission has identified this as an important reason to start the transition early.

It will not be enough to protect only external connections. Post-quantum protection will eventually need to include internal communication as well.

The practical first step is to create an inventory of where cryptography is used and which algorithms, certificates and keys are involved. Organizations should also ask vendors how they plan to make cryptographic components replaceable.

Crypto-agility matters because this will be a transition, not a one-time product update.

What keeps you awake at night?

The speed at which everything moves.

New vulnerabilities can be exploited within days, and an attacker only needs one overlooked connection. That could be an exposed edge device, a supplier’s remote support channel or a poorly protected link to a display.

The complexity of modern environments makes it difficult to protect every connection equally. That is why strong defaults, layered security and continuous monitoring are so important.

And what gives you confidence?

The industry has stopped treating security as an optional addition.

Regulation such as the Cyber Resilience Act is making security practices mandatory. Customers increasingly ask for evidence rather than accepting general promises. Vendors are expected to explain how products are developed, maintained and supported.

Most importantly, we can design products that are secure by design and secure by default without slowing operators down.

For a long time, organizations assumed they had to choose between security and usability. Good security engineering shows that the two can reinforce each other.

The strongest security controls are often the ones that operators barely notice, yet can rely on every day.