EU Cyber Resilience Act: Product Cybersecurity and Lifecycle Evidence
The EU Cyber Resilience Act (CRA) creates product cybersecurity and lifecycle obligations for products with digital elements placed on the EU market. It increases pressure on manufacturers and product teams to understand how software, firmware, components, suppliers, updates, vulnerabilities, technical documentation, and lifecycle support affect product security.
For supply chain security, the practical question is not only whether a product has controls. It is whether the manufacturer can show how product and supplier risks are managed across design, release, update, vulnerability handling, and support.
Use this page when product cybersecurity regulation, technical documentation, lifecycle support, vulnerability handling, or market-access pressure is the reason for action.
This page focuses only on the parts of CRA that drive supply chain security controls and evidence. It is not a full CRA legal guide.
This page is based on Regulation (EU) 2024/2847 and related European Commission CRA guidance listed below. It was last reviewed against the linked official sources on 2026-07-01. It interprets supply chain security implications for this handbook and is not a complete legal compliance guide.
Official references
Use the legal text for obligations and dates. Use guidance sources to interpret what practical implementation may require.
- Regulation (EU) 2024/2847, the Cyber Resilience Act, as published in the Official Journal.
- Consolidated CRA text, for easier article and annex citation.
- European Commission CRA FAQ, for implementation and transition questions.
- Implementing Regulation (EU) 2025/2392, for technical descriptions of product categories in Annexes III and IV.
- BSI TR-03183, as a practical technical guideline for cyber resilience requirements.
Who should care
This page is relevant to:
- Manufacturers and product teams preparing products with digital elements for the EU market.
- Suppliers providing software, firmware, components, cloud functions, or security-relevant services to those products.
- Importers, distributors, and authorized representatives who may need evidence that product cybersecurity obligations are being handled.
- Customers, procurement teams, auditors, and assurance reviewers asking for product security evidence.
Scope and supply chain relevance
CRA applies to products with digital elements placed on the EU market. In practical terms, that can include software, hardware, firmware, connected devices, and remote data-processing solutions that are part of the product's function.
CRA-relevant supply chain work usually centers on secure development and release governance; software, firmware, and component visibility; supplier and dependency assurance; vulnerability handling during the support period; secure update capability; technical documentation; retained assurance evidence; and lifecycle support commitments.
For supply chain security, scope questions usually become evidence questions:
- Which software, firmware, components, services, and supplier inputs are part of the product?
- Which dependencies or supplier-delivered elements affect security during the support period?
- Which updates, vulnerability records, SBOMs, technical documentation, and supplier evidence need to be retained?
This page does not attempt to decide legal scope for every product. It highlights the supply chain security work that CRA can drive when a product is in scope.
Key dates and status
Use these dates for planning, not as legal advice:
| Date | Planning significance |
|---|---|
| 2024-12-10 | CRA entered into force. |
| 2026-09-11 | Vulnerability and incident reporting duties begin for manufacturers under Article 14. |
| 2027-12-11 | Main CRA requirements apply, including essential cybersecurity requirements, conformity assessment, technical documentation, and CE-marking obligations. |
The most important planning point for this handbook is the support-period and lifecycle implication: product teams need ways to maintain visibility of components, vulnerabilities, updates, supplier inputs, and retained evidence after initial release.
Relationship to other standards and drivers
CRA is product-led. It asks whether products with digital elements are designed, maintained, updated, documented, and supported securely.
It may interact with:
- NIS2, where customers or operators are regulated entities managing supplier and product security risk.
- Radio Equipment Directive requirements for connected radio products.
- IEC 62443, NIST SSDF, ETSI EN 303 645, SBOM/VEX expectations, and procurement or customer assurance requirements.
- Technology Options that support transparency, provenance, signing, attestation, and verification.
Harmonized standards and presumption of conformity
Harmonized standards may become important because they can provide a route to presumption of conformity for relevant CRA requirements. For supply chain security, that does not remove the need to understand the underlying evidence.
Even where a standard supports conformity, product teams and suppliers may still need to show which controls operate, which products or components are covered, which evidence is retained, and how updates or vulnerability decisions are handled during the support period.
For a boot-chain example, see ETSI EN 304 623: Boot Managers. That page maps the draft CRA boot-manager standard to supply chain evidence for product acceptance, trust anchors, verified or measured boot, updates, rollback protection, debug interfaces, vulnerability handling, and assessment records.
Threats and failure modes addressed
CRA-relevant practices can help reduce supply chain failures such as:
- vulnerable third-party components included without review
- unclear software or firmware provenance
- insecure or unauthorized update mechanisms
- weak vulnerability handling during the support period
- missing or incomplete SBOM or component visibility
- insufficient supplier or component assurance
- poor signing and release governance
- weak technical documentation evidence
- unsupported products remaining in use without clear lifecycle commitments
CRA expectations mapped to supply chain controls and evidence
| CRA-related expectation | Supply chain threat or failure mode | Practices & controls | Evidence to retain or request |
|---|---|---|---|
| Secure development and product security lifecycle CRA Art. 13 §§ 1-3 | Vulnerabilities are introduced through software, firmware, dependencies, or supplier-delivered components. | Secure development practices, dependency review, supplier security expectations, release governance. | Secure development records, dependency and component inventories, security review records, supplier declarations, release approval records. |
| Vulnerability handling during the support period CRA Art. 13 §§ 6-10 CRA Art. 14 | Known vulnerabilities remain untracked, unassessed, or unpatched across product and supplier components. | Vulnerability intake, triage, impact assessment, remediation workflow, supplier coordination, disclosure process. | Vulnerability records, triage decisions, remediation plans, supplier notifications, VEX/status statements, disclosure records. |
| Secure update capability CRA Art. 13 § 8 | Unauthorized, malicious, or vulnerable firmware or software is delivered to products. | Signed updates, update authorization, release approval, rollback protections, update monitoring. | Signing records, update manifests, release approvals, update logs, rollback and recovery records. |
| Software and component visibility CRA Art. 13 §§ 3, 6 | Teams cannot identify affected products when a component or dependency is compromised or vulnerable. | SBOM or component inventory generation, dependency tracking, product/component mapping. | SBOMs, component inventories, dependency review records, vulnerability impact assessments. |
| Technical documentation and assurance evidence CRA Art. 31 | The manufacturer cannot demonstrate that supply chain controls are defined and operating. | Evidence retention, control mapping, documentation ownership, assurance review process. | Technical documentation, control records, audit logs, test reports, supplier evidence, update and vulnerability records. |
| Supply-chain-aware lifecycle support and maintenance CRA Art. 13 §§ 8-10 | Products remain in use after supplier support, component visibility, update availability, or vulnerability handling commitments are unclear. | Support-period definition, supplier and component support tracking, end-of-support communication, maintenance planning, customer notification. | Support policy, supplier support records, component support status, maintenance records, end-of-support notices, update history, customer communications. |
What to do next
- Use Threats and Failure Modes to connect CRA-driven work to concrete supply chain failures.
- Use 10 Best Practices and Lifecycle Map to turn expectations into practical controls.
- Use Software Component and Vulnerability Management and Secure Updates and Lifecycle Monitoring to identify evidence for SBOM, dependency, update, and vulnerability work.
- Use SBOM, VEX, and Component Visibility, Signing, Keys, and Credentials, Secure Update and Recovery Mechanisms, and Evidence Exchange and Verifier Workflows for implementation mechanisms.
- Use Supplier Security Questions and the Evidence Checklist when turning CRA-driven needs into supplier or audit requests.