EU CRA

The EU CRA policy pack maps the vulnerability-handling obligations of the European Union’s Cyber Resilience Act to a check the Anchore Enterprise policy engine can evaluate against container images and SBOMs. The pack is deliberately narrow, enforcing only the Act’s requirement that products ship free of known exploitable vulnerabilities, and ships as a single bundle ready to import as a policy.

Current EU CRA policy pack version: EU-CRA 2026.1

The EU CRA pack requires the Anchore Enforce entitlement. Contact Anchore Customer Success for access and more information.

Introduction

The Cyber Resilience Act sets cybersecurity requirements for products with digital elements placed on the EU market. It applies to manufacturers rather than operators: if you sell or distribute software or a connected product in the EU, the obligations attach to you, and CE marking depends on meeting them. That reach makes it relevant well beyond EU-based vendors: any supplier shipping into the single market is in scope.

The Act’s Annex I Part I sets out the security properties a product must have when it is made available, including that it be delivered without known exploitable vulnerabilities. Part II covers the vulnerability handling that follows: maintaining an SBOM, addressing vulnerabilities without delay, and reporting actively exploited vulnerabilities to ENISA.

This pack addresses the Annex I Part I requirement directly, using the CISA Known Exploited Vulnerabilities (KEV) catalog as the evidence that a vulnerability is exploited in practice. The wider Part II obligations are process and reporting duties rather than artifact checks, but they lean on the same machinery: the SBOMs Anchore Enterprise generates, and the VEX annotations that record how each finding was assessed.

Controls

Anchore Enterprise checks for the following control specifications against container images and SBOMs:

Rule set	Anchore role	Applies to
`Container KEV`	Fail when any package is affected by a vulnerability on the CISA KEV catalog	Container images
`SBOM KEV`	Fail when any component is affected by a vulnerability on the CISA KEV catalog	SBOMs

Both rule sets are bound to a default mapping matching every registry, repository, and tag, and both share an empty DefaultAllowlist ready for your accepted risks.

VEX Annotations

Each rule set is split into two rules that differ only in annotation state, as described in Annotations and VEX:

One rule matches KEV findings that carry no annotation yet, so un-triaged exploitable vulnerabilities fail the evaluation.
The other matches KEV findings annotated affected or under_investigation.

Findings annotated not_affected or fixed match neither rule. This is the mechanism that makes a narrow KEV gate workable under the CRA: a KEV-listed vulnerability whose code is not reachable in your product is assessed, justified, and cleared from the evaluation, and the assessment travels into the VEX document a downstream consumer or market surveillance authority can read.

Use the Pack

Import the pack like any other policy. See Manage Policies for the GUI, AnchoreCTL, and API workflows. Once imported, scope it to the registries and repositories it should apply to through Policy Mappings, and attach any allowlists you need before activating it as the account’s default policy.

Because the pack enforces a single requirement, most teams run it alongside a broader policy, such as the Secure pack or a framework pack, rather than as their only active policy.