The EU Cyber Resilience Act: What You Actually Need to Know

Cybersecurity moves quickly. New threats, technologies, regulations and industry standards seem to arrive almost every week. Whether you're just starting out or you've spent twenty years working in the industry, keeping up with everything isn't always straightforward.

And nobody can be an expert in everything.

Sometimes, amid all the technical language, regulatory documents and endless acronyms, it's worth stripping things back and asking a fairly simple question: what does this actually mean?

That's what we're here for.

Take the European Union's Cyber Resilience Act, or CRA. You may have heard about it, read the headlines or sat through a presentation explaining why your organisation needs to prepare. But what is it actually asking businesses to do? Does it affect software developers? What about open-source projects? And why should anyone outside Europe care?

The short answer is that the EU wants manufacturers to take greater responsibility for the cybersecurity of the digital products they put on the market.

That includes everything from smart doorbells and baby monitors to commercial software and industrial equipment. Rather than leaving security entirely to the people buying and using these products, the CRA introduces requirements for how they are designed, maintained and supported.

And as of September 2026, some of those requirements have already started to apply.

The legislation entered into force on 10 December 2024, but its implementation is staggered. On 11 September 2026, mandatory reporting requirements began applying to manufacturers of covered digital products. The main product-security obligations will follow on 11 December 2027.^1,2

Those dates matter because the CRA is not simply another regulation that businesses can put aside until the end of next year. Some companies already have legal responsibilities under it.

The most immediate change concerns reporting. Manufacturers must notify authorities when they become aware of an actively exploited vulnerability in a covered product or a severe incident affecting its security.

An early warning must generally be submitted within 24 hours, followed by a more detailed notification within 72 hours. A final report is then due no later than 14 days after a fix is available for an actively exploited vulnerability, or within a month of the 72-hour notification for a severe incident.³

That doesn't mean every bug discovered by a developer needs to be reported to Brussels within a day. The requirements concern specific categories of vulnerabilities and incidents, including vulnerabilities for which there is reliable evidence of malicious exploitation.

For cybersecurity teams, the distinction is important. Discovering a vulnerability during routine testing is not necessarily the same as discovering that somebody is actively exploiting it.

The EU has also introduced a centralised reporting mechanism. The European Union Agency for Cybersecurity, better known as ENISA, launched its Single Reporting Platform on 11 September 2026. Manufacturers report once: the notification goes to the national CSIRT where the manufacturer is based, ENISA receives it at the same time, and that CSIRT shares it with its counterparts in the countries where the product is sold.⁴

But reporting is only the beginning.

When the main requirements become applicable in December 2027, manufacturers will be expected to demonstrate that cybersecurity has been considered throughout the design, development and maintenance of their products.

In practice, that means identifying and assessing cybersecurity risks, addressing known vulnerabilities, maintaining processes for security updates and providing customers with clearer information about the security support they can expect.

Think about a connected device that receives software updates for a few years before its manufacturer quietly stops supporting it.

For consumers, that can leave a perfectly functional product exposed to newly discovered vulnerabilities. For businesses, it can create security risks that are difficult to manage, particularly when devices remain in use long after their original purchase.

Under the CRA, manufacturers will generally need to establish a defined security support period and communicate when that support will end. The legislation sets requirements for determining that period, including a general minimum of five years, subject to exceptions where a product's expected use is shorter.¹

The principle is straightforward: security should not become an afterthought once a product has been sold.

The Act also introduces conformity assessment requirements. Depending on the product and its classification, manufacturers may need to demonstrate compliance through internal assessment procedures or involve an independent conformity assessment body.

The familiar CE marking will form part of this system, indicating that a product meets the applicable EU requirements. It is not a guarantee that a device or application can never be hacked, but it creates a regulatory framework for holding manufacturers accountable.

And the consequences of non-compliance can be substantial.

For certain breaches of the CRA's essential cybersecurity requirements, national authorities may impose administrative fines of up to €15 million or 2.5% of a company's total worldwide annual turnover, whichever is higher.¹ Different limits apply to other categories of infringement, and the legislation includes specific provisions for smaller organisations.

So who actually needs to pay attention?

The obvious answer is manufacturers of connected devices and companies developing commercial software. But the implications extend further.

Software vendors, hardware manufacturers, importers and distributors can all have responsibilities depending on their roles. Cybersecurity consultants may find themselves helping clients assess compliance, while security teams will increasingly need to connect technical vulnerability management with regulatory reporting.

And this is not exclusively a European concern.

The CRA applies to covered products made available on the EU market. A manufacturer based in Britain, the United States or elsewhere may therefore need to comply if it wants to sell those products in Europe.

For international technology companies, that makes the CRA a commercial consideration as much as a regulatory one.

A company may develop its software in California, manufacture hardware in Asia and sell its products across Europe. The fact that its headquarters are outside the EU does not automatically place those products beyond the legislation's reach.

There are, however, important exceptions and distinctions.

The Act does not cover every digital service or every piece of software in exactly the same way. Certain products already regulated under other sector-specific frameworks are excluded or subject to different arrangements. The precise obligations depend on what the product is, how it is supplied and the role of the organisation involved.

Open-source software is another area that deserves attention.

Much of the modern technology industry depends on software maintained by individuals and communities who may never charge anybody for using it. Applying commercial manufacturer obligations indiscriminately to those contributors would create obvious difficulties.

The CRA recognises this distinction.

Ordinary open-source software developed and shared outside commercial activity is generally not treated in the same way as a commercial product placed on the market. The legislation also establishes specific provisions for certain organisations described as open-source software stewards, which support the development and sustainability of open-source projects.

Those stewards have a lighter set of obligations than commercial manufacturers, including a cybersecurity policy and reporting duties that begin in December 2027, and they are not subject to administrative fines under the Act.^3,5

That does not mean businesses can simply label a commercial product open source and assume the CRA no longer applies. The circumstances in which software is developed, supplied and commercialised still matter.

For organisations that rely heavily on third-party libraries and open-source components, the legislation also reinforces the importance of understanding what is inside their products.

Software supply chains are complicated. A single application can depend on hundreds of components, each with its own maintainers, dependencies and potential vulnerabilities.

Manufacturers will need appropriate processes for identifying and handling vulnerabilities affecting their products, including those originating in third-party components. The CRA also introduces requirements concerning the documentation of product components, including a software bill of materials.

That is likely to make software supply-chain visibility an increasingly important part of compliance preparation.

Of course, none of this happens in isolation.

Cybersecurity professionals already work with vulnerability management programmes, secure development practices, incident response procedures and recognised security standards. For some organisations, the CRA will formalise activities they have been carrying out for years.

For others, particularly smaller manufacturers and software businesses without dedicated security teams, the requirements may involve more substantial changes.

There is also a legitimate question about the cost of compliance.

Security assessments, documentation, vulnerability management and conformity procedures all require time and resources. Larger technology companies may already have the infrastructure to absorb much of that work, while smaller businesses may find it more challenging.

The EU's intention is to establish a common level of product security across the market. Whether the regulatory framework achieves that without creating disproportionate burdens will become clearer as the wider requirements take effect.

For now, businesses should be asking some practical questions.

Do we manufacture, develop, import or distribute products covered by the CRA? Do we know which vulnerabilities would trigger mandatory reporting? Can our teams identify and escalate those incidents quickly enough to meet the deadlines? And are we documenting the security of our products throughout their expected lifetime?

These are not questions solely for legal departments.

A CISO may need to oversee the organisation's approach, but developers, product managers, security engineers, incident responders and senior business leaders will all have a part to play.

The CRA also changes the conversation between technology suppliers and their customers.

Businesses purchasing software and connected devices will increasingly be able to ask more specific questions about security support, vulnerability handling and regulatory conformity. Manufacturers, meanwhile, will need to demonstrate that cybersecurity has been considered before a product reaches the market, rather than simply responding when something goes wrong.

It is worth keeping expectations realistic.

The Cyber Resilience Act will not eliminate software vulnerabilities, prevent every cyberattack or make every connected device secure. No regulation can guarantee that.

But it does represent a significant change in where responsibility sits.

For years, the cybersecurity industry has encouraged organisations and individuals to protect themselves through updates, secure configurations, awareness training and sensible purchasing decisions. Those responsibilities remain.

The CRA adds another layer: the companies creating digital products must meet defined cybersecurity requirements and take responsibility for managing vulnerabilities over the products' support periods.

And that is the part worth understanding, whether you're a junior security analyst, an experienced penetration tester, a software developer or somebody responsible for running a technology business.

The important dates are already upon us. Mandatory reporting began in September 2026, and the wider product-security requirements arrive in December 2027.

The technical and legal details will continue to evolve as guidance, standards and conformity assessment arrangements develop. Organisations will need to follow those developments and seek specialist advice where necessary.

But the central idea is not especially complicated.

If you're putting digital technology on the European market, cybersecurity is increasingly something you must build into the product, maintain throughout its supported life and be prepared to demonstrate.

For an industry that has spent decades reminding people to install their security updates, perhaps the most interesting change is that the people making the products are now facing clearer obligations of their own.