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

For decades, a product could be sold in Europe with almost any level of cybersecurity, or none at all. A router could ship with a hard-coded admin password. A smart camera could go years without a single security patch. Industrial equipment could reach the end of its sale life with known, unfixed vulnerabilities still inside it. There was no law that said any of this was wrong, because product safety law was written for physical hazards, electric shock, fire, mechanical failure, not for software that could be attacked across a network.

The European Union Cyber Resilience Act closes that gap. For the first time, cybersecurity becomes a legal condition for placing a product on the EU market, on the same footing as electrical safety or electromagnetic compatibility. If a product has digital elements and it connects to anything, its manufacturer now carries binding obligations for how it is built, how vulnerabilities are handled, how long it is supported, and how incidents are reported. Products that do not meet the bar cannot legally be sold in the Union.

This is one of the most consequential pieces of cybersecurity legislation in the world, and its reach extends far beyond Europe's borders. If you make, import, or distribute connected products, or if you operate infrastructure that depends on them, the CRA affects you, and the clock is already running. This guide explains what the CRA is, exactly who it covers, the deadlines you must plan around, the requirements a compliant product has to meet, and the consequences of getting it wrong.

Why the Cyber Resilience Act Exists

The CRA responds to a structural failure in the digital product market. Two problems drove it.

The first is a low and inconsistent level of security in products with digital elements. Insecure products became one of the main pathways for successful cyberattacks, and the cost of that insecurity fell on users and society rather than on the manufacturers who created it. When a poorly secured device is compromised and drawn into a botnet, or used as a foothold into a network, the manufacturer who cut the corner rarely pays the price.

The second is that buyers, whether consumers or businesses, had almost no way to tell secure products from insecure ones. There was no label, no declaration, no baseline requirement. Security was invisible at the point of purchase, which meant the market did not reward it. Manufacturers who invested in security competed on price against those who did not.

The CRA corrects both problems by setting a mandatory baseline and tying it to market access. Security stops being an optional selling point and becomes a legal precondition. Buyers gain a signal they can trust, the CE marking, that now carries a cybersecurity meaning. And the cost of insecurity moves back to the party best placed to prevent it: the manufacturer.

What the CRA Actually Is

The Cyber Resilience Act is Regulation (EU) 2024/2847. It was adopted on 23 October 2024, published in the Official Journal on 20 November 2024, and entered into force on 10 December 2024.

The single most important legal fact about the CRA is that it is a Regulation, not a Directive, and that distinction shapes everything about how it applies. A Regulation is binding in its entirety and directly applicable in every member state. There is no national transposition step, no waiting for 27 separate countries to write their own versions, and no country-by-country variation in the rules, the deadlines, or the penalties. The same obligations take effect on the same day across the entire Union and the wider European Economic Area.

This matters enormously for planning. Contrast the CRA with the NIS2 Directive, which each member state had to convert into its own national law, a process that ran years behind schedule and produced meaningful differences between countries. With the CRA there is nothing to wait for. The text is final, the dates are fixed, and they apply to you directly.

The CRA is built in the style of European product-safety law. It belongs to the same family of legislation that governs the CE marking you already see on electronics, machinery, and toys. That design choice is deliberate: it plugs cybersecurity into an enforcement machine that manufacturers, importers, distributors, and market surveillance authorities already understand.

Who the CRA Applies To

The CRA regulates products with digital elements, defined as any software or hardware product, and its remote data processing solutions, that includes a direct or indirect logical or physical data connection to a device or network. In plain terms, if it contains software and it can connect to something, it is in scope.

The scope is deliberately broad, close to universal for the connected product market. It reaches consumer devices, business software, operating systems, network equipment, hardware components, firmware, mobile apps, and industrial devices alike. The default assumption should be that a product is in scope unless it is specifically excluded. This is not a narrow rule aimed only at critical infrastructure. It is a horizontal law that touches most of the digital economy.

The CRA reaches manufacturers anywhere in the world. The trigger for the law is placing a product on the EU market, not where the maker is located. A manufacturer in India, the United States, or anywhere else that sells connected products into the Union is bound by the CRA just as fully as a European one. In practice, a non-EU manufacturer must operate through an EU-based importer or an appointed authorised representative, and those parties carry their own verification duties. The obligation follows the product through the whole distribution chain.

What Falls Outside the CRA

The CRA avoids double regulation by excluding products already governed by dedicated sectoral rules. Out of scope are:

• Medical devices and in-vitro diagnostic devices, covered by their own EU regulations.
• Motor vehicles, covered by EU vehicle type-approval and cybersecurity rules.
• Civil aviation products certified under EU aviation safety law.
• Marine equipment under its own directive.
• Products developed exclusively for national security or defence, or to process classified information.
• Spare parts that simply replace identical components to the same specification.

Two categories deserve special mention because they cause the most confusion:

Free and open-source software. Non-commercial open-source software, the hobby project or community library developed and shared outside a commercial activity, is out of scope. To avoid chilling the open-source ecosystem, the CRA also creates a lighter-touch role called the open-source software steward for foundations and organisations that systematically support commercial-use open source. Stewards have proportionate duties but are not subject to administrative fines. However, once open-source software is monetised or offered with paid commercial support, the provider can be pulled into the full set of manufacturer obligations.

Software-as-a-Service and cloud. Pure SaaS and cloud services are not products under the CRA; they fall under the NIS2 Directive instead. The exception is when a remote data processing solution is integral to a product, when the connected product will not function without its manufacturer-operated backend. In that case the backend is treated as part of the product and comes into scope.

The Compliance Timeline: The Dates That Matter

The CRA applies in phases. Understanding these dates, and what has to be ready by each one, is the difference between a controlled compliance program and a last-minute scramble.

It is tempting to look at December 2027 and conclude there is plenty of time. That reading is a trap, for several reasons.

The substantive obligations are build-outs, not paperwork. Standing up a secure development lifecycle, a coordinated vulnerability disclosure program, and machine-readable software bills of materials across an entire product portfolio is measured in quarters and years, not weeks. These are process and engineering changes, and they touch how products are designed, built, tested, and maintained.

Third-party assessment has finite capacity. Higher-risk products need assessment by a notified body. Those bodies only come online from June 2026, and their capacity is limited. Manufacturers who wait will find themselves in a queue with everyone else who waited.

The reporting duty arrives first, in September 2026. More than a year before full application, manufacturers must already have a working capability to report actively exploited vulnerabilities and severe incidents to the authorities within 24 hours. That capability, the monitoring, the internal escalation, the reporting channel, has to exist and be rehearsed before the deadline, not after.

Harmonised standards are still being written. The technical standards that make compliance practical, and that grant a presumption of conformity, are being developed now and will land close to the deadline, compressing the window in which manufacturers can adopt them.

The realistic conclusion: any organisation in scope should already be moving. The gap between now and the deadlines is the time you have to do the work, not a grace period before you start it.

How Products Are Classified: The Four Risk Tiers

Not every product carries the same risk, so the CRA does not treat every product the same way. It sorts products into tiers, and the tier determines how rigorously conformity must be demonstrated. The higher the risk a product represents to the systems around it, the more independent the assessment has to be.

Default products. The large majority of products fall here. The manufacturer can demonstrate conformity through self-assessment, using an internal control procedure, without involving a third party. Self-assessment does not mean the requirements are lighter. It means the manufacturer is trusted to assess its own conformity against the same essential requirements, and remains fully liable for that assessment.

Important products, Class I. These are products whose core function is security-related or that carry elevated risk. The category includes identity and access management software, password managers, VPN products, network management systems, security information and event management (SIEM) systems, firewalls' lighter cousins in network gear such as routers and switches, operating systems, boot managers, public key infrastructure software, and microcontrollers and microprocessors with security-related functions. Class I products can still be self-assessed, but only if the manufacturer fully applies the relevant harmonised standards or a European cybersecurity certification scheme. Otherwise, a third-party assessment is required.

Important products, Class II. These are the higher-risk security products: firewalls, intrusion detection and prevention systems, hypervisors and container runtimes, and tamper-resistant microprocessors and microcontrollers. For Class II, third-party assessment by a notified body is effectively mandatory. Self-assessment is not available.

Critical products. The top tier covers the highest-assurance components: hardware devices with security boxes, smart meter gateways and devices for advanced security purposes such as secure cryptoprocessing, and smartcards and secure elements. For these, the Commission can require a European cybersecurity certificate at a substantial assurance level, the strictest route the framework provides.

A note on how these lists are set. The specific product categories in the important and critical tiers are defined in the Regulation's annexes and further detailed by Commission implementing acts. The examples above reflect the enacted categories, but manufacturers should confirm the exact classification of any specific product against the current implementing regulation rather than relying on general summaries, because the technical descriptions are the legal reference.

Whichever tier applies, the endpoint is the same: the manufacturer draws up an EU declaration of conformity and affixes the CE marking. On a product with digital elements, that CE mark now attests to cybersecurity conformity, and it is the legal gate to the market.

The Essential Requirements: What a Compliant Product Must Do

The heart of the CRA is a set of essential cybersecurity requirements set out in Annex I. They come in two parts. Part I governs how the product itself must behave. Part II governs the processes the manufacturer must run around it. A compliant product needs both.

Part I: Security Properties of the Product

Products must be designed, developed, and produced to deliver an appropriate, risk-based level of cybersecurity. Based on the manufacturer's risk assessment, a compliant product should, among other things:

• Be placed on the market with no known exploitable vulnerabilities.
• Ship with a secure-by-default configuration, and offer the ability to reset the product to that original secure state.
• Include a mechanism to fix vulnerabilities through security updates, including, where applicable, automatic updates that are on by default with an easy opt-out.
• Protect against unauthorised access through appropriate access controls, including authentication and identity management, and report attempted unauthorised access.
• Protect the confidentiality of stored and transmitted data, for example through state-of-the-art encryption.
• Protect the integrity of data, commands, programs, and configuration against unauthorised manipulation.
• Practise data minimisation, processing only the data that is adequate, relevant, and necessary.
• Protect availability of essential functions, including resilience against denial-of-service attacks.
• Minimise their own attack surface, including external interfaces.
• Reduce the impact of an incident using appropriate exploitation-mitigation techniques.
• Provide security-relevant logging and monitoring of internal activity.
• Allow users to securely and permanently delete data and settings.

Part II: Vulnerability Handling Processes

The product properties are only half the picture. The CRA also requires manufacturers to run mature processes for handling vulnerabilities across the product's life. Manufacturers must:

1. Identify and document vulnerabilities and components, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format, covering at least the top-level dependencies of the product.
2. Address and remediate vulnerabilities without delay, including by providing security updates, and where feasible ship security updates separately from feature updates.
3. Apply regular security testing and reviews.
4. Once a fix is available, publicly disclose information about fixed vulnerabilities, including a description, the affected products, the impact, the severity, and remediation guidance.
5. Put in place and enforce a coordinated vulnerability disclosure policy.
6. Provide a contact address for reporting vulnerabilities and facilitate information sharing.
7. Provide mechanisms to securely distribute updates.
8. Ensure security updates are disseminated without delay and, other than for tailor-made products by agreement, free of charge.

Why the SBOM requirement is a turning point: for years, buyers, especially in critical infrastructure, have asked vendors for a software bill of materials and been told it was not available. The CRA makes it a legal obligation. Every in-scope product must have a machine-readable inventory of at least its top-level software components. When the next widespread vulnerability in a common library appears, the difference between an organisation that can query its SBOMs and identify affected products in hours, and one that must email vendors and wait weeks, is enormous. The CRA moves the whole market toward the former.

The Support Period and Update Obligation

One of the most practically significant requirements concerns how long a product must be supported. Under the CRA, the manufacturer must provide security updates for a support period of at least five years. Where a product is reasonably expected to be in use for less than five years, the support period matches that shorter expected use.

The manufacturer sets the exact period to reflect how long the product will realistically be in service, considering user expectations, the nature and purpose of the product, and comparable products on the market. During the support period, vulnerabilities must be handled and security updates provided free of charge. To give buyers transparency, the end-of-support date has to be made clear at the point of purchase, so a buyer knows how long the product will receive security fixes before they commit to it.

For long-lived assets this is a meaningful shift. A buyer can now expect, as a legal baseline, that a connected product will be patched for a defined and disclosed period, rather than discovering after the fact that support quietly ended.

Obligations Across the Supply Chain

The CRA places duties on every economic operator that handles a product, not just the manufacturer, so that non-compliant products are caught at multiple points.

Manufacturers carry the primary responsibility. They must design and build to the essential requirements, conduct and document a cybersecurity risk assessment, exercise due diligence over third-party and open-source components, run the vulnerability-handling processes, set and honour the support period, carry out the applicable conformity assessment, compile technical documentation, draw up the EU declaration of conformity, affix the CE marking, and comply with the reporting obligations.

Importers may place a product on the EU market only if it is conforming. Before doing so, they must verify that the manufacturer carried out the conformity assessment, drew up the technical documentation, affixed the CE marking, and provided the declaration of conformity and user instructions. An importer who believes a product is non-conforming must not place it on the market, and must inform the manufacturer and the authorities where there is a significant cybersecurity risk.

Distributors must act with due care, verify the CE marking and that the upstream operators met their obligations, and refrain from making a non-conforming product available. They must cooperate on corrective actions, withdrawals, and recalls.

A recurring principle runs through all of this: any importer or distributor who modifies a product substantially, or markets it under its own name, is treated as a manufacturer and inherits the full set of manufacturer obligations.

Incident and Vulnerability Reporting

From 11 September 2026, manufacturers must report two kinds of events: any actively exploited vulnerability in their product, and any severe security incident affecting the security of the product. Reports go simultaneously to the designated national CSIRT acting as coordinator and to ENISA, submitted through a single reporting platform so a manufacturer files once rather than to many bodies.

The reporting cadence is staged:

This is a demanding capability to build. Reporting within 24 hours means an organisation needs monitoring that would surface an actively exploited vulnerability, an internal escalation path that reaches the right people fast, and a rehearsed process for filing to the platform. This is exactly why the reporting obligation is the first hard deadline that bites, and why it should be in place and tested well before September 2026.

Penalties, and the Real Consequence: Losing the EU Market

The CRA is backed by significant administrative fines, set in three tiers, based on whichever figure is higher.

The turnover-based ceiling is what makes these fines serious for large companies: 2.5% of global turnover can dwarf the fixed figure. Fines are imposed by national market surveillance authorities and must be effective, proportionate, and dissuasive. Open-source software stewards are not subject to these administrative fines, and smaller enterprises receive proportionality consideration.

But the fine is not the biggest stick. The real consequence of non-compliance is loss of market access. Without a valid CE marking and declaration of conformity, a product with digital elements simply cannot be legally placed on or made available on the EU market. There is no version of this where a manufacturer absorbs a fine as a cost of doing business and carries on selling. A non-compliant product is barred at the gate.

For products already on the market, authorities operating under the EU market surveillance regime can order corrective action, restrict or prohibit a product from being made available, and require its withdrawal or recall. Where a product presents a significant cybersecurity risk, it can be forced off the market across the entire Union. Distributors are legally barred from stocking non-CE products, so the commercial consequences cascade well beyond any fine: lost distributors, forced recalls, reputational damage, and exclusion from business procurement.

The takeaway: compliance is not a risk to be priced and managed against a possible fine. For anyone whose business depends on selling connected products into Europe, it is a precondition for having a product to sell at all.

How the CRA Connects to Standards and Other Laws

The CRA does not stand alone. It sits inside a larger European cybersecurity framework and leans on technical standards to make compliance workable.

Harmonised standards and the presumption of conformity. A product that conforms to harmonised standards published in the EU's Official Journal is presumed to conform to the corresponding essential requirements. This is the practical backbone of compliance: meeting the standard means a manufacturer does not have to argue conformity from first principles, and for Class I products it can preserve the self-assessment route. The Commission has tasked the European standardisation organisations, CEN, CENELEC, and ETSI, with producing the CRA harmonised standards, and that work is underway with delivery targeted ahead of full application.

The EU Cybersecurity Act. The CRA connects to the European cybersecurity certification schemes established under the Cybersecurity Act. For critical products, the Commission can require certification at a substantial assurance level, and certification can also serve as a conformity route for important products.

NIS2. The CRA and the NIS2 Directive are complementary rather than overlapping. NIS2 governs the cybersecurity of organisations, the essential and important entities that operate critical services. The CRA governs the cybersecurity of products. A more secure product baseline strengthens the supply chain that NIS2 operators depend on, which is why the two are best understood as layers of the same strategy: secure the products, and secure the organisations that run them.

IEC 62443 and consumer IoT standards. For industrial and operational technology, the technical work behind the CRA harmonised standards is expected to build on the IEC 62443 series, the leading international standard for the security of industrial automation and control systems. For consumer IoT, the baseline draws on ETSI EN 303 645 and the EN 18031 series developed for radio-equipment cybersecurity. Manufacturers already aligned to these standards will find much of the CRA groundwork familiar.

What the CRA Means for OT and Industrial Devices

Operational technology deserves specific attention, because it is both squarely in scope and frequently misunderstood.

Industrial and OT products, programmable logic controllers, remote terminal units, human-machine interfaces, industrial network equipment, sensors, and gateways, are products with digital elements when they contain software and can connect to a network. They are in scope exactly as much as any IT product, and non-EU industrial vendors that sell into Europe are bound.

A point of frequent confusion is worth clearing up. An earlier 2022 draft of the CRA explicitly listed industrial automation and control systems, including PLCs, DCS, and SCADA, as critical products. Those entries were removed from the enacted 2024 Regulation. As a result, most general OT devices are default-class products subject to self-assessment, unless a specific component or function pulls them into a higher tier. An industrial firewall, for example, falls into the Class II important category; an embedded security microcontroller can be Class I; a secure element can be critical. Manufacturers and buyers should classify each product on its actual function, and should not repeat the outdated claim that the CRA labels PLCs or SCADA systems as critical.

For asset owners and critical-infrastructure operators, the CRA is quietly powerful, because it hands them leverage they never had before. From full application, OT vendors selling into the EU must ship products with no known exploitable vulnerabilities, secure-by-default configurations, at least five years of free security updates, a coordinated vulnerability disclosure program, and a machine-readable SBOM. These are exactly the features OT buyers have requested for years and rarely received. Now they are a legal baseline, and operators can require them contractually with the weight of the law behind the request.

Procurement implication: operators should not wait for December 2027 to feel the benefit. They can start writing CRA conformity into OT tenders and RFPs now, requiring CE marking, a declaration of conformity, SBOM delivery, a declared support period, and a vulnerability-disclosure contact. Vendors that cannot meet these terms will increasingly be excluded from serious procurement well before the legal deadline, which turns the CRA into a commercial reality ahead of its formal one.

Common Findings from Beacon Security's Work

Across OT and product-security assessments, several patterns come up repeatedly that will make CRA readiness harder for organisations that do not address them now:

• No software bill of materials anywhere. Manufacturers frequently cannot produce a component inventory for their own products, and asset owners cannot obtain one from their vendors. Building SBOM generation into the development pipeline is often the single largest gap.
• Security treated as a release checkbox, not a lifecycle. Products get a one-time security test before launch, with no process for handling vulnerabilities that surface after shipping. The CRA's Part II process requirements are where many manufacturers are least prepared.
• No coordinated vulnerability disclosure channel. There is often no published contact, no policy, and no internal workflow for receiving and acting on a vulnerability report from an outside researcher.
• Undefined or informal support periods. Manufacturers rarely commit to a defined update period, and buyers rarely have it in writing. The CRA forces both sides to make this explicit.
• Reporting readiness underestimated. Very few organisations could actually meet a 24 hour reporting deadline today. The monitoring, escalation, and filing capability has to be built and rehearsed, not assumed.
• Procurement contracts silent on product security. OT asset owners often have no security clauses in vendor contracts, which means they inherit whatever the vendor chooses to provide. The CRA is the moment to change that.

What to Do Now: A Compliance Checklist

For manufacturers, the path to compliance is a program, and it should be running already:

1. Scope and classify. Inventory every product sold or planned for the EU, confirm which are products with digital elements, and classify each as default, important Class I, important Class II, or critical.
2. Run a gap analysis against the Annex I essential requirements, both the product properties and the vulnerability-handling processes.
3. Stand up a secure development lifecycle, with secure design, threat modelling, security testing, secure defaults, and a no-known-exploitable-vulnerabilities gate at release.
4. Build SBOM tooling and process, generating machine-readable software bills of materials and performing due diligence on third-party and open-source components.
5. Establish vulnerability handling and coordinated disclosure, with a policy, a reporting contact, remediation timelines, and a secure, free update-distribution mechanism.
6. Set and document the support period, at least five years or the expected use time, and build the capability to deliver updates across it.
7. Build the incident and vulnerability reporting capability on the 24, 72, and 14 cadence, wired to ENISA and the national CSIRT, and have it live before 11 September 2026.
8. Choose and execute the conformity assessment route, self-assessment where allowed, or third-party assessment for Class II and critical products, and book notified-body capacity early.
9. Compile technical documentation and user information, draw up the EU declaration of conformity, and affix the CE marking.
10. If you are a non-EU manufacturer, appoint an EU authorised representative and line up compliant importers.

For asset owners and operators, the action is different but no less urgent: start requiring CRA conformity in procurement now, and use the SBOM and support-period obligations to strengthen your own vulnerability management and supply-chain security.

The Cyber Resilience Act is not a distant regulatory abstraction. It is a binding law with fixed dates, real penalties, and a market-access gate that no in-scope organisation can ignore. The organisations that treat the time between now and 2027 as working time, rather than waiting time, are the ones that will still have products to sell in Europe when the deadline arrives.

Beacon Security helps product manufacturers and industrial operators prepare for the Cyber Resilience Act, from product classification and secure-development and SBOM readiness to IEC 62443 aligned assessments and OT procurement requirements. Contact us to build a CRA readiness plan for your products and your supply chain.