CRA Due Diligence Checklist

Identify whether the component manufacturer has issued a Declaration of Conformity or applied CE marking

For most OSS components, the answer is "no" — which is expected, since non-commercial OSS is exempt. Document this finding.

Record the component's identity: name, version, PURL, license, and ecosystem

This establishes the exact artifact under assessment. PURL provides globally unique identification.

Assess license compatibility and commercial risk

License type affects distribution rights and may impose obligations (copyleft, attribution). Document the license and any implications.

Evaluate release cadence: how frequently are new versions published?

Regular releases indicate active maintenance. A component with no release in 18+ months is a risk indicator.

Assess maintainer health: bus factor, number of active contributors, responsiveness to issues

A single-maintainer project with slow issue response creates continuity risk. Document the contributor profile.

Review OpenSSF Scorecard or equivalent project health metrics

Scorecard evaluates branch protection, signed releases, fuzzing, CI tests, and SLSA compliance. Document the score and key findings.

Document time-to-remediate: how quickly does the project patch security issues?

Average days from CVE disclosure to patch release. Fast remediation (<14 days) is a strong signal of mature security processes.

Check for unpatched Critical and High severity CVEs in the specific version

Cross-reference against NVD, OSV.dev, and the European Vulnerability Database (EUVD, when available). Document all findings.

Perform reachability analysis: are known vulnerabilities exploitable in standard deployment configurations?

A CVE that exists in code but is unreachable in typical use is a different risk than one in a hot path. Document reachability for each finding.

Review historical vulnerability performance: frequency, severity, and patch speed over the past 24 months

A component that has had 20 Critical CVEs in two years is a different risk profile than one that has had zero, even if both are currently clean.

Verify binary hardening: ASLR, DEP/NX, Stack Canaries, Control Flow Guard

Compiled binaries should use modern exploit mitigations. Absence of these protections indicates elevated risk. Recommended for all components; required for high-criticality.

Run static analysis (SAST) for common weakness classes

Injection flaws, buffer overflows, use-after-free, and other CWE categories. Document tool used and findings summary. Included in both Standard and High-Criticality assessments.

Run credential / secret scanning on source repository and published artifacts

Scan git history and package artifacts for leaked API keys, tokens, and passwords. Active credentials in published packages are a direct security exposure. Included in both Standard and High-Criticality assessments.

Review for supply chain compromise indicators: anomalous code, obfuscated logic, unexpected network calls

AI-driven or manual review for code that doesn't match the component's declared purpose. Recommended for high-criticality components.

Scan published artifacts for malware signatures

Check package artifacts against antivirus engines (e.g., VirusTotal). Triage any detections. Recommended for high-criticality components.

Audit CI/CD workflows for security anti-patterns

Check for script injection, overly permissive tokens, and publish workflows triggerable by untrusted contributors. A compromised CI workflow is a direct path to a compromised release. Recommended for high-criticality components.

Inventory cryptographic algorithm usage (CBOM)

Identify all crypto algorithms used or implemented. Verify they meet current standards (e.g., no MD5 for security-sensitive contexts). Recommended for high-criticality components.

Assess top transitive dependencies for inherited risk

A component is only as secure as its dependencies. Review the 3–5 highest-risk sub-dependencies. Recommended for high-criticality components.

Each assessment is timestamped with a specific date of issue

Reports are point-in-time assessments. The date establishes what was known and when.

Each assessment has a unique Report ID for traceability

Enables cross-referencing between SBOM entries and due diligence evidence. Auditors expect traceability.

Findings are mapped to specific CRA Annex I Essential Requirements

Annex I, Section 1(1): unauthorized access protection. Section 1(3): attack surface minimization. Section 2(1): vulnerability identification and documentation.

A formal assertion is signed by a named assessor with documented credentials

Professional judgment carries higher weight than tool output in audits. The assertion is what makes the report audit-ready.

Assessment methodology is documented (data sources, tools, process)

Auditors will ask "how did you assess this?" Document the sources (NVD, OSV, OpenSSF Scorecard, Aldur, etc.) and the process.

Maintain a machine-readable SBOM covering at minimum all top-level dependencies

SPDX or CycloneDX format. Required by Annex I, Part II(1). The SBOM is the index; the due diligence reports are the evidence.

Link each SBOM entry to its corresponding due diligence report (via PURL and Report ID)

Auditors will cross-reference your SBOM against your documentation. Every component in the SBOM should have a traceable assessment.

Include reports in technical documentation under Annex VII: "test reports verifying conformity" and "vulnerability handling evidence"

This is the specific Annex VII section where due diligence reports belong. Cross-reference Article 13(5), Annex I Parts I and II, Recital 34.

Retain all documentation for at least 10 years after product is placed on the market

Article 13(13). Or for the duration of the support period (minimum 5 years per Article 13(8)(b)), whichever is longer.

Monitor assessed components for new Critical/High CVE disclosures

Annex I, Part II requires "effective and regular tests and reviews." Set up monitoring for all components in your SBOM.

Re-assess components upon major version changes, security patches, or at least annually

Point-in-time assessments become stale. Plan for annual refreshes or event-driven re-assessment.

Report actively exploited vulnerabilities to ENISA (via national CSIRT) within 24 hours

Required from September 11, 2026. You cannot report what you haven't identified — this obligation presumes you have component inventory and monitoring in place.