cra-vulnerability-obligations

Overview

The EU Cyber Resilience Act (CRA) sets binding cybersecurity requirements for products with digital elements sold in the EU: secure-by-design development, vulnerability handling with coordinated disclosure, SBOM provision, and security support for the product lifecycle. It shifts product security from best practice to legal obligation, with significant penalties.

This skill is a defensive compliance guide for product teams: understanding the obligations, building the vulnerability-handling machinery, and evidencing conformity. It is practical guidance, not legal advice — involve counsel for applicability and interpretation.

Start from the product lifecycle, not the legal text: the CRA rewards what good product-security teams already do — threat modeling, secure development, vulnerability disclosure programs, SBOMs, and timely patching. Map your existing practices to the obligations first; the gaps you find are the actual work program.

When to use

• Determining CRA applicability for your products (scope, timelines, product categories).
• Building coordinated vulnerability disclosure (CVD) processes to meet CRA duties.
• Producing SBOMs and security documentation for products.
• Defining security support periods and update policies.
• Preparing conformity assessment evidence.

Core concepts

• Scope and timelines. The CRA covers products with digital elements placed on the EU market, with obligations phasing in (vulnerability reporting duties apply from September 2026; full application later). Confirm your product category and timeline with counsel — dates and categories matter.

• Essential cybersecurity requirements. Secure-by-default configuration, protection against unauthorized access, data confidentiality/integrity, vulnerability-free-by-design development, and automatic security updates where applicable.

• Coordinated vulnerability disclosure. Manufacturers must have a CVD policy: a public contact point, defined timelines for acknowledging and addressing reports, and processes feeding fixes into updates. This overlaps heavily with running a disclosure/bounty program.

• Vulnerability reporting duties. Actively exploited vulnerabilities and severe incidents must be reported to ENISA/CSIRTs within defined timeframes (early notification within 24 hours for actively exploited issues, with follow-ups). Build the detection-to-report pipeline before you need it.

• SBOM obligations. Provide SBOMs to market-surveillance authorities on request (and consider customer provision) in standard formats — the same SBOM practice as dependency-scanner, now with regulatory weight.

• Security support period. Define and communicate how long a product receives security updates (minimum expectations apply); end-of-support needs a clear, communicated plan.

• Conformity assessment. Depending on product category: self-assessment, EU-type examination, or full quality-assurance — with technical documentation evidencing the security properties and processes.

• Supply-chain duties. Manufacturers must consider third-party component vulnerabilities — your dependency-management program becomes compliance evidence.

• Vulnerability severity triage for reporting. Not every CVE is reportable — build the severity-and-exploitability triage that distinguishes routine patching from reportable events, with legal in the loop.

• Market surveillance readiness. Authorities can request documentation and SBOMs; maintain a ready package per product rather than assembling under request deadlines.

Practical workflow

1. Scope with counsel: confirm which products are in scope, their categories, and applicable timelines. Document the applicability analysis — it is the foundation of everything else.
2. Map existing practices: threat modeling, secure SDLC, disclosure handling, SBOM generation, patching cadence — map each to CRA requirements and identify genuine gaps.
3. Build CVD operations: public security contact, intake and triage process with defined SLAs, researcher communication standards, and the fix-to-update pipeline. Test it with a dry run.
4. Stand up reporting capability: define what counts as reportable (actively exploited vuln, severe incident), who decides, the 24-hour notification workflow, and the evidence package. Involve legal in the decision chain.
5. Produce product documentation: SBOMs per release, security update policy and support periods, secure-configuration guidance for users, and the technical file supporting conformity assessment.
6. Maintain the lifecycle: monitor components for new CVEs, ship security updates within committed windows, track support-period commitments, and review conformity evidence on each major release.

Quick wins

• Confirm product applicability and timelines with counsel this quarter
• Publish a security contact and stand up CVD intake with triage SLAs
• Generate SBOMs for current releases and validate their completeness

Sustaining the practice

• Review applicability whenever products or categories change
• Test the vulnerability-reporting workflow with tabletop exercises
• Audit SBOM completeness per release; automate generation in the pipeline
• Track regulatory guidance evolution — CRA interpretation is still maturing

Metrics that prove it works

• CVD intake-to-acknowledgement and intake-to-fix times
• % of releases with complete SBOMs and documentation
• Security update delivery within committed windows
• Conformity evidence completeness per product

Common pitfalls

• Assuming it does not apply. "We're not a security company" is irrelevant — the CRA covers products with digital elements broadly. Get a proper applicability analysis.
• No 24-hour reporting capability. The early-notification clock starts when you know. Without a pre-built decision chain and evidence package, you will miss it.
• CVD policy as a web page. A security.txt file without triage staff, SLAs, and a fix pipeline is not a disclosure program. Operate it.
• SBOMs nobody can produce. Generating SBOMs for the first time under regulatory pressure is painful. Build generation into the pipeline now.
• Undefined support periods. Vague "we update as needed" commitments fail the support-period obligation. Define, publish, and honor them.
• Treating it as a legal checkbox. The CRA's technical requirements reward genuine product-security maturity. Checkbox compliance without the engineering will fail conformity scrutiny.
• Ignoring the supply chain. Third-party component vulnerabilities are your reporting duty too. Your SCA program is now compliance infrastructure.
• Stale interpretation. CRA guidance and standards are evolving. Assign ownership for tracking regulatory developments, not just initial compliance.
• Confusing CE marking with security. Conformity processes assess documented processes and evidence — they do not make the product secure. Build the engineering, not just the file.
• Underestimating update infrastructure. The CRA's update obligations require reliable, secure update delivery — including for products that never had it. Budget the engineering.