The September 2026 CRA Reporting Deadline | Embedded Manufacturers Act Now

Most embedded and IoT manufacturers are watching the EU Cyber Resilience Act deadline in December 2027.

That is important but it is not the first deadline that should worry product teams.

The real operational deadline arrives earlier.

On 11 September 2026, the CRA reporting obligations began. From that date, manufacturers of products with digital elements must be ready to report actively exploited vulnerabilities and severe incidents affecting the security of their products.

For embedded manufacturers, this is not just a legal milestone. It is an engineering readiness test.

If your product contains firmware, connected software, remote update capability, cloud connectivity, third-party components, open-source packages, or field-deployed devices, you need more than a compliance plan. You need a working vulnerability reporting process.

What is the September 2026 CRA Reporting Deadline:

The September 2026 CRA reporting deadline means manufacturers must be prepared to notify authorities about serious cybersecurity issues before the full CRA enforcement date in December 2027.

This creates an early compliance obligation.

The full CRA framework becomes applicable later, but vulnerability reporting starts first. That means companies cannot wait until 2027 to build their internal cybersecurity processes.

By September 2026, manufacturers should already have:

A vulnerability intake process
Product security ownership
SBOM and component visibility
Incident triage workflows
Secure update and patching procedures
Documentation for affected products and versions
A clear escalation path for severe incidents
A reporting process aligned with ENISA and the CRA Single Reporting Platform

In simple terms; if a vulnerability is actively exploited in your embedded or IoT product, you need to know what happened, which devices are affected, how severe the issue is, and how to report it quickly.

CRA Deadlines Manufacturers Should Know

There are two CRA dates every embedded product team should separate clearly.

11 September 2026 | Reporting Obligations Begin

This is the early deadline for reporting:

Actively exploited vulnerabilities
Severe incidents impacting the security of products with digital elements

This deadline is especially important for connected devices, firmware-based products, industrial IoT systems, gateways, controllers, and products with OTA update capability.

11 December 2027 | Main CRA Obligations Apply

This is when the main CRA obligations apply more broadly, including secure-by-design requirements, conformity assessment, CE marking alignment, technical documentation, vulnerability handling, and lifecycle security obligations.

The mistake many manufacturers make is thinking they can wait until 2027. They cannot. The September 2026 CRA deadline requires operational readiness much earlier.

What Must Be Reported Under the CRA?

The CRA focuses reporting on cybersecurity issues that can create real risk in the field.

Manufacturers need to report:

1) Actively Exploited Vulnerabilities

An actively exploited vulnerability is not just a theoretical weakness.

It means attackers are already using, or attempting to use, the vulnerability in real-world conditions.

For embedded products, this could include:

A firmware vulnerability being exploited remotely
Weak authentication in a connected gateway
Exploitable update mechanisms
Hardcoded credentials discovered in deployed devices
A bootloader weakness allowing unauthorized firmware
A cloud API flaw affecting device control
A vulnerable open-source library inside firmware

This is where visibility matters.

If you do not know which firmware versions, components, or software packages are deployed across your product fleet, reporting becomes difficult very quickly.

2) Severe Incidents Affecting Product Security

A severe incident is an event that has a significant impact on the security of the product with digital elements.

For example:

Unauthorized access to device management systems
Compromise of signing keys or update infrastructure
Large-scale exploitation of connected devices
Security failure affecting remote control or telemetry
Attackers manipulating device behavior
Severe disruption caused by a cybersecurity flaw

For manufacturers of embedded and IoT products, this requires coordination between engineering, security, support, compliance, and leadership.

A support ticket cannot be the first time your company thinks about incident response.

ENISA 24-Hour Reporting: Why Speed Matters

One of the most important requirements is speed.

Manufacturers must be ready to submit an early warning within 24 hours after becoming aware of an actively exploited vulnerability or severe incident.

This is why ENISA 24-hour reporting is such an important operational keyword for embedded manufacturers.

A 24-hour window is short.

You cannot build a reporting process after the incident happens. You need a predefined workflow before the deadline arrives.

That workflow should answer:

Who receives vulnerability reports?
Who decides whether the issue is reportable?
Who confirms whether exploitation is active?
Who identifies affected product versions?
Who communicates with authorities?
Who approves customer communication?
Who owns patch development?
Who tracks the final resolution?

Without clear ownership, 24 hours disappears fast.

Why Embedded and IoT Manufacturers Face a Bigger Challenge

For many software companies, vulnerability reporting is already part of daily security operations.

For embedded manufacturers, it is often more complicated.

Embedded products usually involve:

Firmware releases across multiple hardware variants
Bootloaders and low-level code
Third-party libraries
Real-time operating systems or embedded Linux distributions
Long product lifecycles
Field-deployed devices with limited connectivity
OTA update constraints
Industrial or safety-sensitive environments
Hardware root of trust and secure boot dependencies
Regional product variations

That means a vulnerability is rarely “just a software ticket.”

It may affect firmware integrity, device availability, update safety, regulatory documentation, customer operations, and product trust.

This is why the CRA early deadline matters so much.

The September 2026 deadline forces manufacturers to prove they can detect, understand, report, and respond to product security issues while devices are already in the field.

The SBOM Connection: Why Component Visibility Matters Before September 2026

Many teams search for terms like SBOM mandatory September 2026 because they understand the connection between vulnerability reporting and software transparency.

A better way to think about it is this:

If you need to report actively exploited vulnerabilities quickly, you need to know what software components are inside your product.

That is exactly where an SBOM becomes critical.

An SBOM, or Software Bill of Materials, helps manufacturers identify:

Open-source packages
Third-party libraries
Firmware components
Kernel versions
Bootloader dependencies
Cryptographic libraries
Middleware
Build-time and runtime components

Without an SBOM, teams may not know whether a new CVE affects their product.

Without version mapping, they may not know which customers or deployed devices are affected.

Without build traceability, they may not know which firmware images contain the vulnerable component.

So even if your full CRA conformity work continues toward 2027, your SBOM process should be operational well before September 2026.

What Embedded Manufacturers Should Prepare Now

The companies that handle the September 2026 CRA reporting deadline well will not be the ones that write a policy at the last minute.

They will be the ones that turn vulnerability handling into a repeatable engineering process.

Here is what manufacturers should start building now.

1) Confirm Which Products Are in CRA Scope

Start by identifying which products qualify as products with digital elements.

For embedded and IoT manufacturers, this may include:

Connected industrial controllers
IoT gateways
Smart meters
Sensor devices
Pump and motor controllers
Firmware-based monitoring systems
Embedded Linux devices
Products with mobile or cloud connectivity
Devices with OTA update capability
Software-enabled hardware platforms

If your product connects directly or indirectly to a network or another device, it may fall under CRA scope.

2) Create a Vulnerability Intake Process

Your company needs a clear way to receive vulnerability reports.

This may include:

A public security contact
A vulnerability disclosure page
A dedicated security email
Internal triage ownership
Response time expectations
A process for external researchers
A way to track submitted issues

If vulnerability reports go to a general support inbox, they may be missed, delayed, or mishandled.

3) Build a PSIRT or Product Security Workflow

A full Product Security Incident Response Team may not be realistic for every company, especially smaller manufacturers.

But every embedded company needs a PSIRT-style workflow.

That means assigning responsibility for:

Vulnerability triage
Technical impact analysis
Exploitability assessment
Product version mapping
Patch planning
Customer communication
CRA reporting decisions
Documentation and closure

The goal is not bureaucracy. The goal is speed, clarity, and accountability.

4) Generate and Maintain SBOMs

SBOMs should not be created manually once per year.

For embedded products, the SBOM should ideally be generated as part of the build and release process.

A practical SBOM workflow should include:

CycloneDX or SPDX format
Component names and versions
Open-source dependency tracking
Firmware image mapping
Release-to-SBOM traceability
CVE monitoring
Archive of SBOMs per firmware release

This makes vulnerability reporting faster and more accurate.

5) Map Firmware Versions to Deployed Products

Knowing that a vulnerability exists is not enough.

You need to know which products are affected.

Manufacturers should maintain traceability between:

Product model
Hardware revision
Firmware version
Bootloader version
SBOM version
Release date
Customer or deployment batch
Update status

This is essential for vulnerability reporting embedded products because many devices remain deployed for years.

6) Prepare Secure OTA Update Workflows

If a vulnerability is actively exploited, reporting is only one part of the response.

You also need a corrective measure.

For connected embedded products, that often means secure OTA updates.

A CRA-ready OTA process should include:

Firmware signing
Encrypted transport
Rollback protection
A/B update partitions where appropriate
Version control
Update logs
Failure recovery
Device health checks
Controlled rollout strategy

If your update mechanism is not secure, the patch process itself can become an attack path.

7) Define Internal Reporting Timelines

Do not design your internal process around the external deadline.

Design it to move faster.

For example:

Security report received: same day
Initial triage: within hours
Exploitability check: same day
Product impact mapping: within 24 hours
Reporting decision: before external deadline
Patch plan: immediately after confirmation
Customer communication: aligned with legal and security teams

This gives your team enough room to meet the CRA’s reporting expectations without chaos.

8) Prepare for the CRA Single Reporting Platform

Manufacturers will use the CRA Single Reporting Platform for mandatory reporting.

That means companies should prepare assigned roles, internal approvals, product information, and notification workflows before the system becomes operational.

You should know:

Who is authorized to submit reports?
Which company entity is responsible?
Which product data must be included?
Who maintains access credentials?
Who validates technical content before submission?
Who tracks follow-up updates and final reports?

This should be part of your CRA compliance roadmap.

Common Mistakes Manufacturers Should Avoid

The September 2026 CRA reporting deadline is not difficult because the concept is unclear.

It is difficult because many companies are not operationally prepared.

Common mistakes include:

Waiting Until 2027

The full CRA compliance deadline may be December 2027, but reporting starts in September 2026.

Waiting until 2027 means you may already miss the first operational obligation.

Treating SBOM as a Documentation Task

SBOM is not just a PDF or spreadsheet.

It should be connected to your build system, release process, vulnerability monitoring, and product lifecycle.

Having No Product Security Owner

If everyone is responsible, no one is responsible.

A named owner or team must manage vulnerability triage, reporting, and remediation.

Ignoring Legacy Products

CRA reporting obligations can matter for products already made available on the EU market.

If old firmware versions are still deployed, they should not be invisible to your security process.

Confusing IT Security With Product Security

Corporate IT incident response is not the same as embedded product vulnerability management.

Product security must understand firmware, hardware, OTA pipelines, device fleets, customer deployments, and regulatory impact.

What a CRA Reporting Readiness Checklist Should Include

Before September 2026, embedded manufacturers should be able to answer these questions:

Do we know which products are in CRA scope?
Do we have a vulnerability disclosure process?
Do we have a responsible product security owner?
Can we identify affected firmware versions quickly?
Do we generate SBOMs for firmware releases?
Can we map components to deployed products?
Do we monitor CVEs and actively exploit vulnerabilities?
Do we have a secure OTA or patch delivery process?
Can we prepare an early warning within 24 hours?
Can we submit a full notification within 72 hours?
Can we document corrective actions and final reports?
Are engineering, compliance, legal, and support aligned?

If the answer to several of these is “not yet,” the deadline is closer than it looks.

How Epteck Helps Embedded Manufacturers Prepare

At Epteck GmbH, we help embedded and IoT manufacturers prepare for CRA compliance at the engineering level.

That includes more than writing policy documents.

We support teams with:

CRA readiness assessment
Embedded product scope review
CRA gap analysis for embedded systems
Secure Boot architecture
Firmware signing and key management
Secure OTA update workflows
SBOM automation using SPDX and CycloneDX
Vulnerability handling process design
PSIRT-style workflow setup
Firmware security testing
Audit-ready technical documentation
CE, CRA, and GPSR compliance alignment

Our focus is simple: help manufacturers build products that are secure by design, maintainable in the field, and ready for EU market access.

If your product contains firmware, connectivity, OTA updates, cloud integration, or third-party software components, now is the right time to review your CRA reporting readiness.

FAQs

What is the September 2026 CRA reporting deadline?

The September 2026 CRA reporting deadline refers to the start of mandatory reporting obligations under the EU Cyber Resilience Act. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.

What must manufacturers report under the CRA?

Manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of their products with digital elements. For embedded and IoT products, this may involve firmware vulnerabilities, update mechanism weaknesses, device compromise, or security incidents affecting connected product operation.

What is ENISA 24-hour reporting under the CRA?

ENISA 24-hour reporting refers to the requirement to submit an early warning within 24 hours after becoming aware of a reportable actively exploited vulnerability or severe incident. Manufacturers should prepare internal triage and escalation workflows before the deadline begins.

Is an SBOM mandatory by September 2026?

The September 2026 deadline is focused on reporting obligations. However, SBOM readiness is strongly connected to effective vulnerability reporting because manufacturers need to know which software components, firmware versions, and dependencies are affected by a vulnerability. In practice, SBOM automation should be prepared before the reporting deadline.

Does the CRA reporting deadline apply to embedded products already on the market?

CRA reporting obligations can apply to products with digital elements made available on the EU market, including products placed on the market before the full CRA application date. Manufacturers should review legacy and currently deployed products as part of their reporting readiness.

What is an actively exploited vulnerability under CRA?

An actively exploited vulnerability is a weakness that is being used or has been used by attackers in real-world conditions. For embedded products, this may include exploitable firmware, insecure update mechanisms, exposed services, weak authentication, or vulnerable third-party components.

What should embedded manufacturers do before September 2026?

Embedded manufacturers should identify CRA-scope products, build a vulnerability intake process, generate SBOMs, map firmware versions to deployed devices, prepare secure OTA workflows, assign product security ownership, and define internal reporting procedures.

How is the September 2026 CRA deadline different from the December 2027 deadline?

The September 2026 deadline relates to reporting obligations for actively exploited vulnerabilities and severe incidents. The December 2027 deadline is when the main CRA obligations apply more broadly, including secure-by-design requirements, conformity assessment, CE marking alignment, and full lifecycle cybersecurity obligations.

How can Epteck help with CRA reporting readiness?

Epteck helps embedded and IoT manufacturers prepare for CRA reporting readiness through gap analysis, SBOM automation, secure boot, secure OTA workflows, vulnerability handling processes, firmware security testing, and audit-ready documentation for CRA, CE, and GPSR alignment.