The Cyber Resilience Act is the first horizontal cybersecurity regulation in the European Union to apply directly to products with digital elements. For software vendors, that scope is wide enough to cover almost everything they ship into the EU market. The compliance obligations begin to bite well before the headline 2027 enforcement date, because the underlying evidence has to exist for the periods the regulator will eventually inspect.
Self-assessment is the path most software products will take. The default conformity route under CRA Annex VIII allows manufacturers of non-critical products to evaluate themselves against the essential requirements in Annex I and the vulnerability handling requirements in Annex II. Self-assessment does not mean light-touch. It means the manufacturer carries the documentation burden, and a notified body is not standing between you and your customers if the documentation falls short.
What CRA actually asks for
The essential cybersecurity requirements in Annex I read like a security baseline. Products must be delivered without known exploitable vulnerabilities, must have a secure default configuration, must protect data in transit and at rest, must minimize attack surface, and must support secure update mechanisms. Annex II adds the operational layer: vulnerability handling, coordinated disclosure, prompt remediation, and an SBOM kept current for the lifecycle of the product.
For a software product, almost every one of those requirements ties back to evidence the supply chain already produces, or could produce, if the right capture is in place. The trick is that CRA cares about the lifecycle, not just the release moment. A product is in scope for as long as it is on the market, and the evidence must keep accumulating for that entire period.
The components of a CRA evidence pack
A practical self-assessment pack for a software product centers on six artifact families.
The first is the SBOM, in a recognized format such as CycloneDX or SPDX, kept current as the product evolves. CRA explicitly references the SBOM as a required artifact. The expectation is not a one-time export but a series of versioned SBOMs that match the releases shipped to EU customers.
The second is the vulnerability handling record. For each known vulnerability that affects a shipped version, the pack should document when it was identified, how it was assessed for exploitability in context, what mitigation was applied, and how customers were notified. This is the meat of Annex II.
The third is the coordinated disclosure log. Manufacturers are expected to provide a contact point and a process for receiving vulnerability reports. The pack should include the policy, the contact details published to the public, and the records of any reports received and their handling.
The fourth is the secure development evidence. CRA does not prescribe a specific framework, but it expects the manufacturer to show that security is considered throughout the lifecycle. SCM controls, code review records, build pipeline policies, and dependency scanning all contribute here.
The fifth is the update mechanism documentation. Products must support security updates, and the pack should describe how updates are delivered, how they are authenticated, and how customers are informed.
The sixth is the risk assessment itself. CRA Annex I requires that products be designed against an analysis of cybersecurity risks. The pack should include the assessment, the threats considered, and how the design choices respond to them.
Where most teams underestimate the work
The most common mistake is treating CRA as a release-time exercise. The regulation cares about every version that is on the market, for as long as it is supported. A product with a five-year support window has five years of vulnerability handling records to produce, not just the records from the most recent release.
The second mistake is treating the SBOM as a static artifact. CRA expects the SBOM to be kept up to date, which means each release needs a fresh SBOM, and the historical SBOMs need to remain accessible. If a vulnerability is reported against a component that was present in a version shipped two years ago, the pack must include the SBOM for that version.
The third mistake is underestimating the disclosure log. A coordinated disclosure process that has never received a report is not a deficiency. A coordinated disclosure process that received a report and cannot show how it was handled is.
How Safeguard supports CRA self-assessment
Safeguard generates and retains the supply chain artifacts CRA expects. SBOMs are produced on every build and stored against the release they describe, with content hashes, timestamps, and links to the source code that produced them. Vulnerability findings are recorded against the SBOMs that contained them, with severity, exploitability signals, and the affected components.
When a vulnerability is triaged, the decision is logged with the user, the rationale, and the linked artifacts. When a fix is shipped, the new SBOM links back to the finding it addresses. The result is a continuous record that maps cleanly to the Annex II vulnerability handling requirements.
For coordinated disclosure, Safeguard captures the inbound reports routed through the platform, the assessments performed, and the actions taken. For secure development, the policy gates that run at build and release time produce evaluation records that demonstrate the controls operated as designed.
When the time comes to assemble the self-assessment pack, the compliance lead pulls a scoped export covering the product, the version range, and the period under review. The export is structured against the CRA articles and annexes, which means an inspector can trace any claim in the pack to the underlying record.
The lifecycle obligation
CRA's lifecycle requirement is the part of the regulation most likely to surprise teams that have not built for it. Products must be supported for the period during which they are reasonably expected to be in use, with a minimum of five years for most categories. During that period, vulnerability handling continues, SBOM updates continue, and the evidence base grows.
Teams that adopt continuous evidence generation absorb this requirement without much friction, because the evidence accumulates as a side effect of operations. Teams that rely on point-in-time documentation face an ongoing burden that grows with each new version shipped.
Preparing for inspection
Self-assessment under CRA does not eliminate the possibility of inspection. Market surveillance authorities can request documentation, and they can require remediation if the documentation is insufficient. The pack should be ready to show, not just ready to assemble.
A good test is the random version question. Pick a version of the product that shipped six months ago. Can you produce its SBOM, the vulnerabilities that were known about it at that time, the triage decisions that followed, the updates that were issued, and the customer notifications that went out? If those artifacts exist and can be retrieved within hours, the pack is in good shape. If they require reconstruction, the work to do is clear.
The strategic position
CRA is not the last regulation that will require this evidence. NIS2 expects supply chain risk management for essential and important entities. The EU Data Act adds obligations around interoperability and access. Future product-specific regulations are likely to follow the same evidence pattern.
Building the CRA pack as infrastructure rather than as a one-off project means each subsequent regulation becomes a translation layer rather than a new program. The supply chain evidence base is the foundation, and CRA is the first major test of whether it holds.