EU CRA: Code Traceability and Vulnerability Management as Law
EU Cyber Resilience Act: Software security is now a legal requirement for products bearing the CE mark
Regulation (EU) 2024/2847 makes cybersecurity a marketability requirement for any product with digital components in the EU. Code traceability, vulnerability management, and verifiable SBOMs are no longer just best practices—they are now legal obligations.
Key Points
- The EU CRA (Regulation (EU) 2024/2847), published on October 23, 2024, establishes mandatory cybersecurity requirements for all products with digital components sold in the EU.
- The requirements for reporting actively exploited vulnerabilities (Art. 14) take effect on September 11, 2026—the first critical date for software manufacturers.
- The full implementation of the regulation, including the cybersecurity CE marking, takes effect on December 11, 2027.
- Article 13 requires manufacturers to document and demonstrate their Secure Development Lifecycle (SDL)—from design through the end of the product's useful life.
- Article 16 establishes the Software Bill of Materials (SBOM) as a requirement: a verifiable list of all software components in the product.
- V-PROOF Integration generates the cryptographic chain of custody for the code, commit by commit—the technical foundation for complying with Articles 13, 14, and 16 simultaneously.
EU CRA: When "Secure by Design" Is No Longer Just a Slogan but Becomes Law
For decades, the software industry has operated under an unspoken principle: cybersecurity is an optional feature that is added only if the market demands it. The EU Cyber Resilience Act puts an end to that model. As of December 2027, no product containing digital elements may be marketed in the EU without demonstrating that it meets the security requirements set forth in Annex I of the regulation.
Published on October 23, 2024, in the Official Journal of the EU, Regulation (EU) 2024/2847 applies to any hardware or software product that includes “digital elements”—a deliberately broad definition that ranges from industrial IoT devices to mobile applications, and from access control systems to business management software. The only products explicitly excluded are those already covered by specific sector-based regulations (medical devices, vehicles, aviation) and pure software-as-a-service (SaaS) offerings that do not involve downloading any components to the user’s device.
The Paradigm Shift at the EU CRA
The EU CRA shifts the responsibility for cybersecurity from the end user to the manufacturer. Until now, when software had vulnerabilities, the user “accepted the risk” by installing the product. Under the CRA, the manufacturer is responsible for the product’s security throughout its entire lifecycle, including managing post-release vulnerabilities for at least five years or for the intended period of use, whichever is longer.
The penalties for noncompliance are significant: up to 15 million euros or 2.5% of global annual revenue for failure to comply with the essential cybersecurity requirements in Annex I, and up to 10 million euros or 2% for failure to comply with other obligations, such as vulnerability reporting. National market surveillance authorities are responsible for oversight in each Member State.
Three categories, three levels of difficulty
The EU CRA classifies products into three categories based on their level of cybersecurity risk. The category determines the conformity assessment procedure required to obtain the CE marking:
Dates that product teams should include in their roadmap
Why start now and not in 2027?
The EU CRA requires manufacturers to demonstrate a Secure Development Lifecycle—a secure development process—rather than simply ensuring that the final product meets specific requirements. A process has a track record. Compliance audits will look back: a manufacturer that begins cryptographically sealing its development process in 2024–2026 will have two or three years of verifiable history by the time the assessment takes place. One that starts in December 2027 will have zero demonstrable history.
Articles that require technical evidence—and what V-PROOF generates V-PROOF each one
V-PROOF Coverage Required V-PROOF EU CRA
| EU CRA Obligation | Requirement | Coverage | V-PROOF Module |
|---|---|---|---|
| Art. 13 — Secure Development Lifecycle | |||
| Art. 13(1) of theSDL, as documented | Verifiable track record of the secure development process from design through deployment | ✓ Complete | Git Integration |
| Art. 13(3)Patch Management | Traceability of Security Patch Deployment: When, Which Version, Who Authorized It | ✓ Complete | Git Integration |
| Art. 13(6)Technical Documentation | Up-to-date and verifiable technical documentation for conformity assessment | ✓ Complete | V-Seal Git Integration |
| Art. 14 — Reporting of Vulnerabilities and Incidents | |||
| Art. 14(1)24h — ENISA Alert | timestamp record timestamp the exact moment the exploited vulnerability was discovered | ✓ Complete | V-Seal |
| Art. 14(2)72h — Notice | Record of the actions taken from the discovery through formal notification | ✓ Complete | V-Seal |
| Art. 14(7)Notification to ENISA | The manufacturer is responsible for formally notifying ENISA | — Manufacturer's Liability | Regulatory Process |
| Art. 16 — Software Bill of Materials (SBOM) | |||
| Art.16 Verifiable SBOM | A complete and verifiable list of software components, including third-party and open-source dependencies | ✓ Complete | Git Integration |
| Annex I — Essential Cybersecurity Requirements | |||
| Annex I — PartI: Product Requirements | Evidence of the implementation of each safety control required in the product design | ✓ Complete | V-Seal |
| Appendix I — PartII: Vulnerability Management | A verifiable process for identifying, analyzing, and resolving vulnerabilities throughout the lifecycle | ✓ Complete | Git Integration V-Seal |
| Convergence of the EU CRA and EU AI Act For software with AI components | |||
| EU CRA Art. 13 + EU AI Act . 12 | Lifecycle Traceability of AI Models Embedded in Software Products: Versions, Training, Deployment | ✓ Complete | AI Orchestrator Git Integration |
EU CRA + EU AI Act: The Dual Obligation for Software with Integrated AI
Any software product that incorporates AI components is subject to both the EU CRA and the EU AI Act. And this overlap creates additional obligations that neither framework addresses on its own.
An ML-based anomaly detection system integrated into cybersecurity software, an AI-powered code assistant, and a security recommendation system on a SaaS platform—all of these are AI systems under the EU AI Act products with digital components under the EU CRA. The manufacturer must comply with the software lifecycle traceability requirements (EU CRA Art. 13) and the requirements for event logging and human oversight of the AI system (EU AI Act . 12 and 14) for the same product.
V-PROOF the intersection with a single integration
V-PROOF AI Orchestrator module cryptographically V-PROOF the entire lifecycle of the AI models integrated into the product: training datasets, model versions, evaluation metrics, and every decision made in production. The Git Integration module logs the code that implements them. Together, they meet the traceability requirements of the EU CRA (Art. 13) and the EU AI Act Arts. 12, 16) without duplicating the integration.
The EU CRA and Software Supply Chain Security
The EU CRA introduces a concept that changes the way development teams must think about their dependencies: software supply chain responsibility. Manufacturers are responsible for vulnerabilities in third-party components they integrate into their products—including open-source libraries.
This responsibility extends to the providers of development tools that the manufacturer uses in its SDL process. A manufacturer that uses a U.S.-based CI/CD or code management platform to manage its secure development process introduces a component subject to the CLOUD Act into its supply chain. If U.S. authorities require access to the product’s development history—including records of discovered vulnerabilities and their resolution timelines—that provider cannot guarantee confidentiality.
V-PROOF Integration provides code traceability with its legal headquarters in Spain. The SDL records are sovereign: the cryptographic chain of custody for the development process remains under EU jurisdiction.
V-PROOF the EU CRA
Strengths, Regulatory Use Cases, and Scope Limitations
- Cryptographic chain of custody from commit to commit—the documented and verifiable SDL required by Art. 13, built during normal development Article 13 — Verifiable SDL
- Timestamp of the exact time each vulnerability was discovered — essential for demonstrating compliance with the 24-hour deadline set forth in Art. 14 Article 14 — Vulnerability Notification
- Commit-to-commit traceability of dependencies and third-party components — the technical foundation for generating and verifying the SBOM required by Article 16 Article 16 — SBOM
- Verifiable record of the implementation of the controls in Annex I — evidence for the technical documentation supporting conformity assessment and CE marking Annex I — Essential Requirements
- Dual coverage EU AI Act the EU CRA and EU AI Act software with integrated AI components — a single integration for two regulatory frameworks Regulatory Convergence 2026–2027
- Supplier with its registered office in Spain: the SDL process registered with V-PROOF is V-PROOF subject to the U.S. CLOUD Act Supply Chain Sovereignty
- ISVs (Independent Software Vendors) that market software in the EU and need to document their SDL by December 2027 Art. 13 — Software manufacturers
- Manufacturers of industrial and consumer IoT devices with embedded software—especially Class I and II devices, which have more stringent evaluation requirements Class I–II — Critical products
- DevSecOps teams that need to cryptographically seal their CI/CD pipeline as evidence of a secure development process Art. 13 — CI/CD Pipeline
- CISOs preparing technical documentation for Class I and II conformity assessments as far in advance as possible Articles 24–32 — Conformity Assessment
- Software manufacturers with built-in AI that are subject to both the EU CRA and EU AI Act are seeking a single traceability infrastructure Convergence of the EU CRA and EU AI Act
- The design of the product's security architecture: V-PROOF that the implementation process was carried out correctly; it does not design the security architecture. Product Design
- Penetration testing and security testing (Appendix I): V-PROOF the test results; it does not perform the tests. The tests are conducted by the security team or a specialized third party. Appendix I — Security Testing
- Formal reporting of vulnerabilities to ENISA (Art. 14): V-PROOF an immutable record of the discovery; formal reporting to the regulator is the manufacturer’s responsibility. Art. 14 — ENISA Notification
- The CE marking (Art. 47): requires conformity assessment by a notified body for Classes I and II. V-PROOF the technical evidence that facilitates this assessment; it does not grant the marking. Art. 47 — CE Marking
Does your development team have the documented SDL that CRA compliance assessors will require?
V-PROOF a 48-hour strategic assessment that maps the EU CRA requirements applicable to your products, identifies existing code traceability gaps, and defines the necessary Git integration.
Request an EU CRA Strategic AssessmentSources and Regulatory References
- Regulation (EU) 2024/2847 of the European Parliament and of the Council of October 23, 2024 — EUR-Lex CELEX:32024R2847
- ENISA — EU CRA Implementation Guidance, 2025 — enisa.europa.eu
- European Commission — Frequently Asked Questions About the EU CRA — digital-strategy.ec.europa.eu
- CEN/CENELEC — Standardization Mandate for the EU CRA (Harmonized Technical Standards) — cencenelec.eu
- BSI (Federal Office for Information Security) — EU CRA Orientation Guide for Manufacturers, 2025 — bsi.bund.de
- Regulation (EU) 2024/1689 (EU AI Act) — Convergence Reference with the EU CRA for AI Software — EUR-Lex
