Skip to content

alloy-it

CRA operations for manufacturers of products with digital elements.

Know what you shipped. Keep scanning it. Be ready to report when something is actively exploited.

From 11 September 2026, EU manufacturers must report actively exploited vulnerabilities in products already on the market to ENISA and their national CSIRT, within 24 hours of becoming aware. You cannot report what you cannot find. alloy-it keeps a living inventory of every release you placed on the market, watches it for the rest of the product's market life, and prepares the filing when something lands.

When a fix is required, it also gets you back to the build environment that produced the affected binary, years later, on products with ten- to fifteen-year support periods.

What alloy-it does not do

It is not CE-marking software and not a notified body. It does not submit anything to ENISA or a CSIRT on your behalf, and it does not email your customers automatically. It detects, times, scopes, and prepares. Filing and disclosure stay deliberate human acts.

Start here

  • CRA operations

    Create a product, record the releases you shipped, and fill in your reporter identity. This is the minimum for 11 September 2026, and it does not require an SBOM.

  • Build environments

    Install alloy-provisioner and pull a blueprint. Reproducible toolchains for local development and CI, and the rebuild path when you must patch an old release.

  • How it works

    The loop: monitor detects, notify scopes the report, trace back finds the origin, reproduce ships the fix.

  • Why alloy-it

    The problem this solves, and who it is for.

The two ways in

Most teams arrive through one of two doors. They lead to the same platform.

CRA operations Build environments
You are Product security, PSIRT, compliance An embedded or platform engineer
You need To know what you shipped and be able to report on it A toolchain that installs the same way everywhere
You start with A product and its releases alloy-provisioner and a blueprint
Where it runs The dashboard Your machine, a VM, or CI
Read Get started → CRA operations Get started → Build environments

They meet at provenance: a release records which blueprint built it, so triage can point at a rebuild target rather than at an archaeology project.

The workflow, end to end

  1. Products and releases: record what you placed on the market.
  2. SBOMs: attach a vendor CycloneDX or SPDX document per release, or derive one from the firmware when you want to verify rather than trust.
  3. Monitoring: scheduled rescans keep findings current and overlay actively-exploited data from KEV and EUVD.
  4. Triage: decide, per component, what is actually in the product, with a justification an assessor can read.
  5. Reporting: when something exploited hits a shipped release, stamp awareness and prepare the 24h / 72h / 14-day Article 14 payloads.
  6. Advisories: separately, and later, tell customers what to do.
  7. Evidence: export per-release packs and keep the conformity checklist honest.
  8. Build environments: reconstruct the toolchain and ship the patch.

Getting help