CRA reporting: is your chat assistant in scope?

Since 11 September 2026 (Regulation EU 2024/2847, Article 71) the first hard obligation of the Cyber Resilience Act has been in force: the reporting duty in Article 14. It runs in hours rather than weeks, and it falls on the manufacturer of a product with digital elements. For anyone who operates or ships an AI chat assistant, one question comes first: is that assistant such a product at all? The answer follows from the way the thing is built, not from the label on the offering. This article walks the decision path, sorts the four build types that occur in practice, quotes the deadlines as written and shows what has to be in place so the first report does not fail on a missing account.

Enlarge graphic

Labels in the illustration

• Assistant in operation
• Is software shipped or
• operated on customer premises?
• Yes
• No
• Shipped widget script
• Article 14
• Self-hosted component
• Article 14
• Is the server function essential
• to a function of the product?
• Yes
• Integral remote data processing
• Article 14
• No
• Pure cloud service
• NIS2
• Article 14 leaf: the deadline chain starts on awareness
• 24 hours
• Early warning to CSIRT and ENISA
• 72 hours
• Notification with means of exploitation
• Final report
• 14 days after fix, 1 month after incident
• The duty falls on the manufacturer; a pure cloud service is assessed under NIS2

Does the assistant fall under the reporting duty?

What went live on 11 September 2026

The Cyber Resilience Act applies in stages. The main body with the essential cybersecurity requirements and conformity assessment applies from 11 December 2027 (Regulation EU 2024/2847, Article 71). One article was pulled forward: the reporting obligations in Article 14 have applied since 11 September 2026 (Regulation EU 2024/2847, Article 71). The German federal office describes that date as 21 months (BSI) after the regulation entered into force.

Article 14 covers two kinds of report on separate clocks. One concerns actively exploited vulnerabilities in the product, the other severe incidents affecting its security. Both open with an early warning within 24 hours (Regulation EU 2024/2847, Article 14) of the manufacturer becoming aware, and then diverge. Set up only one chain and you have covered half the duty, which you notice the moment the other triggers. Operationally: two templates, two distribution lists, two deadline clocks, and a decision on who fires which chain when the case is unclear.

The decision path: four build types, one question

The regulation covers products with digital elements. A chat assistant consists of software, but software alone does not make a product in the sense of the regulation. What matters is who developed it, who ships it and where it runs. The Commission services put it this way: standalone Software-as-a-Service offerings designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves such products, yet they fall within scope as soon as they meet the definition of remote data processing (European Commission, FAQ version 1.3).

In practice these forms mix. An assistant embedded as a script whose answers come from a server function at the provider is both at once: a shipped component and a remote processing step without which the component stays silent. That combination is the norm as soon as an assistant is embedded in a website and shop. Document the integration and half the decision path is done, because the classification follows from the architecture diagram, not from the contract title.

Remote data processing is the term that decides

The regulation defines the term narrowly and in a single sentence. It is the test for every assistant whose answers are not produced on the user's device. Hold that sentence against your own architecture once and the classification usually settles itself.

Three features sit in that sentence and all three have to coincide. First, the processing happens at a distance. Second, the software for it was designed and developed by the manufacturer or under the manufacturer's responsibility. Third, its absence would prevent the product from performing one of its functions. Drop one of the three and the remote processing is not part of the product, so Article 14 does not attach to it.

• The assistant shows no answer without the server function: the processing is integral and belongs to the product.
• The assistant keeps answering from a local knowledge base and only the enrichment drops out: the processing is supplementary.
• The server function comes from a third party and exists without the manufacturer's involvement: it does not count towards that product.
• The server function exists under the manufacturer's responsibility: it counts towards the product even on someone else's infrastructure.

For operators this makes scope an architecture question. Keeping the knowledge base and the answer path in house does not change the classification, but it makes it testable. Spreading them across a chain of external services means answering two questions per link: who developed it, and what fails without it? That chain deserves documentation anyway, because it is also the basis for privacy and hosting and for any answer given to a supervisory authority.

The deadline chain in detail

The deadlines are written out and leave little room for interpretation. They are built as a chain: each step assumes the previous one has run, and each step demands more content than the one before. The first step is deliberately thin so it can go out quickly.

In practice the chain leaves at most one working day between awareness and early warning, usually far less. That is the same window in which technical fallback has to stand: teams that have rehearsed the routes under outage and fallback can hang the reporting chain off the same alerting instead of building a second one beside it.

Where reports go and who is responsible

For reports under Article 14, ENISA establishes a single reporting platform, with member states and ENISA operating their own electronic endpoints (Regulation EU 2024/2847, Article 16). For a German manufacturer the first point of contact is therefore the competent national CSIRT, with the report going to ENISA at the same time. The federal office separately names 11 December 2026 (BSI) as the point by which member states are to ensure a sufficient number of notified bodies. Those bodies concern conformity assessment rather than reporting, yet the two are regularly conflated.

From the reports received, ENISA prepares a technical report on emerging risk trends in products with digital elements every 24 months (Regulation EU 2024/2847, Article 17). By 11 September 2028 (Regulation EU 2024/2847, Article 70) the Commission submits a further report to the Parliament and the Council. Reporting today therefore feeds an evaluation that shapes how supervision is later focused: an argument for structuring a report properly, and for logging your own tool control so the sequence of events can be told later without reconstruction.

• A named person with a deputy who may send the early warning without waiting for management sign-off.
• Access to the reporting platform set up and used once outside an emergency, so the login is not sorted out in the first hour.
• A maintained list of member states in which the product has been made available, retrievable without asking around.
• The timestamp of becoming aware, logged with source and recipient, because that time decides whether the deadline was met.
• Prepared text blocks for early warning, notification and final report, kept separate for vulnerabilities and incidents.

What a missed deadline costs

The penalty framework is tiered. Breaching the essential cybersecurity requirements or the obligations in Articles 13 and 14 is subject to fines of up to 15 000 000 EUR or 2.5 % (Regulation EU 2024/2847, Article 64) of worldwide annual turnover for the preceding financial year, whichever is higher. A second group of obligations is capped at 10 000 000 EUR or 2 % (Regulation EU 2024/2847, Article 64 paragraph 3), incorrect or incomplete information to notified bodies and market surveillance authorities at 5 000 000 EUR or 1 % (Regulation EU 2024/2847, Article 64 paragraph 4). Reporting therefore sits in the top tier, alongside the product requirements.

Company size is thus a mitigating factor for a single deadline, not an exit from the procedure. For a business running custom functions inside the assistant this means the duty does not scale with headcount but with the number of functions that would fail without the remote processing.

How heavy the reporting load realistically is

The worry about weekly reports does not survive contact with the data. Over the reporting period 42,595 (ENISA) new vulnerabilities were disclosed, an increase of 27 % (ENISA) on the previous year. Only a fraction were actively exploited: 245 (ENISA) entries were added to the catalogue of known exploited vulnerabilities in the same window, and at least 115 (ENISA) exploited vulnerabilities were reported as impacting organisations in the member states. The duty attaches to active exploitation, not to disclosure, which shifts the order of magnitude by two decimal places.

For Germany the federal office draws a similar picture: 119 (BSI) new vulnerabilities became known per day on average during the reporting period, a growth of around 24 % (BSI). And around 80 percent (BSI) of reported attacks were directed at small and medium-sized enterprises, which in the authority's assessment often lack the means and knowledge to protect themselves unaided. Reading that figure as evidence that reporting concerns large providers reads it against its own message.

The route into an assistant rarely runs through the assistant itself. Supply chain risks account for 10.6 % (ENISA) of the observed risks, with web threats following at 27.3 % (ENISA). On the technical side, the share of pages carrying at least one third party sits at 90 % (Web Almanac) or above, the median stands at 83 requests (Web Almanac) to third parties on desktop, and scripts make up 24.8 % (Web Almanac) of content types, the largest single share. A chat widget is one of those scripts. What holds for the attack surface holds for the defence: the routes described under prompt injection are the routes along which a reportable exploitation arises.

Legal uncertainty itself is often the obstacle. In the survey year 19.95 % (Eurostat) of enterprises in the union used AI technologies, with language-generating methods reaching 8.76 % (Eurostat). Among enterprises that considered adoption and dropped it, 52.52 % (Eurostat) named a lack of clarity about the legal consequences. A documented decision path removes that obstacle, whichever way the result falls. Planning for peak season demand follows the same logic: a known load is manageable, an unknown one is not.

What belongs in place operationally now

The effort sits in the preconditions rather than in the report. An early warning is a short text; sending it within a day fails in practice on accounts, on responsibilities and on nobody having the list of affected member states to hand. Those things can be settled beforehand, and they overlap with what gets written down for acceptance testing before go-live.

• The classification in writing: which build type applies, which server function is integral, who is the manufacturer under the regulation.
• A bill of materials with origin, version and owner, so a reported third-party defect can be attributed within hours.
• The reporting path as a written procedure, with a named person, a deputy and a route that carries at the weekend.
• The moment of awareness captured technically: who learned what and when, from which source, with which evidence.
• A contact point for incoming vulnerability reports, published and actually read.
• A support period defined and documented, since Article 13 sets it at at least five years (Regulation EU 2024/2847, Article 13).
• Contractual clarity with suppliers about who reports when the defect sits in a bought-in component.

A migration is the cheapest moment for this inventory, because the architecture is already on the table. Anyone replacing an old chatbot should ask for the classification as part of the handover instead of a legal question answered afterwards. The same applies to a newly built website assistant: what fails without the remote processing is a design decision, not an interpretation after the fact.

Drawing the line to NIS2 and existing products

The regulation draws the boundary to cloud services explicitly: the NIS2 Directive applies to cloud computing services and cloud service models such as Software as a Service, Platform as a Service or Infrastructure as a Service (Regulation EU 2024/2847, Recital 12). An assistant offered purely as a service, belonging to no shipped product, is assessed there rather than here. The same recital does, however, set a threshold in its next sentence: entities providing cloud computing services in the Union that qualify as medium-sized enterprises or exceed the thresholds for medium-sized enterprises fall within the scope of that directive (Regulation EU 2024/2847, Recital 12). A small provider below that threshold is therefore in most cases covered neither by Article 14 nor by the NIS2 reporting duty. Where the provider does fall within the scope of the directive, the classification changes the addressee, not the pace: the NIS2 Directive then likewise requires an early warning within 24 hours (Directive EU 2022/2555, Article 23) of becoming aware of a significant incident. In that case the classification says who receives the report; whether a report is owed at speed at all is settled beforehand by scope and by the size of the provider. Anyone settling the hosting question finds the connecting point under privacy and hosting.

There is no grace period for the installed base. By way of derogation from the general transitional rule, the obligations in Article 14 apply to all products with digital elements within scope that were placed on the market before 11 December 2027 (Regulation EU 2024/2847, Article 69). An assistant that has been running for two years is therefore as much in scope as one starting tomorrow.

That leaves the question of important products. Annex III class I lists 19 (Regulation EU 2024/2847, Annex III) categories; the implementing regulation describes one of them as products that communicate over the public internet, process requests on the basis of natural language and thereby grant access to other services or control devices in domestic environments (Implementing Regulation EU 2025/2392). An assistant on a corporate website without device control generally sits outside that class. That matters for conformity assessment, not for the reporting duty in Article 14. How the classification relates to the data protection assessment is covered under GDPR and hosting in chat. How XICBOT reports incidents is set out on the status page, and how changes are shipped and recorded in the changelog.

Frequent questions