Prepare for the EU Cyber Resilience Act

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) places continuous obligations on any manufacturer of a “product with digital elements” sold on the EU market: document what is inside every release, place no release on the market with known exploitable vulnerabilities, and, from 11 September 2026, report actively exploited vulnerabilities to your CSIRT and ENISA within 24 hours.

This quickstart walks one product release through that lifecycle using Anchore Enterprise: model the product, bring its SBOMs into the system, continuously monitor the release against policy, and respond with evidence when an exploited vulnerability appears.

Before You Begin

You will need:

• Anchore Enterprise v6.1.0 or later and a matching AnchoreCTL, configured against your deployment.
• A completed feed sync that includes the EPSS and CISA KEV datasets. Verify under System > Health in the GUI, or with anchorectl feed list.

Every workflow in this guide can be driven from the Anchore Enterprise GUI. The steps below use AnchoreCTL commands, with the GUI path called out where it is the natural fit.

Model Your Product

The CRA’s unit of compliance is the product placed on the market. In Anchore Enterprise that is an App; each release you ship is a Version, and everything inside a release (container images, filesystem scans, imported SBOMs) are its Assets.

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

The version status field (in_progress, released, eol) mirrors the CRA product lifecycle; you will use it again when the release eventually leaves support.

Generate and Store the Release SBOMs

The CRA (Annex I, Part II (1)) requires a machine-readable SBOM covering at least the product’s top-level dependencies. A real product is rarely a single artifact, so add assets from different sources into the same version:

# A container image that Anchore Enterprise pulls and analyzes (centralized analysis)
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

# A third-party supplier component, imported exactly as the supplier delivered it
anchorectl app version asset add sbom telemetry-module-1.8.0.cdx.json \
  --app iot-gateway --version 2.4.0 --asset telemetry-module -t module --wait

You can also scan a local directory tree, such as a build output, an unpacked firmware image, or a mounted VM disk, as a filesystem asset; see also the Create SBOMs from Virtual Machines quickstart.

In the GUI, open Applications > iot-gateway > 2.4.0: the Contents tab shows one deduplicated package view across all assets, including licenses and which asset contains each package.

Make the SBOM Available to Authorities

Two CRA annexes turn the stored SBOM into a document you must be able to produce on demand. Annex II (9) requires the information you give users to state where the SBOM can be accessed, if you choose to make it available to them. Annex VII includes the SBOM in the product’s technical documentation, which market-surveillance authorities can request at any point while the product is on the market.

In the GUI, use the version’s Download menu to export the unified SBOM as CycloneDX 1.6 or SPDX 2.3: a single machine-readable document covering every asset in the release. With AnchoreCTL:

# CycloneDX 1.6
anchorectl app version export sbom-cyclonedx-1 2.4.0 --app iot-gateway -f iot-gateway-2.4.0.cdx.json

# SPDX 2.3
anchorectl app version export sbom-spdx-2 2.4.0 --app iot-gateway -f iot-gateway-2.4.0.spdx.json

The document is produced from the stored SBOMs at the moment you request it, so the same release yields the same component inventory whether the request arrives at launch or years into the support period.

Monitor the Release Against Policy

Annex I Part I (2)(a) requires that products are made available “without known exploitable vulnerabilities”. Policies express that requirement as enforceable rules, and they work in two ways: as a release gate at ship time, and as the ongoing monitoring mechanism once the release is on the market. The bundled default policy already stops on CISA KEV-listed findings and critical severities.

For a dedicated CRA baseline and your own testing, consider creating a new policy in the policy editor with two rules on the vulnerabilities gate: STOP when a finding is listed on the CISA KEV catalog, and STOP when its EPSS score is at or above a threshold you choose (0.75 is a common starting point). Stricter rule sets can be layered on from there. Associate the policy with the product so every version is evaluated against it:

anchorectl app update iot-gateway --policy-id eu-cra-baseline

Evaluate the release; in CI, the exit code is the gate:

anchorectl app version policy status get 2.4.0 --app iot-gateway --fail-based-on-results

If the evaluation fails, inspect the findings:

anchorectl app version policy findings list 2.4.0 --app iot-gateway

or use the version’s Compliance tab in the GUI, where findings can be sorted and filtered by policy rule. For pipeline integration patterns, see the CI quickstart.

A passing evaluation is not the end of the job; this is where policy becomes the monitoring mechanism. Anchore Enterprise re-evaluates stored SBOMs on every vulnerability database update, so a shipped release that starts violating the policy surfaces immediately, without anything being rescanned. Configure event notifications so that signal reaches Slack, Jira, Microsoft Teams, or a webhook.

Respond to an Exploited Vulnerability

The detection mechanism is the policy itself: when a vulnerability database update brings a new finding, such as a CVE newly listed on the CISA KEV catalog, a shipped release that was passing starts failing its policy evaluation, and the event notifications configured in the previous section carry that signal to your team.

From 11 September 2026, an actively exploited vulnerability in a product on the EU market starts Article 14’s clock: a 24-hour early warning, a 72-hour notification, and a 14-day final report. The first thing every one of those needs is scope: which products and releases are affected?

Find the blast radius. Start from the failing evaluations: the events and notifications name each App Version that has started failing, the Applications view in the GUI shows compliance status per version, and each version’s Compliance tab identifies the finding responsible.

There is also a search capability. Press Ctrl/Cmd+K anywhere in the GUI and enter a vulnerability ID (for example CVE-2022-22965): the quick vulnerability search returns every App Version containing an affected package, across your whole portfolio, in seconds.

Record the assessment as VEX. Document your engineering analysis as vulnerability annotations using the standard VEX status and justification vocabulary. In the GUI, open the finding in the version’s Vulnerabilities tab and record an annotation: a status of Affected, Not Affected, Fixed, or Under Investigation, a justification where applicable, and your impact or action statement. The same annotation can be recorded with AnchoreCTL; the values below are illustrative:

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; free of charge per Annex I Part II (8)."

Annotations apply to a specific vulnerability-and-package pair and flow through to listings, summaries, and exports.

Export the evidence. Produce a CycloneDX Vulnerability Disclosure Report (VDR) that carries the product identity, components, findings, and your VEX analysis in one document. In the GUI, use the version’s Download menu and choose the VDR export; or with AnchoreCTL:

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

Submit the report. Article 14 notifications are made through the ENISA Single Reporting Platform (SRP), the single entry point that opens on 11 September 2026. Manufacturers register with an EU Login account, the designated national CSIRT validates your representatives on first access, and one electronic submission reaches your coordinator CSIRT and ENISA simultaneously. Submit the early warning within 24 hours of awareness and the notification within 72 hours; the VDR you exported above provides the supporting technical detail at each stage.

Ship the Fix and Maintain the Support Period

Annex I Part II requires security updates to be distributed without delay, and Article 13 (8) obliges you to keep handling vulnerabilities for the product’s support period (at least five years). Model the security update as a new linked version containing the fixed components:

anchorectl app version add 2.4.1 --app iot-gateway --previous-version 2.4.0 --status in_progress

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

anchorectl app version asset add sbom telemetry-module-1.9.0.cdx.json \
  --app iot-gateway --version 2.4.1 --asset telemetry-module -t module --wait

anchorectl app version policy status get 2.4.1 --app iot-gateway

With the affected components updated, the finding clears and the gate passes. For the public advisory obligation (Annex I Part II (4)), export the VEX document for the affected release:

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

Both versions now stay registered and are re-evaluated automatically on every vulnerability database update for as long as they exist; this is the support-period obligation running at zero marginal effort. Scheduled reports provide the recurring review evidence Annex I Part II (3) expects. When a release finally leaves support:

anchorectl app version update 2.4.0 --app iot-gateway --status eol

Summary

For one product release you now have a machine-readable SBOM, an exploitability-based release gate, a documented VEX assessment, a regulator-ready VDR, and ongoing security updates driven by continuous monitoring. That is the working skeleton of a CRA vulnerability-handling process.

The reference map below shows how each CRA obligation maps to the Anchore Enterprise capability used in this guide.