CRA September 2026: Vulnerability Reporting Starts — What Manufacturers Must Do Now

The EU Cyber Resilience Act’s vulnerability reporting obligation took effect on September 11, 2026. This is the first CRA enforcement milestone — full product compliance follows in December 2027. Manufacturers of products with digital elements must now report actively exploited vulnerabilities to ENISA within strict timelines. For organizations still using informal vulnerability handling processes, this regulatory obligation requires immediate formalization.

This guide covers what must be reported, the exact timelines, the preparation checklist for compliance, SBOM requirements, and how the reporting obligation interacts with existing processes.

What Must Be Reported

Any actively exploited vulnerability in your product must be reported. This includes: zero-day vulnerabilities discovered through your own security monitoring or research, vulnerabilities reported through your coordinated vulnerability disclosure (CVD) program that are subsequently found to be actively exploited, vulnerabilities in third-party components (open-source libraries, commercial SDKs) that are embedded in your product and actively exploited, and severe incidents affecting the security of the product that indicate active exploitation.

The trigger is active exploitation — not the mere existence of a vulnerability. However, manufacturers must also maintain processes to detect exploitation of known vulnerabilities in their products, making monitoring capability a de facto requirement.

Reporting Timelines

1. Within 24 hours — Early warning: Notify ENISA that an actively exploited vulnerability has been identified. Provide: confirmation that the vulnerability is actively exploited, initial severity assessment (CVSS or equivalent), affected product names and versions, and initial recommended mitigations (if available).
2. Within 72 hours — Full vulnerability notification: Provide detailed technical information: vulnerability description and root cause, exploitation method and known attack vectors, complete list of affected product versions, detailed mitigation and remediation recommendations, and indicators of compromise (IoCs) where applicable.
3. Within 14 days — Final report: Complete root cause analysis, patch status and timeline for remaining fixes, notification status for affected users, lessons learned and preventive measures implemented, and updated severity assessment based on full analysis.

Preparation Checklist

To be ready for CRA vulnerability reporting, manufacturers must have the following in place:

• Vulnerability handling process: A documented, tested process for receiving, triaging, analyzing, and resolving vulnerabilities. This process must cover both internally discovered and externally reported vulnerabilities.
• Coordinated Vulnerability Disclosure (CVD) policy: A publicly accessible policy that tells external security researchers how to report vulnerabilities to you. Include: contact information (security@yourcompany.com), expected response times, safe harbor provisions for good-faith security research, and disclosure coordination timeline.
• SBOM (Software Bill of Materials): A current, accurate inventory of all software components in every product. When a new CVE is published, you must be able to determine within hours which of your products are affected. Use standardized SBOM formats (CycloneDX or SPDX) for interoperability.
• ENISA reporting registration: Register with ENISA’s reporting platform and test the submission process before you need it under time pressure.
• Exploitation monitoring: Active monitoring for exploitation of known vulnerabilities in your products. This includes: vulnerability database monitoring (NVD, CISA KEV), dark web intelligence for product-specific exploit activity, and customer incident reports that may indicate exploitation.
• Internal escalation path: Clear escalation from engineering (vulnerability confirmed) to legal (reporting obligations) to management (resource allocation and disclosure decisions).

SBOM: The Foundation for Fast Response

The SBOM requirement is foundational for CRA vulnerability reporting. When a critical CVE drops for a widely-used library (the next Log4j), you need to answer within hours: which of our products contain this component? The SBOM provides that answer. Best practices for CRA-ready SBOM management: generate SBOMs automatically as part of the CI/CD build process, update SBOMs with every release (not just major versions), use CycloneDX or SPDX formats for standardization, include transitive dependencies (dependencies of dependencies), and store SBOMs alongside product releases for audit trail.

Interaction with Existing Processes

CRA vulnerability reporting does not replace existing obligations — it adds to them:

• CVE/NVD reporting: Continue reporting vulnerabilities to MITRE/NVD. CRA reporting to ENISA is separate and has different timelines.
• GDPR breach notification: If the exploited vulnerability leads to a personal data breach, GDPR 72-hour notification to the supervisory authority also applies.
• NIS2 incident reporting: If your organization is a NIS2-regulated entity and the exploitation constitutes a significant incident, NIS2 24h/72h reporting to the national authority also applies.
• Customer notification: The CRA requires manufacturers to inform users about vulnerabilities and available patches. This is separate from the ENISA regulatory notification.

Frequently Asked Questions

Does this apply to SaaS-only products?

Pure SaaS without downloadable components is generally out of CRA scope. However, if your SaaS includes client-side software (desktop apps, browser extensions, mobile apps), those components are in scope for vulnerability reporting. The server-side cloud infrastructure is excluded, but software distributed to users is covered.

What happens if we miss the 24-hour deadline?

Market surveillance authorities can impose penalties. While the full penalty framework (up to EUR 15M or 2.5% of turnover) applies from December 2027, vulnerability reporting violations can be enforced from September 2026. Demonstrate good faith: a late report with full information is better than no report. Document the reasons for any delay.

Do we need to report vulnerabilities in open-source dependencies?

Yes, if the vulnerability is actively exploited and affects your product. The manufacturer (not the open-source project maintainer) bears the reporting responsibility. This is why SBOM management and continuous dependency monitoring are essential for CRA compliance.

What constitutes active exploitation?

Active exploitation means the vulnerability is being used by threat actors to compromise systems in the wild — not just that a proof-of-concept exists. Sources for determining active exploitation: CISA Known Exploited Vulnerabilities (KEV) catalog, threat intelligence feeds, customer incident reports, and your own monitoring. When in doubt, report — ENISA prefers over-reporting to under-reporting.