That is the part of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) that switches first. The conformity assessment machinery, CE marking, technical documentation, the Annex I essential requirements, waits until December 11th, 2027. The provisions on notifying conformity assessment bodies have applied since June 11th, 2026, but they were aimed at Member States and notified bodies rather than at you. September 11th is the first CRA obligation that lands on manufacturers, and it’s the one with a stopwatch attached.
It's worth being clear about who "you" is (although if you're reading this blog on our website, the you is probably you), because the Commission's guidance of July 27th (C(2026) 5252 final) narrowed the scope in one direction while confirming it in another.
Software is a product with digital elements that is supplied to a user and executed on the user's side. Browser extensions and locally installed applications, including Electron apps, are in scope. A web app or PWA that runs only in the browser is not a product on that basis alone, NIS2 covers that ground instead. Ship a local client, though, and the server-side it depends on can serve as a remote data-processing solution. And the reporting obligation applies to products already placed on the market before December 2027 and continues after the support period ends.
What actually changes on September 11th
Article 14 sets out a three-stage cadence for two triggering events: an actively exploited vulnerability in your product, and a severe incident affecting your product's security.
You submit once, through ENISA's Single Reporting Platform. It goes to the CSIRT designated as coordinator in the Member State of your main establishment, where decisions about your products' cybersecurity are predominantly taken, and to ENISA simultaneously. Article 14(7) provides a cascade of authorized representative, importer, distributor and user location for manufacturers with no EU establishment.
Two things about the report itself. First, it is confidential: it goes to your CSIRT and ENISA, not to the public. Reporting is not publishing. Second, Article 14(8) separately requires you to inform users, "where appropriate in a structured, machine-readable format that is easily automatically processable." The guidance is specific here, customers you have a direct relationship with must be told directly, while a general advisory covers the broader user base. If you don't tell them, the notified CSIRTs may do it for you.
The penalties, without the drama
Article 64 sets three tiers of administrative fines:
- Up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of the Annex I essential requirements or the Article 13 and 14 obligations, which is where reporting sits, in the top bracket.
- Up to €10 million or 2% for other obligations under the regulation.
- Up to €5 million or 1% for supplying incorrect, incomplete, or misleading information to notified bodies or market surveillance authorities.
Microenterprises and small enterprises are exempt from fines for missed reporting deadlines, and open source software stewards aren't subject to administrative fines at all.
Fines are the headline, but they're probably not the biggest commercial exposure. Market surveillance authorities can also require products to be withdrawn from the market, prohibit their availability, or order a recall. For most software vendors, "you may not sell this in the EU until you fix it" is a considerably worse quarter than a fine.
The clock starts at "aware", and "aware" is a decision you have to defend
At the risk of sounding like AI slop: this is an important operational consideration. Paragraph 213 of the guidance says a manufacturer is aware only once, following an initial assessment, it can assume with a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has affected the product's security. You are allowed to verify a suspicion before the clock starts.
You are not allowed to take your time about it. Paragraphs 213 and 214 require the assessment to begin without delay, whether the tip comes from a customer, a researcher, an authority, or the press. Dragging out verification does not move the deadline, it invites the argument that you became aware earlier than you claim. The practical controls are timestamps: when the report arrived, when the assessment began, and when you verified. Without that record, it looks in hindsight as though the clock started at intake.
Equally useful is what isn't reportable. Scanner findings, a published CVE with no exploitation in your product, a coordinated disclosure, your own pentest results — none of these start a 24-hour clock, and Article 14 imposes no duty to go hunting for exploitation in the first place.
There’s an important exception to the actively exploited condition: a researcher report revealing planted malicious code or a compromised build pipeline is considered a severe incident under Article 14(5)(b), reportable without any established exploitation.
The 24 and 72 hours are calendar hours. They run through weekends, holidays, and executive offsites.
Reachability will become an essential data point.
Paragraph 218 confirms that what matters is exploitation in your product. If a vulnerability in a third-party component is exploited in your product, you report. If it cannot be exploited in your product, or has not been exploited there, the Article 14 obligation falls away — even where the same CVE is being actively exploited in somebody else's product. What remains is voluntary notification under Article 15 and telling the component maintainer under Article 13(6).
Right now, the ‘not actively exploited’ condition will save many people from having to do anything. Come December next year, when requirements to make fixes available take effect, it’s going to make the difference between sensible protection for your customers and a remediation apocalypse.
Exploitability in your specific product is moving from a triage nicety to the thing that determines whether you have an actionable event at all. And that determination is only as good as your ability to make it, quickly, and with evidence.
Most software composition analysis produces an inventory: every CVE in every declared dependency, ranked by a severity score that knows nothing about your code. Endor Labs SCA changes the unit of analysis from the dependency to the function, tracing whether the vulnerable function is actually callable across direct, transitive, and phantom dependencies. That cuts findings by an average of 92%. As Travis McPeak at Cursor put it: "Over 97% of vulnerabilities flagged by our previous tool weren't reachable in our application."
Containers matter here because the CRA does not care which layer of your artifact the vulnerability lives in. A typical production image returns hundreds of vulnerability findings, most of them in OS packages the application never loads— for example, a statically compiled binary that ships glibc but never calls into it. Endor Labs Container Reachability extends the same analysis down through the runtime and OS layers, classifying each package as Reachable, Potentially Reachable, or Unreachable, and cutting container noise by up to 90% without forcing a migration to distroless base images.
Fewer false positives, shorter list
Annex I's requirement to ship without known exploitable vulnerabilities is a December 2027 obligation, not a September one. But the guidance records something in passing that is worth thinking about now: findings produced by AI-assisted analysis constitute awareness for the purposes of a known exploitable vulnerability. Test aggressively and you generate obligations a more reticent competitor does not have.
That is an argument for accurate tooling, not less of it. A false positive you cannot confidently dismiss is an obligation you cannot cleanly discharge. Endor Labs AI SAST orchestrates detection, triage, and remediation agents on top of a semantic code model rather than pattern matching — where legacy static analysis has historically run hot, with NIST's study of C/C++ tools measuring 69% false positives. In our June 2026 benchmark across eight real-world projects, it found 192 real vulnerabilities, around 3x what frontier models found, with 4x more high-severity findings than the strongest traditional tool (72 vs 17) and roughly 60% fewer false positives. Every confirmed finding ships with a written classification rationale and a context-aware fix.
Suggested homework
None of this is legal advice, and your counsel should have the final word on scope. But if you want a practical list:
- Scope your portfolio against section 2.2 of the guidance, and against the variants rule in paragraph 14 — separate OS builds and bundles with differing feature sets are distinct products, each with its own documentation and support period.
- Record which Member States each product is available in. The early warning asks for it.
- Determine your coordinating CSIRT now, using the Article 14(7) main-establishment test.
- Name a reporting owner and a deputy, and build an out-of-hours path. Calendar hours include weekends.
- Set up an intake channel for tips. The public single point of contact isn't formally required until December 2027 under Article 13(17), but you cannot promptly assess what never reaches you.
- Impose timestamp discipline: intake, assessment start, verification.
- Be able to produce an SBOM per product per release, not per repository.
- Register for the Single Reporting Platform and dry-run a submission before you need one.
September 11th is a reporting deadline, but the work it exposes is inventory and exploitability work — knowing what you ship, knowing what's actually reachable in it, and being able to prove both on a Saturday. That work doesn't get easier in December 2027, when the handling and documentation obligations arrive on top.
If you'd like to see what reachability does to your own findings before the clock starts, request a demo.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: