---
title: "CRA SBOM and Vulnerability Management Template"
canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template"
source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template"
author: "Sorena AI"
description: "Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields."
published_at: "2026-03-04"
updated_at: "2026-05-25"
keywords:
  - "CRA SBOM"
  - "CRA vulnerability handling"
  - "Cyber Resilience Act vulnerability management"
  - "CRA technical documentation"
  - "Cyber Resilience Act"
  - "Product security"
  - "Products with digital elements"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# CRA SBOM and Vulnerability Management Template

Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.

*Template* *EU CRA*

## CRA SBOM and vulnerability handling template

A field-level template for recording components, vulnerability decisions, security updates, disclosure work, and technical documentation evidence under the EU Cyber Resilience Act.

Use it to connect engineering vulnerability work to CRA Annex I Part II, Article 13, Article 14, and Annex VII evidence without treating the SBOM as a public-format checklist.

The CRA makes component awareness part of vulnerability handling. Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. Annex VII also places the SBOM, vulnerability handling process, disclosure policy, reporting contact, and secure update mechanism inside the technical documentation framework. This template is designed for the working record behind those obligations.

## Template section 1: product and release scope

Start each SBOM and vulnerability record by fixing the exact product version it applies to. CRA technical documentation must identify the product, software versions affecting compliance, support-period information, and the vulnerability handling process.

Do not use one generic SBOM label for every build. Exposure, remediation, and user advisory decisions depend on the released version, supported branch, and update channel.

- Product name, model, product family, hardware variant, software branch, version, build identifier, and release date
- Intended purpose, deployment assumptions, remote data processing solution notes, and integrations that affect cybersecurity risk
- Support-period end date or support-period determination record linked to the user information and technical documentation
- Release status: pre-market, placed on the market, supported, latest substantially modified version, archived, or unsupported
- Technical documentation links: cybersecurity risk assessment, test reports, EU declaration of conformity, user instructions, and conformity assessment record

## Template section 2: SBOM and component record

The CRA requires an SBOM in a commonly used, machine-readable format and says it must cover at least top-level dependencies. The law does not name CycloneDX, SPDX, or another specific public format in the source material used for this page, so keep the template format-neutral unless a later implementing act or your conformity route requires more.

The useful operational record is broader than a dependency export. It should show why each integrated component does or does not affect the product's CRA risk assessment, vulnerability exposure, and update path.

- Component name, type, supplier or maintainer, repository or supplier reference, version, hash or package identifier, license, provenance, and integration path
- Classification: first-party code, third-party commercial component, free and open-source component, hardware component, firmware, library, container image, remote data processing solution, or external dependency
- Depth marker: top-level dependency, transitive dependency tracked for risk reasons, embedded component, build-time tool, or excluded non-runtime dependency with rationale
- Security status: supported, unsupported, end-of-life date if known, known vulnerability references, exploitability in this product, and compensating controls
- Due-diligence evidence: CE marking or supplier conformity information where available, update history, vulnerability database checks, security test results, supplier security contact, and acceptance or replacement decision

*Recommended next step*

*Placement: after the template section that defines SBOM fields*

## Connect dependency evidence to CRA vulnerability handling

SSOT can keep component records, vulnerability triage, Article 14 checks, advisories, update evidence, and technical documentation links in one governed workflow.

- [Open SSOT for CRA evidence](/solutions/ssot.md): Track component inventory, vulnerability decisions, disclosure status, update evidence, and technical-file links in one governed system.
- [Review CRA vulnerability handling](/contact.md): Check whether your SBOM, CVD policy, vulnerability triage, update process, and technical documentation evidence are connected.

## Template section 3: vulnerability intake and Article 14 trigger check

Every vulnerability record should separate intake facts from legal-reporting conclusions. The CRA vulnerability handling duty applies broadly during the support period, while mandatory Article 14 reporting is triggered only for actively exploited vulnerabilities in the product and severe incidents affecting product security.

Record the awareness basis. The Commission FAQ explains that mandatory reporting is not triggered merely because a flaw exists or is found in good-faith testing without reliable evidence of malicious exploitation.

- Report source: researcher, customer, supplier, component maintainer, internal test, telemetry, threat intelligence, bug bounty, CSIRT, or market surveillance authority
- Received timestamp, triage timestamp, awareness timestamp, confidence level, and evidence supporting or rejecting active exploitation
- Affected products, supported versions, affected components, exposure conditions, default configuration impact, and user populations affected
- Initial Article 14 classification: actively exploited vulnerability, severe incident, voluntary-report candidate, user-notification issue, or no reporting trigger with rationale
- Escalation links: CSIRT or ENISA submission identifiers where applicable, internal incident record, vulnerability advisory draft, and authority correspondence

## Template section 4: remediation, update, and validation evidence

Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed, including through security updates, and to apply effective and regular security tests and reviews. The template should therefore track the chosen remedy and the evidence that it worked.

Avoid hard-coded severity-to-deadline tables unless they are based on your own policy and risk assessment. The CRA source material supports a risk-based remedy path, not one universal patch deadline for all vulnerabilities.

- Risk assessment summary, severity, exploitability, safety or business impact, affected security property, and reason for the chosen remedy
- Remedy type: patch, configuration mitigation, workaround, feature disablement, component replacement, autonomous fix, supplier fix, documentation change, withdrawal, or recall assessment
- Fix owner, approving owner, target release vehicle, security update identifier, package signature or integrity evidence, and rollout channel
- Validation evidence: regression tests, security test results, component scan after fix, build provenance, update installation checks, and residual-risk acceptance
- Update availability record showing each security update made available during the support period and how users can still access it for the CRA-required availability period

## Template section 5: coordinated disclosure and component coordination

Annex I Part II requires a coordinated vulnerability disclosure policy, a reporting contact, and measures to facilitate sharing of information about vulnerabilities, including vulnerabilities in third-party components contained in the product. ENISA's vulnerability disclosure material also describes CVD as a multi-party process that coordinates reporting, fixing, mitigation, and public disclosure.

For integrated components, the finished-product manufacturer still has to handle the vulnerability in the finished product. If the component maintainer cannot fix it, the record should show the product-level alternative.

- Public reporting contact, coordinated vulnerability disclosure policy URL, reporter handling status, safe-harbor or non-prosecution statement if used, and acknowledgement trail
- Upstream maintainer or supplier notified, notification date, maintainer response, embargo or coordination window, and shared fix or documentation where applicable
- Downstream user notice plan, impacted-user list, customer support script, advisory owner, and publication approval
- Fixed-vulnerability disclosure content: affected product, vulnerability description, impact, severity, remediation steps, update availability, and any justified publication delay
- Component fallback decision: wait for upstream, replace component, patch internally, disable function, isolate exposure, or retire the affected branch

## Template section 6: technical documentation and retention links

The SBOM and vulnerability template should not sit apart from the CRA technical file. Annex VII expressly includes the SBOM where applicable, the vulnerability handling process, coordinated disclosure policy, evidence of the reporting contact, and the technical solutions chosen for secure update distribution.

Keep confidential technical documentation separate from public advisories. The CRA does not generally require public release of the technical documentation or SBOM, although users must receive required user information and may be given SBOM access if the manufacturer chooses to make it available.

- Technical documentation section where the SBOM, vulnerability handling process, disclosure policy, reporting contact, and secure update mechanism are stored
- Cybersecurity risk assessment update needed: yes, no, or already updated, with reason and approver
- User-facing artifacts updated: advisory, release notes, installation instructions, secure deployment guidance, end-of-support notice, or update archive notice
- Authority-facing artifacts: Article 14 reports, intermediate status updates, final report, market surveillance authority request response, and reasoned-request SBOM export
- Retention rule for records forming part of the technical documentation or declaration of conformity: keep available to authorities for at least 10 years after placing on the market or for the support period, whichever is longer

## Primary sources

- [Regulation (EU) 2024/2847, Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Grounds the SBOM, vulnerability handling, coordinated disclosure, update distribution, user information, technical documentation, and record-retention fields used in the template.
  - Quote: "software bill of materials in a commonly used and machine-readable format"
- [European Commission CRA FAQs, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Supports the risk-based vulnerability handling approach, integrated-component handling, Article 14 trigger interpretation, and technical documentation clarifications.
  - Quote: "manufacturers shall, in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay"
- [ENISA Vulnerability Disclosure](https://www.enisa.europa.eu/topics/vulnerability-disclosure?ref=sorena.io) - Supports the coordinated vulnerability disclosure process fields for reporting, fixing, mitigation, multi-party coordination, and public disclosure after a fix or mitigation is ready.
  - Quote: "Coordinated Vulnerability Disclosure is crucial for protecting users"

## Related Topic Guides

- [CRA Applicability Test for Products With Digital Elements](/artifacts/eu/cyber-resilience-act/applicability-test.md): Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.
- [CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence.
- [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions.
- [CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.
- [CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.
- [CRA Conformity Assessment and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.
- [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route.
- [CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.
- [CRA deadlines and compliance calendar | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.
- [CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties.
- [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.
- [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.
- [CRA Essential Cybersecurity Requirements in Annex I](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): An official source guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence.
- [CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.
- [CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.
- [CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.
- [CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.
- [CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.
- [CRA Known Exploitable Vulnerabilities at Launch FAQ](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.
- [CRA Legacy Products FAQ | Pre-11 December 2027 Products](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records.
- [CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls.
- [CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.
- [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes.
- [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.
- [CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work.
- [CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.
- [CRA Over-the-Air Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.
- [CRA penalties and fines FAQ | Article 64 fine caps](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs.
- [CRA Penalties and Fines: Article 64 Caps and Enforcement Context](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches.
- [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.
- [CRA Products with Digital Elements Scope | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.
- [CRA Products With Digital Elements Scope FAQ](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries.
- [CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information.
- [CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence.
- [CRA Requirements | Annex I, Manufacturer Duties and CE Evidence](/artifacts/eu/cyber-resilience-act/requirements.md): Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.
- [CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.
- [CRA Security Updates vs Functionality Updates FAQ](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.
- [CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties.
- [CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information](/artifacts/eu/cyber-resilience-act/faq/support-period.md): Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence.
- [CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document.
- [CRA Technical Documentation FAQ | Annex VII Evidence and Technical File](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.
- [CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.
- [CRA Update Availability and Software Archives FAQ](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.
- [CRA User Information and Transparency FAQ | Annex II Instructions](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.
- [CRA vs RED Cybersecurity Delegated Act](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.
- [CRA vs UK PSTI Act | Cyber Resilience Act Comparison](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare cited EU Cyber Resilience Act duties with UK PSTI planning points, with UK legal details clearly marked for separate source review.
- [CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.
- [CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.
- [Cyber Resilience Act Module A FAQ | Internal Production Control](/artifacts/eu/cyber-resilience-act/faq/module-a.md): FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires.
- [EU CRA Compliance Program for Manufacturers and Economic Operators](/artifacts/eu/cyber-resilience-act/compliance.md): Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.
- [EU Cyber Resilience Act Checklist for Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence.
- [EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.
- [EU Cyber Resilience Act FAQ](/artifacts/eu/cyber-resilience-act/faq.md): Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.
- [EU Cyber Resilience Act Repairs and Spare Parts FAQ](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.
- [EU Cyber Resilience Act Technical Documentation and Audit File](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template