Most industrial device makers and machine builders don’t yet realize it, but the Cyber Resilience Act (CRA) fundamentally changes what it means to build a connected industrial device.
Not because cybersecurity is new, but because CRA formalizes long term responsibilities for any digital elements embedded in industrial equipment and sets clear expectations for CRA compliance across connected industrial devices. As an EU regulation, the CRA applies to all products with digital elements placed on the European market, regardless of where they are manufactured¹.
And here is the uncomfortable truth: If you develop, own, or brand the connectivity inside your device, the CRA makes you fully responsible for proving that it is secure, updatable, and properly maintained throughout its entire lifecycle.
This article explains what that responsibility looks like in practice and answers a question many manufacturers are now asking: what does the CRA actually mean for companies that build their own connectivity?
Figure 1. CRA Responsibility chain – who owns or brands connectivity owns the CRA liability
CRA applies to “products with digital elements,” meaning hardware and software that have, or enable, direct or indirect network connectivity. This includes embedded communication interfaces, protocol stacks, wireless modules, gateways, or any custom developed connectivity solution.
What is new is not that connectivity introduces cybersecurity considerations. It is that CRA treats connectivity as a regulated part of the product, one that must be secured, documented, and maintained over time.
In practice, this means:
Although discussion in the industry sometimes suggests the dates might shift, the CRA deadlines are clear:
Figure 2. CRA key deadlines
Harmonized standards are still being finalized, but development is progressing, and there is currently no strong indication that the 2027 deadline will be postponed.
Figure 3. The current development status of the harmonized standards and supporting documents expected to underpin CRA conformity.
One of the most common questions we hear is: What security obligations does the CRA introduce for device makers and machine builders?
The short answer is that CRA goes far beyond improving cybersecurity. It introduces mandatory security and lifecycle requirements that apply for as long as the device is on the market, often 10–15 years or more.
Figure 4. CRA security obligations
These obligations are formal, evidence based, and subject to assessment². CRA requires:
Manufacturers must demonstrate that the connectivity in their product is developed and maintained under a structured, repeatable, and auditable security process. Informal or ad hoc practices are not enough.
CRA requires ongoing processes for:
This responsibility does not end at product launch. It applies throughout the device’s entire operating lifetime.
Manufacturers must document:
This becomes especially challenging when connectivity stacks contain older or inherited code.
If your device or machine is expected to operate for more than ten years, you must have the capability and organizational commitment to deliver secure updates throughout that period.
CRA requires maintainable evidence, including:
For many, this type of documentation simply does not exist for in-house connectivity stacks.
CRA introduces strict consequences:
CRA conformity is no longer just a regulatory requirement. It is rapidly becoming a customer requirement.
Figure 5. Consequences of non-nompliance
A common misconception is believing that existing internal cybersecurity practices meet CRA expectations. Many teams also ask: How does CRA affect in house connectivity solutions that were built years ago?
In reality, informal or ad hoc security efforts fall short because CRA demands:
Many device makers and machine builders underestimate the gap between their current approach and the rigor CRA requires. This is especially true when teams rely on legacy protocol stacks, unmaintained open source components, or undocumented integrations.
Based on decades of experience helping device makers and machine builders integrate communication technology, HMS Networks frequently sees two main categories of blind spots when companies prepare for CRA readiness: Blind spots in owned connectivity and blind spots related to third party suppliers.
Both areas create significant compliance challenges under CRA’s long term security and lifecycle expectations.
Legacy protocol stacks
Many were developed years ago, lack modern security controls, and cannot easily be brought up to today’s standards.
Unmaintained open source dependencies
Connectivity stacks often include open source components that now must be documented, monitored, and patched.
No formal vulnerability response process
Teams typically address issues as they arise, but CRA requires a documented, continuous process.
Limited long term maintainability
In house connectivity solutions often rely on individuals or aging codebases that cannot meet ten to fifteen years of update obligations.
These blind spots are understandable. Connectivity has historically been viewed as a functional requirement, not an industrial cybersecurity concern.
CRA requires device makers and machine builders to ensure that third party hardware and software used in their products meet security requirements. This is often underestimated and can become one of the most difficult parts of CRA conformity.
Hardware dependencies
CRA applies to any hardware component that can influence product security, including microcontrollers and secure elements.Many older components are being moved into “spare part lifecycle” and will be exempt from CRA. When this happens, the entire security obligation transfers to the device maker.
Manufacturers will increasingly need a CRA Declaration of Conformity from hardware suppliers.
Software dependencies
Operating systems, protocol stacks, and embedded libraries must also have CRA declarations. If they do not, the device maker becomes responsible for monitoring vulnerabilities, issuing patches, and maintaining security throughout the lifecycle, even when source code is not available.
Why suppliers matter more than ever
Third party software and hardware may become the biggest obstacle to CRA compliance. Even if the device maker’s own code meets requirements, noncompliant components from suppliers can block conformity.
If you are wondering what the Cyber Resilience Act means for your long term connectivity responsibilities, the answer is that it creates formal security, maintenance, and documentation obligations that device makers and machine builders can no longer avoid.
Ultimately, every manufacturer must answer a key strategic question:
Who is responsible for CRA compliance inside your connected device, you or your suppliers?
CRA forces manufacturers to think differently about connectivity. It is no longer about making the device talk to a network. It is about owning and proving long term security, documentation, and lifecycle obligations.
This leads to the next question:
Do you truly want to own all the security, maintenance, and compliance obligations that come with developing and branding your own connectivity?
We will explore this further in the next article, Why CRA Is painful, but necessary, where we examine hidden costs, organizational burdens, and why this shift ultimately benefits the industrial ecosystem.
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
