The Cyber Resilience Act (CRA) fundamentally changes what it means to maintain embedded industrial connectivity. For device makers, connectivity is no longer just a technical implementation. It becomes a regulated part of the product that requires secure development, ongoing vulnerability management, firmware update mechanisms, documentation, and long-term lifecycle support.
For device makers relying on in-house chip + stack solutions, this creates a significant and ongoing compliance burden. Skills, processes, and resources that were once sufficient for a functional implementation must now be extended to cover a regulated lifecycle, not just at launch, but for the full operational life of the product.
Anybus CompactCom addresses this directly. By replacing in-house connectivity with a ready-made communication interface developed, tested, documented, and maintained by HMS, device makers can transfer a significant part of the connectivity-layer cybersecurity workload to HMS, while retaining clear ownership of the complete device and its CRA conformity.
This document explains what HMS provides, how it reduces the compliance burden in practice, and what remains the device maker's responsibility.
Using the Anybus CompactCom doesn't remove the device maker's responsibility for CRA compliance of the complete product. It reduces the scope, effort, and risk related to the communication interface.
The table below maps the key CRA-related responsibilities against what HMS provides through Anybus CompactCom, and what remains with the device maker.
CRA area | What HMS provides | What you retain |
| 1. Development processes & evidence | Anybus development follows certified secure development processes:
Security functions are built into the communication layer, including authentication, encryption, and secure boot. | Secure development processes for the host application and complete device. |
| 2. Vulnerability monitoring & disclosure | HMS operates a dedicated product security function, including:
| Monitoring and responding to vulnerabilities in the host application and other device components. Reporting vulnerabilities in Anybus CompactCom to HMS. |
| 3. Connectivity scope & ownership | Anybus CompactCom provides a ready-made industrial network interface, removing the need to develop and maintain protocol stacks internally. HMS takes responsibility for the communication interface security and its ongoing maintenance. | Full responsibility for the complete device, including host application, configuration, risk assessment, and CRA conformity. |
| 4. Update & patch management | Anybus CompactCom 40 only accepts firmware digitally signed by HMS, ensuring integrity of updates. The IIoT Secure variant additionally verifies firmware integrity at every boot. HMS supports three device firmware update scenarios. See the Firmware section for full details. | Firmware update mechanisms for the host application. Coordinating host and ABCC firmware updates to maintain version consistency. Documenting the update process for machine builders. |
| 5. Third-party dependencies | HMS validates and maintains embedded software components, including open-source elements. SBOMs for relevant Anybus CompactCom firmware are available on request. | SBOM maintenance and third-party component tracking for the host application and other device software. |
| 6. Documentation & lifecycle traceability | HMS provides a comprehensive set of security documentation:
Guide: covering intended use, trusted network configuration, secure-by-default settings, disabling unused ports and services, and available secure channels. | |
| 7. Legacy products & future strategy | Using Anybus CompactCom reduces the long-term effort of maintaining, updating, and securing embedded connectivity across product generations. HMS manages the connectivity lifecycle, so device makers do not need to sustain this capability internally over the full product lifecycle. | Long-term compliance planning and documentation for the complete device. |
For device makers already using Anybus CompactCom, the CRA creates a clear case for standardizing and expanding its use across more products, variants, and future platforms.
Without a consistent connectivity strategy, each product variant or platform generation may require separate security processes, documentation, and update mechanisms - multiplying the compliance effort over time. By standardizing on Anybus CompactCom, device makers can manage connectivity security, updates, and documentation through a single, proven HMS lifecycle rather than maintaining this effort product by product.
CRA makes consistent use of a proven, maintained communication interface more valuable than ever.
One of the more complex CRA obligations for device makers is vulnerability management, not just for their own product, but as part of a wider supply chain.
Under the CRA, the machine builder, device maker, and connectivity provider each hold the role of manufacturer of a product with digital elements. Each is obliged to address known exploitable vulnerabilities in their product. In practice, this creates a chain of responsibility:
Figure 1. The CRA vulnerability management chain, from industrial facility owner to connectivity provider, with security advisories and updates flowing back through the supply chain.
The CRA imposes tight deadlines on vulnerability processing, requiring manufacturers to establish a Product Security Incident Response Team (PSIRT) capable of responding promptly to incoming reports. Each manufacturer must also monitor vulnerabilities in the components they use, not only those reported by customers.
This is a significant operational burden for device makers, particularly those without existing security processes or dedicated security resources.
From an HMS perspective, the vulnerability management infrastructure for Anybus CompactCom is already in place:
When device makers use Anybus CompactCom, they benefit from this infrastructure directly. Rather than building and maintaining their own vulnerability monitoring and disclosure capability for the connectivity layer, they can rely on HMS to manage this, and receive structured, timely information when vulnerabilities are identified.
Vulnerability management is one of the most operationally demanding CRA obligations. For the connectivity layer, HMS handles it.
Firmware update management is another area where the CRA introduces practical complexity for device makers, particularly where a device is integrated into a machine.
A device using Anybus CompactCom typically has at least two firmware components that require updating:
In most cases, the device maker requires the ABCC firmware to match the host firmware, as the two are tested together and are not independently interchangeable. This means firmware updates must typically be coordinated, with both components updated as a compatible pair.
HMS supports all three practical update scenarios:
Figure 2. A device with Anybus CompactCom contains two firmware components, the Anybus CompactCom and the host CPU. Firmware on each component can be updated via the console port, the Ethernet interface, or a combination of both.
At the machine level, the challenge is greater. Just as the device maker tests host and ABCC firmware compatibility before release, the machine builder needs to validate firmware compatibility across all devices in the machine before deploying an update. This means machine updates are typically packaged as a single update covering all components, rather than updated device by device.
From a usability perspective, this requires a single update interface for the complete machine. In practice, the console port of an individual device is often not accessible to the end user in a deployed machine. The only feasible path for a complete machine update is therefore to update both the host and ABCC firmware via the Ethernet interface.
HMS supports this scenario. The ABCC firmware can be updated via the Ethernet interface, allowing it to be included in a coordinated machine-level update alongside the host firmware. This maintains version consistency across all components without requiring physical access to individual devices.
Figure 3. A machine-level firmware update is coordinated through a single upgrade interface, allowing the PLC, connected devices, and their embedded communication interfaces to be updated together, maintaining version consistency across all components.
Supporting machine-level firmware updates via the Ethernet interface is essential for practical CRA compliance in deployed machines. HMS supports this out of the box.
HMS offers two main Anybus CompactCom 40 variants. The right choice depends on the intended use and operating environment of the device.
Standard Anybus CompactCom 40 variants are appropriate for devices operating within trusted, segmented industrial networks with restricted access and defined operating conditions. When integrated according to the intended-use guidance in the Security Device Integration Guide, Anybus CompactCom 40 provides sufficient CRA-relevant connectivity security for OT environments.
Figure 4. Anybus CompactCom 40 provides sufficient CRA connectivity in trusted OT environments.
For devices that require IT or IIoT connectivity, web access, or secure communication outside trusted networks, Anybus CompactCom 40 IIoT Secure is the recommended path. It provides additional protection mechanisms including:
Figure 5. The Anybus CompactCom IIoT Secure provides the required CRA connectivity in IT/IIoT-connected applications.
IIoT Secure reduces the need for additional external security measures. such as firewalls and enables secure communication in IT-connected and IIoT applications. IEC 62443-4-2 certification from TÜV is planned during 2026.
Whether your device operates in a trusted OT network or an IT/IIoT-connected environment, there is an Anybus CompactCom variant designed to meet your CRA connectivity requirements.
Using the Anybus CompactCom significantly reduces the scope of connectivity-related CRA work. It does not remove the device maker's responsibility for the complete product. The following responsibilities always remain with the device maker, regardless of the connectivity approach used:
The Security Device Integration Guide provided by HMS gives practical recommendations on intended use, secure-by-default configuration, and integration guidance, supporting device makers in meeting these responsibilities efficiently.
The goal is not to remove responsibility, but to reduce the scope, effort, and long-term risk of maintaining CRA-compliant connectivity.
Dr. Jens Jakobsen
Product Security Manager, HMS Networks
Dr . Jens Jakobsen is Product Security Manager at HMS Networks, where he leads the company’s work to strengthen the cybersecurity of industrial communication products and protect connected equipment from emerging threats. He brings extensive experience from technical and leadership roles at HMS Networks, Schneider Electric, and Motorola Solutions, and has worked for many years with industrial communications and cybersecurity. Dr. Jakobsen holds seven granted patents in telecom and industrial communication technologies.
