CRA September 2026 Deadline: What AI API Providers Using Open Source Models Must Prepare For

The Cyber Resilience Act enters its first compliance gate in September 2026, not December 2027. That five-month gap is where most AI API providers will get caught. Regulation (EU) 2024/2847 applies to any "product with digital elements" placed on the EU market, and that definition captures AI inference APIs, model-serving platforms, and any cloud service that wraps open source models in a commercial offering. If a provider serves Mistral, Llama, or Qwen weights through a paid API endpoint, the CRA treats that provider as a manufacturer with specific obligations starting 21 months after the regulation entered into force on December 10, 2024.

The September 2026 gate is about notification, not documentation

Article 14 of the CRA requires manufacturers of products with digital elements to notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability, followed by a substantive report within 72 hours. This obligation activates in September 2026, well ahead of the December 2027 deadline for full conformity assessment, SBOM requirements, and security-by-design documentation.

For AI API providers, this is an operational requirement, not a paperwork exercise. When a critical vulnerability is disclosed in a model's inference framework, a tokenizer library, or a serving dependency like vLLM or llama.cpp, the provider must have detection workflows, triage processes, and a regulatory notification pipeline ready. A provider that discovers a vulnerability on a Friday and reports it the following Wednesday will be in breach.

The 24-hour window assumes the manufacturer already has internal processes to detect and assess vulnerabilities. Building those processes from scratch in five months is feasible but requires focus. Providers relying on informal security channels, community issue trackers, or ad hoc monitoring will find September 2026 unworkable without structural changes.

Open source models create commercial CRA obligations

The CRA distinguishes three categories of actor, and the distinction determines the scope of obligations:

Category	CRA Obligations	Example
Commercial vendor (manufacturer)	Full: security by design, SBOM, vulnerability management, conformity assessment, ENISA notification	An API gateway serving Llama 3 via a paid endpoint
Open source steward	Lighter: cybersecurity policy, vulnerability disclosure, cooperation with authorities	The Meta team maintaining Llama weights under a community licence
Internal use	Exempt: software built and used within a single organisation, never placed on the market	A bank fine-tuning Mistral for internal document analysis

The critical point for AI API providers: bundling open source models into a commercial product transfers the compliance burden to the vendor, not the model's original developer. When a platform packages vLLM, PyTorch, transformers, and a quantised GGUF file behind a paid API, the platform owns the CRA obligations for that entire stack. The Apache Software Foundation does not inherit liability for Kafka when a payments vendor embeds it. The same principle applies to model weights and inference runtimes.

This is why asserting "we serve open source models" is not a CRA defence. The regulation targets the commercial product, not the licence of its components.

SBOM requirements reach into the model supply chain

Under CRA Article 10, manufacturers must include a Software Bill of Materials as part of their technical documentation. For traditional software, an SBOM lists libraries, versions, known vulnerabilities, and licences. For AI API providers, the SBOM must also account for:

• The inference runtime (vLLM, llama.cpp, TensorRT-LLM) and its transitive dependencies
• Model tokenizers and their underlying library dependencies
• CUDA, ROCm, or other GPU acceleration layers
• Quantisation tooling (AutoGPTQ, llama.cpp conversion scripts)
• The model weights themselves, including training data disclosures where required by the AI Act

Generating this is not a one-time exercise. The SBOM must be maintained and updated as dependencies change. A model provider pushing a new quantised checkpoint without updating the SBOM is non-compliant. Teams that treat SBOMs as pre-audit paperwork rather than continuous pipeline artifacts will produce documentation that is stale by the time auditors review it.

Tooling exists. Syft generates SBOMs from container images, Grype scans them against vulnerability databases, and FOSSA handles licence compliance alongside security scanning. The key is integration into CI/CD pipelines, not manual generation before audit windows.

DORA and CRA overlap for financial services AI procurement

Financial entities subject to DORA (Regulation (EU) 2022/2554, fully applicable since January 17, 2025) face the CRA as an overlapping regime. DORA requires ICT third-party risk assessment. The CRA requires product security conformity from vendors. For a bank procuring an AI inference API, both regulations demand due diligence from the same vendor through different lenses.

DORA asks: "Is this ICT provider resilient, and does it manage operational risk?" The CRA asks: "Is this software product secure by design, and does its manufacturer handle vulnerabilities properly?"

No joint implementing act has been issued. The EBA has acknowledged the interaction but specific guidance for financial services software has not materialised. The pragmatic approach is to treat CRA compliance as additive to DORA. A vendor that produces CRA conformity documentation with an up-to-date SBOM, vulnerability disclosure policy, and ENISA notification process will, in most cases, satisfy DORA's third-party assessment requirements as well. Waiting for the carve-out creates procurement risk.

For AI API providers specifically, DORA Article 28 requires financial entities to maintain concentration risk strategies for critical ICT services. An API provider routing all inference through a single non-EU cloud jurisdiction creates exactly the concentration risk DORA addresses. Multi-provider, EU-jurisdiction routing is the architectural answer, and it is one of the areas where ozeye's approach of routing through Mistral AI, Scaleway, and OVHcloud with automatic fallback becomes relevant.

Practical steps before September 2026

1. Map the software supply chain. Conduct a dependency audit across every container image and runtime in the inference stack. Identify which components are products with digital elements, who the manufacturer is, and whether each component is subject to CRA obligations.

2. Update procurement questionnaires. Add CRA-specific sections: compliance plan timeline, SBOM availability, vulnerability notification turnaround. Vendors that cannot answer these questions by mid-2026 are behind schedule. That information is useful before contract renewal.

3. Build the notification pipeline. The 24-hour ENISA notification window requires detection, triage, and reporting infrastructure. This is an operations problem, not a legal one. Security teams need to own the SLA, not compliance teams.

4. Assess manufacturer status honestly. If the organisation builds, packages, or distributes AI inference software to external users, affiliates, or clients under licence, it is likely a manufacturer under the CRA. The September 2026 notification requirements apply directly.

5. Verify SBOM coverage. Ensure SBOM tooling runs in CI/CD for every release, not manually before audits. Each inference container, model artefact, and serving dependency must be captured.

The December 2027 full compliance date is workable. The September 2026 gate is not a stretch target. It is a regulatory deadline with enforcement consequences, and it is closer than most teams think.

This is an interpretation of Regulation (EU) 2024/2847, not legal advice. Verify your organisation's specific obligations with qualified counsel.