Cyber Resilience Act · duty from 11 Sep 2026

Know before the clock starts.

From 11 September 2026, an actively exploited vulnerability gives you 24 hours to report. Also for products already in the field.

TrustEngine is the detection and evidence engine for CRA compliance. It wires your per-product SBOMs to live vulnerability and exploitation data, matches every new signal to the exact components and versions you ship, and maintains the living technical file the CRA expects, with controlled sharing so customers get proof, not blueprints.

scroll
The two dates

The deadline everyone plans for isn't the one that hits first.

December 2027 is the date on the roadmap. 11 September 2026 is the date obligations start. And it isn't a milestone you pass: it's a clock that can start any day after it, for any product you've shipped that is still out there.

On the roadmap
Dec 2027
Full applicability: conformity, CE marking, essential requirements. The date everyone is watching.
a milestone you plan for
Hits first
11 Sep 2026
Article 14 reporting duty: 24 hours after becoming aware of active exploitation. Also for products already on the market.
a clock that can start any day
Try it

An SBOM says what's inside. Not that it's on fire.

Paste a component list. It gets matched against exploitation signals, the noise is struck through with the judgement recorded, and what actually needs action comes out on top. This demo uses a small illustrative rule set; the product runs on live feeds.

93%not affected, documented
42 not affected3 need action
log4j-core@2.14.1actionzlib@1.2.11libpng@1.6.37glibc@2.31busybox@1.35pcre2@10.42libxml2@2.9.14expat@2.4.9ncurses@6.3readline@8.1gettext@0.21libffi@3.4.2sqlite@3.41.2nghttp2@1.51c-ares@1.18xz-utils@5.6.0actionkrb5@1.20gmp@6.2.1libuv@1.44icu4c@72.1harfbuzz@6.0freetype@2.12fontconfig@2.14cairo@1.17pixman@0.42openssl@3.0.1actionlibwebp@1.3.0jpeg-turbo@2.1.5libtiff@4.5.0openjpeg@2.5dav1d@1.0.0opus@1.3.1flac@1.4.2libogg@1.3.5dbus@1.14util-linux@2.38coreutils@9.1bash@5.1.16guava@31.1netty@4.1.86junit@5.9.1protobuf@3.21moment@2.29.4axios@1.4.0snakeyaml@1.33
Product-level, living

ISO covers the company. The CRA hands every product its own living file.

A certificate covers the organisation and gets renewed periodically. The CRA expects a technical file per product, and that file only helps if it reflects reality on the day something happens. Components change, new CVEs land daily, suppliers push updates.

ISO certificate · renewed yearly
pentest report · last March
SBOM_v7_FINAL_def2.xlsx · exported once
audit binder · point in time
RE: RE: evidence for the auditor
compliance spreadsheet · stale in days
Product file · v3.2signed
  • Components, updated today
  • VEX judgements, per version
  • Supplier attestations, in
  • Exploitation watch, live
  • History, every change recorded
compliance as a living state, not a periodic proof
What's inside

The engine behind the 24-hour clock.

Most teams are preparing documents: an SBOM, a process on paper. TrustEngine turns the document into a tool.

detection

Wired to live exploitation data

CVE streams, vendor advisories, CISA KEV, EPSS, OSV, ExploitDB. Awareness is the duty behind the duty: you cannot report in 24 hours what nothing told you happened.

matching

Every signal matched to what you ship

Not "log4j exists" but "log4j-core 2.14 ships in your v3.2, and the path is reachable". The match is what tells you the clock has started.

the living file

A technical file that never stands still

Per product, maintained through the support period, signed on every change. The file you build for the regulator is the file that defends you in court.

triage

Exploit-aware triage, written down

Every CVE gets a VEX judgement in the context of your build: reachable or not, affected or not. The noise is struck through with the reasoning recorded.

controlled sharing

Share proof, not blueprints

Views on the same SBOM: deep internally, shareable externally. Hand over SBOM plus VEX and you set the signal, instead of cleaning up other people's false positives.

the clock

When it starts, evidence is ready

A match drafts the early warning from the dossier: component, version, judgement, timeline. The 24 hours go into deciding, not into searching.

How it works

Three actions. One signature.

01

Ingest

Your SBOM comes in. Every component, every version, per product.

cyclonedx · spdx · ci hook
02

Match & triage

Live signals matched to what you actually ship. Noise struck through, judgement written down.

kev · epss · osv · vex per cve
03

Sign

The file is signed and stays current. Evidence ready when someone asks, or when the clock starts.

sha256 · verifiable by third parties
Article 14, verbatim

Three deadlines. One dossier.

0h
early warning to the CSIRT of your main establishment and ENISA, after becoming aware of active exploitation.
0h
intermediate report on the incident.
0 days
final report, after a corrective measure is available.
They have the document. They couldn't act on it.
What we keep finding in CRA engagements, even in teams that already ship SBOMs.

Mark what matters. Strike the rest.

0% panic added. Urgency comes from the dates, not from us.