EU CRA Reporting Has Started: What Signage Buyers Should Ask
CRA reporting duties began on September 11, 2026 for manufacturers of covered products on the EU market. Confirm who handles incidents and how affected users receive information.
AI-generated illustration of an after-hours maintenance check; not a documented security incident.
A security lead opens a message about a component that ships inside a screen on a wall, and has to work out, under a 24-hour timer, whether it counts, who owns it, and who must be told. If you buy or install that screen, one question decides what you can act on: who is obliged to tell you, and how fast.
Since 11 September 2026, the manufacturers of products with digital elements made available on the EU market have had to report actively exploited vulnerabilities and severe incidents under the EU Cyber Resilience Act. The trigger is the product being made available in the EU, not the manufacturer's location: a maker outside the EU, with no establishment in it, is still in scope. What changed in September is that Article 14 applies.
Who reports, and to whom
The duty sits with manufacturers. Buying or running a display does not by itself put you under it — it creates a dependency, because timely upstream information helps you identify affected deployments and act.
The trigger is narrow, and that helps. It covers a flaw that is already being exploited, or a serious incident that affects product security. Not every bug or failed update. An outage alone does not establish whether the reporting criteria are met.
Reports go through the CRA Single Reporting Platform, and the manufacturer selects the national CSIRT designated as coordinator — normally where its main establishment in the EU is. The ENISA SRP FAQ states that on submission the notification normally becomes available to ENISA simultaneously, subject to the exceptional circumstances described in the rules, while the coordinator CSIRT then disseminates it onward — not one authority after another. With no EU establishment, a defined order picks the coordinator: authorized representative, importer, distributor, then the Member State with the most users.
Two clocks, and they are not the same clock
Inside a project team, the most useful fix is this: "the CRA reporting deadline" is not one number.
| Trigger | Early warning | Full notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability | Within 24 hours of becoming aware | Within 72 hours | No later than 14 days after a corrective measure is available |
| Severe incident | Within 24 hours of becoming aware | Within 72 hours | Within one month of the 72-hour notification |
Two different final-report clocks. Anyone who sums this up as a single "14-day rule" is wrong for one of the two cases.
Keep the two dates apart. The Act came into force on 10 December 2024, and its main obligations apply from 11 December 2027. The stage that began in September 2026 is not a general compliance deadline and brought in no new certificate. Open-source stewards start later still, on the same date.
Where the information goes, and why it can arrive late
A plausible sequence, offered as an example rather than a documented incident: a parts supplier finds an exploited flaw in a component that ships inside displays. In this example, the finished-product manufacturer must assess its own reporting duties after receiving the supplier’s information. A mailing list, unread portal or misdirected message can delay that handoff. Map who receives and assesses the information; do not assume the clock starts simply when a supplier sends an email.
The report to the authorities and the notice to users are two different obligations, and your incident plan should distinguish them.
The first is the notification itself, owed by the manufacturer to the authorities. The second is Article 14(8): as the Commission's FAQs on the Cyber Resilience Act set out, the manufacturer must inform the impacted users of the product, and where appropriate all users, of those vulnerabilities or incidents. If it decides not to do so in a timely manner, the receiving CSIRTs may provide that information to users where it is proportionate and necessary to prevent or mitigate the impact.
So the notice you receive is not merely a favor to negotiate — there is a duty behind it, plus a fallback if the manufacturer stays quiet. Two limits are worth stating. A CSIRT is not your account manager, and the fallback is a discretionary power, not a service level. And the full notification is written for the authorities, so do not assume you will receive it; what reaching you looks like in practice is the information needed to protect the deployment. Ask for a named contact and a time bound because the duty exists, not because compliance alone will reach you.
One more detail: in December 2025 the Commission set out when a CSIRT may hold back a report from other CSIRTs on justified security grounds. Delay in the chain is therefore something the rules allow for — a reason to hold a direct channel rather than lean on public distribution.
Roles overlap, so build the questions before you need them
This turns into a buying problem because roles are product-specific and overlap. A firm can be the manufacturer of one line and the importer of another, and a CMS supplier can be the manufacturer of its own product. The role follows what the company does for that product — who makes it, who places it on the market, whose brand it carries — not how much stock sits in a warehouse.
| Role | Information to request | Records or process to confirm | Handoff question to resolve |
|---|---|---|---|
| Component supplier | Component-level advisories | Advisory feed, end-of-support dates | A route that reaches the finished product's owner |
| Display manufacturer | The finished product's vulnerability intake | Product documentation, update mechanism, and the Art. 14(8) user notice | A named security contact reachable by buyers |
| Player or CMS vendor | Software-side advisories | Version history, update path | Which software version maps to which hardware revision |
| Importer or authorized representative | The market-facing contact point in the EU | EU-facing documentation and contact details on the product | Engineering detail from the manufacturer |
| Distributor or reseller | The customer-facing install base | Install base, batch records | Which upstream contact provides each needed item? |
| Integrator or operator | The deployment: which unit, which site, when | Asset register, configuration records | How the applicable user notice reaches the deployment owner |
Treat that as a list of questions, not conclusions. Which role your company holds for a product is a determination your compliance owner makes against the Commission's guidance and FAQ.
Seven things to ask for in writing
None of these needs new regulation. They need an email.
- A configuration identifier — model, hardware revision, and the batch or serial range your units fall into.
- A named security contact, with a defined escalation window. If a shared support address is used, confirm who monitors it and how security messages are escalated.
- The update channel and its end date — how a security update would reach you, and how long that support period runs.
- A route to receive incident information, with a time bound attached.
- The support-period and vulnerability-handling documentation for that specific configuration, not for the product family.
- The technical documentation you can use to assess the product, to the extent the supplier releases it.
- What you may pass on to your own customers, and what you may not.
The seventh item helps you pass on information without changing its meaning. If you resell or install, you will be asked things you cannot answer. Knowing which details you may pass on, and which need the maker to write directly, turns a panicked call into a routine step — and stops a customer repeating something that was never true.
If you are also renewing a supplier relationship, the commercial questions belong with choosing a display partner. The security annex is a different conversation, and easier to have while nothing is on fire.
What this cannot settle
Four things are deliberately outside this article: which role your firm holds for a product; whether a given model falls into a given group; whether units already on the market need a fresh assessment; and the exact edges of the reporting duty. Each is a call for your compliance owner.
The dates above are as published on the Commission's own pages, read on 1 October 2026, and those pages do get updated. Re-read them before you rely on a date in a contract.
Tell us the destination market and the exact model or configuration. We will check which of these items exist for that configuration — a security contact, an update channel, support-period information — and tell you plainly which ones do not. Send us the model and the market.
