Vulnerability Reporting Requirements
Published: April 5, 2026
See all Executive Briefings
Executive Summary
Why It Matters
- The September 11, 2026 reporting deadline is real and approaching fast. If you sell downloadable or on-premises software to EU customers, you'll need to report actively exploited vulnerabilities to EU authorities within 24 hours of becoming aware of them.
- This is required by the EU Cyber Resilience Act (CRA), which mandates reporting to the European Union Agency for Cybersecurity (ENISA).
- This applies to on-premises and downloadable software; pure Software-as-a-Service (SaaS) is generally excluded.
- Most organizations are preparing for the December 2027 full compliance deadline and missing the earlier September 2026 reporting deadline.
- You can't report vulnerabilities you don't know about. SBOM generation and vulnerability monitoring must be operational before September 2026.
- Penalties for non-compliance: up to €15 million or 2.5% of global annual turnover, whichever is greater.
- See Scope Determination in Full Analysis for detailed product-type guidance.
Prepare Now
This isn't a theoretical compliance checkbox. It requires operational readiness: real-time vulnerability monitoring, pre-approved reporting templates, and escalation paths that work on weekends and holidays.
The September 2026 deadline is less than six months away, and most product security incident response processes weren't designed for 24-hour regulatory reporting. Organizations that wait until late 2026 to address this will find themselves scrambling.
Key Actions
- Determine which of your products are in scope using the Scope Determination table in the Full Analysis section. Document your rationale for each product.
- Implement SBOM generation for all in-scope products. You can't report vulnerabilities in components you don't know you're using.
- Establish vulnerability monitoring for your product dependencies. Key sources: CISA KEV catalog, vendor advisories, and threat intelligence feeds.
- Prepare reporting templates for ENISA/CSIRT submissions now. Don't wait until you're in a crisis to figure out what information to include.
Important Notes
- Legacy products are in scope: Reporting obligations apply to products already on the market, not just new releases. A vulnerability in a product shipped in 2020 must be reported under CRA timelines starting September 2026.
- Hybrid architectures: If your on-premises product requires cloud connectivity to function (authentication, licensing, core features), both the on-prem component and the cloud backend are in CRA scope.
- Define your 'awareness' triggers now: The 24-hour clock starts when you 'become aware' of an actively exploited vulnerability. See EC Guidance on 'Becoming Aware' in the Appendix.
- Prepare reporting templates now: Don't wait until you're in a crisis to figure out what information ENISA requires. Draft templates for early warning, full notification, and final reports.
- Coordinate with your managed security provider: If you use a managed Security Operations Center (SOC) or Security Information and Event Management (SIEM) service, ensure they understand CRA reporting requirements and can support rapid escalation.
Full Analysis and Recommendations
Background
The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, establishes mandatory cybersecurity requirements for 'products with digital elements' sold in the EU market. The regulation entered into force on December 10, 2024, with a phased implementation schedule.
Key dates:
- September 11, 2026: Vulnerability reporting requirements become mandatory
- June 11, 2026: Member States must designate Conformity Assessment Bodies (CABs)
- December 11, 2027: Full CRA compliance required (all essential cybersecurity requirements, CE marking (Conformité Européenne, indicating European conformity), technical documentation)
The September 2026 deadline is the one most organizations are missing. Full compliance planning focuses on December 2027, but vulnerability reporting is mandatory 15 months earlier.
Scope Determination
Understanding what falls within CRA scope is critical for planning. Use this table to determine whether your products require CRA vulnerability reporting:
| Product Type |
In Scope? |
Notes |
| On-premises/downloadable software |
Yes |
Full reporting obligations apply |
| Pure SaaS/PaaS |
No |
May fall under NIS2 instead |
| On-prem + required cloud backend |
Yes (both) |
Cloud component in scope if necessary for product function |
| On-prem + optional cloud features |
Partial |
On-prem in scope; optional cloud features likely excluded |
| IoT/embedded hardware |
Yes |
Hardware, firmware, and required cloud all in scope |
| FOSS (non-commercial) |
No |
Unless monetized beyond actual costs |
| FOSS (commercial activity) |
Yes |
But fines don't apply per Article 64(10)(b) |
| Medical devices |
No |
Covered by Regulation EU 2017/745 |
| Motor vehicles |
No |
Covered by Regulation EU 2019/2144 |
Note: FOSS = Free and Open-Source Software. NIS2 = Network and Information Security Directive 2. PaaS = Platform-as-a-Service. IoT = Internet of Things.
Hybrid Architecture Nuance: If a device can only function with a connection to the cloud, then both the device and the cloud infrastructure are in CRA scope. This is particularly relevant for products requiring cloud-based authentication, licensing, or feature functionality.
Reporting Requirements
From September 11, 2026, manufacturers must report to ENISA through the Single Reporting Platform (SRP):
What Triggers Reporting
- Actively exploited vulnerabilities in your product. This means reliable evidence that the vulnerability is being exploited in the wild by malicious actors, not that the vulnerability has been exploited in your specific environment.
- Severe incidents impacting product security, including cloud backend compromises that affect product functionality
Reporting Timelines
- 24 hours: Early warning after becoming aware of an actively exploited vulnerability or severe incident
- 72 hours: Full notification with details
- 14 days: Final report after a corrective measure is available (or within 1 month for severe incidents)
Prioritized Response Actions
The following actions are in priority order. For most organizations, items 1-4 should be complete by Q2 2026; items 5-7 by August 2026.
- Scope Determination: Document which products are in scope using the table above. Include rationale for borderline cases (hybrid SaaS/on-prem products). This is foundational; everything else depends on it.
- SBOM Generation: Implement automated SBOM generation for all in-scope products. Without SBOMs, you can't know if a newly-disclosed vulnerability affects your product, and you can't comply with the 24-hour reporting window.
- Vulnerability Monitoring: Establish monitoring for exploitation intelligence on your product dependencies. Key sources include the CISA KEV catalog, vendor security advisories, and threat intelligence feeds.
- Define 'Awareness' Triggers: Document what constitutes 'becoming aware' for reporting clock purposes. According to EC guidance, awareness occurs when you have 'reasonable certainty' that a vulnerability is being actively exploited. Options for triggering this include: CVE publication with exploitation reports, CISA KEV listing, researcher report to your Product Security Incident Response Team (PSIRT), or confirmed exploitability in your specific build.
- Map PSIRT to CRA Timelines: Augment existing PSIRT processes to meet 24/72-hour/14-day requirements. Most PSIRT processes weren't designed for 24-hour regulatory reporting. Key gaps: defined triggers, pre-approved templates, escalation paths that work on weekends/holidays.
- Draft Reporting Templates: Prepare pre-built templates for ENISA/Computer Security Incident Response Team (CSIRT) submissions. Don't wait until you're in a crisis to figure out what information to include.
- Identify Main EU Establishment: Determine which Member State CSIRT you'll report through. Your 'main establishment' is the Member State where decisions related to product cybersecurity are predominantly made. If that can't be determined, use the Member State where you have the most EU employees. Non-EU manufacturers use the Member State of their authorized representative, importer, or distributor (in that order). See CRA Article 14(7) in the Appendix.
Practical Compliance Considerations
SBOM Requirement is Implicit for Reporting
While formal SBOM requirements apply under the December 2027 deadline, practical compliance with September 2026 reporting requires SBOMs in place earlier. You need to know what components are in your product to know if they're affected by an actively exploited vulnerability. If you don't have SBOMs and a vulnerability management process in place before September 2026, you can't comply.
Existing PSIRT Processes Need Augmentation
Most product security incident response processes weren't designed for 24-hour regulatory reporting. Key gaps to address:
- Real-time awareness of exploitation status across dependencies
- Defined internal triggers for 'becoming aware' (ambiguity here creates compliance risk)
- Pre-approved templates and workflow for rapid ENISA/CSIRT notification
- Clear escalation paths that can execute within 24 hours including weekends and holidays
Document Your Interpretations
The CRA leaves some areas open to interpretation, particularly around 'becoming aware' and scope boundaries for hybrid products. Document your organization's interpretation of these grey areas now, before you're making decisions under pressure. If regulators later disagree with your interpretation, a documented rationale demonstrates good faith compliance efforts.
Coordination with Managed Security Providers
For organizations using managed SOC or SIEM services, ensure your provider understands CRA reporting obligations and can support rapid escalation:
- Alert correlation should flag exploitation indicators related to your product dependencies
- Incident notification workflows should include CRA-specific escalation paths
- Documentation and evidence retention should support regulatory reporting requirements
Need Help Preparing for CRA?
Exposure Security can help your organization prepare for CRA compliance. We offer:
- Scoping assessments and documentation templates
- PSIRT process reviews and CRA-aligned procedures
- Reporting templates for ENISA/CSIRT submissions
- Standards and procedures tailored to your product portfolio
- Advisory services for documenting regulatory interpretations in grey areas (awareness triggers, hybrid product scope, and other ambiguous requirements)
Contact us to discuss how we can support your CRA readiness efforts.
Appendix
Primary Sources
European Commission CRA Summary
CRA Full Text
CRA Article 14: Reporting Obligations
ENISA Single Reporting Platform (SRP)
Open Regulatory Compliance Working Group
- orcwg.org/cra
- Industry working group resources for CRA compliance
EC Guidance on 'Becoming Aware'
The European Commission's draft CRA implementation guidance clarifies when the reporting clock starts:
- Awareness occurs when, after an initial assessment of a detected or reported suspicious event, the manufacturer has reasonable certainty that a vulnerability is being actively exploited.
- This interpretation aligns with related EU guidance (e.g., NIS2) to ensure consistency across regulatory reporting requirements.
Source: European Commission CRA Implementation Guidance (March 2026)
Vulnerability Intelligence Sources
CISA Known Exploited Vulnerabilities (KEV) Catalog
- cisa.gov/known-exploited-vulnerabilities-catalog
- U.S. Cybersecurity and Infrastructure Security Agency's authoritative list of vulnerabilities with confirmed active exploitation. Updated frequently; a KEV listing is strong evidence of 'active exploitation' for CRA purposes.
CVE Program
- cve.org
- Common Vulnerabilities and Exposures database. CVE publication alone does not indicate active exploitation; cross-reference with KEV or exploitation reports.
Software Bill of Materials (SBOM)
An SBOM is a formal, machine-readable inventory of software components and dependencies. CRA Annex I, Part II requires manufacturers to 'identify and document vulnerabilities and components contained in products, including by drawing up a software bill of materials.'
SBOM Resources
- Syft, CycloneDX CLI: Open-source tools for generating SBOMs from source code, container images, or binaries
- SPDX and CycloneDX: Industry-standard SBOM formats accepted by most vulnerability management platforms
- GitHub Dependency Graph: Built-in SBOM export for repositories hosted on GitHub
SBOM Best Practices
- Generate SBOMs automatically as part of your CI/CD pipeline
- Include transitive dependencies (dependencies of your dependencies)
- Store SBOMs in a central repository with version tracking
- Integrate SBOM data with vulnerability monitoring tools
- Verify the integrity of SBOM generation tools themselves; supply chain attacks have targeted security tooling
NIS2 Directive
- eur-lex.europa.eu/eli/dir/2022/2555
- Network and Information Security Directive 2. Applies to 'essential' and 'important' entities providing services (not products). Pure SaaS providers typically fall under NIS2 rather than CRA. Organizations may be subject to both if they provide both products and services.
Key Definitions
- Products with digital elements: Hardware or software products designed to connect to devices or networks, directly or indirectly
- Remote data processing solution: Data processing carried out remotely where the software is designed by or for the manufacturer and the absence of which would prevent the product from performing one of its functions
- Actively exploited vulnerability: A vulnerability for which there is reliable evidence that a malicious actor has exploited the vulnerability in a system without permission of the system owner.
Note:
This refers to exploitation anywhere in the wild, not exploitation in your specific environment.
This briefing is part of Exposure Security's ongoing executive intelligence series. For questions about how this applies to your organization specifically, contact us.