EU CRA HowTo: A Practical Readiness Playbook for Software Vendors​

The EU Cyber Resilience Act (CRA) is no longer a future rumor - it’s law, and the timelines are set.

If you build, import, or distribute products with digital elements in the EU, the CRA will change how you design software, how you ship it, and how you operate it over its lifetime. It introduces clear obligations around security-by-design, SBOM transparency, vulnerability handling, incident reporting, and technical documentation.

In this article, I’ll walk through:

• the official CRA timeline,
• what the law actually expects from you,
• how product risk classes work,
• and a practical roadmap you can start implementing right now.

No legalese. Just what you need to know now to be ready before 2027.

1. CRA Timelines: What Happens When?

Let’s start with the dates that matter.

The CRA follows a staged rollout:

The key takeaways - there are two critical milestones ahead:

• From September 2026, you must be able to detect and report serious issues within 24 hours.
• From December 2027, no new product can go on the EU market without being CRA-compliant. And non-compliance can mean potentially blocked market access and quite significant fines.

So the question is not “Will we be affected?”

The question is “How ready will we be and how fast?”

2. What the CRA Actually Wants from You

The CRA targets products with digital elements - essentially any hardware or software that uses digital data processing and can connect to a network.

It bundles the requirements into four big buckets:

A) Product Security Requirements

You must ensure an appropriate cybersecurity level based on a risk assessment of the product. In practice, this means:

Security-by-Design

Security is part of design, development and production – not a bolt-on after GA.

Security-by-Default

The product ships in a secure configuration:

• No default passwords
• Least-privilege roles
• Hardened defaults
• Minimal attack surface (only necessary ports/services)

CIA by architecture

The product must be designed to protect:

• Confidentiality
• Integrity
• Availability

B) Handling of Vulnerabilities

You must have a structured vulnerability management process, including:

• Receiving vulnerability reports (Coordinated Vulnerability Disclosure)
• Performing regular security testing (including pentests where needed)
• Assessing and treating vulnerabilities appropriately Providing free security updates for a defined support period
• Publishing information about vulnerabilities and their remediation

From September 2026 onwards, actively exploited vulnerabilities and significant security incidents must be reported within 24 hours to national authorities and ENISA.

C) Third-Party Components & Supply Chain

The CRA explicitly pushes you to get your software supply chain under control:

• Maintain a Software Bill of Materials (SBOM) that records third-party components
• Exercise due care when using third-party/OSS components
• Track and forward potential vulnerabilities to upstream suppliers
• Ensure your supply chain is not a blind spot In other words: no more “we don’t know what’s inside”.

D) Minimum Information for Users

Manufacturers must provide essential information to users, including:

• Product identification (type, version, etc.)
• Intended use
• A contact point for security issues
• Access to the EU declaration of conformity
• And – if an SBOM exists – controlled access for authorized actors

3. CRA Product Risk Classes – Where Does Your Product Fit?

The CRA differentiates between different product categories. Very simplified:

Standard Products

Examples:

• consumer apps,
• tax/office software,
• basic consumer IoT (vacuum robots, trackers).

Requirements:

• baseline cybersecurity requirements,
• risk assessment,
• secure development & updates,
• CE marking often via self-declaration.

“Important” Products (Class I)

Examples:

• identity and access management systems,
• privileged access management,
• browsers, password managers, VPNs,
• operating systems, routers, switches,
• smart locks, cameras, baby monitors, smart assistants.

Requirements:

• all baseline requirements,
• explicit security-by-design & security-by-default,
• lifecycle risk management,
• mandatory vulnerability handling & support,
• technical documentation, CE marking.

“Critical” Products (Class II and certain hardware)

Examples:

• hypervisors, container runtimes, IDS/IPS,
• hardware security modules, certain crypto devices,
• smart meter gateways, secure elements, chipcards.

Requirements:

• everything above, plus
• third-party conformity assessment (Notified Body),
• penetration testing and extensive audits,
• strict supervisory oversight.

For most SaaS and enterprise software vendors, you’ll land in Standard or Class I.

If you’re running infrastructure, security products, or crypto-intensive systems, assume Class II until proven otherwise.

4. What You Must Do in Each Phase of the Product Lifecycle

The CRA maps nicely onto the real software lifecycle: design → development → deployment → maintenance.

Let’s translate the legal language into concrete actions.

Phase 1: Design & Architecture

Goal: ensure security is built into the product concept.

You should:

• Perform a product-specific risk assessment:
  • What could realistically go wrong?
  • What’s the impact if it does?
• Make cybersecurity a design constraint:
  • authentication/authorization model
  • network exposure & segmentation
  • encryption choices
  • update mechanism
  • logging & monitoring
• Define secure defaults:
  • default roles
  • default configs
  • which features are enabled/disabled out of the box

A simple test: if you took your architecture diagram to a regulator or a critical customer - could you explain how security is embedded, not just added?

Phase 2: Development & Build

Goal: make secure development and SBOM generation part of your normal delivery pipeline.

You should:

• Integrate a secure development lifecycle:
  • threat modeling for critical components
  • code reviews with security criteria
  • SAST/SCA/DAST where meaningful
  • secure coding guidelines and training
• Treat SBOMs as first-class build artefacts:
  • generate SBOMs in CI/CD, not manually
  • standardize on one or two formats (e.g. CycloneDX, SPDX)
  • store SBOMs centrally, with version history
• Enforce SBOM quality gates:
  • no missing component metadata for core modules
  • no introduction of banned/unsupported components
  • flag releases that include known-critical vulnerabilities or EOL libraries

At this point, “we can’t generate SBOMs” is not a technical limitation - it’s a strategic decision. Under CRA, it’s the wrong one.

Phase 3: Conformity Assessment & CE Marking

Goal: prove that the product meets CRA requirements before it hits the EU market.

You should:

• Build a technical documentation package per product:
  • architecture & risk assessment
  • description of security controls
  • SBOMs and component history
  • results of security tests
  • vulnerability management and update processes
• Prepare your EU declaration of conformity:
  • mapping CRA requirements to your controls and evidence
• For higher-risk classes, prepare for external conformity assessment:
  • engage with a notified body in time
  • understand their expectations on penetration tests and documentation

Think of this as your “CRA audit pack”. If a regulator or major customer asks, you should be able to hand over a coherent, up-to-date document package including the SBOM, not a loose folder of PDFs.

Phase 4: Maintenance & Support (Minimum 5 Years)

Goal: keep the product secure and supported over its actual lifetime.

You should:

• Commit to a support window:
  • typically at least 5 years
  • shorter or longer if the expected lifetime clearly differs
• Continuously monitor for vulnerabilities:
  • map new CVEs against your SBOMs
  • prioritize based on exploitability and impact
  • track remediation SLAs
• Provide free security updates:
  • without unreasonable friction for users
  • with clear release notes and security information
• Maintain an incident & reporting process:
  • from September 2026: report actively exploited vulnerabilities and serious incidents
  • within 24 hours of becoming aware
  • cooperate with national authorities and ENISA
  • keep documentation of actions taken

SBOMs are crucial here: without them, impact analysis turns into guesswork.

5. What Exactly Has to Be Reported - And How Fast?

Once the reporting obligations kick in (11 September 2026), the CRA expects you to report:

• Actively exploited vulnerabilities
• Security incidents that threaten the security of your product
• Vulnerabilities that may cause significant risk if left unaddressed

The bar is deliberately high: this isn’t about every minor bug. It’s about issues that genuinely matter from a security and resilience standpoint.

You must:

• Report immediately, and at the latest within 24 hours of becoming aware
• Report to the competent national authority (e.g., BSI in Germany), which then forwards to ENISA
• Provide:
  • a description of the vulnerability or incident
  • affected products and versions
  • risk assessment
  • actions taken and planned (updates, mitigations)

If your internal processes can’t produce this information quickly, that’s a warning sign.

6. What the CRA Really Means for SBOMs

CRA as a Turning Point for SBOMs

For many organizations, the CRA will be the turning point where SBOMs stop being “something security keeps talking about” and become core technical documentation.

In practice, CRA pushes you to:

• Maintain SBOMs for all CRA-in-scope products
• Use them as a basis for vulnerability and license risk analysis
• Plug them into your incident response and reporting flow
• Provide controlled access to SBOM data for the right stakeholders
• Keep a historical record of all your releases and SBOMs

Crucially: this is not about publishing your entire SBOM to everyone. It’s about:

• Knowing exactly what you ship
• Being able to prove it
• Being able to respond quickly when something breaks in your supply chain

If you have a platform that can:

• Ingest SBOMs from CI/CD and suppliers
• Centrally store and version them
• Enrich them with vulnerabilities, licenses and provenance
• Enable controlled sharing (with ABAC, redaction and audit trails)

…then you’re not just CRA-ready - you’re also in a good position for other regulations (if they’re affecting you as well) like NIS2, DORA, and sector-specific rules around software supply chain security.

7. A 90-Day CRA Readiness Blueprint

You don’t need a massive program to start. You need a focused push.

Here’s a realistic 90-day blueprint:

Month 1 - Scope & Ownership

• Identify which of your products are CRA in scope
• Classify them roughly (Standard, Important, Critical)
• Assign clear SBOM ownership per product line
• Document your secure development practices (even if you improve them later)

Month 2 - SBOM & Vulnerability Pipeline

• Integrate SBOM generation into your CI/CD pipelines for at least 1–2 flagship products
• Stand up a central SBOM repository with versioning and immutable logs
• Connect vulnerability data to your SBOMs
• Define and enforce basic SBOM quality gates

Month 3 - Documentation & Incident Simulation

• Create a technical documentation template per product
• Draft your CRA-aligned declaration of conformity outline
• Define your 24-hour reporting process (who triggers, who writes, who sends)
• Run a full table-top exercise:
  • CVE appears in a widely used component
  • Walk through: where are we affected, how do we respond, how do we report?

You won’t be “done” after 90 days. But you’ll have a working skeleton that you can harden and scale.

8. CRA as an Accelerator, Not Just a Burden

The CRA is often framed as a pure compliance burden. I see it differently. It’s a forcing function that pushes the industry towards:

• Transparent software supply chains
• Real security-by-design instead of slogans
• Structured vulnerability and incident handling
• A level of documentation that finally matches the reality of software risk

The organizations that start early will discover something interesting: The exact same capabilities that make them CRA-compliant also make them faster during incidents, stronger in enterprise sales cycles, and more trustworthy to regulators and critical customers.

If you want to go deeper into how to build SBOM-driven CRA readiness - from CI/CD integration to controlled sharing with customers and authorities - that’s exactly the space we’re building in at Exodos Labs.