From 11 September 2026, a manufacturer of products with digital elements that discovers an actively exploited vulnerability has twenty-four hours to send a first warning to ENISA and the national CSIRT, and seventy-two for the full notification. The duty covers products already sold. The hard part is not the speed of the report: it is that within twenty-four hours you have to know whether that vulnerable component is inside your product. And that is an inventory question, not a security one.
01What exactly starts on 11 September 2026?
The Cyber Resilience Act — Regulation (EU) 2024/2847 — entered into force on 10 December 2024 and applies in general from 11 December 2027. But the Regulation has a staggered calendar, written into Article 71: "This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026". Article 14 is the one on reporting obligations, and it is the first piece of the CRA to become enforceable.
Two kinds of event must be reported. An actively exploited vulnerability is one "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)). A severe incident is one that negatively affects — or can negatively affect — the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that leads to the execution of malicious code in the product or in a user's systems (Article 14(5)).
The clocks, for both cases, run like this:
- 24 hours — early warning: "without undue delay and in any event within 24 hours" of the manufacturer becoming aware. It is enough to say that the event exists and in which Member States the product is available.
- 72 hours — the notification proper: the nature of the problem, an assessment, and any corrective or mitigating measures taken or available.
- 14 days — the final report for actively exploited vulnerabilities, "no later than 14 days after a corrective or mitigating measure is available".
- 1 month — the final report for severe incidents, counted from the submission of the 72-hour notification, not from the availability of a patch: a difference that matters when you write the procedure.
Reports go simultaneously to the CSIRT designated as coordinator and to ENISA, through a single channel: the Single Reporting Platform established under Article 16, which ENISA operates and maintains and which becomes operational on 11 September 2026 (ENISA, Single Reporting Platform). You report once: the platform distributes the information to the CSIRTs of the other Member States where the product is available.
02Does it apply to products already on the market?
Yes, and this is the part that surprises people most. The CRA's general transitional rule (Article 69(2)) says that products placed on the market before 11 December 2027 are subject to the Regulation only if, from that date, they undergo a substantial modification. It looks like a comfortable way out. The next paragraph closes it: "By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027" (Article 69(3)).
In operational terms: the compliance machinery — essential requirements, technical documentation, CE marking — concerns new products and starts in December 2027. The duty to report starts earlier and concerns the entire installed base. Including that release you shipped four years ago, that nobody touches any more, and that a customer still runs in production.
03Who counts as a "manufacturer", and what is at stake?
The Regulation defines a manufacturer as "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark" (Article 3(13)). The consequence is blunt: it does not matter who wrote the code, it matters whose name is on the box. If you ship under your own brand a product someone else built for you, the reporting duty is yours.
The product perimeter is wide — "software or hardware product and its remote data processing solutions, including components placed on the market separately" (Article 3(1)) — but not unlimited. Recital 12 clarifies that cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the CRA: pure SaaS sits rather in the NIS2 perimeter. But cloud functionality without which the product cannot perform its function is part of the product.
On financial exposure the text is explicit: non-compliance with the essential requirements of Annex I and the obligations of Articles 13 and 14 carries fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher (Article 64(2)). There is, however, a valve: paragraph 10 of the same article exempts microenterprises and small enterprises from administrative fines, but only for failure to meet the twenty-four-hour deadline. Read it for what it is: the obligation stands, the 72-hour notification and the final report remain sanctionable. It is not a postponement — it is breathing room on the first alert.
04Why twenty-four hours is an inventory problem
The scene is always the same. A CVE lands on a widely used library, with evidence of exploitation in the wild. The question is not "how do we fix it" — that comes later — but "is it inside one of our products? which version? at which customers? in which EU countries?". If the answer depends on three people opening repositories and reading dependency files from memory, it does not arrive within twenty-four hours. And if it does not arrive, it is not that you report badly: you have no data to report.
The size of the problem is not an impression. Black Duck's 2026 OSSRA report, built on 947 commercial codebases across 17 industries, measures an average of 581 open source vulnerabilities per codebase, more than double the previous year (+107%), with 87% of codebases containing at least one, and the average number of open source components up 30% in twelve months (Black Duck, OSSRA 2026). Commercial software today is overwhelmingly assembled: the part written in house is the minority.
And readiness is not keeping up: in ENISA's survey of European SMEs (194 organisations, 31 countries, February-March 2026) the area with the lowest scores is precisely incident handling and product lifecycle management (ENISA, 13 July 2026) — exactly the capability that becomes mandatory on 11 September 2026.
05What the CRA actually says about SBOMs (and what it does not)
Precision matters here, because a fair amount of commercial confusion is circulating around this deadline. The SBOM — software bill of materials: the machine-readable list of the components a product is made of — is not an obligation that starts on 11 September 2026. It sits in Annex I, Part II, point 1, among the vulnerability handling requirements, and asks manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products".
Three things must be said honestly, because the text says exactly these and no more:
- The date is 11 December 2027, not September 2026: Annex I is part of the essential requirements, which apply with the general application of the Regulation and, under Article 69, to products placed on the market from that date or substantially modified afterwards.
- The legal minimum is top-level dependencies. The text says "at the very least": it does not impose the full transitive tree. Anyone claiming the CRA mandates a recursive SBOM is selling, not quoting.
- The SBOM does not have to be published. The Regulation does not require disclosure: it is kept in the technical documentation and made available to market surveillance authorities on request (Recital 77).
So: in September 2026 nobody fines you for not having an SBOM. They fine you, if at all, for not reporting in time. And that is where the circle closes: the SBOM is not what the law asks of you in September, it is what makes what the law asks of you in September survivable. Building it now settles two deadlines with one piece of work — the twenty-four-hour window today, Annex I in December 2027.
06What about AI-generated code?
This is the point that changes the nature of the problem, and almost nobody connects it to the CRA. The same OSSRA report records that roughly 85% of organisations use AI-powered coding assistants — and that 76% of those that ban them acknowledge their developers use them anyway — with the average number of files per codebase up 74% in a year.
The most discussed risk is the hallucinated dependency: a study presented at USENIX Security 2025 generated 576,000 code samples with 16 models and found non-existent packages in 5.2% of cases on commercial models and 21.7% on open-source ones, for a total of 205,474 unique package names that never existed (Spracklen et al., USENIX Security 2025). An invented name that someone actually registers becomes a clean way in — the phenomenon known as slopsquatting.
But the hallucinated dependency is the pathological case, and also the easiest to catch: a package that does not exist breaks the build. The ordinary case is quieter and, for the CRA, more important: the AI imports packages that do exist and do work, and that nobody consciously chose. Nobody assessed them for maintenance, licence, provenance or vulnerability history. Nobody decided to take responsibility for them: they simply appeared in the dependency file alongside a function that was needed.
If the acceptance criterion for that code is "it works", the criterion works beautifully — until you have to declare to an authority what is inside your product, within twenty-four hours, with your name on the box.
This is not an argument against AI in development: the productivity is real. It is an argument about the gate. If generation speeds up tenfold and the gate stays "the tests pass", the inventory falls apart ten times faster. The right gate is trivial to describe and takes discipline to hold: every build produces its own bill of materials, every new dependency shows up in a diff a human looks at, every component has an owner. Teams generating code with AI need an SBOM more, not less.
07What to put in the contract, and what to do now
There is a structural asymmetry in the CRA that SMEs run into immediately: the obligation sits with whoever places the product on the market under their own name, but knowledge of the components often sits with the software supplier. The Regulation requires manufacturers to exercise due diligence when integrating third-party components, "so that those components do not compromise the cybersecurity of the product" (Article 13(5)) — but in practice, due diligence is exercised through the contract. Three clauses, to be written before you need them:
- Supplier notification times tighter than your own. If you have twenty-four hours from becoming aware, the supplier must alert you within a fraction of that, through a named channel and recipient — not a generic support address.
- Delivery of the SBOM with every release, in a commonly used, machine-readable format, updated whenever a dependency changes. It is the only way the inventory stays alive instead of becoming an expired snapshot.
- Cooperation during the reporting window, with defined availability and explicit responsibility if the delay originates upstream. Add the length of the support period and of security update provision: that is a contractual variable, not a given.
Internally, the order that works is this. First, scope: which products you place on the market under your own name, and in which EU countries they are available — the list of countries is information the early warning explicitly asks for, and it is usually the one that is missing. Second, the component inventory, generated automatically inside the build pipeline: an SBOM produced by hand is already stale the next day. Third, a reporting procedure with names and phone numbers, answering one question — who decides, at three in the morning on a Saturday, that this event must be notified — rehearsed at least once, cold. Fourth, the contracts. In that order: the fourth without the first is worth nothing.
Continuous technical monitoring — correlating new CVEs against the inventory every day — is a different capability, and in our family it lives with Fenrir. But it comes afterwards: without an inventory there is nothing to correlate. The work P3 does on this deadline is the upstream work, and it is the boring kind: scope, bill of materials, procedure, clauses. It is the same method we use for NIS2 and DORA — the picture first, then the decisions — and the same logic of control we call operational sovereignty: knowing what is inside your systems is the precondition for every other choice, including sovereign software and the assessment of a cloud provider. If the starting point is a picture of network, data and suppliers, that is a seven-day on-prem audit.