Are Your Devices Ready for the EU’s Cyber Resilience Act?

The European Union’s Cyber Resilience Act (CRA) will fundamentally change how all connected devices must be designed. The CRA governs devices sold within European Union nations, but its impact will be felt far beyond the continent. Conformance with CRA will demand all current and future devices focus on secure deployment, development and use. CRA is the first legislative effort that moves security responsibilities away from the user and towards the device manufacturer.

These new regulations go into effect in December of 2027. This future date is causing alarm across the industry. Why? Because a small percentage of devices sold for use on the factory floor today meet the expected requirements.

This paper will outline the CRA and the technical challenge device manufacturers face. We’ll explore the dissent forming against the CRA. We’ll discuss how these regulations impact implementations of EtherNet/IP, PROFINET and Modbus TCP. Finally, we’ll outline a plan to get your devices ready for CRA.

What Do These Key Requirements Mean in Practice?

For many manufacturers the reporting and documentation required by CRA will seem like ISO certification adapted to security. It’s important to understand that many of the technical requirements related to the CRA are still undefined. The act defined the security outcome needed but not the standards by which those outcomes are measured. Final clarity on these issues is expected in late 2026. This is problematic for device manufacturers. However, there is strong evidence that by aligning to IEC-62443 and serving the goals of NIS2 you will be in a strong position to meet CRA certification.

CRA Requirements in a Nutshell:

• Implement secure-by-design principles
  Building security into products during initial development and design. Both IEC 62443 and the EU Cyber Resilience Act require manufacturers to think about security during design. This includes using threat modeling frameworks like STRIDE to identify risks: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. The key principles are simple: use secure defaults, limit access rights, test for vulnerabilities before release and provide security updates throughout the product’s life.
• Add vulnerability management throughout product lifecycle
  Device vendors must actively test their devices for vulnerabilities and enable 3rd party researchers to report vulnerabilities. The manufacturer must quickly remedy any identified vulnerabilities and report them to customers. This obligation exists for at least five years after the purchase of the product.
• Provide software bill of materials (SBOM)
  Device vendors must maintain accurate SBOM. Reference all internal, third-party or open-source libraries that are leveraged in the development of your product.
• Support incident reporting
  Incidents must be reported to authorities if they are being actively exploited. Active events must be reported within 24 hours. Security updates and patches as well as release notes need to be made available to customers.
• Provide free security updates for product lifetime
  The lifetime of a product is at least five years.

Why is CRA Controversial?

There are three main challenges to the CRA initiative. There are those who argue that moving liability for security to device vendors, and by extension developers, is pragmatic. There are some that believe it is bureaucratic overreach that will slow technology adoption and reduce market competitions. And there are fears that companies may decide to no longer serve the European Union.

CRA Liability

Liability concerns are best illustrated by the open-source community. They have been opposed to the CRA. Their initial fear was that open-source contributors could be liable for free software they developed or contributed to. Their concern was addressed with an exemption for non-commercial open-source solutions. However commercial use of open-source software has always been fertile ground for interpretation and disagreement.

In addition, it is not clear where the chain of command ends related to security. Many products sold today leverage a suite of technology. This typically included multiple open-source libraries and third-party libraries. Vendors will have a greater responsibility to vet and document the quality of the software components leveraged. With the potential of fines for non-compliances many question how blame will trickle through the software supply chain.

CRA Bureaucratic Burden

The CRA will undeniably increase the complexity of device development. The regulation will not be compatible with all existing product architectures, and the regulations increase the development burden and cost of bringing new devices to market.

Requirements to continually test a device for security vulnerabilities add a significant burden and ongoing cost to product development. Vendors will either need to invest in in-house talent or work with third parties to meet these testing goals.

Notifying customers is also problematic in a market that often disjoints customers from the device vendor. New business systems outside of product development will be needed to maintain these relationships.

The CRA requirements continue a trend many automation device manufacturers have been experiencing for the last decade. The fear is that at some point new regulation will make the barrier to entry too steep for many existing and future vendors. Twenty years ago, many industrial automation device manufacturers had boot strap stories. Through consolidation and technological advancement, it has become extremely rare to see an upstart company not backed by external capital bringing devices to market.

CRA EU Market Supply

The other concern for EU customers is the supply side of economics. Manufactures selling to the EU already face large burdens related to product safety and environmental concerns. The additional burden of security may lead to fewer vendors offering solutions to EU customers—which could, in theory, increase costs and reduce the use of new and emerging technology.

Does the CRA Impact EtherNet/IP, Profinet & Modbus Technologies?

It’s important to note that no protocol specific certifications equate to CRA certification. In addition, security add-on features from these technologies are not required to meet CRA requirements. CRA cares about the security outcome, not the specific method used to achieve it.

While not a direct requirement implementing the additional features of CIP Security (for EtherNet/IP) and PROFINET Security and Modbus/TCP Security will drastically increase the security of your device and will reduce the work needed to reach CRA. Industrial communication protocols like EtherNet/IP, PROFINET and Modbus TCP lack basic security features such as authentication and integrity. To add these features security add-ons need to be deployed.

Under CRA reporting requirements these technologies, implemented without their corresponding security features, will need to be clearly identified as security gaps. A document featuring a list network security shortcoming is not something your sales team wants to explain to potential customers. It is expected that the CRA will increase the availability and demand for devices that offer protocol specific security features.

CIP Security, PROFINET Security and Modbus/TCP Security are very likely to become de facto requirements in the future. This will not be a direct reaction to CRA requirements but the technical evolution towards secure devices has been accelerated by CRA.

What do Protocol Specific Security Features Add?

While there are nuances in how each of EtherNet/IP, PROFINET and Modbus TCP implement security they are all offering three very important values. They offer end point authentication, data integrity and confidentiality (encryption).

• Authentication – “Are you who you say you are?”
  Authentication verifies if two devices are who they say they are and can communicate. Primarily accomplished with the use of certificates. Authentication helps prevent unauthorized access and spoofing attacks.
• Data Integrity – “Has this message been tampered with?”
  Data integrity adds a mechanism to ensure the message sent was not tampered with prior to being received. This is usually accomplished with cryptographic hashes or digital signatures. Data integrity helps prevent man-in-the-middle attacks.
• Confidentiality – “Can others read this?”
  Confidentiality encrypts messages on the wire so that the content of the messages cannot be stolen. It helps prevent the threat of espionage and eavesdropping.

These three features meet the basic security features outlined by the CRA. The technology would align with CRA but the implementation may not. You’ll need to work with your team or with your vendor to ensure secure-by-design principles are used and documented.

I’m Overwhelmed. What do I do Next?

For most device manufacturers the challenges CRA creates will seem daunting. They are both technical and process based. To ensure CRA compliance becomes an opportunity as opposed to an obstacle for your organization consider the following timeline.

Accomplish in 2025
→ Educate your team on CRA – Get an internal champion to lead the effort. This will be a cross-team effort.
→ Begin security architecture planning – Where are your products today? What needs to be upgraded to align with CRA?
→ Establish vulnerability tracking processes

Accomplish in 2026
→ Implement secure development lifecycle
→ Prepare for vulnerability reporting (September 2026)
→ Develop SBOM capabilities – this may be a larger challenge than expected.
→ Plan conformity assessment strategy

What Will CRA Mean for Your Organization?

The CRA represents both a challenge and an opportunity for device manufacturers. It will accelerate adoption of security technology in an industry that has long viewed it as an afterthought. The additional technical burden of CRA means that collaboration with third party services providers will be necessary for all but the largest manufacturers. Static code analysis, penetration testing and regimental documentation of your code bases need to be implemented.

Where market demand failed to make security a requirement on the factory floor legislation may succeed. The evolution toward secure devices should help make the increasingly connected factory floor of tomorrow more attainable.

About the Author