CRA Compliance for OEM/ODM Companies: Why Supply Chain Evidence Matters

Does CRA Compliance for OEM/ODM Companies Really Not Apply?

“The product doesn’t carry my brand, so the CRA is my customer’s job.” We hear this often from OEM and ODM companies preparing for the Cyber Resilience Act (CRA). The idea is partly right. Under Regulation (EU) 2024/2847, a Manufacturer is not only the company that builds the product. It is also a company that has someone else design or make the product, then sells it under its own name or trademark.

Who Is the Manufacturer in a Typical ODM Model?

In a common setup, ODM A designs and builds a product. Brand B sells it in the EU under its own brand. In this case, Brand B is most likely the Manufacturer under the CRA, not ODM A. But the answer depends on the business model and on whose name is on the product.

Why the Supply Chain Still Matters

The CRA asks the Manufacturer to finish many tasks before a product goes on the market. These include a cybersecurity risk assessment, technical documentation, conformity assessment, and a vulnerability handling process. The Manufacturer must also check third-party components with proper care.

Here is the problem. In many projects, the ODM holds the real design data. The ODM writes the firmware, picks the Linux packages, joins the open-source parts, designs Secure Boot, and builds the login system. So Brand B may carry the legal duty, but the technical evidence sits with the ODM.

What Brand Customers Now Ask ODMs to Provide

Brand customers are starting to ask ODMs for a CRA evidence package. Common requests include:

• Product security scope: network interfaces, and functions that use authentication or sensitive data.
• Software component details: third-party libraries, open-source parts, versions, and an SBOM.
• Threat model and risk assessment: attack surfaces, threats, and mitigations.
• Security design evidence: Secure Boot, firmware integrity checks, credential handling, and update checks.
• Vulnerability management: CVE monitoring, who decides if a flaw applies, and how updates are delivered.

The brand may add this information to its own technical documentation. So a project that looks like one brand’s compliance task slowly becomes a supply chain compliance project. It involves the brand, the ODM, and the component suppliers.

The Real Question for OEM and ODM Teams

The key question is not “Is the CRA my legal duty?” It is “Can I give evidence when my customer asks?” Many teams would struggle to answer. They may have no SBOM, no saved threat model, or no clear process for handling a vulnerability. At that point, the CRA becomes a customer requirement.

How to Start Without Building a Huge System

You do not need a big CRA program on day one. Start by reviewing your current secure development lifecycle (SDL). Find what evidence you can reuse. Then fill the gaps. A simple path looks like this: requirements, threat modeling, risk assessment, security design, verification, SBOM, vulnerability management, and technical evidence.

Many teams already do part of this work. What is often missing is not the security work itself. It is proof that customers, auditors, or conformity assessment can use. If you wait until your customer asks, it is usually a little late.

How The ONE Can Help

The ONE helps OEM and ODM companies start from their current development process. Support includes gap analysis, product classification, risk assessment, threat modeling, technical documentation, testing evidence, and vulnerability management. The goal is not one more set of documents. It is to organize what R&D, QA, cybersecurity, and supply chain teams already have into clear, traceable evidence that brand customers can use. The ONE’s testing services also cover internet-connected products, hardware, and embedded software.

Key Takeaways

• Check your role first: Confirm whose name or trademark goes on each product, because this decides who is the Manufacturer under the CRA.
• Expect requests from brand customers: Prepare now for questions about your firmware, components, and security design, even if you are not the legal Manufacturer.
• Build an SBOM for every product line: Track third-party and open-source components and their versions, including older firmware.
• Save your security work as evidence: Keep threat models, risk assessments, and test results in a clear, traceable format.
• Define a vulnerability process: Decide who monitors CVEs, who judges if a flaw applies, and who delivers updates after launch.
• Reuse what you already have: Start from your current SDL and fill only the gaps, instead of building a new system from zero.

Source of Article

The ONE original article, based on Regulation (EU) 2024/2847 (Cyber Resilience Act).
https://eur-lex.europa.eu/eli/reg/2024/2847/oj