A practical readiness guide for security and product leaders shipping into the EU.
On September 11, 2026, the EU Cyber Resilience Act’s vulnerability and incident reporting obligations will go into effect. From that date, any manufacturer of a product with digital elements sold into the EU must:
- Submit an early warning to ENISA and the relevant CSIRT within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
- Submit a full notification within 72 hours.
- Submit a final report within 14 days of a corrective measure (or one month for severe incidents).
This is the first CRA obligation with operational teeth, with maximum fines up to €15 million or 2.5% of global turnover (whichever is higher) for serious breaches.
This is not a documentation problem. It’s a detection-to-disclosure workflow problem, and the ones who succeed will have practiced it before September.
Why September 2026, not December 2027, is the deadline that matters now
Most CRA preparation conversations centre on the 11 December 2027 full-compliance date: CE marking, conformity assessment, and technical file. That’s the date legal teams have been planning around since the regulation entered into force on 10 December 2024.
September 2026 is sharper for three reasons.
It’s first, and it’s close. A few months from now, your security team needs to be operating a workflow that’s likely new to them and unpracticed.
It applies to legacy products too. The reporting obligation isn’t gated on whether the product was placed on the market before or after full application. If you have a product with digital elements available in the EU on 11 September 2026 and an actively exploited vulnerability surfaces, you must report it.
It’s where the first fines will come from. Conformity assessment failures get spotted in audits. A missed 24-hour notification gets spotted by ENISA in real time when a CSIRT in another country files first. The regulators don’t need a year of preparation to enforce this one.
The honest readiness question for most organisations is not “will we be CE-marked by December 2027?” It’s “if a critical CVE in our product gets exploited next October, can we file the early warning to ENISA in 24 hours, with the right detail, through the right platform, signed by the right person?”
Now is the time to act.
What the EU CRA reporting obligation requires
The mechanics, per Article 14 of Regulation (EU) 2024/2847 and the official European Commission guidance:
| Stage | Deadline | What’s required |
| Early warning | Within 24 hours of awareness | Notify the relevant CSIRT and ENISA via the Single Reporting Platform that an actively exploited vulnerability or severe incident has occurred. Available technical details at this point. |
| Full notification | Within 72 hours of awareness | More complete technical information, scope of impact, products affected, and any mitigation guidance available. |
| Final report — vulnerabilities | Within 14 days of a corrective measure becoming available | Full root cause, remediation, affected versions, and customer guidance. |
| Final report — severe incidents | Within 1 month | Equivalent close-out for incidents rather than vulnerabilities. |
Three operational details most teams miss:
“Awareness” starts the clock, not “confirmation.” The 24-hour timer begins when the manufacturer becomes aware. That’s a deliberately low bar, designed to surface emerging exploitation early. If your security team gets a credible signal on Friday at 6 PM, the clock is running over the weekend.
This is for actively exploited vulnerabilities – not every CVE in your product. The trigger is evidence of exploitation in the wild or a severe incident affecting product security. The judgment call about whether a signal qualifies has to be made fast, by someone authorised to make it.
One filing, one platform. Manufacturers report once via ENISA’s CRA Single Reporting Platform (SRP). The receiving CSIRT then disseminates to the rest of the CSIRT network. You do not file 27 times.
The four gaps many organizations need to fill
Across the conversations we’re having with security and product leaders preparing for September 2026, the same four readiness gaps come up.
Gap 1 — No designated reporter, no escalation path. Who actually files the notification? Who’s the backup when they’re on vacation? Who has the authority to decide that a signal qualifies as “actively exploited”? In most organisations, the answer is “we’d figure it out.” That’s the answer that produces a missed deadline.
Gap 2 — No detection-to-disclosure timeline you’ve actually measured. The mean time to detect an actively exploited vulnerability in your own product is not the same as MTTR on a SIEM alert. It depends on customer disclosure channels, threat intelligence ingestion, and how fast a triage call can convene. Most teams have never measured the full path. Many discover, when they try to, that 24 hours is not realistic with their current setup.
Gap 3 — No clean inventory of which products are in scope. The reporting obligation applies per product placed on the EU market. If your portfolio has 40 products and you don’t know which are CRA-covered, which versions are still supported, which components they share, and which customers are EU-based, you can’t scope a notification under time pressure.
Gap 4 — No way to instrument the supply chain at the speed of the obligation. The vulnerability that triggers a notification might originate in your code, in a third-party dependency, in an open-source library, in a CI/CD compromise, in a leaked secret, or in AI-generated code your developers shipped last month. The faster you can correlate signals to products to customer impacts to fixes, the faster the early warning happens. Teams running fragmented scanners and disconnected ASPM dashboards lose hours to correlation.
A 4-month readiness plan to be operational by September 2026
Month 1 — Inventory and ownership. Map every product with digital elements you place on the EU market. Classify by current support status. Designate the reporter, the backup, and the decision-maker on “Does this signal qualify?” Document the on-call rotation. Get sign-off from legal and the executive owner.
Month 2 — Detection and correlation. Stand up continuous detection across first-party code, dependencies, secrets, IaC, containers, CI/CD, and AI components. The point isn’t more alerts. It’s the ability to pivot from “we just heard about active exploitation of CVE-X” to “here’s every product, version, and customer affected.” If you can’t do that today, that’s a key gap to fill.
Month 3 — Workflow and tabletop. Build the actual filing workflow: intake forms, decision gates, draft templates for the 24-hour and 72-hour notifications, sign-off chain, ENISA Single Reporting Platform credentials in place. Run a tabletop with a realistic scenario. Time it from the initial signal to the filed notification.
Month 4 — Drill, harden, repeat. Run a second tabletop with a harder scenario (Friday evening signal, ambiguous exploitation evidence, third-party dependency, multiple products affected). Fix what broke. Document the runbook so the on-call can execute without consulting six people.
How Cycode shortens the path to readiness
The CRA reporting obligation is, operationally, a software-supply-chain visibility problem with a regulatory clock attached. It rewards organisations that can correlate, prioritise, and act on actively exploited risk across their entire software factory in one workflow.
Cycode is built to do exactly that. For CRA reporting readiness specifically:
An out-of-the-box EU CRA compliance dashboard. Cycode ships a pre-built dashboard that maps platform findings, controls, and evidence to the CRA’s essential requirements and reporting obligations. When a signal lands, the dashboard surfaces every affected product, version, dependency, and remediation status in one view. The same platform also covers SOC 2, ISO 27001, NIST, SSDF, and CIS Benchmarks, so one program serves the regimes auditors and market surveillance authorities ask about.
Continuous detection across the full software supply chain. Next-Gen SCA with reachability and exploitability analysis. ML-powered Secrets Detection across repos, CI/CD, IaC, and productivity tools. Container Security correlated to root cause in code. Code Leak Detection across public platforms and the dark web. SAST with industry-leading precision. Risk Scoring that adapts to threat intelligence, business impact, and exposure. The signals you need to start the 24-hour clock are clearer when visibility is unified and context centralized.
Cycode Projects for product-to-asset mapping. Cycode Projects lets you mirror your real organisational structure inside the platform: business units, product lines, individual products, applications, and teams. Every repo, pipeline, dependency, container, and AI component is mapped to the product it belongs to, with ownership attached. When a signal lands at 6pm on a Friday, you don’t lose the first hour reconstructing which products are affected. The mapping is already there, integrates with your existing CMDB via API, and lets you scope “which versions, which customers, which CRA-covered products” in minutes.
One graph, full exposure context, full audit trail. Every asset, finding, decision, and remediation lives in the Context Intelligence Graph (CIG). The graph models exposure paths and blast radius natively: which downstream products inherit a vulnerable component, which customer-facing services are reachable from an exploited entry point, where ownership sits, and how risk propagates from commit to pipeline to artifact to runtime. That’s the data behind the “scope of impact” section of a 72-hour notification. Persistent decision traces sit alongside it, so when a market surveillance authority asks how you arrived at the determination that a signal qualified or didn’t, the answer is in the audit trail, not in a Slack thread someone has to reconstruct.
ADLC Security for AI risk in your products. The AI components in your shipped products are CRA-covered software. They need to be visible. AI Visibility auto-discovers shadow AI, coding assistants, and MCP servers. AI Governance enforces policy with full AIBOM coverage. AI Guardrails block risky patterns and prompt-leaking secrets in real time. AI Risk Detection scans application code for OWASP LLM Top 10 vulnerabilities.
Cycode Maestro for triage and remediation at AI speed. Maestro orchestrates exploitability confirmation, blast radius analysis, owner identification, and PR-ready fix generation. Cycode customers adopting AI remediation see 17× higher 90-day close rates for critical and high-severity findings, directly relevant to the CRA’s 14-day final-report clock. The AI Exploitability Agent answers the “Is this actually exploitable in our application context?” question that gates the qualify/don’t-qualify decision on a notification.
Five questions to ask your team this week
Use these as a self-assessment starting point for a CRA readiness conversation with your application security, product security, and legal stakeholders.
- Who files the 24-hour early warning to ENISA, and who is their backup? Names, on-call rotation, written down.
- From a credible exploitation signal, how long does it take us today to identify every product, version, and customer affected? If the answer is “we’d need to ask around,” that’s the gap.
- Have we run a timed tabletop on the full reporting workflow yet? End-to-end, signal to filed notification.
- Who has authority to decide that a signal qualifies as “actively exploited”? That decision is made under time pressure. It needs an owner.
- What’s our coverage of AI components in our shipped products? AI-generated code, AI features, MCP integrations. They’re CRA-covered software.
If two or more of these don’t have crisp answers, the gap to September is wider than the calendar suggests.
Accelerate your CRA reporting readiness
Cycode’s EU CRA dashboard maps your existing risk posture against the essential requirements and reporting obligations. We’ll walk through how Cycode helps determine what your readiness looks like today and fill the gaps ahead of the September deadline.
