The Cyber Resilience Act’s New Reporting Obligations Are Active: What You Should Know

The European Cyber Resilience Act (CRA) has begun to come into effect, requiring that organizations in scope for the CRA report exploited vulnerabilities and severe security incidents within 24 hours. Do you know if this applies to your organization? Are you prepared to meet the new guidelines?

Scope

Cybersecurity crimes split into two categories: cyber-dependent crimes, where the computer or the hardware itself is the target, and cyber-enabled crimes, where the digital infrastructure is used to reach something else – stolen data, ransom, extortion. This split matters for compliance too: the CRA is a cyber-dependent law – it regulates the product itself. GDPR and NIS2 sit more on the cyber-enabled side – what happens once an attacker is already in. Knowing which side an incident falls on tells you which regulation, and which clock, just started running.

The EU Cyber Resilience Act (CRA) was passed in 2024, and has officially been in force since September 11, 2026; though not all of its provisions are yet active. The first phase of the CRA focuses on the reporting obligations under Article 14 and Annex II. The rest of the new requirements become enforceable on December 11, 2027, when the CRA applies in full: Article 13’s essential cybersecurity requirements for the product itself, and the Annex I vulnerability-handling obligations (SBOM, disclosure policy, security updates).

These additional requirements become legally binding rather than good practice, alongside the CE marking required to place a product on the EU market, starting in December 2027 date.

Timeline

• Actively Exploited Vulnerabilities (meaning there’s reliable evidence it’s already been used in a real attack, not just discovered): Requires an early warning within 24 hours, a detailed notification with mitigation steps within 72 hours, and a final report within 14 days of the correction.
• Severe Security Incidents (ask: did this affect, or could it have affected, the product’s ability to protect sensitive data or functions – or did it lead, or could it have led, to malicious code getting in?): Requires an early warning within 24 hours, a detailed notification within 72 hours, and a final report within 1 month of that notification.

Who does it affect

Manufacturers – organizations producing products with digital elements, whether or not the organization itself builds them, as long as they are marketed under its name or trademark. This applies regardless of where the company is based – what matters is that the product reaches the EU market.

Open source – the CRA splits this into three tiers. Purely volunteer, non-commercial open-source projects are exempt entirely.

• Organizations that “steward” an open-source project used commercially – maintaining it, without selling it themselves, like a foundation – fall under a lighter regime (Article 24): a documented security policy and cooperation with authorities, plus some reporting obligations, but no fines for non-compliance.
• Open-source software that’s monetized, sold, or bundled into a commercial product carries the full manufacturer obligations, same as any other product – including reporting its actively exploited vulnerabilities under the CRA.

How the CRA fits alongside other regulations

The CRA doesn’t sit alone – it lands inside a set of obligations most security teams already manage:

1. NIS2 – almost the same clock (24 hours / 72 hours / 1 month), but reported to the national CSIRT, not through the CRA’s ENISA platform.
2. GDPR – a 72-hour breach notification to a data protection authority when personal data is involved. A single incident can trigger both, on two different clocks.
3. DORA – overlapping ICT incident-reporting duties for financial-sector products.
4. EU AI Act, NIST AI RMF, ISO 42001 – for products with AI components. All three assume the same starting point as the CRA: a documented, current inventory of what’s in the product.
5. Product Liability Directive (PLD, 2024/2853) – a different kind of exposure, in effect from December 9, 2026: not a regulator-facing duty but civil liability toward a person actually harmed when an attacker exploits a vulnerability – and the manufacturer doesn’t get a pass just because an attacker did the exploiting.

Practical takeaway: build one incident-response and asset-inventory process that can feed every regulator’s clock, instead of a separate workflow per regulation.

Steps organizations should consider

1. Know what you ship. A complete, continuously updated SBOM (and AI-BOM where relevant) of every component – open-source and third-party included – plus a public coordinated disclosure policy and reporting contact.
2. Detect exploitation, not just disclosure. A CVE match alone doesn’t tell you if it’s actively exploited. Continuous scanning tied to real exploitability is what tells you if the 24-hour clock has started.
3. Pre-build the reporting workflow. Decide in advance who confirms an active exploit, who signs off, and where it gets reported (ENISA, your CSIRT, your DPA) – and log every decision as you go.
4. Build remediation speed into the pipeline. The 72-hour and 14-day deadlines depend on how fast you can patch and re-verify, not just detect.
5. Extend the same discipline upstream. Apply the same inventory and monitoring to your open-source and third-party suppliers.

Why SAST, SCA, and malicious package protection matter for both kinds of incidents

The CRA’s 24-hour clock assumes you can answer fast: is this actively exploited vulnerability present in something we ship? That question has two sides.

The cyber-dependent side – SAST helps prevent reportable issues from arising. It flags weaknesses in your own code before it ships, so the vulnerability never exists in a shipped product and never needs reporting at all. Checkmarx Next Gen SAST and Fusion post an F1 of 0.64 and 0.71 respectively (Checkmarx-reported), against an industry average of ~0.20. This is the difference between fixing real issues and chasing false alarms.

The cyber-enabled side – Software Composition Analysis (SCA) and malicious package protection. Most data-theft and ransomware incidents don’t start with your own code – they start with a component you imported, and there are two separate problems here.

The first is scale: roughly 77% of application code today is prebuilt open-source, a typical application carries ~1,180 open-source components, and about 95% of open-source vulnerabilities sit in transitive dependencies – several layers removed from anything a developer chose by name. That’s what SCA covers: knowing which of those components has a known CVE. So when an issue is disclosed, you can check in minutes whether it’s in your product.

The second problem is identifying malware (whether it’s been exploited or not) infections, for fast reaction and remediation and compliance. Checkmarx’s MPP is built for that side specifically — with over 500,000 malicious packages actively tracked and hundreds more discovered and added every month, backed by an audit-ready AI-BOM/SBOM.

The two halves do different jobs. SAST helps you avoid the clock altogether – fix it before it ships, and there’s nothing to report. SCA and malicious package protection help you answer fast when you can’t avoid it – a new CVE lands, and you need to know in minutes whether it’s in your product, not find out from an attacker. Between prevention and fast detection, that’s what makes the 24-hour obligation answerable at all.

Conclusion

the CRA doesn’t ask you to do anything you shouldn’t already be doing – know what’s in your product, catch what you can before it ships, and be ready to move fast on what you can’t prevent. The reporting deadlines are short and the fines for missing them are real. Whether you’re ready depends on work that has to happen before the vulnerability does: an accurate inventory, findings you can trust, and a workflow that already knows where to send the report.

Disclaimer: The information on this blog is for general educational purposes only and does not constitute legal advice