Does the Cyber Resilience Act apply to your on-prem AI appliance?

What does the CRA actually regulate?

The Cyber Resilience Act, Regulation (EU) 2024/2847, regulates products with digital elements: hardware and software placed on the EU market whose intended purpose includes a data connection to a device or network. It is product legislation, not service legislation. That single distinction decides most scoping arguments about AI appliances, because it turns the question away from what the model does and towards how the customer receives it.

An inference server you rack in a customer data centre is a product. A virtual appliance you ship as an image the customer runs on their own hardware is a product too, because software placed on the market separately counts. A hosted endpoint the customer calls over the network is a service, and the CRA leaves it to NIS2 and to contract. Many vendors sell all three, and then discover that one delivery model pulls the whole product line into scope.

Which dates apply, and which are already live?

The September 2026 date is the one teams miss, because it arrives long before CE marking and it is purely operational. From that day, an actively exploited vulnerability in your appliance triggers an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days. If your only security contact is a shared inbox someone reads on Mondays, that timeline is not survivable.

Is an AI appliance an important or critical product?

Most AI appliances land in the default class, where self-assessment against the essential requirements is enough. The picture changes if the appliance performs a security function the customer relies on: identity management, network protection, VPN termination, secure boot or key handling. Those categories sit in the higher classes, where a notified body or a harmonised standard enters the process. Read Annex III against your feature list, not against your marketing page, because a bundled reverse proxy or an included secrets manager can move the whole box.

What does compliance look like in practice?

1. Define the product boundary in writing: hardware, base image, your software, third-party components, and what the customer supplies. The boundary is the scope of everything that follows.
2. Produce a software bill of materials and keep it generated by the build, not maintained by hand. The CRA expects it to be current for the supported version.
3. Run and record a cybersecurity risk assessment, then map each essential requirement in Annex I to the control that satisfies it.
4. Declare a support period and mean it. Five years is the reference point, and the period you publish sets how long you owe security updates.
5. Stand up coordinated vulnerability disclosure: a public contact, a triage commitment, a patch service level and a changelog customers can read.
6. Build the reporting path before September: who declares an incident severe, who files with the CSIRT, and where the 24 hour clock is recorded.
7. Assemble technical documentation and the EU declaration of conformity, then apply the CE mark when the 2027 date lands.

Sovereignty sold as hardware is sovereignty bought as product liability. The appliance that wins the deal is the same appliance that carries the CE obligation.

How does this interact with the AI Act and NIS2?

The three overlap on evidence rather than on duties. Your CRA vulnerability handling process is the same process a NIS2 supply chain audit asks about, and the same one a customer cites when their supervisor asks how supplier risk is managed. Your SBOM answers component questions from both. When the AI Act high-risk regime lands on 2 December 2027 for Annex III systems, the logging, robustness and accuracy evidence you build for Annex I of the CRA overlaps with the technical documentation that regime expects.

The practical consequence for a small vendor is that one appliance evidence file serves three regimes if you build it once and date every artefact. Building three separate files is how compliance work doubles without improving the product.