Get started: CRA operations¶
This is the shortest path to being able to file an Article 14 report correctly. It is smaller than most teams expect, and stage one does not require an SBOM.
The obligation that starts on 11 September 2026 is: when you become aware that a vulnerability in something you placed on the market is being actively exploited, report it to ENISA and your national CSIRT within 24 hours. To do that you need three things: a list of your products, a list of the versions you shipped, and a filing identity. That is stage one.
Stage two is what makes detection automatic rather than dependent on someone telling you first.
Stage one: be able to report¶
1. Create your products¶
Under Products, add each product line you place on the EU market. A product is the thing the CRA holds you accountable for.
| Field | Why it matters |
|---|---|
| Name and SKU | How you and an authority refer to it |
| CRA risk class | default, important_i, important_ii, or critical. Drives the conformity assessment pathway on the Conformity tab |
| Support end date | Your Article 13(8) support period. Minimum five years unless the expected lifecycle is genuinely shorter |
2. Add the releases you shipped¶
For each product, record the firmware versions you placed on the market. When an authority asks what is affected, this is the list you scope the incident against.
You do not need an SBOM for this step. A version string and a date is enough to make the release addressable. Inventories can be attached later, release by release.
3. Fill in your reporter identity¶
Settings → PSIRT alerts. Do this while nothing is on fire; it is what makes a filing valid, and nobody wants to be looking up a manufacturer ID inside a 24-hour window.
| Field | Used for |
|---|---|
| Company name | reporter.company_name in all three Article 14 phases |
| Manufacturer ID | reporter.manufacturer_id |
| Designated national CSIRT | The authority you actually file with |
| Contact name, email, phone | reporter.contact_person |
| Alert emails | Where new high and critical findings land internally |
→ Reporting: before you need it
4. Decide who owns the clock¶
Not a software step, but the one that most often fails. Name a person and a deputy. The 24-hour obligation does not pause for holidays.
What you can do now
You can declare an exploitation the moment you hear about it, from a customer, a partner, a CERT bulletin, or your own telemetry. Declaring stamps the awareness timestamp, scopes the affected releases, and builds the 24h, 72h, and 14-day payloads for you to copy into the ENISA SRP.
Stage two: make detection automatic¶
Stage one relies on someone telling you. Stage two means the platform notices first.
5. Attach an inventory to each release¶
Upload the vendor CycloneDX or SPDX document for a release, or have your pipeline push one on every build.
6. Or derive one from the firmware¶
Where the vendor document is missing, or you do not fully trust it, upload the shipped binary and generate an inventory from it. Where both exist, alloy-it shows the difference rather than merging them; the difference is the interesting part.
Analysis never starts by itself. Uploading a binary does not open it.
7. Let it rescan¶
Scheduled passes re-check every stored inventory against current vulnerability intelligence, and overlay actively-exploited data from CISA KEV and the EU EUVD. New high and critical findings go to your PSIRT alert addresses.
8. Work the triage queue¶
A scan without triage is not evidence. Decide, per component, whether the product is affected, not affected, or the finding is a false positive, with a justification. Decisions persist across rescans and can be carried forward to new releases.
→ Triage
What you can do now
Actively-exploited data is overlaid on your inventory automatically, so an incident opens and the clock starts without anyone reading the news first.
Optional: the rebuild path¶
When triage confirms an affected release and you have to ship a patch, record which blueprint built that release. That provenance link is what turns "we need to patch v2.3.0" into a reconstructable build environment rather than an archaeology project.
→ Build environments · Build provenance
Where this leaves you¶
| Obligation | Covered by |
|---|---|
| Know what you placed on the market | Products and releases |
| Machine-readable SBOM per version | SBOMs or firmware analysis |
| Keep it current | Monitoring |
| Vulnerability handling and triage | Triage |
| Article 14 reporting | Reporting |
| Informing customers | Advisories |
| Technical documentation and evidence | Evidence, Conformity |
| Updates over the support period | Build environments |
Scope classification, secure-by-design engineering, conformity assessment, and CE marking stay with your product and compliance teams, and qualified counsel. alloy-it is not CE-marking software and not a notified body.