A vulnerability should not exist only as a generic ticket against a product name. Version-specific records are needed to determine who is exposed, which branches remain supported, whether a dependency is present, which update corrects the issue and when remediation can be considered complete.
Systematically Document Vulnerabilities
Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects concerning products with digital elements, including vulnerabilities of which they become aware and relevant information provided by third parties. Version tracking gives that requirement operational structure by connecting each vulnerability to the actual product releases and branches in which the vulnerable condition exists.
- Create a vulnerability record.
- Identify product versions.
- Preserve third-party information.
- Update the record as investigation develops.
Track Product Versions and Component Versions Separately
A product version and a third-party component version are not the same thing. One product release can contain hundreds of component versions, and the same component version can appear across several product branches. The vulnerability record should therefore preserve both levels of information so a component advisory can be mapped accurately to the manufacturer's own affected versions.
- Product release or build.
- Component name.
- Component version.
- Product-to-component mapping.
Use the Software Bill of Materials for Component Mapping
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components, including through a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies. SBOM data can accelerate affected-version analysis by showing which product builds contain a vulnerable dependency and which releases have already moved to a corrected component.
- Map components to builds.
- Track dependency versions.
- Identify vulnerable component presence.
- Confirm corrected component versions.
Create an Affected-Version Matrix
An affected-version matrix can show every relevant product branch together with vulnerability status. Useful states can include affected, not affected, under investigation, fixed, mitigated and unsupported. The CRA does not prescribe these exact labels, but a consistent matrix reduces ambiguity when engineering, support and customer communications need to agree on which versions require action.
- Affected.
- Not affected.
- Under investigation.
- Fixed.
- Mitigated.
- Unsupported.
Record Why a Version Is Not Affected
A not-affected conclusion should have a technical basis. The vulnerable component may be absent, the vulnerable function may not be compiled, the affected code path may have been removed or the relevant feature may have been redesigned. Recording the reason helps prevent the same branch from being repeatedly reinvestigated and makes later customer communication more reliable.
- Component absent.
- Code path absent.
- Feature redesigned.
- Configuration prevents the vulnerable condition.
Track Support Status Alongside Vulnerability Status
Article 13(8) requires vulnerabilities to be handled effectively during the support period. Version tracking should therefore include support status and the applicable support end date. An affected supported version requires a remediation decision, while an unsupported historical version can require different communication or archive treatment. Support status should not be inferred merely from how old a version appears.
- Supported.
- Support end date.
- Unsupported.
- Historical archive status where relevant.
Identify the First Fixed Version
The vulnerability record should identify the first fixed version for each relevant branch. This lets support teams and users distinguish a vulnerable release from a corrected release and supports accurate security advisories. Where the same vulnerability is backported into several branches, each branch can have a different first fixed version.
- First fixed version.
- Branch-specific fixed version.
- Security-update identifier.
- Release date.
Track Substantially Modified Versions Carefully
Where subsequent substantially modified versions of a software product exist, Article 13(10) can affect how Annex I Part II point 2 remediation is handled if its conditions are met. Version tracking should therefore distinguish an ordinary maintenance release from a substantially modified version rather than treating every release number change as legally equivalent.
- Identify substantial modifications.
- Identify ordinary maintenance releases.
- Record upgrade eligibility.
- Preserve the Article 13(10) analysis where relevant.
Track Mitigation Separately From Fixed Status
A version protected by a temporary mitigation is not necessarily fixed. The vulnerable code may remain present even though exposure has been reduced through configuration, network controls or disabled functionality. Tracking mitigated and fixed as separate states prevents temporary risk reduction from being mistaken for permanent remediation.
- Mitigation applied.
- Permanent fix pending.
- Residual risk.
- Fixed version.
Track Security-Update Rollout Status
A fixed build existing internally is different from a security update that has been made available to customers. Version tracking should distinguish fix development, verification, release and rollout status. This becomes particularly important because Annex I Part II point 8 requires available security updates addressing identified security issues to be disseminated without delay.
- Fix developed.
- Fix verified.
- Update released.
- Update available to users.
- Rollout completed where measurable.
Keep Version Data Consistent With Customer Advisories
Security advisories should draw affected versions and fixed versions from the same controlled record used by engineering and product security. Maintaining separate manually edited lists can create contradictions where one source says a version is fixed while another says it remains affected. Version tracking should therefore act as a common factual source for remediation, release and communication decisions.
- Use one controlled version record.
- Synchronise engineering and advisory data.
- Review corrections before publication.
- Record significant status changes.
Preserve Version-Specific Evidence
The case record should preserve affected versions, unaffected-version rationale, component versions, support status, fixed versions, mitigation status, update identifiers and release dates. This evidence supports technical documentation and makes later review possible when the same vulnerability class or dependency appears in another product version.
- Affected-version matrix.
- Component mapping.
- Support status.
- Fixed versions.
- Update identifiers.
- Release dates.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.