What the EU Cyber Resilience Act Actually Requires from Software Vendors

· Yunus Yildiz

Context

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) was published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024. Article 14 reporting obligations apply from 11 September 2026; full application is 11 December 2027 for products with digital elements placed on the EU market.

Most vendor communication treats the CRA as a checkbox exercise. It is not. The regulation creates enforceable technical obligations. Under Article 64(2), non-compliance with the essential cybersecurity requirements in Annex I and the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15 000 000 or 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher.

Reality Check

Common Belief

"CRA compliance means adding a security policy page and generating an SBOM at release time."

Why That's Incomplete

The CRA requires ongoing vulnerability management, signed artifacts, and machine-readable transparency throughout the product lifecycle. A one-time SBOM export does not satisfy the regulation.

Annex I Part II point (1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials" — a continuous obligation across the support period, not a release-time activity. The support period itself is defined in Article 13(8): a manufacturer must determine a support period reflecting the time the product is expected to be in use, and during that period must handle vulnerabilities effectively in line with Annex I Part II.

Compliance is not a document. It is an operational capability.

Engineering Implications

The CRA imposes these technical requirements on software distributed in the EU:

1. SBOM Persistence and Accessibility

Requirement: Annex I Part II point (1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products."

What this means:

  • SBOMs must be produced as part of the manufacturer's vulnerability-handling process during the support period, not just at release
  • A commonly used machine-readable format (SPDX or CycloneDX, JSON or XML — not PDF)
  • The OJ language is explicit that the minimum scope is top-level dependencies; many regulators and customers will expect transitive coverage
  • Must be available on request to market surveillance authorities — see Article 23 on identification of economic operators and Annex VII on technical documentation

Common failure: Generating SBOMs manually before audits, not as part of CI/CD.

2. Artifact Signing and Provenance

Requirement: Annex I Part I point (2)(f) requires products with digital elements to "protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions." Annex I Part I point (2)(c) requires update distribution mechanisms (notification, automatic updates with opt-out, postponement). For the secure distribution of those updates and the disclosure of fixed vulnerabilities, see Annex I Part II points (2), (4) and (8).

What this means:

  • Cryptographic signatures on all distributed artifacts (container images, binaries, packages) — the regulation does not name a specific scheme; the obligation is to make integrity verifiable
  • Signatures must be verifiable by downstream consumers, which is what makes the "secure mechanism" demonstrable
  • Provenance attestations linking artifacts to source commits and build processes support both the integrity requirement and the Article 13(5) due-diligence obligation on third-party components
  • Private-key management must prevent unauthorised signing

Common failure: Signing release artifacts but not development/staging builds, creating a gap in the supply chain.

3. Vulnerability Handling Timeline

Requirement: Article 14 sets binding reporting deadlines for actively exploited vulnerabilities and severe incidents, simultaneously to the designated CSIRT coordinator and to ENISA, via the single reporting platform established by Article 16:

  • 24 hours — early warning notification (Art. 14(2)(a) for vulnerabilities; Art. 14(4)(a) for severe incidents)
  • 72 hours — notification with general information and any mitigations taken (Art. 14(2)(b), 14(4)(b))
  • 14 days — final report after a corrective or mitigating measure is available, for vulnerabilities (Art. 14(2)(c)); or one month after the 72-hour notification for severe incidents (Art. 14(4)(c))

In parallel, Annex I Part II requires manufacturers to address vulnerabilities "without delay," provide free security updates, and inform users when updates are available.

What this means:

  • Automated vulnerability scanning integrated into artifact registries
  • Defined SLAs for patching based on severity (not just "we'll fix it when we can")
  • Mechanisms to notify users of vulnerable versions they are running
  • Audit trail of vulnerability discovery, assessment, and remediation — needed to demonstrate the 24h/72h/14d clock starts at "becoming aware"

Common failure: Treating vulnerability management as a quarterly review instead of a continuous process.

4. Auditability and Logging

Requirement: Article 31 and Annex VII require manufacturers to draw up and keep technical documentation that demonstrates conformity with the essential cybersecurity requirements. Under Article 13(13), manufacturers must "keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer."

What this means:

  • Immutable logs of who built what, when, and from which source
  • Signature verification logs showing artifact integrity checks
  • Evidence of vulnerability scan results at the time of release
  • Retention period of at least 10 years or the support period — whichever is longer (Art. 13(13))

Common failure: Logs stored in mutable systems or discarded after 90 days.

Failure Modes

Pattern 1: SBOM Generation as a Pre-Audit Activity

Teams generate SBOMs manually when regulators or customers ask for them. This fails because:

  • SBOMs generated after the fact may be incomplete or inaccurate
  • No evidence that the SBOM reflects what was actually shipped
  • Impossible to retroactively generate SBOMs for past releases

The CRA expects SBOMs to be an output of the build process, not a separate documentation task.

Pattern 2: Vulnerability Scanning Without Blocking

Teams run vulnerability scanners but allow critical vulnerabilities to be deployed "because the release is urgent."

This fails because:

  • Article 13(1) requires manufacturers to ensure the product has been designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I Part I, which include "an appropriate level of cybersecurity based on the risks" (point (1)) and being "made available on the market without known exploitable vulnerabilities" (point (2)(a))
  • Knowingly shipping a known exploitable vulnerability conflicts with this duty
  • Audit logs showing ignored scan failures are evidence of non-compliance

Scanning without enforcement is not compliance. It is evidence of awareness followed by inaction.

Pattern 3: Treating Artifact Registries as Passive Storage

Teams use container registries or package repositories as storage without security controls.

This fails because:

  • The integrity obligations in Annex I Part I point (2)(f) — and the update distribution requirements in 2(c) — apply to the whole delivery path
  • Unsigned or unverified artifacts can be replaced by attackers
  • No provenance means no way to demonstrate what was delivered when

Artifact infrastructure is now part of the regulated system, not just a deployment tool.

What "Good" Looks Like

A CRA-compliant software delivery system has these properties:

  1. Automated SBOM Generation: Every build produces a machine-readable SBOM as a first-class artifact, signed and versioned alongside the software.

  2. Signed Artifacts with Provenance: All distributed binaries, containers, and packages are cryptographically signed. Signatures are verifiable by downstream consumers. Provenance attestations link artifacts to source commits.

  3. Continuous Vulnerability Monitoring: Artifact registries scan for vulnerabilities automatically. Critical findings trigger alerts and block deployment until resolved or explicitly accepted with justification.

  4. Immutable Audit Trail: Build logs, scan results, signature operations, and deployment events are stored in append-only systems with tamper-evident properties. Retention aligns with product support lifecycle.

  5. Defined Remediation SLAs: Vulnerabilities are categorized by severity with documented response timelines. Critical: 24-48 hours. High: 7 days. Medium: 30 days. Adherence is measured and reported.

These are system properties, not documentation artifacts.

Limits & Trade-offs

This approach does not:

  • Prevent all vulnerabilities: CRA does not require zero vulnerabilities. It requires disclosure, transparency, and timely remediation.
  • Eliminate manual review: Some vulnerability findings require human judgment (false positives, exploitability assessment). Automation reduces the scope of manual work but does not remove it.
  • Guarantee regulatory acceptance: CRA enforcement is still evolving. What constitutes "without delay" or "commonly used format" may be clarified through enforcement actions or guidance updates.

Compliance is a moving target. The goal is defensibility, not perfection.

Key Takeaways

  • CRA requires SBOM generation, artifact signing, and vulnerability management as operational capabilities, not documentation exercises.
  • Artifact registries and build pipelines are now part of the regulated system and must support auditability, integrity, and continuous scanning.
  • Vulnerability remediation timelines are enforceable obligations, not best-effort targets.
  • Compliance is demonstrated through immutable audit logs, not policy documents created before audits.
  • The regulation leaves room for interpretation. What matters is the ability to demonstrate ongoing effort, transparency, and timely response.

This article reflects the technical team's understanding of CRA obligations as of May 2026. Article and Annex references were verified against the consolidated EUR-Lex text (CELEX 32024R2847) and are linked to the on-site CRA explorer. It is not legal advice. For compliance questions specific to your product, consult qualified legal counsel.