EU CRA turns release evidence into a continuous compliance control

At a glance

What this is: Anchore shows that EU CRA compliance depends on continuous release-level evidence, not annual review cycles, because active exploitation must be reported within 24 hours once it is known.

Why it matters: This matters because product security, vulnerability management, and release governance teams now need evidence generation, policy evaluation, and reporting to operate as one control loop.

By the numbers:

• Non-compliance under the EU CRA can mean fines up to €15 million or 2.5% of global annual turnover.

Context

The core problem is a compliance model that assumes vulnerability review can happen later, after discovery, investigation, and internal debate. EU CRA collapses that timeline by tying compliance to what is in each release, whether it includes known exploitable vulnerabilities, and how quickly a product team can prove that state when active exploitation appears.

For teams handling software releases, SBOMs, VEX annotations, and reporting evidence become part of the control plane, not post-incident paperwork. That is especially important for product security and software supply chain teams because the regulation applies to products already on the market, so the evidence burden exists across the full support lifecycle.

Key questions

Q: What breaks when release compliance is still managed as a periodic review under EU CRA?

A: Periodic review breaks because the regulation is tied to what is in the release and whether a vulnerability is actively exploited now, not when the next scan runs. If evidence gathering starts only after detection, the team can lose the 24-hour reporting window before it has a defensible affected state and a reportable record.

Q: Why do known exploited vulnerabilities create a faster compliance risk than ordinary CVEs?

A: Known exploited vulnerabilities create faster risk because they immediately change the reporting and market-compliance posture of a shipped release. The issue is not just remediation urgency. It is that the organisation may need to prove impact, notify regulators, and preserve evidence before engineering work is complete.

Q: What are the signs that SBOM-based compliance is failing in release operations?

A: The main signs are manual evidence reconstruction, inconsistent affected-status decisions across teams, and dependence on scheduled scans to discover whether a release is reportable. If SBOMs, VEX notes, and product ownership live in different systems, the organisation is likely to miss deadlines when vulnerability intelligence changes quickly.

Q: How should teams balance engineering remediation and regulatory reporting under EU CRA?

A: Treat them as parallel obligations, not sequential ones. Engineering should fix the vulnerable component, while product security should preserve the product version, affected assessment, and reporting trail. The goal is to make regulatory submission possible even when remediation is still in progress or supply-chain evidence is incomplete.

Technical breakdown

Why periodic vulnerability review fails under EU CRA

Traditional vulnerability management is built around batch cycles. A scanner finds a flaw, analysts validate it, and someone later decides whether it matters for reporting or remediation. EU CRA changes the mechanism by binding compliance to release identity and active exploitation status, which means the relevant state must already be known when the clock starts. That makes the release version, its components, and its evidence trail the unit of control, not the scan result.

Practical implication: move from scan-centric workflows to release-centric governance so evidence exists before a reporting deadline begins.

How SBOM, VEX, and VDR work together

An SBOM tells you what is in the release, VEX records whether a specific vulnerability affects that release, and a VDR packages the product, component, and analysis trail into a reportable artifact. The important architectural point is that these are linked records, not separate documents. When the underlying vulnerability data changes, the compliance state can change even if the code has not, which is why continuous re-evaluation matters.

Practical implication: connect SBOM ingestion, VEX decisions, and VDR export into one governed release pipeline.

Why event-driven policy evaluation matters

A fixed policy gate at build time misses the real regulatory problem, because known exploited vulnerability status can change after release. Event-driven policy evaluation closes that gap by rechecking stored release evidence whenever vulnerability intelligence updates. In compliance terms, that turns detection into governance: the team no longer waits for a manual rescan to learn that a release has become reportable under EU CRA.

Practical implication: trigger alerts from policy state changes, not from scheduled scans, so response starts as soon as compliance changes.

Threat narrative

Attacker objective: The practical attacker outcome is to exploit a shipped vulnerability before the vendor can complete evidence gathering and regulatory reporting.

1. Entry occurs when a newly known exploited vulnerability is mapped back to an already shipped product release.
2. Credential or component exposure is represented by the affected package or asset already embedded in the release SBOM.
3. Escalation happens when the release moves from compliant to non-compliant before manual review can catch up.
4. Impact is regulatory and operational, because the product can miss the 24-hour reporting window and face market restrictions or fines.

Breaches seen in the wild

• Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
• ShinyHunters FBI breach claim 2026: ShinyHunters claims it used a PeopleSoft flaw to breach the FBI and pivot into AWS GovCloud; the FBI has confirmed only an investigation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous compliance is now a release property, not a quarterly activity. EU CRA effectively moves governance from retrospective review to always-on evidence generation. That matters because software teams can no longer assume a scan, a ticket, or a board report is enough when exploitation status changes outside the release cadence. Practitioners should treat the release itself as the controlled object and design compliance around it.

Evidence readiness is the real control gap the regulation exposes. The weak point is not the absence of a vulnerability scanner but the delay between discovery, validation, and reportable proof. When that delay is longer than the reporting clock, the organisation is already exposed. Teams need release-scoped evidence trails that make the reporting answer available before regulators ask the question.

Release governance is becoming a supply chain identity problem as well as a vulnerability problem. Once a product version aggregates supplier SBOMs, imported components, and signed compliance decisions, the control challenge is provenance and accountability across the release chain. That is where product security intersects with identity governance in a practical sense: who attested to what, for which version, and with what evidence? Practitioners should map those attestations to a durable control owner model.

Known exploited vulnerability pressure will force faster decision-making across security, legal, and engineering. EU CRA does not leave room for open-ended triage, so the organisation must pre-agree what counts as affected, not affected, and fixed. That is a governance design issue, not just a tooling issue. Teams should standardise release-level decision criteria before the next active exploitation event occurs.

What this signals

EU CRA makes evidence freshness part of operational resilience. Product teams can no longer treat SBOM generation as a launch-time task, because compliance can change when vulnerability intelligence changes. The practical programme shift is to keep release records live, versioned, and immediately reportable when a known exploited vulnerability appears.

Release governance needs a named concept: compliance latency. That is the delay between a release becoming reportable and the organisation being able to prove its status. The longer that latency, the more likely a team misses the regulatory clock or issues an incomplete report. Practitioners should focus on shrinking that gap by design, not by after-the-fact escalation.

For product security teams, the most important control is decision speed, not just detection speed. A scanner can find a vulnerability, but EU CRA expects the organisation to decide, evidence, and report quickly enough to satisfy a fixed deadline. That means release owners, PSIRT functions, and legal stakeholders need an agreed operating model before the next exploited flaw emerges.

For practitioners

• Define the product as the compliance unit Model each shipped product as a release-scoped asset with versioned component inventory, ownership, and reporting metadata so evidence is tied to the release rather than the scan job.
• Automate SBOM and VEX linkage Keep imported supplier SBOMs, container analyses, and engineering VEX decisions in a single release record so the affected state can be exported without reconstruction.
• Trigger alerts from policy-state changes Configure notifications when a release moves from pass to fail because vulnerability intelligence changed, and route those alerts into product security and incident response queues.
• Prebuild the VDR evidence path Standardise the evidence set needed for the Vulnerability Disclosure Report, including component identity, affected assessment, and final disposition, before an exploited vulnerability appears.

Key takeaways

• EU CRA turns software release management into a continuous compliance discipline with hard reporting deadlines and market consequences.
• The weak point is not only vulnerability detection, but the time it takes to turn component data into a defensible reportable decision.
• Teams that tie SBOMs, VEX decisions, and policy alerts to each release will handle exploited vulnerabilities with less operational disruption.

Key terms

• Compliance latency: The delay between a security weakness being introduced and the organisation proving that its controls still work. In fast-changing environments, that delay creates a gap between documented assurance and real risk, which can leave audits aligned to history rather than current conditions.
• Vulnerability Disclosure Policy: A vulnerability disclosure policy is the public process for receiving security reports from anyone who finds a problem. It sets expectations for safe reporting, response timing, and escalation, so researchers can disclose issues without guessing where or how to send them.
• Release-Scoped Governance: A control model that treats each software version as the unit of inventory, risk decision-making, and evidence retention. It is more reliable than scan-centric governance because it keeps ownership, component identity, and compliance state attached to the release itself.
• Policy State Change Notification: An automated alert triggered when a control decision changes, such as a release moving from pass to fail after new vulnerability intelligence arrives. This is useful when compliance depends on fresh evidence rather than a static approval check.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps security and IAM practitioners connect identity control discipline to wider governance demands.