CRA Compliance 2026: The 11 September Reporting Deadline and What the LiteLLM Cascade Teaches Us

The deadline that arrives before the standard does

On 11 September 2026, Article 14 of the Cyber Resilience Act starts to bite. From that date, any manufacturer placing a product with digital elements on the EU market must notify actively exploited vulnerabilities and severe security incidents: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days for a vulnerability or one month for an incident.

Most compliance roadmaps have the CRA filed under 2027. That is where the bulk of the regulation lands: CE marking, secure-by-design essential requirements, technical documentation and the software bill of materials all apply from 11 December 2027. But reporting is decoupled, and it comes first. The obligation applies to products already on the market, not only to products placed on it after the deadline.

The gap between those two dates is the whole problem. You are required to report component-level exploitation eighteen months before you are required to document your components.

The Commission published implementation guidance on 27 July 2026, and the notification channel, the Single Reporting Platform operated by ENISA under Article 16, is scheduled to be live on the same day the obligation starts. Current status is tracked on the Commission's CRA reporting page.

The primary text is Regulation (EU) 2024/2847. Article 14 sets the reporting duties, Article 16 establishes the Single Reporting Platform, and Annex I, Part II governs vulnerability handling and the software bill of materials.

A worked example: how a security scanner compromised an AI gateway

In March 2026 the threat actor group TeamPCP compromised LiteLLM, a widely deployed open-source AI gateway and proxy. Two malicious versions, 1.82.7 and 1.82.8, reached PyPI. They were live for roughly forty minutes.

The detail that matters is how they got there. LiteLLM was never targeted directly. Its build pipeline installed the Trivy vulnerability scanner without pinning it to a verified version, and Trivy's own release process had already been compromised for about twenty days. The poisoned scanner entered the LiteLLM build and produced poisoned LiteLLM packages. CloudSEK identified the same campaign across a third tool, Checkmarx KICS.

Read that again in control terms. The tool whose job was to find vulnerabilities in the pipeline was the vulnerability in the pipeline. It sat inside the trust boundary, ran with pipeline credentials, and was exempt from the scrutiny applied to application dependencies because it was classified as tooling rather than as code.

The payload ran on every Python invocation rather than on import, so it did not require an application to actually use the library. It executed anywhere the package landed: build runners, container images, ephemeral job containers, developer laptops, cached layers. It collected whatever credentials that process could reach.

CloudSEK's reconstructed exposure dataset links more than 2,500 organizations and roughly 434,000 CI/CD pipeline runs to the affected path. The firm is explicit that a high-confidence exposure match is evidence of exposure, not proof that any given organization was breached or that data was taken. That distinction is worth preserving when you brief a board.

So the containment question is less about whether you installed LiteLLM 1.82.7 during the forty-minute window, and more about which credentials were readable by any process on any runner that touched that dependency path, and whether every one of them has been rotated. Those are very different investigations, and only the second one closes the exposure.

Why this is a CRA problem, not just an incident-response problem

If your organization only consumes software, the LiteLLM cascade is a security incident and possibly a NIS2 matter. If your organization ships software, including software you sell, embed, license, or distribute as part of a connected product, it is also a reporting obligation with a clock on it.

Under the CRA, a manufacturer is whoever develops a product with digital elements and places it on the EU market under their own name or trademark. Company size is irrelevant. If you build it yourself and sell it, you are the manufacturer, which is the role carrying the heaviest obligations. Pure browser-delivered SaaS generally falls outside the CRA and into NIS2 instead, but the boundary is narrower than most teams assume once you ship an agent, an SDK, a plugin, a mobile app or firmware.

There is also an upstream duty that maps directly onto the LiteLLM chain: a manufacturer who identifies a vulnerability in a third-party component integrated into its product must notify the entity maintaining that component. In a three-hop cascade, the organization best placed to spot the compromise may be four dependencies downstream of it.

The overlap is the operational trap. A single credential-harvesting event in a build pipeline can plausibly trigger three of those four at once, on three different clocks, to three different authorities, with three different severity definitions. Organizations that treat CRA reporting as a new standalone process will miss deadlines, while those that extend an existing incident-classification and notification procedure will not.

The 24-hour clock starts at the moment you become aware rather than when you finish investigating, so build the process to make that moment defined, logged and owned. Otherwise you will be reconstructing it retrospectively in front of a regulator.

The SBOM you do not formally need until 2027, and actually need in September

Annex I, Part II, point 1 of the CRA requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials in a commonly used machine-readable format, covering at least the top-level dependencies. That requirement applies from December 2027.

The September 2026 obligation makes it a de facto 2026 requirement anyway. Article 14 asks you to report an actively exploited vulnerability affecting your product within 24 hours of becoming aware. When a compromise surfaces in a library three levels deep in a dependency tree, the only way to answer "which of our products and which versions contain this component" inside that window is to have already answered it.

Top-level dependencies are the stated floor, not a safe target. The LiteLLM cascade would have been invisible in a top-level-only SBOM of a downstream product: Trivy was build tooling, not an application dependency, and LiteLLM may itself have been transitive. If your inventory stops at direct dependencies, it will not answer the question the regulation asks.

Four gaps that break SBOM coverage in practice

Build tooling is not in the SBOM. Scanners, linters, formatters, test harnesses and release automation execute with pipeline credentials and are usually excluded from dependency inventories entirely. This is precisely the gap TeamPCP used.

The SBOM describes the release, not the build environment. Two artefacts with an identical bill of materials can be produced by pipelines with very different exposure, because the compromise landed in the environment rather than the shipped code.

Caches and base images drift from the manifest. A pinned dependency in a lockfile is not the same as a pinned dependency in the layer that actually ran, once you account for base images, ephemeral runners and warm caches.

Nobody owns freshness. An SBOM generated at release and never regenerated answers a question about the past. The 24-hour clock is a question about now.

Scope: three questions that settle it

Do you place a product with digital elements on the EU market under your own name or trademark? If yes, you are a manufacturer and Article 14 applies to you from 11 September 2026, including for products already sold.

Is the product still on the EU market on or after that date? Legacy products are in scope for reporting. The heavier essential requirements only reach existing products upon substantial modification from December 2027.

Is it genuinely out of scope? Pure browser-delivered SaaS is generally outside the CRA, and non-commercial open source is exempt, though the CRA creates a lighter-touch "open-source software steward" role rather than a blanket exclusion, and commercial supply of open-source components pulls you back in. Being outside the CRA usually means being inside NIS2, so this is rarely a route to having no obligation at all.

The Article 14 clock, end to end

Notification goes to the CSIRT designated as coordinator in the member state where you have your main establishment, and is made available to ENISA at the same time. You report once, through the Single Reporting Platform, rather than to each authority separately.

Note what Article 14 does not require. It is not a duty to report every CVE. It applies to vulnerabilities that are being actively exploited in the wild, and to severe incidents affecting the security of the product. Nor does the CRA itself require you to notify business customers, but review your contracts, because customers increasingly impose exactly that by agreement, on tighter timelines than the regulation.

Where CRA meets NIS2 and the supply chain

NIS2 Article 21(2)(d) already requires essential and important entities to take measures addressing supply chain security, including the security-related aspects of relationships with direct suppliers and service providers. The CRA approaches the same risk from the opposite end: it regulates what those suppliers must build and disclose.

For most organizations both apply, in different roles. You are a NIS2 entity managing your suppliers, and a CRA manufacturer being managed by your customers. The evidence that satisfies one largely satisfies the other: a component inventory, a supplier assessment process, a vulnerability-handling procedure and a notification runbook, provided it was designed once rather than three times.

This is where ISO 28000 earns its place. It provides a management system for security in the supply chain, which is the structure most organizations lack when they try to answer supplier-risk questions consistently across procurement, engineering and compliance. The alternative, a spreadsheet of vendor questionnaires, does not survive a cascade like LiteLLM, because the compromised party was never a vendor anyone had assessed.

A 30-day readiness plan

The realistic goal before 11 September is not full CRA conformity. It is being able to make a defensible notification on time. That is a much smaller scope, and it is achievable in the time remaining.

The tabletop is the step teams skip and the one that finds the real gaps. Run it with the scenario stated as it actually arrives: a public advisory names a package your build pipeline uses, you do not yet know whether it reached production, and the clock is already running.

What to take from this

Despite the framing it has received, the LiteLLM compromise is less a story about AI than about a build pipeline that trusted its own tooling, an unrevoked credential and a dependency chain nobody had mapped. The AI layer made it worse only because AI gateways sit unusually close to credentials for cloud accounts, model providers and vector stores.

What changes on 11 September 2026 is that the same event now carries a 24-hour notification duty for anyone who ships software into the EU. The regulation asks you to know quickly whether the cascade reached you and to say so, rather than to prevent it happening at all.

That is a component-inventory problem and an incident-classification problem, well before it is a regulatory problem. Organizations that already run both as disciplines will find Article 14 a small addition. The rest have about thirty days.