Home / EU Regulation
EU Regulation
Cyber Resilience Act
The CRA applies to products with digital elements placed on the Union market.
Effect of this requirement
This rule cannot be read in isolation.
- Transfers
- Bilateral relationship
- Country sources reviewed on
Assumptions, limitations and sources of this reading
Reading point
The product carries its own timeline
Versions, components, vulnerabilities and support decisions must be reconstructible.
- Product qualification and economic role
- Development and maintenance cycle
- Vulnerabilities, dependencies and support
- Product documentation and evidence
Product security cycle
Make security verifiable from design through to vulnerability handling.
Design
Requirements, architecture, threats and dependency choices.
Build
Development, integration, testing and traceability of components.
Distribute and maintain
Versions, documentation, support and fixes.
Receive and process
Reporting, qualification, coordination and product decision.
Decision path
Build the reading around the product and its versions
The analysis must follow what is placed on the market, maintained and patched, rather than a general cyber programme detached from the product lifecycle.
01Product and economic role
Identify the product with digital elements, the versions concerned and the role held in making it available on the European market.
02Support period
Define the maintained versions, patch commitments, dependencies and end-of-support conditions announced to users.
03Vulnerability handling
Link receipt of a report, qualification, decision, correction, coordination and communication to the teams actually responsible.
04File by version
Retain architecture, components, tests, SBOM, risk decisions, documentation and fix evidence for the version actually distributed.
Product security file
The records that must follow the product and its versions.
Questions to address
- The CRA qualification of your product and your economic role
- Your vulnerability management and disclosure process
- Your SBOMs and control over your dependencies
- Your support periods and update policy
Elements that support the response
- Product/version inventory with support status
- Operational disclosure channel and processing log
- SBOMs generated per published version
- Technical documentation and dated fix decisions
Confusions to avoid
- Waiting for the regulatory deadline whilst buyers are already requesting
- Publishing a disclosure channel with no process behind it
- Confusing a one-off SBOM with a maintained SBOM
- Promising product support without sustainable engineering capacity
Assurance file, PR-046Demonstration example
Market expectationSBOM available for each supported versionFinding
Proposed response“SBOM available on request”Finding
Actual stateSBOM generated once, never linked to published versionsFinding
Divergence observedThe SBOM no longer matches the versions shippedGap
ImpactDifficult to defend during the product reviewGap
ActionGenerate the SBOM within the integration pipeline and attach it to every releaseDecision
Reading the coloursFactual observationGap or riskDecision or action
Demonstration
Trace a vulnerability through to the version actually distributed.
The case retains the component, the affected versions, the remediation decision and the product file items that will need to be updated.
Understanding how evidence is qualified →Apply this reading
Delimit the product, the versions and the company's role.
The list of products, the supported versions and the role held in the market make it possible to identify the documentary and technical cycle to be examined.