24 Hours to Report: What the EU Cyber Resilience Act's Live Incident Rules Mean for AI Agent Builders

On 11 September 2026, a quiet but consequential deadline passed in Europe. The reporting obligations in Article 14 of the EU Cyber Resilience Act (CRA) took effect, more than a year before the rest of the regulation applies in December 2027. Since that date, manufacturers of software and connected products sold in the EU have been on a legal clock: when a vulnerability is being actively exploited or a severe incident hits a product, they have 24 hours to raise the alarm.

For companies shipping AI-powered products, agent platforms, SDKs, and developer tools, this is not a distant compliance topic. It is live today, and it applies to products you have already sold. This post explains what the CRA’s reporting rules require, why they matter for teams building agentic software, and what to put in place before your first real incident.

What Article 14 Actually Requires

The CRA (Regulation (EU) 2024/2847) governs “products with digital elements,” a deliberately broad category covering software and hardware sold on the EU market. Article 14 is its incident-reporting backbone, and it is narrower than many people assume.

Two triggers, not one

According to an independent guide to the regulation, a report is required in only two situations:

• An actively exploited vulnerability, meaning there is reliable evidence that a malicious actor has exploited the flaw without the owner’s permission. Flaws fixed before any exploitation go through normal vulnerability handling instead.
• A severe incident that negatively affects, or could negatively affect, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions.

Ordinary bugs and routine patches are out of scope. The trigger is real-world exploitation or a serious security incident.

The three-step clock

Once you become aware, the sequence is strict:

1. Early warning within 24 hours. For incidents, this states whether unlawful or malicious acts are suspected.
2. Fuller notification within 72 hours. This describes the nature of the vulnerability or incident, an initial assessment, and mitigating measures.
3. Final report. For exploited vulnerabilities, this is due within 14 days after a fix or mitigation is available. For severe incidents, it is due within one month of the 72-hour notification.

Reports go through the ENISA Single Reporting Platform to both ENISA and the national CSIRT acting as coordinator, which follows your main EU establishment.

When does the clock start?

“Becoming aware” is the phrase that matters. Law-firm summaries of the European Commission’s July 2026 guidance say a manufacturer is considered aware once an initial assessment gives it a reasonable degree of certainty that exploitation or a compromising incident has occurred. You do not get to wait for a perfect forensic picture, but you also are not expected to report every suspicious log line.

The Details That Catch Teams Out

It applies to products already on the market

Under Article 69(3), Article 14 reporting covers in-scope products placed on the market before December 2027, even if they are never substantially modified. Shipping legacy code does not exempt you.

It outlives support

Vulnerability-handling duties end with a product’s support period. Reporting duties do not: they continue after a product is no longer supported. An old SDK version you stopped patching can still generate a reporting obligation if it is exploited.

Third-party components count

If an actively exploited vulnerability sits in a third-party component inside your product, you generally must report it. The exception is when the vulnerable code cannot be exploited in your product (for example, it is unreachable) or has not been exploited there. For teams stitching together open-source libraries, model-serving stacks, and agent frameworks, this makes your dependency inventory a legal asset.

Users must be told too

Article 14(8) requires manufacturers to inform affected users, and where appropriate all users. The approach is risk-based and need not be public, but it means your customer-communication path needs to be ready alongside your regulator path.

No retroactive reporting

Exploitation known before 11 September 2026 does not need to be reported. A vulnerability known earlier without exploitation becomes reportable if exploitation emerges after that date.

The Penalty Exposure

Article 64 sets the top fine tier at up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of the Annex I essential requirements and the obligations in Articles 13 and 14. One compliance vendor notes that this tier also covers the 24-hour notification duty. Lower tiers of €10 million or 2% and €5 million or 1% cover other obligations and incorrect or misleading information to authorities. Market surveillance authorities can also order a product withdrawn or recalled across the EU, separate from any fine. As always, treat vendor commentary as a starting point and check the regulation text with counsel.

Why This Matters for Agentic AI Teams

The CRA does not mention “AI agents” as a special category, and nothing here should be read as a claim that it does. But the way agentic software is built and operated makes the reporting rules unusually relevant.

Agents widen the “severe incident” surface

A product that takes autonomous actions, calls tools, and holds credentials has more ways to suffer a severe incident than a static application. We have covered how undetected agent swarms expose governance gaps and how coding agents can leak credentials through skill marketplaces. Under the CRA, an incident like that in a product you sell into the EU may not just be an engineering problem. It may start a 24-hour reporting clock.

You cannot report what you cannot see

Article 14 assumes you will notice exploitation. If your agents run without meaningful logging, you may not “become aware” until long after harm is done. That is why action-layer governance is shifting from a nice-to-have to a prerequisite: auditable records of what agents did, with which permissions, are what let you make a credible 24-hour assessment.

Privacy and security clocks can overlap

An agent incident can also be a personal-data breach. Teams already navigating regimes like GDPR, as we explored in what Spain’s AEPD “Rule of 2” means for companies running agents, now face parallel notification duties to different authorities with different deadlines. Law firms advise accounting for overlap with reporting requirements under other EU digital regulations.

A Practical Readiness Checklist

You do not need to boil the ocean. Start here:

1. Confirm scope. Decide which of your products are “products with digital elements” sold in the EU, including older versions still in customers’ hands.
2. Assign an owner. Name one person or team accountable for the 24-hour decision, with a deputy and out-of-hours coverage. The clock does not pause for weekends.
3. Build the triage playbook. Define what counts as “reasonable certainty,” who makes that call, and how the initial assessment is documented.
4. Maintain a living software bill of materials. Know which third-party components, models, and agent frameworks ship in each product, and whether vulnerable code is reachable.
5. Instrument your agents. Log tool calls, permission grants, and credential use so you can detect and scope incidents quickly.
6. Prepare templates. Draft the early warning, 72-hour notification, and user communication in advance, and rehearse with a tabletop exercise.
7. Identify your coordinating CSIRT. It follows your main EU establishment, or your authorised representative’s if you have none.
8. Check supplier contracts. Make sure upstream vendors must tell you quickly about exploitation affecting components you ship.

Conclusion

The CRA’s reporting regime is a reminder that regulators now expect software makers to know when their products are under attack, and to say so quickly. For teams building agentic and AI-enabled products, the lesson is practical: observability, dependency visibility, and a rehearsed escalation path are no longer just good engineering. They are how you meet a legal deadline measured in hours.

The actionable takeaways: confirm which products are in scope today, name an accountable owner, instrument your agents for detection, and rehearse a 24-hour report before you need one. Teams that do this work now will handle their first incident calmly; those that do not will be improvising under a regulatory clock.

Frequently Asked Questions

When did the CRA reporting obligations start?

Article 14 reporting obligations applied from 11 September 2026. The regulation’s general requirements follow later, on 11 December 2027.

Does every software bug have to be reported?

No. Only actively exploited vulnerabilities and severe incidents affecting product security trigger reporting. Ordinary bugs and routine patches follow normal vulnerability handling.

What are the reporting deadlines?

An early warning is due within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix being available (vulnerabilities) or one month after the 72-hour notification (severe incidents).

Does the CRA apply to products I sold before 2026?

Yes for reporting. Article 14 reporting applies to in-scope products placed on the market before December 2027, even if they are never substantially modified, and it continues after support ends.

Who do I report to?

Reports go through the ENISA Single Reporting Platform to ENISA and the national CSIRT designated as coordinator, which follows your main EU establishment.

What are the penalties for failing to report?

Article 64 allows fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of Articles 13 and 14. Confirm specifics with legal counsel.

Sources

• CRA Reporting Obligations (Article 14) - Independent Guide - deadlines, triggers, recipients, and product scope
• Browne Jacobson: Cyber Resilience Act reporting obligations in force - law-firm summary of the obligations and July 2026 Commission guidance
• Pearl Cohen: EU Cyber Reporting Obligations Take Effect on September 11 - deadlines and what must be reported
• Article 64 text via Better Regulation - official penalty provisions as reproduced
• Presencis: CRA Penalty Framework - penalty tiers and reporting-related fines
• Finite State: Cyber Resilience Act Fines and Penalties - vendor commentary on fines and product withdrawal