Organizations across the UK and EU are facing a deluge of new cybersecurity laws and regulations that they must adhere to.

The latest of these rules, which has come into effect as of September 11, is the EU Cyber Resilience Act (CRA)’s Article 14 reporting obligations, which presents a significant challenge for any business selling software or connected devices in the EU.

The CRA, which was passed into law in October 2024, will introduce security obligations throughout a product’s entire lifecycle. The new reporting requirements are part of a staggered roll out of the CRA provisions, which will fully come into effect by December 2027.

With non-compliance with the CRA carrying fines of up to €15m ($17.4m) or 2.5% of global annual turnover, whichever is higher, compliance with the new reporting rules cannot be taken lightly.

Organizations, including those in other jurisdictions that sell digital products into the EU, now have a short timeframe within which they must report exploited vulnerabilities or “severe” incidents relating to their products.

Within just 24 hours of becoming aware of a qualifying event, organizations covered by the CRA must submit an initial alert to the European Union Agency for Cybersecurity’s (ENISA) Single Reporting Platform (SRP). Within 72 hours, a more detailed update must be submitted that contains general technical details, risk assessments and early mitigation steps. Under Article 14, this submission must run in parallel with direct, clear notifications to affected users.

A final post-remediation report must be submitted within 14 days after a patch or corrective workaround becomes available for users in the case of actively exploited vulnerabilities. For severe incidents, the deadline is within one month of the 72-hour notification.

The rules are the EU’s latest effort to pursue its objective of making digital products secure by design.

Infosecurity spoke with cybersecurity and legal experts to explore how organizations should prepare for the new reporting requirements and the best practice approaches to ensure they can comply.

CRA Reporting Readiness Gaps Expose Organizations to Compliance Risks

There are significant concerns regarding organizations preparedness to comply with the CRA reporting obligations.

In June 2026, open-source industry association OpenSSF reported that 66% of global manufacturers, developers and others were “not familiar at all” or “only slightly familiar” with the CRA – rising to 72% in the US and Canada.

Sarah Pearce, partner at law firm K&L Gates, told Infosecurity that while she has observed a significant improvement in awareness of the rules over the past six months, preparedness is much more uneven.

“Larger multinational organizations with mature cybersecurity programs have generally recognized the significance of the September 2026 milestone and have been incorporating CRA requirements into their wider product security and incident response frameworks. However, from what I’ve seen, many companies still view the CRA primarily as a December 2027 product compliance exercise and have not fully appreciated that the legally binding reporting obligations kick in much sooner and require operational readiness,” she warned.

The new reporting requirements are likely to expose unprepared organizations more quickly than many other cybersecurity obligations do, as severe incidents or vulnerability exploits often quickly become apparent.

Brian Honan, CEO at BH Consulting, told Infosecurity that the reporting rules will expose the gap between those who have processes in place to comply and those who have not.

“You cannot report vulnerabilities or incidents effectively if you have not already established who is responsible, how issues are identified and escalated, and what information you need to collect,” he noted.

Ensuring compliance will be daunting prospect for those organizations that have not already undertaken the necessary preparation work, for a number of reasons.

Firstly, the ability to establish whether an incident or vulnerability needs to be reported can be a complex task in itself.

“Companies will be expected to make assessments as to whether a vulnerability is being ‘actively exploited’ or whether an incident meets the threshold of a ‘severe incident’ under considerable time pressure and it may not always be straightforward,” Pearce commented.

Ensuring there are clear processes, stages and accountability for enabling quick incident reports also requires significant pre-planning.

James Blake, VP of global cyber resiliency strategy, response & consulting services at Cohesity, noted: “Who makes the first call at 3.00am on a weekend when an incident occurs? Which reporting deadlines and rules apply? And who drafts and approves the first notification? In my experience advising organizations on cyber response, these seemingly small decisions can become major pitfalls.” 

A key capability that software manufacturers will need is the ability to identify, document, assess, remediate and disclose vulnerabilities throughout the entire supported lifecycle.

The development of sophisticated AI vulnerability discovery tools has led a surging volume of disclosed vulnerabilities, which attackers are exploiting at a rapid rate, making this process a huge challenge today.

Read more: How Industry Coalitions Are Rallying to Secure Open Source Software for the AI Era

Michael Woolslayer, policy counsel at HackerOne, commented: “The best way to avoid triggering the CRA's reporting requirements is to find and fix vulnerabilities before they're actively exploited. That makes fast, proactive vulnerability discovery and remediation more important than ever.”

Another challenge for many organizations that come under the scope of the CRA is that they will also be subject to multiple cyber incident reporting regimes that fall under other EU legislation including NIS2, the Digital Operational Resilience Act (DORA) and the General Data Protection Regulation (GDPR). Compliance with these various rules can mean organizations have to report incidents to different authorities within different timeframes.

“While the CRA creates a dedicated reporting channel through ENISA's Single Reporting Platform, companies will still need robust governance processes capable of identifying which regulatory regimes are triggered by the same event and ensuring that notifications are consistent,” Pearce added.

Avoiding a Tick-Box Approach to CRA Article 14 Compliance

It is important that relevant organizations do not take a tick-box approach to compliance with Article 14, and rather use it as an opportunity to enhance security across the whole enterprise.

Iain Davidson, head of product marketing at Wireless Logic, said that organizations must look beyond basic product compliance and ask how they would actually detect a breach across the wider system.

“Real resilience requires continuous visibility across connected assets, tight credential control, network segmentation and clear, multi-vendor incident response plans,” he said.

Organizations should certainly endeavor to avoid falling into the trap of focusing on their reporting processes at the expense of prevention and recovery.

Blake commented: “Reporting must also not happen at the expense of recovery. Every hour spent satisfying the clock is an hour taken away from restoring the business, so clear roles and separate reporting ownership are essential to keeping recovery on track.”

Honan advised businesses pursuing compliance with Article 14 to initially assess their own vulnerability management and incident response processes and address any inadequacies. After that, security teams should ensure they undertake an inventory the products that are in scope of the regulation, and create clear escalation processes, including establishing ownership and accountability for such tasks.

“Once you have those completed, you can then do a gap analysis of what you have in place against the requirements of the CRA and based on that analysis look at ways to address those gaps,” Honan said.

Finally, organizations should test their new processes to ensure they comply with CRA reporting timeframes, Honan added.

The plan of action must be clearly demonstrated and understood by all relevant stakeholders, covering departments like security, engineering and legal, according to Pearce.

“In my view, the companies that are likely to face the greatest scrutiny are not necessarily those that suffer incidents, but those that cannot demonstrate a credible framework for identifying and reporting them within the required timeframes,” she said.

EU’s CRA Shifts Security Burden from End Users to Manufacturers

The new reporting regulations – and indeed the CRA as a whole – have been received positively among many industry experts, as it signifies a shift in the security burden from the end users to manufacturers, who are normally best placed to build security into their software products.

“For far too long we have accepted software being released with security weaknesses which results in customers to deal with the consequences with little or no accountability on the vendor. Indeed, many vendors use clauses in their End User Licensing Agreement (EULA) to absolve themselves from any responsibility,” Honan commented.

“The CRA changes that equation by making cybersecurity part of the lifecycle of a product rather than an optional extra and places a lot more accountability for security on the vendor,” he added.

While making software manufacturers more accountable for their security of their products is a welcome development, it is important to not shift the burden completely on their shoulders, in what is a complex ecosystem containing multiple players.

Wireless Logic’s Davidson warned: “Manufacturers can secure a device against its intended and reasonably foreseeable use but they cannot secure a deployment architecture they did not design or operate. For industries like IoT, the entity assembling devices, connectivity, cloud platforms, applications and operational processes into a service may in fact have substantially greater control over – and visibility of – the resulting systemic cyber risk than equipment manufacturers.”  

Beyond Compliance: Making CRA Reporting Part of a Secure-by-Design Culture

The CRA reporting requirements represent just one component of a rapidly changing cybersecurity legal framework in the EU, with one of the key goals of legislators being to ensure those who are best placed to deploy secure by design measures – such as software manufacturers – are actually doing so.

The speed at which cybersecurity incidents and vulnerability exploits must be reported will be an onerous task for many organizations, but one that can be achieved with the right planning, processes and testing in place.

It should be part of an overarching security strategy that aims to make software products safer throughout their lifecycles, not merely to avoid punishment for non-compliance.

Legal obligations in areas such as fast and transparent disclosure of security issues needs to become culturally normalized among software manufacturers, and something that is expected or even demanded by customers.