Four cross-cutting views that reveal whether your tools work together — or whether the seams become the risk.
Key Takeaways
- Tool capability is not the bottleneck. Tool boundaries are. An IoT product's lifecycle spans CI/CD, production, PKI, vulnerability management, and OTA platforms — each a mature, well-understood category of tooling. The compliance risk lives in the gaps between them.
- The same data set, viewed from four different directions, produces four different queries — and none can be answered from a single platform. A product pulls you toward its keys and certificates. A key pulls you toward everywhere it has been sent. A vulnerability pulls you toward affected firmware, devices, and markets. A device pulls you toward a complete record assembled from five systems.
- CRA's time dimensions make the seams urgent. The 24-hour early-warning window, the 5-year support floor, and the 10-year documentation retention period all require cross-system answers under deadline — not eventually, but now.
An IoT product crosses five distinct tool boundaries on its way from concept to field deployment. Before the questions, the map — here are the five platforms a typical OEM operates, each holding data the others need.
| STAGE | PLATFORM | WHAT IT HOLDS |
| Build | CI/CD system | Firmware build records, build-time SBOM, signing logs |
| Production | MES / factory management | Production batch records, per-device provisioning logs, injection history |
| Key & certificate management | PKI / KMS / HSM | Key inventory, certificate lifecycle, signing authority records |
| Vulnerability management | SBOM platform + PSIRT feeds | Component inventory, CVE exposure, handling records |
| Deployment | OTA platform | Firmware update status, deployment completion, certificate rotation logs |
Each platform is mature. Each has competent options on the market. Each was selected to do its specific job well. These platforms hold the data. The questions below ask for views across all of them.
CRA does not ask whether your tools are individually adequate. It asks whether your organisation can answer a cross-cutting question under a deadline — questions that require a single view assembled from data that sits across multiple systems. When a CVE lands on a Saturday morning and Article 14's 24-hour clock is running, the gap is never "we lack a tool." The gap is "we have the data, but it lives in three systems and nobody has assembled the answer."
The same data set produces different views depending on where you start looking — and each view is a cross-cutting query that no single platform was built to answer. This article is four such views.
Four questions
Under CRA: Annex VII requires technical documentation — including per-release SBOM history, vulnerability handling records, and Article 14 incident logs — to be retrievable by market surveillance for ten years. If device-level records are scattered across five platforms with no aggregation layer, the documentation obligation becomes a reconstruction exercise each time it is invoked. Over a decade of team turnover, system migrations, and vendor changes, the platforms themselves may not survive — but the documentation obligation does.
Managing the seams
The four views above are not arguments for or against any particular tooling strategy. They are descriptions of where CRA compliance becomes operationally difficult — and in every case, the difficulty has the same shape: information that must cross a tool boundary, under a deadline, for an audit-grade purpose.
Separate tools can satisfy each scenario, provided the seams between them are deliberately managed — defined data-exchange formats, named ownership for cross-cutting queries, standing reconciliation procedures, and audit-grade record retention that spans all systems involved. Many OEMs do this successfully, especially when the number of products and markets is limited and the teams involved have the capacity to maintain the coordination manually.
The operational cost of managing these seams is not fixed. It scales with the number of products, markets, supplier relationships, and the frequency of events — CVEs, production runs, certification audits — that require cross-system answers. An OEM shipping two products into two EU markets has a manageable reconciliation burden. An OEM shipping twenty products across ten markets — with multiple contract factories, several module vendors, and an OTA platform — faces a coordination surface that manual processes cannot sustain across the five-year support floor, let alone the ten-year documentation window.
The question is not whether the seams exist. They exist for every OEM. The question is how you choose to manage them — and whether your current tooling arrangement scales to the obligation CRA imposes.
Where Third-Party Components, First-Party Liability looked outward at vendor relationships, this article looks inward at the tool boundaries inside your own organisation. Both reveal the same pattern: CRA does not break at any single component — it breaks at the seams between them.
The OEMs that pass CRA's stress test will not be the ones with the best tools. They will be the ones who designed for the seams.
Auditing your tool boundaries before September 2026?
A 30-minute conversation with our team is enough to map the seams in your current stack against CRA's reporting clocks.
Contact Us Where to go deeper
This article is part of Snowball's CRA series for IoT OEMs. To follow the series, subscribe to the Snowball compliance newsletter.
