The Cyber Resilience Act came into enforcement through 2026 with concrete due-diligence expectations on software components. The text is general — vendors must demonstrate that they have evaluated and managed component-level security risks throughout the product lifecycle — but the regulator's interpretation, articulated in early enforcement cases, is becoming clearer. Pure SBOM submission is not enough. Vulnerability management policies on paper are not enough. Evidence that specific components have been evaluated, that decisions have been made deliberately, and that residual risks are documented — that is what holds up. Reachability analysis is the technique that produces the evidence at the level the regulator expects.
What CRA due diligence actually expects
Three concrete expectations from early enforcement guidance:
- Component-level risk assessment. For each component in the product, a documented evaluation of security risks.
- Documented mitigation decisions. When a known CVE exists and is not patched, a documented reason.
- Continuous reassessment. The risk picture is current, not a snapshot from product launch.
Each expectation is achievable. Each is harder without reachability data than with.
How reachability supports each expectation
Three mappings:
Component-level risk assessment. Reachability classifies whether each component's risk surfaces in your specific deployment. A library with critical CVEs that is included but never called has materially different risk than one that is on the request path.
Documented mitigation decisions. "Not patched because not reachable, sanitizer detected at the call site, EPSS below threshold" is a documented decision. "Not patched because we didn't get to it" is not.
Continuous reassessment. Reachability re-runs on every release; the classification for each finding has a timestamp and analyser version. The picture is current by construction.
What evidence the CRA file should contain
For each in-scope product, five artefacts:
- Current SBOM in CycloneDX or SPDX with reachability extensions.
- Reachability classification per CVE per component, with timestamps.
- Documented decisions for non-patched CVEs (reasoning, alternative mitigations).
- Vulnerability disclosure policy and incident response evidence.
- Update lifecycle commitments and recent update record.
A vendor walking into a CRA review with these five produces a defensible package. A vendor without them is improvising.
Where customers underestimate the effort
Two recurring patterns:
Treating CRA as a one-time submission. It isn't. Continuous evidence beats spike-effort production.
Underestimating reachability's role. Programs that try to do CRA due diligence with pure SBOM and CVSS triage discover the gap during the first audit conversation, not before.
Programs that integrate reachability from the start avoid both.
How Safeguard Helps
Safeguard produces CRA-aligned evidence as default platform output: reachability-enriched SBOMs, documented decision records per finding, continuous re-assessment with timestamps, lifecycle commitments tracked. Griffin AI generates the narrative summaries that auditors expect to see attached to the technical evidence. For vendors selling into the EU under CRA enforcement, this is the architectural choice that turns due diligence from a project into a continuous platform output.