CRA for AI & ML: AI Act and Model SBOM

Last updated: 2026-10-09

AI in the product means the CRA applies alongside 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), in principle 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 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) need a reliable 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, which has to be implemented in parallel? 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: the company takes part in the AI security expert group of the Alliance for Cyber Security and contributed to the guideline on penetration testing of large language models published there. This is 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: a product is generally in scope if it is made available on the EU market in the course of a commercial activity and its intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)) - 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. AI products without an Annex III or Annex IV function fall into the Standard category and are assessed via self-assessment (Module A). What counts for the classification is the function of the product under Annex III/IV; whether AI is built in plays no role for this.

AI/ML product (example)	Likely classification	Rationale (schematic)	Conformity route
Industrial camera with on-device object detection	Standard	AI performs a function, not an Annex III function	Self-assessment (Module A)
Smart-home device with a general-purpose virtual assistant, home security camera with AI	Annex III, class I (No. 16 or 17)	listed expressly	Module A only under full application of harmonised standards, common specifications or a European scheme (at least “substantial”), otherwise Module B+C or H
ML-driven SIEM / anomaly detection, AI antivirus	Annex III "important", Class I	SIEM and antivirus are explicitly Class I categories	as above
AI-driven firewall / IDS-IPS, hypervisor with ML functionality	Annex III "important", Class II	Firewalls, IDS/IPS, hypervisors are Class II	Module B+C, Module H or a European scheme of at least “substantial”
ML accelerator as tamper-resistant microcontroller / secure element with AI	Class II or Annex IV "critical"	Tamper-resistant microprocessors = II; HSM/secure elements = critical	Class II as above; Annex IV: a European scheme where a delegated act requires one, otherwise as for class II

Matrix with the schematic classification of typical products in AI and ML products into the bands default (not in Annex III/IV), class I and class II (Annex III) and critical (Annex IV). Industrial camera with on-device object detection: default; Smart-home device with a general-purpose virtual assistant, home security camera with AI: class I; ML-driven SIEM, AI antivirus: class I; AI-driven firewall, IDS/IPS, hypervisor with ML functionality: class II; ML accelerator as tamper-resistant microcontroller or secure element: class II (depending on core function or scope) or critical (depending on core function or scope). Assessment routes: default self-assessment (module A), module B+C, H or an EU scheme also possible; class I module A only if harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least substantial) are fully applied, otherwise modules B+C or H; class II modules B+C, module H or a European cybersecurity certification scheme at assurance level at least substantial; critical a European cybersecurity certification scheme where required by delegated act, otherwise as class II. What counts is the core function (Art. 7(1)); integrating a component with an Annex III core functionality does not in itself trigger the class I or II procedures (Art. 7(1), second sentence); schematic orientation, not a classification of an individual case. — Typical products in AI and ML products and their schematic classification; sources: Art. 7, Art. 8, Art. 32, Annexes III and IV of Regulation (EU) 2024/2847.

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 apply; harmonised standards for the CRA have been requested (M/606) but were not yet published in the Official Journal on 9 October 2026. For the SBOM, BSI TR-03183-2 (v2.1.0) is a widely used technical reference. For AI specifically, an "AI-BOM/model-BOM" is being discussed as an extension of the classic SBOM. Clean separation of the regimes matters:

AI Act (Regulation (EU) 2024/1689): applies alongside the CRA and addresses the risks of AI use - high-risk classification, transparency, data governance. For high-risk AI systems Article 12 CRA links the two: meeting Annex I and demonstrating this in the EU declaration of conformity satisfies the cybersecurity requirements of Article 15 AI Act to that extent, and conformity assessment generally follows Article 43 AI Act; important and critical products for which the AI Act would only provide for internal control remain subject to the CRA procedures (Article 12(3)). The cybersecurity risk assessment may form part of the risk assessment under the AI Act (Article 13(4)).
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 and can communicate over the internet; until the regulation is repealed with effect from 11 Dec 2027, overlap with the CRA can arise and must be delineated.
NIS2 / DORA: concern entities (essential/important entities or the financial sector), not the product manufacturer duty. Manufacturers of electronic products can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. Not to be equated with the CRA.
Exemptions: exempt are products to which the MDR, the IVDR or Type-Approval Regulation (EU) 2019/2144 apply, aviation products certified under Regulation (EU) 2018/1139, and marine equipment (Article 2(2) to (4)) - 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 CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation - there is no general obligation to publish it. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. For AI products it makes sense to 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 early and the bill of materials is part of routine operations by 11 December 2027.

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

Since 11 September 2026 the reporting obligations under Art. 14 have applied, the first hard manufacturer duty. If an actively exploited vulnerability or a severe incident becomes known (for AI products, for example, an exploited prompt-injection path, a model extraction or a compromised update pipeline), the following cascade runs via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA:

24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware.
72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
14 days - final report after a corrective or mitigating measure is available, for an actively exploited vulnerability.
1 month - final report after the 72-hour notification, for a severe 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 early-warning and notification workflows across the entire support period (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)).

Deadlines: what comes first

Two dates structure your roadmap. Since 11 September 2026 the reporting obligation (Art. 14) has applied; PSIRT, CVD policy and the connection to the single reporting platform must therefore already be in place. 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. The technical documentation must be retained for at least ten years after placing on the market or for the longer support period (Article 13(13)).

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 an Annex III category - 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 cascade (early warning without undue delay and within 24 hours at the latest, notification within 72 hours at the latest) and plans model and framework security updates across the entire support period. If an ONNX Runtime version gets an actively exploited vulnerability, exactly this cascade has applied since September 2026. In parallel it assesses the AI Act classification separately and aligns both sets of evidence.

What Blackfort does for you

Blackfort Technology supports AI/ML manufacturers and importers along the entire CRA chain, with experience from contributing to the Alliance for Cyber Security's guideline on penetration testing of large language models:

Applicability and scope analysis: a technical assessment of whether your AI product is a PDE, which annex class is plausible and where the CRA and the AI Act interlock.
SBOM/AI-BOM setup: machine-readable SBOM, for example in CycloneDX or SPDX, including model, weights and frameworks.
PSIRT & CVD: reporting processes and the Art. 14 cascade, rehearsed and connected to the single reporting platform.
Risk assessment & threat modeling: including AI-specific threats (prompt injection, poisoning, model extraction), drawing on our contribution to the Alliance for Cyber Security guideline.
Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)).

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

Frequently asked questions

Does an AI model belong in the SBOM?+

Model, weights and ML framework are software dependencies with their own vulnerabilities and thus SBOM-relevant in principle. The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)); it does not prescribe a specific format, and the Commission may specify one by implementing act (Article 13(24)). BSI TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. The exact form as an AI-BOM/model-BOM is still being clarified.

Does the AI Act replace the CRA for AI products?+

No. The AI Act (Reg. (EU) 2024/1689) and the CRA are separate legal acts with different objectives - the AI Act addresses the risks of AI use, the CRA the cybersecurity of the product. Both apply side by side. For high-risk AI systems Article 12 CRA links them: meeting Annex I and demonstrating this in the EU declaration of conformity satisfies the cybersecurity requirements of Article 15 AI Act to that extent; conformity assessment then generally follows Article 43 AI Act.

Does an AI product always have to be assessed via a notified body?+

No. AI products without an Annex III or Annex IV core function are likely to fall into the default category and are assessed by self-assessment (Module A). For class I, such as AI-based SIEM or antivirus, a notified body is needed as long as no harmonised standard, common specification or European scheme (at least 'substantial') is fully applied; for class II and for critical products under Annex IV the procedures of Article 32(3) and (4) apply. This is a schematic classification, not individual legal advice.

Which AI-specific threats belong in the risk assessment?+

Beyond classic software risks, AI-specific threats such as prompt injection, model extraction, data poisoning and adversarial inputs belong in the Annex I risk assessment and threat modeling. This analysis is part of the documented risk assessment under Art. 13 and Annex I.

What applies first - the reporting obligation or the full product requirements?+

The reporting obligation first: the reporting obligations under Art. 14 have applied since 11 September 2026, the full product requirements apply (SBOM, security-by-design, technical documentation, CE) from 11 December 2027. PSIRT and the CVD process must therefore already be in place; but SBOM and threat model need so much lead time that they should start in parallel.

Does an exploited prompt injection fall under the Art. 14 reporting obligation?+

If such a vulnerability is actively exploited or leads to a severe incident, the Art. 14 cascade likely applies: early warning without undue delay and within 24 hours at the latest, notification with the general information available within 72 hours at the latest, then a final report after 14 days (for an actively exploited vulnerability, once a corrective or mitigating measure is available) or 1 month (for a severe incident), reported via the single reporting platform.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).