Cyber Resilience Act Reporting: What Tech Companies Entering Czechia Need to Know

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents under the EU Cyber Resilience Act. Foreign tech companies entering Czechia need clear reporting ownership.

From 11 September 2026, the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements sold in the EU. A foreign technology company entering Czechia should know who carries the reporting duty, how quickly information must move and what its Czech importer or distributor must do when a problem appears.

The Cyber Resilience Act, or CRA, creates horizontal cybersecurity requirements for products with digital elements placed on the European Union market. The Regulation entered into force in December 2024. Most obligations apply from 11 December 2027, but the reporting duties in Article 14 start earlier: 11 September 2026.

That early date matters. A company may still be preparing its wider 2027 compliance programme while already having to report a qualifying vulnerability or incident in 2026.

For manufacturers from Taiwan, South Korea, Japan, Germany, the United States and other markets, Czechia may be the location of an importer, distributor, subsidiary, service team or first European customer. The reporting obligation cannot be managed safely unless responsibilities between headquarters and the European operation are clear.

What the Cyber Resilience Act covers

The CRA applies broadly to products with digital elements made available on the EU market, subject to the Regulation’s scope and exclusions.

Depending on the product and business model, this can include:

connected hardware,
industrial control and automation products,
network equipment,
Internet of Things devices,
consumer smart products,
security products,
software sold as a product,
embedded software and firmware,
components placed on the market separately,
certain commercial open-source activities.

The phrase “product with digital elements” is deliberately wider than ordinary consumer software. A manufacturer of machinery, sensors, medical-adjacent equipment, access systems or industrial electronics may need a CRA analysis even if it does not see itself primarily as a software company.

Some sectors and products are governed by other specialised EU rules or exclusions. The first step is therefore a documented scope assessment—not an assumption based on the company’s industry label.

What changes on 11 September 2026

From that date, manufacturers must report two categories of events:

Actively exploited vulnerabilities affecting a product with digital elements.
Severe incidents having an impact on the security of a product with digital elements.

The European Commission describes the core timeline as:

Stage	Timing
Early warning	Within 24 hours of becoming aware
Full notification	Within 72 hours of becoming aware
Final report for an actively exploited vulnerability	No later than 14 days after a corrective or mitigating measure is available
Final report for a severe incident	No later than one month after the full notification

Reporting is made through the CRA Single Reporting Platform operated by ENISA. Manufacturers submit one notification through the platform. It is addressed to the CSIRT responsible for the country of the manufacturer’s main establishment and, except in particularly exceptional circumstances, made available to ENISA and shared through the CSIRT network.

These are short deadlines. A company that first begins discussing ownership after confirming an incident may already be too late.

Reporting is mainly a manufacturer duty

The Article 14 reporting obligation that started on 11 September 2026 applies to manufacturers. Open-source software stewards are also subject to CRA reporting duties, but their obligation under Article 24(3) starts later, on 11 December 2027.

Importers and distributors have important responsibilities under the wider Regulation, but their role should not be described as identical to that of the manufacturer.

A practical chain looks like this:

the manufacturer maintains the product-security process, investigates the event and submits the required CRA report,
an EU importer checks that the manufacturer has met the applicable requirements before placing the product on the market and must react when it has reason to believe the product is not compliant or presents a significant cybersecurity risk,
a distributor also performs due diligence and must not make a product available when the applicable requirements are not met,
local service, customer-support and security teams may be the first to receive evidence of a vulnerability or incident.

The commercial chain therefore needs a rapid escalation route to the manufacturer, even when the importer or distributor is not the party submitting the Article 14 notification.

Why this matters when entering Czechia

A non-EU manufacturer can enter the Czech market in several ways:

through a Czech distributor,
through an EU importer located in Czechia,
through its own Czech or European subsidiary,
by selling directly to Czech business customers,
through a marketplace or online channel,
as a component supplier to a Czech manufacturer.

Each model creates a different flow of information and responsibility.

A distributor may receive the first customer complaint. A Czech service technician may identify abnormal behaviour. A security researcher may contact the European subsidiary instead of headquarters. A key industrial customer may report an incident to the local account manager.

If these reports remain in a local mailbox for several days, the manufacturer may miss the 24-hour early-warning deadline.

The five operational questions every foreign manufacturer should answer

1. Which products are in scope?

Create a product inventory for the EU market. Include model numbers, firmware and software versions, intended purpose, market channels and responsible legal entities.

Do not assess only flagship products. Accessories, gateways, separately sold software and embedded components may require their own analysis.

2. Who is the manufacturer for CRA purposes?

The commercial brand, contract manufacturer, software developer and EU subsidiary may be different organisations.

Document which legal entity places each product on the market under its name or trademark and who controls product security and updates. A distribution agreement cannot fix an unclear manufacturer role after an incident.

3. Who can decide that an event is reportable?

Security teams investigate technical facts. Legal and product teams interpret regulatory scope. Management may control customer communication.

The company needs a named decision process that can operate within hours, including nights, weekends and public holidays. A 24-hour deadline does not pause while several countries wait for the next meeting.

4. Who has access to the reporting platform?

Identify the people and accounts able to submit and update a report through the ENISA Single Reporting Platform.

Access should be tested in advance. The company should know:

who owns the account,
who acts as backup,
which CSIRT route is relevant,
where evidence and draft notifications are stored,
who approves the submission,
how sensitive vulnerability information is protected.

5. How will Czech partners escalate information?

Contracts and operational procedures should tell Czech importers, distributors and service partners:

what must be escalated,
which emergency channel to use,
what minimum information to collect,
what they must not promise publicly,
how quickly they must contact the manufacturer,
who communicates with customers and authorities.

A generic support ticket with a three-day response target is not enough for CRA reporting.

Build a CRA reporting workflow before an incident

A practical workflow can be organised in seven stages.

Stage 1: intake

Potential signals may come from customers, researchers, monitoring, service teams, distributors, vulnerability databases or internal testing. Every channel should feed a controlled security intake process.

Stage 2: triage

Confirm the affected product and version. Preserve evidence. Determine whether the report suggests exploitation, a severe incident, an ordinary defect or an unrelated event.

Stage 3: scope and materiality assessment

Assess whether the product and event fall within the CRA reporting criteria. Record the reasoning and the time when the company became aware. The awareness time is critical because it starts the reporting clock.

Stage 4: early warning

Submit the initial notification within 24 hours when the criteria are met. The early warning does not require every technical question to be solved. It ensures the authorities receive timely notice.

Stage 5: full notification

Submit the fuller notification within 72 hours, adding available information about the event, affected products, impact and initial mitigation.

Stage 6: correction and customer response

Develop the update, workaround or other mitigating measure. Coordinate customer communication, distribution partners and any related obligations under other rules or contracts.

Stage 7: final report and review

Submit the required final report within the applicable deadline and review why the issue occurred, how it was detected and whether the process worked.

The CRA does not replace other incident duties

A single security event can trigger several frameworks.

Depending on the company and incident, these may include:

CRA reporting,
NIS2 incident obligations,
GDPR personal-data breach notification,
sector-specific product or safety rules,
contractual customer notification,
insurance requirements,
stock-exchange or corporate disclosure rules.

The ENISA platform simplifies CRA reporting, but does not automatically complete every other legal or contractual duty.

Build a reporting matrix showing which team evaluates each framework. The goal is to avoid both missed notifications and contradictory reports.

What importers and distributors should verify

A Czech importer or distributor should not assume that the foreign manufacturer “has compliance handled”. It needs evidence and a practical escalation path.

Before placing or making products available on the EU market, the organisation should verify the applicable CRA requirements, including the manufacturer’s conformity work and required documentation as those provisions become applicable.

Operationally, it should also ask:

Who is the manufacturer’s CRA contact?
Is there a 24/7 security reporting channel?
Which product versions are supported?
How are security updates delivered?
How quickly must the Czech partner escalate a suspected issue?
Who informs Czech customers?
What happens if the manufacturer does not respond?
Can sales be paused when a significant cybersecurity risk is suspected?

These questions belong in supplier onboarding and distribution agreements, not only in a security policy.

What non-EU headquarters should prepare

A European product map

List all products sold in the EU, the responsible manufacturer, importers, distributors, subsidiaries and support channels.

A 24-hour decision process

Create an incident team with technical, legal, product and communication authority. Name deputies in different time zones.

Contractual escalation

Update agreements with Czech and EU partners so that potential vulnerabilities and severe incidents reach the manufacturer immediately.

Evidence preservation

Define which logs, versions, customer reports and technical artefacts must be retained for investigation and reporting.

Security-update capability

The company needs a reliable way to develop, test, distribute and document corrective measures across the supported product lifecycle.

Coordinated communication

A local distributor, global headquarters and security team should not issue conflicting explanations. Prepare approval and translation routes before a crisis.

A 30-day preparation plan

Scope

Inventory products with digital elements sold in the EU.
Record the manufacturer, importer and distributor for each route to market.
Identify exclusions and sector-specific rules requiring specialist review.

Reporting ownership

Appoint a CRA reporting owner and deputy.
Define when the organisation becomes “aware” of an event.
Create 24-hour and 72-hour internal deadlines shorter than the legal limit.
Prepare access to the ENISA reporting platform.

Partners

Give Czech importers, distributors and service teams an emergency security contact.
Add escalation times and evidence requirements to operating procedures.
Review contracts for cooperation, updates and customer communication.

Technical process

Connect support tickets, monitoring and researcher reports to security triage.
Map supported versions and update channels.
Test an actively exploited vulnerability scenario.
Test a severe incident scenario.

Governance

Map CRA against NIS2, GDPR and sector obligations.
Protect confidential vulnerability information.
Record decisions, timestamps and submitted reports.
Brief senior management on the 11 September 2026 reporting start.

Common mistakes

Treating December 2027 as the only deadline

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

Giving responsibility to the Czech distributor without authority

A distributor cannot investigate firmware, approve a global security update or make the manufacturer’s regulatory decisions unless the process and authority genuinely support that role.

Waiting for complete technical certainty

The CRA uses an early-warning stage because every detail may not be known in the first 24 hours. The company needs a process for reporting with the information available and updating it later.

Using ordinary customer support as the only intake channel

A support queue designed for routine complaints may hide a reportable security event until the legal deadline has passed.

Assuming open source is always outside the CRA

The Regulation distinguishes non-commercial open-source development from commercial activity and introduces a role for open-source software stewards. Companies using open-source business models should assess their exact position rather than rely on a slogan.

The main conclusion

The Cyber Resilience Act is not only a future product-certification project for 2027. Its incident and vulnerability reporting duties begin in September 2026.

For a foreign technology company entering Czechia, the largest immediate risk is not the reporting form itself. It is a broken information chain between Czech customers, distributors, service teams, the European importer and the manufacturer’s headquarters.

A workable CRA process answers three questions in advance:

Who recognises a potentially reportable event?
Who decides and submits within the deadline?
How does every Czech and European partner reach that person immediately?

Companies that solve these questions now will be better prepared not only for Article 14, but also for the wider CRA obligations that follow in 2027.

How Kodo can help

Kodo helps international companies turn Czech and European market-entry requirements into workable local processes. We can map partners and information flows, prepare Czech and English operational communication, connect support and reporting workflows, and coordinate implementation with cybersecurity and legal specialists.

Contact Kodo

Sources

This article provides general operational information and is not legal or cybersecurity advice. Organisations should assess their products, role and reporting duties with qualified specialists.