11 August 2026

EU Cyber Resilience Act Explained for Product Developers

Reza Khosravi
No items found.

Table of Contents

What to Expect and Who Should Read This

This guide explains the EU Cyber Resilience Act (Regulation (EU) 2024/2847), what it covers, and what product teams must do.

Who should read:
product managers, software developers, security architects, compliance leads, CTOs.

You will learn:
scope, obligations, penalties, and a step‑by‑step readiness plan with standards you can map to today.

Overview of the Cyber Resilience Act

The CRA sets uniform cybersecurity requirements for products with digital elements across their lifecycle. Read the official text on EUR‑Lex: Regulation (EU) 2024/2847.

Most organizations will need to comply by late 2027. Planning early reduces rework and audit risk.

Who and What Is Covered

The CRA applies to software and connected hardware, including IoT, embedded firmware, and SaaS.

Obligations fall primarily on manufacturers, with specific duties for importers and distributors. For related network and service obligations, see the NIS2 Directive on EUR‑Lex: Directive (EU) 2022/2555.

Core Requirements You Need To Plan For

  • Secure by design and by default: integrate security from the start and minimize exploitable vulnerabilities. See CISA’s guidance: Secure by Design principles.
  • Lifecycle security: vulnerability handling, updates, and incident response processes that persist after release.
  • Technical documentation: keep evidence of secure design, risk assessments, threat models, and an SBOM. For SBOM format and automation, see OWASP CycloneDX: CycloneDX project.
  • Conformity assessment: default products can be self‑assessed, while important or critical categories may require third‑party assessment.
  • Standards mapping: use recognized standards to demonstrate conformity. ENISA’s mapping helps align CRA requirements to standards and practices: ENISA CRA requirements standards mapping.
  • Software development expectations: align engineering with NIST SSDF to operationalize secure development: NIST SP 800‑218 Secure Software Development Framework.

Enforcement and Penalties

Noncompliance can lead to significant fines and market surveillance actions, including corrective measures and recalls. Treat documentation and traceability as first‑class requirements, not paperwork to fill in later.

Action Plan for Product Teams

  1. Classify your products under CRA categories and identify any that may be important or critical.
  2. Map requirements to standards you already use, such as NIST SSDF and CycloneDX, using ENISA’s mapping to close gaps.
  3. Build an SBOM pipeline and capture threat modeling and risk assessments as code‑review artifacts.
  4. Establish vulnerability management with intake, triage, SLA tracking, and post‑release patching.
  5. Prepare conformity evidence early: capture design decisions, test results, and change history in a structured repository.
  6. Update supplier contracts to require SBOMs and security attestations.
  7. Run an internal readiness audit and schedule periodic rechecks before 2027.

Frequently Asked Questions

When does the CRA fully apply?

Compliance is required by 2027. Start now to avoid last‑minute remediation and audit surprises.

Primary source: Regulation (EU) 2024/2847.

What counts as a product with digital elements?

Software or hardware that connects to a network or other devices, including products that receive updates.

How should we document secure design?

Follow NIST SSDF for development practices and keep artifacts like SBOMs, threat models, and test evidence.

Source: NIST SP 800‑218 SSDF and OWASP CycloneDX.

Is there an official map from requirements to standards?

Yes. ENISA provides a mapping from CRA requirements to relevant standards and practices:

ENISA CRA requirements standards mapping.

‍

‍

External sources used in this article

‍

Table of Contents

Subscribe