Elevate

EU Cyber Resilience Act (CRA) Readiness

Build secure-by-design product security and audit-ready evidence to meet the Cyber Resilience Act requirements for products sold in the EU.

CRA readiness assessment + gap remediation mapped to Annex I essential requirements  

SBOM + technical documentation built for conformity, market surveillance, and speed-to-market  

Vulnerability handling + reporting readiness (24h / 72h / 14d) operationalized with clear runbooks   

What the CRA is (and what it changes)

The Cyber Resilience Act (CRA) is an EU regulation establishing horizontal cybersecurity requirements for “products with digital elements” software or hardware, including their remote data processing solutions, and components sold separately.
CRA’s core shift: cybersecurity becomes a market access requirement. Manufacturers must demonstrate that products are designed, developed, and produced to meet an appropriate level of cybersecurity based on risk, and maintain vulnerability handling throughout a defined support period.
CRA timeline (dates you can plan to)

We’re currently in the CRA transition window.

In force: 10 December 2024  

Conformity assessment ecosystem milestone: 11 June 2026 ​

Reporting obligations start: 11 September 2026

Full CRA obligations apply: 11 December 2027

What this means right now (2026)  

If you sell (or plan to sell) products with digital elements in the EU, 2026 is the year to operationalize reporting readiness. Focus on: vulnerability handling workflows, triage + escalation, evidence capture, and CRA reporting runbooks ahead of 11 September 2026.

Who CRA applies to

CRA obligations apply across the supply chain, including:

• Manufacturers (primary obligations)

• Authorized representatives

• Importers

• Distributors

There are also CRA-specific rules for open-source software stewards (certain legal entities supporting FOSS intended for commercial activities), with obligations such as having a cybersecurity policy and vulnerability handling—though they are not subject to penalties under CRA.

What “CRA-ready” means in practice

Essential cybersecurity requirements (Annex I)  
A CRA-ready product must be built and maintained to meet Annex I requirements. Examples include:
No known exploitable vulnerabilities at the time of placing on the market  
Secure-by-default configuration  
Security updates that address vulnerabilities (including update/notification expectations)   
Protection against unauthorized access (e.g., authentication / access control)  
Confidentiality + integrity protections (e.g., encryption, integrity controls) 
Data minimization aligned to intended purpose

Support period (this is often missed)

Manufacturers must determine and communicate a support period during which vulnerabilities are handled effectively, and they must clearly specify the end date (month/year) at purchase.   .

CRA further sets a baseline: the support period is at least 5 years, unless the product is expected to be used for less than 5 years (then it matches the expected use time).   

Reporting readiness (starting 11 Sep 2026)

Manufacturers must report actively exploited vulnerabilities and severe incidents impacting product security using CRA timelines:  

Early warning: within 24 hours  

Full notification: within 72 hours  

Final report: ≤14 days after a corrective/mitigating measure is available (for actively exploited vulnerabilities)  

Final report: within 1 month after the 72-hour notification (for severe incidents)

Reporting is submitted once through the CRA Single Reporting Platform, addressed to the relevant CSIRT, and information is made available to ENISA (with limited exceptions).   

Conformity assessment + CE marking

Most products can rely on self-assessment, but important and critical product categories (Annex III / Annex IV) have stricter routes and may require:

Applying harmonized standards, or  

Undergoing third-party assessment by a notified body (mandatory in some cases)   

How Elevate Consult supports CRA readiness

CRA Readiness Assessment (Scope → Gaps → Roadmap)

  • Confirm CRA applicability (including remote data processing scope)
  • Determine product category & likely conformity route (self vs third-party)
  • Map current state to Annex I/II/VII expectations and produce a prioritized remediation plan

Secure-by-Design Remediation (Evidence-led)

We turn “security goals” into verifiable controls and engineering artifacts:

  • Secure-by-default baselines and hardening requirements  
  • Access control, auth, and logging requirements  
  • Encryption and data handling requirements (confidentiality/integrity/data minimization)  
  • Update and patch governance aligned to CRA expectations   

SBOM + Supply Chain Evidence Pack

  • SBOM process design and integration into release pipelines  
  • component governance + vulnerability intake linkage  
  • “Audit-ready” evidence organization for technical documentation  

Vulnerability Handling Program (PSIRT / CVD)

  • Coordinated vulnerability disclosure (CVD) policy + workflow  
  • Intake → triage → fix → release → communicate  
  • Repeatable evidence capture (tickets, timelines, release notes, root cause)  

Reporting Readiness Playbooks (24h/72h/14d)

  • Escalation paths + decision tree (“is this reportable?”)  
  • Minimum viable data pack for early warning and full notification  
  • Tabletop exercise to validate readiness   

Notified Body Readiness (when applicable)

  • Technical documentation prep and traceability  
  • Pre-assessment support where third-party routes are required 

What you get (deliverables)

  • CRA Applicability & Scope Memo (including remote data processing boundaries)
  • Annex I / Annex II Requirements Matrix (with gap ratings + owners)
  • Cybersecurity Risk Assessment aligned to CRA expectations
  • Support Period Definition Pack (decision logic + user-facing end-date disclosure)
  • Vulnerability Handling Policy + PSIRT/CVD Procedures
  • CRA Reporting Runbooks + notification templates  
  • Technical Documentation Structure (what to collect, where it lives, how to keep it current)   

Engagement options

  • CRA Readiness Sprint (2–4 weeks): applicability, categorization, gap assessment, roadmap 
  • Implementation Support (co-sourced): remediation execution + evidence building 
  • Continuous Compliance: vulnerability handling operations + reporting readiness + audit support  

Why Elevate Consult

We build the evidence, technical documentation, and operating model regulators and market surveillance actually expect; not just a checklist.  
  • SBOM process design and integration into release pipelines  
  • component governance + vulnerability intake linkage  
  • “audit-ready” evidence organization for technical documentation  
We operationalize PSIRT/CVD workflows and reporting runbooks so you can meet CRA timelines with clarity, escalation paths, and repeatable proof.  
We help you implement SBOM governance that connects components, vulnerabilities, and releases—so your documentation and remediation are traceable end to end.  
We guide you through the right route (self-assessment vs. notified body readiness), organizing your technical file and controls evidence to reduce friction and delays.  
We map CRA readiness to existing security programs (ISO 27001, product security SDLC, NIST-aligned practices) to reduce duplicate work and accelerate compliance.  

FAQ

CRA is an EU regulation  stablishing cybersecurity requirements for products with digital elements and related supply-chain responsibilities so products are placed on the EU market with fewer vulnerabilities and stronger lifecycle security expectations.  

A product with digital elements is software or hardware, including its remote data processing solutions, and it also covers software/hardware components placed on the market separately.

Remote data processing refers to data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions.

Practical note: This can include API calls if the software cannot function without them.

 

CRA entered into force 10 Dec 2024. Reporting obligations apply from 11 Sep 2026, and the main obligations apply from 11 Dec 2027.
Manufacturers must define a support period during which they handle vulnerabilities effectively, and they must clearly state the end date (month/year) at the time of purchase. CRA sets a minimum support period of at least 5 years, unless the expected use time is shorter.   
From 11 Sep 2026, manufacturers must report actively exploited vulnerabilities and severe incidents: early warning within 24h, full notification within 72h, final report ≤14 days after a corrective measure is available (for actively exploited vulnerabilities), and within one month for severe incidents.   
Reporting is submitted through the CRA Single Reporting Platform to the relevant CSIRT, with information made available to ENISA, and shared across other CSIRTs where the product is made available (with limited exceptions).   

No. Many products can use self-assessment. However, important and critical products (Annex III/IV) have stricter routes—manufacturers may need to apply harmonized standards or undergo third-party conformity assessment via a notified body (mandatory in some cases).   

CRA requires products to be designed, developed, and produced to ensure cybersecurity based on risk, including secure-by-default configuration, update capability, controls against unauthorized access, and protections for confidentiality/integrity—among other Annex I requirements.   
Typically through technical documentation, a conformity assessment route (self or third-party), and the EU declaration of conformity/CE marking process. CRA also describes presumption of conformity when relevant harmonized European standards are used.
CRA clarifies scope around commercial activity and introduces obligations for certain open-source software stewards (e.g., having a cybersecurity policy and vulnerability handling), while also stating they are not subject to penalties for CRA infringements. CRA also includes specific notes on when some FOSS products can use self-assessment (e.g., important class I/II FOSS under certain conditions). 

Ready to Reduce CRA Exposure Before Reporting Goes Live?

Whether you’re preparing a new product for the EU market or upgrading an existing release, we’ll map CRA obligations to your product, operationalize vulnerability handling and reporting readiness, and build the technical documentation (including SBOM) that supports conformity and speeds enterprise due diligence.
Book a CRA Readiness Call