Most compliance frameworks treat a review as a once-a-year event. The EU CRA doesn’t work that way. It requires you to know what’s in every release, prove that no release ships with a known exploitable vulnerability, and since September 11, 2026, report an actively exploited vulnerability within 24 hours of becoming aware of it. That last part applies to products already on the market today, not just new ones, and the clock doesn’t pause because your evidence isn’t ready yet.

EU CRA’s 24-hour reporting deadline: the stakes and the timeline

Non-compliance can mean fines up to €15 million or 2.5% of global annual turnover, and national regulators have the authority to pull a product from the EU market entirely. Article 14’s reporting obligation runs on a 3-stage clock once you become aware of active exploitation: a 24-hour early warning, a 72-hour notification, and a 14-day final report, all submitted through ENISA’s Single Reporting Platform, a single entry point that itself only opened on September 11, 2026.

Most vulnerability management processes are built around periodic scanning: something finds a problem, someone investigates, someone else decides what to report. A 24-hour deadline doesn’t leave room for that sequence to start from zero.

How the quickstart takes a product from SBOM to Compliance

Anchore Enterprise’s CRA quickstart treats the product itself, not an individual scan, as the unit of compliance. You model your product as an App, each release as a Version, and everything that makes up that release as Assets attached to it:

anchorectl app add iot-gateway \
  --contact-name "Product Security Officer"\ 
  --contact-email [email protected] \
  --description "Industrial IoT gateway - product with digital elements"

anchorectl app version add 2.4.0 --app iot-gateway --status released --release-date 2026-06-15

A real product is rarely one artifact, so assets can come from different sources into the same version, a container image Anchore Enterprise pulls and analyzes directly, and a supplier-delivered SBOM imported exactly as received:

anchorectl app version asset add container-image-remote registry.example.com/iot-gateway/web-console:2.4.0 --app iot-gateway --version 2.4.0 --asset web-console --wait

anchorectl app version asset add sbom telemetry-module-1.8.0.cdx.json --app iot-gateway --version 2.4.0 --asset telemetry-module -t device --wait

Once all of the assets are added to a release version, the release is exportable via a single, unified SBOM in CycloneDX and SPDX format.

Monitor for compliance

Policy is what turns “no known exploitable vulnerabilities” from a stated requirement into something enforced. A CRA-focused policy stops on any KEV-listed finding. That policy attaches to the product and gets evaluated the same way in CI as anywhere else:

anchorectl app update iot-gateway --policy-id eu-cra-baseline
anchorectl app version policy status get 2.4.0 --app iot-gateway --fail-based-on-results

As soon as your product becomes non-compliant with the known exploited vulnerability requirement, it’ll begin to fail policy evaluation. This is the part that matters most for the 24-hour clock. Anchore Enterprise re-evaluates every stored SBOM against updated vulnerability data and policy automatically, so a release that was compliant 6 hours ago and isn’t now gets flagged the moment the underlying data changes, not the next time someone happens to rescan it or tomorrow, burning through the 24-hour reporting window. 

Automating alerts when policy compliance changes

You can use Anchore Enterprise to operationalize the 24-hour reporting deadline; Anchore Enterprise emits automated policy_status_changed notifications at the Application Version level whenever a release’s compliance outcome shifts, such as moving from PASS to FAIL according to your policy rules, such as when a newly published CVE which is known to be exploited affects an asset.

By configuring notification subscriptions to endpoints like Webhooks, Slack, Teams, Jira, GitHub or email, Anchore Enterprise immediately triggers an alert the moment background re-evaluation detects a compliance state change. This event-driven mechanism gives incident response and product security teams immediate notice, starting the triage and VEX process as soon as the 24-hour CRA clock begins.

When that happens, the response follows a specific evidence trail: view the policy results or search across every release for the affected package or CVE, record the engineering assessment as a VEX annotation with a status like affected, not affected, or fixed, and export a Vulnerability Disclosure Report that bundles the product identity, the components, and that VEX analysis into one document:

anchorectl app version vex add 2.4.0 --app iot-gateway --vuln-id CVE-2022-22965 --pkg-name spring-beans --pkg-type java-archive --pkg-version 5.3.17 --status affected --action-statement "Security update 2.4.1 ships the supplier's fixed component."

anchorectl app version export vdr 2.4.0 --app iot-gateway -f iot-gateway-2.4.0-vdr.cdx.json

That VDR is the document that can support the actual submission through ENISA’s SRP.

The outcome: evidence ready before the 24-hour clock starts

Go back to where this started: a 24-hour reporting clock only works if the scope-finding step, which products and releases are affected, doesn’t have to start from a blank page. That’s what continuous re-evaluation against a stored SBOM actually buys you: the answer exists before the question gets asked under pressure.

The technical outcome is a release that’s monitored for the entire support period, not just checked once at launch, with SBOM, VEX, and VDR evidence generated as a byproduct of that monitoring rather than assembled from scratch during an active incident. The business outcome is meeting a genuinely hard, dated regulatory deadline as routine operation instead of a fire drill every time a new exploited vulnerability appears in the news.

We’ve walked through this exact workflow live with partners including Red Hat and Bitsea, whose 5-step CRA readiness framework treats SBOM generation and ongoing risk monitoring as the long pole in the process, not a box to check once. The pattern holds regardless of which specific product or industry: the earlier a product’s SBOM and policy evaluation are in place, the less the September 2026 deadline changes about how a team actually operates day to day.

This is the same product-lifecycle workflow Anchore Enterprise customers used to prepare for September 11, 2026, today. If you’re already running Anchore Enterprise, our EU CRA quickstart walks through the full lifecycle end to end, from modeling a product through submitting evidence via ENISA’s SRP. 

If you’re evaluating how ready your own release process actually is, request a demo and bring your product’s current SBOM and reporting process to the conversation.

This is the fifth and final post in this series. Post 4 covered how FedRAMP and CMMC’s 2026 changes affect a federal Authority to Operate; this one covers the other major compliance regime most software vendors are watching right now: the EU Cyber Resilience Act. That closes out the series from SBOM inventory through Kubernetes visibility, zero-day response, and compliance under both US federal and EU regulatory regimes.

Learn how to operationalize compliance, enforce deterministic policy gates, and automate your path to an audit-ready software supply chain.

Download Now