The Cyber Resilience Act (CRA) changes far more than security processes. It changes how industrial organizations organize work, make decisions, and manage long term responsibilities for connected products. Connectivity is no longer just a technical detail or an engineering choice. It is now a regulated product component with security and maintenance obligations that span the entire lifecycle of a device or machine1.
For industrial device makers and machine builders, this creates a strategic decision point:
Should connectivity continue to be developed and maintained internally, or is it time to rethink this approach altogether?
This article explains why CRA disrupts traditional ways of working, where friction often appears inside organizations, what forward thinking teams are beginning to change, and why it may be time to rethink how connectivity is handled.
Let’s begin with a basic question: Why does CRA disrupt long standing workflows for device makers and machine builders?
Before CRA, it was common for manufacturers to focus on functionality first, with security handled elsewhere in the organization. This was understandable. Security requirements were lighter, and connectivity rarely carried regulatory weight. CRA changes this dynamic and brings several realities to the surface, such as:
Historically, security responsibilities often sat in a separate part of the organization, away from product teams. This worked when security expectations were lighter and connectivity was treated as a technical feature rather than a regulated component.
CRA collapses this separation. Because the communication interfaces and update mechanisms used in connected products are now part of the device’s risk surface, security decisions increasingly overlap with design, connectivity, lifecycle planning, and documentation.
This means security can no longer be isolated. Multiple teams must understand and contribute to CRA related decisions.
Connectivity is often reused across product families, platforms, and versions. This means:
Teams can no longer optimize connectivity in isolation. Decisions must take the wider product portfolio into account.
As outlined in our CRA is redefining industrial connectivity article, many manufacturers historically relied on informal security practices or “best effort” approaches. CRA raises the bar by requiring:
‘Best effort’ security or ad hoc updates no longer meet CRA expectations.
CRA introduces new work that cuts across teams with different priorities. This can create natural friction unless responsibilities are clearly defined. For example:
Figure 1: Organizational alignment challenges and non-optional touchpoints forced to the surface by the Cyber Resilience Act (CRA).
R&D teams generally prioritize architecture, technical feasibility, and ensuring that connectivity and security mechanisms are implemented correctly.
On the other hand, product management usually focus on market timing, customer expectations, and delivery dates.
Under CRA, these perspectives must come together. Decisions about redesigns, update mechanisms, and evidence requirements directly affect both delivery timelines and long term compliance. These trade offs can no longer be solved informally, CRA makes alignment essential.
Figure 2: Ongoing maintenance becomes the dominant cost - especially for lower-volume products
Product teams are usually focused on innovation, features, and keeping development moving. Legal and compliance teams focus on conformity documentation, acceptable risk levels, and ensuring CRA obligations are met.
Before CRA, these perspectives could often coexist with limited friction. Connectivity costs were largely predictable and front loaded:
CRA fundamentally changes this balance.
After CRA:
In other words, connectivity is no longer primarily a per product hardware cost. It becomes a long term software and organizational commitment2.
For lower volume products in particular, the cost of maintaining secure connectivity over time can quickly outweigh the original hardware and development investment. What was once a marginal cost becomes a dominant one.
This shift brings product teams and legal/compliance teams into unavoidable alignment. Decisions about redesigns, update mechanisms, acceptable risk levels, and required evidence now have long term cost implications and can no longer be postponed or handled informally.
A central security team may define policies for secure development and lifecycle management. But individual product teams may feel these expectations are difficult to apply with their current schedules or architectures.
In conclusion, CRA exposes any gaps between policy and reality. To avoid friction, organizations need clear handovers, shared expectations, and aligned responsibilities for updates, security evidence, and long term support.
Some device makers and machine builders are already adapting their working models. Their approaches share several common traits:
Define exactly:
This reduces confusion, delays, and last minute compromises.
Formalize how information moves between teams such as:
Each team should know what information they must provide and what they can expect from others.
Instead of adding security late in the process, it’s better to:
Taking these considerations early reduces rework and delays.
These improvements don’t remove work, but they reduce friction and uncertainty around who is responsible for what.
Figure 3: Connectivity under CRA: five key obligations across the product lifecycle
Connectivity is one of the first areas where CRA pressure becomes unavoidable for device makers and machine builders. There are several reasons for this.
Under CRA, connectivity shifts from a one off development effort to a long term software maintenance and organizational responsibility, fundamentally changing its cost profile.
For lower volume products in particular, the cost of ongoing security maintenance can quickly outweigh the original hardware and development investment. This often forces manufacturers to reassess whether it is still practical to own connectivity internally.
Connectivity is reused across multiple products
One connectivity solution often supports several product lines. A single issue can affect:
Because connectivity components are reused across multiple products and tied directly to secure by design requirements, they are often one of the first areas where CRA pressure becomes impossible to ignore.
If connectivity fails, customers feel it immediately:
When CRA adds security expectations on top, the impact becomes even greater.
Under CRA, connectivity is no longer just a way to speak PROFINET or Modbus.
It is:
Secure industrial networks such as PROFINET Security Class 2/3 and CIP Security are rapidly evolving. These changes may require firmware updates, protocol revisions, or even new communication hardware in the future.
Connectivity decisions made today must account for these long term shifts, not just CRA requirements.
In summary, connectivity becomes one of the first areas where CRA pressure becomes impossible to ignore, making it a natural place for manufacturers to reassess their overall strategy.
Before closing, it is worth asking one final question:
What does a sustainable connectivity strategy look like for device makers and machine builders in a post CRA world?
CRA does more than introduce new documentation or testing requirements. It changes how manufacturers must think about connectivity across teams, across products, and across the entire lifecycle.
Legacy approaches make CRA compliance difficult because they rely on informal processes, unclear responsibilities, and outdated assumptions about ownership. Forward looking manufacturers are already adapting by:
Connectivity is no longer just a functional choice. It is a strategic decision that shapes long term risk, customer trust, support obligations, and organizational efficiency.
For industrial device makers and machine builders, the question is now clear:
Is it still practical to maintain connectivity internally, or is it time to adopt a solution that supports secure, maintained, and CRA ready connectivity for the years ahead?
Whether you are updating existing devices or designing new ones, the right connectivity strategy is key to CRA readiness. Learn more about the Cyber Resilience Act and explore Anybus gateway and embedded solutions that help you build secure, maintainable, and future-ready devices.
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.
References
1. The Cyber Resilience Act - Summary of the legislative text https://digital-strategy.ec.europa.eu/en/policies/cra-summary
2. Cyber Resilience Act - Manufacturers https://digital-strategy.ec.europa.eu/en/policies/cra-manufacturers
