Skip to content
HACKTECH
RegulationReported Published 6 sources

Cyber Resilience Act reporting duties begin as ENISA launches Single Reporting Platform

Since 11 September 2026, manufacturers of products with digital elements made available on the EU market must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act, according to the European Commission. Reports go through the Single Reporting Platform that ENISA launched the same day: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for vulnerabilities, or within a month of the 72-hour notification for severe incidents. The Commission says the duty also covers products placed on the market before the CRA's main obligations apply on 11 December 2027.

  • Cyber Resilience Act
  • ENISA
  • vulnerability reporting
  • incident reporting
  • product security
  • EU

What the sources report

  • Commission timeline: the CRA entered into force on 10 December 2024; Chapter IV on notification of conformity assessment bodies applies from 11 June 2026, the Article 14 reporting obligations from 11 September 2026 and the main obligations from 11 December 2027.
  • Manufacturers report once through the SRP to the CSIRT designated as coordinator, in general in the Member State of their main establishment; unless particularly exceptional circumstances apply, the information is made available to ENISA at the same time, and the receiving CSIRT shares it with CSIRTs in the countries where the product is available.
  • On 11 December 2025 the Commission adopted a delegated act setting out when a CSIRT may delay passing a notification to other CSIRTs on justified cybersecurity-related grounds.
  • Open-source software stewards come under the reporting obligations (Article 24(3)) from 11 December 2027.
  • Help Net Security reported that the first SRP release has no API, so notifications are filed through a web interface; registration uses EU Login with multi-factor authentication, each manufacturer gets one Primary and up to 20 Secondary Assigned Representatives, and a notification sent to the wrong coordinator may be invalidated. ENISA says it upgraded the SRP to version 1.3 on 4 November 2026.

What it means for your organisation

Once a manufacturer becomes aware that a flaw in its product is being actively exploited, it has 24 hours to work out which products are affected and file an early warning. That needs accurate product and component inventories, a working route for outside reports and an agreed path from triage to notification. Because the duty covers products already on the EU market, older firmware and app versions are in scope now, not only from December 2027.

What we check

  • Inventory every product with digital elements sold in the EU, including older firmware and app versions still on the market, with a named owner and the CSIRT coordinator that applies.
  • Run a tabletop exercise that starts from a report of in-the-wild exploitation and times the path to a 24-hour early warning and a 72-hour notification.
  • Test the external vulnerability intake route (security.txt, disclosure mailbox, bug bounty) end to end, including triage and escalation to product security and legal.
  • Check that component inventories and the update pipeline can identify affected versions and ship a corrective measure quickly, with the final report filed no later than 14 days after that measure is available.
  • Confirm SRP Assigned Representative accounts are registered, protected with MFA and backed by deputies for out-of-hours incidents.

Sources

Services that cover these checks

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Mobile application testing

    iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.

    Duration: 6 to 10 working days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works