Why alloy-it¶
The problem¶
You shipped firmware. Some of it years ago. It is running in the field on products you support for another decade.
Then a CVE lands on a component you are fairly sure is in there somewhere, and someone asks three questions you cannot answer quickly:
- Which of our products contain it, and in which versions?
- Is it actually exploitable in our product, or just present?
- If we have to patch, can we still build that release?
Most embedded organisations answer the first from a spreadsheet that was last accurate two releases ago, the second from an engineer's memory, and the third with a wince. That was survivable when it was an internal embarrassment. From 11 September 2026 it is a regulatory deadline with a 24-hour clock attached.
What the CRA actually changes¶
The EU Cyber Resilience Act applies to products with digital elements placed on the EU market. Two dates matter:
| Date | What applies |
|---|---|
| 11 September 2026 | Report actively exploited vulnerabilities and severe incidents to ENISA and your national CSIRT: 24-hour early warning, 72-hour notification, 14-day final report |
| 11 December 2027 | Full application: CE marking, conformity assessment, and all essential requirements |
The September date is the one that bites first, and it is narrower than most teams assume. It does not require a finished SBOM programme. It does not require CE marking. It does not require you to email your customers. It requires that when you become aware a vulnerability in something you shipped is being actively exploited, you can say what is affected, which versions, and when you found out, within a day.
That is an inventory problem before it is a security problem.
What makes it hard for embedded specifically¶
The vendor SBOM and the binary disagree. You get an SBOM from a supplier, or your build system emits one. Whether it describes what actually shipped is a separate question, and for firmware it frequently does not.
The support period outlives the toolchain. A ten-year support commitment means being asked to patch a release built with a compiler version and SDK that no longer install cleanly on any machine you own. "We cannot rebuild it" is not an answer a regulator accepts.
Scanners produce noise, not decisions. A single firmware image yields thousands of findings across a few dozen components. Without a triage decision and a justification per component, a scan report is not evidence; it is a liability, because it proves you knew.
The awareness timestamp is the whole ballgame. Article 14 clocks run from when the manufacturer became aware. If that moment is not recorded, deliberately, in a system nobody can quietly edit afterwards, you have no defensible position about when the clock started.
How alloy-it solves it¶
A living inventory of what you placed on the market. Products and releases, each carrying its own SBOM: vendor-supplied, firmware-derived, or both. Not a snapshot; rescanned on a schedule for the product's whole market life.
Trust but verify. Where you have the binary, derive an inventory from it and compare it against the document you were given. The mismatch is triage input.
Triage as a decision log, not a scan dump. Component-level decisions (affected, not affected, false positive), each with a justification, carried forward across rescans and releases. That log is what an assessor reads.
An awareness clock that cannot be quietly edited. KEV and EUVD data overlaid on your inventory. When something exploited matches a shipped release, an immutable awareness record is written and the 24h / 72h / 14-day payloads are drafted for you to copy into the ENISA SRP.
A rebuild path that survives the decade. Releases link to the versioned blueprint that built them, so the exact environment can be reconstructed and the fix shipped, years later.
Who it is for¶
Product security and PSIRT teams who own the Article 14 clock and currently have no inventory to scope an incident against.
OEMs and industrial vendors with spreadsheets for what shipped, vendor SBOMs they do not fully trust, and support periods measured in decades.
Gateway and device manufacturers with products already in the field and no per-version SBOM to consult when a CVE drops.
Embedded and platform engineers who end up carrying the rebuild, and would rather have the toolchain defined as code than reconstructed from a README.
Who it is not for¶
Being straight about this saves everyone time.
- You need CE marking or a notified body. alloy-it is neither, and does not produce a Declaration of Conformity.
- You want someone to file with ENISA for you. There is no SRP integration by design; filing is a human act with named accountability.
- You are looking for a generic AppSec or container scanner. This is built around shipped firmware and the post-market duties that attach to it.
What about just using a scanner?¶
A vulnerability scanner tells you what CVEs match a set of components. That is one input to the first of the three questions at the top of this page, and nothing at all toward the other two.
| Scanner output | alloy-it | |
|---|---|---|
| What it covers | Components in one scan | Every release you placed on the market, over its market life |
| Vendor SBOM vs binary | Whichever you fed it | Both, compared |
| Triage | A list to work through | A decision log with justifications, carried across rescans |
| Awareness timestamp | Not recorded | Immutable, and the Article 14 clock seed |
| Authority reporting | Not covered | 24h / 72h / 14d payloads prepared for filing |
| Rebuilding an old release | Not covered | Provenance to the blueprint, reconstructible |