Four cross-system views that reveal whether your tools work together — or whether the seams become the risk
Most IoT OEMs already operate mature tooling across the product lifecycle:
Each category is well understood. Each has strong tooling options on the market. The operational problem under CRA is rarely that a tool is missing. The problem is that the answers CRA requires often sit across multiple systems owned by different teams. When a vulnerability appears on a Saturday morning and Article 14’s 24-hour reporting clock starts running, the challenge is usually not:
“We do not have the data.”
The challenge is:
“The data exists — but it lives across three systems and nobody can assemble the answer quickly.”
An IoT product typically crosses five operational platforms from development to field deployment.
Each platform performs its own job well. CRA changes the problem: organizations must now answer questions that cross all of them.
The same data can produce very different operational questions depending on where the investigation starts. This article focuses on four common views:
None can be answered from a single platform alone.
Every product line depends on multiple cryptographic assets:
The operational question is simple:
Can the organization see the complete cryptographic inventory for a product from a single view?
In practice, the answer is often no. Firmware signing keys may live inside release infrastructure. Device certificates are managed by the PKI. OTA encryption keys may sit in another KMS. Debug credentials may be controlled by manufacturing or quality teams. The result is fragmented visibility:
Article 13(8) introduces a minimum five-year support obligation. That means signing infrastructure, certificate chains, and operational ownership must remain functional across:
If the organization cannot answer:
“Which certificates expire within the next 12 months?”
from a single operational view, the support obligation already contains unmanaged operational risk.
Inventory is only one problem. Custody is the harder one. Many OEMs still operate workflows where:
The operational question becomes:
Who can access this key, where does that access exist, and can it be revoked or audited?
The answer usually spans multiple organizations and systems.
In every case, either the key itself — or access to it — has crossed an organizational boundary.
Article 13(1) requires manufacturers to ensure products are designed, developed, and produced according to the essential cybersecurity requirements.
If key governance is fragmented:
The problem is rarely one weak tool. It is weak visibility across the seams between them.
This is where CRA’s reporting timelines become operationally difficult. A vulnerability begins as:
But CRA requires OEMs to quickly determine:
That answer usually spans:
Most organizations do not maintain these relationships in a single system. SBOM platforms know component composition, but not field deployment. Production systems know manufacturing batches, but not software component inventories. Market-distribution systems know regional shipments, but not firmware composition. As a result, the organization must reconcile data across all of them under time pressure. In many OEMs, the firmware-to-SBOM relationship is still maintained manually.
CRA obligations are not completed when the early-warning notification is submitted. They are completed when remediation is delivered. That means the organization must track the entire chain:
Each step crosses a platform boundary. The vulnerability platform does not control the build system. The build system does not control OTA deployment. The OTA platform does not automatically close the vulnerability workflow. Every handoff depends on integrations, reconciliation procedures, or manual operational coordination.
Article 14 introduces three reporting stages:
Each stage depends on different cross-system answers. Annex VII extends the problem further by requiring the same information to remain retrievable for ten years.
The previous views begin with abstract entities:
This view begins with a physical device. The operational question becomes:
Can the organization retrieve the complete lifecycle history of this unit from a single place?
That history may include:
In practice, each platform usually holds only part of the record.
Under normal operations, assembling this information manually is inconvenient. Under Article 14 deadlines, it becomes the operational bottleneck.
Scenario One: customer support
A device stops connecting, and support teams must retrieve firmware status, certificate validity, and update history across multiple systems.
Scenario Two: Market surveillance
An authority requests the conformity history of a device shipped years earlier. Both scenarios require the same thing:
a cross-platform reconstruction of device history.
Many organizations still lack a unified system of record for this.
Annex VII requires documentation to remain retrievable for ten years. Over that period:
The platforms themselves may disappear. The documentation obligation does not.
The four views above are not arguments for or against any particular tooling strategy. Separate tools can work successfully. The operational challenge is whether the seams between them are intentionally managed. That usually requires:
Some OEMs manage this successfully with separate systems, especially when:
But the operational cost grows with:
An OEM shipping two products into two markets can often coordinate manually. An OEM shipping twenty products across ten markets, multiple factories, and several suppliers faces a coordination surface that manual processes cannot reliably sustain over:
Where Third-Party Components, First-Party Liability examined the risk created by external vendor relationships, this article focuses on the internal seams inside the OEM’s own operational stack. Both reveal the same pattern: CRA rarely breaks at a single component.
It breaks at the boundaries between them. The OEMs most prepared for CRA will not necessarily be the ones with the most tools. They will be the ones that intentionally designed for the seams.
