Understanding the EU Cyber Resilience Act (CRA): Complete Security-by-Design Compliance Handbook

The Cyber Resilience Act (CRA) is the European Union's most significant product security regulation since GDPR. Formally adopted as Regulation (EU) 2024/2847, the CRA establishes mandatory cybersecurity requirements for all products with digital elements sold in the EU market. Non-compliance carries penalties up to €15 million or 2.5% of global annual turnover, and products that fail conformity assessment lose EU market access entirely.

Unlike previous frameworks focused on organizational security practices, the EU CRA is product-centric. Every software product must prove security throughout its lifecycle to receive CE marking, which signifies that products sold in the EEA (European Economic Area) have been assessed to meet high safety, health, and environmental protection requirements. For security leaders, this regulation formalizes a long-standing principle: security must be considered at the design phase, not retrofitted after implementation. This guide explains what the CRA requires, who it affects, and how to build compliant practices.

Executive Summary

What the EU CRA Regulates

• All products with digital elements: standalone software, IoT devices, firmware, SDKs, and connected hardware
• Applies to any organization selling to EU customers, regardless of headquarters location
• SaaS products with downloadable components (browser extensions, SDKs, agents) are in scope

Key Compliance Dates

• September 2026: Mandatory vulnerability reporting to ENISA begins
• December 2027: Full compliance with all essential requirements

Security by Design is the Essential New Mandate

• The regulation requires documented evidence that security was addressed during “design and development”
• Traditional AppSec tools (SAST, SCA, DAST) operate after code exists and cannot satisfy this requirement
• This design-stage gap is unique to CRA; other regulations (NIS2, DORA, ISO 27001) do not require it

What Organizations Must Do

• Inventory and classify all products by CRA risk tier
• Implement design-stage security review with documented evidence
• Establish vulnerability handling and ENISA reporting processes
• Generate SBOMs and technical documentation for conformity assessment

What Is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act is an EU regulation setting mandatory cybersecurity requirements for all products with digital elements sold in the European market. Formally adopted as Regulation (EU) 2024/2847 and entering into force on December 10, 2024, the CRA represents the most far-reaching product security regulation the EU has enacted. It is product-centric, requiring every software product, from standalone applications to embedded firmware to SDK components, to prove security throughout its entire lifecycle, from initial design through end-of-life support.

Why Was the EU Cyber Resilience Act Introduced?

Product security failures have grown too consequential and too widespread for voluntary standards to fix. When connected devices reach hundreds of millions of households and businesses, a single architectural shortcut can cascade into infrastructure-level disruption. As shown by the October 2016 Dyn attack, attackers compromised over 600,000 IoT devices by exploiting factory-made usernames and passwords, leaving services like Twitter, Netflix, GitHub, and others unreachable for hours.

The vulnerability was not a coding error that testing would have caught but a product design decision. Although GDPR covers the handling of personal data and NIS2 covers critical infrastructure network security, neither imposes obligations on the manufacturers whose design choices created the attack surface in the first place. The CRA fills this gap by making secure-by-design a legal requirement at the point of manufacture, documented and auditable before products reach the market.

What Makes the EU CRA Different From Other Regulations?

The CRA differs from NIS2, DORA, and ISO 27001 in one key way: it regulates products, not organizations. While NIS2 requires essential service operators to implement security measures, and ISO 27001 certifies organizational security management systems, the CRA requires each individual product to meet specific security requirements and undergo conformity assessment before receiving CE marking for EU market access.

This product-level focus means compliance cannot be achieved through organizational policies alone. Each product requires documented evidence that security was considered and implemented throughout its development, starting at the design phase.

What are the Key Dates You Should Know?

The CRA follows a phased implementation timeline:

Why the September 2026 Deadline Matters:

While December 2027 is the full compliance deadline, September 2026 introduces mandatory vulnerability reporting. This means organizations need:

• Documented vulnerability handling processes
• Established reporting channels to ENISA
• Systems for detecting actively exploited vulnerabilities
• Evidence of ongoing security monitoring

For companies selling to EU customers, this provides an implementation window to build the practices that form the foundation of CRA compliance, including design-stage security reviews.

Penalties for Non-Compliance

The CRA establishes a tiered penalty structure based on violation severity:

Beyond financial penalties, non-compliance affects:

• CE marking eligibility and EU market access
• Product availability (potential withdrawal or recall requirements)
• Customer confidence in your security practices

Which Organizations Must Comply with the CRA?

The CRA specifically calls out four classifications of software providers:

1. Manufacturers

Organizations that design, build, or brand products bear primary responsibility for CRA compliance.

This includes:

• Software publishers selling to EU customers
• Hardware manufacturers with embedded software
• Companies that white-label or rebrand products
• Organizations that substantially modify existing products

2. Importers

Entities that bring products from outside the EU into the EU market must verify compliance before distribution.

3. Distributors

Entities in the supply chain that make products available.

4. Open Source Considerations

Open source software developed outside commercial activity is generally exempt.

However:

• Commercial products using open source components must ensure those components meet CRA requirements
• Any open source integrated into commercial products becomes the manufacturer's responsibility

Does the CRA apply to companies outside the EU?

Yes. The CRA applies to any entity that places products with digital elements on the EU market, regardless of where that organization is headquartered. Non-EU manufacturers must comply with all essential requirements to receive CE marking and maintain EU market access.

Which Products Are Impacted by the CRA?

The CRA applies to products with digital elements (PDEs), defined as any software or hardware product that connects directly or indirectly to a device or network. The scope is deliberately broad to cover the interconnected nature of modern digital products.

Products in Scope:

• Standalone software applications (desktop, mobile, and web applications with downloadable components)
• Operating systems and firmware
• IoT devices and connected hardware
• Software libraries, SDKs, and APIs distributed as components
• Industrial control systems and OT equipment
• Network equipment (routers, switches, firewalls)
• Consumer electronics with data connectivity

What about SaaS Products?

Pure SaaS offerings, where no software component is downloaded or installed, are generally excluded from the CRA's scope. However, most modern SaaS products include downloadable elements that bring them into scope:

• Browser extensions or plugins
• Desktop or mobile companion apps
• Agent software for integrations
• SDKs provided to customers
• CLI tools or development utilities

If your SaaS product includes any downloadable component, that component falls under CRA requirements, and the security of that component must be proven through design-stage practices.

How does CRA Classify Products and Risk Tiers?

The CRA establishes risk categories with corresponding compliance requirements:

What is required for CRA conformity assessment?

CRA conformity assessment requirements depend on product risk classification. Default (non-critical) products allow self-assessment. Important Class I products can self-assess with harmonized standards or use third-party assessment. Important Class II products require mandatory third-party assessment by notified bodies. Critical products require European cybersecurity certification.

What Are the Essential CRA Security Requirements?

The CRA's essential requirements are defined in Annex I of the regulation and are divided into two categories: security requirements for the product itself, and vulnerability handling requirements for ongoing support.

Part I: Security Requirements for Products

1. Security by Design

Products must be "designed, developed and produced" with appropriate cybersecurity levels based on risk assessment. This requires documented evidence that security was considered during architectural decisions, not added after implementation. The regulation states:

"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." (CRA Annex I, Section 1.1)

2. Secure Default Configuration

Products must ship with secure settings by default: least-privilege access, no default credentials, and hardened configurations aligned to intended use. Configurations that require user action to become secure do not meet this requirement.

3. Data Protection

Products must ensure confidentiality, integrity, and availability of data through appropriate mechanisms including encryption, access controls, and data minimization.

4. Resilience and Availability

Products must resist denial-of-service attacks and minimize negative impacts on other network resources.

5. Attack Surface Minimization

Products must minimize external interfaces, disable unnecessary services, and limit the impact of potential compromises through segmentation and containment.

6. Software Bill of Materials (SBOM)

Manufacturers must identify and document all software components, including dependencies, in a machine-readable format — either SPDX or CycloneDX.

Part II: Vulnerability Handling Requirements

• Establish coordinated vulnerability disclosure policies
• Document and remediate vulnerabilities without delay
• Apply effective and regular tests and reviews of product security
• Provide security updates for minimum 5 years or expected product lifetime
• Report actively exploited vulnerabilities to ENISA within 24 hours

Why Security-by-Design Is Core to the CRA Mandate?

The CRA's most consequential requirement is not SBOM generation or vulnerability scanning. It is the mandate for security by design. Article 13 requires manufacturers to "exercise due diligence when integrating components" and ensure products are "designed, developed and produced in accordance with essential requirements." The regulation specifies:

"Manufacturers should therefore ensure that all products with digital elements are designed and developed in accordance with the essential cybersecurity requirements laid down in this Regulation." (CRA (9))

What does Security-by-Design Mean Under the CRA?

Security by design under the CRA means integrating security considerations from the earliest product development phases, during architectural decisions and feature design, not retrofitting security after implementation. The regulation requires documented evidence that security was considered during design, rather than tested only after development.

"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." (CRA Annex I)

We continue to see an acceleration in the amount of focus that the design stage is getting from a cybersecurity risk management perspective, driven not solely by this act, but by global cybersecurity organizations and regulators alike.

The Design-Stage Gap

Most organizations have to this point invested substantially in code-level security tools:

• Static Application Security Testing (SAST) finds vulnerabilities in written code
• Software Composition Analysis (SCA) identifies risks in dependencies
• Runtime Application Security Testing (DAST) uncovers vulnerabilities in running applications

These tools serve important purposes, but they operate after code exists.

The CRA asks a different question: What security decisions were made when this feature was designed? 

When a feature moves from specification to implementation, the security-relevant decisions happen early. What data will this access? How will authentication work? What happens if this component is compromised? By the time code exists to scan, these architectural decisions are already made.

Answering the CRA's design-stage question requires security review during the design phase, with documented evidence that can satisfy conformity assessment. This creates a gap for most organizations: they have tooling for code-level security, but not for design-stage security review.

CRA Requirements vs. Traditional Tools and Other Regulations

The CRA creates new compliance obligations that existing tools and regulations do not cover:

These security-by-design requirements create the primary compliance gap organizations must close.

How Does Prime Security Handle CRA Compliance?

Prime Security's Agentic Security Architect closes the design-stage gap by bringing security review to where the CRA requires it: before code is written. Prime identifies security risks in planned work and creates the documented evidence that conformity assessment requires.

Design-Stage Security Review: Prime's Approach

Prime analyzes feature specifications, architectural decisions, and integration plans as they are created, not after they are implemented. 

When a developer writes a Jira ticket describing a new feature, Prime automatically:

1. Identifies security-relevant changes that warrant review
2. Analyzes architectural implications including data flows, authentication requirements, and attack surface changes
3. Generates security recommendations specific to the proposed design
4. Creates documented evidence of security review for CRA compliance

This shifts security review to where the CRA requires it, the design phase, while ensuring consistent coverage across all development activity.

Manual security design reviews can satisfy CRA requirements in theory. In practice, they create an impossible tradeoff. The CRA demands documented security consideration for every feature across every product. Achieving full coverage manually means either hiring a security architect for every development team or slowing releases to a crawl while a small team reviews everything. Most organizations end up with partial coverage and gaps in their conformity documentation.

Prime resolves this tradeoff. By automating design-stage review, organizations achieve the continuous coverage CRA requires without blocking development. Security teams maintain oversight and make final decisions, but the baseline analysis and documentation happens automatically, at the pace of development.

How Prime Helps Companies Meet Specific CRA Requirements?

Security by Design (Annex I, Part I)

The CRA requires that products "be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." 

Prime ensures that security teams are able appropriately manage the risks of every project by making sure that features are designed securely from the beginning.

Risk Assessment (Statement 37)

The CRA also mandates that “ Manufacturers should ensure that software made available under those conditions is released only following a risk assessment and that it complies to the extent possible with the security requirements relating to the properties of products with digital elements laid down in this Regulation.”

Prime's agent assesses the risk of both new components and existing software based on the rules and regulations set out by each individual company, regardless of size or industry..

Due Diligence on Components (Article 13.5)

The regulation requires manufacturers to "exercise due diligence when integrating components sourced from third parties." 

When development plans include third-party integrations, Prime analyzes the security implications of those integrated design decisions.

Effective and Regular Testing (Annex I, Part II)

The CRA mandates that manufacturers "apply effective and regular tests and reviews of the security of the product." 

Prime fits into your existing workflows between security and engineering,  continuously reviewing development activity.

Technical Documentation (Article 31)

“The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I.”

Prime creates persistent, auditable records of security decisions, recommendations, and reviews, producing the documentation required for conformity assessment and market surveillance.

How does EU CRA Compare to Other Cybersecurity Regulations?

CRA vs. NIS2

NIS2 (Directive 2022/2555) applies to essential and important entities operating critical infrastructure and requires organizational security measures, incident reporting, and supply chain security. The CRA applies to products regardless of who uses them.

The key differences: 

• NIS2 is entity-focused while CRA is product-focused
• NIS2 requires organizational policies while CRA requires product-level conformity
• NIS2 allows member state variation while CRA is directly applicable EU-wide

Most organizations that need to comply with NIS2 will also need to comply with CRA. A software company providing products to healthcare organizations might need NIS2 compliance as an important entity and CRA compliance for each product sold.

CRA vs. DORA

The Digital Operational Resilience Act (DORA) focuses on financial entities with requirements for ICT risk management, incident reporting, and third-party risk management. 

While DORA regulates organizational resilience, CRA focuses on product security. Financial services companies subject to DORA that also manufacture software products need CRA compliance for those products in addition to DORA compliance for their operations.

CRA vs. ISO 27001

ISO 27001 is a voluntary certification for information security management systems. The CRA is mandatory regulation with legal enforcement. ISO 27001 certification can support CRA compliance by showing mature security practices, but does not substitute for product-level conformity assessment and technical documentation.

FAQ

Does the CRA apply to my company if we're headquartered outside the EU?

Yes. The CRA applies to any organization that places products with digital elements on the EU market, regardless of where the company is based. If you sell software, hardware, or connected products to EU customers, you need to meet CRA requirements and obtain CE marking for those products.

Does the CRA apply to SaaS products?

Pure SaaS offerings with no downloadable components are generally out of scope. However, most SaaS products include elements that bring them in — browser extensions, desktop or mobile apps, agent software, SDKs provided to customers, and CLI tools all fall under CRA requirements. If any component gets installed or downloaded by the user, that component is in scope.

When does my company need to be fully CRA compliant?

Full compliance with all security requirements is due by December 11, 2027. However, mandatory vulnerability reporting to ENISA starts earlier, on September 11, 2026. That earlier deadline means you need documented vulnerability handling processes and reporting channels in place well before the full compliance date.

What is the difference between security by design and traditional AppSec testing?

Traditional AppSec tools — SAST, SCA, and DAST — find vulnerabilities in code that already exists. Security by design means making security decisions during the architectural and feature design phase, before any code is written. The CRA requires documented evidence of the latter; code-level scan reports alone do not satisfy this requirement.

What evidence do I need to pass a CRA conformity assessment?

You need documented proof that security was considered during the design phase of each product, a software bill of materials (SBOM) in a machine-readable format, records of vulnerability handling processes, and technical documentation covering how your product meets the Annex I requirements. For higher-risk product categories, third-party assessment by a notified body is also required.

Getting Started With EU CRA Compliance

The Cyber Resilience Act formalizes what security teams have long advocated: security consideration at the design phase, with documented evidence. The regulation provides clear requirements and a defined timeline to build out security by design best practices. Prime Security closes the design-stage gap by bringing automated security review to the design phase, creating the documented evidence that conformity assessment requires while helping your security architects focus on the strategic decisions that need human judgment.

Ready to Explore Design-Stage Security Review?

Request a Demo to see how Prime Security automates CRA-compliant security design reviews across your development organization.

Get Your Copy:

The Cyber Resilience Act (CRA) Cheatsheet

Download