The latest build does not represent the supported portfolio
A vendor generates an SBOM for every release, but clients do not all install the latest version. One older branch remains supported, another awaits migration and a third is in development. When a vulnerability is published, the latest build’s dependencies cannot answer for the whole portfolio. Each version’s inventory and maintenance conditions must be retrievable.
Tracking must distinguish fixing the code, releasing a fixed version and deploying it at the client. Each stage has an owner and evidence. Product, support and security teams can then answer from the same case file rather than independently reconstructing their analyses.
Check the vendor’s role and the product’s scope
The Cyber Resilience Act concerns products with digital elements made available on the Union market, subject to its criteria and exclusions. Assessment focuses on the product and the vendor’s role. For SaaS, examine distributed software and any product-related remote data processing solutions. Open-source software is subject to specific provisions depending on the actors’ activity and role.
As of 30 October 2026, manufacturers’ reporting obligations have applied since 11 September 2026. The CRA’s main application date is 11 December 2027, when reporting obligations for open-source software stewards will also apply. A manufacturer in scope must therefore already organise applicable reporting for its products while preparing for the remaining requirements.
Sources: European Commission: CRA scope and essential requirements, European Commission: Cyber Resilience Act and application timetable, European Commission: CRA reporting and open-source software steward timetable
Connect inventory, applicability and decisions
Annex I, Part II, of the CRA connects component knowledge with vulnerability handling. Assess an alert against the exact version, origin, used functions and conditions described by the vendor. A name match is insufficient. Assign missing information to an owner and keep the assessment open.
Retain the product, released version, artefact, inventory date and source, then connect them to the assessment and decision. Creating an SBOM and sharing it are separate matters: the CRA does not require full public publication in every case. Information to communicate depends on the recipient and applicable provisions.
Sources: CRA, Regulation (EU) 2024/2847, Articles 2, 13, 69, 71 and Annex I
Fictional case: two branches, two remediation paths
In this fictional example, Atelier Suite maintains versions 2.8 and 3.4 of its product. The first includes moteur-rendu 1.6; the second uses moteur-rendu 2.2. Finding DEMO-EDITEUR-01 affects a function in both branches, but the supplier offers two different fixes. Version 4.0, still in development, does not resolve tracking for distributed versions.
The team shares the affected-function analysis but retains one action per branch. For 2.8, the fix needs adaptation and validation in the maintenance environment. For 3.4, a standard update is prepared. Support identifies affected clients. Fixed releases and deployment confirmations are tracked separately.
| Level | Information to maintain |
|---|---|
| Product and version | Branch, maintenance status and verified support date |
| Component | Version, origin, inventory and affected function |
| Assessment | Applicability, sources, unknowns and reassessment |
| Treatment | Action per branch, validation, distribution and evidence |
Organise maintenance to avoid reconstructing answers
List marketed and maintained versions, then associate an inventory with each. Take a recent finding: can you explain which versions are affected, which still need investigation and which are fixed? Define events that reopen analysis: a new advisory, dependency change, support extension or deployment change.
CyberLifeCycle manages product- and version-specific tracking: component monitoring, assessment, priorities and treatment case files. Receive the alerts and reports needed for maintenance decisions. Measure reassessment time, customer-response preparation and requests blocked by missing information. The manufacturer retains responsibility for secure development, testing, updates, notifications and conformity assessment.
Sources: European Commission: manufacturer obligations before and after market placement
Sources consulted
- CRA, Regulation (EU) 2024/2847, Articles 2, 13, 69, 71 and Annex IAccessed on 30 October 2026.
- European Commission: Cyber Resilience Act and application timetableAccessed on 30 October 2026.
- European Commission: manufacturer obligations before and after market placementAccessed on 30 October 2026.
- European Commission: CRA reporting and open-source software steward timetableAccessed on 30 October 2026.
- European Commission: CRA scope and essential requirementsAccessed on 30 October 2026.