The EU Cyber Resilience Act: A Complete Compliance Guide for 2026 and Beyond

Key takeaways

• The Cyber Resilience Act (CRA) entered into force on December 10, 2024 and applies to nearly every "product with digital elements" sold in the EU.
• Vulnerability and incident reporting obligations begin on September 11, 2026. Manufacturers will have 24 hours to file an early warning and 72 hours for a full notification.
• Full compliance, including CE-marking and conformity assessment, is required from December 11, 2027.
• Non-compliance can trigger fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
• The CRA mandates a machine-readable Software Bill of Materials (SBOM), secure-by-design engineering, coordinated vulnerability disclosure, and security updates for the product’s expected lifetime.
• Manufacturers based outside the EU are in scope if their products reach the EU market.

What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) is an EU regulation that sets binding cybersecurity requirements for any "product with digital elements" placed on the European Union market. It is the first horizontal EU law that holds manufacturers accountable for the security of hardware and software throughout the entire product lifecycle—from design to end-of-support.

The CRA was published in the Official Journal of the European Union as Regulation (EU) 2024/2847 and entered into force on December 10, 2024. It introduces a CE-marking regime for cybersecurity comparable to existing safety regulations for physical goods, and it harmonizes rules across all 27 member states, replacing the patchwork of national cybersecurity standards that previously applied to connected products.

In plain terms: if your product can talk to a network, runs software, or is connected software itself, and you sell it in the EU, the CRA applies to you.

Who must comply with the Cyber Resilience Act?

The CRA applies to manufacturers, importers, and distributors of products with digital elements (PDEs). A product with digital elements is any hardware or software product whose "intended and foreseeable use includes direct or indirect data connection to a device or network."

That definition is intentionally broad. In-scope products include:

• Connected hardware: routers, smart home devices, wearables, industrial controllers, medical IoT, connected cars (where not already covered by sector-specific rules).
• Standalone software: operating systems, mobile apps, desktop applications, antivirus tools, identity managers.
• Embedded firmware in any connected device.
• Remote data processing solutions that are necessary for a product to function, including cloud back-ends.

The regulation applies regardless of where the manufacturer is headquartered. A US-based SaaS company selling into Germany, a Japanese IoT vendor shipping to France, and an open-source foundation distributing commercial support contracts in the Netherlands are all subject to the CRA.

There are limited carve-outs. Products already governed by lex-specialis regulations—such as medical devices, motor vehicles, aviation systems, and certain marine equipment—remain under their existing frameworks. Non-commercial open-source software developers are also exempt from CRA fines, though "open source software stewards" (organizations that commercialize or systematically support OSS projects) carry lighter duties.

When does the Cyber Resilience Act take effect?

The CRA uses a phased timeline. Three dates matter for compliance planning:

• June 11, 2026 — Rules on the notification of conformity assessment bodies begin to apply. National authorities can now designate the bodies that will certify high-criticality products.
• September 11, 2026 — Manufacturers must begin reporting actively exploited vulnerabilities and severe security incidents to ENISA and national CSIRTs. The reporting clock is strict: a 24-hour early warning, a 72-hour full notification, a 14-day final report after a patch is available for exploited vulnerabilities, and a one-month final report for severe incidents.
• December 11, 2027 — All remaining obligations apply: secure-by-design requirements, conformity assessment, technical documentation, the CE marking, SBOM generation, vulnerability handling processes, and the duty to provide security updates throughout the support period.

After December 11, 2027, products without a CE marking and matching CRA conformity cannot legally be placed on the EU market.

What are the core requirements of the CRA?

The CRA’s substantive obligations are laid out across Annex I (essential cybersecurity requirements) and Annex II (information and instructions for users). They fall into six categories.

1. Secure-by-design and secure-by-default

Products must be "designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks." That means delivering products with secure default configurations, minimizing the attack surface, protecting confidentiality and integrity of data, and providing mechanisms for secure updates. Authentication, access control, and protection against unauthorized modification must be baked in—not bolted on.

2. Software bill of materials (SBOM)

The CRA makes an SBOM mandatory for every product with digital elements. Manufacturers must:

• Identify and document at least the top-level dependencies of the product.
• Produce the SBOM in a commonly used, machine-readable format. Although the regulation does not specify a format, the de-facto choices are SPDX and CycloneDX.
• Keep the SBOM up to date throughout the product’s support period.
• Make it available to market surveillance authorities on request.

Importantly, the CRA does not require manufacturers to publish SBOMs publicly. They must be available to regulators—and increasingly, to enterprise customers who demand them as part of procurement.

3. Vulnerability handling

Manufacturers must operate a documented vulnerability management process for the entire support period. The CRA expects:

• A coordinated vulnerability disclosure policy with a clear point of contact.
• Mechanisms to receive, triage, and address vulnerabilities reported by external researchers.
• Free, timely security updates that are clearly communicated, ideally delivered automatically where appropriate, and accompanied by advisory information.
• Continuous testing and review of the product’s security, including third-party components.

4. Incident and exploited-vulnerability reporting

Beginning September 11, 2026, manufacturers must report:

• Any actively exploited vulnerability in their product.
• Any severe incident that has an impact on the product’s security.

Reports go through a single EU reporting platform managed by ENISA in cooperation with national CSIRTs. The cadence is fixed: 24-hour early warning → 72-hour notification → 14-day or one-month final report, depending on the event.

5. Conformity assessment and CE marking

The CRA classifies products into four risk tiers: default, Important Class I, Important Class II, and Critical. The higher the tier, the more rigorous the conformity assessment.

• Default products may self-attest.
• Important Class I products may use harmonized standards for self-assessment or rely on a notified body.
• Important Class II products (e.g., firewalls, password managers, EDR) require third-party assessment.
• Critical products may eventually require European cybersecurity certification.

All in-scope products must carry the CE marking before being placed on the EU market.

6. Documentation, lifecycle support, and transparency

Manufacturers must produce technical documentation demonstrating compliance, define an explicit support period (typically at least five years), provide clear user instructions, and notify users when support ends so they can make informed risk decisions.

How does the CRA classify products with digital elements?

The four risk tiers determine which conformity-assessment route a manufacturer must follow.

• Default category — Roughly 90% of products. Examples: smart speakers, fitness wearables, mobile games. Self-assessment is permitted.
• Important Class I — Products with elevated cybersecurity functions or risk. Examples: standalone password managers, network management systems, smart-home hubs, microcontrollers used in critical applications.
• Important Class II — Products whose compromise could have severe systemic impact. Examples: hypervisors, container runtimes, firewalls, intrusion detection/prevention systems, public key infrastructure issuers.
• Critical — A short list of products whose failure could disrupt essential services. Examples: hardware security modules, smart meter gateways, and smartcards used for secure-element functions.

Determining the correct tier is one of the most important early decisions a CRA compliance program makes. It dictates the testing, documentation, and certification path for the next several years.

What are the penalties for CRA non-compliance?

The CRA’s enforcement teeth are aligned with the GDPR’s "highest of fixed amount or percentage of turnover" model.

• Up to €15 million, or 2.5% of global annual turnover (whichever is higher) for breaching the essential cybersecurity requirements in Annex I or the manufacturer obligations in Articles 13 and 14.
• Up to €10 million, or 2% of global annual turnover for other obligations, including market-access and documentation duties.
• Up to €5 million, or 1% of global annual turnover for providing false, incomplete, or misleading information to notified bodies or market surveillance authorities.

National market surveillance authorities can also order product withdrawals, recalls, or bans from the EU market. Reputational damage is the unquantified penalty: every CRA enforcement action becomes a public signal to customers, partners, and competitors.

How to prepare for CRA compliance: a 7-step roadmap

The runway to 2027 is shorter than it looks. Most organizations need 18–24 months to build the engineering, documentation, and reporting muscle the regulation requires.

1. Inventory your in-scope products. Map every product, service, and SaaS offering against the CRA’s "product with digital elements" definition. Include embedded firmware, mobile apps, and remote data processing components.
2. Classify each product by risk tier. Default, Important Class I, Important Class II, or Critical. This drives your assessment path.
3. Generate an accurate SBOM for every in-scope product. Use SPDX or CycloneDX. Make sure first-party and third-party (including open-source) dependencies are captured.
4. Stand up a vulnerability management and disclosure process. Publish a coordinated vulnerability disclosure (CVD) policy, designate a security contact, and integrate vulnerability triage into your SDLC.
5. Wire up incident reporting. Before September 11, 2026, have a documented runbook for the 24-hour, 72-hour, and 14-day/one-month reporting deadlines. Identify who decides, who files, and who communicates.
6. Bake secure-by-design into engineering. Add CRA controls to your secure SDLC, threat-modeling, code-review, dependency-update, and release-gate processes.
7. Build and maintain technical documentation. Compliance is a paper trail. Treat documentation as a versioned, auditable artifact alongside your code.

How Mend.io helps you meet CRA requirements

Mend.io’s AppSec and AI security platform was built for exactly the evidence the CRA demands: an inventory of what is in your software, proof that it has been tested, and a remediation record regulators can audit.

• Mend SCA generates a precise, up-to-date inventory of open-source components and exports SBOMs in SPDX and CycloneDX. It can also import third-party SBOMs and apply VEX (Vulnerability Exploitability eXchange) data so you can communicate exploitability accurately to customers and regulators.
• Reachability analysis filters out theoretical vulnerabilities so your engineering teams focus on issues that actually matter—essential when CRA reporting deadlines start at 24 hours.
• Mend SAST extends coverage to first-party code and runtime artifacts, supporting the CRA’s secure-by-design and continuous testing requirements.
• Automated remediation opens fix PRs and tracks them through merge, giving you the auditable workflow that secure-update and vulnerability-handling obligations require.
• AI-aware governance inventories AI components and models alongside traditional software, so AI-enabled products in scope of both the CRA and the EU AI Act are managed in a single workflow.

The result: a single, governed system of record that produces the SBOMs, vulnerability evidence, and remediation history a CRA conformity assessment will demand—without the manual spreadsheet sprawl most teams default to today.

FAQs

Conclusion: turn CRA compliance into a competitive advantage

The Cyber Resilience Act will reshape the European software and hardware market the way GDPR reshaped data protection. Manufacturers who treat it as a paperwork exercise will scramble in 2027. Those who treat it as a forcing function for secure-by-design engineering, accurate software inventories, and disciplined vulnerability management will ship products that EU buyers, regulators, and procurement teams actively prefer.

The work starts now. Inventory your products, classify them, generate SBOMs, document your processes, and put the reporting plumbing in place before September 11, 2026.

Ready to operationalize CRA compliance? Talk to us about generating CRA-grade SBOMs, automating vulnerability remediation, and producing the audit-ready evidence the regulation requires.