CRA Vulnerability Documentation and Risk Reassessment

The Cyber Resilience Act (CRA) makes the cybersecurity risk assessment a lifecycle record rather than a one-time design document. Manufacturers must document the assessment and update it as appropriate during the product's support period. They must also systematically document relevant cybersecurity aspects concerning the product, including vulnerabilities of which they become aware and relevant information provided by third parties, and update the risk assessment where necessary.

For engineering teams, the practical question is therefore not simply whether a vulnerability was fixed. It is whether new vulnerability information changes assumptions, threats, affected assets, intended or reasonably foreseeable use, applicable essential cybersecurity requirements, or the evidence supporting the existing risk assessment.

What the CRA requires from the risk assessment

Article 13 requires manufacturers to undertake a cybersecurity risk assessment for a product with digital elements and to take its outcome into account across planning, design, development, production, delivery and maintenance.

Article 13(3) requires that assessment to be documented and updated as appropriate during the support period. At minimum, it must analyse cybersecurity risks based on the product's intended purpose, reasonably foreseeable use and conditions of use, including factors such as the operational environment and assets to be protected. It must also address how the essential cybersecurity requirements in Annex I apply and are implemented on the basis of the assessment.

This creates an important operational distinction: the assessment is not only evidence produced for conformity assessment. It is also a maintained engineering input during the period in which the manufacturer handles product vulnerabilities.

The Commission's July 2026 implementation guidance specifically addresses CRA risk-assessment requirements. The guidance is non-binding, while the legal obligations remain those in Regulation (EU) 2024/2847.

Vulnerability documentation is an input to reassessment

Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects concerning the product, including vulnerabilities of which they become aware and relevant information provided by third parties. Where necessary, the manufacturer must update the product's cybersecurity risk assessment.

That wording creates two related but distinct records:

the vulnerability and cybersecurity information that the manufacturer receives or discovers; and
the assessment decision about whether that information changes the documented cybersecurity risk assessment.

Not every vulnerability needs to cause a wholesale rewrite of the assessment. But a team should be able to show that relevant information entered a controlled process and that the need for reassessment was considered rather than silently assumed away.

A useful workflow therefore treats reassessment as an explicit decision point in vulnerability handling.

What should trigger a reassessment decision?

The CRA does not prescribe a single internal trigger list. Manufacturers can design a process appropriate to the product and risk. From an engineering perspective, however, several events are sensible candidates for mandatory review.

A newly discovered vulnerability in the product

A vulnerability may invalidate an assumption about an interface, privilege boundary, authentication mechanism, parser, dependency or security control. The first question is not only severity; it is whether the weakness reveals that the existing risk model is incomplete or inaccurate.

New information about a third-party component

Relevant information may arrive from a component supplier, open-source project, security researcher, coordinated vulnerability disclosure process or another third party. If the affected component is present in the product, teams should determine whether the information changes exposure, attack paths or mitigation assumptions.

Evidence that a control is less effective than assumed

Testing, field information or vulnerability analysis can show that a control does not reduce risk as expected. Even when a patch is straightforward, the underlying assessment may need revision if it relied on that control.

A change in reasonably foreseeable use or operating conditions

Product deployment can evolve. New integrations, network exposure or operating environments may make an existing vulnerability materially different from the risk originally assessed. Article 13(3) expressly ties the assessment to intended and reasonably foreseeable use and conditions of use.

A recurring vulnerability pattern

Repeated vulnerabilities in the same subsystem can indicate a systemic design or development issue. The individual findings may be handled separately, but the pattern can justify revisiting the broader risk treatment and applicable security requirements.

Record the reassessment decision, including when nothing changes

A defensible lifecycle record should capture more than the final risk score. For each material vulnerability or new cybersecurity input, retain enough context to reconstruct the decision.

A practical reassessment record can contain:

product, variant and release or version scope;
vulnerability identifier or internal reference;
source of the information and awareness date;
affected component, interface or security function;
current exposure and relevant operating assumptions;
existing risk-assessment entry or entries potentially affected;
whether the risk assessment requires an update;
rationale for that decision;
remediation, mitigation or monitoring actions;
evidence reviewed, such as test results, advisory data or supplier information;
decision owner and review date; and
links to the resulting revised assessment where an update was required.

A decision that no assessment change is necessary can still be valuable evidence. It shows that the new information was considered against the existing model. The rationale should be specific enough to be reviewed later; a generic status such as "not applicable" is rarely useful by itself.

Keep product and release scope explicit

Vulnerability evidence becomes difficult to audit when it is detached from the exact product context. A component vulnerability may affect one release but not another, or may be exploitable only when a feature is enabled in a particular variant.

The reassessment process should therefore identify the affected product configuration rather than treating the vulnerability as a global organisation-level fact. Where several supported versions exist, record which versions were evaluated and why the conclusion differs if it does.

This also helps prevent a later risk assessment from accidentally inheriting conclusions that were valid only for an earlier release or operating condition.

Connect the decision to the original risk model

A vulnerability-management ticket and a cybersecurity risk assessment answer different questions. The ticket usually tracks investigation and remediation. The risk assessment explains the product's cybersecurity risks and how the applicable essential requirements are addressed.

When a vulnerability changes the risk picture, the records should be linked. For example, a newly discovered unauthenticated interface might require updates to an attack scenario, affected asset, likelihood or impact reasoning, applicable Annex I requirement, mitigation, verification evidence, or several of these elements.

The important control is traceability: a reviewer should be able to move from the new information to the reassessment decision and, where applicable, to the revised risk record and remediation evidence.

Do not overwrite the history that explains the decision

Risk assessments evolve during the support period. If a current document simply replaces the previous version, teams can lose evidence of what was known and why an earlier decision was reasonable at the time.

Versioned or otherwise auditable records are preferable. They should make it possible to establish:

what the assessment said before the new information arrived;
what information triggered review;
who reviewed it and when;
what changed, if anything; and
which evidence supported the new conclusion.

This is an engineering recommendation rather than a prescribed CRA file format. The regulation sets the obligation to document and update the assessment as appropriate; organisations can choose the tools and record structure that fit their development process.

Integrate reassessment into vulnerability handling

A workable process avoids creating a separate compliance exercise after technical remediation is finished. Instead, add the reassessment decision to the normal vulnerability workflow.

One possible sequence is:

Capture the vulnerability or third-party cybersecurity information and identify the affected product scope.
Triage technical relevance, exposure and potential impact.
Map the finding to existing risk assumptions, threats, assets and security requirements.
Decide whether the cybersecurity risk assessment needs to change.
Update the assessment where necessary and retain the previous state or revision history.
Remediate or mitigate the vulnerability according to the applicable vulnerability-handling process.
Verify the resulting control or fix and attach the supporting evidence.
Close the record only when the technical work and the reassessment decision are both traceable.

This sequence can be implemented in existing issue trackers, product-security systems or governance tooling. The CRA does not require a particular software platform for the record.

Reassessment is broader than vulnerability severity

A severity score can support triage, but it should not be the sole criterion for updating a risk assessment. A moderate-severity vulnerability may expose an incorrect architectural assumption. Conversely, a high-severity issue in a component may not be reachable in the product's actual configuration.

The reassessment decision should consider product-specific context: intended use, reasonably foreseeable use, operational environment, assets to be protected, exposure, compensating controls and the assumptions already documented in the risk assessment.

That is why retaining the reasoning matters. The evidence should explain the relationship between the generic vulnerability information and the manufacturer's product-specific conclusion.

Review the process across the support period

The CRA's main obligations apply from 11 December 2027. Manufacturers preparing now can use the implementation period to establish a repeatable lifecycle process before the risk-assessment and vulnerability-handling obligations become applicable.

A useful readiness exercise is to select several historical vulnerabilities and test whether the organisation can reconstruct the complete chain: affected product and version, information received, technical analysis, original risk assumption, reassessment decision, remediation, verification and final evidence.

If that chain depends on personal memory or disconnected records, the process is likely to become harder to operate as the number of supported releases grows.

Keeping vulnerability decisions connected to the correct product, release and evidence is also a natural fit for AA-sec. AA-sec is focused on secure product development and lifecycle evidence and is designed around traceability between requirements, vulnerability work, evidence and decisions. It does not make the manufacturer's legal compliance decision; the value of the workflow is keeping the supporting context reviewable as the product changes.

Practical readiness checklist

Before relying on the process, verify that the organisation can answer:

Where is the current cybersecurity risk assessment for each product maintained?
How are relevant vulnerabilities and third-party cybersecurity information captured?
Which events require an explicit reassessment decision?
Can each vulnerability be tied to the affected product, variant and supported release?
Can reviewers identify which existing risk assumptions were considered?
Is the decision to update or not update the assessment documented with rationale?
Are revised risk records linked to remediation and verification evidence?
Is historical assessment state retained sufficiently to reconstruct earlier decisions?
Are ownership and review dates recorded?
Can the process operate throughout the full support period rather than only before initial market placement?

Key takeaway

Under the CRA, vulnerability documentation and cybersecurity risk assessment are connected lifecycle activities. Manufacturers must systematically document relevant cybersecurity aspects, including vulnerabilities and relevant third-party information, and update the cybersecurity risk assessment where necessary.

The practical control is an explicit reassessment decision backed by product-specific evidence. By linking each material vulnerability to the affected product context, existing risk assumptions, the update decision and resulting remediation evidence, manufacturers can keep the assessment current without turning every vulnerability into a complete reassessment exercise.

Official sources

Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
Cyber Resilience Act — European Commission