The EU Cyber Resilience Act (CRA): A Complete Guide to Compliance

Almost every product sold today contains software of one kind or another, from the cars we drive and the cameras in our homes to the controllers that run factories and the applications on our phones. For many years, however, that software was built with remarkably little attention to security. Products were commonly shipped with default passwords, released without any means of updating them, and left to carry known weaknesses that were never corrected, and when those weaknesses were eventually exploited, it was almost always the user, rather than the company that had built the product, who bore the consequences.

The European Union has now decided that this situation cannot be allowed to continue. The Cyber Resilience Act, formally known as Regulation (EU) 2024/2847, is a new law that establishes a common cybersecurity standard for connected and software-based products. Cybersecurity requirements did exist before its arrival, but they were scattered across a patchwork of industry-specific rules that reached only certain parts of the market. The CRA draws those threads together into a single framework and, for the first time at European Union level, makes compliance with a cybersecurity baseline a condition of selling a broad range of products within the Union.

The scope of the law is deliberately wide, and its effect is felt well beyond Europe's own borders. Any manufacturer that places a product on the EU market falls within its reach, regardless of where that manufacturer happens to be based, provided the product connects to a device or a network in the course of its normal use. In the sections that follow, this guide sets out what the CRA requires, who is obliged to comply, how a new family of standards known as the EN 40000 series translates the law into practical engineering, how the handling of vulnerabilities works in day-to-day terms, and the deadlines around which organisations will need to plan.

Why the CRA Exists

To understand the law, it helps to begin with the problem that it was designed to solve, because two distinct failures in the market lay behind it.

The first was that insecure products had become one of the easiest routes into a network, and yet the manufacturers responsible for them rarely felt any consequence. When a poorly protected device was drawn into a botnet or used as a stepping stone into a corporate system, the resulting cost fell on the victim rather than on the manufacturer whose shortcut had made the intrusion possible in the first place.

The second failure was that buyers had almost no reliable means of distinguishing a secure product from an insecure one. In the absence of any common standard or visible signal at the point of sale, security remained invisible at precisely the moment when purchasing decisions were being made, and a market that cannot see security will not reward it. Manufacturers who chose to invest in it therefore found themselves competing on price against those who had chosen not to.

The CRA sets out to address both failures through a single mechanism. It establishes a common baseline that every product within its scope must meet, and it connects that baseline directly to market access, so that security ceases to be an optional feature and becomes instead a condition of being permitted to sell at all. In doing so, it places responsibility with the party that is best positioned to manage the risk, which is the manufacturer.

What the CRA Is

The CRA takes the form of a Regulation, and in the language of European Union law that distinction carries real weight. A Regulation applies directly and uniformly in every member state from the moment it takes effect, without any intermediate step in which each country enacts its own version, which means that the core requirements and the associated deadlines are the same whether an organisation happens to be dealing with Germany, France, or any other part of the Union.

There is, however, one important qualification to that uniformity. Each member state remains responsible for setting and enforcing its own penalty rules, within the limits that the CRA prescribes, so the manner in which a breach is investigated and fined may still differ from one country to another. The Regulation is also marked as relevant to the wider European Economic Area, although it does not take effect there automatically, since its application in the non-EU states of that area depends on its formal incorporation into the EEA Agreement.

The CRA has been built upon the established model of European product law, the same framework that places the familiar CE mark on electronics, toys, and machinery. This was a deliberate design decision, because it allows cybersecurity to be enforced through a structure that manufacturers, importers, distributors, and national market authorities already understand and know how to operate.

Who the CRA Applies To

The law is framed around a particular term, the product with digital elements, which in practical terms refers to any hardware or software product, together with any remote or cloud-based components on which it depends and any parts that happen to be sold separately.

Whether the CRA actually applies to such a product then depends on a further condition. The product must be placed on the EU market, and its intended or reasonably foreseeable use must involve a connection to a device or a network. This condition has been drawn deliberately broadly, with the result that it captures consumer gadgets, business software, operating systems, network equipment, individual components, mobile applications, and industrial devices alike. A sensible rule of thumb, therefore, is to treat any product that connects to something as worth examining, rather than to assume from the outset that it must fall outside the law.

The obligations attach to the product itself rather than to the nationality of its maker, so a manufacturer located anywhere in the world is bound by the same rules as a European one once it begins to sell into the Union. Where an importer established in the EU brings a non-EU manufacturer's product to market, that importer assumes its own duties to verify that the product is compliant, and a manufacturer may in addition appoint a representative within the Union to act on its behalf. Each participant in the chain, from manufacturer through importer to distributor, carries a set of duties appropriate to its particular role, rather than one identical set of obligations imposed uniformly on all of them.

Certain products lie outside the CRA because their cybersecurity is already governed by other European legislation, among them medical devices, motor vehicles, civil aviation, and marine equipment. Two further areas tend to cause more confusion than the rest, and each of them deserves a clear explanation.

Free and open-source software. Software that is developed and shared outside any commercial activity generally falls outside the CRA altogether. Once open-source software is supplied commercially, however, the obligations that arise will depend on the role the provider plays and on the manner in which the software is made available. In order to accommodate the way that open-source projects are actually sustained, the CRA introduces a lighter category known as the open-source software steward, which is intended for the foundations and organisations that support the projects used within commercial products, and such stewards carry proportionate responsibilities without being exposed to fines.

Cloud services and software as a service. Standalone online services of this kind ordinarily sit outside the CRA, with one exception. Where a portion of such a service functions as a remote data-processing solution that a product genuinely requires in order to perform one of its functions, that portion is treated as part of the product and therefore falls within scope. Providers of purely standalone services may instead find themselves governed by a separate instrument, the NIS2 Directive.

How Products Are Classified

The CRA does not subject every product to the same degree of scrutiny. Instead, it arranges products into four groups according to what each product principally does, and the group into which a product falls determines how rigorously the manufacturer must demonstrate that it meets the rules. That demonstration is known as conformity assessment, and, depending on the level of risk involved, it may be carried out either by the manufacturer itself or by an independent body.

• The great majority of products fall into the category of standard products, for which the manufacturer is generally able to assess its own product and declare that it complies.
• Important products of Class I include items whose purpose is security-related or otherwise higher in risk, such as password managers, virtual private networks, network management systems, and operating systems, and although the manufacturer may still assess these itself, it may do so only where it correctly applies the relevant standards, failing which an independent body must be involved.
• Important products of Class II, which include firewalls, intrusion detection systems, and hypervisors, are higher in risk still, and for that reason they always require an independent assessment.
• Critical products, such as smartcards, secure elements, and smart meter gateways, are subject to the strictest route of all, and they may be required to hold a formal European cybersecurity certificate.

Whichever group a product belongs to, the process concludes in the same manner. The manufacturer draws up a declaration of conformity, which is a signed statement to the effect that the product meets the applicable requirements, and then affixes the CE mark to it. It is worth being precise about what that mark signifies, because it is easy to read more into it than it actually conveys. The mark indicates that the manufacturer has declared the product compliant after completing the required assessment, but it is neither a guarantee that the product is free of vulnerabilities nor evidence that every product has been independently tested by a third party.

What a Compliant Product Must Do

At the centre of the CRA lies a set of essential requirements, and these fall into two halves. The first concerns the security properties that the product itself must possess, while the second concerns the processes that the manufacturer must operate in order to handle vulnerabilities throughout the product's life. A product is compliant only when it satisfies both halves together.

In order to translate these requirements into something that engineers can genuinely follow, the European standards bodies are preparing a dedicated family of standards known as the EN 40000 series. It is important to be candid about their present status, since they remain drafts and do not yet carry the force of law in their own right. Once they have been officially published and correctly applied, however, they are expected to confer what is termed a presumption of conformity, which means that a manufacturer that follows them will be treated as having met the corresponding parts of the law. In practical terms they represent the clearest available bridge between the text of the CRA and the day-to-day work of product development. One part of the series establishes a shared vocabulary so that everyone relies on the same definitions, a second sets out the principles of cyber resilience, and a third addresses the handling of vulnerabilities.

The principles offer the most concise summary of what a compliant product should embody, and they reward careful reading.

• The first principle is that security should be risk-based, which means that the protection applied ought to be proportionate to the risk at hand, since a connected medical device and a smart light bulb face very different threats and should not be held to one identical checklist.
• The second is security by design, under which security is considered from the earliest stages of development and built into the requirements, the architecture, and the testing, rather than added as an afterthought once the product is nearly complete.
• The third is that a product should be secure by default, so that it is safe in the state in which it ships, without depending on the user to adjust any settings first, and it is this principle that removes the familiar problems of default passwords and unnecessary open features.
• The fourth is transparency in product security, whereby the manufacturer is open about what the product's security does and does not do, about its known limitations, and about the measures that have been taken to manage risk, and provides users with clear documentation.

Resting on those principles, the product itself is expected to meet a number of concrete properties. It must be placed on the market without known exploitable vulnerabilities and with a secure default configuration, and it must provide a means of correcting flaws through security updates. It must control who is able to access it, protect both the confidentiality and the integrity of the data it holds, and collect only the data that it genuinely needs. It must continue to function when it is placed under attack, keep its exposed surface as small as possible, record events of security significance, and allow users to delete their data securely once they no longer require it.

Vulnerability Handling: From Report to Fix

The second half of the requirements is the part for which many manufacturers are least prepared, because it calls for an ongoing process rather than a single test conducted before launch. Perhaps the clearest way to understand it is to follow one vulnerability along its entire journey, from the outside world through to a corrected version in the hands of users, and the vulnerability-handling standard within the EN 40000 series sets out that journey as an orderly sequence.

The work begins well before any report is ever received, because vulnerabilities cannot be handled effectively without the necessary groundwork already in place. That groundwork consists of a written policy governing how vulnerabilities are handled, a public policy that tells researchers how to report the problems they find, secure internal channels of communication, a dependable mechanism for distributing updates, and a software bill of materials. The software bill of materials is, in essence, a list of the software components contained within a product, presented in a form that a machine can read and covering at least the product's top-level dependencies, and it matters a great deal, because when a new flaw is announced in a widely used software library, that list is what allows a manufacturer to establish within hours, rather than weeks, whether its own products are affected.

The process of reporting a problem to the manufacturer must be made both straightforward and safe. It is not sufficient to wait passively for the occasional bug report to arrive, and a manufacturer is therefore expected to publish a clear disclosure policy and to offer more than one confidential means of making contact, so that a finding can reach the right people regardless of the technical sophistication of the person who is reporting it. A well-constructed policy also provides a safe harbour, which is an undertaking not to pursue legal action against a researcher who acts in good faith, who reports the issue privately before making it public, and who neither exploits the flaw nor attempts to extract payment in return for it. That single undertaking is very often what transforms the security community from a perceived threat into a genuinely valuable source of assistance.

Within the organisation, each report is best managed in much the same way as a support ticket. Every report is recorded and tracked as a case in its own right, and the person who submitted it receives an acknowledgement promptly, typically within two to three days, so that they know it has been received and is being taken seriously. The manufacturer then confirms whether the flaw is genuine and how serious it is, checks it against the software bill of materials in order to identify every product and version that is affected, and assigns to it both a severity and a responsible owner. Handling vulnerabilities as tracked cases, each with a clear owner and a defined deadline, is precisely what makes the reporting timescales that follow realistic rather than a last-minute scramble.

Once the flaw has been confirmed, the manufacturer develops and tests a correction, delivers it through the update mechanism prepared earlier, and provides it free of charge for as long as the product continues to be supported. When the correction is available, the manufacturer discloses the vulnerability responsibly, accompanied by a clear description and by guidance that enables users to protect themselves in the meantime.

A number of cases carry a further obligation, in that they must also be reported to the authorities. Where a vulnerability is being actively exploited, or where a severe incident affects the security of a product, the manufacturer is required to notify the authorities according to a fixed schedule under Article 14. An early warning must be submitted within 24 hours of the manufacturer becoming aware of the matter, and a fuller notification within 72 hours. The final step then depends upon the nature of the case. For a vulnerability that is being actively exploited, the final report is due within 14 days of a corrective measure becoming available, whereas for a severe incident it is due within one month of the 72-hour notification. This distinction is worth stating carefully, because a widely repeated shorthand collapses both cases into a single fourteen-day rule, and that shorthand is simply incorrect.

Penalties, and the Real Consequence

The CRA is supported by substantial financial penalties. A breach of the essential requirements or of the core manufacturer duties can attract a fine of up to €15 million or 2.5% of worldwide annual turnover, whichever of the two figures is higher, with lower ceilings applying to less serious breaches. It is the turnover figure that gives these penalties their weight in the case of large companies, since a percentage of global revenue can far exceed the fixed monetary cap. As noted earlier, the individual member states establish their own national penalty rules within the framework that the CRA sets, so the precise exposure will depend in part on the country in which a breach happens to be pursued.

The fine, however, is seldom the most severe consequence, because the greater pressure arises from the question of market access. A product that has not been brought into compliance, and that consequently lacks a valid CE mark and declaration of conformity, cannot lawfully be placed on the EU market at all. In the case of products that are already on sale, the authorities may require corrective action, restrict or prohibit them, and order their recall, and a product judged to present a serious risk may be withdrawn from the market across the entire Union. Because distributors are not permitted to stock products that fail to comply, the damage extends well beyond any individual fine, reaching into lost sales channels, enforced recalls, and exclusion from serious procurement. For a business whose livelihood depends on selling into Europe, compliance is not, therefore, a cost to be weighed against the possibility of a fine, but rather the very condition of having a product to sell in the first place.

How Beacon Security Can Help

Much of the CRA consists of engineering and process work rather than paperwork, and it is there that the real effort is required. Beacon Security works alongside your product, engineering, and leadership teams to build the capability that the law expects, rather than simply presenting a list of tasks to be completed.

• Through a gap assessment, we measure your products and processes against the essential requirements and the EN 40000 series, and set out clearly where the gaps lie and what will be involved in closing them.
• In the area of secure development and process design, we help you put the principles of security by design and secure by default into everyday practice, together with the product risk assessment and lifecycle activities that the law anticipates.
• For vulnerability handling and disclosure, we help you establish a disclosure policy, confidential reporting channels, and a triage and remediation workflow, so that the 24-hour and 72-hour reporting deadlines become genuinely achievable.
• On documentation, we help you build and maintain a software bill of materials and prepare the technical file and the declaration of conformity on which a conformity assessment depends.
• Through training and awareness, we prepare the engineering, product, and management teams who carry out the work, so that the obligations are understood at the points where decisions are actually taken.
• By means of internal audit and readiness reviews, carried out ahead of both the conformity assessment and the reporting deadline, we ensure that any gaps come to light on your own schedule rather than on that of an assessor.

The Compliance Timeline

The CRA does not arrive all at once but instead takes effect in stages, and those dates only acquire their full meaning once the obligations that sit behind them are understood, which is the reason they appear at the end of this guide rather than at the beginning.

December 2027 can appear comfortably distant, yet to treat it as a far-off deadline would be a mistake. Establishing a secure development process, a functioning disclosure programme, and a software bill of materials across an entire product range is measured in quarters and years rather than in weeks. Independent assessment, moreover, is available only in limited quantity, and the manufacturers who leave the matter late will find themselves competing for that capacity with everyone else who has done the same.

Most significant of all, the first genuinely binding deadline does not fall in 2027 at all. From September 2026, a manufacturer must already be capable of detecting a serious vulnerability, escalating it internally, and reporting it within 24 hours, and that duty extends to products that are already in the field. The interval between now and these dates is best understood as the time available in which to carry out the work, and not as a grace period to be enjoyed before that work begins.

This is a general awareness guide, and it is not a substitute for legal advice or for Regulation (EU) 2024/2847 and the current guidance of the European Commission, both of which take precedence. Beacon Security helps manufacturers and suppliers prepare for the Cyber Resilience Act, from gap assessment and secure development through to vulnerability handling, SBOM readiness, documentation, and training. Contact us to build a CRA readiness plan for your products and your supply chain.