What the EU Cyber Resilience Act Actually Requires from Software Vendors

· Eurtifact Platform Team

Context

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in October 2024. Full compliance is required by 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 with financial penalties up to €15 million or 2.5% of global annual turnover.

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.

Article 13(5) requires manufacturers to “identify and document vulnerabilities and components” not just at release, but continuously. Article 14 requires security updates “without delay” and “for the expected lifetime of the product.”

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: Article 13(5) mandates a Software Bill of Materials that is “in a commonly used and machine-readable format.”

What this means:

  • SBOMs must be generated automatically as part of the build process
  • SPDX or CycloneDX format (JSON or XML, not PDF)
  • Must include all transitive dependencies, not just direct ones
  • Must be accessible to users and authorities upon request

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

2. Artifact Signing and Provenance

Requirement: Article 13(1) requires ensuring the integrity of products “by means of technical solutions.”

What this means:

  • Cryptographic signatures on all distributed artifacts (container images, binaries, packages)
  • Signatures must be verifiable by downstream consumers
  • Provenance attestations linking artifacts to source commits and build processes
  • Private key management must prevent unauthorized 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(1) requires security updates “without delay” and Article 11 mandates reporting actively exploited vulnerabilities within 24 hours.

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

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

4. Auditability and Logging

Requirement: Article 13(6) requires documentation sufficient to demonstrate conformity.

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 aligned with product support lifecycle (typically 5+ years)

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(2) requires products to be secure “by default”
  • Knowingly shipping critical vulnerabilities violates the duty of care
  • 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:

  • Article 13(1) requires protection against tampering
  • Unsigned or unverified artifacts can be replaced by attackers
  • No provenance means no way to prove what was delivered

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 January 2026. It is not legal advice. For compliance questions specific to your product, consult qualified legal counsel.