This is the first deadline of the Cyber Resilience Act. The reporting obligation assumes you already know your product's building blocks well enough to quickly recognise if it's affected by a newly published vulnerability, or not. Most manufacturers of connected products are not in that position. They have a build plan, and a reasonable belief that the build plan describes the device.

The CRA's goal is a secure product, not just additional paperwork. The technical file, the SBOM and the conformity assessment are evidence that the product has that security. Useful evidence, but a product that is secure in theory is not always secure in practice. Confuse the two and a compliance programme drifts toward producing excellent paperwork about a device nobody has verified in real life.

The declared inventory is thin by design

The CRA does require a software bill of materials. Annex I, Part II asks manufacturers to draw one up "in a commonly used and machine-readable format covering at the very least the top-level dependencies." It becomes part of the technical documentation under Article 31 and Annex VII, retained for ten years or the support period.

Two things follow from that wording, and both matter.

The first is depth. Top-level dependencies is the bare minimum the CRA asks for, and in embedded firmware the risk that matters sits well below it. A firmware project that lists an SDK as one line has declared almost nothing. The vulnerabilities that get reported against embedded systems live inside those SDKs. In the TLS implementation, the Bluetooth stack, the HTTP server, the filesystem driver. All of it can sit below the declared surface.

The second is visibility. Recital 77 is explicit that manufacturers "should not be obliged to make the SBOM public." Market surveillance authorities can request it. Your customers cannot. Often, neither can you, if the component in question is a module you bought from someone else and integrated into your own product. You inherit the obligation without inheriting the information.

So a company assembling a connected product from third-party modules has a legal duty to report vulnerabilities in software it cannot easily enumerate, sourced from suppliers who are under no obligation to tell it what is inside.

An SBOM is a claim about a build, not a measurement of a device

Even a thorough, honest, deeply resolved SBOM describes an intention. It is generated from the build system, and the build system describes what was supposed to happen.

Between that description and the device on the shelf, a lot happens.

Contract manufacturers flash what they have. Radio stacks arrive as precompiled binary blobs with their own version numbers and their own published vulnerabilities, frequently a version behind what the datasheet claims. Vendored copies of libraries drift from upstream. Debug builds ship. Components get substituted late for availability reasons that never make it back into the documentation. A field update replaces part of an image and not the record of it.

None of this requires anyone to be careless or dishonest. It's just what happens in the supply chain when physical products are manufactured. But the point is, a shipped artefact is the only authoritative record of itself.

That record is readable. Compiled code carries structure that survives the loss of symbols, and known code can be recognised by it. From a flash dump alone it may be possible to identify which SDK a firmware image was built against and often which version, recover much of the build configuration the developers chose, and separate the vendor's supplied code from the manufacturer's own.

Both halves of that separation are useful. The identified portion gives you a component inventory derived from the artefact rather than asserted about it, one you can check against what your supplier told you, and map to published vulnerabilities today rather than during a 24-hour reporting window. The remainder is the code your organisation actually wrote, isolated and much smaller than the whole. That is where the interesting attack surface lives, and something a bill of materials rarely covers.

Firmware is one layer of a product, not the product

An attacker does not stop at the flash image, and neither should an assessment.

The board is where it starts. Debug interfaces have a way of surviving into production. JTAG and SWD pads left populated, a UART console still printing at boot and still accepting input. Annex I asks that products "limit attack surfaces, including external interfaces." A programming header that gives up the firmware and the keys is exactly that requirement failing, and it is not visible from any build artefact.

The questions don't stop at the board. Is secure boot actually enabled on shipped units, or only on the engineering configuration? Does the root of trust hold, or can it be rolled back to an earlier signed image with a known flaw? Is the OTA update authenticated and integrity-checked end to end, and what happens if it is interrupted? How does pairing and provisioning work, and what is trusted during that window? What does the companion app hold, and what does it accept? What does the cloud API enforce that the device assumes is enforced?

Every one of those is a boundary between two components, and boundaries are where security issues often appear. The firmware team owns the firmware. The app team owns the app. The cloud team owns the backend. Nobody owns the trust boundary between them, and that is where an attacker lives.

In 1968 Melvin Conway observed that any organisation which designs a system "will produce a design whose structure is a copy of the organisation's communication structure." It is usually quoted as a warning to software architects. Back when I was one, it was a favourite of mine. For connected hardware, though, it reads more like a map. The interfaces inside the product are the interfaces between the groups that built it, and in this industry those groups are usually not even the same company. A silicon vendor's SDK. A module vendor's precompiled radio stack. A contract manufacturer's production line. An agency's companion app. A platform provider's cloud. The product's trust boundaries land where the commercial boundaries land.

That is also the root of the inventory problem described earlier. The documentation falls through the same gaps the security does, because they are the same gaps.

So a compliance programme organised around a company's own teams and artefacts inherits the structure that produced those gaps in the first place. An assessment of the finished product does not. It arrives with no idea who was responsible for what, which also happens to be the attacker's position.

This complements the work you are already doing

None of the above argues against process-side compliance. Gap analysis against the essential requirements, secure development lifecycle, vulnerability handling procedures, EN 18031 conformity for radio equipment, mandatory under the Radio Equipment Directive since 1 August 2025. All of it is necessary, and none of it is replaced by looking at a device.

But it shares an assumption. It assesses the process that produces the product, and infers the product from the process. That inference is sound most of the time. Where it fails, it fails silently, and it fails specifically in the places a supply chain and an org chart introduce.

So the two approaches want each other. Working left to right through the lifecycle establishes that you are building the product correctly. Working from the finished product establishes that what you built is what you think you built. One is an argument. The other is evidence.

There is a simpler way to put it. Your attacker does not have your build plan either. They have the device, a programmer, and time. Assessing the product the way an attacker will is not redundant. It is the only view of your product that you and your adversary share.

December 2027 is when the CRA's full obligations arrive. The manufacturers who handle that comfortably will be the ones who, well before then, stopped assuming and went and looked. Not because a regulation told them to, but because it is the only way to know whether the thing they sell is as safe as they believe it is.

References