CRA for AI & ML products

AI in the product means the CRA applies — on top of, not instead of, the AI Act

Anyone placing a device with on-device inference, an ML-driven controller, an AI assistant in firmware or a camera with object detection on the EU market is, from the perspective of the Cyber Resilience Act (Regulation (EU) 2024/2847), typically selling a product with digital elements (PDE). The AI capability does not make the product a special case — it sharpens the questions the CRA asks anyway: How secure is the software? Where do the dependencies come from? How long will it be patched? The common reflex "surely the AI Act covers us" is dangerously incomplete.

The real pain in this sector is a double burden combined with an unclear factual basis. Teams that train, fine-tune or source their model from the open-source ecosystem (Hugging Face, PyTorch, ONNX Runtime) often have no solid answer to three questions: Is our AI product even a PDE? Does the model belong in the SBOM? And how does all of this relate to the AI Act many houses are only now implementing? On top of that come AI-specific attack surfaces — prompt injection, model extraction, data poisoning, adversarial inputs — that classic software security processes simply do not anticipate.

Blackfort Technology works precisely at this intersection. Christian Gebhardt is a member of the ACS AI working group and co-author of a public guide on penetration testing LLMs — subject-matter authority at the seam between product security and AI, not an official mandate. This text classifies your situation schematically and does not replace individual legal advice.

When an AI/ML product is a PDE — and which annex class likely applies

Rule of thumb: as soon as AI/ML as software is part of a product made available on the EU market with a direct or indirect data connection, the CRA likely applies — regardless of whether the model runs locally (on-device) or in a companion app. Purely externally hosted AI services (SaaS inference without a shipped product) must be classified separately, inter alia via the AI Act. Most AI products fall into the Standard category and are made conformant via self-assessment (Module A). What matters for classification is not "does it contain AI" but the function of the product under Annex III/IV.

The technical descriptions of the important and critical categories are set out in Implementing Regulation (EU) 2025/2392. The AI component does not change the class — but it does increase the evidentiary effort within that class.

Sector standards and delineation from adjacent regimes

For software security, the CRA Annex I requirements and the emerging harmonised standards apply; for the SBOM, BSI TR-03183-2 (v2.1.0) is the authoritative technical reference. AI-specific consensus is converging on an "AI-BOM/model-BOM" as an extension of the classic SBOM. Clean separation of the regimes is essential:

• AI Act (Reg. (EU) 2024/1689): addresses the risks of AI use — high-risk classification, transparency, data governance. A separate legal act, applying in parallel with the CRA. An AI product may be subject to both; the evidence must be coordinated, not merged.
• CRA: addresses the cybersecurity of the product — security-by-design, vulnerability handling, SBOM. This is the layer where "is the model vulnerable?" belongs.
• RED Delegated Reg. 2022/30: relevant where your AI device is radio-capable; overlap with the CRA can arise and must be delineated.
• NIS2 / DORA: concern operators (essential/important entities or the financial sector), not the product manufacturer duty. Not to be equated with the CRA.
• Exemptions: AI in MDR/IVDR medical devices, in vehicle type-approval, civil aviation or marine equipment is exempt from the CRA — whoever builds an AI diagnostic device under MDR is not subject to the CRA here.

SBOM and supply-chain reality: the model is a dependency

The typical AI stack is more than your own code: pre-trained models and weights, ML frameworks (PyTorch, TensorFlow), inference runtimes (ONNX Runtime, TensorRT), tokenizers, data pipelines and a deep tree of Python dependencies. Each of these is a software dependency with its own vulnerability and EOL risk — an abandoned OSS framework or a model version with a known poisoning is just as much a supply-chain problem as an outdated C library.

The machine-readable SBOM must, under the CRA (Annex I) and BSI TR-03183-2, be in CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1, cover at least the top-level dependencies and form part of the technical documentation — there is no general obligation to publish it. For AI products this specifically means: track model, weights and framework with provenance, version and known vulnerabilities. CycloneDX already supports ML/AI component types for this; the exact form of the AI-BOM is still being clarified. Set this up cleanly now and you won't have to retrofit it in 2027.

Reporting capability and PSIRT: the Art. 14 cascade, understood correctly

From 11 September 2026 the reporting obligations under Art. 14 apply — the first hard manufacturer duty. If an actively exploited vulnerability or a severe security incident becomes known (for AI products typically an exploited prompt-injection path, a model extraction or a compromised update pipeline), the following cascade runs via the ENISA Single Reporting Platform:

• 24 hours — early warning from awareness.
• 72 hours — full notification including corrective or mitigating measures.
• 14 days — final report after a corrective measure is available, for an actively exploited vulnerability.
• 1 month — final report after the 72-hour notification, for a severe security incident.

The blanket shorthand "24h/72h/14 days" is wrong — the final report distinguishes between vulnerability (14 days) and incident (1 month). In practice your house needs a PSIRT/CVD process for this: a defined intake channel, a triage team able to assess AI-specific reports, and rehearsed 24/72-hour workflows across the entire support period (guideline at least five years, oriented to the expected product lifetime).

Deadlines: what comes first

Two dates structure your roadmap. On 11 September 2026 the reporting obligation (Art. 14) takes effect — PSIRT, CVD policy and the SRP connection must be in place by then. On 11 December 2027 the full product requirements follow (security-by-design, SBOM, technical documentation, CE marking, conformity assessment). So reporting capability first, then full product compliance — though SBOM and threat model need so much lead time that both should be started in parallel.

A worked scenario: maker of a smart inspection camera

A mid-sized manufacturer launches an industrial camera with on-device object detection; the model is based on a pre-trained OSS network, runs via ONNX Runtime and is served by OTA updates. The function is not a security function under Annex III — the product is Standard and self-assessed via Module A. The manufacturer produces a CycloneDX 1.6 SBOM that, alongside the firmware stack, tracks the ML runtime and model version with provenance. In the threat model it assesses adversarial inputs (manipulated images), data poisoning of the update path and model extraction, and derives hardening measures. It sets up a PSIRT intake and a CVD policy, rehearses the 24/72-hour cascade and plans model and framework security updates over at least five years. If an ONNX Runtime version gets an actively exploited vulnerability, exactly this cascade applies from September 2026. In parallel it assesses the AI Act classification separately — both coordinated, nothing conflated.

What Blackfort does for you

Blackfort Technology UG (haftungsbeschränkt) supports AI/ML manufacturers and importers along the entire CRA chain — with the rare addition of genuine AI security competency:

• Applicability and scope analysis: Is your AI product a PDE, which annex class is plausible, where does the CRA end and the AI Act begin?
• SBOM/AI-BOM setup: machine-readable SBOM in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1 including model, weights and frameworks.
• PSIRT & CVD: reporting processes and the Art. 14 cascade, rehearsed and SRP-ready.
• Risk assessment & threat modeling: including AI-specific threats (prompt injection, poisoning, model extraction) — based on ACS AI/LLM pentest expertise.
• Technical documentation: Annex I compliant, audit-proof, retainable for 10 years.

Start with the applicability analysis, read the basics in the CRA overview and the SME guide — or talk to us directly via contact.