EU CRA LLM Requirements: What Applies to Products That Call Models

The Cyber Resilience Act organizes requirements around products with digital elements rather than a special LLM technology category. It attaches cybersecurity properties and manufacturer processes to products placed on the Union market. An LLM call matters when it forms part of an in-scope product's design or required remote processing.

TL;DR

• CRA scope follows the product with digital elements and its qualifying remote data processing, rather than the LLM label.
• A manufacturer maps model calls to Annex I access, confidentiality, integrity, minimisation outcomes based on its risk assessment. The assessment also covers resilience and monitoring.
• Third-party model services still require dependency due diligence and route inventory, with vulnerability processes and evidence where they affect the product.
• Standalone cloud services developed outside the manufacturer's responsibility generally remain outside the product's CRA scope.

CRA scope starts with the product

Article 2 of the official Cyber Resilience Act text covers 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 those products as software or hardware products and their remote data processing solutions, including separately marketed components.

Remote data processing has a tight definition. The manufacturer designed and developed the processing, or it was designed and developed under the manufacturer's responsibility, and the product would lose one of its functions without it. Recital 12 gives both sides of the line. Manufacturer-provided cloud functionality required to control a smart-home device can fall inside. Cloud services designed outside the manufacturer's responsibility fall outside that concept, and NIS2 addresses many cloud computing services separately.

A software vendor whose product orchestrates a hosted model may have CRA duties for its software product. The external model API gains no automatic status as the vendor's remote data processing. Scope turns on the marketed product and the manufacturer's responsibility, with function and connection reviewed for the actual arrangement.

The risk assessment selects the applicable requirements

Article 13 requires the manufacturer to assess cybersecurity risks and use the outcome throughout the product lifecycle. The documented assessment covers intended purpose, reasonably foreseeable use, operating conditions, and assets. It also accounts for expected use time.

For an LLM-enabled product, document the model's job and the product decisions surrounding it. Name the data sources used to assemble context, caller identities, permitted routes, provider endpoints and response actions, plus versions that affect security behaviour. Include foreseeable misuse such as unauthorized route access, excessive retrieval, injected instructions, unapproved destinations, and a provider change that alters processing location.

The CRA also addresses overlap with the AI Act. Article 12 of the CRA says an in-scope product classified as a high-risk AI system can be deemed compliant with the AI Act's Article 15 cybersecurity requirements when it meets the CRA conditions listed there and demonstrates the required protection in its declaration of conformity. That bridge applies only when both statutes' scope tests are met. It creates no general rule that every LLM is a CRA product.

Access and destination controls attach to each request

Annex I Part I point (d) requires protection from unauthorized access through appropriate controls. Its examples include authentication and identity or access management, and the point also requires reporting on possible unauthorized access. A front-end login gives the product a principal. The outbound request still needs an authorization decision tied to that principal and route, including the model capability being requested.

A credible test sends a restricted role to an administrative model route and expects a denial before transmission. The evidence names the caller, requested route, destination, and product version. It also records the policy revision and outcome. Identity-aware AI gateway architecture describes the request-bound identity pattern.

Destination control belongs beside authorization. The product should know which HTTP model endpoints its released version can call and reject an unapproved route. That inventory supports risk analysis and incident scoping while providing evidence for third-party due diligence. Direct calls using a developer's key create a separate path and need IAM controls plus enforcement at the egress and application layers.

Data controls operate before and after inference

Point (e) requires confidentiality for data stored by the product and for data transmitted or otherwise processed. Point (g) requires data adequate, relevant, and limited to the intended purpose. TLS protects the transport channel between systems. The product also needs to decide which content belongs in the request. A retrieval pipeline that attaches eight customer records to summarize one case has a minimisation problem before encryption starts.

Classify the assembled prompt before transmission, then redact or block content according to product policy. Preserve the classification and action without turning the security record into another store of sensitive prompt text. Prompt-level DLP sets out that control point.

Point (f) covers data and command integrity. It extends to programs and configuration against unauthorized manipulation or modification. LLM integrations place user text and retrieved material into a shared processing path alongside tool descriptions and system instructions. Request inspection can identify policy violations before the endpoint call. Response inspection can stop prohibited content or commands before the product acts on them. Version records connect the result to the model route and configuration in force.

Point (h) addresses availability of essential and basic functions after an incident. Point (i) covers negative effects on services provided by other devices or networks, while point (j) calls for limiting attack surfaces. Rate limits, route restrictions, bounded retries, circuit breaking, and a documented degraded mode translate those outcomes into product behaviour. The precise set follows the risk assessment rather than a generic LLM checklist.

Monitoring needs usable security records

Annex I Part I point (l) calls for security-related information through recording and monitoring relevant internal activity, including access to or modification of data, services, or functions, with a user opt-out mechanism. A model request can access a service and retrieved data. The product should identify which activity is security-relevant, what the opt-out changes, and which fields remain necessary for security.

A useful record contains supplied identity context, request route, content classification, and destination. It also names the model when available, policy revision, enforcement outcome, and timestamp. It should be tamper-evident and written independently of the application path being assessed. AI audit log immutability explains the custody problem behind that design.

At 09:05 during a conformity review, the assessor should be able to select one release and trace a denied request across the identity record and policy decision, then connect it to the destination inventory and test report. A dashboard showing 40,000 successful calls cannot answer that question. My view is that request volume is the least interesting logging metric in a CRA evidence pack.

Components and vulnerability handling include the integration

Annex I Part II requires manufacturers to identify and document components and vulnerabilities, create a machine-readable software bill of materials covering at least top-level dependencies, remediate vulnerabilities, test security regularly, maintain coordinated disclosure, share relevant vulnerability information, and distribute security updates securely. Article 13 adds due diligence for integrated third-party components.

For LLM products, the component view may include orchestration libraries, connectors, prompt templates shipped as configuration, and response parsers. Self-hosted model-serving software can also be a component. A hosted model service can remain an external dependency rather than an integrated component. Record it in the architecture and risk analysis when the product relies on it. The record should cover endpoint, region, contract owner, and escalation route, plus observed version information. Avoid forcing every remote service into the SBOM when the statutory component model points elsewhere.

The Commission's CRA implementation guidance publication confirms that its July 2026 guidance addresses scope and remote data processing. It also covers support periods, reporting, and risk assessment. Use the current guidance and applicable harmonised standards during conformity preparation, then preserve the rationale used for each product release.

Documentation joins design to proof

Annex VII calls for the product's intended purpose, software versions affecting compliance, architecture, vulnerability processes, SBOM, risk assessment, support-period basis, applied standards or alternative solutions, and conformity test reports. An LLM requirements pack should therefore connect each applicable Annex I point to a design statement and executed test.

Keep six practical artifacts: a product scope memo, model-route inventory, risk scenarios, policy definitions, test evidence, and a release-specific exception register. The list stays useful because every artifact has a different owner and review cadence. The scope memo belongs with legal and product security. Engineering maintains routes and versions. The security team owns execution of policy tests. Product leadership approves exceptions and residual risk.

Article 14 reporting has applied since 11 September 2026, ahead of full application on 11 December 2027. The European Commission's reporting page identifies the 24-hour early warning and 72-hour notification. It also describes the final-report stage. Request records and route inventory can support those filings, although the manufacturer remains responsible for deciding and reporting.

DeepInspect

DeepInspect operates on authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It uses identity context supplied by the application and classifies request content. It then enforces per-role and per-route destination policy, inspects responses, and writes a signed per-decision record before returning the response. Those controls can support selected Annex I outcomes and their test evidence.

The boundary excludes local execution, STDIO tools, endpoint compromise, provider training, model weights, stolen credentials used through another path, and direct traffic that bypasses the proxy. DeepInspect also leaves manufacturer status and CRA scope with the accountable product teams. Those teams retain legal reporting, vulnerability remediation, and conformity assessment. Book a technical deep dive at deepinspect.ai.