Everything You Need To Know About the Cyber Resilience Act

By Rebecca Harper • 23 June 2026 • 10 min read

The European Union’s Cyber Resilience Act (CRA) is the first major regulation to treat cybersecurity as a product safety requirement rather than an organisational governance one.

While there are many regulations that focus on how organisations manage cyber risk internally, the CRA takes a different approach. It focuses on the products themselves. More specifically, whether the software, devices, platforms, and connected technologies entering the European market are secure by design, maintained appropriately, and supported throughout their lifecycle.

For years, cybersecurity has often been treated as a governance issue, an operational concern, or a technical challenge owned largely by security teams. The CRA signals something broader: cybersecurity is increasingly being treated as a product safety requirement and for organisations selling products into the EU market, the implications extend far beyond compliance.

What Is the Cyber Resilience Act?

At its core, the CRA is designed to improve the cybersecurity of products with digital elements.

In practical terms, if a product contains software, connects to a network, exchanges data digitally, or includes embedded connected technology, it is likely to fall within scope.

The regulation applies across the product lifecycle, introducing obligations around secure-by-design development, vulnerability management, security updates and patching, incident and vulnerability reporting, technical documentation and conformity assessments, and ongoing product security maintenance. It also introduces financial penalties and, perhaps more significantly, the possibility of products being restricted or removed from the market entirely if organisations fail to comply at a persistent and serious level.

The intention is to reduce the volume of insecure digital products entering the European market while creating a more consistent baseline for cybersecurity expectations across member states. Importantly, this is not guidance or a recommended framework. The CRA is a legally enforceable regulation.

Why the CRA Matters

One of the reasons the CRA has attracted so much attention is because it changes where accountability sits.

Historically, many cyber regulations have focused on organisational resilience: how businesses manage risk, respond to incidents, govern suppliers, and protect critical services. The CRA shifts attention to the security of the product itself.

In effect, the regulation treats cybersecurity more like traditional product safety. Just as manufacturers are expected to ensure physical products meet safety standards before entering the market, the CRA expects digital products to meet baseline cybersecurity requirements before they can be sold in the EU. That creates significant implications for product development teams, engineering functions, software providers, procurement leaders, and supply chains.

It also reinforces a wider market trend. Customers, regulators, insurers, and investors increasingly expect organisations to demonstrate not only that they can respond to cyber incidents, but that security has been embedded into products from the outset.

Who Does the CRA Apply To?

A common misconception is that the regulation only applies to organisations headquartered within the EU. In reality, the CRA applies to any organisation placing qualifying products onto the EU market, regardless of where the business itself is based. That means UK, US, and global organisations may all fall within scope if they sell products with digital elements into Europe.

The regulation is expected to impact a wide range of organisations, including:

Software vendors
SaaS and cloud providers
IoT manufacturers
Hardware manufacturers with embedded software
Industrial technology providers
Importers and distributors of digital products

Manufacturers carry the greatest responsibility under the regulation because they are accountable for ensuring compliance throughout the product lifecycle.

There are also categories of “critical products” that face enhanced scrutiny and more rigorous conformity assessment requirements because of the level of cyber risk associated with them.

What the CRA Requires

The operational impact of the CRA is where many organisations are likely to feel the greatest pressure. The regulation is not simply about creating documentation or updating policies. It requires organisations to demonstrate that security has been operationalised throughout the product lifecycle. That includes embedding secure-by-design principles into development processes, maintaining effective vulnerability management capabilities, issuing security updates appropriately, and maintaining technical evidence of compliance.

For many businesses, this will require stronger visibility across software components, dependencies, suppliers, and third-party risk. It will also place greater emphasis on mature vulnerability management processes and clearer escalation pathways between security, engineering, product, and compliance teams. In practice, some organisations may discover that the biggest challenge is not understanding the regulation itself, but operational readiness.

Incident Reporting Under The CRA and the ENISA Platform

One of the most operationally significant aspects of the CRA is the introduction of mandatory incident and vulnerability reporting obligations. Manufacturers will be required to report:

Actively exploited vulnerabilities
Severe incidents impacting the security of products with digital elements

Importantly, the reporting obligations are tied specifically to product security and exploitation of vulnerabilities. This makes the CRA distinct from broader breach notification requirements under regulations such as GDPR or NIS 2.

The timelines themselves are intentionally demanding. Under Article 14 of the CRA, organisations will be expected to submit:

An early warning notification within 24 hours of becoming aware of an actively exploited vulnerability or severe incident
A more detailed notification within 72 hours
A final report within one month

For many organisations, these reporting windows may prove difficult to achieve operationally, particularly where software supply chains are complex or visibility into dependencies is limited.

The regulation also introduces a centralised reporting structure linked to the European Union Agency for Cybersecurity (ENISA). ENISA is developing a Single Reporting Platform (SRP) designed to streamline reporting across member states. Rather than requiring businesses to separately notify multiple national authorities, the intention is to create a more unified reporting mechanism. The reporting flow currently published describes the expected process as follows:

A manufacturer identifies an exploited vulnerability or severe incident.
An initial notification is submitted through the ENISA reporting platform.
Relevant national authorities and Computer Security Incident Response Teams (CSIRTs) are informed.
Follow-up technical information and remediation details are then submitted through the same structure.

At the time of writing, the platform itself is still being developed, with the reporting obligations due to begin applying from September 2026.

Operationally, these obligations are likely to place greater pressure on:

Vulnerability monitoring
Internal escalation procedures
Software bill of materials (SBOM) visibility
Supplier oversight
Incident response coordination
Cross-functional communication between engineering, security, legal, and compliance teams

Key Dates Businesses Need To Know

There are two major dates organisations should already be preparing for.

From 11 September 2026, the CRA’s vulnerability and incident reporting obligations will begin to apply.

The wider compliance obligations take effect from 11 December 2027. By this point, products entering the EU market must meet the CRA’s cybersecurity requirements, maintain technical documentation, complete relevant conformity assessments, and satisfy associated CE marking obligations– the conformity-marking requirement, familiar from physical product safety, that confirms a product meets applicable EU regulatory standards before market entry.

Although those deadlines may appear distant, many organisations with complex supply chains or limited SBOM visibility are already discovering that operational preparation takes considerably longer than anticipated.

What Businesses Often Get Wrong About the CRA

One of the most common misunderstandings is the belief that the CRA is primarily an IoT regulation. While connected consumer devices are certainly within scope, the regulation applies much more broadly than many organisations initially assume. Enterprise software, cloud-connected platforms, industrial technologies, embedded software systems, and a wide range of connected products may all be impacted.

Another misconception is that the regulation only applies to organisations headquartered within the EU. In reality, the CRA applies to organisations placing products with digital elements onto the EU market regardless of where the business itself is based. UK and US organisations selling into Europe face the same obligations as EU-based providers.

There is also a tendency to underestimate how operational the regulation is. The CRA is not simply a documentation exercise or another policy-driven compliance framework. It requires organisations to demonstrate evidence of secure development practices, vulnerability handling processes, patch management capabilities, and ongoing product security maintenance.

This means the regulation is likely to impact:

Engineering and development teams
Product functions
DevOps and security operations
Procurement and supplier management
Legal and compliance teams
Executive leadership

Many organisations are also underestimating the amount of preparation time required. The biggest challenge is unlikely to be understanding the regulation itself. More often, the difficulty lies in operational readiness. Common gaps include:

Limited visibility into software components and dependencies
Incomplete SBOM management
Weak supplier security oversight
Fragmented vulnerability management processes
Immature escalation and reporting procedures
Difficulty evidencing secure-by-design development practices

Finally, many businesses initially focus on the financial penalties associated with the regulation while overlooking the wider commercial implications. Authorities may restrict sales, require remediation actions, force recalls, or remove non-compliant products from the EU market altogether. For many organisations, continued access to the European market may ultimately become the strongest driver for CRA compliance.

The Penalties for Non-Compliance

The financial penalties under the CRA are substantial. For the most serious violations, organisations may face fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. These penalties may apply where organisations fail to meet cybersecurity requirements, neglect reporting obligations, or place non-compliant products onto the market.

Additional penalties may apply where organisations provide inaccurate or misleading information to regulators.

However, the financial penalties alone do not fully capture the business risk associated with the regulation. The potential impact on market access, customer trust, procurement eligibility, and supplier relationships may prove even more commercially significant.

Preparing for the CRA: Where To Start

For many organisations, preparation will require more than reviewing policies or updating compliance documentation. The regulation will likely force businesses to examine how security is embedded across product design, development, maintenance, supplier oversight, and incident response.

For many organisations the best place to start is scope: understanding which products fall within the regulation and which don’t. From there preparation can follow a logical sequence:

Foundation: establish visibility. Most organisations find that the biggest early gap is not process maturity but basic visibility, specifically, the ability to map software components and dependencies through a maintained software bill of materials (SBOM). Without this, vulnerability management and supplier oversight have no reliable foundation to build on.

Process: harden vulnerability and incident response. With visibility established, organisations can assess the maturity of their vulnerability management processes, their ability to meet the CRA’s aggressive reporting timelines, and the effectiveness of escalation pathways between engineering, security, and compliance functions.

Assurance: evidence secure-by-design practices. The final layer is evidencing that security has been embedded into the development lifecycle itself, not retrofitted after the fact. This is typically where organisations with mature governance frameworks, such as ISO 27001, find themselves better positioned: the controls infrastructure already exists; it needs to be extended and pointed at product security.

This is also why many businesses are increasingly aligning existing governance and security frameworks with emerging product security requirements. Frameworks alone will not guarantee compliance, but organisations with mature governance, risk management, supplier oversight, and incident response capabilities are likely to be in a stronger position as CRA obligations take effect.

The Direction of Travel

The Cyber Resilience Act represents a significant evolution in cybersecurity regulation. Rather than focusing solely on organisational governance or resilience, the CRA places cybersecurity expectations directly onto digital products themselves. For organisations selling into the European market, this is likely to become not only a compliance issue, but a product strategy, operational resilience, and commercial trust issue as well.

The organisations best positioned to respond successfully will likely be those that move beyond viewing the CRA as a last-minute compliance exercise and instead treat it as part of a broader shift towards secure-by-design operations, stronger resilience, and greater product accountability.

Ultimately, the CRA reflects a wider reality facing modern businesses: cybersecurity is no longer simply an IT responsibility. It is increasingly becoming a core expectation of product quality, customer trust, and market access.