The EU Cyber Resilience Act Starts Today: Can Businesses Really Report A Cyberattack In 24 Hours?

A new EU cybersecurity deadline has officially come into effect today, and at first glance, it sounds rather unforgiving: businesses have just 24 hours to report certain cyber incidents.

But it’s not quite as simple as that; there’s an important catch. The Cyber Resilience Act (CRA) isn’t simply introducing a blanket rule that every business have to report every single cyberattack within 24 hours. From 11 September, the first major CRA reporting obligations apply to manufacturers of products with digital elements, covering actively exploited vulnerabilities and severe incidents affecting product security. Importantly, most of the wider CRA requirements won’t apply until December 2027, so this is just the beginning.

But still, 24 hours is 24 hours. So, is this actually a realistic expectation?

 

The 24-Hour Clock Isn’t Quite What It Sounds Like

 

Under Article 14 of the act, manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident. A more detailed notification follows within 72 hours, and finally, the last report comes a little later, depending on the specific circumstances.

So, it’s really important to note the difference between these three deadlines, because, as several of our experts point out, nobody is realistically expected to solve an entire cyberattack before lunch tomorrow. It would be nice, but it’s not realistic.

Martin Riley, CTO at Bridewell, argues that the 24-hour warning is deliberately designed as an escalation rather than a completed investigation. The first notification is essentially an alarm bell: letting people know that something serious is happening, and alerting other organisations using the affected product that they may need to take precautions.

Jose Lejin PJ, Principal Member of Technical Staff at Salesforce, makes much the same point: “The 24-hour rule is workable if you read what the CRA actually requires. It is not ‘explain the whole cyberattack by tomorrow.’”

And that might be the most important part of properly understanding the rule. The EU isn’t necessarily asking businesses to know everything within a day; it’s asking them to know enough to raise the alarm.

 

 

What If You Don’t Know You’ve Been Hacked?

 

Of course, that makes things more complicated. Muhammad Yahya Patel, vCISO and Cybersecurity Advisor for EMEA at Huntress, says the requirement is “directionally right but operationally challenging”. In the first 24 hours of an incident, organisations may still be trying to understand what happened, contain the damage and preserve evidence.

Rob Demain, CEO of e2e-assure, similarly argues that the deadline is realistic primarily for organisations with mature detection capabilities. If you have continuous monitoring, you might know something is wrong within minutes, so it’s easier to follow these rules. Figuring out exactly what happened, however, can take a lot longer. It’s possible that this could expose some issues with cybersecurity maturity, and at the end of the day, that’s generally the point.

The biggest problem with a 24-hour reporting deadline may not be the reporting but rather how realistic the detection process is within that window. As Ali Waezzadah, CISO at iCOUNTER, puts it, “Manufacturers cannot report what they cannot detect.” If a company doesn’t know that a vulnerability is being actively exploited, the clock hasn’t really become its problem yet. The problem is that it might not even know the clock has started.

 

The Supply Chain Could Make This Even Harder

 

Modern software isn’t exactly a neat little box built entirely by one company. Products can contain proprietary code, open-source packages, third-party components and now, more often than not, AI models and services too.

Eran Kinsbruner of Checkmarx says manufacturers will need continuous visibility across their software supply chains so they understand which vulnerabilities affect their products. Ilkka Turunen, Field CTO at Sonatype, takes this further. He warns that organisations need to know which components are inside which products and which versions are affected before an incident occurs. Because trying to reconstruct that information manually during a crisis could make the 24-hour window “nearly impossible to meet”.

This is where the CRA could have an interesting unintended consequence. The regulation may effectively force companies to invest in software inventories, dependency tracking, monitoring and incident-response infrastructure earlier than they otherwise would have, which will most likely have really postive effects on overall cybersecurity.

 

So, Is 24 Hours Actually Realistic?

 

For a large manufacturer with strong monitoring, clear escalation procedures, incident-response expertise and a detailed understanding of its software and hardware stack, probably, yes. But, for a smaller company that discovers an exploit at 3am and starts asking who’s actually responsible for reporting it, the answer is more complicated.

Daryl Flack, Partner at Avella Security, describes 24 hours as “a pretty unforgiving window”, particularly because organisations need to establish whether an incident actually meets the reporting threshold and get the right technical and legal people involved.

And that may sound daunting at first, but it’s also precisely the point. The CRA is effectively asking companies, if you sell connected technology into the European market, how quickly could you actually tell the people who depend on it that something serious is wrong? How well can you understand the problems and how quickly can you deal with them?

So, perhaps it’s less about whether a company can fill in a form within 24 hours and more about how confident they are in how well they could potentially deal with a sudden issue, and this all comes down to proper planning. Indeed, it seems as if the regulation may have already identified a bigger cybersecurity problem, and perhaps this is the first step towards making things safer.

 

Experts Comment:

 

• Muhammad Yahya Patel: vCISO and Cybersecurity Advisor for EMEA at Huntress
• Rob Demain: CEO of e2e-assure
• Carl B. Johnson: President at Cleared Systems; Owner at ComputerSecurity.us
• Darren Williams: Founder and CEO at BlackFog
• Artem Serebrov: Director of Product at PCA Cyber Security
• Eran Kinsbruner: Vice President of Product Marketing at Checkmarx
• Martin Riley: Chief Technology Officer at Bridewell
• Camellia Chan: CEO and Co-founder of X-PHY
• Daryl Flack: Partner at Avella Security
• Ilkka Turunen: Field CTO at Sonatype
• Omair Manzoor: Founder, CEO and Chief Hacker at ioSENTRIX
• Jose Lejin PJ: Principal Member of Technical Staff at Salesforce
• Ali Waezzadah: CISO at iCOUNTER
• Shane Tierney: Senior Program Manager, GRC, Drata

 

Muhammad Yahya Patel, vCISO and Cybersecurity Advisor for EMEA at Huntress

 

 

“The 24-hour early warning requirement under the CRA is directionally right but operationally challenging in a way that deserves honest acknowledgment. The operational reality is more complicated, though. In the first 24 hours of a significant incident, most organisations are trying to understand the scope, stop the bleeding, and preserve evidence. The problem is that many organisations don’t yet have the detection and escalation maturity to know within 24 hours that they have something reportable, let alone the nature of what’s been accessed inside a complex environment.

“Reporting inaccurate information to regulators under mandatory timelines creates its own problems both for the organisation revising its initial assessment and for the regulator acting on incomplete intelligence. It’s important to mention, The CRA doesn’t ask businesses to report being attacked. It asks manufacturers to report when their products are being used as the attack vector.”

 

Rob Demain, CEO of e2e-assure

 

 

“It’s only realistic for businesses that already have mature detection in place. And a 24-hour deadline is only asking for it to be reported, not the full investigation. Organisations running continuous monitoring will usually know within minutes that they’ve been hit; what takes longer is establishing scope, root cause, and impact, and that work can carry on after the initial notification.

“Transparency in itself has merit, but “full” and “accurate” aren’t the same thing. A rushed report built on guesswork can misdirect response efforts and cause more harm than a short delay would. The right balance is early, honest signalling, i.e. “we’ve identified a significant incident and are investigating”, rather than a complete picture on day one.
The real test isn’t whether 24 hours is realistic but whether an organisation has invested in the visibility to detect an incident that fast at all.”

 

Carl B. Johnson, President at Cleared Systems; Owner at ComputerSecurity.us 

 

 

“The 24-hour reporting rule is realistic only for organisations that already have mature incident response, asset visibility, vulnerability management, and decision-making authority in place. For many businesses, the hardest part will not be writing the report. It will be knowing quickly enough what happened, whether the issue is reportable, who must be notified, and who inside the company has authority to make that call.

“The public deserves timely notice, but rushed reporting can also create confusion if facts are incomplete. The right balance is fast initial notification, followed by disciplined updates as the investigation develops.”

 

Darren Williams, Founder and CEO at BlackFog

 

 

”The 24-hour requirement is realistic, but only if we recognise what it is: an early warning, not a completed forensic investigation. The real challenge for many organisations is that they still lack visibility into what data has left the network, where it went, and whether an incident is still active. Attackers can exfiltrate sensitive information in minutes, so waiting days for perfect attribution creates unnecessary risk for customers and partners.

“The right balance is phased disclosure. Notify quickly with what is known, then provide deeper technical detail as the investigation develops. The CRA should force organisations to improve detection, data exfiltration monitoring and incident response readiness.
Companies that cannot establish the basic facts of an attack within 24 hours have a broader security problem than simply meeting a regulatory deadline.’’

 

Artem Serebrov, Director of Product at PCA Cyber Security

 

 

“New regulatory obligations on device manufacturers to report the active exploitation of vulnerabilities in their products are likely to collide with the reality of cyber security monitoring and its limits. Device manufacturers selling into the European market aren’t currently obliged by the EU to monitor how cyber criminals are targeting vulnerabilities in their products. It’s therefore no surprise that the majority of manufacturers lack sophisticated capabilities to pick up on vulnerability exploitation – particularly dark web monitoring, which is essential to track how vulnerability discovery and exploitation play out in cybercriminal forums.

“Overall, there are parallels to be drawn between the current state of the Cyber Resilience Act and the early days of GDPR rules. Similarly, under GDPR, obligations to report data leakage were introduced without obligations to measure data loss. This invited companies to softly limit the extent to which they were monitoring data loss in the interest of avoiding hefty GDPR-related fines. It will be interesting to see how EU policymakers react to avoid a similar state of affairs with Cyber Resilience Act reporting obligations in effect.”

 

Eran Kinsbruner, Vice President of Product Marketing at Checkmarx

 

 

“What all this means for manufacturers is that secure development, effective vulnerability handling, and traceability across the software supply chain should be elevated to the top of their priority list. They need to have processes in place to ensure continuous visibility across their software supply chain so they know which vulnerabilities will impact their product.

“Modern applications are assembled from a complex ecosystem of components, with combinations of proprietary code, open-source packages, third-party components and, increasingly, AI models and services all interconnected. Organisations need to understand these components, their dependencies and the risks they introduce. Reviewing your application security tools to ensure they continuously scan code and environments to find new vulnerabilities, automatically map the affected applications and environments, assess and prioritise risk and remediation, and log every action taken for auditable evidence, will be critical.”

 

Martin Riley, Chief Technology Officer at Bridewell

 

 

“There’s an important nuance in how this rollout is being framed. What takes effect [today] isn’t the whole EU Cyber Resilience Act coming into force. The Act’s broader obligations, conformity assessments, CE marking, secure-by-design requirements, don’t apply until December 2027. What starts [today] is a narrower and much sharper piece: Article 14’s requirement for manufacturers to report actively exploited vulnerabilities and severe incidents. It’s been brought forward by 15 months because regulators want early visibility into live exploitation before the rest of the regime is in place. That’s a deliberate sequencing choice, not an accident.

“The detail that gets lost in most coverage is when the clock actually starts. It isn’t triggered by a confirmed, fully investigated breach. It starts the moment a manufacturer becomes aware that a vulnerability is being actively exploited, or that a severe incident has occurred. That’s a much lower bar than people assume, and it’s deliberate. The 24-hour early warning was never meant to explain what happened. It’s meant to raise the alarm early enough that other organisations running the same product can start applying compensating controls before anyone has the full picture. Waiting for certainty defeats the purpose. At that stage, speed of warning matters more than completeness of warning.

“The structure reflects that thinking. There are three stages, not one. Within 24 hours, an early warning, essentially a flag that something serious is happening and where. Within 72 hours, a fuller notification covering what’s known about the product, the nature of the exploit, and any mitigations already available. Then a final report, within 14 days of a fix becoming available for a vulnerability, or within a month for a severe incident. Each stage adds detail as the investigation matures. None of them demand the full story on day one.

“So is it realistic? Yes, because it was never designed to be a full report in 24 hours. It’s a structured escalation, and the first step is deliberately lightweight. What it does demand is that organisations already have the internal capability to detect exploitation, escalate it, and notify a regulator within a day, before the root cause is even established. For a mature vendor with an established incident response function, that’s achievable. For smaller manufacturers or newer entrants without that function built out, it will be uncomfortable.

“That discomfort is probably a feature rather than a flaw. If a 24-hour early warning duty causes a vendor genuine pain, that’s a sign their detection and response capability wasn’t where it needed to be, regardless of the regulation. The Act is simply forcing that gap into the open earlier than the market would otherwise expose it.”

 

Jonathan Lee, Director of Cyber Strategy and UK Public Policy Lead at TrendAI

 

 

“The Cyber Resilience Act is often portrayed as a 24-hour cyberattack reporting rule, but its real focus is manufacturers reporting actively exploited vulnerabilities and severe incidents affecting products with digital elements. The clock starts ticking once there’s a reasonable degree of certainty that a serious issue exists, not once every fact is confirmed. An early warning is required at 24 hours, fuller details at 72, with final reporting to follow. That reflects the reality that understanding the full extent of an incident can take days or weeks.

“Transparency matters, but regulator notification isn’t the same as public disclosure. These reports go to ENISA and national CSIRTs, helping defenders act early while investigations continue. The real test isn’t whether organisations can file a report within 24 hours, it’s whether they can detect a severe incident within 24 hours. If they can’t, the deadline is the least of their problems.”

 

Camellia Chan, CEO and Co-founder of X-PHY

 

 

‘‘The CRA’s 24-hour initial reporting requirement puts direct pressure on manufacturers to ensure their internal processes are ready. The bigger challenge, however, is spotting an attack quickly enough to act.

“Vulnerability exploitation already accounts for more than one in five observed initial intrusions across the EU. Attackers are also increasingly targeting weaknesses deeper within devices and infrastructure, where conventional software monitoring can have less visibility. As AI speeds up the discovery and use of new flaws, identifying those threats becomes even harder.

“Reporting an incident quickly is crucial, but the clock doesn’t stop there. The sooner teams understand where an attack is happening, the sooner they can contain it and limit the impact on operations and user data. That means having security across the full technology stack, including at the hardware level.”

 

Daryl Flack, Partner at Avella Security 

 

 

“24 hours is a pretty unforgiving window. In those 24 hours, you need to identify the issue, establish whether you are dealing with an actively exploited vulnerability or a severe security incident, bring in the right technical and legal people and get the early-warning notification out the door. That’s no mean feat.

“It’s also important to remember this isn’t just an EU vendor issue. UK and US manufacturers selling relevant products into the EU are caught too, and it includes legacy products already in distribution, not simply whatever gets launched after 11 September.

“The interesting bit here is that this reporting clock starts well before many of the Cyber Resilience Act’s wider engineering obligations kick in. So, manufacturers could be reporting vulnerabilities in products they’re not yet formally required to “fix” under the full Cyber Resilience Act regime.

“That’s where this could get tricky. It could create some interesting tension between vendors and operators, particularly around what “actively exploited” actually means in practice and when everyone agrees that the 24-hour clock has actually started.”

 

Ilkka Turunen, Field CTO at Sonatype 

 

 

“The EU Cyber Resilience Act’s 24-hour reporting requirement exposes a basic problem for many organisations: they still don’t have a clear understanding of the software they ship. The average software supply chain is over 180 external components, and in 2025 Sonatype found nearly 1.8 billion downloads that had risks with fixes available but ignored. This shadow inventory is set to grow with the rise of AI development.

“The CRA makes every risk from every adopted component the concern of the organisation using it. When a vulnerability affecting any one adopted component is actively exploited, teams now have a 24-hour deadline to report it to ENISA and their local regulator.

“Teams need to know which products contain the affected components, which versions are exposed and inform both the regulator and their customers. If that picture has to be reconstructed manually during an incident, the reporting window will be nearly impossible to meet.

“The CRA will necessitate accurate, up-to-date software supply chain data before an incident happens. Organisations need to be able to trace components and dependencies as part of the development process, not for the first time under incident pressure.”

 

Omair Manzoor, Founder, CEO and Chief Hacker at ioSENTRIX 

 

 

“The 24-hour reporting requirement is well-intentioned but creates a tension between speed and accuracy that most organizations are not equipped to resolve. In our incident response work, determining the scope of a breach within 24 hours is possible for organizations with mature detection and forensic capabilities. For most businesses — particularly SMBs that the CRA now covers — 24 hours is barely enough time to confirm whether an incident actually occurred, let alone characterize it meaningfully.

“The realistic compromise is tiered reporting: an initial notification within 24 hours confirming a potentially exploitable vulnerability has been discovered, followed by a substantive technical report within 72 hours once forensic analysis provides actionable detail. Forcing detailed disclosure before the organization understands what happened risks publishing inaccurate information that misleads affected parties and potentially exposes attack details that help other threat actors.

“The organisations that will meet this requirement are those that invest in incident response preparedness before an incident occurs — pre-built response playbooks, retained forensic partners, and pre-drafted notification templates. The CRA effectively makes incident response planning mandatory, which is the right outcome even if the 24-hour timeline is aggressive.”

 

Jose Lejin PJ, Principal Member of Technical Staff at Salesforce

 

 

“The 24 hour rule is workable if you read what the CRA actually requires. It is not “explain the whole cyberattack by [today].”

“From 11 September, manufacturers of products with digital elements must send ENISA and the coordinating CSIRT an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident that affects product security. Awareness means a reasonable degree of certainty after an initial look, not the first odd log. A fuller notification is due in 72 hours. Users should be told so they can protect themselves. The rest of the CRA (secure by design, CE marking) still waits until December 2027.

“That staged split is the right balance. The public should not wait weeks. Firms also should not be forced to publish guesses that panic customers or help the attacker. Complete root cause in a day is not realistic. A short, factual early warning is. Teams that already know who declares awareness and what they will file can meet this. Teams that wait until the investigation feels finished will miss it.”

 

Ali Waezzadah, CISO at iCOUNTER

 

 

“The question states “report a cyberattack in 24 hours,” but the CRA’s rule is not a general “you got hacked, notify us in24 hours”. It covers manufacturers and focused on product security:

• An actively exploited vulnerability in a product
• A severe incident affecting the security of the product

“The “we suffered a cyberattack” reporting is under different rules. A company could suffer a terrible ransomware attack on its internal HR systems and have zero CRA reporting obligations, because it didn’t affect a product’s security. The real challenge is not the clock — it is detection and the definition of “aware”. Manufacturers cannot report what they cannot detect. The timer starts when the company becomes “aware.” When does the company become “aware”? A cautious compliance officer says the clock starts early, and a diligent engineer wants to finish the analysis.

“The requirement is achievable if the underlying capabilities exist, and difficult if it doesn’t. The vital question is “do manufacturers have the essential capabilities to know within 24 hours”? For most, that’s the honest gap. The regulation is essentially using a reporting deadline as a lever to force detection investment.

“For a well-resourced company that has built the underlying capabilities, while they still have some work to do, 24 hours is doable. For others, it won’t be about whether the form can be filed fast enough — it will be about whether they even know they have something to file.”

 

Shane Tierney, Senior Program Manager, GRC, Drata

 

 

“The broader CRA requirements become fully applicable on 11th December 2027, but the September milestone is a practical forcing function for in-scope organisations to formalise and rehearse vulnerability-handling and incident-reporting processes before an incident occurs.

Instead of treating it purely as a compliance checkbox, enterprises should use it as a prompt to strengthen operational discipline around vulnerability handling, reporting and risk management. This means having a clear record of the staged reporting process. Teams also need to know what must be disclosed, who to contact, and how to submit each report.

Where enterprises can really get ahead, though, is by turning these obligations into an operating program: defining product scope, assigning ownership, rehearsing vulnerability handling, maintaining the necessary evidence, and connecting testing and documentation to the other frameworks they already manage, such as SOC 2, ISO 27001, and GDPR, for example. An effective and efficient GRC team shouldn’t need to be building a parallel, manual process just for CRA or any other mandate.

This is where automation can help. Modern compliance platforms can help teams map CRA requirements to existing internal controls, organise supporting evidence, and connect relevant testing and monitoring across the frameworks they already manage. That readiness support complements, but does not replace, product-security, engineering, legal, conformity-assessment, or incident-reporting responsibilities.

The organisations that treat this deadline as an opportunity to consolidate and automate their compliance operations, instead of adding on another manual process, will be the ones who handle CRA, and whatever comes next, with less friction.”