Cyber Resilience Act: Obligations for Software and Hardware Manufacturers – Operational Guide

Are you developing an application or producing a connected device? Since 2025, the Cyber Resilience Act (CRA) from the European Union imposes strict obligations on you. It's not optional, not a voluntary label – it's law. And fines can reach up to 2.5% of global annual turnover.

Here at Meteora Web we see it daily with our clients: companies discovering only now that their embedded software or SaaS product must meet stringent cybersecurity requirements. And we're not talking about longer passwords or occasional updates. We're talking about vulnerability management, transparent communication, technical documentation, and a well-defined vulnerability disclosure process.

In this guide we cut straight to the point: what a manufacturer (software or hardware) must do to comply with the CRA, with concrete examples and actions you can take right now.

What is the Cyber Resilience Act and why it concerns you

The Cyber Resilience Act (Regulation EU 2024/2847) is the first European legal framework imposing cybersecurity requirements for products with digital elements – software, hardware, firmware – placed on the market. Whether you sell B2B or B2C, whether you are a startup or an SME: if your product has a digital component and is marketed in the EU, you are covered.

Goal? Reduce exploitable vulnerabilities, force manufacturers to release timely patches, and ensure consumers are informed about risks. The CRA applies to the entire product lifecycle: from design to disposal.

Who is considered a manufacturer under the CRA

The regulation defines a manufacturer as anyone who develops, manufactures, or has a product with digital elements developed/manufactured and places it on the market under their own name or trademark. This includes:

• IoT device makers (smart home, industrial sensors, wearables)
• Desktop, mobile or cloud software developers
• Embedded system providers (firmware on microcontrollers)
• SaaS platforms offering software functionality – note: the CRA also covers standalone software (e.g., mobile apps, business software)
• Assemblers of hardware components with integrated software (e.g., router vendors, IP cameras, smart thermostats)

Important: if your product includes open source components, compliance remains your responsibility. You cannot shift liability to the library provider.

Key obligations for manufacturers: a practical checklist

The CRA is not a single task but a set of requirements to be integrated into your development process. Here are the essential points.

1. Security by design

You must adopt a security approach from the design phase. “Adding security later” is not enough. This means:

• Initial risk analysis (threats, attack surfaces)
• Selection of secure components and libraries (no obsolete dependencies)
• Implementation of principles like least privilege, input validation, encryption of sensitive data
• Documentation of security choices (keep for audits)

Practical example: a client producing connected thermostats used a WiFi module with firmware stuck on 2019 versions. We forced an upgrade to the latest release and enabled OTA updates protected by cryptographic signatures.

2. Vulnerability management

The manufacturer must establish a continuous process to identify, report and fix vulnerabilities. This includes:

• A public channel for receiving vulnerability reports (e.g., security@company.com or a dedicated page)
• A maximum time for releasing patches (CRA doesn't set a fixed deadline, but requires “timely” and documented response)
• Free security updates for at least 5 years from market placement (or for the expected product lifespan, whichever is longer)

Vulnerability disclosure obligation: you must publish advisories on known vulnerabilities and inform users. Here's a minimal disclosure page template:

<h2>Security Advisories</h2>
<p>We encourage responsible disclosure. Report vulnerabilities to security@myproduct.com.</p>
<ul>
  <li><strong>CVE-2025-1234</strong> – RCE in module X (fixed in v2.1.3, release 2025-08-01)</li>
  <li><strong>CVE-2025-5678</strong> – XSS in admin panel (fixed in v3.0.0, release 2025-09-15)</li>
</ul>

3. Software Bill of Materials (SBOM)

The CRA requires transparency on software components. You must be able to provide a Software Bill of Materials (SBOM) listing all dependencies, versions, and licenses. Public release is not mandatory (unless requested by authority), but you must have it ready.

Accepted standard formats: CycloneDX (recommended), SPDX. Example of a CycloneDX snippet:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{"license": {"id": "Apache-2.0"}}]
    }
  ]
}

Immediate actions: use tools like syft (Anchore) or trivy to generate SBOM automatically during builds. Integrate into CI/CD.

4. Technical documentation and declaration of conformity

Before placing the product on the market, you must prepare technical documentation demonstrating compliance with CRA requirements. This includes risk analysis, security specifications, test results. Additionally, you must draft an EU Declaration of Conformity and affix the CE marking (updated with the new CRA symbol).

Download a template: the European Commission has published models – search on ec.europa.eu.

5. Notification of actively exploited vulnerabilities

If a vulnerability in your product is actively exploited, you must notify ENISA (EU Agency for Cybersecurity) within 24 hours, and within 72 hours provide an impact assessment. A heavy obligation, but essential for transparency.

Which products are exempt? (Spoiler: few)

The CRA excludes only:

• Non-commercialised free software (e.g., personal open source projects without profit)
• Medical devices under specific regulation (MDR)
• Aeronautical components (covered by EASA)

Caution: open source software distributed commercially (even indirectly, like a paid-support CMS) is included. If your product is a simple WordPress plugin sold on a marketplace, you fall under the CRA.

Penalties and timelines

The CRA has been in force since 11 December 2024, but most obligations become applicable from 11 December 2027. However, some provisions (vulnerability notification) are already active. Don't wait for 2027: compliance takes months of technical and organisational work.

Penalties: up to €15 million or 2.5% of global annual turnover, whichever is greater.

How we at Meteora Web are approaching this

We support our clients (from startups to manufacturing SMEs) in their CRA compliance journey. We always start with a gap analysis: comparing current processes with regulation requirements. Then we intervene on:

• Integration of SBOM in CI/CD pipelines
• Setting up a vulnerability disclosure policy
• Firmware/software security audit with SAST/DAST scanning
• Technical documentation and declaration of conformity

A concrete example: a client producing precision agriculture sensors had no automatic update process. We implemented a hardware-signed OTA system and drafted the notification procedure to ENISA. Now they are CRA-compliant.

In summary – What to do next

1. Take inventory of your products: list all your software and digital devices marketed in the EU.
2. Perform risk analysis: identify the most likely vulnerabilities for each product.
3. Generate the SBOM: use syft or trivy on every build; integrate into CI/CD.
4. Establish a vulnerability disclosure policy: create a public page and a dedicated email address.
5. Plan updates: define a patch release cycle for at least 5 years.
6. Read the pillar guide: for a broader view on NIS2 and CRA, see our Definitive Pillar Guide on NIS2 and EU Cybersecurity Regulations.

Don't wait for a fine to arrive. The Cyber Resilience Act is not just an obligation: it's an opportunity to make your products more secure and competitive. We are here to help.