Modern IoT hardware is rarely built by a single company. Cellular modules, radio modems, and connectivity stacks are typically developed by specialized vendors and integrated by OEMs into a finished product. CRA was written with this industry structure in mind. It does not require OEMs to take over a supplier’s internal security operations. But it does treat every integrated component as part of a single product — and that product has only one ultimately accountable manufacturer. For most IoT OEMs, that is where the real tension begins.
For IoT OEMs, CRA supply-chain responsibility ultimately centers around six areas. Five are defined relatively clearly in the regulation itself. One — supplier due diligence — remains intentionally broad and will likely become more defined through future implementation guidance and supervisory practice. That distinction matters. Because:
CRA text defines the legal floor. On top of that, ENISA guidance, European Commission recommendations, and EN 18031 standards are gradually shaping supervisory expectations around:
When an OEM integrates a third-party connectivity module into a product, CRA sees:
one product, one ultimately accountable manufacturer.
If the module vendor also sells directly into the EU market, the vendor may itself qualify as a CRA manufacturer. But responsibility for the finished product still remains with the OEM.
This creates a difficult operational reality: OEM compliance often depends heavily on supplier cooperation.
But CRA does not reduce OEM accountability because of that dependency.
OEMs cannot:
As a result, the supplier contract becomes:
the operational bridge between CRA responsibility and what the OEM can actually execute.
Supplier agreements increasingly need to define:
These expectations cannot remain implicit. They need to be contractually defined.
CRA Article 13(8) introduces a minimum five-year support obligation. But module vendor roadmaps are usually independent from OEM product lifecycles. That means the module vendor may stop supporting the component while the OEM product still remains within its CRA support period. This is one of the hardest operational problems CRA creates.
At that point, OEMs usually face three expensive options.
Potentially defensible legally, but increasingly risky from a regulatory perspective over time.
Usually impractical. OEMs often lack source access and cannot realistically assume long-term ownership of the module attack surface.
Architecturally cleanest. Operationally most expensive. Because it may require:
To reduce long-term CRA exposure, many OEMs are now building:
into products from day one. Because:
designing for replaceability early is dramatically cheaper than retrofitting around lifecycle constraints later.
Regardless of supplier agreements, there are three responsibilities OEMs cannot transfer.
Under CRA Article 14, “becoming aware” includes what the OEM reasonably should have known. If a CVE affecting software inside a module is already publicly listed in NVD, regulators may not accept:
“the vendor had not informed us yet”
as a valid justification for delayed action.
A supplier agreement assigning “CRA compliance” to the module vendor may transfer commercial liability. It does not transfer regulatory accountability. Regulators will still hold the OEM accountable for the finished product.
The OEM’s Article 14 reporting clock follows the OEM’s own timeline. If the vendor requires six weeks to ship a fix, and the OEM waits six weeks before reporting, the compliance problem started on day one — not week six.
The practical question is no longer:
“What should eventually be implemented?”
The question is:
“What capabilities must be built before 2026?”
Three areas already form the minimum operational baseline.
Preferably in:
Minimum “top-level dependency” visibility will likely become insufficient quickly.
At minimum:
All three are necessary.
The hard part is not promising five years. The hard part is whether suppliers can actually support five years operationally.
These areas are not yet explicitly mandated by CRA, but they are becoming clear supervisory expectations.
OEMs increasingly need to answer:
“Which deployed devices run which module firmware versions, and which known CVEs affect them?”
Without that visibility, Article 14 timelines may begin before impact scope can even be determined.
OEMs cannot depend entirely on supplier notifications. Minimum monitoring typically includes:
Before integration, OEMs increasingly need documented assessment of:
OEMs and suppliers should define the following before incidents occur:
For most OEMs:
Because the infrastructure-heavy capabilities usually require the longest lead time.
Can the organization answer the following question within 48 hours?
“Which module firmware version is running on this deployed device, and which known vulnerabilities affect it?”
If not, the operational compliance system is probably still incomplete.
CRA does not fundamentally change how IoT products are engineered. What it changes is:
who becomes accountable for the security outcome of the final product.
The OEMs that establish real supply-chain visibility before September 2026 will likely become the organizations regulators, customers, and procurement teams trust first.
