Compliance & Regulation7 min read

Cyber Resilience Act: what changes for your clients

The European Cyber Resilience Act (EU 2024/2847) reaches its most binding phase on 11 September 2026: any actively exploited vulnerability in a digital product must be reported to ENISA within 24 hours. For agencies and developers delivering software to clients, this is a concrete operational obligation.

What is the CRA and who is affected

The Cyber Resilience Act (EU regulation 2024/2847, published in the Official Journal of the EU on 23 October 2024) imposes security requirements on products with digital elements placed on the European market. It covers software, web applications, firmware and connected components. Agencies that develop and deliver digital products to clients, SaaS publishers, service providers maintaining production platforms — all fall within scope as soon as their products are sold or transferred to entities established in the EU.

What the CRA concretely requires from agencies and developers

  • Notification of actively exploited vulnerabilities within 24 h — report to ENISA upon discovery of active exploitation, even before a fix is available.
  • Incident report within 72 h — more detailed account to ENISA within three days of the initial notification.
  • Active vulnerability management over the entire product lifecycle — SBOM, CVE tracking and patching within defined timelines.
  • Security documentation delivered with the product — secure configuration guide, update log, reporting procedure for end users.
  • Secure by default design — the product must start in a secure state, without unmodified default credentials.
  • Coordinated disclosure process — documented mechanism allowing third parties to report vulnerabilities.

The 11 September 2026 deadline: vulnerability notification

11 September 2026 is the application date for reporting obligations (article 14 of the regulation). It is not when the entire regulation comes into force — it has applied progressively since 11 December 2024 — but it is the first operational deadline that directly affects technical teams. From that date, a vulnerability known to be actively exploited must trigger a notification to ENISA within 24 hours, whether or not a fix is available.

Preparing before 11 September 2026

01

Inventory digital products in scope

List the software, SaaS solutions and components you develop and deliver to clients in the EU. Exclude pure services and open source products without commercial support, which benefit from a partial exemption.

02

Establish a Software Bill of Materials (SBOM)

Inventory third-party components (libraries, frameworks, dependencies) integrated in each product. A structured SBOM (SPDX or CycloneDX formats) is the basis for CVE tracking. Integrate its generation into your CI/CD pipeline.

03

Set up CVE monitoring and an escalation procedure

Subscribe to relevant vulnerability feeds (NVD, CERT-EU, publishers of your dependencies). Define an internal decision circuit: who validates the ENISA notification, who drafts the report, which channel to use.

04

Prepare notification templates

The initial notification within 24 h must contain: product identification, vulnerability description, proof of active exploitation, available mitigation measures. Prepare a legally validated template.

05

Open a disclosure channel for third parties

Publish a coordinated disclosure policy (security.txt at the root of your-domain.com, dedicated page) with a contact address and a processing time commitment.

06

Update contracts and delivered documentation

Verify that your maintenance contracts identify CRA obligations and define the sharing of responsibility. Delivered technical documentation must include the secure configuration guide.

CRA and NIS2: two distinct texts

The CRA covers the security of digital products (software, components, firmware placed on the market); NIS2 (EU directive 2022/2555) covers the resilience of entities. The same actor may be subject to both — but obligations, competent authorities and notification timelines differ.

What this changes for your infrastructure

Bringing a digital product into compliance is not just a documentary exercise. Rapid detection of active exploitation requires the ability to monitor for abnormal behavior, CVE alerts on components in production and detailed access to application logs. Infrastructure hosted on servers you control — with root access, complete logs and freedom to deploy monitoring tools — is structurally better positioned than shared infrastructure.

Your infrastructure, under your control

Full logs, root access, freedom to deploy monitoring and detection tools: infrastructure you control is the first building block of a serious CRA posture.

Need help?

Browse our help center and FAQ, or write to our team — support in French, English and Arabic.