Industries such as pharmaceuticals, chemicals or agri-food heavily rely on laboratory equipment, especially for quality control, R&D or chemical analysis. These instruments are vital for numerous business processes, many of which are critical for operational and regulatory compliance (i.e. in pharmaceutical industries, quality control of raw materials and finished products for batch release, or the production of regulatory reports). As a result, ensuring the availability and reliability of laboratory equipment is a top priority for these companies. However, these devices—originally designed to operate in isolation—are now increasingly connected to improve operational efficiency through automated data collection and harmonized analytical methods across sites.

These operational requirements have driven the widespread adoption of Laboratory Information Management Systems (LIMS). In pharmaceutical settings, LIMS manages analytical batch records, monitors quality parameters, and provides full traceability for regulatory audits. In environmental testing, they streamline data collection, validation, and reporting, reducing manual errors. In food safety labs, LIMS automate compliance reporting and trigger alerts when contamination thresholds are exceeded.

Centralizing the management of laboratory equipment data with LIMS requires instruments to be networked, even when this was not initially anticipated by manufacturers. This increased connectivity thus brings new cybersecurity challenges, as many laboratory systems are based on outdated technologies and thus potentially increase the attack surface.

Obsolete Systems: A Growing Security Risk

Many laboratory devices still run on proprietary or outdated operating systems (such as Windows XP) that no longer receive security updates. These legacy systems are highly vulnerable to known exploits and are difficult to patch.

Manufacturers rarely release patches for obsolete equipment, despite the long lifespan of these devices. Once deployed, patching is further complicated by governance issues—specifically, determining who is responsible for applying updates.

Most laboratory instruments also have limited built-in security features. They often use unsecure or outdated communication protocols (such as HTTP, FTP, or SMBv1/v2) and are frequently deployed with poor configuration practices, further weakening their security. Although newer models support secure standards like OPC UA or SFTP, these features are not always enabled or properly configured.

Figure 1: Typical industrial network architecture in pharmaceutical manufacturing.

Identity and access management is another major challenge in laboratory environments. Many devices still rely on default or shared local accounts and cannot enforce proper authentication mechanisms. These systems are rarely compatible with centralized directories through protocols such as LDAP, making it difficult to enforce consistent security policies across multiple sites. While from an operational perspective authentication may not seem necessary, when combined with obsolete operating systems, insecure communication protocols, and limited access control, these weaknesses turn laboratory devices into easy entry points for cyberattacks.

As laboratories increasingly interconnect their instruments with LIMS, cloud analytics, and centralized data historians, this lack of cybersecurity hygiene not only directly exposes devices but also puts the broader corporate network at risk.

Securing Laboratory Systems with Isolation and Gateways

When laboratory equipment cannot be secured due to its inherent limitations, exposure must be minimized as much as possible. This involves placing such devices behind secured intermediary systems—such as dedicated gateways or workstations—and defining specific network zones to limit the surface of a potential compromise. By segmenting the network and filtering data flows, potential compromises can be better contained and the impact on other critical systems limited.

Three key solutions can enhance security in this context:

• Workstations equipped with cybersecurity tools to ensure compatibility between lab equipment and secured networks. This approach works best when modern workstations act as intermediaries, translating data securely and enabling monitoring. In reality, this approach has been the historical way to interconnect laboratory devices to manage them and manipulate their data.
• Laboratory equipment isolation from broader network environments to limit exposure. This approach extends standard network segmentation practices to laboratory systems, controlling their exposure without fully isolating them, and maintaining necessary data flows for operations. It is cost-effective and easy to deploy, making it ideal for older systems that cannot be patched.
• Edge devices for protocol translation and network isolation. These devices are highly effective for environments needing real-time data exchange between incompatible systems.

Figure 2: Pharmaceutical network architecture implemented with laboratory equipment protection measures.

While these solutions help secure industrial environments, they also introduce new challenges such as patch management and equipment ownership — critical factors in maintaining long-term security. Ultimately, these are responses to an initially unsecured situation, and therefore not perfect: for instance, using workstations as gateways is a good practice, but it requires patching, lifecycle management, and can come with added costs and increased footprint in server rooms (increased infrastructure requirements).

The choice of solution to mitigating cybersecurity risks must align with organization’s technical constraints and operational context. A few common practices help illustrate the diversity of strategies:

• Laboratory equipment isolation in a dedicated VLAN remains an effective first step. However, even segmented systems must rely on secure communication protocols to ensure data integrity and prevent unauthorized access.
• Edge devices offer another layer of protection. But they come with their own set of challenges, particularly around organizational ownership, management and maintenance responsibilities.
• Workstation equipped with cybersecurity tools often act as gateways by default, converting data into formats that can be read and processed downstream — whether by LIMS, cloud platforms, or internal databases. This setup is common and secured as long as the workstation is properly managed and hardened to avoid becoming single points of failure or introducing additional attack surfaces. Implementing this intermediary layer is ideal but this requires developing or integrating reliable translation mechanisms, sometimes not handled by the vendor.

Conclusion: Strengthening Cybersecurity in Laboratory Environments

In given industries, ensuring the integrity of data, quality of final product and the safety of consumers remains one of the priorities. However, as laboratories become increasingly digitalized and interconnected, new use cases are emerging that challenge traditional architectures and operational models. This evolution demands a more comprehensive, end-to-end approach to cybersecurity—one that integrates technical safeguards, process maturity, and clear governance throughout the laboratory ecosystem.

Implementing a cybersecurity-by-design approach throughout the entire project lifecycle is essential—not only to anticipate risks early but also to support business teams in integrating security seamlessly into their operations.

The Cyber Resilience Act (CRA) will reinforce the cybersecurity of digital assets within the European Union for manufacturers as well as importers and distributors of such assets.

To go further: Cyber Resilience Act: A revolution redefining product security and transforming the ecosystem – RiskInsight

Cet article Protecting Connected Instruments: A Growing Challenge for Laboratories est apparu en premier sur RiskInsight.

In 2024, the number of connected IoT devices worldwide was estimated at around 18 billion, more than double the world’s population. From connected alarms to smart elevators, industrial sensors, and medical devices, these technologies now shape our daily lives. 

Recent advances in the field of IoT have transformed the way we interact with connected objects. Designed to be intuitive, they are accessible without specific expertise. The connections between them, often wireless, go almost unnoticed by users. However, behind this apparent simplicity lie sophisticated communication protocols, including MQTT.  

Due to its popularity and growing presence in sensitive operations, MQTT has been the subject of research for several years regarding the risks associated with its use. Here, we will focus on how it works, its potential vulnerabilities, and best practices for ensuring secure communications. 

MQTT and the reasons behind its popularity 

This protocol’s strengths 

Developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom), MQTT was designed to provide a lightweight, efficient solution with low energy and bandwidth consumption for monitoring isolated oil pipelines in the desert via satellite link. 

It is precisely because of these fundamental properties that MQTT has now established itself as the standard for IoT data transmission. This protocol is also frequently used to upload data from sensors or connected objects to cloud platforms. 

Figure 1 – MQTT key features 

How it operates 

Definitions of key terms 

MQTT Client: A device that exchanges information. 

MQTT Broker: An intermediary entity that allows MQTT clients to communicate and through which all MQTT messages pass. Specifically, the broker receives published messages and distributes them to the relevant recipients (subscribers to the corresponding topic).  

Topic: A string of characters used to filter and organize messages according to a hierarchical structure. When a client posts a message, they associate it with a topic.  

Publish/Subscribe: A model derived from the classic client/server model, in which requests are not initiated by a client requesting resources from a server, but by a server regularly sending updates to clients without active solicitation.

MQTT is a “Machine to Machine” or M2M communication protocol that operates according to a Publish/Subscribe model, allowing for great flexibility in its implementation. 

MQTT clients can take on the role of publisher, subscriber, or both.  

To receive the information they need, subscribers subscribe to topics (1), which are generally organized hierarchically within the broker (e.g., Home/Room/etc.). When a publisher sends a message intended for subscribers to that topic (2), they are notified by the broker (3).

As a result, MQTT clients are not required to share the same network or be active at the same time, and do not need to be synchronized with each other.  

Figure 2 – Illustration of a simplified MQTT architecture 

Moreover, MQTT offers a “Quality of Service” mechanism for its messages, allowing communications to be tailored to the requirements of the application. For example, it can guarantee message delivery in the event of an unstable connection. MQTT clients can select one of three QoS levels for the distribution of their messages: 

• QoS 0 « At most once » – The message will be delivered once or not at all, without acknowledgment. 
• QoS 1 « At least once » – The message will be delivered periodically until the sender receives an acknowledgment.  
• QoS 2 « Once » – The message is guaranteed to be delivered once and only once. 

The chosen QoS level also affects how long the message is stored locally by the sender and recipient.  

This architecture enables decentralized and scalable communications. These features are particularly advantageous in the IoT field, where flexibility is essential to accommodate a wide range of use cases. They also explain why MQTT extends far beyond the IoT and finds applications in many other environments, such as telemetry and industrial monitoring. 

Is MQTT vulnerable? 

Like many other communication protocols, MQTT is not secure by default. Although most implementations now incorporate robust security solutions, certain weaknesses and configuration errors persist, leaving systems vulnerable. 

To illustrate these concepts, we will look at a standard example of how this protocol is used in an industrial environment. 

Figure 3 – Illustration of an example of industrial use of MQTT 

In this scenario, all systems represented contain an MQTT client that allows users to subscribe to topics and communicate with the on-premise broker. MQTT communications are unencrypted and there is no authentication of the broker or clients, leaving it possible for an attacker to access production data exchanged in clear text or to send commands to equipment by impersonating the broker or one of its clients. 

How can you protect yourself? 

To effectively mitigate these risks, the broker and MQTT clients must be carefully deployed and configured. Here we propose various security measures to ensure confidentiality, integrity, authenticity, and availability of end-to-end communications. 

Securing the MQTT broker 

Enabling default encryption for communications 

When port 8883 is the only MQTT port defined, unencrypted communication attempts on the broker are rejected. Furthermore, it is essential that the broker has access to a valid certificate and private key and that the cryptographic suite used is secure (e.g., TLS 1.2 or 1.3).  

Figure 4 – Enabling encryption on a Mosquitto MQTT broker via a configuration file 

Many IoT devices have low computing power and limited resources, so adding mechanisms such as TLS can represent a significant overhead. 

Implementation of customer authentication and control of their access rights 

MQTT allows the authentication of clients connecting to a broker using common methods such as a username and password (with an associated password file) and verification of the client’s certificate, validated by a certification authority (the broker must have the certificate from this authority). Some brokers also allow the use of external authentication solutions. 

To restrict subscriptions or publications on certain topics by clients, an Access Control List or ACL logic can be added.

Figure 5 – Addition of a certificate and password authentication with access control on a Mosquitto MQTT broker 

Strict management of topics is essential to prevent data leaks and limit the risk of compromising the broker. The use of wildcards # and + must be carefully monitored, as an overly permissive configuration would allow an attacker to access all ongoing exchanges. 

Deployment of broker protection measures    

A quick search on the Shodan search engine reveals thousands of MQTT brokers exposed on the Internet, often left in their default configuration, whose users are unaware of their existence or implications. It is therefore essential to protect the broker from both internal and external threats by applying good security practices, such as regularly updating the system or restricting the number of simultaneous requests and connections, to prevent denial-of-service attacks and ensure its availability. 

Securing MQTT clients 

Enabling communication encryption 

To connect to the broker, clients must use port 8883 and have a valid certificate and private key, otherwise the connection will be rejected.

Figure 6 – Encrypted connection on an MQTT Paho client 

The use of self-signed certificates to connect to the broker is strongly discouraged because they can be easily substituted.  

Implementation of broker authentication (mutual authentication) 

In addition to client authentication, MQTT supports broker authentication by verifying the certificate authority that signed its certificate, thus ensuring mutual authentication (mTLS) and secure communications.

Figure 7 – Broker authentication on an MQTT Paho client 

Implementation of customer protection measures 

If an MQTT client is compromised, an attacker could access a significant amount of information depending on the configuration of the targeted broker. This is why clients, and their secrets, must also be protected by applying good security practices on the client’s host machine and on the content of exchanges (e.g., adding anti-replay mechanisms to requests).  

What does the future hold for MQTT? 

Despite its maturity, MQTT remains an evolving protocol and is gradually incorporating innovative features to meet the growing demands of connected environments. In a context where demand for reliable, secure, and low-power communications continues to increase, it is likely that MQTT use cases will continue to multiply in the coming years.

Cet article The security of the MQTT protocol est apparu en premier sur RiskInsight.

However, this evolution highlights specific cybersecurity challenges associated with these systems, prompting industrial companies to consider how to secure these applications. 

What opportunities does Artificial Intelligence bring? And what are the potential cybersecurity risks that come with it?  

AI & Industry 

To better understand the range of possibilities offered by these technologies, Wavestone has created the 2024 Generative AI Use Case Radar for Operations. This radar lists the usage trends observed among its industrial clients, as well as other potential use cases that may develop in the coming years:  

Figure 1 – Generative AI use cases Radar for Operations 

Wavestone has identified four types of use cases (decision support, tool and process improvement, document generation, and task assistance) that impact various industrial functions (production, quality, maintenance, inventory management, supply chain, etc.). 

Figure 2 – Main uses of generative AI in industrial operations 

Here are some concrete examples illustrating how these technologies integrate into the operations of various sectors, what they bring, and the potential impacts of cyberattacks on these systems: 

Figure 3 – Real AI use cases in industrial sector 

These systems provide significant technological and strategic advantages, as well as considerable financial or time savings. 

However, integrating these technologies can also introduce new risks that companies must consider. 

AI Cyber Risks 

How can an attacker compromise these systems? 

There are several categories of AI-specific attacks, all exploiting vulnerabilities present in different phases of these models’ lifecycle, providing a broad attack surface:  

Figure 4 – AI lifecycle: possible attacks  

Most of these attacks aim to divert AI from its intended use. The objectives can include extracting confidential information or making the AI perform unauthorized actions, thereby compromising the security and integrity of the systems. 

To understand these attacks in detail, Wavestone’s experts have illustrated evasion and oracle methods in this dedicated article. 

What is the situation regarding these risks for industrial companies? 

As it stands, the risks associated with AI in the industry vary greatly depending on the sector and its application. 

To carry out oracle, manipulation, and prompt injection attacks against an AI system, being able to interact with it by providing input data is crucial. This is feasible with some generative AIs, like ChatGPT, which require a user input to start operating. Conversely, other systems, such as those used for predictive maintenance (AI based solutions that anticipate and prevent equipment failures), do not rely on human instructions to function, making interactions more complex. Moreover, the types of input data for these systems are often very specific, hard to obtain, and manipulate. 

Data poisoning attacks could be an alternative, as this method does not require interacting with the AI system. However, this would first require infiltrating the information system to gain access to the AI, deeply understanding its architecture, and then attempting to alter its behavior- with no guarantee of success. Moreover, companies with a good level of cybersecurity already have countermeasures and protection methods in place which significantly reduces the chances of such an attack succeeding. 

Comparatively, other methods that do not specifically target the AI system can be easier to implement and may provide an attacker with a greater opportunity to cause harm to a company. 

However, some AI applications, like generative AI assistants, are vulnerable to input-based attacks mentioned above. 

Here is an example of an attack scenario on the vaccine production assistant shown in Figure 3. 

Context of the use-case 

Employees write their request to the assistant, attaching the specifications of the vaccine to be produced. The assistant runs the analysis and, using a RAG module (which provides the AI with additional data without retraining), cross-references this information with the company’s database. Finally, the assistant returns a machine instruction file to employees, which they can use directly to launch production.  

Attack scenario 

 Figure 5 – Attack scenario killchain on vaccine production assistant 

The consequences of a theft of trade secrets such as this could include the resale of this information to competitors or its public disclosure, which could have significant financial and reputational implications. However, conventional access management security measures can help to reduce the risk of this type of attack. 

Finally, although some AI applications are vulnerable to new attacks, specific security measures tailored to the weaknesses of each system ensure effective protection. 

So, what are the points to remember? 

After all, the risks associated with AI technologies for industrial companies are not fundamentally new. 

Although some AI systems are vulnerable to new attacks, the cybersecurity principles for protecting against them and limiting their impact remain unchanged. 

It therefore remains essential to adopt a risk-based approach and integrate cybersecurity by design for any AI application.  

Cet article Artificial Intelligence, Industrials, and Cyber Risks: What’s the Current State? est apparu en premier sur RiskInsight.