Cyber Resilience Act Compliance Readiness
The EU Cyber Resilience Act mandates SBOM documentation, vulnerability handling processes, and security update mechanisms for all products with digital elements. Cyvance is already building the operational infrastructure – not just checking compliance boxes.
Article 14 Reporting Obligations
Full CRA Application
CRA Requirements Mapped
CRA Enforcement Timeline
The Cyber Resilience Act (Regulation 2024/2847) entered into force on 10 December 2024 with a phased enforcement schedule. Reporting obligations under Article 14 apply from 11 September 2026.
10 Dec 2024
CRA Entered
Into Force
11 Jun 2026
Conformity Assessment
Bodies (Ch. IV)
11 Sep 2026
Article 14 Reporting
Obligations Apply
11 Dec 2027
Full CRA
Application
SBOM & Vulnerability Handling
Annex I, Part II – Vulnerability Handling Requirements
CRA Annex I Part II 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." This is the cornerstone requirement – and it's where Cyvance's operational SBOM pipeline delivers the most value.
| CRA Reference | Obligation | Cyvance Capability | Status |
|---|---|---|---|
| Part II(1) | Draw up an SBOM in a commonly used and machine-readable format covering at least top-level dependencies | CycloneDX 1.5 JSON generation from deployed environments. Enumerates 8 component types (application, library, framework, OS, device, firmware, container, file) across 4 package managers (dpkg, rpm, pacman, Windows registry). Includes PURL identifiers, full dependency graph, supplier metadata, and license capture. Cryptographically signed with Ed25519. | Built |
| Part II(2) | Address and remediate vulnerabilities without delay, including by providing security updates | TRX threat scoring engine classifies every finding into 4 tiers (ATTACKED, FUNCTIONAL, POC, UNPROVEN) using curated exploit-intelligence sources spanning confirmed exploitation, weaponization, exploitation probability, and vendor advisories. Predictive exploitation-probability signals identify CVEs likely to be weaponized before they reach public exploited-vulnerability catalogs. Priority formula is deterministic and auditable – no black-box AI. | Built |
| Part II(3) | Apply effective and regular tests and reviews of the security of the product | Continuous agent snapshots with configurable collection intervals. SBOM staleness monitoring detects components that haven't been updated beyond configurable thresholds. SBOM diff engine tracks component-level changes between snapshots – additions, removals, and version changes. | Built |
| Part II(4) | Once a security update is available, publicly disclose information about fixed vulnerabilities including severity and impact | VEX (Vulnerability Exploitability eXchange) processing with 4 statuses: Exploitable, Not Affected, Fixed, Under Investigation. VEX statements include justification tracking, impact assessment, and action statements. Supports CycloneDX VEX and CSAF VEX formats. | Built |
| Part II(5) | Put in place and enforce a policy on coordinated vulnerability disclosure | Setting and enforcing the coordinated-disclosure policy is the manufacturer's duty; Cyvance provides the structured exchange layer beneath it. VEX-format support enables vulnerability communication between manufacturers, operators, and downstream consumers, with status-lifecycle tracking as the disclosure audit trail. | Built |
| Part II(6) | Facilitate sharing of information about potential vulnerabilities, including a contact address for reporting | Publishing the reporting contact address is the manufacturer's action; Cyvance supplies the information that makes disclosure meaningful. A 304,000+ enriched CVE corpus with exploit intelligence from 7 sources, mapped per component via the SBOM correlation chain (PURL → CPE → NVD, distro advisory, MSRC), so shared vulnerability information is accurate and component-specific. | Built |
| Part II(7) | Provide mechanisms to securely distribute updates so that exploitable vulnerabilities are fixed in a timely manner | Cyvance supplies the integrity layer for update evidence, not the update channel itself. Ed25519 signing of every agent snapshot and SBOM, TOFU (Trust-On-First-Use) enrollment with device ID derived from public-key fingerprint, and a tamper-evident snapshot envelope with hash verification – so the record of what is deployed and patched is cryptographically verifiable and cannot be forged. | Built |
| Part II(8) | Security patches disseminated without delay and free of charge, with advisory messages | Disseminating the patches is the manufacturer's action; Cyvance provides the layer that tells them which patches matter and when. Multi-platform package-manager tracking (dpkg, rpm, pacman, Windows registry) detects installed versions, CVE correlation identifies which are affected, and TRX scoring prioritizes patching urgency on real exploit signals, not just CVSS. | Built |
Manufacturer Obligations
Article 13 – Obligations of Manufacturers
Article 13 establishes the core obligations for manufacturers of products with digital elements – from cybersecurity risk assessments to component due diligence and systematic vulnerability documentation. Cyvance provides the operational data layer that makes these obligations continuously verifiable rather than periodic checkbox exercises.
| CRA Reference | Obligation | Cyvance Capability | Status |
|---|---|---|---|
| Art 13(2–3) | Undertake cybersecurity risk assessments, documented and updated during the support period | Continuous risk assessment via TRX scoring with full audit trail. SBOM diff engine tracks component-level changes over time. Finding history maintains deterministic scoring data with timestamped state transitions – risk documentation that updates itself. | Built |
| Art 13(5) | Exercise due diligence when integrating third-party components, including open-source | SBOM component-to-CVE correlation chain: PURL → CPE → NVD matching, Debian/Ubuntu distro advisory matching, MSRC Patch Tuesday matching. Every third-party dependency is automatically evaluated against 304,000+ enriched CVEs. | Built |
| Art 13(6) | Report vulnerabilities in integrated components to the component manufacturer | VEX processing tracks vulnerability-to-component mapping with status lifecycle. Component supplier metadata captured in SBOM enables traceability to upstream manufacturers. | Built |
| Art 13(7) | Systematically document vulnerabilities, including information from third parties | Complete NVD CVE coverage, enriched with curated exploit-intelligence sources spanning confirmed exploitation, weaponization, exploitation probability, and vendor advisories (Debian, Ubuntu, MSRC). Finding model with deterministic TRX scoring provides the audit-grade documentation regulators require. | Built |
| Art 13(8) | Handle vulnerabilities effectively per Annex I Part II during the entire support period | Full vulnerability lifecycle: discover → prioritize → validate → remediate. TRX-weighted urgency ensures the most dangerous exposures surface first. Continuous monitoring with heartbeat model keeps vulnerability data current – not stale quarterly scans. | Built |
| Art 13(24) | Commission may specify SBOM format via implementing acts | CycloneDX 1.5 – the leading machine-readable SBOM format endorsed by OWASP and widely adopted across industry. Cyvance is aligned with the expected standard before implementing acts are published. SPDX support is on the roadmap should the Commission specify multiple formats. | Ready |
| Art 13(25) | ADCO may conduct Union-wide dependency assessments; manufacturers may be asked to provide SBOMs | CycloneDX export service with full dependency graph reconstruction. SBOMs are export-ready in the machine-readable format regulators expect – no manual compilation needed. | Built |
Reporting Obligations
Article 14 – Applies from 11 September 2026
Article 14 is the first CRA obligation to become enforceable, from 11 September 2026. It requires manufacturers to notify CSIRTs and ENISA of actively exploited vulnerabilities within 24 hours (early warning) and 72 hours (full notification). Cyvance provides the detection and data infrastructure that makes these reporting timelines achievable.
| CRA Reference | Obligation | Cyvance Capability | Status |
|---|---|---|---|
| Art 14(1) | Notify any actively exploited vulnerability to CSIRT and ENISA simultaneously | Real-time exploit detection via curated exploit-intelligence sources spanning confirmed in-the-wild exploitation, weaponized tooling, public proof-of-concept releases, and exploitation-probability scoring. TRX engine auto-classifies ATTACKED-tier vulnerabilities the moment signals appear – providing the detection layer that feeds notification workflows. | Detection Built |
| Art 14(2)(a) | Early warning notification within 24 hours of becoming aware | Continuous monitoring agent with configurable heartbeat intervals. Exploit-intelligence sources refreshed on automated daily schedules – exploitation-probability signals, in-the-wild exploitation catalogs, and exploit-tooling imports. TRX classification runs on every snapshot ingestion, surfacing newly exploited CVEs within hours, not days. | Detection Built |
| Art 14(2)(b) | Vulnerability notification within 72 hours including general information, nature of exploit, corrective measures | Pre-built CVE detail data: CVSS severity, impact vectors, exploit availability (weaponized tooling, public PoC), corrective measures from advisories, exploitation-probability scores. TRX audit log provides timestamped signal history. All data is structured, machine-readable, and ready for CSIRT reporting formats. | Data Built |
| Art 14(2)(c) | Final report within 14 days after corrective measure is available, including description, severity, details of corrective measures | Full vulnerability lifecycle data: discovery timestamp, TRX classification history via audit log, VEX status transitions (Exploitable → Fixed), severity scores, and corrective measure tracking. Provides the structured data needed to compile final reports. | Data Built |
| Art 14(8) | Inform impacted users of vulnerabilities and risk mitigation measures, where appropriate in machine-readable format | VEX ingestion and processing in CycloneDX VEX and CSAF formats – statements are parsed, correlated to findings, and applied to prioritization, including justification, action statements, and impact descriptions. VEX export is in development. | Built |
| Art 14(7) | Submit notifications via the single reporting platform (ENISA) using electronic notification end-points | Cyvance provides the detection and data preparation layer. The actual notification submission to ENISA's single reporting platform will require integration once ENISA publishes the electronic notification end-point specifications (expected before September 2026). | Pending ENISA |
Security Property Requirements
Annex I, Part I – Essential Cybersecurity Requirements
Annex I Part I establishes the security properties that products with digital elements must exhibit. Cyvance's agent collects the telemetry needed to continuously verify these properties across deployed infrastructure – turning point-in-time compliance checks into continuous assurance.
Part I, 2(a)
No Known Exploitable Vulnerabilities
Products shall be made available on the market without known exploitable vulnerabilities.
Cyvance Coverage
CVE correlation engine matches every component against 304,000+ enriched CVEs via PURL → CPE → NVD, distro-advisory, and MSRC chains. TRX scoring flags known exploitable exposures (ATTACKED / FUNCTIONAL tiers) from real exploit intelligence – continuous evidence that deployed products carry no known exploitable vulnerabilities.
Part I, 2(b)
Secure by Default Configuration
Products shall be delivered with a secure by default configuration, including the possibility to reset to original state.
Cyvance Coverage
Configuration audit collector: SSH hardening assessment, sysctl security settings, sudoers analysis, SUID binary detection. Identifies deviations from secure defaults.
Part I, 2(c)
Security Update Mechanism
Ensure vulnerabilities can be addressed through security updates, including automatic updates and notification of available updates.
Cyvance Coverage
Multi-platform package manager tracking: dpkg, rpm, pacman, Windows registry. Detects installed versions, correlates with CVEs, and prioritizes patching urgency via TRX scoring.
Part I, 2(d)
Access Control & Authentication
Ensure protection from unauthorized access by appropriate control mechanisms.
Cyvance Coverage
Access collector: user enumeration, group membership, authorized_keys analysis, privilege escalation detection. Maps who has access to what across every monitored host.
Part I, 2(e)
Data Confidentiality
Protect confidentiality of stored, transmitted or processed data by encrypting relevant data at rest or in transit.
Cyvance Coverage
Network exposure collector: TLS version detection, protocol analysis, encryption posture assessment per listening service. Identifies services that should be encrypted but aren't.
Part I, 2(j)
Attack Surface Minimization
Products shall be designed, developed and produced to limit attack surfaces, including external interfaces.
Cyvance Coverage
Network exposure mapping: listening ports, service fingerprinting, network topology discovery. Identifies unnecessary exposed services that expand the attack surface.
Part I, 2(l)
Security-Related Monitoring
Provide security related information by recording and monitoring relevant internal activity.
Cyvance Coverage
11 parallel telemetry collectors: host info, packages, processes, network exposure, containers, services, config audit, access, process context, network topology, SBOM. Continuous snapshots with cryptographic signing.
Coverage Summary
Cyvance maps operational capabilities to CRA obligations – not theoretical coverage, but production-deployed features verified against the final regulation text (2024/2847).
Annex I Part II
8/8SBOM & Vulnerability Handling
Full coverage. CycloneDX 1.5 SBOM generation, VEX processing, cryptographic signing, multi-source vulnerability correlation, and continuous monitoring.
Article 13
7/7Manufacturer Obligations
Key obligations covered. Risk assessment, third-party due diligence, systematic documentation, vulnerability lifecycle management, and SBOM export readiness.
Article 14
5/6Reporting Obligations
Detection and data layers complete. ENISA single reporting platform integration pending – notification end-point specs expected before September 2026.
Annex I Part I
7/13Security Properties
Core security properties instrumented: known-exploitable-vulnerability detection, config audit, access control, encryption posture, attack surface, monitoring, and update tracking. The remaining properties – data integrity, data minimisation, availability under attack, and secure data deletion among them – are product-design obligations that live in the manufacturer's own architecture, not in an external assurance layer.
Transparency & Roadmap
Compliance credibility requires honesty about gaps. Here's what we've built, what's pending, and what depends on external specifications.
ENISA Single Reporting Platform Integration
Article 14(7) requires notification submission via ENISA's single reporting platform using electronic notification end-points. ENISA is expected to publish the platform specifications before September 2026. Cyvance provides the complete detection and data preparation layer – integration will follow once the API specifications are available.
Status: Awaiting ENISA platform specifications
SPDX Format Support
Article 13(24) allows the Commission to specify SBOM format requirements via implementing acts. Cyvance currently generates and ingests CycloneDX 1.5 – the leading OWASP-endorsed format. SPDX parser support is on the roadmap to ensure compliance regardless of which format(s) the implementing acts specify.
Status: Roadmap – CycloneDX 1.5 active, SPDX planned
OpenVEX Format Parser
Cyvance processes VEX data in CycloneDX VEX and CSAF formats. OpenVEX – designed by Chainguard and adopted by some container security tools – is on the roadmap. The data model already supports OpenVEX semantics; only the parser implementation is pending.
Status: Roadmap – schema ready, parser planned
CEN/CENELEC Technical Standards
The European standardization bodies (CEN/CENELEC) are developing harmonized standards for CRA conformity assessment. These standards will detail specific technical requirements for security testing, SBOM format, and vulnerability disclosure processes. Cyvance is monitoring these publications and will align immediately upon release.
Status: Awaiting standards publication
Beyond CRA: Regulatory Ecosystem
The CRA doesn't exist in isolation. It intersects with DORA, NIS2, and other frameworks – and Cyvance's capabilities serve multiple regulatory requirements simultaneously.
Also Addresses
DORA
Article 28 third-party ICT risk register requirements. Cyvance's SBOM + CVE correlation pipeline generates the vendor risk evidence DORA auditors expect.
Enforcement: Active (Jan 2025)
Also Addresses
NIS2
Supply chain risk management, vulnerability handling, and incident reporting obligations. 30,000 entities in Germany alone under NIS2UmsuCG transposition.
DE Transposition (NIS2UmsuCG): pending, expected 2026
Also Addresses
US EO 14028
OMB M-23-16 requires secure-development self-attestation from federal software suppliers, with SBOMs requestable by agencies. Cyvance generates compliant SBOMs natively – ready the moment US federal procurement asks.
Active since 2023
Start Your CRA Readiness Assessment
Article 14 reporting obligations apply in September 2026. Cyvance maps your actual infrastructure against CRA requirements today – not a checkbox questionnaire, but operational evidence from deployed environments.
This page maps Cyvance platform capabilities to EU Cyber Resilience Act (Regulation 2024/2847) requirements based on the official final text published 20 November 2024. This is not legal advice. Consult qualified legal counsel for compliance determination specific to your products and obligations.