OT & IoT Cybersecurity Report 2024
This whitepaper targets security teams of industrial automation and control systems (IACS) asset owners and product suppliers.
.avif)
Table of content
Product Security Lifecycle for Industrial Automation & Control Systems
Mitigating supply-chain risks is one core requirement of IEC 62443
Integrate automated SBOM into processes automate SBOM generation & link to known vulnerabilities
No shortcut to IEC 62443 compliance!
EXECUTIVE SUMMARY
Industrial control systems, known as Operational Technology (OT), along with the Internet of Things (IoT) and Industrial IoT (IIoT), form the digital backbone of Industry 4.0. Today’s production,logistics, and operational processes are virtually unimaginable without OT and IoT. Connected devices, machines, and systems that continuously exchange dataare at the heart of modern industry.
However, this growing connectivity and digitalization also brings new challenges: robust cybersecurity measures are essential, as IoT, IIoT, and OT systems often need to meet high security requirements despite vulnerable software. In 2024, the cybersecurity company ONEKEY surveyed over 300 IT decision-makers and C-level executives about their perspectives and strategies in cybersecurity. The findings from this comprehensive survey are presented in the OT & IoT Cybersecurity Report 2024.
Growing Awareness of Cyber Threats: Nearly 75% of companies recognize that hackers are increasingly targeting industrial control systems and IoT devices.
Insufficient Protective Measures: Many companies lack adequate defenses against cyberattacks, with gaps in realistic risk assessment, effective prevention strategies, and actionable response capabilities.
Compliance Knowledge Gaps: Numerous companies are insufficiently informed about relevant compliance requirements, with nearly half unaware of technical cybersecurity standards.
Outdated Firmware as a Vulnerability: Outdated firmware in devices and machines is increasingly exploited by hackers as an entry point. Attacks on unprotected firmware can be devastating, potentially halting entire production batches.
Lack of Software Bill Of Materials(SBOM): Over half of companies lack complete SBOMs, even though they are essential for effective cybersecurity.
Budget Constraints: 60% of companies rate their cybersecurity budget as inadequate oruncertain, with only 34% considering it “sufficient” or “significant.”
Insufficient Cybersecurity Processes: Only about a quarter of companies rate the maturity of their cybersecurity processes as adequate, with many lacking measures to enhance security practices and meet compliance requirements.
UNDERESTIMATED RISK: OT AND IOT
The study clearly shows that cybersecurity in OT and IoT poses significant risks, yet many companies are still under prepared. More than half of respondents (52%) have already experienced cyberattacks through OT or IoT devices, with just as many suspecting that cybercriminals are specifically targeting these devices as entry points. Nonetheless, OT and IoT cybersecurity is often considered less critical.
"With over 2,000 new software vulnerabilities identified each month, companies that fail to keep their software updated aren't asking if they'll be targeted by cyberattacks, but when— and how severe the consequences will be." Jan Wendenburg, CEO ONEKEY
Instead, many companies are focusing more on protecting payment and financial systems (42%), corporate networks and datacenters (39%), as well as customer data (36%). Email, cloud services, and appsare also perceived as greater threats, while the risks to OT (OperationalTechnology) and IoT (Internet of Things) are often underestimated.
As digitalization advances at the production and logistics level in German industry, a growing number of security gaps are emerging — creating new points of attack for cybercriminals.
CYBER RESILIENCE: A REALISTIC SELF-ASSESSMENT
Over a quarter (26%) of companies consider their cybersecurity maturity in product and project development to be 'adequate,' thanks to a defined and active security process. An additional 12% have security processes in place but deem their control measures insufficient. Meanwhile, 9% of companies report having no such processes at all.
Companies focus on a variety of measures to enhance their cyber resilience: 36% conduct threat analyses, 23% use penetration testing, 22% rely on intrusion detection systems, and 15% focus onvulnerability assessments. Network segmentation to limit the impact of attacks is implemented by 19% of companies. Notably, 38% of companies consider the security guarantees of their IT service providers and suppliers to be the 'most important' measure.
Regarding budget allocation, one-third of respondents consider the funds for defending against cyberattacks to be 'limited' and see room for improvement. In 27% of companies, the cybersecurity budget situation is unclear. Only 34% have an 'adequate' or 'significant' budget to strengthen their cyber resilience.
"Many companies appear to prioritize cybersecurity only after an incident has already taken place." Jan Wendenburg, CEO ONEKEY
Less than a third (32%) of the companies surveyed in the study have implemented procedures to learn from security incidents and make necessary improvements. Given the ongoing threat landscape, predefined business processes that govern how to handle cyberattacks both during and after an incident should be part of every company’s security repertoire.
On a positive note, a good third (34%) of companies conduct a thorough analysis and assessment of a security incident following a cyberattack, in order to derive concrete improvement measures.
LACK OF KNOWLEDGE OF LEGAL CYBERSECURITY REQUIREMENTS
Starting in 2026/2027, the EU Cyber Resilience Act (CRA) will require all manufacturers of devices, machinery, andequipment selling products in the EU to meet enhanced cybersecurity requirements. However, the study reveals that many companies are not yet adequately prepared for this. Only 28% of the surveyed companies have specific compliance regulations for the security of industrial control systems or IIoT devices. For a third (34%), OT or IoT security regulations are part of the company's general cybersecurity policies but are not specifically addressed. Alarmingly, 19% of companies have made no special provisions in this area. One-fifth of respondents were either unable or unwilling to provide information, indicating significant uncertainty and a high level of unknowns.
Less than a third (29%) of respondents report being familiar with the regulations and cybersecurity standards relevant to their industry. About a third (34%) have limited knowledge, while 25% have no knowledge at all. Given typical development times of two to three years, companies that do not act in time risk being unable to sell their products in the EU starting in 2027 if they have not met the requirements by then.
Additionally, 46% of the surveyed companies were unable to specify which cybersecurity standards are relevant to their product development. The importance of these standards is often under estimated: only 23% consider the EU Cyber Resilience Act (CRA) to be relevant. Other standards, such as IEC62443 (20%), EN 303 645 (16%), EN 21434 (14%), and UNR155 (8%), are also seen as important by only a minority. This highlights the significant information gap regarding compliance.
INADEQUATE SECURITY TESTING AND PATCH MANAGEMENT FOR IOT DEVICES
When procuring IoT devices, only 29% of industrial companies conduct thorough security tests. 30% limit themselves to superficial tests or sampling, while 15% perform no security checks at all. There maining companies did not provide any information on this matter.
A similar pattern emerges when analyzing device firmware: less than a third (31%) of companies conduct regular security tests to identify vulnerabilities in the embedded software. 47% test the firmware only occasionally or not at all, and 22% did not provide any information on this matter.
"Anyone who delays applying a patch exposes themselves to significant risk, as cybercriminals specifically exploitthe time window between discovery and resolution." Jan Wendenburg, CEO ONEKEY
Regarding software updates, 33% of companies update their devices immediately after a patch becomes available. In contrast, 31% wait until the next scheduled release, while 10% provide no further updates after delivery. An additional 26% of respondents are unsure about their devices' update policies.
When asked if the cybersecurity of already deployed devices is checked, 28% of companies respond that they do so automatically. 30% conduct occasional manual checks, while 17% perform nofollow-up security assessments. However, waiting for scheduled updates poses significant risks, as cybercriminals often exploit the time window between discovery and resolution.
SBOM: IMPLEMENTATION STILL LACKING
According to the survey, fewer than a quarter (24%) of industrial companies maintain a complete Software Bill Of Materials (SBOM). While software for computers and networks is usually documented, many companies lack an overview of the software in devices, machinery, and equipment. This is problematic, as outdated software in controlsystems is a common entry point for hackers. Typical examples include manufacturing robots, CNC machines, and building automation systems. These systems are connected to the company network, creating a significant attack surface. However, the majority of companies either have no SBOM or only an incomplete one.
TRAINING AND AUDITS: ESSENTIAL FOR STRONG CYBERSECURITY AWARENESS
A positive trend is emerging, but there is still significant room for improvement. 40% of industrial companies offer their employees regular cybersecurity training and workshops. 27% have integrated cybersecurity rules into their employee handbooks and company policies.
Additionally, 62% of the surveyed companies conduct regular cybersecurity audits. 24% rely on external assessments, 18% on internal audits, and 20% use a combination of both approaches. However, formore than a third of companies, it is unclear whether and to what extent regular cybersecurity reviews are conducted.
BACKGROUND
NEW EUROPEAN CYBER RESILIENCE ACT (CRA) AIMS AT INCREASING SECURITY LEVEL AND TRANSPARENCY
On September 15, 2022, the European Union Agency for Cybersecurity (ENISA) published the draft of the new Cyber Resilience Act (CRA), which came into force on December 10, 2024, following adjustments and approval by the EU. The CRA applies throughout the European Union and worldwide to all manufacturers, importers and distributors of products with digital elements that market their products in the EU.
The CRA aims at increasing the level of security of all products with digital elements within the European Union by requiring manufacturers to implement and maintain a cybersecurity framework and to follow this framework throughout the product’s lifecycle. Additionally, enhanced transparency about security properties will enable consumers and businesses to take security-conscious decisions and use products with digital elements more securely.
LIMITED TIME TO ACT FOR PRODUCTS WITH DIGITAL ELEMENTS
This initiative by the ENISA follows increasing damage caused by cybercrime, which resulted in global costs of more than EUR 5.5 trillion in 2021 . Many of these cyberattacks are caused by vulnerabilities in products with digital elements and aggravated by lack of transparency by manufacturers about relevant security properties. While the CRA targets a broad scope of “products with digital elements”, ranging from operating systems, desktop and mobile applications to hardware devices and network equipment, this whitepaper will focus on connected devices and target manufacturers, distributors, and importers of such devices.
The CRA was adopted by the European Commission as a European Directive in 2024 and came into force on December 10, 2024. This leaves little time – even with the transition period until December 10, 2026 – to adopt the necessary reporting requirements and fulfill the remaining fundamental requirements.Due to multi-year design & development cycles, all manufacturer need to act now. Only devices regulated by Regulation (EU) 2018/1139 (civil aviation), Regulation (EU) 2017/745 (medical devices), Regulation
(EU) 2017/746 (in vitro diagnostic medical devices), or devices certified in accordance with Regulation (EU) 2019/2144 (type-approval motor vehicles and their trailers, and systems, components and separate technical units intended for such vehicles...) are exempt
from the CRA. With the average multi-year timespan between design and production of connected devices this leaves little time
for adoption and applying necessary security changes.
MITIGATING SUPPLY-CHAIN RISKS IS ONE CORE REQUIREMENT OF IEC 62443
Figure 2 demonstrates the 8 practices for product development processes defined in IEC 62443-4-1.
The practices pose requirements to all phases of a product development lifecycle to support and assure defense in depth and secure by design during development but also to have all processes in place to manage security related issues through the products lifecycle. One core requirement of IEC 62443-4-1 is to manage supply-chain risk.
SECURITY CONTROLS MUST COVER SUPPLY-CHAIN TOO
In modern applications, 80%-90% of the code base is made up of third-party software components – open source as well as proprietary. These range from crypto-libraries being used to secure sensitive information to closed-source SDKs to control third-party hardware modules included in the IACS. As a majority of the code base is not under direct control of the vendor, a significant share of an IACS’ risk and exposure is inherited from third-party software components.
THIRD-PARTY RISKS REMAIN HIDDEN
Risks included: Lack of visibility: While direct dependencies and inclusions of third- party components are often known, the supply chain rarely ends there. Third-party components commonly rely on further dependencies, which in turn have dependencies as well. Making the entire supply-chain transparent is even more challenging when the source code of affected components is not available.
THIRD-PARTY SOFTWARE MAY INCREASE THE THREAD LEVEL
Increase the thread level: Development practices as well as security measurements of vendors of third-party open source and commercial off-the-shelf (COTS) software components are rarely vetted. This results in scenarios where a significant part of the final product does not comply with the vendors’ security requirements, which lowers the security posture of the entire IACS environment.
ATTACKERS INCREASINGLY FOCUS ON SUPPLY-CHAIN
Supply chain attacks: Supply chains have moved into the focus of cyber criminals as a lucrative entry-point into their target’s infra- structure. Threat actors have started to actively plant backdoors in open-source components and to spread malware via open-source repositories.The severity of supply chain risks justifies rigorous mitigation efforts. The IEC 62443-4-1 acknowledges these challenges and discusses supply- chain risk from different angles in 3 of the 8 practices.
DEFINE SECURITY REQUIREMENT & ADDRESSSECURITY ISSUES
Practice 1 – security management (SM) contains security requirements for externally provided component (SM-9) and to assess and address security related issues (SM-11). A process must be established to identify third- party providers and assess the associated risks of third-party components taking their role in the product's secure design and defense in depth strategy into account. Additionally, it must be assured that all security-related issues – including such issues that are inherited by third-party dependencies – are addressed prior release.
TEST 3RD-PARTY SOFTWARE FOR VULNERABILIETIES
Practice5 – securityverificationand validation testing (SVV) includes requirements for vulnerability testing (SVV-3). Vulnerability testing is required for the entire product including any third-party dependencies. As such, as part of this requirement, also third-party code needs to be tested for known vulnerabilities and configuration issues.
MANAGE EMERGING THREATS
Practice 6 – management of security-related issues (DM) defines requirements for receiving notifications (DM-1), reviewing (DM-2) and assessing security-related issues (DM-3). This includes monitoring of third-party components, which are integrated into the IACS, for security related events to allow for timely impact assessment and remediation.
.avif)
INTEGRATE AUTOMATED SBOM INTO PROCESSES AUTOMATE SBOM GENERATION & LINK TO KNOWN VULNERABILITIES
The following section delves deeper into those aspects of supply-chain risk and how binary software composition analysis can significantly contribute to automating mitigating controls demanded by IEC 62443-4-1, while reducing manual efforts associated with achieving those requirements at the same time.
Software composition analysis (SCA) describes the automated process of determining the software components (open source and COTS), which are included in a final product. The result of a SCA is a SBOM. As it cannot be assured that source code is available for all software components provided by third parties along the supply-chain, SCA can often only rely on compiled binary representations of a software component.
SM-9: Security requirements for externally provided components By including binary SCA as part of the process to identify and manage security risks associated with third-party components used within the product, the generation of an inventory of software components from third-party suppliers can be automated. This is achieved by deconstructing the binary firmware to assure that all software components, which will eventually be delivered to the users of IACS, can be identified. Static and dynamic methods can be utilized to build a SBOM by identifying software components, associated versions, as well as applied patches. Based on this information, known vulnerabilities, affecting those software components can be identified and further investigated.
SM-11: Assessing and addressing security-related issues Implementing an automated security quality gate with binary SCA as part of the release process will assist the process of verifying that a product or product upgrade is not released until its secu- rity-related issues have been mitigated. To identify such issues as early as possible in the software development process, this security quality gate must be integrated into the build process. By automatically failing release pipelines if the identified security issues exceed previously accepted risk levels appropriated to the intended use-cases and security context, it can be assured that security- related issues originating from third-party software are addresses as early as possible.
SVV-3: Vulnerability testing Performing binary SCA on all executable files to identify known vulnerabilities in the product’s software components and libraries is explicitly mentioned as a requirement as part of vulnerability testing. Additionally, extending SCA by automating analysis of system configuration to highlight misconfigured and insufficiently hardened services, and investigate compiler settings to avoid insecure configurations that foster vulnerabilities can significantly reduce manual efforts and provide a head-start on subsequent penetration tests.
DM-1, DM-2, DM-3 Receiving notifications, reviewing, and assessing security-related issues
Security is not just a one-off effort. It is a process and requires continuous maintenance. Regularly assessing the SBOM of a firmware for newly published vulnerabilities, pro-actively ad- dresses this requirement and supports reviewing and assessing phases of security- related issues by validating applicability to the product and determining impact.
The table summarizes the supply chain risks, the requirements that IEC 62443-4-1 imposes on software development processes of IACS vendors to mitigate these risks, and how ONEKEY’s automation for firmware security analysis supports complying with these requirements.
No shortcut to IEC 62443 compliance!
Stringent security practices as required by IEC 62443-4-1 add significant overhead to existing development life cycles.
Nevertheless, they are a necessity to address today’s elevated security requirements and address the ever-increasing threat landscape. Unfortunately, there is - in general - no shortcut to implement IEC 62443 and related compliance.
There are various tools available to improve documentation, processes and cybersecurity. To simplify and support your IEC 62443 implementation, ONEKEY provides expert ‘s advice and offers consulting resources to support product suppliers.
Check out the key takeaways on the next page and learn how to substantially reduce your efforts during implementation and maintaining compliance with IEC 62443.
ONEKEY 360: Consulting and Automation
In addition to reducing manual efforts by adding automated controls to processes required by IEC 62443-4-1, ONEKEY aids product suppliers in adopting IEC 62443-4-1 with gap analyses and implementation support.
ONEKEY also offers IEC 62443-4-1 compliant managed services to conduct security verification and validation testing, covering requirements of practice 5, and to manage security-related issues, as required by practice 6, supporting with validation, triage, and impact assessments of reported vulnerabilities.
ONEKEY’s technical experts and security researchers are also available to identify gaps to a product’s adherence to IEC 62443-4-2 and to conduct penetration tests and vulnerability assessments on IACS applications, embedded devices, network components, and host devices.
AUTOMATION & SUPPORT TO ACHIEVE & MAINTAIN CRA SECURITY REQUIREMENTS & COMPLIANCE
ONEKEY’S SECURITY EXPERTS’ ADVICE & AUTOMATION
In addition to reducing manual efforts by adding automated controls to processes required by the CRA, ONEKEY aids manufacturers, importers, and distributors of products with digital elements in adopting processes required by the CRA with gap analyses and implementation support.
ONEKEY‘s automated firmware security analysis platform can automatically detect and report violations of essential cybersecurity requirements as defined in Section 1 of Annex I of the CRA. Expanding on ONEKEY’s automated capabilities, ONEKEY’s technical experts and security researchers are also available to identify gaps to a product’s adherence to the CRA and to conduct penetration tests and vulnerability assessments on affected connected devices.
KEY TAKE AWAYS
Manufacturers need to act now to ensure product compliance:
- With attacks on connected devices on the rise, ENISA has defined essential requirements to increase the level of security of connected devices and established a framework to foster cooperation and information sharing on new vulnerabilities and emerging threats.
- CRA provides the toolset to produce such cyber-resilient connected devices, especially from a supply-chain risk’s perspective.
- To meet elevated security and compliance requirements and to tackle supply-chain risks, implementation of automated security and compliance controls, i.e., holistic binary software analysis, are required. Automated initial software analysis and continuous monitoring will substantially reduce efforts for implementation and maintaining CRA compliance.
- The ONEKEY platform automates essential cybersecurity and compliance processes, as required by the CRA. Vulnerability management, assessment, prioritization and monitoring are practically automated, and the required reporting obligation is also met through extensive reporting.
Interested in further discussion with our security experts on how to achieve and maintain your CRA product security compliance? Please contact our security experts at: experts@onekey.com
Ready to automate your Product Cybersecurity & Compliance?
Make cybersecurity and compliance efficient and effective with ONEKEY.