- Vulnerability and incident reporting rules under Article 14 of the Cyber Resilience Act (Regulation EU 2024/2847) apply from 11 September 2026 .
- This requirement applies to products already on the market. Manufacturers must report actively exploited vulnerabilities to ENISA and their national CSIRT within 24 hours.
- Software SMEs must establish a security contact, a triage workflow, and a software bill of materials (SBOM) ahead of this date.
CRA in brief: The Cyber Resilience Act (Regulation EU 2024/2847) sets EU cybersecurity requirements for products with digital elements placed on the EU market, including software. Article 14 vulnerability and incident reporting rules take effect on 11 September 2026 . Comprehensive product rules take effect on 11 December 2027 .
Key takeaways
- Scope of rules becoming mandatory on 11 September 2026
- The three-stage reporting cascade: 24 hours, 72 hours, 14 days
- Application to products already on the market , including existing releases
- Necessity of a Software Bill of Materials (SBOM) before the 2027 mandate
- Rules governing open source and limits of commercial activity
The early reporting mandate
Teams often classify the Cyber Resilience Act alongside 2027 obligations. Technical documentation, CE marking, conformity assessment, and essential cybersecurity requirements take effect on 11 December 2027.
Article 14 applies earlier. From 11 September 2026 , manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents to ENISA and their national CSIRT.
Two factors create urgency:
First, it applies to products already on the market. The regulation includes no grandfathering. If customers use your software in the EU on 11 September 2026 and an actively exploited vulnerability emerges, reporting obligations apply regardless of the original release date.
Second, the clock runs for 24 hours. Teams cannot build vulnerability disclosure workflows after receiving an exploit notification. The operational process must exist before 10 September.
For software SMEs, 11 September represents an operational readiness milestone with a fixed calendar date.
Article 14 requirements
Two events trigger reporting: actively exploited vulnerabilities in your product, and severe incidents affecting product security.
Handle internal test findings through routine vulnerability management. Report vulnerabilities undergoing active exploitation against users.
The reporting cascade
| Stage | Deadline | Recipient | Content |
|---|---|---|---|
| Early warning | Within 24 hours of becoming aware | ENISA and national CSIRT via single reporting platform | Existence of an actively exploited vulnerability or severe incident; affected Member States if known |
| Notification | Within 72 hours of becoming aware | ENISA and national CSIRT | General product details, nature of exploitation, corrective or mitigating measures taken |
| Final report | Within 14 days of corrective measure availability (vulnerabilities); within 1 month (severe incidents) | ENISA and national CSIRT | Vulnerability description, severity, impact, known exploit details, corrective measures |
Awareness triggers the deadline, not confirmation. If a security researcher emails your security contact on Friday at 14:00 with details of active exploitation, the 24-hour clock begins on Friday at 14:00.
Requirements for 11 September readiness
- Monitored security contact. Publish a dedicated security address for vulnerability reports rather than routing to generic support queues.
- Defined triage workflow. Designate team members to assess incoming reports within hours and escalate active exploits.
- Product inventory. Maintain a definitive list of supported products, deployed versions, and maintained forks.
- Reporting platform access. ENISA operates the single reporting platform for CRA notifications. Register and verify user access ahead of time.
- Software Bill of Materials (SBOM). Maintain an up-to-date inventory of third-party software components.
Why an SBOM is necessary in 2026, not 2027
Statutory SBOM mandates form part of technical documentation rules taking effect in December 2027. Deferring SBOM implementation until 2027 fails under September 2026 requirements.
When an actively exploited vulnerability emerges in a common dependency, your team must determine within 24 hours whether your product contains the affected component. Manual code audits across all delivered versions cannot complete within 24 hours.
A maintained SBOM provides the visibility required to meet the 24-hour deadline.
Practical SME baseline:
- Generate an SBOM per version in SPDX or CycloneDX format within your build pipeline
- Store SBOMs for every version still supported or deployed at customer sites
- Connect SBOMs to vulnerability feeds to match new CVEs against your dependency tree
- Include transitive dependencies where third-party software risks concentrate
Build tooling generates SBOMs without software licence fees. Engineering integration requires several days of setup before the September deadline.
End-of-life dependencies
End-of-life dependencies no longer receive upstream security patches. If an exploit targets an unmaintained component in your software, Article 14 still requires a warning within 24 hours and a final report detailing remediation. Lacking upstream maintenance does not qualify as an approved corrective measure.
Audit your dependency tree to identify unmaintained packages. Options include upgrading, replacing components, purchasing extended commercial support, or maintaining a private fork. Each option requires more than 24 hours to execute.
Scope and covered entities
The CRA applies to manufacturers of products with digital elements placed on the EU market. Manufacturer status covers any entity that develops software or has software developed to commercialise under its brand name.
| Profile | In Scope? | Details |
|---|---|---|
| Commercial Software Vendor (EU) | ✅ Yes | Core scope |
| SaaS Provider | ⚠️ Partial | Pure SaaS falls under NIS2 rather than the CRA; software distributed for local client execution falls under the CRA. Evaluate by product. |
| Hardware / IoT Manufacturer | ✅ Yes | Core scope |
| Firmware Developer | ✅ Yes | Core scope |
| Non-EU Vendor Selling in the EU | ✅ Yes | Applies to products placed on the EU market; importer and representative rules apply |
| Non-Commercial Open Source Developer | ❌ No | Excluded from scope |
| Open Source Steward / Commercial OSS | ⚠️ Partial | Lighter rules apply to stewards; full obligations apply when commercialised |
| Internal Enterprise Software User | ❌ No | Not classified as a manufacturer |
Non-EU software SMEs: The CRA applies based on market placement. Software offered to EU customers falls within scope regardless of corporate headquarters location. Non-EU vendors must designate an EU-established importer or authorised representative for December 2027.
Open source provisions
The CRA excludes open source software developed and supplied outside commercial activity.
Scope depends on commercial activity rather than open source licensing. Commercial activity indicators include:
- Charging for software, support, or hosted versions
- Offering paid enterprise editions alongside free tiers
- Distributing software components within commercial products
- Employing developers to maintain software for corporate commercial purposes
The text establishes the open source software steward status for foundations supporting open source development without direct commercialisation. Stewards follow adapted rules focused on security policies and regulatory cooperation.
Commercial product manufacturers retain full vendor responsibility for integrated open source components. Upstream maintainers do not carry manufacturer liability. For software incorporating AI models, consult our guide on AI Act compliance tools .
Risk classes and conformity pathways
The CRA categorises products by risk level to define December 2027 conformity assessment procedures. The 11 September 2026 reporting obligations apply uniformly across all classes.
| Class | Examples | Conformity Pathway |
|---|---|---|
| Default (Most Products) | Business software, consumer apps, general IoT | Internal control (self-assessment) |
| Important Class I | Browsers, password managers, VPNs, network management, security smart home devices | Self-assessment using harmonised standards, or third-party assessment |
| Important Class II | Operating systems, firewalls, industrial control systems, microprocessors | Mandatory third-party conformity assessment |
| Critical | Hardware security modules, smartcards, secure elements | European cybersecurity certification scheme |
Most software SMEs fall into the default class and can self-assess conformity. Vendors of security-related tools, such as identity management or network protection, must verify Class I and Class II criteria to prepare for external audit costs.
Penalties
| Violation | Maximum Fine |
|---|---|
| Essential cybersecurity requirements or manufacturer obligations | €15M or 2.5% of annual worldwide turnover, whichever is higher |
| Other statutory obligations | €10M or 2% of annual worldwide turnover |
| Supplying incorrect, incomplete, or misleading information to authorities | €5M or 1% of annual worldwide turnover |
Submitting inaccurate reports under pressure creates regulatory risks alongside reporting delays. Establish operational processes that produce accurate notifications quickly.
Software vendors in EU accession countries
Western Balkans, Ukraine, Moldova, Georgia: Candidate countries align cybersecurity frameworks under accession chapters 10 (Information Society and Media) and 1 (Free Movement of Goods).
Current alignment: No candidate country has transposed the CRA, though several consult on NIS2-aligned cybersecurity frameworks.
Immediate obligation: The CRA applies upon placing a product on the EU market. Vendors in Belgrade, Podgorica, Kyiv, or Tirana distributing software to EU customers must meet 11 September 2026 reporting rules under the same conditions as EU companies.
Operational impact: Regional exporting vendors must deploy the same incident reporting workflows as EU sellers. Implementing SBOM and vulnerability triage practices now prevents emergency adjustments during incidents. Consult guidance from ENISA or national authorities such as ANSSI .
6-week action plan
- Confirm status in writing. Document whether your company qualifies as a manufacturer placing digital products on the EU market.
-
Publish a security contact and disclosure policy.
Deploy a
security.txtfile and monitor the listed address. - Define triage and escalation workflows. Name individuals responsible for evaluating reports and authorizing regulatory notifications.
- Generate SBOMs for supported releases. Automate creation in SPDX or CycloneDX format within your build pipeline.
- Connect SBOMs to vulnerability feeds. Monitor dependency trees continuously against new CVEs.
- Audit end-of-life dependencies. Select replacement or maintenance strategies for unmaintained components.
- Register on the ENISA platform. Validate user credentials before a real incident occurs.
- Conduct a simulation exercise. Test team responsiveness against the 24-hour early warning window.
Frequently Asked Questions
Which CRA provisions apply on 11 September 2026?
Does the September 2026 obligation apply to software already on the market?
Do I need an SBOM by September 2026?
Does the Cyber Resilience Act apply to open source software?
Does the CRA apply to software companies outside the EU?
This article is for informational purposes only and does not constitute legal advice. For advice specific to your situation, consult a qualified legal professional.
Themio.ai maps your Cyber Resilience Act obligations by product and risk class, and identifies what must be in place before 11 September 2026 (in under 2 minutes), with every finding traceable to the article it comes from. See how it works →