As the entry into force of the EU Cyber Resilience Act (CRA) approaches, many companies assume that the full mandatory application date of 11 December 2027 is still a long way off and have not yet started preparing for CRA compliance.

In fact, not all CRA requirements start in 2027.

On 11 September 2026, the CRA reporting obligations enter into force ahead of the rest.

This means that manufacturers selling connected products in the EU market must establish a product security incident response mechanism and a vulnerability reporting mechanism, or face compliance risk.

What is the CRA reporting obligation?

The CRA requires manufacturers, once they become aware of an exploited vulnerability or a major security incident affecting a product, to report it to the EU cybersecurity authority within set deadlines.

Its core objectives are to:

· Improve cyber threat awareness across the EU;

· Shorten vulnerability handling cycles;

· Raise the overall security level of digital products;

· Strengthen supply chain security management.

Reports are received through the Single Reporting Platform (SRP) built by the EU Agency for Cybersecurity, ENISA.

Which companies are affected?

The CRA applies to the great majority of products with digital elements (PDE).

Typical products include:

Consumer products

· Smart cameras

· Smart door locks

· Smart home devices

· Smart wearables

· Routers

· NAS storage devices

Industrial and commercial products

· Industrial gateways

· PLCs

· HMIs

· Industrial controllers

· Charging piles

· Energy storage systems

· Energy management equipment

· Industrial IoT devices

Software products

· Operating systems

· Mobile apps

· Cloud platform clients

· Network management software

· Cybersecurity products

Wherever a product is intended for the EU market and falls within the scope of the CRA, the manufacturer must fulfil the relevant reporting responsibilities.

What has to be reported?

The CRA focuses on two types of situation.

1. Actively exploited vulnerabilities

Where a company discovers that:

· A product has a security vulnerability;

· And the vulnerability is already being exploited by an attacker;

the CRA reporting process must be triggered.

Examples include:

· Remote code execution (RCE) vulnerabilities;

· Default password vulnerabilities;

· Authentication bypass vulnerabilities;

· Privilege escalation vulnerabilities;

· Data leakage vulnerabilities.

2. Severe incidents

These include:

· Large-scale attacks on a product;

· Service interruption;

· Data breaches;

· Ransomware incidents;

· Supply chain attacks;

· Backdoor implantation.

Where an incident affects product security or user safety, the manufacturer must assess it and report.

How strict are the CRA deadlines?

The CRA uses a rapid reporting mechanism similar to that of NIS2.

Once a relevant incident is discovered, companies must act as follows.

Within 24 hours

Submit an early warning. This should cover:

· The basic facts of the incident;

· Information on the affected product;

· A preliminary impact assessment;

· Whether there is any cross-border impact.

Within 72 hours

Submit a detailed incident report. This should cover:

· The results of technical analysis;

· The range of affected products;

· How the vulnerability was exploited;

· Mitigating measures already taken.

Ongoing updates

Submit a final report within 30 days once the investigation is complete. This should cover:

· Root cause analysis;

· Remediation measures;

· Risk reduction measures;

· The security update plan.

What is the biggest problem companies face today?

Many companies already have R&D teams and quality systems, but have not established a product security incident response team (PSIRT).

Common problems include the following.

No channel for receiving vulnerabilities

Company websites often have no:

· Security contact;

· security@ mailbox;

· Vulnerability submission channel.

As a result, researchers cannot reach the vendor.

No vulnerability handling process

Once a vulnerability is found:

· Who assesses it?

· Who fixes it?

· Who releases the patch?

· Who reports it to the EU?

Responsibilities are not clearly allocated.

No coordinated vulnerability disclosure mechanism

Many companies have not yet established:

· A vulnerability intake process;

· A vulnerability rating mechanism;

· A communication mechanism for external researchers;

· A vulnerability disclosure policy.

This directly affects CRA conformity.

What should companies do now?

11 September 2026 is very close. We recommend that companies start the following work immediately.

Stage 1: establish a PSIRT team

Set up a product security incident response team and define:

· Organisational structure;

· Allocation of responsibilities;

· Escalation mechanism;

· Emergency response mechanism.

Stage 2: publish a CVD policy

Prepare and publish a Coordinated Vulnerability Disclosure Policy that tells external researchers:

· How to submit vulnerabilities;

· Response times;

· The handling process;

· Any reward mechanism (optional).

Stage 3: establish security contact channels

At a minimum, establish:

· security@company.com;

· An official security page;

· A named security contact.

Stage 4: build a vulnerability management process

Covering:

· Vulnerability intake;

· Risk assessment;

· CVSS scoring;

· Remediation verification;

· Patch release;

· Vulnerability disclosure;

· CRA reporting.

Together these form a standardised closed management loop.

Stage 5: carry out a CRA gap analysis

Focus on:

· The security requirements in CRA Annex I;

· The secure development lifecycle (SDL);

· SBOM management;

· Vulnerability management mechanisms;

· Security update mechanisms;

· PSIRT system development.

Complete the remediation work in advance.

NTEK services

The CRA is regarded as one of the most far-reaching product cybersecurity regulations the EU has introduced in recent years.

Many companies focus on the full application date of 11 December 2027, but in practice the reporting obligation that starts on 11 September 2026 is the first critical milestone companies face.

For companies that intend to keep selling into the EU market, the question is no longer whether to prepare for the CRA, but whether they can establish compliant vulnerability response and reporting capability in time.

Establishing a PSIRT system, a vulnerability management mechanism and a coordinated vulnerability disclosure policy in advance will become a fundamental capability for entering the EU market.

NTEK Information Security Laboratory can provide:

· CRA gap analysis;

· PSIRT system development;

· Coordinated vulnerability disclosure (CVD) policy development;

· Vulnerability management process development;

· CRA technical documentation coaching;

· Product cybersecurity testing and conformity verification.

We welcome the opportunity to discuss CRA compliance implementation with you.