For you
Manufacturer
Articles 13 and 14
Know what you shipped. Keep scanning it. Be ready to report.
Track every firmware release you shipped. Get alerted when a component in it is actively exploited. Have the Article 14 report ready to file.
For manufacturers under the EU CRA. Not a CE-marking tool, not a notified body.
How it works
You tell alloy-it what you shipped. It keeps watching. When something is exploited, you are ready.
You set up
ProductGW-4200 Gateway
- v2.4.1Vendor SBOM
- v2.3.0Firmware binary
- v2.2.0SBOM from CI
alloy-it
Product inventory, per release
Rescanned continuously against vulnerability intelligence, every finding triaged
You run
For authorities
Exploit incidents & Article 14 reports
24h / 72h / 14-day packets, ready to file with ENISA
For customers
Security advisories
Your public advisory page, CSAF and PDF
For your team
Alerts, triage & evidence
PSIRT alerts, decisions with reasons, a rebuild path
See it in the product
alloy-it · Reporting · Exploit incidents
| Exploit ID | CVE | Product | First aware | 24h early warning | 72h notification | 14d final | Status |
|---|---|---|---|---|---|---|---|
| EXP-2026-004 | CVE-2026-1337 | GW-4200 Gateway | 68h ago | sent | in 4h | in 12d | Reporting |
| EXP-2026-003 | CVE-2026-0912 | TX-90 Sensor | 3d ago | sent | sent | in 9d | Patch in progress |
| EXP-2026-002 | CVE-2025-8841 | GW-4200 Gateway | 22d ago | sent | sent | filed | Closed |
alloy-it prepares the payload and tracks the clock. You file it with ENISA or your national CSIRT.
Every exploited CVE gets its 24h / 72h / 14-day clock, with the affected releases already scoped. See what the deadline requires →
Built for the manufacturer of record
Also for you
Substantial modifier
Treated as a manufacturer
The teams inside that organisation
Not this product
Authorised representatives, importers acting only as importers, distributors, open-source stewards, notified bodies, and authorities are not the buyer.
One loop. Four capabilities.
Not a collection of separate tools. Monitor detects, notify scopes authority reporting, trace-back finds origin, reproduce ships the fix. See the platform overview →
01
Monitor
Product inventory & continuous scan
02
Notify authorities
Article 14 readiness
03
Trace back
Component → release → evidence
04
Reproduce
Rebuild & ship the fix
Getting ready is smaller than you think
No SBOM programme needed to start. Begin with what you shipped.
Start here
Be ready to report
- 1Add your products
- 2List the firmware releases on the market
- 3Fill in your reporter identity
Declare an exploitation: the clock starts, affected releases are scoped, and the 24h / 72h / 14-day payloads are built.
Then, automate it
Add continuous monitoring
- 1Attach an SBOM per release, by upload or from CI
- 2Or derive one from the firmware binary
- 3Let alloy-it rescan continuously
Actively exploited CVEs open an incident before anyone has to notice the news.
How alloy-it maps to CRA obligations
What the regulation asks for, and what you get.
The CRA requiresalloy-it gives you
- Machine-readable product SBOMCycloneDX / SPDX per release, or derived from the firmware
- An SBOM that stays currentOne SBOM per release, rescanned continuously
- Vulnerability handlingComponent-level triage with justification and history
- Actively exploited reporting (Art. 14)KEV / EUVD overlay, awareness clock, SRP-ready JSON
- Technical documentationAn evidence pack per release
- Security updates over the support periodRebuild the exact environment that built the release
- Toolchain SBOM (optional depth)Blueprint SBOM including build-time dependencies
Not CE-marking software, not a notified body. alloy-it prepares the Article 14 payload; you submit it to ENISA or your CSIRT.
What changes for your team
Monitoring, reporting and rebuilds, before and after.
Today
- MonitoringNobody rescans the firmware still in the field
- ReportingFriday 23:00: an exploit is public, nobody knows which releases are hit
- RebuildOnly one engineer can still build the old release
With alloy-it
- MonitoringEvery release rescanned daily, every finding triaged with a reason
- ReportingIncident open, affected releases listed, early warning drafted
- RebuildAnyone can rebuild its environment from the pinned blueprint
Open core. No lock-in.
The provisioner that reconstructs a build environment is free and open source. Product security and CRA operations are the SaaS.
Open source
Provisioner (reproduce leg)
- Apache 2.0 licence
- Runs natively on Linux, WSL2, Docker, VMs
- Self-hostable
- No telemetry, no account required
SaaS
Product security + CRA operations
- Free tier available
- Products, releases & SBOM monitoring
- Triage, KEV/EUVD & Article 14 evidence
- Firmware-derived inventory
- Rebuild path via blueprints
How it looks in your organisation
Same manufacturer duties. Different products, teams, and support periods.
Product Security & PSIRT
No living inventory. Scans dump thousands of CVEs. Article 14 reporting is already in force.
See the PSIRT path →
OEMs & Industrial Vendors
Spreadsheets for what shipped. Vendor SBOM and binary disagree. 10 to 15 year support with no rebuild plan.
See how OEMs run CRA →
Gateway Manufacturers
Gateways already in the field with no per-version SBOM when a CVE drops.
See the gateway path →
Plans
Basic is free forever. Talk to us when you need enterprise scale for CRA operations.
Basic
Free
Manufacturers getting started with product inventory and CRA monitoring
- Products, releases & vendor SBOM upload
- Continuous CVE scanning & alerts
- Component-level triage
- Firmware-derived SBOM (on demand)
Enterprise
Contact us
OEMs and gateway makers running CRA operations at scale across the support period
- Everything in Basic
- Automatic exploit detection (KEV / EUVD)
- Unlimited seats & SSO / SAML
- On-premise / air-gapped deploy
Free forever for Basic · See full plan details →
Ready to get CRA-ready?
Start with a product inventory, or book a 15-minute walkthrough of Article 14 readiness.