EU Cyber Resilience Act Explained for Engineering Teams

The EU Cyber Resilience Act (CRA — Regulation (EU) 2024/2847) entered into force on 10 December 2024 (twenty days after publication in the Official Journal on 20 November 2024). For software vendors, this changes everything: machine-readable SBOMs are no longer optional, vulnerability response timelines are now legal obligations, and non-compliance carries fines of up to €15 million or 2.5% of global annual turnover under Article 64(2)(a).

For teams shipping AI-generated code, the stakes are higher. The CRA's vulnerability handling obligations under Annex I, Part II — combined with the Article 14 24/72-hour reporting clock for actively-exploited vulnerabilities — make the absence of AI attribution metadata a compliance risk. If you don't know whether a vulnerability was introduced by a human or an AI agent, you cannot properly assess your remediation timeline or root-cause the incident report Article 14 requires within 14 days.

What Changed and When

The CRA has a tiered enforcement timeline. Understanding which obligations apply to your organization requires mapping your product to the timeline:

10 December 2024 (Entry into Force — Already in effect)

• Regulation is now law in all EU member states
• Manufacturers must reach full compliance by 11 December 2027 (the staged transition under Article 71)
• New products placed on the EU market after the application dates must comply immediately

11 September 2026 (Vulnerability and Incident Reporting Obligations Apply)

This is the first hard regulatory deadline (Article 14 reporting under Article 71). All manufacturers must:

• Be ready to publish a machine-readable SBOM alongside affected products (the SBOM obligation itself sits in Annex I, Part II, point (1), referenced from Article 13, and applies fully from 11 December 2027)
• Notify the relevant CSIRT and ENISA when an actively exploited vulnerability is contained in their product, or when a severe incident affects the security of the product:
  • Early warning: within 24 hours of becoming aware
  • Vulnerability / incident notification: within 72 hours
  • Final report: within 14 days for actively exploited vulnerabilities (within one month for severe incidents)
  • The trigger is active exploitation and severe incident — not "any critical CVE in your dependency tree"

11 December 2027 (Full Application)

All requirements fully apply. Article 64 administrative fines become enforceable across the regulation's full scope.

Who Is In Scope

The CRA applies to products with digital elements sold to EU customers. This includes:

• Cloud software accessed by EU users
• Mobile apps distributed to EU markets
• Developer tools used by EU engineering teams
• Infrastructure software running in EU data centers
• AI agents and autonomous systems that generate or modify code

Not in scope:

• Free software released under an open-source license unless you provide professional support or services around it
• Custom software developed under contract for a specific customer

Most vendors are in scope. If you have any EU customers or market into the EU, assume CRA applies.

SBOM Mandates: Format and Content

The CRA specifies what must be in the SBOM but leaves format flexibility:

Accepted Formats:

• CycloneDX (recommended; native for security-focused SBOMs)
• SPDX (for license compliance emphasis)
• Other machine-readable formats, provided they contain all mandatory elements

What the regulation actually mandates (Annex I, Part II, point (1), referenced from Article 13):

The CRA requires manufacturers to "identify and document vulnerabilities and components contained in the product, 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 product." Format flexibility is preserved — CycloneDX and SPDX both qualify.

The legally mandated minimum is therefore narrower than most enterprise SBOM templates. Top-level dependencies in a machine-readable format are the regulatory floor; transitive dependencies, full license data, dependency relationships, and timestamps are best practice but not specifically required by the CRA itself.

Recommended SBOM content (regulatory minimum + best practice):

For AI-coded software, add:

• AI Attribution Metadata — Which components or patches were generated or modified by AI agents
• Provenance Chain — Source commit hash, build date, agent identity, model version
• This is not yet mandated by CRA, but will be required by NIST and increasingly by enterprise buyers

Vulnerability Response Timelines

The CRA's hard reporting clock is set by Article 14. The trigger is active exploitation (a vulnerability being exploited in the wild against your product) or a severe incident affecting the security of the product — not "critical CVSS score in your dependency graph." Routine high-severity dependency CVEs are still subject to the manufacturer's vulnerability handling obligations under Annex I, Part II, but the 24/72-hour clock does not start until exploitation or a severe incident is observed.

Actively-exploited vulnerabilities (Article 14)

Once you become aware that a vulnerability in your product is being actively exploited:

1. Within 24 hours: Submit an early-warning notification to the relevant CSIRT (designated as coordinator) and to ENISA.
2. Within 72 hours: Submit a vulnerability notification with general information about the affected product, the nature of the exploited vulnerability, and any corrective or mitigating measures users can apply.
3. Within 14 days of a corrective measure being available: submit a final report (description, severity, impact, root cause, mitigation, and information enabling identification of the manufacturer).

You do not need to ship a fix in 24 hours. You must notify the regulator on the regulator's clock.

Severe incidents (Article 14)

For severe incidents impacting the security of a product:

1. Within 24 hours: Early warning notification.
2. Within 72 hours: Incident notification.
3. Within one month: Final report.

Routine vulnerability handling (Annex I, Part II)

Outside Article 14 triggers, manufacturers must still handle vulnerabilities throughout the support period — address vulnerabilities without delay, share information with users, and provide security updates separately from feature updates wherever feasible.

SBOM Updates Required

Every time you release a patched version:

• Update the version number
• Update the SBOM to reflect dependency changes
• Publish both together
• Sign the SBOM cryptographically (best practice, not yet mandated)

Penalties for Non-Compliance

Failing to comply carries steep fines. Article 64 of the CRA sets three tiers (whichever is higher between the cash sum and the percentage of total worldwide annual turnover for the preceding financial year applies):

Article 64(2)(a) — most severe (essential cybersecurity requirements + Articles 13 and 14):

• Up to €15 million or up to 2.5% of global annual turnover

Article 64(2)(b) — other obligations under the regulation:

• Up to €10 million or up to 2% of global annual turnover

Article 64(2)(c) — supplying incorrect, incomplete or misleading information to authorities:

• Up to €5 million or up to 1% of global annual turnover

The CRA does not include a €30M / 5% tier. (That figure is sometimes confused with GDPR or the Digital Services Act, which have different ceilings.)

The Article 64 fines become enforceable at full application on 11 December 2027. Article 14 reporting obligations apply from 11 September 2026, so reporting failures are the first thing that can attract a penalty under the regulation.

Practical Compliance Path

Phase 1: Inventory (Now — by July 2026)

• Audit all products with "digital elements" sold to EU customers
• For each product:
  • Document supplier, version, release date
  • Generate SBOM using Syft, Trivy, or cdxgen
  • Validate SBOM completeness against CRA Annex B
  • For AI-coded components: tag AI attribution metadata

Tools:

• syft (Anchore) for container images
• cdxgen (AppThreat) for polyglot projects
• trivy (Aqua) for scanning + SBOM output
• Chalk (Crash Override) for build-time SBOM integration with AI metadata

Phase 2: Publishing (July 2026 — 11 September 2026)

• Create a publicly accessible SBOM repository for each product version
• Make SBOMs available in machine-readable format alongside release notes
• Document your vulnerability response process
• Set up email/contact mechanisms for receiving vulnerability reports

Best practice:

https://yourcompany.com/.well-known/sbom/
  ├── product-name-v1.0.0.cdx.json
  ├── product-name-v1.0.1.cdx.json
  └── product-name-v2.0.0.cdx.json

Phase 3: Response Readiness (from 11 September 2026 onward)

• 24-hour on-call team for critical vulnerability reports
• Pre-template vulnerability response statements
• Integration with Slack/PagerDuty for alert escalation
• SLA tracking: did we respond in 24/72 hours?

Phase 4: Continuous Compliance (Ongoing)

• Rebuild and republish SBOM on every release
• Tag SBOM with cryptographic signature (Sigstore recommended)
• Update SBOM when vulnerability is discovered in a dependency
• Retain technical documentation (which includes the SBOM) per Article 31 for 10 years from when the product is placed on the market or for the support period, whichever is longer

AI-Coded Software and CRA Compliance

The CRA doesn't explicitly mention AI agents, but the compliance requirement for "provenance data" for every vulnerability fix implicitly requires knowing whether the fix was human-authored or agent-generated.

Here's why: if a vulnerability is discovered and you must respond in 24 hours, and your response is "we released a patch with an AI-generated fix," regulators will ask:

• "Who reviewed the AI-generated patch?"
• "What is your evidence that it fixes the vulnerability without introducing new ones?"
• "Who takes liability if the fix is wrong?"

The regulatory white space: EU has no specific guidance yet on AI-generated code provenance. This is Crash Override's wedge. Organizations using autonomous agents to generate code patches need:

1. AI provenance logging — Record model version, prompt, date, reviewer
2. AI attribution in SBOM — Tag each component with its authorship source
3. Review evidence — Document human review of AI-generated patches before they ship

See our article on NIST SSDF with AI Agents for the technical implementation.

Key Takeaways

• 11 September 2026 is when Article 14 reporting obligations apply — the first hard deadline. 11 December 2027 is full application.
• €15M or 2.5% turnover under Article 64(2)(a) is the top fine tier (essential requirements + Articles 13 and 14). Lower tiers: €10M / 2% (other obligations) and €5M / 1% (incorrect or misleading info to authorities).
• CycloneDX or SPDX both qualify as "commonly used and machine-readable" SBOM formats; the regulatory floor is top-level dependencies (Annex I, Part II, point (1)).
• 24h / 72h / 14-day reporting clocks apply to actively-exploited vulnerabilities and severe incidents under Article 14 — not to every high-CVSS dependency CVE.
• AI-coded software is not yet specifically called out by the CRA, but the Article 14 reporting clock and the Annex I vulnerability-handling obligations both depend on knowing who or what authored a given patch.

Start the SBOM inventory phase now. Most organizations will need 4-6 months to audit all products, generate accurate SBOMs, and integrate SBOM generation into their build pipelines.

References

• EU Cyber Resilience Act — Regulation (EU) 2024/2847 (EUR-Lex official text) — Complete regulation
• European Commission CRA summary — Plain-language summary with timeline
• European Commission CRA reporting page — Article 14 reporting guidance
• CISA 2025 SBOM Minimum Elements (Draft for Comment, comment period closed Oct 2025) — Useful baseline; not CRA-mandated
• CycloneDX Specification — One of two commonly-used SBOM formats
• SPDX Specification — The other