The EU CRA regulation: Three key considerations any international company needs to know

Cybersecurity risks continue to escalate, software and products grow more complex, operational demands intensify, and regulations evolve. At the same time, organizations are under growing pressure to understand what compliance actually requires and act before deadlines become business disruptions.

The new Cyber Resilience Act (CRA) is a landmark regulation with far-reaching implications. While it originates in Europe, its reach extends well beyond, affecting any organization that develops, distributes, or sells connected products in the European market – regardless of its headquarters. For many organizations, the question is no longer whether CRA matters, but how to prepare effectively while balancing the growing complexity of connected products, security requirements, and the need to maintain products over time.

In a recent panel discussion covering everything from hardware design to security updates in the field, CRA experts Mena Roumbakis from STMicroelectronics and Eystein Måløy Stenberg from Northern.tech unpacked what the EU CRA actually requires in practice: who it applies to, where teams are falling short, and what to do today. Whether you’re leading product, engineering, compliance, or security, here are the three considerations that matter most, along with the steps to take before compliance becomes an operational liability.

Takeaway #1: No checkboxes. EU CRA compliance is a holistic initiative.

“You can't come along with a question like, I've done X, Y, and Z. Am I compliant? The answer is still maybe, or maybe not. It's more qualitative. Is your system secure? And do you have the documentation to back up that it's secure?”

– Ed Watson, Northern.tech, Moderator

As Stenberg delineates, the application of CRA is notably broad. CRA applies to “products with digital elements (PDE).” The panelists break it down.

At the core, the CRA regulation only stipulates the necessity to transmit or store data, excluding certain named market segments (e.g., medical). Therefore, PDEs don't need to be internet-connected; if a product consumes, stores, or processes data, it falls within scope because, as Roumbakis notes, it remains a security attack vector.

CRA also applies to new and existing products. As Stenberg notes, the "market entry date" is the crux: the date the individual product enters the European market. Any unit shipped into Europe after the December 2027 enforcement deadline must comply — regardless of when that product line originally launched, and including existing inventory. Likewise, any significant changes to existing products after enforcement, such as software updates, also bring them into scope. For example, a software vendor that ships a major update after the enforcement date must comply with CRA for both the newly updated products and new product purchases. A simplified checkbox approach consistently misses these nuances.

Likewise, fulfilling a CRA compliance “checklist” may not be enough. The intent of CRA is to apply security best practices across the full stack of a product throughout its lifecycle – from hardware to software design to ongoing monitoring, maintenance, and support. The interconnected and interdependent nature of CRA demands a holistic approach.

For example, secure boot and update mechanisms impact hardware decisions through the requirements, such as memory or storage, needed to fulfill each. Under vulnerability management, the OEM must know whether the product is affected and how to remediate identified vulnerabilities, which directly influences how OEMs monitor, track, and deploy security updates. Similarly, generating a software bill of materials (SBOM) requires OEMs to know what software each product includes, potentially affecting the software components and vendors they choose to utilize. Rip-and-replace is typically a costly course of correction; CRA forces OEMs to choose and rely on other providers that likewise monitor, manage, and secure their own products and maintain them for years to come.

CRA forces OEMs to be conscientious and intentional regarding the hardware, software, design, and documentation decisions of products from the beginning. Roumbakis and Stenberg reiterated the necessity of approaching CRA holistically throughout the discussion, from high-level concepts to the details of technical elements. The application of CRA for organizations is clear: CRA is a qualitative, holistic effort. A checkbox approach will not work.

Takeaway #2: Security starts at design and ends with decommissioning.

“CRA is meant to be a holistic view on security – the full life cycle from inception to development, to delivery to the end of life of the product itself.”

– Mena Roumbakis, STMicroelectronics, Featured panelist

A key implication of this holistic approach is that organizations cannot simply retrofit security or treat compliance as a one-time project. Instead, CRA compliance requires a continuous mindset shift that integrates security into every stage of the product lifecycle and across all teams involved.

Security starts at inception. Roumbakis references product development, noting security influences hardware choices, and hardware vendors must also comply with CRA and facilitate OEM compliance. Choosing hardware with security and compliance built in makes overall execution easier and faster.

Similarly, Stenberg advises OEMs to first focus on what is on the product, the device. Where OEMs can improve processes, such as vulnerability management and operations, over time, architecture and design decisions embedded in the physical product are far harder to change once the product has shipped. For example, one cannot change the hardware of shipped devices to support secure boot, or integrate over-the-air (OTA) software update mechanisms into devices in the field. In both scenarios, making foundational product changes requires recalling all fielded products and incurring significant business costs.

Success depends on cross-functional collaboration. Engineering, compliance, procurement, and product management must all work together to ensure that architecture decisions, processes, documentation, and technical controls are aligned. Security is an ongoing, organization-wide commitment, and that level of security is what CRA enforces.

Takeaway #3: Security and compliance are here to stay. Get started early.

“CRA's already started; we're in the midst of it now. Full implementation will be in 2027. It's not something we need to look at in the future. It's something we need to focus on today. And as far as development goes, we probably should have been looking at it yesterday. Even for customers in the US, it's important to take note: if you're shipping any sort of electronics into the EU, you need to be paying attention to CRA.”

– Mena Roumbakis, STMicroelectronics, Featured panelist

Both panelists reiterate the importance of starting early as one of the best things OEMs can do. CRA impacts the full development lifecycle and requires auditable documentation. Roumbakis notes that it is extremely difficult to have a completed product and then go back and shore up security. Or fulfill the extensive documentation requirements after product launch. Starting early accelerates compliance timelines and makes implementation overall easier.

Stenberg recommends first identifying the organization's requirements and second, the processes already in place. In doing so, OEMs start documenting their security while identifying gaps. “Detecting vulnerabilities, notifying customers, and providing remediation updates – document what exists,” states Stenberg. “Then, work on fixing the holes.” Similarly, Roumbakis recommends thinking about security on day one and documenting along the way.

With the average time-to-market at 54 months, proactive engagement with CRA requirements is essential. The products designed now are the ones that will hit the market when CRA is in full enforcement. To avoid costly, last-minute remediation or compliance failures, OEMs should prepare now, embedding security and compliance controls into their design, development, and operational processes from the outset, rather than retrofitting them later.

Facilitating a more secure future

“CRA is not a regulation for bureaucracy's sake. It’s more like lifting the bottom of the market to a security standard. Those who don't have security, haven't thought about it, or haven't cared before, will struggle more. But in the end, it is just good general security practices. It is common sense security processes to make sure that at least you cover the basics.”

– Eystein Stenberg, Northern.tech, featured panelist

Early and ongoing engagement with CRA requirements is not just a matter of regulatory obligation—it is a strategic imperative for any organization seeking long-term success in the European market.

Referenced throughout the webinar, there is anticipation that CRA will impact security like the General Data Protection Regulation (GDPR) did for data privacy. Also emanating from the European Union, the GDPR is often cited as transforming data privacy. From industry giants such as Google, Facebook, and LinkedIn to setting new standard operating procedures across marketing and sales disciplines, GDPR continues to demand more from companies regarding data privacy. Many anticipate CRA will follow a similar trajectory.

The organizations that start early and view CRA compliance as a continuous journey, rather than a one-time hurdle, will be best positioned to thrive in a rapidly changing regulatory landscape.

“You can't just complete the product, put it on the shelves, and then not have to think or worry about it. What does the product security look like through the usage? And once taken out of the field? You must make sure that the product is available and functioning as intended securely for the full product lifecycle.”

– Mena Roumbakis, STMicroelectronics, featured panelist

Check out the full panel recording.

Featured Panelists

Mena Roumbakis is a Technical Marketing Engineer at STMicroelectronics with a focus on MPU products and Security for the STM32 ecosystem in the Americas. Mena brings over 20 years of experience in design, support, and marketing to the table. He has a broad range of expertise covering various products, including microcontrollers, DSPs, and processors, and is passionate about helping engineers find the best design solutions. He is committed to providing exceptional guidance and support, ensuring that engineers have the resources and tools they need to succeed.

Eystein Stenberg is the CTO of NorthernTech, a leader in device lifecycle management, and the creator of Mender, the market-leading solution for robust, secure, and customizable over-the-air (OTA) software updates. With over 15 years of experience in security and systems management, Stenberg has served on the front lines of some of the largest production environments and possesses in-depth knowledge of solving real-world system security challenges. An expert in embedded system security and IoT device management, Stenberg routinely shares his insights at industry technology conferences and other sector-focused events, such as automotive.