Cyber Resilience Act: ENISA reporting duties effective 11 September 2026
News date: 2026-10-20 · Sources reviewed: 2026-10-26
Cybersecurity regulation is not limited to organizations covered by NIS2. Since 11 September 2026, Cyber Resilience Act (CRA) reporting obligations have applied to manufacturers of products with digital elements. ENISA launched its Single Reporting Platform (SRP), while the Greek National Cybersecurity Authority published local guidance. ENISA updated its reporting FAQ on 15 October 2026.
Who is covered, and how CRA differs from NIS2
CRA addresses the cybersecurity of products with digital elements made available on the EU market, including software and connected devices, and places key obligations on manufacturers. NIS2 addresses cybersecurity risk management by defined categories of entities. An organization may need to assess both frameworks, but ordinary product users should not assume they have CRA manufacturer reporting duties.
- Determine whether the company is a manufacturer of an in-scope product.
- Inventory products, versions, third-party components and security owners.
- Connect product security, engineering and legal/compliance functions.
Which events trigger reporting
Mandatory notifications concern actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements. Not every theoretical weakness automatically requires a report. Greek guidance clarifies that no retrospective notification is required where the manufacturer already knew of active exploitation before 11 September 2026. Awareness after that date may trigger reporting even for an older product or vulnerability.
- Define evidence criteria for confirmed active exploitation.
- Record when the manufacturer became aware of the event.
- Assess impact with the designated compliance decision-maker.
The 24-hour and 72-hour deadlines
ENISA guidance requires an early warning without undue delay and no later than 24 hours after awareness. A further notification with an initial assessment is due within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification. These clocks demand preparation before an incident occurs.
- 24 hours: early warning.
- 72 hours: notification and initial assessment.
- Final report: different deadlines for vulnerabilities and severe incidents.
How the ENISA SRP works
Manufacturers submit mandatory reports electronically through ENISA’s platform and select the appropriate coordinating CSIRT. The Greek authority notes that direct CSIRT contact does not replace subsequent SRP submission. ENISA publishes registration guidance, manuals and FAQs. The separate obligations for open-source software stewards apply from 11 December 2027, not September 2026. On 20 October 2026, SRP was upgraded to version 1.2.1, changing how Secondary or Backup Assigned Representatives (ARs) are invited. Organizations should follow current documentation rather than relying on older registration instructions.
- Prepare SRP access and assign reporting roles.
- Designate backups for holidays and out-of-hours escalation.
- Establish a process for collecting technical evidence promptly.
- Review the revised Secondary/Backup AR invitation flow following SRP 1.2.1 on 20 October 2026.
A minimum operational readiness plan
Manufacturers need a PSIRT or equivalent vulnerability intake, triage, evidence preservation, notification decision and remediation workflow. Third-party dependency visibility matters: the Greek authority notes that exploitation of a component embedded in a final product can create a reporting obligation for the final product manufacturer too.
- Maintain a product, component and owner register.
- Define an incident workflow with 24-hour escalation capability.
- Run a tabletop reporting exercise and document gaps.
VALUE360 can assist with technical risk assessment, incident readiness processes and security-control documentation alongside qualified legal advisers. This article is informational and is not legal advice.
Explore the related VALUE360 service →
Sources
- cyber.gov.gr — anafores eypatheion kata cra cyber resilience act
- enisa.europa.eu — the cra single reporting platform is launched
- enisa.europa.eu — frequently asked questions
- enisa.europa.eu — single reporting platform srp
Remediation prioritization
Prioritize by actual exposure, affected software versions, privileges and signs of compromise—not headline severity alone. Confirm affected releases and mitigations against the vendor advisory.
Implementation questions
Does this automatically affect our environment?
No. First verify whether the specific product, version and relevant configuration are deployed.
Is a security tool enough on its own?
No. Combine patching, restricted access, logging and tested backups.
