Skip to content

Reporting (CRA Article 14)

From 11 September 2026, a manufacturer must report actively exploited vulnerabilities in products already placed on the market to their national CSIRT and ENISA. The clock starts when the manufacturer becomes aware. This guide covers the dashboard area that supports that duty: Reporting.

Two things to be clear about before anything else:

Two hard boundaries

  • alloy-it never submits anything. It detects, times, scopes, and prepares the payload. A human copies that payload into the ENISA Single Reporting Platform or the national CSIRT portal and records the reference back in alloy-it.
  • This is not customer notification. Informing end customers is a separate duty on a separate timeline, handled through advisories.

Where it lives

Page Path
Incident queue (org-wide) /reporting
Incident workspace /reporting/:incidentId
Per-product view /products/:productId/reporting
Reporter identity and PSIRT alert emails /settings/notifications

Before you need it: set the reporter identity

The SRP payloads are only useful if they carry your organisation's filing identity. Fill this in under Settings → PSIRT alerts while nothing is on fire:

Field Used for
Company name reporter.company_name in all three phases
Manufacturer ID reporter.manufacturer_id
Designated national CSIRT reporter.designated_national_csirt: the authority you file with
Contact name / email / phone reporter.contact_person
Alert emails Where new high and critical findings land

Nobody wants to be looking up a manufacturer ID inside a 24-hour window.

How an incident starts

Automatic: awareness sync

A background job overlays CISA KEV and EUVD "actively exploited" data on your product inventory, vendor SBOMs and firmware-derived inventories alike. When an actively-exploited vulnerability matches a component in a shipped release, alloy-it writes an awareness record.

The awareness record is immutable. It holds first_aware_at, the source (kev, euvd, kev+euvd, or manual), the upstream event timestamp, and the detection path (feed_sync, rescan, manual).

This timestamp is the Article 14 clock seed and the single most audit-relevant field in the system, which is why nothing in the interface can edit it.

You can force a sync from the Reporting page.

Manual: Declare exploitation

Awareness can also come from a customer report, a partner disclosure, or your own telemetry, long before a feed catches up. Use Declare exploitation on the Reporting page.

The wizard:

  1. Identify the vulnerability. One CVE, or several when a single exploitation event spans multiple CVEs. Identifiers are normalised, deduplicated, and sorted. You can also record awareness without a CVE and link one later.
  2. Scope the affected releases. alloy-it searches your shipped releases for the CVE and pre-selects the hits. The manual scope picker lets you add releases the scan did not find, the common case for a vulnerability with no matching component identity.
  3. Confirm. Declaring stamps first_aware_at at T₀ and opens the incident.

Declaring the same vulnerability twice returns the existing incident rather than restarting the clock.

The incident workspace

Each incident has a human-facing ID in the form EXPLOIT-YYYY-MM-NNN. Prefer it over the CVE in internal communication: an incident may cover several CVEs, or none at all yet.

Deadlines

Three clocks are derived and shown as deadline pills:

Clock Derived from Regulatory phase
24 hours first_aware_at Early warning
72 hours first_aware_at Detailed notification
14 days patch_released_at Final report, post-patch

The 14-day clock only appears once you link a patch release, because the obligation is anchored to the fix, not to awareness.

Status

Status Meaning
open Declared, not yet worked
investigating Being assessed
filed_manual Submitted to the authority outside alloy-it; the reference is recorded here
closed_not_affected Assessed as not affecting a shipped product
closed_remediated Fixed and shipped

Closing without filing requires an assessment rationale, plus who decided and when. That record is the audit defence for every vulnerability you did not report, and the workspace will not let you close quietly.

Affected releases

The workspace lists affected releases: product name, version, and which SBOM sources matched. Use it when drafting the 72-hour notification's "where the product is available" section and when briefing executives.

Field device and customer counts are not tracked in the platform.

Filing: the three SRP phases

The workspace builds three JSON documents, one per Article 14 phase, from the incident, your reporter identity, and the SRP draft fields you fill in. Each is offered as copy JSON.

Phase Message type Contents
1 (24h) CRA_ARTICLE_14_EARLY_WARNING Reporter, impacted product (name, model, affected firmware versions, PURL, CPE), incident indicators, affected territories, critical-infrastructure flag
2 (72h) CRA_ARTICLE_14_DETAILED_NOTIFICATION Early-warning reference, technical analysis (description, CVSS v4 vector and score, exploitability, threat actors), workarounds, remediation status and distribution, TLP level
3 (14d post-patch) CRA_ARTICLE_14_FINAL_REPORT Verification results, root cause, long-term prevention measures, evidence pack hashes

Sign-off is enforced

Each phase carries an approver and an approval timestamp. A phase cannot be marked sent without a recorded approval. Regulatory submissions are accountable to Legal and Compliance, and the workspace holds that line rather than trusting a habit.

After filing, record the ENISA reference / SRP ticket ID in the draft. Phase 2 and 3 payloads reference it automatically.

Evidence

Evidence pack hashes recorded on the incident tie the filing to the exact SBOM, findings, and triage decisions that existed at the time.

Generate the pack from the affected release before you file, so the hashes are stable.

→ Evidence packs

What this deliberately does not do

  • It does not email customers. That is advisories, downstream of triage.
  • It does not submit to any authority. There is no API integration with the SRP, by design.
  • It does not decide whether a vulnerability is exploited. KEV and EUVD are signals; the declaration is a human act, recorded as such.