Modern IoT hardware rarely comes from one company — cellular modules, radio modems, and connectivity stacks are built by specialists and assembled by OEMs. CRA was written with this structure in mind. It does not ask you to take over your vendor's internal security work — but it treats every module inside your product as part of a single product with a single accountable manufacturer, and that manufacturer is you. That is where the real tension lives for most IoT OEMs today.
Key Takeaways
- Two manufacturers, one accountable party. You and your module vendor are both manufacturers under CRA — but the obligations don't transfer. You are accountable for the finished product, end to end.
- Three obligations are non-negotiable. A product-level SBOM, a vulnerability handling process with a published CVD policy, and a minimum five-year support commitment. Above this floor, EU guidance and industry practice signal where the supervisory bar is heading.
- Your supplier contract is the only bridge between what CRA requires of you and what you can deliver without the vendor. SBOM depth, CVE notification SLA, and disclosure timing must be specified — not assumed.
- Support-window mismatch is the hardest problem. When your vendor's roadmap ends before your CRA support obligation does, every path forward is costly. Module-replaceability designed in from day one is the most defensible preparation.
- Start with the floor, then build toward the strictest reasonable reading. SBOM and CVD policy first; field inventory and independent monitoring second; supplier contract terms third — the priority order matters more than doing everything at once.
What CRA requires — and what that means for you
If you're an OEM, CRA's supply chain obligations come down to six areas — five tightly defined in the text, and one — due diligence — left deliberately open for implementing acts to fill in. That distinction matters for how you build your programme: the specific obligations are your enforceable floor today; the open one is where the strictest reasonable reading of the current text is your safest guide.
| CRA REQUIRES |
WHAT IT MEANS FOR YOU |
| Due diligence over third-party components you integrate |
You have to show you assessed the security of what you put into your product — not just trusted the vendor's brochure. The text doesn't spell out exactly what counts; supervisory practice in 2026–2027 will fill in the blanks. |
| An SBOM covering at least top-level dependencies |
A machine-readable bill of materials for your product. "At least top-level" is the floor, not the ceiling — when a CVE hits something buried inside a module, an SBOM that stops at the module name won't be enough. |
| Vulnerability reporting back to the component provider, and remediation |
If you find a vulnerability in something you integrated — including open source — you report it upstream and address it in your product. Not optional, and not something you can delay until the vendor responds. |
| 24-hour early warning from when you become aware of an actively exploited vulnerability |
Your clock, your timeline. Once you know — or reasonably should have known — the clock is running. It does not pause for the vendor's investigation or for a joint disclosure agreement. |
| Continuous vulnerability identification, secure update mechanisms, a CVD policy, and structured handling of reports |
One operating discipline, four moving parts: discover (continuous identification), receive (CVD policy), process (structured handling), fix (secure update). They have to function together for the full support period. |
| Minimum five-year security update commitment |
At least five years, or the product's expected use if shorter. For most IoT products that means five years — and your module vendor's support roadmap is set independently of yours, which makes this one of the hardest operational problems to solve. |
The CRA text is the floor — binding, and not contractable past. On top of that, ENISA and the European Commission have been publishing implementation guidance on SBOM depth, coordinated vulnerability disclosure, and supplier risk evaluation. EN 18031 harmonised standards are finalising through 2026 — not regulation, but the strongest current signal of where the supervisory bar will sit. Design your programme around the text and EU guidance first; mark everything else as inference, and know the difference when it matters.
For a full treatment of CRA's essential requirements and the September 2026 versus December 2027 deadlines, see Snowball's CRA overview.
The OEM's reality under CRA
When you integrate a third-party connectivity module into your product, CRA sees one product with one accountable manufacturer — you. Your module vendor, if they place their module on the EU market, is a manufacturer too, accountable for the module in their own right.
| |
INTEGRATING OEM |
MODULE VENDOR |
| Accountable for |
Finished product (end to end) |
The module (its firmware, SBOM, lifecycle) |
| SBOM delivery |
Product-level SBOM — required |
Internal module SBOM — required to own compliance; not required to hand to OEM unless contractually agreed |
| Vulnerability response boundary |
Owns the Article 14 clock at product level; must monitor, report, and remediate — cannot wait for vendor |
Owns vulnerability handling at module level; patching cadence is their responsibility |
| Who reaches the field |
Only the OEM can push updates to deployed devices |
Vendor can only deliver patches to the OEM, not to the field |
| Supplier due diligence |
Required on module vendors — selection, monitoring, documented risk assessment |
Required on their own sub-component and software suppliers |
Your compliance depends on the vendor — and CRA does not give you a pass for that. You cannot produce the module's internal SBOM yourself. You cannot patch the module firmware without the vendor. That is why your supplier contract is the only mechanism that bridges the gap — and it needs to specify what you cannot do alone: SBOM delivery with format, depth, and update triggers; vulnerability notification with defined speed, format, and channel; and coordinated disclosure timelines including embargo handling.
Choosing a vendor is a supply chain risk decision you are making for the lifetime of the product. A slow vendor patching process means slow product patching. A shallow SBOM means shallow vulnerability assessment. Surface these dependencies before you commit — they become permanent features of your CRA exposure once the product ships.
Support-window mismatch is the hardest version of this dependency. CRA's five-year minimum support obligation (capped at the product's expected use if shorter) is set by your product, not your vendor's roadmap — and vendor support windows are often shorter than yours. When the module hits end-of-support before your product does, every path forward is costly:
- Walking back your support commitment is legally defensible but creates regulatory exposure that compounds over time.
- Maintaining the module firmware internally is usually not viable — you do not have the source, and the attack surface you inherit is the one you cannot patch.
- Upgrading the hardware in the field is the cleanest path in theory and the most expensive in practice — firmware re-certification, field logistics, and customer coordination at scale.
The OEMs planning for CRA today are building module-replaceability into the product architecture from the start — a socketed physical interface, a clean hardware abstraction layer between module and product firmware, certification scoped so that swapping a module doesn't trigger a full recertification. Any one of these designed in from day one is far cheaper than retrofitting around a constraint that didn't exist in the original spec.
Whether your vendor is itself under CRA changes your enforcement leverage. Vendors selling into the EU are CRA manufacturers in their own right — your contract sits on top of a shared regulatory framework. Vendors selling only upstream stay outside CRA's manufacturer definition; your contract becomes the only mechanism that brings them along. Which side of that line each vendor sits on is the first thing your due diligence should answer.
Three red lines CRA draws for the OEM
These three are non-negotiable, regardless of what you write into supplier contracts:
You cannot claim ignorance. "Becoming aware" in Article 14 includes what you ought reasonably to have known. If a CVE in something inside one of your modules is sitting in NVD and you only learn about it from the vendor weeks later, the clock did not start when the vendor told you — it started when a reasonably-monitoring OEM would have caught it.
You cannot contract your obligations away. Assigning "CRA compliance" to a module vendor in a supplier agreement moves commercial risk, not the regulatory obligation. If the vendor misses an obligation, you can pursue them under contract — but the regulator names you, not them.
You cannot wait for the vendor's patch before you act. Your Article 14 clock runs on your own timeline. If your module vendor takes six weeks to ship a fix and you waited to report until then, the violation is on day 1, not week 6.
What to do about it
Knowing the relationship structure is the starting point. The question is what you actually build — organised in layers: what CRA mandates, what EU guidance points toward, and what industry practice signals.
The floor: what CRA's text makes non-optional
Three obligations are binding and leave no room for interpretation:
- A product-level SBOM in SPDX or CycloneDX format. Annex I Part II point 1 sets the floor — "a commonly used and machine-readable format covering at the very least the top-level dependencies." How far past that floor you go is a judgment call that supervisory practice will refine. A standard format now costs far less than a conversion later.
- A vulnerability handling process built around Annex I Part II's ongoing requirements. The minimum viable version has three parts: a public URL where researchers can report vulnerabilities to you (your CVD policy), an internal process for tracking and responding to those reports with defined timelines, and a secure update path that stays functional for the full support period. If any of these three is absent, the programme is not compliant — regardless of how strong the engineering is.
- A five-year minimum support commitment under Article 13(8) — capped at the product's expected use if shorter. Making this work in practice depends heavily on how long your module vendors commit to supporting their own components.
Beyond the floor: what guidance and industry practice point toward
These are not CRA obligations — but they are the clearest signal of where supervisory expectation is heading. Two take the longest to build from zero; start there.
- Field inventory: A system that can answer "which deployed units run which module firmware version, with which known CVEs" in hours, not days. Without it, your Article 14 clock runs on a vulnerability you cannot yet scope — which is why we treat this as a practical implication of Annex I Part II's vulnerability handling requirements, not just an industry good practice. (Annex I implication)
- Independent CVE monitoring: Feeds and escalation paths that do not depend on the vendor notifying you — NVD, vendor security bulletins, and relevant CERT alerts at minimum, with a defined escalation path when a relevant CVE appears. (industry practice)
- Supplier risk evaluation: Documented assessment before integration, covering the vendor's CRA compliance status, patching cadence, and SBOM delivery capability. (ENISA, Commission)
- Coordinated disclosure procedures: Agreed in writing with your module vendors, including embargo handling and joint-release timelines. (ENISA, Commission)
- CVE notification SLA: A contractual commitment with a defined response time. 24 to 48 hours from the vendor's awareness is a reasonable benchmark in OEM-vendor agreements; no published standard fixes the number. (industry inference)
- Periodic supplier review: Annually at minimum, triggered also by major CVEs or changes in the vendor's ownership or support posture. (industry practice, ISO/IEC 27036)
Where to start — given where the calendar is
With September 2026 just months away, the question is not which of the above to do eventually — it is which to do first. For most OEMs: SBOM and CVD policy first (both documentable quickly), field inventory and independent monitoring second (both require infrastructure build time), supplier contract terms third (important, but slower to negotiate).
Build toward a single test: can you answer a regulator's question about a specific deployed device within 48 hours?
Build the programme that absorbs updates — not one that gets rebuilt by them
Everything above is a snapshot of where CRA's supply chain requirements sit today. Implementing acts, EN 18031, and the first wave of supervisory practice in 2027–2028 will fill in the blanks — and the OEMs that designed for the strictest reasonable reading will absorb each clarification as a refinement, not a rebuild. Third-party component management is the work the IoT industry has in front of it for the next three years. The OEMs that can answer "which deployed devices run which module firmware version, with which known vulnerabilities" before September 2026 will be the ones that customers, regulators, and procurement teams trust first.
CRA does not change how IoT is built. It changes who is held accountable for the security of what gets built. The OEMs that get supply chain visibility right before September 2026 will set the standard the rest of the industry follows.
Where to go deeper
This article is part of Snowball's CRA series for IoT OEMs.
To follow this series, subscribe to the Snowball newsletter.
_SNB%20Hard%20crop.png)
