Skip to content
CRA Sentinel

How it works

Five steps from a product you ship to evidence you can produce

Three things you do once per version, one thing the software does continuously, and one thing your team owns for as long as the product is supported.

Get startedTalk to us

The five steps

What you do, and what the software does

Three of these are yours and happen once per version. One runs continuously without you. The last one stays yours for as long as the product is supported.

  1. 1
    You

    Add your product

    Record a product you place on the market. This is the thing your customers own — a device, an application, a piece of firmware.
  2. 2
    You

    Add the supported version

    Add each release you still support. Versions matter more than products here: a vulnerability is your problem when it reaches a version you support, and the reporting duty reaches your installed base rather than only what you ship today.
  3. 3
    You

    Upload the SBOM

    Upload a CycloneDX or SPDX JSON software bill of materials for that version. CRA Sentinel parses it into a component inventory and tells you what it can and cannot check — components without a resolvable identifier are reported as gaps rather than counted as clean.
  4. 4
    CRA Sentinel

    Monitoring surfaces relevant exposure

    Component versions are range-checked against OSV on a continuing basis, and matches are cross-referenced against CISA KEV and the ENISA EU Vulnerability Database for evidence of active exploitation. New advisories are checked against inventory you uploaded long ago, so a supported version does not stop being watched because you stopped shipping it.
  5. 5
    Your team

    Triage, open cases, track deadlines, keep evidence

    A named person decides whether the product version is affected, not affected, or needs more information, and the reasoning is recorded either way. Where a decision leads to a duty, a reporting case opens, the statutory stages are tracked from recorded awareness, and every step is written to an append-only evidence history you can export.

The same thing, as a pipeline

What each stage hands the next

The two stages in the middle of this diagram are the ones a person owns. CRA Sentinel does not move a finding past triage on its own.

  1. 01SBOMCycloneDX or SPDX, per version
  2. 02Component inventorywhat is actually inside
  3. 03ExposureOSV range match, KEV and EUVD
  4. 04Human triagea named person decides
  5. 05CRA caseopened where a duty follows
  6. 06Evidenceappend-only, exportable
Illustration of the 6-stage CRA Sentinel pipeline. Not a screenshot of the application.

When a case opens

What the clocks are measured from

Deadlines run from the moment awareness is recorded — not from when someone next signs in. Awareness is a recorded field, so a case opened late still measures from when your organisation actually knew.

0h — awareness is recorded

  1. 0124h

    Early warning

    from becoming aware

    An early warning that an actively exploited vulnerability, or a severe incident affecting the security of the product, exists. Submitted without undue delay and in any event within 24 hours.

  2. 0272h

    Detailed notification

    from becoming aware

    The fuller notification, giving what is known about the vulnerability or incident and any corrective or mitigating measures taken. Again without undue delay, and in any event within 72 hours.

  3. 03Final

    Final report

    measured from a different event

    Not a third countdown from awareness. For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident it is due within one month of submitting the 72-hour notification.

The 24-hour and 72-hour windows are drawn to scale against each other; the final report is deliberately off that scale because it is not measured from awareness. CRA Sentinel computes and tracks these stages from the awareness time your team records. It does not submit anything, and it does not decide whether a given event is reportable.

What stays yours

The decisions, and the record of them

CRA Sentinel is deliberately not an automated compliance engine. It gathers the evidence, computes the timing and keeps the record; your team decides.

  • A named person makes every triage decision. Machine API keys are refused for it.
  • Changing a decision keeps the previous one as a revision rather than overwriting it.
  • A person reviews and submits every report. Nothing is filed automatically.
  • Decisions not to report are recorded with their reasoning, the same as decisions to report.

What this workflow does not establish

Following these steps does not make an organisation compliant with the Cyber Resilience Act, and CRA Sentinel does not determine whether a given event is legally reportable. It supports the operational work and preserves the record; the legal determination, and the responsibility for it, remain with you. This is not legal advice.