Does the CRA require a separate AI risk assessment?

Article 13 requires a cybersecurity risk assessment for the product with digital elements. A product's LLM integration belongs inside that product assessment when it affects cybersecurity risk. Article 13(4) allows the assessment to form part of a risk assessment required by another Union act for products also covered there.

Does a hosted LLM provider become part of the product?

It depends on the statutory remote-processing test and the actual arrangement. Processing designed outside the manufacturer's responsibility generally falls outside that concept, while processing developed under its responsibility and required for a product function can qualify. Third-party dependency risk still belongs in the manufacturer's assessment.

When should the assessment be updated?

Article 13 calls for updates as appropriate during the support period. Product and route changes provide concrete triggers. Provider, component, operating-environment, and vulnerability changes should also reopen the relevant scenarios. Record the trigger and the scenarios reviewed.

EU CRA AI Risk Assessment: A Product-Level Method for LLM Calls

Article 13 of Regulation (EU) 2024/2847 makes the cybersecurity risk assessment part of the product lifecycle. The manufacturer documents the assessment, updates it during the support period, and uses its conclusions across planning, design, development, production and delivery as well as maintenance. When a product calls an LLM, the assessment needs to follow the request through the product rather than ending at the application's code repository.

TL;DR

Start with the product's intended purpose, reasonably foreseeable use, operating environment and protected assets, then record the expected use period.
Map LLM request scenarios to the applicable Annex I requirements and explain any requirement treated as inapplicable.
Include third-party model and orchestration dependencies in due diligence without assuming every standalone cloud service falls directly under the CRA.
Test controls with identity-bound HTTP evidence, then assign treatment and residual-risk approval to named owners.

Scope the product before scoring any risk

The Cyber Resilience Act legal text applies to products with digital elements made available on the market when intended purpose or reasonably foreseeable use includes a direct or indirect connection to a device or network. Article 3 defines a product with digital elements as software or hardware plus qualifying remote data processing. Remote processing qualifies when the manufacturer designed and developed it, or did so under its responsibility, and its absence would prevent one of the product's functions.

That language gives the risk team a boundary test. Draw the product and its supplied software. Add the controlled backend, required remote processing and integrated components plus external dependencies. Recital 12 says websites that fail to support product functionality and cloud services designed outside the manufacturer's responsibility fall outside the Regulation's remote-processing concept. A standalone model API therefore gains no automatic CRA status merely because an in-scope product sends it requests.

The assessment still considers dependency risk. Article 13(5) requires due diligence when third-party components are integrated so they avoid compromising the product's cybersecurity. The legal scope of a provider and the manufacturer's dependency analysis are separate questions. Keep both conclusions in writing and have counsel approve the first.

Article 13 defines the assessment inputs

Article 13(3) names the minimum analytical frame: intended purpose, reasonably foreseeable use, conditions of use, and operational environment. The analysis also covers assets to protect and expected use duration. The assessment must show how Annex I Part I applies and how the manufacturer will meet Part II vulnerability-handling requirements. Article 13(4) places that assessment in the Annex VII technical documentation.

For an LLM-enabled support product, intended purpose might permit an authenticated service agent to summarize a selected customer case. Foreseeable use includes pasting unrelated case text, asking the model to reveal hidden instructions, or routing a request through an added provider. Protected assets include case content, authorization state and system prompts plus destination configuration. Security records belong in the asset inventory as well. Each statement should point to product documentation or observed production behaviour.

A useful assessment unit is the product scenario, rather than "the LLM" as one undifferentiated asset. The model endpoint receives traffic. The product assembles context and chooses a route. It also supplies credentials and uses the response. An unapproved destination can expose case content, while an over-privileged credential expands the available model actions. Identity-aware AI gateway architecture shows where caller context can remain attached to the outbound request.

Build scenarios around Annex I outcomes

The assessment should describe the threat, its precondition and affected asset plus the product consequence. It then connects the applicable Annex I point to the existing control and evidence, followed by residual risk. Four scenarios give an LLM integration a credible first pass.

Unauthorized inference access. A valid session reaches a route outside the caller's role, or a shared service credential erases the originating identity. Annex I Part I point (d) requires protection from unauthorized access through controls including authentication, identity, or access management. Test the role-to-route decision with a blocked request and preserve the identity-bound record.

Sensitive context leaves the product. Retrieval adds customer data unrelated to the task, or a user pastes regulated material into the prompt. Points (e) and (g) address confidentiality and data minimisation. Test classification and redaction before transmission, using the mechanism described in prompt-level DLP.

Instructions or responses are manipulated. Retrieved text changes the effective command, or the response carries content that violates the product's policy. Point (f) addresses integrity of processed data, commands, programs, and configuration. Evidence should join request inspection and response inspection with the model destination and policy revision that made the decision.

A provider or component changes underneath the product. A route moves to a different model version, an orchestration dependency gains a vulnerability, or a provider endpoint changes region. Article 13(5) and Annex I Part II require third-party due diligence and component documentation. The resulting process covers vulnerability review and remediation, followed by testing. The evidence joins the declared inventory to destinations and versions observed in production.

Rate inherent risk and verify the control

Scoring should serve a decision. Define impact against the assets and functions named in the product scope. Define likelihood against attack preconditions and exposure in the documented operating environment. Record the inherent rating before controls, then test the control and calculate residual risk under the same method. A colour in a spreadsheet has value only when the cell links to the test that earned it.

At 16:40 on release day, an assessor should be able to open one scenario and see the denied HTTP request, the role supplied by the application, the destination selected and the prompt classification. The same record should name the policy revision. That packet is a control test. A screenshot of an enabled toggle proves configuration at one moment and says little about execution.

My opinion is that a risk register with no negative control tests is a catalogue of hopes. Test the path that should fail. Send an unauthorized role to a restricted route, place a synthetic identifier in the prompt, request an unapproved model destination, and interrupt the policy service. The expected outcomes should be a route denial and a content redaction or block. An unapproved destination should be denied, while a policy-service interruption should fail closed. Fail-closed AI gateway covers the operational choice behind the last result.

Treatment plans need product owners and dates

Each residual risk needs one disposition selected from reduce, avoid, transfer, and accept. The written treatment should name an accountable owner and target date. It should define the control change, verification method, and product versions covered. Acceptance belongs with someone authorized to own the product consequence. A platform engineer can explain a shared key; the product owner accepts the business exposure created by it.

Use release events to trigger reassessment. A new model provider, material route change and altered data source, plus any new autonomous action should reopen the relevant scenarios. The same review follows a support-period change, serious vulnerability, or substantial product modification. Article 13 requires updates as appropriate during the support period and systematic documentation of relevant cybersecurity aspects, including known vulnerabilities and third-party information.

The support period itself affects risk. Article 13 sets a general minimum of five years unless expected product use is shorter, while the detailed rules and any product-specific measures still require review. Security updates made available during support generally remain available for at least ten years or the remaining support period, whichever is longer. Those dates influence dependency support and monitoring. They also determine the feasibility of later remediation.

Technical documentation is the output, not a separate project

Annex VII requires the product description, architecture, vulnerability-handling processes, software bill of materials, risk assessment, support-period rationale, applied standards or alternative solutions, and test reports. Build those records while assessing rather than recreating them for conformity review. The European Commission's CRA implementation guidance page confirms that its 27 July 2026 guidance addresses scope and support periods alongside reporting and risk assessments.

A clean evidence chain connects the scenario with its Annex I point, control design, and policy identifier. The same chain carries the test execution, result, residual rating, treatment decision, and release. Keep model endpoints and versions in the same chain when they affect the product's security behaviour. That record also helps incident teams explain what should have happened when Article 14 reporting starts.

The assessment boundary should state its blind spots. An HTTP control sees traffic deliberately routed through it. Local model execution and STDIO tools require separate controls and evidence sources. So do endpoint compromise, stolen credentials used on another path, provider training, model weights, and direct bypass requests. Listing them avoids overstating test coverage.

DeepInspect

DeepInspect sits inline on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates supplied identity context and prompt classification for each request, then applies the approved destination and policy revision. A signed per-decision record can provide the execution evidence behind Annex I tests for access control and confidentiality. The same record can support minimisation, integrity, and security monitoring tests.

The product team retains the CRA scope decision and risk method. It also owns the treatment choice and residual-risk acceptance. DeepInspect has no view into local execution, STDIO, endpoint compromise, provider training, model weights, stolen credentials used elsewhere, or requests that bypass its HTTP route. Those scenarios stay in the product assessment with controls owned by the relevant teams. Book a technical deep dive at deepinspect.ai.