A useful product security evidence checklist for Cyber Resilience Act (CRA) readiness should answer one practical question: can the manufacturer reconstruct what product was assessed, which cybersecurity risks and requirements applied, what engineering work was performed, what vulnerabilities were known, and why a release or post-market decision was made?
The CRA requires manufacturers to document cybersecurity risks, systematically document relevant cybersecurity aspects, maintain technical documentation, perform security tests and reviews, handle vulnerabilities, and keep product information current through the lifecycle. The evidence needed to operate those duties is broader than a single compliance folder. It should remain tied to the exact product, version and decision that generated it.
Evidence is broader than the formal technical documentation
Article 31 and Annex VII define the minimum content of the CRA technical documentation. That formal set includes the product description, relevant software versions, design and architecture information, vulnerability-handling processes, the cybersecurity risk assessment, support-period reasoning, applied standards or other technical specifications, test reports, the EU declaration of conformity and, where applicable on reasoned request, the SBOM.
Operational product-security evidence is usually broader. Teams may need intermediate test results, vulnerability triage records, release approvals, component provenance, change records, incident timelines and other engineering records to explain how the formal documentation was produced and kept current.
The practical distinction is:
- technical documentation is the regulated documentation set required by the CRA;
- supporting security evidence is the traceable record of engineering, security and governance work that substantiates decisions and helps keep that documentation accurate.
Not every internal artefact needs to be copied into Annex VII documentation, but the manufacturer should be able to retrieve the records that support material security and conformity decisions.
1. Product identity and scope evidence
Every evidence chain starts with an unambiguous product baseline. Annex VII requires a general description of the product, its intended purpose, software versions that affect compliance, and the user information required by Annex II.
For each product or release, retain enough context to identify exactly what the evidence applies to:
- product name, type, variant and release identifier;
- intended purpose and reasonably foreseeable use;
- supported operating or deployment environments;
- software, firmware and hardware versions that affect cybersecurity requirements;
- relevant build or artefact identifiers, hashes or signed release references;
- architecture or component boundaries used for the assessment;
- manufacturer legal entity and accountable product owner;
- applicable user information and security instructions.
The important control is scope consistency. A risk assessment for version 3.1 should not silently become evidence for version 3.4 if architecture, dependencies or security assumptions changed in between.
2. Cybersecurity risk assessment evidence
Article 13 requires the manufacturer to assess cybersecurity risks and use the result during planning, design, development, production, delivery and maintenance. The assessment must be documented and updated where appropriate during the support period.
A practical evidence set should show:
- assets, functions and security properties that need protection;
- intended purpose, reasonably foreseeable use and operating assumptions;
- threat scenarios, attack paths and trust boundaries considered;
- identified cybersecurity risks and their treatment decisions;
- which Annex I Part I requirements apply;
- how applicable requirements are implemented;
- why a requirement is considered not applicable, where relevant;
- residual-risk decisions and accountable approval;
- triggers that require the assessment to be reviewed.
The evidence should make the reasoning visible, not merely preserve a final risk score. A later reviewer should be able to understand why a risk was accepted, mitigated, transferred into a requirement or reopened after a product change.
3. Security requirements, design and architecture evidence
Annex VII requires information on product design and development and, where applicable, drawings, schemes and a system-architecture description explaining how software components interact and integrate into the overall processing.
Useful records include:
- security requirements derived from the risk assessment;
- architecture diagrams and trust boundaries;
- external interface and protocol inventories;
- authentication and access-control design decisions;
- cryptographic design and key-handling assumptions;
- data-flow and data-minimisation decisions;
- secure-default configuration decisions;
- attack-surface reduction measures;
- resilience and incident-impact mitigation measures;
- security-relevant logging and monitoring design.
The goal is traceability from risk to requirement to implementation evidence. A diagram alone is not enough if there is no way to show which security concern it addresses or which released product version it describes.
4. Component and SBOM evidence
Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including through an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. Article 13 also requires due diligence when integrating third-party components.
For each release, retain:
- the release-specific SBOM;
- component names, versions and stable identifiers where available;
- supplier or upstream source information relevant to product security;
- evidence of manually integrated or vendored components that automated package discovery may miss;
- component-change history between releases;
- records linking component vulnerabilities to affected products and releases;
- third-party security information used in risk or remediation decisions.
The SBOM should be treated as product evidence, not as a detached build artefact. Its value depends on being attributable to the exact release used for vulnerability analysis and maintenance decisions.
5. Security testing and review evidence
Annex I Part II requires effective and regular security tests and reviews. Annex VII requires reports of tests used to verify the product and vulnerability-handling processes against the applicable essential cybersecurity requirements.
Keep records that show what was tested, against which product baseline, and what happened to the findings:
- security test plan or test scope;
- test environment and product version;
- relevant automated security-test outputs;
- code-review or design-review findings where used;
- penetration, fuzzing or protocol-security test reports where appropriate to the product and risk;
- identified findings and severity or risk assessment;
- remediation or accepted-risk decisions;
- verification or regression-test evidence after remediation;
- final test summary used in the release decision.
The CRA does not prescribe one universal test toolchain. The evidence should instead demonstrate that the manufacturer selected and performed security verification appropriate to the product and its cybersecurity risks.
6. Vulnerability-handling evidence
Vulnerability handling continues after release and needs a durable decision trail. Annex I Part II covers identification, remediation, testing, disclosure, coordinated vulnerability disclosure, secure distribution of updates and related records.
A practical vulnerability evidence record should include:
- intake source and discovery time;
- affected product, release and component scope;
- technical analysis and exploitability assessment;
- decision status and reasoning;
- links to the relevant SBOM component where applicable;
- remediation owner and planned fix;
- security test or verification evidence for the fix;
- security-update release and distribution record;
- disclosure decision and publication information;
- coordinated vulnerability disclosure correspondence where relevant;
- Article 14 reporting assessment where a reporting trigger may apply;
- user communication and mitigation instructions where required.
Preserve negative decisions as well. If a candidate vulnerability is assessed as not affecting a release, the reason and evidence behind that conclusion can be as important as a confirmed finding.
7. Support-period and security-update evidence
Article 13 requires manufacturers to determine a support period that reflects expected use and to handle vulnerabilities throughout that period. The end date must be communicated to users, and Annex VII requires the information used to determine the support period.
Retain:
- the support-period decision and its rationale;
- expected product lifetime and use assumptions;
- relevant third-party component or operating-environment dependencies;
- published support-period information;
- security-update policy and distribution mechanism;
- records showing when security updates were released and made available;
- update integrity or authenticity verification evidence;
- end-of-support user communication where applicable.
A support-period decision should be versioned if the product, market assumptions or dependencies change in a way that affects the underlying reasoning.
8. Release and conformity-decision evidence
Before placing a product on the market, the manufacturer must prepare technical documentation and carry out the applicable conformity assessment. A practical release evidence package should connect the formal conformity material with the engineering baseline that was actually approved.
Useful records include:
- release identifier and immutable artefact references;
- final risk-assessment revision;
- applicable requirement status and unresolved exceptions;
- final security-test summary;
- open vulnerability review and disposition;
- approval of residual risks or documented exceptions;
- applied harmonised standards, common specifications, certification schemes or other technical specifications, as relevant;
- conformity-assessment records;
- EU declaration of conformity;
- accountable release approval and date.
The release approval should distinguish machine-verifiable conditions from human decisions. Automation can confirm that evidence exists; it should not silently substitute for accountable risk or conformity judgement.
9. Post-market monitoring and corrective-action evidence
CRA evidence does not stop when a release is placed on the market. Manufacturers must systematically document relevant cybersecurity aspects, handle vulnerabilities during the support period and take corrective measures when they know or have reason to believe that a product or manufacturer process is not in conformity.
Post-market records can include:
- newly identified vulnerabilities and affected-release analysis;
- security incidents and product-impact assessment;
- updated risk assessments;
- corrective or mitigating measures;
- security-update releases;
- user notifications;
- regulatory reporting decisions and submission records where Article 14 applies;
- changes to product support or operating assumptions;
- evidence that a product change triggered, or did not trigger, reassessment.
This creates continuity between the released product and the evidence generated while it remains supported.
10. Evidence-management controls
Evidence quality is not only about the document itself. Teams also need controls that make records attributable and retrievable later.
For each material record, capture where practical:
| Evidence control | Question it should answer | | --- | --- | | Product scope | Which product, variant and release does this record belong to? | | Source | Which tool, team or process created it? | | Timestamp | When was it created or approved? | | Owner | Who is accountable for the record or decision? | | Version | Is this the current record, or has it been superseded? | | Integrity | Can the team detect unintended alteration? | | Relationship | Which requirement, risk, component, vulnerability or decision does it support? | | Retention | How long must it remain available? | | Access | Who can view or change it? |
For formal CRA technical documentation and the EU declaration of conformity, Article 13 requires manufacturers to keep them available to market-surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer. Supporting evidence should be retained consistently enough that the manufacturer can still explain the technical documentation and lifecycle decisions during the relevant period.
A compact release evidence checklist
Before approving a release, verify that the evidence set can answer these questions:
- Product baseline: Can we identify the exact product, software and hardware versions being approved?
- Purpose and assumptions: Are intended use, foreseeable use and operating assumptions current?
- Risk assessment: Does the cybersecurity risk assessment reflect this release?
- Requirement coverage: Can applicable Annex I requirements be traced to implementation and verification evidence?
- Architecture: Are security-relevant interfaces, dependencies and trust boundaries current?
- SBOM: Is there a release-specific SBOM and can component changes be explained?
- Security verification: Do test records identify the release, scope, findings and remediation status?
- Vulnerabilities: Are known findings and candidate vulnerabilities assessed with documented reasoning?
- Updates and support: Are support-period and security-update decisions documented and communicated where required?
- User information: Are security instructions and required user-facing information aligned with the release?
- Conformity material: Are the required technical documentation and conformity records current?
- Release decision: Is approval attributable to an accountable person or process, including any accepted residual risks?
- Post-market ownership: Is there a clear owner for monitoring, vulnerability response and corrective action after release?
A checklist is useful only if each item resolves to evidence. Replacing the links with a collection of screenshots or a generic “done” status makes later reconstruction difficult.
Common evidence anti-patterns
Several patterns weaken an otherwise mature product-security process:
- Evidence without product scope. A test report exists, but nobody can prove which release it covered.
- Current-state-only records. A dashboard shows today's status but historical decisions are overwritten.
- SBOM without release identity. Components are listed, but the SBOM cannot be tied to the shipped artefact.
- Vulnerability status without reasoning. A finding is marked “not affected” or “accepted” without supporting analysis.
- Risk assessment without change triggers. The document exists, but significant product changes do not cause review.
- Approval without accountable ownership. A release is marked green with no record of who accepted residual risks.
- Compliance folder assembled at the end. Evidence is copied from engineering tools after the release instead of being generated and retained as part of normal work.
The corrective pattern is consistent: keep the evidence close to the engineering activity that creates it, then preserve the relationships needed to reconstruct a decision later.
Keeping requirements, evidence, vulnerability work and release decisions connected to the correct product context is the operational challenge behind this checklist. AA-sec is designed around traceability between requirements, security evidence, assessments, vulnerability work, release decisions and exact product or lifecycle context, while complementing existing engineering and delivery systems. It does not determine CRA conformity or make the manufacturer's engineering or legal decisions.
Key takeaway
A CRA readiness evidence set should let a manufacturer reconstruct the product-security story of a specific release: what product was assessed, what risks and requirements applied, which components were included, what security verification was performed, how vulnerabilities were handled, what users were told, and why the product was approved or changed.
The strongest evidence model is therefore lifecycle-based rather than document-based. Build evidence into product, security and release workflows, keep each record scoped to the correct version, and preserve enough history to explain both positive and negative decisions when the product changes or a market-surveillance question arrives.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products — BSI