What Is the CRA? A Complete Guide to the EU Cyber Resilience Act

The short answer
The CRA (Cyber Resilience Act) is the EU regulation requiring that every digital product sold in the EU is secure from design through end of support. It applies wherever the company is based — if the product is sold in the EU, the CRA applies.

Key takeaways

• Regulation (EU) 2024/2847 entered into force on December 10, 2024.
• It covers "products with digital elements": hardware, software and firmware that connect to a network or another device — including standalone software.
• Since September 11, 2026, vulnerability and incident reporting obligations apply, including to products already on the market.
• Full application begins on December 11, 2027. Products must meet all requirements and carry CE marking to be sold in the EU.
• Fines reach up to €15 million or 2.5% of global annual turnover, whichever is higher.
• The CRA isn't a one-time certification. It's an obligation that runs for the product's entire support period.

What is the CRA?

The CRA is the EU's first horizontal cybersecurity law aimed at products themselves. Earlier EU cybersecurity laws such as NIS2 mostly regulate organizations — requiring companies to protect their own systems. The CRA regulates what manufacturers sell.

The EU introduced the CRA to address two problems:

1. Many connected products have weak security, and they stop receiving updates soon after sale.
2. Buyers can't tell whether a product is secure — there's little transparency.

So the CRA puts responsibility on the manufacturer: consider security at design time, ship without known exploitable vulnerabilities, provide security updates throughout the support period, and tell users clearly how long that support will last.

Who must comply?

Three roles

Anyone who sells a product under their own brand, or substantially modifies it, is treated as the manufacturer. In OEM/ODM arrangements, whoever places the product on the EU market under their name and controls the product carries manufacturer obligations — make sure contracts say so.

Is my product in scope? Three questions

1. Is it a hardware, software or firmware product? (Standalone software counts.)
2. Is it made available on the EU market? (Paid or free.)
3. Does its intended use include a data connection? Direct or indirect, physical or logical. USB, Bluetooth, serial ports, APIs, and firmware updates via a computer all count.

If the answer to all three is yes, it's in scope.

What about cloud services? A useful test: if you switched off the cloud service, could your hardware still perform its advertised core function? If not, the cloud service is part of the product's "remote data processing," and the manufacturer is responsible for it too.

What's out of scope

Non-commercial open-source software, pure SaaS (covered by NIS2 instead), medical devices, aviation equipment, motor vehicles, products developed exclusively for defense or national security, and marine equipment — these are covered by their own sector rules.

How products are classified

The CRA sorts products into four classes by cybersecurity importance. The class decides whether you can self-assess or need a third party:

Classification depends on the product's core functionality, not its name or marketing.

Core requirements

Annex I of the CRA sets out requirements in two parts.

Part I: product security requirements (examples)

• Secure by default, with the ability to reset to the original state
• Protection against unauthorized access (authentication, access control)
• Confidentiality and integrity of data (encryption)
• Minimal attack surface, with unnecessary interfaces disabled
• Recording and monitoring of security-relevant activity
• Secure deletion of user data
• No known exploitable vulnerabilities at the time of release
• Automatic security updates where feasible, with an opt-out

Part II: vulnerability handling requirements

• Create and maintain a software bill of materials (SBOM)
• Fix vulnerabilities promptly and provide free security updates
• Test product security regularly
• Establish and publish a coordinated vulnerability disclosure policy
• Provide a contact point for reporting vulnerabilities
• Publish information about vulnerabilities once fixed

What is an SBOM?

An SBOM (software bill of materials) is a product's "ingredients list": the software components it contains and their versions. The CRA requires that it:

• Uses a machine-readable format (typically SPDX or CycloneDX)
• Covers at least the top-level dependencies
• Is updated with each release
• Is provided to market surveillance authorities on request — it doesn't have to be published

Technical documentation and support period

Manufacturers must prepare technical documentation (product description, risk assessment, test results, proof of conformity, records of updates and vulnerability handling) and keep it for 10 years or the support period, whichever is longer. The support period — how long security updates will be provided — must be clearly communicated to users.

Reporting: 24 hours, 72 hours, 14 days

Since September 11, 2026, manufacturers must report when they become aware of:

1. An actively exploited vulnerability in their product
2. A severe incident affecting the product's security

Reports go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator in the member state of the manufacturer's main establishment. Manufacturers must also inform affected users.

Note: reporting obligations apply to every product on the EU market, including products placed on the market before 2027.

Timeline

As of October 2026, CRA harmonized standards are still being drafted. The European Commission published practical guidance in July 2026, and ENISA released a cyber resilience maturity assessment model for SMEs.

Penalties

Authorities can also order products withdrawn or recalled.

How to prepare for the CRA: five stages

1. Inventory your products: list every product and version sold in the EU, decide whether each is in scope and which class it falls into. Output: product list and classification.
2. Run a gap analysis: compare current practice against the Annex I product and vulnerability-handling requirements. Output: gap analysis.
3. Build a secure development process and SBOMs: embed security in development, generate an SBOM for each release and monitor components for vulnerabilities. Output: development procedure, SBOMs.
4. Set up vulnerability handling and reporting: establish a product security incident response team (PSIRT), a disclosure policy and reporting templates, and identify your coordinating CSIRT. Output: vulnerability handling procedure, reporting process.
5. Prepare technical documentation and conformity assessment: compile the technical file, choose the assessment module, sign the EU declaration of conformity and affix CE marking. Output: technical documentation, declaration of conformity.

Start with these (you can begin today)

• Form a cross-functional team (R&D, QA, legal, customer support)
• Confirm which products are sold in the EU and in which countries
• Confirm your reporting process — the obligation is already live
• Pilot an SBOM for one product
• Inventory your existing security documentation and evidence to see what you can reuse

Common mistakes

• "It only covers hardware." Standalone software, firmware and apps all count.
• "We don't need to act until 2027." Reporting obligations started in September 2026 and apply to existing products too.
• Treating the CRA as a one-time certification. Throughout the support period you must keep handling vulnerabilities, updating SBOMs and shipping security updates.
• "Our cloud features are separate." If the product can't work without the cloud service, the cloud service is in scope.
• Forming a team only after an incident. Without a prepared process, a 24-hour deadline is almost impossible to meet.

How the CRA relates to other rules

Read more: What is ISO 27001, What is SEMI E187

How Guidant AI helps

The CRA asks for records — and evidence — across the entire product lifecycle. Guidant AI turns those requirements into work you can divide up and track.

• CRA compliance framework: Annex I and Annex II requirements organized as controls, each with suggested evidence, ready to start a project.
• Product and version inventory: register each product, version and support period, with reminders as support end dates approach.
• Tasks and evidence: assign each requirement to R&D, QA or legal, with evidence attached to the matching item.
• SBOM and component vulnerability scanning: upload source code or an SBOM to get standard-format SBOMs and vulnerability reports, with scheduled rescans.
• Internal audit and remediation: run an internal check well before 2027; findings flow straight into a remediation plan.

We also use Guidant AI to run a CRA self-assessment of our own product — much of what's in this guide comes from that experience.

Guidant AI is not a notified body and does not issue CE marking or proof of conformity.

[Book a demo →]

See how Guidant AI maps to it →

FAQ