What evidence can a software repository actually provide for the Cyber Resilience Act?
A repository can support a claim. It cannot make the manufacturer’s decision.
Trace each mapped requirement from the legal text to the records a software team might hold, the Annex VII technical file, and the conclusions those records cannot support on their own.
These are the 16 grouped requirements ConformOps currently maps, not every individual CRA provision. The first 15 map binding law; the final row is a non-binding editorial convention. Every evidence example and Annex VII connection is ConformOps’ interpretation, not an official acceptance criterion.
The table is a reading index. Follow any requirement to its full record below, with all dataset fields visible without expanding a control. On smaller screens the table scrolls horizontally.
Repository observability of the mapped subject. Partial and No are evidence boundaries, not failure states.
The final category, full application of a harmonised standard, entitlement to a conformity presumption or completion of the selected route. A public repository or open-source dependency does not establish Article 32(5) eligibility; that option covers qualifying Class I/II software, not critical products.
packages.lock.json; package-lock.json; pom.xml; other manifests and lockfiles; supplied CycloneDX or SPDX JSON.
Partial
That all shipped components are present, a supplied SBOM is accurate, or the product has no vulnerabilities. Presence, structural usability and completeness are different claims.
That the chosen duration is justified, users can obtain and install updates, signing keys are controlled, or updates remain available for the required period.
User manual source; secure installation and configuration guides; update and decommissioning instructions; support and contact pages.
Partial
That the instructions reach users, are understandable in the required language, or accurately describe the distributed product and its support arrangements.
Declaration draft; conformity-procedure index; CE artwork; references to certificates and sign-off records.
No
That the manufacturer has completed conformity assessment, an authorised person signed, the certificate covers this release or CE marking was correctly affixed.
Source register; citations with authority labels and review dates; methodology documentation.
Yes
That guidance changes the Regulation, creates an additional obligation or validates a legal conclusion. This row is an editorial safeguard, not a compliance requirement.
02 / Shared vocabulary
Five terms. Five different claims.
Observable evidence
A bounded fact directly inspectable in a particular source revision or retained artifact, such as a declared dependency or a configured test. Presence is not proof of effectiveness.
Supporting evidence
A record that helps substantiate a claim when its provenance, release relevance and scope are checked, such as a test report linked to a shipped build.
Partial evidence
Relevant information that leaves material parts of the claim unverified, such as a manifest without a build inventory.
Human assertion/decision
An attributed statement or accountable choice, such as product scope, risk acceptance or the support-period rationale. Storing it in Git does not turn it into an independently verified fact.
Not observable from a repository
A fact requiring evidence outside the source snapshot, such as whether a report was submitted, an inbox is monitored or a conformity procedure was completed.
These labels describe the role of evidence, not a ranking or percentage. An observable fact can still be only partial support for a wider legal requirement. Strong evidence below means stronger support after provenance and scope checks, never automatic satisfaction.
03 / The evidence records
What to look for. What it leaves open.
Example paths describe where teams commonly keep records. They are not required filenames or a promise that a scanner can read every format. Each record has a stable link for citation.
README.md; docs/product-scope.md; architecture diagrams; licence and distribution notes.
Other evidence / where to look
Commercial supply terms, EU distribution records, a reviewed product boundary and evidence of any own-name/trademark supply or substantial modification assigning manufacturer duties.
Observable evidence / what it establishes
The snapshot describes intended functions, interfaces and stated distribution assumptions.
Strong supporting evidence
A dated scope decision tied to the release, actual supply model and remote processing dependencies, with evidence for any exclusion.
Partial evidence
An architecture diagram or README describing only one repository in a larger product.
Insufficient by itself
An open-source licence or a README saying the CRA does not apply.
What cannot be inferred
Whether the product is made available on the EU market, whether an exclusion applies, or which legal role an organisation actually holds.
Human assertion/decision needed? Yes
Confirm the product boundary, market facts, role and any exclusion rationale.
Annex VII connection
1(a) intended purpose; 2(a) architecture. These support scope analysis, not a legal scope determination.
Applicable Official Journal standards references, certification scope and external conformity-assessment records where required. For Article 32(5), retain whole-product qualifying FOSS licence/source evidence and Article 31 technical documentation public at placing on the market, tied to the release.
Observable evidence / what it establishes
Documented product functions and a proposed category or standards mapping.
Strong supporting evidence
An approved comparison of actual core functions to legal categories, with a justified route and verified scope of applied standards or certification.
Partial evidence
A functional specification naming security features without the complete product context.
Insufficient by itself
A dependency on a cryptography library, a security badge or an unsupported claim of Class I status.
What cannot be inferred
The final category, full application of a harmonised standard, entitlement to a conformity presumption or completion of the selected route. A public repository or open-source dependency does not establish Article 32(5) eligibility; that option covers qualifying Class I/II software, not critical products.
Human assertion/decision needed? Yes
Approve classification and the applicable route; obtain the external assessment or certification when required.
Annex VII connection
1(a), 2(a) product functions and architecture; 5 standards and solutions; 7 declaration.
Operational context, user and misuse evidence, signed residual-risk decisions and external test findings.
Observable evidence / what it establishes
Named assets, threats, assumptions, proposed treatments and recorded review history.
Strong supporting evidence
A release-specific assessment linking realistic use and misuse cases to controls, test evidence, applicability decisions and accountable risk acceptance.
Partial evidence
A threat model for one service without the product's other components or operating environment.
Insufficient by itself
An empty risk-register template or a vulnerability scanner's numerical score.
What cannot be inferred
That all material risks were identified, a likelihood estimate is justified, or residual risk is acceptable to the manufacturer.
Human assertion/decision needed? Yes
Approve assumptions, requirement applicability, treatment and residual-risk acceptance.
Annex VII connection
3 risk assessment; 2(a) design context; 6 test reports.
Data-flow inventories; retention settings; rate limits; service and privilege configuration; resilience tests; logging policies.
Other evidence / where to look
Live exposure reviews, recovery exercises, traffic and failure testing, and operational data-retention verification.
Observable evidence / what it establishes
Declared data use, exposed interfaces, mitigation code and configured logging or resilience mechanisms.
Strong supporting evidence
A release-bound data and interface inventory with justified necessity, least-privilege review, failure testing and verified incident-containment behaviour.
Partial evidence
A rate-limit configuration or backup script without a demonstrated recovery or load test.
Insufficient by itself
A statement that only necessary data is collected, or that backups exist.
What cannot be inferred
That deployed interfaces match source, collected data is necessary, recovery works, or connected systems remain available during an attack.
Human assertion/decision needed? Yes
Justify data necessity and applicability; review resilience, exposure and incident-impact evidence.
Annex VII connection
2(a), 2(c) architecture and monitoring; 3 risk assessment; 6 tests.
SECURITY.md; security.txt source; disclosure policy; triage runbook; advisory templates and remediation history.
Other evidence / where to look
Published contact and policy, monitored inbox records, case timelines, upstream notifications and user advisories.
Observable evidence / what it establishes
A stated reporting channel, policy, handling steps and any retained issue or advisory records.
Strong supporting evidence
A published CVD policy and usable contact, with attributable case records showing triage, remediation, upstream coordination and justified disclosure timing.
Partial evidence
SECURITY.md names a contact and response target but has no evidence of actual handling.
Insufficient by itself
A security email address or a policy template copied into the repository.
What cannot be inferred
That the contact is monitored, the policy is enforced, reports are handled without delay or affected users received advisories.
Human assertion/decision needed? Yes
Assign operational ownership, assess reports and approve remediation and disclosure decisions.
Annex VII connection
2(b) vulnerability processes, CVD policy and contact evidence; 6 process tests.
packages.lock.json; package-lock.json; pom.xml; other manifests and lockfiles; supplied CycloneDX or SPDX JSON.
Other evidence / where to look
Build output, SCA-generated SBOM, artifact digests and supplier component records.
Observable evidence / what it establishes
Declared or locked dependencies and the contents and structural usability of a supplied SBOM.
Strong supporting evidence
A release-bound CycloneDX or SPDX SBOM generated from the shipped build, with verified artifact identity and a reviewed inventory including at least top-level dependencies.
Partial evidence
A dependency manifest: ranges do not identify shipped versions, and even a lockfile may include development-only components.
Insufficient by itself
A README saying we track dependencies, or an empty generated SBOM.
What cannot be inferred
That all shipped components are present, a supplied SBOM is accurate, or the product has no vulnerabilities. Presence, structural usability and completeness are different claims.
Human assertion/decision needed? Yes
Confirm release linkage and inventory completeness, investigate divergences and assess component vulnerabilities.
Annex VII connection
2(b) SBOM within vulnerability-process documentation; 8 supply to authorities where applicable following a reasoned request. This is not a general duty to publish the SBOM.
Expected-use and lifecycle evidence, support commitments, signed release artifacts, delivery tests and update availability records.
Observable evidence / what it establishes
A proposed support end date, configured update mechanisms and stated distribution process.
Strong supporting evidence
An approved support-period rationale tied to expected product use, with authenticated release artifacts, tested distribution and retained availability evidence.
Partial evidence
A release-signing workflow or end-of-support date without execution, delivery or lifecycle evidence.
Insufficient by itself
A promise of lifetime updates or a signed Git tag without a verified update chain.
What cannot be inferred
That the chosen duration is justified, users can obtain and install updates, signing keys are controlled, or updates remain available for the required period.
Human assertion/decision needed? Yes
Approve the support rationale, applicable exceptions and the adequacy of delivery and retention arrangements.
Annex VII connection
2(b) secure update distribution; 4 support-period rationale; 1(d) user instructions.
Awareness timestamps, exploitation and affectedness evidence, submission receipts and affected-user communications.
Observable evidence / what it establishes
The presence of a runbook or retained drill record can be inspected; an actual reporting obligation and submission require external facts.
Strong supporting evidence
An accountable case decision and timestamped reports with platform receipts linked to the relevant vulnerability, plus user-notification records where applicable.
Partial evidence
A rehearsed runbook with named owners and the 24-hour, 72-hour and applicable final-report steps.
Insufficient by itself
A CVE or KEV match, an internal issue marked reported, or a successful drill presented as a real submission.
What cannot be inferred
That this product is actively exploited, when awareness arose, whether reporting is required, or whether the authority received a timely report.
Human assertion/decision needed? Yes
Assess the reporting trigger and awareness facts; make and record required reports and user communications.
Annex VII connection
2(b) related vulnerability-handling process context. Annex VII documentation is not an Article 14 submission.
docs/technical-file/; architecture and design records; standards register; test reports; release-document index.
Other evidence / where to look
Controlled technical-file package, production-validation records, approved risk and support rationale, signed declaration and retention controls.
Observable evidence / what it establishes
Available documentation sections, named versions and links to retained supporting records.
Strong supporting evidence
A controlled release-specific file covering all applicable Annex VII elements, with traceable sources, responsible review, retained tests and a copy of the declaration.
Partial evidence
An architecture document and generated technical-file draft with missing production, testing or approval records.
Insufficient by itself
An Annex VII folder, a populated template or a generated export labelled complete.
What cannot be inferred
That the technical file is complete, current, authentic, retained for the required period or sufficient for a conformity assessment.
Human assertion/decision needed? Yes
Review every applicable section and its evidence, resolve omissions and control release and retention of the file.
Annex VII connection
1 product and instructions; 2 design, production and vulnerability processes; 3 risks; 4 support rationale; 5 standards; 6 tests; 7 declaration; 8 SBOM on qualifying authority request.
User manual source; secure installation and configuration guides; update and decommissioning instructions; support and contact pages.
Other evidence / where to look
The instructions actually supplied with the release, language and accessibility review, and publication or distribution evidence.
Observable evidence / what it establishes
Written instructions, stated security properties and contact or support details in the snapshot.
Strong supporting evidence
Release-matched instructions checked against the product and Annex II, delivered in the required form and language with verified contact and support information.
Partial evidence
A developer README with installation steps but no user-specific security or decommissioning guidance.
Insufficient by itself
A documentation URL or a statement that users should configure the product securely.
What cannot be inferred
That the instructions reach users, are understandable in the required language, or accurately describe the distributed product and its support arrangements.
Human assertion/decision needed? Yes
Review accuracy, audience, language and delivery for the relevant market and release.
Annex VII connection
1(d) information and instructions required by Annex II.
Declaration draft; conformity-procedure index; CE artwork; references to certificates and sign-off records.
Other evidence / where to look
An authorised signed declaration, completed conformity-assessment records, valid external certificates where required and marking evidence.
Observable evidence / what it establishes
A declaration file or marking asset can be found, but authority, route completion and actual marking require verification beyond source.
Strong supporting evidence
An authenticated signed declaration identifying the product and applicable legislation, backed by the completed route and verified marking on the distributed product as applicable.
Partial evidence
A filled Annex V working draft or a certificate reference without scope and validity checks.
Insufficient by itself
A generated declaration, a CE logo in the repository or a passing evidence check.
What cannot be inferred
That the manufacturer has completed conformity assessment, an authorised person signed, the certificate covers this release or CE marking was correctly affixed.
Human assertion/decision needed? Yes
Complete the applicable procedure; an authorised signatory issues the declaration and the manufacturer controls marking.
Annex VII connection
7 copy of the EU declaration; 5 standards and specifications; 6 test reports.
Source register; citations with authority labels and review dates; methodology documentation.
Other evidence / where to look
Current official publications and an editorial review of any interpretation drawn from them.
Observable evidence / what it establishes
Whether source entries contain a URL, date and binding or non-binding label.
Strong supporting evidence
A reviewed source register linking legal propositions to EUR-Lex and separately labelling Commission or ENISA explanatory material.
Partial evidence
A useful guidance link without a date or distinction between explanation and legal text.
Insufficient by itself
A Commission or ENISA logo, or a statement that guidance is legally binding.
What cannot be inferred
That guidance changes the Regulation, creates an additional obligation or validates a legal conclusion. This row is an editorial safeguard, not a compliance requirement.
Human assertion/decision needed? No
No separate legal approval is created by this convention; an editor still checks source status and interpretation.
Annex VII connection
No standalone Annex VII requirement to use this labelling convention; source traceability supports documentation review.
Maintained by ConformOps. Dataset version 1.1.0; catalogue baseline cra-eu-2024-2847@2026-09-22.1; source review 2026-09-22.
Scope: one editorial row for each of the 16 ConformOps requirement IDs in the named ruleset. These are grouped product mappings, not the number of legal obligations and not an exhaustive clause-by-clause CRA checklist. Fifteen rows map binding law; one documents a non-binding source-handling convention.
Method: compare each mapped subject with the cited legal text, identify plausible software-team records, then separate what can be inspected from what requires operational evidence or an accountable decision. Examples are illustrative, not observations from a sample of repositories or a list of files ConformOps necessarily parses.
Legal references identify the English EUR-Lex texts, reviewed using retained EU Publications Office copies. They describe the subject of this public row and may refine the assessment catalogue's broader locators. Annex VII connections are our crosswalk, not extra obligations. Commission and ENISA explanatory guidance is non-binding; implementing regulations are binding law. No ENISA guidance supplies an additional requirement in this version.
Operator boundary: the substantive checklist describes manufacturer evidence. Articles 19, 20 and 24 establish distinct importer, distributor and steward regimes; these are not supplied by a manufacturer checklist. Articles 21 and 22 can assign manufacturer duties in specific circumstances, requiring an evidence-backed role decision. Manufacturer Article 14 reporting applies from 11 September 2026; steward Article 24(3) reporting applies from 11 December 2027. Other main obligations apply from 11 December 2027; earlier evidence work is readiness preparation.
Automatically observable means inspectable from a repository snapshot: Yes means the bounded fact can be inspected directly; Partial means only supporting records or implementation clues are visible; No means the decisive fact requires external verification. It never means automatically satisfied. A repository may retain an external record without proving its authenticity or current validity.
Strong evidence means comparatively stronger support for the stated claim after checking authenticity, date, product scope, release or build identity, completeness and reviewer authority. It is not a legal safe harbour. Missing evidence in a snapshot means unknown, not absent in the organisation; a successful scan or build is not proof of compliance.
Human decision needed concerns the substantive manufacturer or reviewer judgment described in this dataset. It is separate from whether ConformOps implements a mandatory approval gate for that rule. A No on the editorial source-handling row means no separate legal decision is created by that convention.
Maintenance: review legal sources and catalogue coverage before each release; increment the dataset version and review date for content changes, list affected IDs and reasons in the changelog, and retain prior released data files. These are dated editorial findings, not a promise of continuous legal monitoring. Corrections can be sent to help@conformops.eu with the row ID and supporting source.
Coverage limits: grouped rows are not a complete decomposition of Annex I. For example, permanent data removal and secure transfer in Part I(2)(m) need their own implementation evidence; user decommissioning instructions alone do not establish that behaviour. Hardware-specific evidence and product-specific sector rules need additional analysis.
Timing: Article 71 provides for main application from 11 December 2027 and Article 14 reporting from 11 September 2026. The map describes evidence needs, not a claim that every duty already applies to every product. Read the reporting timeline and the cited legal text for the relevant dates and conditions.
05 / An open reference
Download, cite and build on it.
Reuse the original dataset under Creative Commons Attribution 4.0 International (CC BY 4.0). Credit ConformOps, link the licence and indicate any changes. ConformOps' original mapping, commentary and dataset structure. Third-party legal texts and guidance remain subject to their own reuse terms; no ownership of them or official endorsement is claimed.
CSV contains one row per requirement, with version, licence and methodology retained in each row. JSON includes the same records with a dataset-level vocabulary, methodology and changelog.
Suggested citation
ConformOps, CRA Software Evidence Map, version 1.1.0 (2026-09-22), https://conformops.eu/research/cra-software-evidence-map. CC BY 4.0. Indicate changes when adapting.
For a specific claim, append its requirement ID and permalink, for example CRA-SBOM-001. Cite the underlying legal text for legal requirements and this map for its evidence analysis.
Found an omission or a better evidence example? Send a correction with the requirement ID and a supporting source.
06 / Publication history
Changelog
Version 1.0.0 ·
Initial publication of all 16 mapped requirement IDs, with independently checked legal locators, evidence boundaries, Annex VII connections, methodology and CC BY 4.0 downloads. No repository sampling or compliance scoring is performed.
Version 1.1.0 ·
Reviewed catalogue coverage for ruleset 2026-09-22.1. Clarified CRA-SCOPE-001 operator boundaries and CRA-CLASS-001 Article 32(5) release-specific evidence, and methodology distinguishes manufacturer and steward reporting dates. Other row mappings retain their evidence boundaries; no new statutory duty, automatic approval or compliance score is introduced. Prior release files remain unchanged.