EU Cyber Resilience Act Reporting Starts September 11, 2026: What Software Vendors Need Ready

The EU Cyber Resilience Act does not wait until its broader product-security rules apply in December 2027. From 11 September 2026, manufacturers of in-scope products with digital elements must report actively exploited vulnerabilities and severe security incidents.

The first warning is due within 24 hours of becoming aware of a reportable event, followed by a fuller notification within 72 hours. Final reporting follows later. Reports go through ENISA's new Single Reporting Platform.

For software vendors, the immediate problem is operational rather than theoretical. A company needs to know which products are in scope, what counts as a reportable event, who can declare that the reporting clock has started, and how engineering, security, legal and product teams can assemble reliable information quickly enough.

This guide focuses on that September 2026 readiness problem.

What changes on September 11, 2026?

Article 14 of the Cyber Resilience Act starts applying on 11 September 2026, more than a year before most of the CRA applies.

The European Commission's CRA reporting guidance states that manufacturers must report:

• actively exploited vulnerabilities contained in products with digital elements
• severe incidents having an impact on the security of those products

The reporting sequence is:

The Commission also confirms that the CRA's broader obligations generally apply from 11 December 2027, while Article 14 reporting starts on 11 September 2026. See the CRA summary.

So September is not the deadline to finish every CRA conformity or CE-marking project. It is the deadline to make sure the organisation can detect, classify, escalate and report qualifying security events on time.

Does the reporting duty apply to existing products?

Yes. The reporting obligations are not limited to products launched after September 2026.

The Commission's CRA summary explains that Article 14 reporting applies to products with digital elements made available on the Union market, including products already placed on the market before the main CRA application date.

That means a company planning its CRA programme around a 2027 release can still have September 2026 reporting exposure for older products such as:

• desktop software
• mobile applications
• downloadable developer tools
• connected-device software
• commercial open-source products
• software bundled with hardware
• older supported product versions

The first readiness exercise should therefore be a product inventory, not a code rewrite.

What is a "product with digital elements"?

The CRA uses a broad product concept.

The Commission's legislative summary describes a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components made available separately.

A useful first-pass scope screen is:

Do we make software or hardware available on the EU market?
        ↓
Does it connect directly or indirectly to a device or network?
        ↓
Are we the manufacturer under the CRA definition?
        ↓
Does an exclusion or sector-specific regime apply?
        ↓
Potential CRA product

This is a screening framework, not legal advice.

Does the CRA apply to SaaS?

Not every SaaS service automatically becomes a CRA product.

The CRA includes remote data processing solutions when the remote processing is designed and developed by, or under the responsibility of, the manufacturer and the product would be unable to perform one of its functions without that remote processing.

So:

Installed/marketed software
        ↓
Vendor-operated cloud processing
        ↓
Required product function

can be different from an unrelated standalone cloud service.

The Commission's final practical guidance published on 27 July 2026 specifically addresses remote data processing and other scope questions. See Commission guidance on CRA implementation.

Software vendors should classify the actual architecture, not use "we are SaaS" as a blanket answer.

What is an actively exploited vulnerability?

The Article 14 trigger is more specific than "a CVE exists".

ENISA's Single Reporting Platform FAQ defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission.

A practical triage flow is:

Vulnerability signal
        ↓
Is our product/component affected?
        ↓
Is exploitation possible in our product?
        ↓
Is there reliable evidence of active malicious exploitation?
        ↓
If yes, assess Article 14 reporting

Ordinary vulnerabilities still need appropriate handling even when they do not trigger Article 14 reporting.

What if the issue is in a third-party dependency?

Third-party components do not remove the final product manufacturer's need to assess its own product.

Modern products commonly contain frameworks, packages, operating-system libraries, container images, SDKs and firmware components.

When a dependency is implicated, the team needs to answer quickly:

• Which products contain it?
• Which versions contain it?
• Is the vulnerable code reachable?
• Is the product actually affected?
• Is a patch or mitigation available?
• Which users or releases need action?

This makes dependency visibility a reporting-readiness capability.

A software bill of materials can help, but the immediate operational requirement is the ability to map a vulnerable component to affected commercial products and versions within hours rather than days.

What counts as a severe security incident?

ENISA describes a reportable severe incident as one having a severe impact on the security of a product with digital elements.

The CRA focuses on effects on the product's ability to protect:

• availability
• authenticity
• integrity
• confidentiality

ENISA's reporting fields also account for incidents that introduce or could introduce malicious code into a product or a user's network and information systems.

This means a conventional infrastructure severity score is not enough.

A cloud outage may be operationally severe without being a CRA severe security incident. A compromise of product-update integrity may be highly significant even with limited downtime.

Ask:

What happened to the security properties of the product, not merely how disruptive was the outage?

When does the 24-hour clock start?

The clock is tied to the manufacturer becoming aware of the reportable vulnerability or incident.

That makes escalation design critical.

Weak:

Researcher email
→ support inbox
→ engineer sees it tomorrow
→ security team hears later
→ nobody agrees when the clock started

Stronger:

Security signal received
        ↓
Case ID created
        ↓
Prompt technical assessment
        ↓
Reportability decision
        ↓
Awareness timestamp recorded
        ↓
24-hour workflow starts

Preserve:

• when the signal arrived
• who received it
• when assessment began
• evidence reviewed
• affected product/version
• reportability decision
• decision timestamp
• decision owner

Do not reconstruct that timeline from chat messages after the deadline.

What information is needed for reporting?

The first warning is deliberately lighter than the final report.

ENISA's current SRP FAQ publishes the planned reporting fields. Depending on stage, they include:

• notification type and level
• manufacturer or open-source software steward
• affected product
• relevant Member States where available
• basic vulnerability/incident information
• exploit or incident description
• corrective or mitigating measures
• actions users can take
• detection and occurrence timing
• severity and impact
• root cause or threat type
• security-update details

The important design lesson is:

Do not treat the 24-hour warning as a completed forensic report.

The first stage establishes awareness and essential facts. The 72-hour and final stages carry progressively richer information.

How are reports submitted?

Reporting is designed to go through ENISA's Single Reporting Platform (SRP).

The Commission says manufacturers report once through the platform, which routes the notification to the relevant CSIRT designated as coordinator and, except in particular exceptional circumstances, simultaneously to ENISA.

ENISA says the SRP is scheduled to be operational on 11 September 2026.

Its Assigned Representative registration guidance says representatives authenticate through EU Login. Validation by the relevant CSIRT happens after first access and does not block notification submission.

ENISA also says no reporting API will be provided at this stage.

So automate the internal process:

detection
→ triage
→ data collection
→ deadline tracking
→ approval
→ report preparation

but do not build an imaginary ENISA API integration.

What should software vendors have ready before September 11?

1. A CRA product register

For each potentially in-scope product, record:

2. One vulnerability intake process

Signals can come from:

• researchers
• customer support
• scanners
• vendors
• CSIRTs
• ENISA/EUVD
• CVE feeds
• GitHub advisories
• EDR/security monitoring
• internal testing

Route them into one traceable case process.

3. A reportability checklist

Capture:

Product affected?
Version affected?
Third-party component?
Reliable evidence of active exploitation?
Severe product-security incident?
Security properties affected?
Known user impact?
Mitigation available?

4. A 24-hour escalation chain

For example:

Security analyst
→ product/security owner
→ CRA reporting lead
→ legal/compliance review
→ submission owner

Every critical role needs a backup.

5. An internal reporting schema

Model known fields before an incident:

{
  "caseId": "CRA-2026-0017",
  "notificationType": "VULNERABILITY",
  "product": "Example Desktop Agent",
  "affectedVersions": ["4.2.x", "4.3.0"],
  "awarenessAt": "2026-09-12T08:15:00Z",
  "activeExploitationEvidence": [],
  "mitigations": [],
  "userActions": []
}

This is an internal example, not ENISA's exact submission format.

6. Deadline automation

Once a case is deemed reportable:

awareness
→ +24h early warning
→ +72h fuller notification
→ vulnerability: final report after remediation deadline
→ severe incident: final report within the required one-month period

Use your incident platform, task system or an internal tool. The clock should not live in someone's memory.

A practical reporting architecture

Security inputs
  ├─ disclosure inbox
  ├─ scanners/advisories
  ├─ customer reports
  └─ incident monitoring
          ↓
Security case system
          ↓
Product/component lookup
          ↓
CRA triage
  ├─ not reportable → normal vulnerability process
  └─ potentially reportable
          ↓
Awareness timestamp + deadline engine
          ↓
24h / 72h report workspace
          ↓
Approval
          ↓
ENISA SRP submission
          ↓
Submission evidence
          ↓
Patch / mitigation / user communication
          ↓
Final report

The useful part is not the diagram. It is that each stage has an owner, timestamp and evidence trail.

Do you need a perfect SBOM before September 11?

No, but you do need fast product-impact analysis.

If lock files, artifact manifests, container inventories, dependency scanners and release metadata already let the team identify affected products reliably, a perfect enterprise SBOM programme does not need to block September readiness.

Ask one operational question:

When a dependency becomes actively exploited, can we identify every affected product and version within hours?

If the answer is no, dependency visibility is urgent.

What about small companies?

The CRA includes proportionality measures, but small size is not a reason to ignore the reporting workflow.

The Commission's CRA summary notes that qualifying microenterprises and small enterprises cannot be fined for failing to meet the 24-hour deadline for reporting vulnerabilities and severe incidents.

That is not the same as a blanket exemption from Article 14 reporting.

A proportionate minimum can be:

• one security intake channel
• one primary and one backup reporting owner
• product/version inventory
• dependency visibility
• reportability checklist
• deadline reminders
• secure evidence storage
• user communication template

A disciplined lightweight process is better than an expensive platform nobody operates.

What about open-source software?

ENISA says open-source software stewards have reporting obligations to the extent set out in the CRA.

That is more specific than "everyone maintaining a public repository".

Commercial involvement, stewardship role and CRA definitions matter. Organisations that commercially support or systematically steward open-source products should use the Commission's 2026 guidance for scope analysis rather than assuming an open-source licence automatically removes CRA obligations.

Should reporting be automated?

Automate workflow and evidence collection, not the legal/security judgement.

Good automation targets:

• product/version lookup
• dependency mapping
• CVE/EUVD enrichment
• deadline calculation
• reviewer assignment
• missing-field checks
• report draft generation
• submission evidence
• follow-up tasks

Do not automatically report every critical scanner alert.

The statutory triggers involve active exploitation and severe product-security incidents, not merely CVSS severity.

Seven tabletop tests before September 11

Dependency exploit

A library used in three products is reported as actively exploited. Can you identify affected releases within two hours?

Weekend disclosure

A credible researcher report arrives Saturday morning. Does someone see and triage it?

Uncertain exploitation

A critical CVE exists but exploitation evidence is unclear. Who decides reportability and records why?

Legacy product

A 2024 release still used in the EU is affected. Can you find ownership, affected versions and communication channels?

Third-party component

Can the team determine whether the vulnerable code path is actually reachable in the product?

Reporting/platform problem

If the reporting platform or an internal system has an issue near the deadline, is there a documented escalation and evidence trail?

Primary owner unavailable

If the usual reporting lead is absent, is a trained backup ready?

Any answer of "we would figure that out during the incident" identifies work to finish now.

September 2026 readiness checklist

• □Potential CRA products inventoried
• □Legacy products included
• □Product/security owners named
• □Vulnerability reports enter a traceable case system
• □Dependencies can be mapped to products and versions
• □CRA reportability checklist exists
• □Awareness decisions and timestamps are recorded
• □24h/72h deadline alerts are automatic
• □Primary and backup submission owners exist
• □EU Login/SRP access guidance has been reviewed
• □Known SRP fields are represented internally
• □User-notification channels are known
• □Submission evidence can be stored securely
• □A tabletop exercise has been completed
• □The team distinguishes September reporting from December 2027 full CRA compliance

What not to do

Do not wait until December 2027

Article 14 starts on 11 September 2026.

Do not report every vulnerability as actively exploited

The trigger is more specific than "a CVE exists".

Do not ignore older products

Reporting can apply to products already available on the EU market.

Do not treat CVSS as the legal trigger

CVSS can support prioritisation, but active exploitation and CRA incident criteria are separate.

Do not build an ENISA reporting API integration today

ENISA currently says no reporting API is planned at this stage.

Do not make one employee the reporting system

Use primary and backup roles plus a durable evidence trail.

Do not assume "SaaS" settles scope

Remote data processing can form part of an in-scope product. Analyse the actual product architecture and current Commission guidance.

FAQs

When do Cyber Resilience Act reporting obligations start?

Article 14 reporting starts on 11 September 2026. Most broader CRA obligations apply from 11 December 2027.

What must be reported within 24 hours?

Manufacturers must provide an early warning after becoming aware of an actively exploited vulnerability in an in-scope product or a severe incident affecting the product's security.

Does every vulnerability need to be reported?

No. The Article 14 vulnerability trigger concerns actively exploited vulnerabilities, where there is reliable evidence of malicious exploitation.

Where are CRA reports submitted?

ENISA is establishing the Single Reporting Platform as the reporting entry point. Notifications are routed to the appropriate national CSIRT coordinator and, except in particular exceptional circumstances, ENISA.

Does the deadline apply to software already on the market?

Yes. The reporting obligations are not limited to products first placed on the market after September 2026.

Is SaaS automatically covered?

No. Scope depends on the actual product and architecture. Remote data processing can be part of an in-scope product when the product relies on it for a function.

Conclusion

The first major Cyber Resilience Act deadline is an incident-response deadline, not a CE-marking deadline.

From 11 September 2026, in-scope manufacturers need to move from:

security signal
→ product impact
→ reportability decision
→ awareness timestamp
→ 24-hour warning
→ 72-hour notification
→ mitigation
→ final report

without inventing the process after the clock has started.

For software vendors, the most valuable work now is practical: know the products, know the dependencies, centralise vulnerability intake, define reportability, record awareness, automate deadlines, assign backups and rehearse the workflow.

The broader CRA programme continues toward December 2027, but those later conformity obligations should not distract from the reporting duty arriving first.

If your software business needs to turn security, product inventory and incident workflows into a maintainable internal system, Softotic's custom software development service can help design the operational tooling, while web application development can support secure internal dashboards and workflow interfaces.

Sources and references

• European Commission: Cyber Resilience Act reporting obligations
• ENISA: Cyber Resilience Act Single Reporting Platform FAQ
• ENISA: CRA SRP Assigned Representative user registration
• European Commission: Cyber Resilience Act summary
• European Commission: 2026 Cyber Resilience Act implementation guidance
• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act